...

Documentation tools best practices

General

• Every doc/space should have a clear audience and owner. Bonus points for establishing these in the header of the doc/space.

  • The audience dictates location/access rights e.g. is the doc/space tied to a repo, team, theme, or functional group; is it public or private.

  • The owner is responsible for lifecycle management. This means setting location/access rights when setting up the doc, and transferring or archiving a doc/space when it is moved or completed.

• Establish rules for what is “canonical” to create a single source of truth.When information should be accessible from multiple places, link rather than duplicating pages.

• Discoverability is key. We need clear rules on what goes where and fewer, established entry points which act as indexes to linked docs.

• Archive more. More docs = more docs to maintain. If docs are out of date, we should be empowering folks to signal that they are out of date or just archive them.

What goes where?

OEP-19 provides guidance on long-term developer documentation, and proposes the following. Summarizing, with light edits:

• Long-term developer docs should live in GitHub.

  • Where docs are coupled with a repo, they should live in /docs or /api for docs and API reference, respectively.

  • This includes things like design docs, arch decisions, READMEs, how-tos, API reference.

  • Depending on scope, they can live in either the repos they document, or broader documentation repos (e.g. edx-documentation) which get built to Read-the-docs.

• Developer Short-term developer notes should be in Confluence.

Extending the guidance above:

• GitHub (including both docs meant to be read in GitHub , followed by Confluence and those published to read-the-docs), should be seen as the “canonical” sources source of information . These established sources allow information to be discoverable & centralizedfor developer docs.

• Confluence is good for docs that don’t fit neatly into a repo or are not strictly code/feature related. Some examples:

  • Organizationally-linked docs - Documents pertaining to a team/project/theme that are scoped to a group in edX e.g. Theme feature planning docs, team meeting notes.

  • Non-code resource docs - Resources like system architecture diagrams, or brand resources that have an Open edX scope, but are too high-level for Read-the-docs.

  • Internal developer docs - Documentation that should be strictly internal and is not tied to a private repo e.g. internal debugging/system notes.

  Docs may be written in other tools should be reserved for short-term or organizational docs.

  • Short-term docs - Documents used for feature planning, discovery work, etc. which are short-lived may live in Confluence. Short-lived docs should either be:

    • Moved to GitHub when finalized, or…

    • Archived when no longer relevant.

  • Organizational docs - Documents pertaining to an internal edX organizational construct (team/project/theme) used for planning and coordination of people can live in Confluence.

• Other tools (e.g. Google Docs, Miro) can be used for the sake of collaborative tooling, rich diagram editing, etc. but must be discoverable (linked) from GitHub or Confluence and, ideally, moved into one of these when complete.

Documentation tools best practices

General

• Every doc should have a clear audience and owner. Bonus points for establishing that in the header of the doc/space.

• Discoverability is key. Establish entry points and have links out to disconnected docs.

• Linking > Duplicating. When possible, establish a single source of truth. Link where necessary. It means you only have to keep one doc up to date and it is clearer when something is canonical.

• Archive more. More docs = more docs to maintain. If docs are out of date, we should be empowering folks to signal that they are out of date or just archive them.

GitHub / Read the Docs

Following OEP-19, documentation around code generally gets stored in GitHub (either to be read in GitHub or published to Read-the-Docs). This allows it to be searchable and live near the code it describes. It also describes different types of docs in GitHub and where to store them:

• Repo specific docs should live in the repos they document and include the following types:

  • ADRs, READMEs, and How-to’s should live in the /docs folder of a repo or app and be linked from the their respective repo/app-level readmeREADME.

• Cross-repo docs go in edx-documentation to be published to Read-the-docs.

Confluence

Best-practices

• Docs in Confluence are generally scoped and provide access rights based on the space. Spaces should have clear purposes and audiences.

• When navigating a space, consider:

  • Purpose (day-to-day planning; education; history)

  • Audience (just the writing team, or broader?)

  • Who can write? Who can read?

Central Spaces - Spaces that are of interest across/outside of the org. These exist separately from Localized spaces, which are targeted to individuals/teams. Centralized spaces are further split into 2 categories based on access-rights:

Internal - Internal resources, private to edX.

are either Internal (private resources to edX e.g. IT, HR, Brand) or External (open to the Open edX community e.g.) and should be clear about their audience. Additionally, we think of spaces in 2 broad categories.

• Centralized Spaces are of broad interest across/outside the org so should be written to be understood by that broader audience. This includes spaces like:

  • Company internal resources (IT, HR, Facilities, Brand, etc.)

  • https://openedx.atlassian.net/wiki/spaces/ENG

  • Cross-functional team spaces (Working Groups, DEI, Hackathon, edX Cares)

  • Themes (Content, Engagement, etc.)

  • External - Spaces of interest to the Open edX community, public by nature.resources (https://openedx.atlassian.net/wiki/spaces/AC

    Shared resource spaces UX, Brand, etc.

    , UI toolkit)

• Localized Spaces - Used for specific teams/individuals, are for organizing focused projects/teams so are not meant to be shared/understand by those outside of the group the space is meant to serve. These include spaces like:

  • Team / squad / personal spaces

• See Proposal: Confluence Organization for more details on how we propose organizing spaces.

• Highest level pages in a space should help self-document the resources in the space. See Creating Index Pages for a template.

• Every space should have an owner .

  The owner should “watch” the entire space and is responsible for

  in charge of keeping the space clean, organized, and useful (including archiving of old pages if not granted to other editors).

• Duplication of information should be avoided, cross link when possible. You can also /include one confluence page into another if you want the info to be seen together.

• Archive more. Anyone stumbling across an out-of-date page should be empowered to update or archive it. Alternatively, for spaces with more restrictive archiving rights, they may request update/archive using the following signals:

  #updates-needed

  tags proposed in Tags & Signaling.

Tags & Signaling

This is a set of proposed labels to apply to Confluence pages meant to signal the type of page or actions that should be taken on a page. Using searches or crawlers, space administrators could use these to keep spaces organized.

• #update-me - Propose adding this new tag to help space owners find out-of-date pages.

• #archive-me - Propose adding this new tag to help space owners find pages that should be archived/deleted

  .Investigate tooling/watching for this tag for space owners so they can be notified about these

  .

Student blog / edX Blog / Open edX Blog / Open edX Discuss

Google docs / Miro / Figma / Other

...

Docs can be written in tools outside of Confluence or GitHub, but everything should be discoverable from one of those 2 tools.

For in-progress docs (e.g. a Miro diagram), they should be linked to the related project/repo.

Info should be moved to Confluence/GitHub when complete in other authoring tools. Delete the old doc or replace the content with a link to the new page after the documentation has been moved.

• For permanent docs Graphical Tools (Miro/Figma) etc. - Extract finalized images into the new location (e.g. diagrams that can’t be done with other tools) they should be linked to a permanent home (Confluence/GitHub) Core Committers Phase 2 )

• Doc Tools - Extract the text or attach the rendered doc in the new location.

Student blog / edX Blog / Open edX Blog / Open edX Discuss