incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: [DISCUSS] Apache CloudStack Project Bylaws
Date Thu, 13 Dec 2012 20:55:09 GMT

On Dec 13, 2012, at 5:19 PM, Chip Childers <chip.childers@sungard.com> wrote:

> On Thu, Dec 13, 2012 at 9:58 AM, Sebastien Goasguen <runseb@gmail.com> wrote:
>> Chip, some thoughts inline.
>> 
>> Don't mind the pickiness.
> 
> Thanks for the review.  Any no, I don't mind the pickiness!
> 
>> On Dec 13, 2012, at 3:30 AM, Chip Childers <chip.childers@sungard.com> wrote:
>> 
>>> Hi all,
>>> 
>>> I'd like to start a conversation about our project bylaws.  This is
>>> something that an Apache project doesn't absolutely require, but I
>>> believe that some of the larger TLP's have found it to be valuable.
>>> More specifically, I would like to see us discuss and agree on the
>>> contents of the bylaws prior to graduating (hence why I'm bringing it
>>> up now).  If others don't agree that this is the time or place, or
>>> that they are not needed, then please say so!
>>> 
>>> For the draft below, I started with the Hadoop project's version
>>> (found here: http://hadoop.apache.org/bylaws.html ), and then took a
>>> stab at editing the contents a bit to match some of the conventions
>>> that we have been using as a community already.
>>> 
>>> In the draft, I'm assuming that the CloudStack trademark will be
>>> transfered at or before the time of graduation from the incubator, and
>>> therefore retained the statements about ASF owning the trademark
>>> (which is not yet true AFAIK).
>>> 
>>> I've also retained the references to the PMC, instead of what is
>>> currently the PPMC.  For the purpose of this discussion, consider PMC
>>> to be equal to the PPMC today (with the obvious qualification that we
>>> are under the Incubator PMC today).
>>> 
>>> Section 2.1.4 talks about the PMC being responsible to the board, but
>>> that will only be the case after we graduate.
>>> 
>>> Please take a look, and let's start the process of figuring out what's
>>> good / bad / otherwise about the draft.  All opinions are welcome!
>>> 
>>> -chip
>>> 
>>> 
>>> *****************************************************
>>> Draft Apache CloudStack Project Bylaws
>>> *****************************************************
>>> 
>>> 1. Introduction
>>> 
>>> 1.1. This document defines the bylaws under which the Apache
>>> CloudStack project operates. It defines the roles and responsibilities
>>> of the project, who may vote, how voting works, how conflicts are
>>> resolved, etc.
>>> 
>> I would not use 'etc'. Either list everything it defines or scratch the whole sentence.
>> In previous bylaws I was involved with the less the better to avoid room for interpretation.
>> 
> 
> Agreed, let's drop that sentence.
> 
>> 
>>> 1.2. CloudStack is a project of the Apache Software Foundation. The
>>> foundation holds the trademark on the name "CloudStack" and copyright
>>> on Apache code including the code in the CloudStack codebase. The
>>> foundation FAQ explains the operation and background of the
>>> foundation.
>>> 
>>> 1.3. CloudStack is typical of Apache projects in that it operates
>>> under a set of principles, known collectively as the "Apache Way". If
>>> you are new to Apache development, please refer to the Incubator
>>> project for more information on how Apache projects operate.
>>> 
>> Maybe:
>> CloudStack is an Apache project that operates under a set of principles known collectively
as the "Apache Way".
>> 
>> But that still leaves room for interpretation: What are those principles ?
> 
> Well, I think that's honestly the nature of it.  However, the list
> that's on the ASF FAQ page is:
> 
> "Transparancy, consensus, non-affiliation, respect for fellow
> developers, and meritocracy, in no specific order."
> 
> Does that work for everyone?

works for me.

> 
> I also think we should drop the statement about "If you are new to Apache..."
> 
>>> 2. Roles and Responsibilities
>>> 
>>> Apache projects define a set of roles with associated rights and
>>> responsibilities. These roles govern what tasks an individual may
>>> perform within the project. The roles are defined in the following
>>> sections:
>>> 
>>> 2.1. Users
>>> 
>>> The most important participants in the project are people who use our
>>> software. Users contribute to the Apache projects by providing
>>> feedback to developers in the form of bug reports and feature
>>> suggestions. As well, users participate in the Apache community by
>>> helping other users on mailing lists and user support forums.
>> Feature requests instead of feature suggestions ?
> 
> They are synonymous to me.  Why do you think that "request" is better?

I thought that's what JIRA called it. But apparently not. So feature suggestion is fine.

> 
>> Is that all users can do ?
> 
> Are there other items that you suggest adding?
> 
>> What's their responsibilities ?
> 
> IMO, I'm not sure a user has any.

That's my point. I am wondering what's the status of a user in the project. Ultimately this
leads to the question of whether a user (who only submits tickets and help other folks on
the ml can become a committer and ultimately join the PMC) ?
This might be more of a process issue than a bylaw.

If we keep this role in there, maybe we should specify that users can vote and that [VOTE]
threads are sent to the -users list as well.


> 
>>> 2.2. Contributors
>>> 
>>> Contributors are all of the volunteers who are contributing time,
>>> code, documentation, or resources to the CloudStack Project.
>> 
>> Devil's advocate hat on: I am contributing time but no code, docs or resources. Am
I a contributor ?
> 
> Certainly!  Using you as an example, when you go to a meet-up to help
> support the project you are contributing time.
> 
>>> A
>>> Contributor that makes sustained, welcome contributions to the project
>>> may be invited to become a Committer,
>> By who ? ( I know you spell it out later, but you may have to write it here)
> 
> Let's add: "by the PMC."
> 
>>> though the exact timing of such
>>> invitations depends on many factors.
>> 
> 
> That's the issue...  it's entirely based on a PMC member deciding to
> propose the contributor as a committer.  I'd like to leave this one as
> is.

You could add something like: "the invitation will be at the discretion of a supporting PMC
member"

> 
>> 
>>> The form of contribution is not
>>> limited to code.
>> But is it mandatory ?
>> 
> 
> Nope.
> 
> Let's use this sentence instead:  "Contributions are not just code,
> but can be any combination of documentation, testing, user support,
> code, code reviews, bug reporting, community organizing, or project
> marketing."
> 
> Does that work for you?

yes. Point being that a user who does not submit review requests could become a committer
?
I am not sure if there is precedent in other apache projects.

> 
>>> It can also include code review, helping out users on
>>> the mailing lists, documentation, testing, etc.
>> 
>> In the Users roles you said that "users contribute". Are users contributors ? If
yes, how do users and contributors differ ?
> 
> Good point.  Are users actually contributors if they actually
> communicate with the project in any way?  Should we drop the user
> role?

I don't want to drop it, but its role needs to be clear. Especially accessing to the PMC.
Or we put the user role within the contributor role.

> 
>>> 
>>> 2.3. Committers
>>> 
>>> The project's Committers are responsible for the project's technical
>>> management. Committers have access to all project source control
>>> repositories. Committers may cast binding votes on any technical
>>> discussion regarding the project (or any sub-project).
>>> 
>>> 2.3.1. Committer access is by invitation only and must be approved by
>>> a majority consensus
>> 
>> You only define Lazy consensus and Lazy majority later on.
> 
> That should be lazy consensus.
> 
>>> of the active PMC members. A Committer is
>>> considered emeritus by their own declaration or by not contributing in
>>> any form to the project for over six months. An emeritus committer may
>>> request reinstatement of commit access from the PMC. Such
>>> reinstatement is subject to lazy consensus of active PMC members.
>>> 
>>> 2.3.2. All Apache Committers are required to have a signed Individual
>>> Contributor License Agreement (ICLA) on file with the Apache Software
>>> Foundation. There is a Committer FAQ which provides more details on
>>> the requirements for Committers at Apache.
>> Is there such as thing as Committer bylaws ? If yes I would say "Committers abide
to the Apache bylaws" instead of talking about FAQ.
> 
> I don't believe there is.
> 
>> 
>>> 
>>> 2.3.3. A Committer who makes a sustained contribution to the project
>>> may be invited to become a member of the PMC. The form of contribution
>>> is not limited to code.
>> 
>> But is code mandatory ?
> 
> No.
> 
>> 
>>> It can also include code review, helping out
>>> users on the mailing lists, documentation, testing, etc.
>> 
>> no etc.
> 
> Since we already discuss this in the roles section, I actually think
> we should just remove it from here.
> 
>> 
>>> 
>>> 2.4. Project Management Committee
>>> 
>>> The Project Management Committee (PMC) for Apache CloudStack is
>>> responsible to the board and the ASF for the management and oversight
>>> of the Apache CloudStack codebase. The responsibilities of the PMC
>>> include:
>>> 
>>> - Deciding what is distributed as products of the Apache CloudStack
>>> project. In particular all releases must be approved by the PMC
>>> - Maintaining the project's shared resources, including the codebase
>>> repository, mailing lists, websites.
>>> - Speaking on behalf of the project.
>> 
>> Devil's advocate: If I am not in the PMC does this mean I cannot speak "on behalf"
?
>> What does this allow a PMC member to say that John Doe could not say ?
>> 
> 
> So this came directly from Hadoop, and I didn't put much thought into
> it.  However, I think we should think of this as a statement about the
> official member > board > PMC delegation of responsibilities.  The
> distinction is that anyone can speak as themselves, noting that they
> are part of the CloudStack community.  I think the difference is that
> for a press discussion, PMC members are able to say that they are
> "from the CloudStack project".  At least this is the way that I think
> about it…

ok, I am probably reading to much into this. Makes sense.

> 
>>> - Resolving license disputes regarding products of the project
>>> - Nominating new PMC members and committers
>>> - Maintaining these bylaws and other guidelines of the project
>> 
>> Is the list of responsibilities exhaustive ?
> 
> Actually, I think it is, with one exception.  It actually doesn't call
> out the primary role of a PMC, to foster and support the project's
> community.

Then we should add it.

> 
>>> 
>>> 2.4.1. Membership of the PMC is by invitation only and must be
>>> approved by a lazy consensus of active PMC members. A PMC member is
>>> considered "emeritus" by their own declaration or by not contributing
>>> in any form to the project for over six months. An emeritus member may
>>> request reinstatement to the PMC. Such reinstatement is subject to
>>> lazy consensus of the active PMC members.
>>> 
>>> 2.4.2. The chair of the PMC is appointed by the ASF board. The chair
>>> is an office holder of the Apache Software Foundation (Vice President,
>>> Apache CloudStack) and has primary responsibility to the board for the
>>> management of the projects within the scope of the CloudStack PMC. The
>>> chair reports to the board quarterly on developments within the
>>> CloudStack project.
>>> 
>>> 2.4.3. The chair of the PMC is rotated annually. When the chair is
>>> rotated or if the current chair of the PMC resigns, the PMC votes to
>>> recommend a new chair using Single Transferable Vote (STV) voting. See
>>> http://wiki.apache.org/general/BoardVoting for specifics. The decision
>>> must be ratified by the Apache board.
>>> 
>>> 3. Decision Making
>>> 
>>> Within the CloudStack project, different types of decisions require
>>> different forms of approval.
>> 
>> A bit vague.
>> 
> 
> Drop it?

yes

> 
>>> For example, the previous section
>>> describes several decisions which require "lazy consensus" approval.
>> 
>> no need for example.
> 
> Agreed.
> 
>>> This section defines how voting is performed, the types of approvals,
>>> and which types of decision require which type of approval.
>>> 
>>> 3.1. Voting
>>> 
>>> 3.1.1. Decisions regarding the project are made by votes on the
>>> primary project development mailing list
>>> (cloudstack-dev@incubator.apache.org).
>> 
>> How about the users ? they don't get to vote ?
> 
> AFAIK, all votes for an Apache project have to happen on the dev list
> (or private PMC list).

Ah interesting, then we should wrap the user role into the contributor role.
However I think users should have a say.

> 
>> 
>>> Where necessary, PMC voting may
>>> take place on the private CloudStack PMC mailing list. Votes are
>>> clearly indicated by subject line starting with [VOTE].
>> 
>> who can call a vote ?
> 
> I guess it depends on the specific vote that's occurring.  Should we
> add this per topic below?

I would say yes. Others have thoughts on this ?

> 
>> 
>>> Votes may
>>> contain multiple items for approval and these should be clearly
>>> separated. Voting is carried out by replying to the vote mail. Voting
>>> may take four flavors
>>> 
>>> +1 "Yes," "Agree," or "the action should be performed." In general,
>>> this vote also indicates a willingness on the behalf of the voter in
>>> "making it happen"
>>> +0 This vote indicates a willingness for the action under
>>> consideration to go ahead. The voter, however will not be able to
>>> help.
>>> -0 This vote indicates that the voter does not, in general, agree with
>>> the proposed action but is not concerned enough to prevent the action
>>> going ahead.
>>> -1 This is a negative vote. On issues where consensus is required,
>>> this vote counts as a veto. All vetoes must contain an explanation of
>>> why the veto is appropriate. Vetoes with no explanation are void. It
>>> may also be appropriate for a -1 vote to include an alternative course
>>> of action.
>> I am not a committer. If I vote -1, does this constitute a veto ?
> 
> The concept of binding vs non-binding is what decides that question.
> In the case of a contributor voting on a technical topic, the vote is
> non-binding and (IMO) therefore not a valid veto.  It's an expression
> of opinion.
> 
>> 
>>> 
>>> 3.1.2. All participants in the CloudStack project are encouraged to
>>> show their agreement with or against a particular action by voting.
>>> For technical decisions, only the votes of active committers are
>>> binding. Non binding votes are still useful for those with binding
>>> votes to understand the perception of an action in the wider
>>> CloudStack community. For PMC decisions, only the votes of PMC members
>>> are binding.
>> 
>> This clarifies 3.1.1 , but is still vague on a non-binding -1
>> 
> 
> Perhaps add: "Non-binding -1 votes are not considered to be vetos for
> any decision."

Maybe add a small subsection that describes binding vs non-binding.

> 
>>> 
>>> 3.1.3. Voting can also be applied to changes made to the CloudStack
>>> codebase. These typically take the form of a veto (-1) in reply to the
>>> commit message sent when the commit is made.
>> 
>> by a committer
>> 
>>> 
>>> 3.2. Approvals
>>> 
>>> These are the types of approvals that can be sought. Different actions
>>> require different types of approvals
>> 
>> There are three types of approvals that can be sought. Section 3.4 describes actions
and types of approvals needed.
> 
> Agreed.
> 
>> 
>>> 
>>> Lazy Consensus - Lazy consensus requires 3 binding +1 votes and no
>>> binding vetoes.
>>> Lazy Majority - A lazy majority vote requires 3 binding +1 votes and
>>> more binding +1 votes than -1 votes.
>>> Lazy 2/3 Majority - Lazy 2/3 majority votes requires at least 3 votes
>>> and twice as many +1 votes as -1 votes.
>>> 
>>> 3.3. Vetoes
>>> 
>>> 3.3.1. Vetoes are only possible in a lazy consensus vote.
>>> 
>>> 3.3.2. A valid, binding veto cannot be overruled. If a veto is cast,
>>> it must be accompanied by a valid reason explaining the reasons for
>>> the veto. The validity of a veto, if challenged, can be confirmed by
>>> anyone who has a binding vote. This does not necessarily signify
>>> agreement with the veto - merely that the veto is valid.
>>> 
>>> 3.3.3. If you disagree with a valid veto, you must lobby the person
>>> casting the veto to withdraw their veto. If a veto is not withdrawn,
>>> any action that has been vetoed must be reversed in a timely manner.
>> who is you ?
>>> 
>>> 3.4. Actions
>>> 
>>> This section describes the various actions which are undertaken within
>>> the project, the corresponding approval required for that action and
>>> those who have binding votes over the action.
>>> 
>>> 3.4.1. Technical Decisions
>>> 
>>> Technical decisions should be made by the entire community using
>>> consensus gathering, and not through formal voting.  The CloudStack
>>> community will assume that silence represents consensus on a proposal.
>>> 
>> Since there is no vote, what is the timeline for considering that consensus has been
reached.
>> 
>>> During the consensus gathering process, technical decisions may be
>>> vetoed by any Committer with a valid reason.
>>> 
>>> 3.4.2. Release Plan
>>> 
>>> Defines the timetable and actions for a release.
>> 
>> "timetable and work items " to avoid using "actions" in this "Actions" section.
>> 
> 
> Agreed.
> 
>>> The plan also
>>> nominates a Release Manager.
>>> 
>>> Lazy majority of active committers
>>> 
>>> 3.4.3. Product Release
>>> 
>>> When a release of one of the project's products is ready, a vote is
>>> required to accept the release as an official release of the project.
>>> 
>>> Lazy Majority of active PMC members
>>> 
>>> 3.4.4. Adoption of New Codebase
>>> 
>>> When the codebase for an existing, released product is to be replaced
>>> with an alternative codebase. If such a vote fails to gain approval,
>>> the existing code base will continue.
>>> 
>>> This also covers the creation of new sub-projects within the project
>>> 
>>> Lazy 2/3 majority of PMC members
>>> 
>>> 3.4.5. New Committer
>>> 
>>> When a new committer is proposed for the project
>>> 
>>> Lazy consensus of active PMC members
>>> 
>>> 3.4.6. New PMC Member
>>> 
>>> When a committer is proposed for the PMC
>>> 
>>> Lazy consensus of active PMC members
>>> 
>>> 3.4.7. Committer Removal
>>> 
>>> When removal of commit privileges is sought. Note: Such actions will
>>> also be referred to the ASF board by the PMC chair
>>> 
>>> Lazy 2/3 majority of active PMC members (excluding the committer in
>>> question if a member of the PMC).
>>> 
>>> 3.4.8. PMC Member Removal
>>> 
>>> When removal of a PMC member is sought. Note: Such actions will also
>>> be referred to the ASF board by the PMC chair.
>>> 
>>> Lazy 2/3 majority of active PMC members (excluding the member in question)
>>> 
>>> 3.4.9. Modifying Bylaws
>>> 
>>> Modifying this document.
>>> 
>>> Lazy majority of active PMC members
>>> 
>> 
>> Do we need to set a timeframe on updating/reviewing bylaws ?
>> 
> 
> I wasn't suggesting one, but do folks think this is a good idea?

We need to check who is allowed to call a vote on changing the bylaws :)
Then technically it could happen at anytime.

> 
>>> 3.5. Voting Timeframes
>>> 
>>> Formal votes are open for a period of at least 72 hours to allow all
>>> active voters time to consider the vote.
>>> 
>>> *****************************************************
>> 
>> -sebastien
>> 
>> 


Mime
View raw message