One Summary outline draft

Wed Jan 30 07:40:55 UTC 2008

Jeff Spaleta wrote:
> On Jan 29, 2008 6:12 PM, Vladimir Kosovac <vnk at mkc.co.nz> wrote:
> 
> 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.  

I was indeed thinking of a RelNotes SIG at the 'set of packages' level - 
that set being "accepted features" for a new release. There is obviously 
a core group of developers/packagers built-in, so we ask for volunteers 
from docs/arts/bugtriagers/...(?) groups.

 From time to time, some large packages (or package groups) will be 
introduced as accepted features, such as the case with KDE4 now. These 
big ones warrant separate SIGs due to their size/complexity and the fact 
that they are flagged for inclusion in release notes for every release, 
regardless of them being either major or minor update. These large SIGs 
also advertise for volunteers. The 'docs/release notes' part of such a 
large SIG is then co-ordinated with RelNotes SIG and everybody is happy.

Other large SIGs do the same, regardless of whether their set of 
packages is relevant for the current version of release notes - they do 
it for the sake of having decent documentation. Come the release time, 
it's trivial to build rel. notes from such docs and people are already 
trained on how to produce the notes in acceptable format.

Now, I'm looking at all this mostly from the 'textmonkey' perspective 
but there's no reason why similar couldn't be applied for others, 
including the appropriate training.

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.
> 
I agree but I think that we can look at the RelNotes SIG as something 
half way between the two. This one might be a good pilot group, working 
in reverse: the core group of writers/designers/bugzappers... etc, is 
there to accept the new code-monkeys group and new contributors, too. 
Maintainers of new features don't have to worry about recruiting 
volunteers from other groups at that point - more time to code and test.

New volunteers get to start on smaller papers/sets of documents. 
Everybody works on new stuff all the time and nobody gets bored, 
including bug triagers, who don't get bored, anyway. Plus nothing stops 
people (that's again me from a docs project point of view) to start 
writing 'real docs' about 'accepted features' or for other, established 
SIGs at the same time.

> 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.

Again, 'accepted features' package set + Mr Stanley's input seems ideal 
for this. In general, new features appear in Fedora from a better 
starting point, with more bugs ironed out and likely better docs to 
start with (I'm hoping that notes writers will eventually get exited 
about some new stuff and expand on release notes later on).

> 
> 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.
> 

The one show stopper I can see with this is a chronic short-handedness. 
   I guess it is up to SIGs to lure people in but if RelNotes appears to 
be good entry point and a way to get more new contributors properly 
trained and made re-assignable (MyFedora looks promising as an 
ad-service on that end), we could have a source to fill the needs of 
individual packages and less visible SIGs, who will always have this 
problem.

Vladimir

> -jef
> 
> _______________________________________________
> fedora-advisory-board mailing list
> fedora-advisory-board at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-advisory-board
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20080130/d24a3c0e/attachment.sig>