...

...

...

...

For features released from other repos, the product managers and doc team members work together to decide on what will be included in the weekly release notes.

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. 

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

Process

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. 

1. Doc team identifies release notes content by reviewing the LMS/Studio Release Pages wiki page and asking the product team for items.
2. Doc team creates a draft of release notes. The team also adds the file on the index.rst page.
3. When the draft is as complete as possible, create a pull request and tag Development, Product, and PM team members, asking for review and collaborationReview 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.
4. Create a branch in the edx-documentation repo, e.g. "RN_WeekEndFeb3" for easy identification.
5. 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.
6. Commit your changes to your branch.
7. 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).
8. Development, Product, PM, and Training teams can comment or make updates as necessary. 
9. 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.
10. 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. 
11. Doc team publishes the release notes and republishes all documents affected by the release by creating new builds of documentation projects on readthedocs.
12. 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.
13. Make revisions as necessary. Before merging the PR, squash commits.
14. Merge the pull request.
15. Build the release notes project on RTD.
16. 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. .