Let's re-start a discussion about role-based SIGs

[Jeff Spaleta]

Okay now that F9 is out the door, and before I've voted out of office,
its time to take another stab at a discussion about building and
strengthening the abilities of role based SIGs inside the Fedora
projects moving forward.

I've come to picture the work the Fedora project needs to do as
structured in terms of two types of communities (I have to credit Greg
for some of the refinement on the image from the last round of
discussion about this a few months back). One such type of community I
would name "Subprojects". A subproject would be a group of peers who
are doing roughly the same things, and could be considered a guild for
a particular type of skilled labor. The other type of community I
would name "Special Interest Groups" (SIGS), and each SIG would
encompass all roles from users to developers that are needed to
sustain the growth of software usage and development for a particular
purpose.

Common tasks or experience define the membership of a Subproject
Common interests but different tasks and experience define the
membership of a role-based SIG.

SIG roles would map directly to subprojects. The idea being that
people from different SIGS who are doing the same sort of tasks can
establish best practices through discussion in the subprojects
associated with that role. For example we'd have a packaging
subproject, and each SIG should have members filling the package
maintainer role who were also participating in the packaging
subproject to learn and refine best practices. Same goes for
documentors, triagers and so-on.

But its not a one-to-one mapping. There would be needed Subprojects
which don't necessarily map to a common SIG role, but they would still
exist to get specific work done or to establish a peer group of
experts. I would hold up our infrastructure,translation and marketing
teams as an example of this type of Subproject construct, a Resource
Subproject.

They key idea is that for the role-based SIGs idea I am putting
forward, we turn the SIG concept deliberately into a construct that
encourages direct user participation, so that SIGs can more easily
recruit for their own expanding workforce needs their own by
connecting with users who are already interested in and using the
software in the scope of the SIG. Experienced, veteren SIG members
take on the role of mentoring and sponsoring new recruits.. and the
SIG becomes a self-sustaining community with the goal of growing the
capabilities of open software for a particular area of interest.

It is my very fervent belief that we need to build a recruitment and
retention program inside of the Fedora Project that encourages
enthusiastic users to become active contributors, and I think the
role-based SIG construct has the best potential of doing that.. we
just have to shake-up and tighten-up what we mean we we talk about a
SIG. And that is exactly what my role-based approach to SIG building
is meant to do.

Okay so I think that was close enough to a thousand words. Here's the
updated cartoon diagram of what I mean when I'm talking about
role-based SIGs:
http://jspaleta.fedorapeople.org/role-based-sigs/sig-teams.png


How would this impact our current teams? Some current SIGs would
simply be rebranded as Subprojects.
Some would decide they really are both a SIG and a subproject (Art for
example could easily be both)
For the SIGs that remain, they start identifying roles and 'we' find a
way to recruit poeple to fill those roles, and we start building ways
to connect users directly with SIGs.

But people have to want to run SIGs this way. They have to want to
turn SIGs into this sort of meeting places that encourages user
participation. Once people agree this is the way to structure things,
then we can start to re-enforce that structure.

-jef