On Jan 31, 2008 8:30 AM, <jspaleta@xxxxxxxxx> wrote: > right now the only team structure we have is a SIG, so i've reused the > name. I frankly don't care what its called. And with that being said... perhaps I've abused the SIG term in my strawman too severely. I should be punished. Perhaps my strawman should lay it out like this. Leave the SIG definition as is, and (re)organize a role based Packaging SIG. In such a strawman, groups focusing on packaging such as the Astronomy, Games, and KDE SIGs would be reformulated under the new role based thing (if they wanted to try out my idea). I'm at a loss as to what to call the reformulated groups..confederacy of allied packagers (CAPs)? They would define what part of the packagespace they take stewardship over (overlap is fine), and define roles internally for all tasking related to that space. In parallel other existing SIGs like Documentation would choose to prep training and build policy meant to be used to support a role, in each area of the packagespace. So in this strawman, let's say the current KDE SIG decided to play ball with my idea. They would reformulate as a CAP under the Packaging SIG, and would identify a set of task based roles on their team, among them a documenter role. Documentation SIG, would find a way to create training aimed at a group of new "documenters" to help them get started doing documentation tasks for the CAP they are assigned to. Training on things like release note beat writing, how to work with the doctools, maybe its information on how to identify and track "feature" hotness. Documentation things that the package maintainers and developers who drive KDE packages forward aren't going to be experts at. I then lead a recruitment drive to get interested people into a documenter training session. At the end of that training period (however its laid out), some of the people will wander away, and some of them will take an assignment. Once trained the new documenters are assigned to a CAP and are integrated into that groups work. We assess how people feel about the role they are in each release cycle. And perhaps make a large recruitment push for a different role each release cycle. -jef _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
