crunch-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From m...@apache.org
Subject svn commit: r1453462 - in /crunch/site/trunk: content/bylaws.mdtext lib/path.pm
Date Wed, 06 Mar 2013 18:19:43 GMT
Author: mafr
Date: Wed Mar  6 18:19:43 2013
New Revision: 1453462

URL: http://svn.apache.org/r1453462
Log:
Add DRAFT bylaws document to vote on.
Don't publish until we have a successful vote!

Added:
    crunch/site/trunk/content/bylaws.mdtext   (with props)
Modified:
    crunch/site/trunk/lib/path.pm

Added: crunch/site/trunk/content/bylaws.mdtext
URL: http://svn.apache.org/viewvc/crunch/site/trunk/content/bylaws.mdtext?rev=1453462&view=auto
==============================================================================
--- crunch/site/trunk/content/bylaws.mdtext (added)
+++ crunch/site/trunk/content/bylaws.mdtext Wed Mar  6 18:19:43 2013
@@ -0,0 +1,356 @@
+Title:    Project 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.
+
+
+This document defines the bylaws under which the Apache Crunch 
+project operates. It defines the roles and responsibilities of the 
+project, who may vote, how voting works, how conflicts are resolved, etc. 
+
+Crunch 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
+Crunch codebase. The
+[Foundation FAQ](http://www.apache.org/foundation/faq.html) explains the
+operation and background of the foundation. 
+
+Crunch 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. 
+
+
+## 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 Crunch 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. They have access to all of the project's code repositories
+and may cast binding votes on any technical discussion regarding the
+project.
+
+Committer access is by invitation only and must be approved by lazy 
+consensus of the active PMC members. A committer is considered *emeritus*
+by his or her own declaration or by not reviewing patches or committing 
+patches to the project for over six months. An emeritus committer may 
+request reinstatement of commit access from the PMC which must be 
+approved by lazy consensus of the active PMC members. 
+
+Commit access can be revoked by a unanimous vote of all the active PMC 
+members (except the committer in question if he or she is also a PMC 
+member). 
+
+All Apache committers are required to have a signed [Contributor License
+Agreement (CLA)](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. 
+
+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, etc. 
+
+### Project Management Committee 
+
+The Project Management Committee (PMC) is responsible to the board and
+the ASF for the management and oversight of the Apache Crunch codebase.
+The responsibilities of the PMC include: 
+
+  * Deciding what is distributed as products of the Apache Crunch 
+    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 
+lazy consensus of active PMC members. A PMC member is considered 
+emeritus by his or her 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, which must be approved by a lazy consensus of 
+active PMC members. 
+
+Membership of the PMC can be revoked by an unanimous vote of all the 
+active PMC members other than the member in question. 
+
+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 
+Crunch) and has primary responsibility to the board for the 
+management of the projects within the scope of the Crunch PMC. The 
+chair reports to the board quarterly on developments within the 
+Crunch project. 
+
+The term of the chair is one year. When the current chair's term is up or if
+the chair resigns before the end of his or her term, the PMC votes to
+recommend a new chair using lazy consensus, but the decision must be ratified
+by the Apache board. 
+
+
+## Decision Making 
+
+Within the Apache Crunch project, different types of decisions require 
+different forms of approval. For example, the previous section describes 
+several decisions which require "lazy 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@crunch.apache.org. Where necessary, PMC 
+voting may take place on the private Crunch PMC mailing list 
+private@crunch.apache.org. 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. 
+
+<table class="table">
+  <thead>
+    <tr>
+      <th>Vote</th>
+      <th>Meaning</th>
+    </tr>
+  </thead>
+  <tbody>
+    <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 in
+          "making it happen."</td>
+    </tr>
+    <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>
+    <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>
+    <tr>
+     <td>-1</td>
+     <td>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.</td> 
+    </tr>
+  </tbody>
+</table>
+
+All participants in the Crunch 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 Crunch community. For PMC decisions,
+only the votes of PMC members are binding. 
+
+Voting can also be applied to changes already made to the Crunch
+codebase. These typically take the form of a veto (-1) in reply to the 
+commit message sent when the commit is made. Note that this should be a 
+rare occurrence. All efforts should be made to discuss issues when they 
+are still patches before the code is committed. 
+
+### Approvals 
+
+These are the types of approvals that can be sought. Different actions 
+require different types of approvals. 
+
+<table class="table">
+  <thead>
+    <tr>
+      <th>Approval Type</th>
+      <th>Definition</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>Consensus</td>
+      <td>For this to pass, all voters with binding votes must vote and there
+          can be no binding vetoes (-1). Consensus votes are rarely required
+          due to the impracticality of getting all eligible voters to cast a
+          vote.</td> 
+    </tr>
+    <tr>
+      <td>Lazy Consensus</td>
+      <td>Lazy consensus requires 3 binding +1 votes and no binding vetoes.</td>
+    </tr>
+    <tr>
+      <td>Lazy Majority</td>
+      <td>A lazy majority vote requires 3 binding +1 votes and more binding +1
+          votes that -1 votes.</td>
+    </tr>
+    <tr>
+      <td>Lazy Approval</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
+          lazy majority or lazy consensus approval must be obtained.</td>
+    </tr>
+    <tr>
+      <td>2/3 Majority</td>
+      <td>Some actions require a 2/3 majority of active committers or PMC
+          members to pass. Such actions typically affect the foundation of 
+          the project (e.g. adopting a new codebase to replace an existing 
+          product). The higher threshold is designed to ensure such changes
+          are strongly supported. To pass this vote requires at least 2/3 of
+          binding vote holders to vote +1.</td>
+    </tr>
+  </tbody>
+</table>
+
+### 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 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 class="table">
+  <thead>
+    <tr>
+      <th>Action</th>
+      <th>Description</th>
+      <th>Approval</th>
+      <th>Binding Votes</th>
+      <th>Days</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>Code Change</td>
+      <td>A change made to a codebase of the project and committed by a
+          committer. This includes source code, documentation, website 
+          content, etc.</td>
+      <td>Lazy approval (not counting the vote of the contributor), moving
+          to lazy majority if a -1 is received</td>
+      <td>Active committers</td>
+      <td>1</td> 
+    </tr>
+    <tr>
+      <td>Release Plan</td>
+      <td>Defines the timetable and actions for a release. The plan also
+          nominates a Release Manager.</td>
+      <td>Lazy majority</td>
+      <td>Active committers</td>
+      <td>3</td>
+    </tr>
+    <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>Lazy majority</td>
+      <td>Active PMC members</td>
+      <td>3</td>
+    </tr>
+    <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.</td>
+      <td>2/3 majority</td>
+      <td>Active PMC members</td>
+      <td>6</td>
+    </tr>
+    <tr>
+      <td>New Committer or reinstatement</td>
+      <td>When a new committer is proposed for the project.</td>
+      <td>Lazy consensus</td>
+      <td>Active PMC members</td>
+      <td>3</td>
+    </tr>
+    <tr>
+      <td>New PMC Member or reinstatement</td>
+      <td>When a committer is proposed for the PMC.</td>
+      <td>Lazy consensus</td>
+      <td>Active PMC members</td>
+      <td>3</td>
+    </tr>
+    <tr>
+      <td>Committer Removal</td>
+      <td>When removal of commit privileges is sought. Note: Such actions
+          will also be referred to the ASF board by the PMC chair.</td>
+      <td>Consensus</td>
+      <td>Active PMC members (excluding the committer in question if a member
+          of the PMC).</td>
+      <td>6</td>
+    </tr>
+    <tr>
+      <td>PMC Member Removal</td>
+      <td>When removal of a PMC member is sought. Note: Such actions will
+          also be referred to the ASF board by the PMC chair.</td>
+      <td>Consensus</td>
+      <td>Active PMC members (excluding the member in question).</td>
+      <td>6</td>
+    </tr>
+    <tr>
+      <td>Modifying Bylaws</td>
+      <td>Modifying this document.</td>
+      <td>2/3 majority</td>
+      <td>Active PMC members</td>
+      <td>6</td>
+    </tr>
+  </tbody>
+</table>
+
+---
+
+*This is version 1 of the bylaws.*

Propchange: crunch/site/trunk/content/bylaws.mdtext
------------------------------------------------------------------------------
    svn:eol-style = native

Modified: crunch/site/trunk/lib/path.pm
URL: http://svn.apache.org/viewvc/crunch/site/trunk/lib/path.pm?rev=1453462&r1=1453461&r2=1453462&view=diff
==============================================================================
--- crunch/site/trunk/lib/path.pm (original)
+++ crunch/site/trunk/lib/path.pm Wed Mar  6 18:19:43 2013
@@ -20,6 +20,8 @@ our @nav = (
 	  href => "/mailing-lists.html" },
 	{ title => "Issue Tracking",
 	  href => "http://issues.apache.org/jira/browse/CRUNCH" },
+	{ title => "Bylaws",
+	  href => "/bylaws.html" },
 	{ title => "License",
 	  href => "http://apache.org/licenses/LICENSE-2.0.html" },
 );



Mime
View raw message