Jeff Spaleta wrote:
On Jan 29, 2008 6:12 PM, Vladimir Kosovac <vnk@xxxxxxxxx> 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 areresponsible 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
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.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.
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@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
