Documentation Overview and Products

Introduction

The doc team seeks to create useful information for anyone who uses the edX platform—learners, educators, researchers, system admins, and developers. Our documentation is based roughly on audience, with one or more products that correspond to each one. For example, for our course authors audience, we have the Building and Running an edX Course guide. 

Because the documentation team's capacity has been limited, ownership and maintenance of some of these products has been transferred to other teams. The documentation team currently maintains documentation for all Learner, Educator, and Business teams, but does not cover any Infrastructure teams, including the Open Source and data teams. 

Specifically, the documentation team will continue to update the partner version of our educator and learner guides (Building and Running an edX Course and the EdX Learner's Guide) and any documentation for the business team. The documentation team does not currently maintain the Open edX versions of our educator and learner guides (Building and Running an Open edX Course and the Open EdX Learner's Guide).

If partner, learner, or business documentation needs updates, anyone in the organization—including program coordinators, partner managers, and course author support—can submit a JIRA ticket to the DOC project. The documentation team will prioritize these requests.

Other teams will use the information that the documentation team has provided to maintain their documentation products.

For more information, see Doc Team Work Information.

Documentation Product Owners

Updating Documentation Products

The owner of a documentation product determines if a feature or change needs documentation, then either creates that documentation independently or requests help from the documentation team.

Determine Documentation Needs

In general, you can use the following checklist to determine whether a feature or change needs documentation. The page for each product has more information for that specific product.

  • Is documentation for this feature a contractual obligation?
  • Will this feature/change require action from the guide's audience? For example, will this change affect any settings that system administrators or developers depend on, or will this change affect the way system administrators operate an Open edX instance?
  • Will this feature/change be visible to the guide's audience, even if the feature/change doesn't require action? For example, time zone improvements caused course due dates and times to change automatically to a learner's new time zone. Previously, both the Building and Running guide and the EdX Learner's Guide specifically mentioned that all times were in UTC.
  • Will this feature/change provide a new opportunity for the guide's audience? For example, is the feature a new tool that course teams can (but aren't required to) use?
  • Will this feature/change cause new events or SQL tables to appear in data packages?

Update Documentation or Submit a Documentation Request

A doc product owner can update documentation independently or request help from the documentation team.

Update Documentation Independently

Creating or updating documentation generally involves creating a new branch from the edx-documentation master branch, finding or creating .rst source files, merging any changes to the master edx-documentation branch, and then building the updated documentation product on readthedocs. 

For more information, see Creating and Updating Documentation - RTD.

Note: The edX Help Center is authored in Zendesk. Contact the doc team for updates or inclusions to the help center.

Request Help from the Doc Team

The documentation team is happy to provide limited writing and editing services. When you request help from the team, you can write a draft of the documentation for the doc team to review, or you can provide enough information for the doc team to write the documentation. The documentation team will then prioritize the work.

To ask for help from the doc team, submit a JIRA ticket to the DOC project. Make sure that the ticket includes:

  • A due date. This is the date when the feature/change is expected to be live (meaning released and turned on—not, for example, behind a flag). If the due date is uncertain, provide a best guess.
  • The engineer who will review the documentation.
  • The product team member who will review the documentation.
  • The feature/change priority.
  • If you have written a draft, the location of the .rst files and/or a PR number.
  • If you have not written a draft, enough detailed information that the doc team can write a draft for you to review. This includes screen shots or a link to a sandbox.
  • Links to additional information about the feature/change, including presentations and wiki pages.