On Dec 13, 2012, at 5:19 PM, Chip Childers <chip.child...@sungard.com> wrote:
> On Thu, Dec 13, 2012 at 9:58 AM, Sebastien Goasguen <run...@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.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. >> > > 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 >> >>
