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.
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.
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? 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.
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
Community - people interested in a common area
Participant
Contributor
Leader
OGB Facilitator
Project - people developing code
Participant
Committer
Leader
OGB Facilitator
User Group - people drinking beer
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.
Better to be clear and unambiguous rather than to be overly concise ;-)
--
Alan Burlison
--
