Writing GNOME release notes

Note: This refers to 3.2 (to be released by the end of September 2011) and is still subject to change.

  • Send an announcement email asking people to provide information (potential recipients: desktop-devel-list, marketing-list, gnome-accessibility-list, gnome-doc-list, gnome-i18n, release-team)

  • Ask specific questions on the marketing-list if needed (for 3.2 this was needed for Featured Apps story)

  • After sending the announcement email, give developers a few days to edit the wikipage.
  • Branch release-notes in GNOME Git for gnome-3-x (see Branching)

  • Commit a skeleton (commits: 1, 2, 3)

  • Ask FredericPeters to set up http://library.gnome.org/misc/release-notes/3.x/ and password protection, once the skeleton has been committed. While working on the release notes this will make it easier to see recent changes and its design.

  • Take a look at a potentially already existing Release Notes wikipage for this release and clean it up if needed

  • Also use potentially existing private collections (AndreKlapper had his notes collected over 3.1 here)

  • Go through what the developers wrote in their NEWS files. This is available per GNOME release at http://ftp.gnome.org/pub/GNOME/core/ and http://ftp.gnome.org/pub/GNOME/apps/

  • Also go through the Commit Digests of the last months to find more interesting stuff to mention

  • Have a release team meeting and update the status of planned features for the release (Features planned for 3.1, meeting minutes for 3.1)

  • rnusers.xml:
    • Documentation: Ask Docs Team/ShaunMcCance for any new user docs and for docs converted from Docbook to Mallard format
  • rna11y.xml: Ask a11y team about improvements, e.g. via mailing list or by joining a meeting.

  • rndevelopers.xml:
  • rni18n.xml:
    • Go to Damned Lies, take alphabetic list of all languages with more than 70% (safe, as you can still comment languages later that didn't reach 80%), and add them in the format of <listitem><para>LanguageName</para></listitem>.

    • Close to the release date add a section to highlight those language teams with big improvements in either UI or docs coverage. Use the UI version comparison and Doc version comparison pages for this.

  • rnlookingforward.xml: Use Roadmaps (if up-to-date) and Features pages to provide an outlook

  • Bonus points for quickly checking the Desktop help if new or changed behavior is documented already. If it is not, file a bug report.

Text in good shape but needs some more tweaking

Text basically finished

Close to the release

Afterwards

Next version

In this specific case it refers to version 3.4

  • Use Mallard instead of Docbook format

AndreKlapper/WritingReleaseNotes (last edited 2013-02-23 18:29:06 by AndreKlapper)