Open Stack

You guys hit on some of the unanswered questions that we have as well. I think on some of these things, we want to let the discussion progress a little and see what people think of various options before filling in the gaps. Some other comments inline.

On Feb 12, 2012, at 3:07 PM, Jay Pipes wrote:
> On 02/12/2012 03:12 PM, Thierry Carrez wrote:
>> 
>> * How do you limit the number of strategic members to 6-8 ? I agree with
>> you that you need to have a limit to have a functional board...
>> Solutions include only allowing "founding members" (first come first
>> serve, a bit unfair and exclusive to late comers), or have the
>> "strategic members" as a whole vote for their 6-8 directors seats (more
>> fair, but meaning each member would not be entitled to a seat).
> 
> Agreed with the above concerns, and I'd also like to point out that I believe the following two points should be covered in the structure documents at some point:

These are good questions that I don't know if we have good answers for yet. Thierry identified a couple of possibilities; there are probably more. I definitely want to put some more thought and hear more input on this issue.

> * How do members of the board of directors get removed from the board, if such removal is warranted?

There's prior art for handling removal or discipline of members. These kinds of details would most likely be hashed out in the Bylaws. Alice King has been helping with the legal aspect of it and had some thoughts around removal of Board members, but I don't know if she had settled on specifics yet. 

> * Is individual and strategic membership granted for a certain amount of time? For example, if I contributed to a project early on, because an individual member, and then did not contribute or participate in the community for 2 years, do I still get the same voting power? Same goes for strategic/corporate members. If they cease being active in the projects, do they lose membership?

Strategic membership would require a multi-year commitment from the company who wants to be a Strategic Member. For Individual Members, I'm open to hearing options around requirements or limitations on terms.

>> * Individual members should contribute to the OpenStack project in a
>> meaningful way. For code contributions, that's easy to measure: if you
>> commit code, you can be a member. For other contributions that's
>> harder... I propose that you have a individual membership committee that
>> is tasked with reviewing proposed non-developer members.
> 
> While I appreciate Thierry's point here, I'm not sure an individual membership committee would be seen as anything more than a "clique of developers who gate the community"...

A Membership Committee is a possibility we had already tossed around and which markmc laid out in his proposal. I think it's possible to make it work as long as it functions openly and tends towards inclusion vs. exclusion. On the other hand, I also think we haven't seen a negative impact from the open Launchpad group that has served a similar function.

>> * You use individual members for two elections: board election and
>> technical committee. While I agree that non-technical roles (think
>> marketing, advocacy, legal guidance... but also potentially users)
>> should definitely have a say in the board election, I'm not convinced
>> non-technical individual members should elect the technical committee
>> representatives. If you agree, that means you would have two categories
>> of individual members (technical and non-technical) with slightly
>> different rights. This probably means two separate membership committees
>> (one rarely used for technical non-developer types, and one for
>> non-technical members). If that's too complex, you can avoid extra
>> complexity by using lazy consensus on the ML for the technical
>> (non-developer) members, instead of a separate committee.
> 
> I agree with the above point about only technical folks voting for members of the technical committee.

This one is tough for me because I don't know how to objectively draw the lines between technical, quasi-technical, and non-technical. For instance, there are technical users who may not contribute code but who potentially should have a voice. My first instinct would again be to favor inclusion over exclusion as I haven't seen a huge problem in the current base of users. I think the biggest thing to watch for is "stuffing the ballot box," and I think there are other ways to catch that and guard against it.

Thanks for the comments,

Jonathan.