+1 On Fri, Jul 22, 2016 at 1:37 PM, Sailesh Mukil <[email protected]> wrote:
> +1 > > On Fri, Jul 22, 2016 at 1:16 PM, Marcel Kornacker <[email protected]> > wrote: > > > +1 > > > > On Fri, Jul 22, 2016 at 12:46 PM, Jim Apple <[email protected]> > wrote: > > > This is a vote on the following proposal for bylaws: > > > > > > https://gerrit.cloudera.org/#/c/3669/2 > > > > > > The vote is to be done by "Lazy Consensus". Active PMC members, > > > according to http://incubator.apache.org/projects/impala.html, may > > > vote. The vote will be open 72 hours and will pass if there are "3 > > > binding +1 votes and more binding +1 votes than -1 votes." > > > > > > +++++ > > > > > > I am not on the PPMC, so my vote is non-binding. Here it is anyway, as > > > according to our draft bylaws, "Non binding votes are still useful for > > > those with binding votes to understand the perception of an action in > > > the wider Impala community." > > > > > > (Non-binding) +1. > > > > > > My reasoning is that these bylaws are probably not utterly bonkers, > > > since they are mostly what Hadoop uses, and they are easy to change if > > > anyone finds something problematic. Additionally, since many of us in > > > the Impala community are new to The Apache Way, having a document that > > > spells things out (like how voting works) will, I hope, serve as a > > > helpful foundation. > > > > > > +++ > > > > > > Here is a plain-text copy of the patch for mailing-list archival > > purposes: > > > > > > +++ > > > > > > Apache Impala (incubating) Project Bylaws > > > > > > Introduction > > > > > > This document defines the bylaws under which the Apache Impala > > > (incubating) project operates. It defines the roles and > > > responsibilities of the project, who may vote, how voting works, how > > > conflicts are resolved, etc. > > > > > > Impala is a project of the Apache Software Foundation. The foundation > > > holds the trademark on the name "Impala" and copyright on Apache code > > > including the code in the Impala codebase. The foundation FAQ explains > > > the operation and background of the foundation. > > > > > > Impala 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. > > > > > > 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. > > > > > > Contributors > > > All of the volunteers who are contributing time, code, documentation, > > > or resources to the Impala 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 write access to the project's version > > > control repositories. Committers may cast binding votes on any > > > technical discussion. > > > > > > Committer access is by invitation only and must be approved by > > > consensus approval 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 consensus approval of active PMC members. > > > > > > Significant, pervasive features may be developed in a speculative > > > branch of the repository. The PMC may grant commit rights on the > > > branch to its consistent contributors for the duration of the > > > initiative. Branch committers are responsible for shepherding their > > > feature into an active release and do not cast binding votes or vetoes > > > in the project. > > > > > > 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, testing, etc. > > > > > > Release Manager > > > A Release Manager (RM) is a committer who volunteers to produce a > > > Release Candidate according to HowToRelease. The RM shall publish a > > > Release Plan on the dev@ list stating the branch from which they > > > intend to make a Release Candidate, at least one week before they do > > > so. The RM is responsible for building consensus around the content of > > > the Release Candidate, in order to achieve a successful Product > > > Release vote. > > > > > > Project Management Committee > > > The Project Management Committee (PMC) is responsible to the board and > > > the ASF for the management and oversight of the Apache Impala > > > codebase. The responsibilities of the PMC include > > > > > > Deciding what is distributed as products of the Apache Impala project. > > > In particular all releases must be approved by the PMC > > > Maintaining the project's shared resources, including the codebase > > > repository, mailing lists, and 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 > > > consensus approval 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 consensus > > > approval of the active PMC members. > > > > > > 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 Impala) and has primary responsibility to the board for the > > > management of the projects within the scope of the Impala PMC. The > > > chair reports to the board quarterly on developments within the Impala > > > project. > > > > > > 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 BoardVoting > > > for specifics. The decision must be ratified by the Apache board. > > > > > > Decision Making > > > > > > Within the Impala project, different types of decisions require > > > different forms of approval. For example, the previous section > > > describes several decisions which require "consensus approval" > > > 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 ([email protected]). > > > Where necessary, PMC voting may take place on the private Impala PMC > > > mailing list. 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 > > > > > > +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. > > > Patches are reviewed in the code review tool, where the vote flavors > are: > > > > > > +2 "I am confident in the change and this can be committed without > > > further review after addressing the remaining points I have made." > > > +1 "I am OK with this being committed after the remaining points in my > > > comment have been addressed and someone else votes +2." > > > -1 "I oppose this being committed." > > > All participants in the Impala 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 Impala community. > > > For PMC decisions, only the votes of PMC members are binding. > > > > > > Approvals > > > These are the types of approvals that can be sought. Different actions > > > require different types of approvals > > > > > > Consensus Approval - Consensus approval requires 3 binding +1 votes > > > and no binding vetoes. > > > Lazy Consensus - Lazy consensus requires no -1 votes ('silence gives > > assent'). > > > 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. > > > 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 their veto. If a veto is not withdrawn, any > > > 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. > > > > > > Code Change > > > A change made to a codebase of the project and committed by a > > > committer. This includes source code, documentation, website content, > > > etc. > > > > > > At least one +2 from a committer and no -1 from any committer. > > > > > > 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 > > > > > > New Branch Committer > > > When a branch committer is proposed for the PMC > > > > > > Lazy consensus of active PMC members > > > > > > New Committer > > > When a new committer is proposed for the project > > > > > > Consensus approval of active PMC members > > > > > > New PMC Member > > > When a committer is proposed for the PMC > > > > > > Consensus approval of active PMC members > > > > > > Branch Committer Removal > > > When removal of commit privileges is sought or when the branch is > > > merged to the mainline > > > > > > Lazy 2/3 majority of active PMC members > > > > > > 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). > > > > > > 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) > > > > > > Modifying Bylaws > > > Modifying this document. > > > > > > Lazy majority of active PMC members > > > > > > Voting Timeframes > > > Votes are open for a period of 72 hours to allow all active voters > > > time to consider the vote. Votes relating to code changes are not > > > subject to a strict timetable but should be made as timely as > > > possible. > > >
