STATUS: Draft - open for comments
The doc is open for comments. Eventually we want to get to “living document”. This can be modified and moved forward but you have to want to propose changes, not just whine about it 
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.
STATUS: Draft - open for comments The doc is open for comments. Eventually we want to get to “living document”. This can be modified and moved forward but you have to want to propose changes, not just whine about it |
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.
When things move - Space maintainers should move/update/archive docs in the spaces they own. Although this adds administrative overhead, the clarity of doling out resources and ownership will be worth the hassle. |
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.
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.
Docs in Confluence are generally scoped and provide access rights based on the space. Spaces 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.)
Cross-functional team spaces (Working Groups, DEI, Hackathon, edX Cares)
Themes (Content, Engagement, etc.)
External resources (https://openedx.atlassian.net/wiki/spaces/AC, UI toolkit)
Localized Spaces 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 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 tags proposed in 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.
These are not linked to our other services and thus not discoverable. They should be viewed as temporary tools for collaboration or should be linked to Confluence/GitHub. |
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.
Graphical Tools (Miro/Figma) etc. - Extract finalized images into the new location (e.g. Core Committers Phase 2 )
Doc Tools - Extract the text or attach the rendered doc in the new location.
These have specific use-cases for broadcast communication and are out of scope of this document.
These have specific use-cases for broadcast communication and are out of scope of this document.