Glynn Foster wrote: > 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
I think there's probably a need for a step prior to Contributor - someone is interested but who you aren't ready to give write access to just yet. Otherwise we have no way of distinguishing between people who are active on lists etc and people we trust to make changes to code. To me it would seem to be risky to just give commit rights to everyone who said they wanted them. I don't know of any other open source community that gives commit rights to anyone who just turns up & asks. > 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. I think this is the key - separating the constitutional stuff from the day-to-day stuff. > 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. We can always add new types of collectives as and when we need them. I think it would be easier and quicker if we figured out how to rejig the things we already know the shape of (CGs, UGs & Projects) and then add the new stuff as a separate step. -- Alan Burlison --
