[cab-discuss] Considering Membership

[Simon Phipps]

On May 3, 2006, at 01:00, Stephen Hahn wrote:

> * Ben Rockwood <benr at cuddletech.com> [2006-05-02 15:14]:
>> Sorry for lagging on the "5 Membership Questions" list.  I'm not  
>> so sure
>> its as simple as just a shot list which is why I've struggled with  
>> it.
>> But here are some ideas based on research I was doing last night.
>
>   Thanks for writing this up, Ben.

Likewise. We discussed this on the CAB before but it never got  
recorded; I'm pleased to see something written that we can work on.

>
>> - I'm curious if we should write the constitution with the  
>> possibility
>> of it one day being the bylaw's by which to incorporate a Foundation.
>> I'm personally opposed to doing so, but being prepared might not be a
>> bad idea.

I'd say not. The needs of a Foundation would be met with nylaws at  
the time it was created and as Roy suggested might well prove  
orthogonal to the rules that create an effective community of  
communities.

>> - Of the models I've looked at, the one that I like the best is
>> OpenOffice.  By this model anyone that wants to be a voting member  
>> can
>> do so by simply registering and becoming an "Observer" of a given  
>> project.

I'm afraid I regard that as too low a threshold over at OO.o and it's  
something I personally believe they will have to change going forward.

>>
>> If we use the OO.org model[1], my adapted hierarchy looks like this:
>>
>> - User/Anyone (This level is currently in the Governance Draft but I
>> think is obvious and doesn't need to be explicitly noted)
>> - Community Member: A registered user who is the observer of one  
>> or more
>> OpenSolaris Communities.  Observers may cast one vote per in each
>> community for local issues, but only a single vote in OpenSolaris  
>> wide
>> matters (eg: OGB Election)
>> - Contributer/Developer: A contributing acknowledged contributer to a
>> given OpenSolaris Community, by whatever means is considered  
>> acceptable
>> within that community (ie: evangelism for OS-Marketing, writting/ 
>> editing
>> for OS-Docs, code-contribution for code communities, etc)
>> Contributers/Devs are to be named by the leaders of that community by
>> way of a documented vote, to be reported to the OGB.  The OGB  
>> reserves
>> the right to intervene in such decisions, but is encouraged to  
>> stay out
>> of local politics. [All members at this level must submit a SCA.]
>
>   So I think that I have a preference for the model the threshold is
>   contribution, and where a community identifies its contributors:   
> that
>   would mean, for example, that the Marketing community would state  
> that
>   folks who helped out by giving booth time or writing slogans or
>   designing banners would be contributors.
>
>   I guess I am stuck on how observation makes one sufficiently  
> involved
>   to be able to participate in a recorded vote:  the observers are
>   unlikely to be impacted by the consequences of any particular
>   decision, whereas the contributors most likely will be.

I agree with this. I have always promoted the idea that those who  
contribute, vote (but see below, "scope"). Once "scope" is allowed  
for I'd suggest that voting at the various levels be reserved to  
those recognised as contributors.

>
>> - Core Contrib/Developer (aka: leaders): Core Developers are also
>> leaders of their given OpenSolaris Community.  These persons are  
>> given
>> the right to decide matters and call votes within their community, to
>> oversee and manage various sub-projects, etc.
>
>   I like identifying "Community Leader" with this role.
>
>> - Project Lead:  Each community must elect one Core Dev to act as the
>> Project Lead.  This single person is responsible for that community
>> and ensuring that responsibilities are met.  This person is, by
>> default, to act as a liaison to both the OGB and any other comities
>> (eg; arc) but has the ability to delegate such duties to some other
>> Core Dev within that given community if they choose, never the less
>> the project lead is still responsible for that persons actions.
>
>   This level of specification might be too precise to balance  
> workloads.
>   I wonder if instead the communities should be expected to provide
>   liaisons to the committees the constitution identifies, but not to
>   specify how they select those liaisons.  (For one thing, it is not
>   clear that the liaisons should have to be leads...)
>
>> - Governing Board Member: Person who is elected by the whole  
>> community
>> to represent the project and its interests as a whole.  To be  
>> elegable
>> for election the person needs only to be a community member.  Being a
>> member of the OGB does NOT entitle you to the rights of any higher
>> membership level than you have on your own merits (ie: OGB members  
>> don't
>> automatically get the right to dictate within a community nor commit
>> rights).
>
>   Sounds good.

Not sure I agree. I suspect the OGB should be elected by recognised  
contributors from nominations made from the whole membership  
(nominated and seconded by a suitable number of general members).  
Further discussion below.

>
>> So, the loose hiararchy is:
>>
>>            O G B
>>         /    /   \   \
>>      Community Leads
>>     /  /   /  |  |   \   \
>> Core Developers / "Leaders"
>>  /     |   |   |   |   |   |  \
>> Contributers/Developers & "Observers" / Members  <-- Voting Persons
>> |  || | | ||   |  ||   ||| || |
>> Users and anyone who wants to be kool.
>>
>> What do you think?  Its not 5 questions, but I'm thinking a lot about
>> the problem.  I need to re-write this list and formalize it, but its
>> sufficient at this point for discussion.
>>
>> [1]: The model is actually hobbled together based on Roy's Draft
>> governance, the Apache Bylaws, OO.org Constitution, and a  
>> composite from
>> the governance/bylaws of KDE, GNOME, and MediaWiki.  I believe  
>> this is,
>> imho, "the best of all worlds" as it applies to our future  
>> constitution.
>
>   Again, thanks for kicking this off.  I think that a large  
> question is
>   the degree of involvement that leads to being able to partcipate  
> in a
>   vote...

Another issue to consider is the scope of voting ability. For  
example, someone who is contributing to the marketing community to  
its satisfaction should certainly be able to vote about decisions,  
leadership representation and whatever else is being decided in that  
community. However, they almost certainly should not have a vote in  
decisions in the Documentation community unless they have also  
contributed over there.

It's also arguable that the "electoral college" for community-wide  
voting should not necessarily include everyone with a vote in every  
community. Decisions at the meta-community level almost certainly  
require a perspective on OpenSolaris that stretches beyond the scope  
of any single community. It's therefore arguable that voting on  
issues at the OGB/Community Lead level should only involve Core  
Developers/Leaders and above. Certainly Apache reserves voting at  
this level to those elected to "Member" status, which is a peer  
college level analogous to Ben's Core Developer/Leader level.

S.