Jim Grisanzio wrote:
> 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.
As I said, the various Cs/Ps/UGs whatever (the operation bits of the
community) would propose/promote people to voting status ('Member'?).
The purpose of the Electorate collective is purely to identify all the
people who have a vote, no matter how they got the vote, and to decouple
someone's voting status with their membership of whatever Cs/Ps/UGs they
happen to be involved with at any point in time. Think of it as a split
between Legislature and Executive ;-)
>> 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. :)
As I said, I don't much care exactly how we break things down
internally, so I'll just limit myself to pointing out that most
organisations founder if they don't have a clearly defined person or
persons in charge.
>> 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.
As I said I think it is more important to use names that make sense in
the context in which they are being used, and far less important to
arbitrarily use the same name for different things in the belief that it
is somehow simpler.
And yes we do need Participant and Committer. I participate in quite a
few Open Source communities (on email lists, submit patches etc), but I
have commit rights in far fewer of them. It's an important distinction,
no matter what labels we use.
> 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.
Sure, some are going to be reused, some (such as Committer) will be
specific to a particular type of group.
--
Alan Burlison
--
