...

...

...

...

...

For features released from edx-platform and other repos, the release notes writer works with the product managers to decide on what will be included in the weekly release notes, and to make sure that the included features and changes are described accurately and positioned appropriately.

The source files for edX release notes are in the edx-documentation/en-us/release_notes folder.

Process

The process for creating or updating release notes is the process outlined on the Creating and Updating Documentation - RTD page, with the additional steps outlined below. 

The Documentation team drafts the release notes by making a new branch off of master. Development, product, and PMs review and revise the notes as necessary through a GitHub pull request. 

...

Note: The source files for edX release notes are in the edx-documentation/en-us/release_notes folder.

1. Review the list of commits that are in the week's releases and works with the product team to determine which items are mentioned, and the descriptive text for each item.
2. Create a branch in the edx-documentation repo, e.g. "RN_WeekEndFeb3" for easy identification.
3. On this branch, create the rst source files for the release notes as follows:
   
   1. Identify what components are affected. For example, studio, lms, analytics, documentation.
   2. In the release_notes/2017 folder, in the appropriate component subfolders (create one if it doesn't yet exist), add a dated file where you'll write the item descriptions. For example, if there is a Studio item and an Analytics item, create studio_2017-02-03.rst under the "studio" subfolder and analytics_2017-02-03.rst under the "analytics" subfolder.
   3. In the release_notes/source/ folder, update the index file for each affected component. For example, update studio_index.rst with a title "Week ending 3 Feb 2017" and an "include" directive to the file you created in step b.
   4. In the release_notes/source/2017 folder, add a summary file for that week's releases, named for the release date (usually the Friday). For example, 2017/2017-02-03.rst. In this date summary file, add a title (e.g. "Studio" or "Analytics") and an "include" directive to each file you created in step b.
   5. In the 2017 folder, update the index.rst with an entry for the summary file you just created. Note that these lines are filenames, not dates.
4. Commit your changes to your branch.
5. On GitHub, create a pull request and tag reviewers. (Going to the repo in Github.com and creating the pull request there gets you the proper PR template).
6. Development, Product, PM, and Training teams can comment or make updates as necessary. 
7. Doc team drafts an announcement for the partner and Open edX portals for review by another doc team member. The portal announcement is an abridged version of the release notes.
8. Doc team merges the pull request. If changes come in after this point, the team will make every effort to get the change published as soon as possible. 
9. Doc team publishes the release notes and republishes all documents affected by the release by creating new builds of documentation projects on readthedocs.
10. Doc team updates the release date review and revise the release notes, making sure that the included features and changes are described accurately and positioned appropriately.
11. Make revisions as necessary. Before merging the PR, squash commits.
12. Merge the pull request.
13. Build the release notes project on RTD.
14. Update the release date on the docs.edx.org page and publishes the portal announcement on the partner and Open edX portals. The portals automatically send the announcement to subscribers as an email message.

...

1. .