The highest-level goals for this doc are to:

• Clarify what goes where, with the goal of single source-of-truth.

• Establish best-practices for how to use our documentation tools.

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.

• Single source of truth. Establish rules for what is “canonical”. 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. 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.

• Short-term developer notes should be in Confluence.

Extending the guidance above:

• GitHub (including both docs meant to be read in GitHub and those published to read-the-docs), should be seen as the “canonical” source of information for developer docs.

• Confluence 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.

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 their respective repo/app-level README.

• 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.

      • 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.

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

      • Shared resource spaces (e.g. UI toolkit)

  • Localized Spaces - Used for specific teams/individuals, not meant to be shared/understand by those outside of the group the space is meant to serve.

    • Team / squad / personal spaces

• Every space should have an owner.

  • The owner should “watch” the entire space and is responsible for keeping the space clean, organized and useful.

• 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:

  1. #updates-needed - Propose adding this new tag to help space owners find out-of-date pages.

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

  3. 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

• For temporary writing/collaborating but not permanent storage: move them somewhere else (generally Confluence) when done. Delete the old doc or replace the content with a link to the new page after the documentation has been moved.

• For permanent docs (e.g. diagrams that can’t be done with other tools) they should be linked from a permanent home (Confluence/GitHub)