Chip, some thoughts inline. Don't mind the pickiness.
On Dec 13, 2012, at 3:30 AM, Chip Childers <chip.child...@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. > 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 ? > 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 ? Is that all users can do ? What's their responsibilities ? > 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 ? > 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) > though the exact timing of such > invitations depends on many factors. Which ones ? > The form of contribution is not > limited to code. But is it mandatory ? > 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 ? > > 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. > 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. > > 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 ? > It can also include code review, helping out > users on the mailing lists, documentation, testing, etc. no etc. > > 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 ? > - 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 ? > > 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. > For example, the previous section > describes several decisions which require "lazy consensus" approval. no need for example. > 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 ? > 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 ? > 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 ? > > 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 > > 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. > > 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. > 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 ? > 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
