impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brown <mi...@cloudera.com>
Subject Re: [VOTE] Apache Impala Bylaws
Date Fri, 22 Jul 2016 21:06:12 GMT
+1 (non-binding)

On Fri, Jul 22, 2016 at 12:46 PM, Jim Apple <jbapple@cloudera.com> 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 (dev@impala.incubator.apache.org).
> 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.

Mime
View raw message