Author: mdrob
Date: Wed Mar 5 16:44:03 2014
New Revision: 1574568
URL: http://svn.apache.org/r1574568
Log:
Adding Bylaws Draft for Voting.
Added:
accumulo/site/trunk/content/bylaws.mdtext (with props)
Added: accumulo/site/trunk/content/bylaws.mdtext
URL:
http://svn.apache.org/viewvc/accumulo/site/trunk/content/bylaws.mdtext?rev=1574568&view=auto
==============================================================================
--- accumulo/site/trunk/content/bylaws.mdtext (added)
+++ accumulo/site/trunk/content/bylaws.mdtext Wed Mar 5 16:44:03 2014
@@ -0,0 +1,167 @@
+Title: Apache Accumulo Bylaws
+Notice: Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ .
+ http://www.apache.org/licenses/LICENSE-2.0
+ .
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+# Apache Accumulo Project Bylaws
+
+This is version 0 of the bylaws. This draft has not yet been accepted by the
Accumulo Project and only exists for voting purposes.
+
+# Introduction
+
+This document defines the bylaws under which the Apache Accumulo project
operates. It defines the roles and responsibilities of the project, who may
vote, how voting works, how conflicts are resolved, etc.
+
+Accumulo is a project of the [Apache Software
Foundation](http://www.apache.org/foundation/). The foundation holds the
copyright on Apache code including the code in the Accumulo codebase. The
[foundation FAQ](http://www.apache.org/foundation/faq.html) explains the
operation and background of the foundation.
+
+Accumulo 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](http://incubator.apache.org/) for more information on how Apache
projects operate. Terms used at the ASF are defined in the [ASF
glossary](http://www.apache.org/foundation/glossary.html).
+
+# 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 Accumulo project are considered contributors. 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 code repositories and
may cast binding votes on any technical discussion regarding Accumulo.
Committer access is by invitation only and must be approved by consensus
approval of the active PMC members. Upon acceptance of the invitation to become
a committer, it is the accepting memberâs responsibility to update his/her
status on the Accumulo web page accordingly.
+
+A committer is considered emeritus, meaning inactive, by his or her own
declaration or by not reviewing patches or committing patches to the project
for over six months. Emeritus members will be recognized by the PMC on the
Accumulo web page, in honor of their past contributions. Emeritus members
retain all voting and commit rights associated with their former designation
and can move themselves out of emeritus status by sending an announcement of
their return to the developer mailing list. It will be the returning member's
responsibility to update his/her status on the web page accordingly.
+
+An emeritus committerâs commit access may be disabled as part of routine
security. Access shall not be removed without notifying the committer, and
access shall be maintained if the committer wishes to leave it active. A
committerâs commit access shall be reactivated upon the committerâs request
to the PMC.
+
+All Apache committers are required to have a signed [Contributor License
Agreement](http://www.apache.org/licenses/icla.txt) on file with the Apache
Software Foundation. There is a [Committer
FAQ](http://www.apache.org/dev/committers.html) which provides more details on
the requirements for committers.
+
+It is the custom of the Accumulo project to also invite each committer to
become a member of the Accumulo PMC.
+
+## Project Management Committee
+
+The Project Management Committee (PMC) is responsible to the ASF Board of
Directors (âthe Boardâ) for the management and oversight of the Apache
Accumulo codebase. The responsibilities of the PMC include:
+
+Deciding what is distributed as products of the Apache Accumulo 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. Upon acceptance of the invitation to
become a PMC member, it is the accepting memberâs responsibility to update
his/her status on the Accumulo web page accordingly.
+
+A PMC member is considered emeritus, meaning inactive, by his or her own
declaration or by not contributing in any form to the project for over six
months. Emeritus members will be recognized by the PMC on the Accumulo web
page, in honor of their past contributions. Emeritus members retain all voting
and commit rights associated with their former designation and can move
themselves out of emeritus status by sending an announcement of their return to
the developer mailing list. It will be the returning member's responsibility to
update his/her status on the web page accordingly.
+
+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 Accumulo) and
has primary responsibility to the board for the management of the projects
within the scope of the Accumulo PMC. The chair reports to the board quarterly
on developments within the Accumulo project.
+
+When the current chair of the PMC resigns, the PMC votes to recommend a new
chair using consensus approval, but the decision must be ratified by the Apache
board.
+
+# Decision Making
+
+Within the Accumulo project, different types of decisions require different
forms of approval. For example, the previous section describes several
decisions which require '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: [email protected]. Where necessary, PMC voting
may take place on the private Accumulo PMC mailing list:
[email protected]. Votes are clearly indicated by a subject line
starting with [VOTE]. A vote message may only pertain to a single itemâs
approval; multiple items should be separated into multiple messages. Voting is
carried out by replying to the vote mail. A vote may take on one of four forms,
defined below.
+
+<table>
+<tr><th>Vote</th>
+ <th>Meaning</th>
+<tr><td>+1</td>
+ <td>'Yes,' 'Agree,' or 'The action should be performed.' In general, this
vote also indicates a willingness on the behalf of the voter to 'make it
happen'.</td>
+<tr><td>+0</td>
+ <td>This vote indicates a willingness for the action under consideration
to go ahead. The voter, however, will not be able to help.</td>
+<tr><td>-0</td>
+ <td>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.</td>
+<tr><td>-1</td>
+ <td>'No', 'Disagree', or 'The action should not be performed.' 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.</td>
+</table>
+
+All participants in the Accumulo project are encouraged to vote. 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 across the wider Accumulo community. For PMC decisions, only the
votes of active PMC members are binding.
+
+Voting can also be applied to changes to the Accumulo codebase. Please refer
to the Accumulo commit and review standard for details.
+
+## Approvals
+
+There are the types of approvals that can be sought. Different actions require
different types of approvals.
+
+<table>
+<tr><th>Approval Type</th>
+ <th>Definition</th>
+<tr><td>Consensus Approval</td>
+ <td>A consensus approval vote passes with 3 binding +1 votes and no
binding vetoes.</td>
+<tr><td>Majority Approval</td>
+ <td>A majority approval vote passes with 3 binding +1 votes and more
binding +1 votes that -1 votes.</td>
+<tr><td>Lazy Approval (or Lazy Consensus)</td>
+ <td>An action with lazy approval is implicitly allowed unless a -1 vote is
received, at which time, depending on the type of action, either majority
approval or consensus approval must be obtained.</td>
+</table>
+
+## Vetoes
+
+A valid, binding veto cannot be overruled. If a veto is cast, it must be
accompanied by a valid reason explaining 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.
+
+<table>
+<tr><th>Action</th>
+ <th>Description</th>
+ <th>Approval</th>
+ <th>Binding Votes</th>
+ <th>Minimum Length (days)</th>
+<tr><td>Code Change</td>
+ <td>A change made to a codebase of the project. This includes source code,
documentation, website content, etc.</td>
+ <td>Lazy approval, moving to consensus approval if a -1 is received.</td>
+ <td>Active committers</td>
+ <td>1</td>
+<tr><td>Release Plan</td>
+ <td>Defines the timetable and actions for a release. The plan also
nominates a Release Manager.</td>
+ <td>Majority approval</td>
+ <td>Active committers</td>
+ <td>3</td>
+<tr><td>Product Release</td>
+ <td>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.</td>
+ <td>Majority approval</td>
+ <td>Active PMC members</td>
+ <td>3</td>
+<tr><td>Adoption of New Codebase</td>
+ <td>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.</td>
+ <td>Consensus approval</td>
+ <td>Active PMC members</td>
+ <td>7</td>
+<tr><td>New Committer or Reinstatement</td>
+ <td>When a new committer is proposed for the project.</td>
+ <td>Consensus approval</td>
+ <td>Active PMC members</td>
+ <td>3</td>
+<tr><td>New PMC Member or Reinstatement</td>
+ <td>When a committer is proposed for the PMC.</td>
+ <td>Consensus approval</td>
+ <td>Active PMC members</td>
+ <td>3</td>
+<tr><td>Modifying Bylaws</td>
+ <td>Modifying this document.</td>
+ <td>Majority approval</td>
+ <td>Active PMC members</td>
+ <td>7</td>
+</table>
Propchange: accumulo/site/trunk/content/bylaws.mdtext
------------------------------------------------------------------------------
svn:eol-style = native
