Alan Burlison wrote: > Jim Grisanzio wrote: > > >> We can also trim the levels of membership to three: (1) Participant, (2) >> Contributor, (3) Member. >> >> * Participant: You have registered on the site. >> * Contributor: You contribute to a Group and have been recognized by >> that Group. >> * Member: You have earned the right to vote in community-wide elections. >> > > I thought the suggestion was to keep the voting rights completely > divorced from the operational side of the community, so we'd have > Communities (C), Projects (P) and User Groups (UG). These would be > 'operational' groupings of people. While they would be able to propose > the granting of voting rights to people, membership of one of these > operational groupings would not of itself confer voting rights >
Yah, the new Membership Committee will be responsible for specifying how to qualify to be a Member and it will approve each Group's outline of how its members (small m) become Members (big M) if they so choose. I thought that's what we discussed today but I could be wrong. > We'd then have a fourth collection of people which is completely > orthogonal to the other three and that was solely concerned with > constitutional matters - for the sake of discussion let's call it > Electorate. > > There are a couple of issues that I can see with your proposed > membership grades. > > In your suggestion, 'Participant' is just someone who has registered. A > large proportion of such people don't participate in any meaningful way, > and I really don't think we need a collective name for them - if we do > it should probably be 'Registrant', as that is a more accurate > description. > Agree. Just cut them. :) In fact, Glynn didn't have Participants in one of his drafts too. The serve no purpose in governance until they start contributing. > The problem with the definition you gave for 'Member' is that it > confuses someone's constitutional role with their roles in the other OSO > activities they are associated with. For example let's assume I'm a > Participant in UG1 and a Contributor in P2, then I get granted a vote. > Now would I become a Member in both UG1 and P2? No, sorry for the confusion. There's no such thing as Member (big M) in a Group. Member is simply to vote in OGB elections and other community elections if we every have them. You'd still be a Contributor in your project but you'd be a Member of the OpenSolaris Community too. > That doesn't make any > sense - I may still be just turning up at the occasional UG1 meeting, > why should I become more 'important' in UG1 and P1 just because I now > have a vote? In the case of P1, because I'm now a Member, does that > mean I also get commit rights? > > We *could* get around this by qualifying someone's Member status with > the collective that granted them that status, but I expect people's > interests and contribution levels will change over time. That shouldn't > affect their voting rights, but it would get very messy trying to make > sure that they were always associated with at least one collective as a > Member so that they always kept their vote. > To me the only people who can support someone's right to be a Member is his/her peers, the people he/she works with. I don't want an uninvolved third collective -- the Membership Committee -- deciding that. They would have no basis to make that decision. However, I'm fine with the Membership Committee writing and enforcing a community-wide standard for what it means to be a Member that all the Groups have to meet that standard. This way we don't have one Group arbitrarily adding Members using low standards. > A simpler option, as discussed in the OGB meeting I attended, is to > split off the voting role from everything else, so we'd end up with > something like the list below. Note I'm not really bothered what we > call the roles within the last three collectives, other than to note > that there is no practical or logical reason why they should all be the > same. Rather than trying to oversimplify, we should just pick the roles > that each collective needs and then try to give them the most > descriptive names we can think of. > > Electorate - people who vote > OGB Chair > OGB Member > Member > ok > Community - people interested in a common area > Participant > Contributor > Leader > OGB Facilitator > ok, but dump participant. And why do we need Leader? Can't it be just understood that one of the Contributors or many of them are leading their Community? To me the Leaders of each Group should be obvious. They are the most active. Why quantify them as a specific role? Intentionally bing minimalist here. :) > Project - people developing code > Participant > Committer > Leader > OGB Facilitator > ok, but dump participant. Do we need "committer" here? In others words, can this person be a Contributor -- same level as Contributor in Communities but who has /different/ access privileges in the Project (access to the gate, etc)? Also same question re Leader. I'm just trying to reduce the number of names to the absolute minimum. > User Group - people drinking beer > And sake :) > Participant > Coordinator > OGB Facilitator > > I'm fully in favour of simplification but I think that trying to > oversimplify just creates confusion as you can end up using a single > term for things which are not in fact the same, e.g. 'Member' to > describe both a constitutional role and a community activity role. > In my example, Member only describes a voting role (should have explained that better). It has no operational significance, per say, but it surely derives its substance from operations (I've put back so much code I've earned the right to vote, I've contributed this over that time, etc). However, in all the /other/ examples I'm using single terms for multiple roles because I think it's obvious and I'm fine with Contributor meaning one thing in a UG and something else in a Project because there are so few roles and groups. > Better to be clear and unambiguous rather than to be overly concise ;-) > I'm liking our current system more and more. :) Jim -- http://blogs.sun.com/jimgris/
