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? 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? > 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. >> 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. > >> 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? >> 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? >> >> 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... >> - 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. >> >> 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? >> 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). > >> 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? > >> 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." >> >> 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? >> 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 > >
