Hey, On 15/07/2008, at 10:09 PM, Jim Grisanzio wrote: > I updated this again to reflect the removal of the Facilitator role, > and I'm also recommending the removal of the Emeritus role. This is > just an outline of an idea to give the infrastructure dev team the > minimum information (roles, structure, relationships) they've been > requesting for four weeks so they can continue working to build the > applications to upgrade the site and support the gate migration.
[snip] As I said on Jim's blog, I like this a lot more than some of the others. As I see it, we have a couple of formal roles within our community (which I've grouped accordingly) - - Contributor - Leader - Member - OGB A Contributor is *everyone* in the context of opensolaris.org. No one would be involved or reading lists if they weren't interested, and contributing to the success of the community. Leader are those people with a stronger position in the community. Leaders in the project sense may be ones making decisions and deciding the direction of a project. They have respect from their peers that has elevated them into a position of responsibility. Only leaders can elevate other people to that position, to share in the responsibilities. Both of these roles have a set of attributes - - can edit web pages - can administer mailing lists - can commit code Members are those who want to be associated with the OpenSolaris community, and care about its long term success from a social point of view. Membership is voluntary, and based on an individual's contribution to the community. Members are approved by a small membership committee (the tick boxers), but recommended (reference) by existing Members. They can vote in community wide elections, but don't necessarily have a say in many of the operational parts of the community (ie. Projects). Members elect OGB board representatives, who are given the responsibility for the long term success of the project, ensuring that it has all the resources it needs to be that success. The rest of Jim's proposal starts to identify the high level groups. I also believe this comes close to my thoughts - - Projects - Communities/SIGs - User Groups Very, very close. I've added Release Team and ARC as stand outs, because I believe those are fundamentally important in getting our software out into the hands of our users. Glynn
