redefining SIGs (old and new)

Jeff Spaleta jspaleta at gmail.com
Thu Jan 31 18:23:59 UTC 2008


On Jan 31, 2008 8:30 AM,  <jspaleta at gmail.com> 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




More information about the fedora-advisory-board mailing list