Mailing-List: contact dev-help@impala.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@impala.incubator.apache.org
MIME-Version: 1.0
From: Jim Apple <jbapple@cloudera.com>
Date: Fri, 22 Jul 2016 12:46:40 -0700
Message-ID: <CAC-pSX0C+mYJ3mRGZxz3OUhsuC+m-2xxtWEuwmtwWh0AXSvM8Q@mail.gmail.com>
Subject: [VOTE] Apache Impala Bylaws
To: dev@impala.incubator.apache.org
Content-Type: text/plain; charset=UTF-8
archived-at: Fri, 22 Jul 2016 19:47:27 -0000

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.