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 _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
