Re: Maybe help ease the pain of 2.20 release notes?

["Gervais Mulongoy" <gervais mulongoy gmail com>]

What areas should the release notes cover then? Below are a few suggestions:

• Universal Access (languages, TTS, STT, accessibility)
  
• Communication (email, IM, VOIP, video conferencing)
• Office (abiword, openoffice)
• Productivity (image viewing, document viewing, note-taking)
• Playback (music, video)
• Customization (composite eye-candy, themes)
• Management (peripherals, storage, power, networking)

If we use this notion of beats, then we should clearly define the
requirements for each beat, as well as the mandate for each release.
Quim and Dave you both seem to have strong stakes in this, so what do
you recommend?

On 3/15/07, Joachim <joachim gnome googlemail com> wrote:

On 3/15/07, Dave Neary <dneary free fr > wrote:

Designing release notes: the Fedora experience:
http://www.redhat.com/magazine/019may06/features/documentation_design/

> In journalism, a beat is an area of coverage that one or a few writers focus on. It might be politics in the local government, football with the local league, sports in general, fashion, food, and so forth. A beat writer has a chance to get to know an area as a specialist, to become a face and name known by the newsmakers being covered in the beat.

That's pretty much what I've been suggesting for the Documentation team -- each writer would cover one or more application manuals, get to know those apps' developers, be part of those teams, etc.
I'd really like to drive this forward, and perhaps both can work together?
Problem is, lack of writers!

The other problem with the release notes is that we do them backwards.
We should be thinking about the 2.20 release notes NOW, not in 6 months. We should be planning what the focus of the next release is, instead of just listing what's come over the wall at the end of the cycle.

--
marketing-list mailing list
marketing-list gnome org
http://mail.gnome.org/mailman/listinfo/marketing-list