Any more discussion on this? If don't hear back I'll put this up for the vote on Monday
FYI, there is a mistake in the text on the wiki: (I edited the page to address) "Decisions regarding the project are made by votes on the primary project development mailing list u...@zookeeper.apache.org." The primary project mailing list is the dev@ list. Regards, Patrick On Wed, Jan 12, 2011 at 5:26 PM, Mahadev Konar <maha...@yahoo-inc.com> wrote: > I agree with Pat on this one. Ben, we do send out notices saying that we are > cleaning up patches and if folks want to add to the release or think some > jira should be there to voice there concern. I am not sure whats the > significance of adding it to the bylaws? We can definitely add it to how to > release section. What do you think? > > Thanks > mahadev > > > On 1/12/11 3:40 PM, "Patrick Hunt" <ph...@apache.org> wrote: > >> Why don't we see if it becomes a problem and then add it to our >> process rather than codifying in the bylaws. That work? >> >> Patrick >> >> On Wed, Jan 12, 2011 at 3:36 PM, Benjamin Reed <br...@yahoo-inc.com> wrote: >>> i've added it to the cwiki: >>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeperBylawsProposal >>> >>> i don't mean the pre-annouce time to stretch things out. it's really to make >>> sure the status updates go out. as we get more committers we need to make >>> sure that there is a heads up that something is coming so that if someone >>> will be on vacation or something like that we can take it into account. >>> >>> the idea is that we would say: hey next month we will be having a vote that >>> way interested parties can watch out for it rather than going on vacation, >>> coming back, and finding out that a blocker was overridden and a flawed >>> release has gone out. >>> >>> ben >>> >>> On 01/12/2011 09:21 AM, Patrick Hunt wrote: >>>> >>>> Hi Ben, thanks for getting this rolling. Your committer suggestion >>>> sounds fine to me. WRT to pre announcing, we are already giving >>>> multiple days for a vote, also in the lead up to a release it should >>>> be pretty obvious that one is imminent (we usually send out status >>>> updates and such, plus the activity is pretty clear on the lists, >>>> jira, svn, etc...). Adding more "pre announce time" will stretch out >>>> the timeframes (and process) even longer, I'd rather we keep it as is >>>> unless ppl think this is a big issue. >>>> >>>> Would you mind creating a proposal page on the cwiki similar to what Pig >>>> did? >>>> http://markmail.org/message/lvchbhoojpbwuxyx >>>> >>>> Regards, >>>> >>>> Patrick >>>> >>>> On Tue, Jan 4, 2011 at 9:17 AM, Benjamin Reed<br...@yahoo-inc.com> wrote: >>>>> >>>>> I really like the Pig bylaws. I would suggest using it as a starting >>>>> point >>>>> for ZooKeeper. One thing I would like to modify is the Committer section. >>>>> Pig's bylaws state that the committer becomes emeritus if they haven't >>>>> contributed in any form for 6 months. I would tighten that up and say if >>>>> they haven't been actively involved in reviewing or committing. (They are >>>>> after all committers.) I have made this change to the text. >>>>> >>>>> The other change that I would like, and did not add, is for some of the >>>>> votes to have a requirement to pre-announce. Specifically for PMC, >>>>> committer, and release it would be nice to give a week or two notice that >>>>> a >>>>> vote will be coming up, just so that interested parties don't miss it. >>>>> >>>>> ben >>>>> >>>>> here is the text: >>>>> >>>>> Introduction >>>>> This document defines the bylaws under which the Apache ZooKeeper project >>>>> operates. It defines the roles and responsibilities of the project, who >>>>> may >>>>> vote, how voting works, how conflicts are resolved, etc. >>>>> >>>>> ZooKeeper is a project of the Apache Software Foundation The foundation >>>>> holds the copyright on Apache code including the code in the ZooKeeper >>>>> codebase. The foundation FAQ explains the operation and background of the >>>>> foundation. >>>>> >>>>> ZooKeeper 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. >>>>> >>>>> 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. >>>>> >>>>> Users >>>>> The most important participants in the project are people who use our >>>>> software. The majority of our contributors start out as users and guide >>>>> their development efforts from the user's perspective. >>>>> >>>>> Users contribute to the Apache projects by providing feedback to >>>>> contributors 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. >>>>> >>>>> Contributors >>>>> All of the volunteers who are contributing time, code, documentation, or >>>>> resources to the ZooKeeper Project. A contributor that makes sustained, >>>>> welcome contributions to the project may be invited to become a >>>>> committer, >>>>> though the exact timing of such invitations depends on many factors. >>>>> >>>>> Committers >>>>> The project's committers are responsible for the project's technical >>>>> management. Committers have access to a specified set of subproject's >>>>> subversion repositories. Committers on subprojects may cast binding votes >>>>> on >>>>> any technical discussion regarding that subproject. >>>>> >>>>> Committer access is by invitation only and must be approved by lazy >>>>> consensus of the active PMC members. A Committer is considered emeritus >>>>> by >>>>> his or her own declaration or by not reviewing patches or commiting >>>>> patches >>>>> to the project for over six months. An emeritus committer may request >>>>> reinstatement of commit access from the PMC which must be approved by >>>>> lazy >>>>> consensus of the active PMC members. >>>>> >>>>> Commit access can be revoked by a unanimous vote of all the active PMC >>>>> members (except the committer in question if he or she is also a PMC >>>>> member). >>>>> >>>>> All Apache committers are required to have a signed Contributor License >>>>> Agreement (CLA) on file with the Apache Software Foundation. There is a >>>>> Committer FAQ which provides more details on the requirements for >>>>> committers. >>>>> >>>>> 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. It can also include code review, helping out users on the mailing >>>>> lists, documentation, etc. >>>>> >>>>> Project Management Committee >>>>> The PMC is responsible to the board and the ASF for the management and >>>>> oversight of the Apache ZooKeeper codebase. The responsibilities of the >>>>> PMC >>>>> include >>>>> >>>>> Deciding what is distributed as products of the Apache ZooKeeper 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. >>>>> Resolving license disputes regarding products of the project. >>>>> Nominating new PMC members and committers. >>>>> Maintaining these bylaws and other guidelines of the project. >>>>> 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 >>>>> his >>>>> or her 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, >>>>> which must be approved by a lazy consensus of active PMC members. >>>>> >>>>> Membership of the PMC can be revoked by an unanimous vote of all the >>>>> active >>>>> PMC members other than the member in question. >>>>> >>>>> 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 >>>>> ZooKeeper) >>>>> and has primary responsibility to the board for the management of the >>>>> projects within the scope of the ZooKeeper PMC. The chair reports to the >>>>> board quarterly on developments within the ZooKeeper project. >>>>> >>>>> When the current chair of the PMC resigns, the PMC votes to recommend a >>>>> new >>>>> chair using lazy consensus, but the decision must be ratified by the >>>>> Apache >>>>> board. >>>>> >>>>> Decision Making >>>>> Within the ZooKeeper project, different types of decisions require >>>>> different >>>>> forms of approval. For example, the previous section describes several >>>>> decisions which require 'lazy consensus' approval. This section defines >>>>> how >>>>> voting is performed, the types of approvals, and which types of decision >>>>> require which type of approval. >>>>> >>>>> Voting >>>>> Decisions regarding the project are made by votes on the primary project >>>>> development mailing list u...@zookeeper.apache.org. Where necessary, PMC >>>>> voting may take place on the private ZooKeeper PMC mailing list >>>>> priv...@zookeeper.apache.org. Votes are clearly indicated by subject line >>>>> starting with [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. >>>>> >>>>> Vote Meaning >>>>> +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. >>>>> All participants in the ZooKeeper 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 ZooKeeper community. For PMC >>>>> decisions, >>>>> only the votes of PMC members are binding. >>>>> >>>>> Voting can also be applied to changes already made to the ZooKeeper >>>>> codebase. These typically take the form of a veto (-1) in reply to the >>>>> commit message sent when the commit is made. Note that this should be a >>>>> rare >>>>> occurrence. All efforts should be made to discuss issues when they are >>>>> still >>>>> patches before the code is committed. >>>>> >>>>> Approvals >>>>> These are the types of approvals that can be sought. Different actions >>>>> require different types of approvals. >>>>> >>>>> Approval Type Definition >>>>> Consensus For this to pass, all voters with binding votes must >>>>> vote >>>>> and there can be no binding vetoes (-1). Consensus votes are rarely >>>>> required >>>>> due to the impracticality of getting all eligible voters to cast a vote. >>>>> 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 that -1 votes. >>>>> Lazy Approval An action with lazy approval is implicitly allowed >>>>> unless a >>>>> -1 vote is received, at which time, depending on the type of action, >>>>> either >>>>> lazy majority or lazy consensus approval must be obtained. >>>>> 2/3 Majority Some actions require a 2/3 majority of active committers >>>>> or >>>>> PMC members to pass. Such actions typically affect the foundation of the >>>>> project (e.g. adopting a new codebase to replace an existing product). >>>>> The >>>>> higher threshold is designed to ensure such changes are strongly >>>>> supported. >>>>> To pass this vote requires at least 2/3 of binding vote holders to vote >>>>> +1. >>>>> >>>>> Vetoes >>>>> 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. >>>>> >>>>> If you disagree with a valid veto, you must lobby the person casting the >>>>> veto to withdraw his or her veto. If a veto is not withdrawn, the action >>>>> that has been vetoed must be reversed in a timely manner. >>>>> >>>>> 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. It also specifies the minimum length >>>>> of >>>>> time that a vote must remain open, measured in business days. In general >>>>> votes should not be called at times when it is known that interested >>>>> members >>>>> of the project will be unavailable. >>>>> >>>>> Action Description Approval Binding Votes Minimum Length >>>>> Code Change A change made to a codebase of the project and committed >>>>> by a >>>>> committer. This includes source code, documentation, website content, >>>>> etc. >>>>> Lazy approval (not counting the vote of the contributor), moving to lazy >>>>> majority if a -1 is received Active committers 1 >>>>> Release Plan Defines the timetable and actions for a release. The plan >>>>> also nominates a Release Manager. Lazy majority Active committers >>>>> 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 Active PMC members 3 >>>>> 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. 2/3 majority >>>>> Active >>>>> PMC members 6 >>>>> New Committer or reinstatement When a new committer is proposed for the >>>>> project. Lazy consensus Active PMC members 3 >>>>> New PMC Member or reinstatement When a committer is proposed for the >>>>> PMC. >>>>> Lazy consensus Active PMC members 3 >>>>> Committer Removal When removal of commit privileges is sought. Note: >>>>> Such >>>>> actions will also be referred to the ASF board by the PMC chair. >>>>> Consensus Active PMC members (excluding the committer in question if >>>>> a >>>>> member of the PMC). 6 >>>>> 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. >>>>> Consensus Active PMC members (excluding the member in question). 6 >>>>> Modifying Bylaws Modifying this document. 2/3 majority Active >>>>> PMC >>>>> members 6 >>>>> >>>>> >>> >>> >> > >
