accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From md...@apache.org
Subject svn commit: r1574568 - /accumulo/site/trunk/content/bylaws.mdtext
Date Wed, 05 Mar 2014 16:44:04 GMT
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: dev@accumulo.apache.org. Where necessary, PMC voting may take place on the private Accumulo
PMC mailing list: private@accumulo.apache.org. 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



Mime
View raw message