One Summary outline draft

[Jeff Spaleta]

On Jan 29, 2008 6:12 PM, Vladimir Kosovac <vnk at mkc.co.nz> wrote:
> There seems to be a good cross-section of FP subprojects involved in a
> production of release notes and summaries, all of which could benefit
> from the better co-ordination of the effort:
>
>   * Maintainers/Packagers
>   * Testers/Bug Triagers
>   * Beats and Docs writers / Translators
>   * Artists
>   * Marketing
>
> Being inventive (not!), I thought something like RelNotes SIG, acting as
> an umbrella for all of the * above might achieve this better co-ordination.
>
> Immediate and a very visible benefit would be accurate Release Notes
> produced on time throughout the dev-cycle (and Rahul and others relieved
> of beyond-human effort during the last 48 hrs before the mirrors open
> every 6-7 months).
>
> The other, less visible benefit, is the possibility (there was a bit of
> a talk about it within docs team, too) to use this road to attract new
> contributors and get them started on smaller, less intimidating pieces
> of the project.
>
> Is there anything fundamentally wrong with this?


There's nothing specifically wrong with this... In fact Release Note
Beat writers are essentially that coordinating SIG.  The issue is, we
need to generate beat writers in different areas. And the only way I
can see to do that effectively is to organize a SIG for each "area"
and have a documentor role in each SIG team.  But how do we inject
those people into the work flow of package related SIGs?  My rainbow
diagram tries to explain that.

We need to organize the concept of the SIG as a team of people who are
responsible for a set of packages.  Not the art, or documentation or
triage or whatever.... SIGs need to equal responsibility for ALL the
tasks associated with a chunk of the package space that needs care in
feeding.  We group those tasks into roles and encourage each SIG to
have someone commit to a role.

We organize those roles into support groups that are made up of people
filling that role in each sig, as well as floating experts to provide
high skill support for everyone in that role.
We dont call them SIGs, we call them something else.. in my diagram I
called then Interface Specialists. But the idea is these are the
umbrella groups that bring people from different corners of the
package space together to deal with common tasks.

We need to build a template and get a few of the more higher profile
SIGs (KDE im looking at you!!!!) to try a role based approach.  We
need to build out baseline training for these roles...for example
triage. If the new triage initiative can build out a baseline training
program for new contributors who want to help by being triagers...and
we can have individual SIGs carve out a role for a triager in their
group.. then we can dedicate a week where we train up a group of
triagers, and then hand them off to SIGs looking for triagers..in a
way where we aren't burdening the other SIG members into trying to
train up the new guys in an area that none of the other SIG members
are experts in.

We can do it with triage....and we can do it with documentation
people.  We dont ask the package maintainers or the developers to
train up a decent triager or documenter. We do that project wide, and
then the SIGs take them in and incorporate them into how that SIG does
its day to day business.

-jef