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




Hi,

I'd like to see us address a few areas (in particular a specific type of
user/use case) across the board.

Perhaps three or four.

We for example, we might decide to do a profile on:

 - Blind user(get a reference from Aaron Leventhal or Peter Korn)
 - Sysadmin for a big deployment (try Dave from Largo)
 - GNOME application developer (we should have no trouble finding lots
of these)

Turn the tables a bit - instead of talking about functionality, try to
get developers (and us) thinking of users first, and functionality second.

Cheers,
Dave.

Gervais Mulongoy wrote:
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
<mailto:joachim gnome googlemail com>> wrote:



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


        Designing release notes: the Fedora experience:
        http://www.redhat.com/magazine/019may06/features/documentation_design/
        <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 <mailto:marketing-list gnome org>
    http://mail.gnome.org/mailman/listinfo/marketing-list




-- 
Dave Neary
GNOME Foundation member
bolsh gnome org



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]