Return-Path: X-Original-To: apmail-couchdb-commits-archive@www.apache.org Delivered-To: apmail-couchdb-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6991711FDB for ; Fri, 1 Aug 2014 21:56:54 +0000 (UTC) Received: (qmail 86937 invoked by uid 500); 1 Aug 2014 21:56:54 -0000 Delivered-To: apmail-couchdb-commits-archive@couchdb.apache.org Received: (qmail 86882 invoked by uid 500); 1 Aug 2014 21:56:54 -0000 Mailing-List: contact commits-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list commits@couchdb.apache.org Received: (qmail 86873 invoked by uid 99); 1 Aug 2014 21:56:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Aug 2014 21:56:54 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Aug 2014 21:56:53 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id 4B60023893ED; Fri, 1 Aug 2014 21:55:45 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: svn commit: r1615244 - in /couchdb/site: bylaws.v1.html bylaws.v2.html Date: Fri, 01 Aug 2014 21:55:45 -0000 To: commits@couchdb.apache.org From: nslater@apache.org X-Mailer: svnmailer-1.0.9 Message-Id: <20140801215545.4B60023893ED@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Author: nslater Date: Fri Aug 1 21:55:44 2014 New Revision: 1615244 URL: http://svn.apache.org/r1615244 Log: Fixed links to point to correct internal anchors Modified: couchdb/site/bylaws.v1.html couchdb/site/bylaws.v2.html Modified: couchdb/site/bylaws.v1.html URL: http://svn.apache.org/viewvc/couchdb/site/bylaws.v1.html?rev=1615244&r1=1615243&r2=1615244&view=diff ============================================================================== --- couchdb/site/bylaws.v1.html (original) +++ couchdb/site/bylaws.v1.html Fri Aug 1 21:55:44 2014 @@ -24,7 +24,7 @@

2. Roles and Responsibilities

The ASF defines 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.

Your role is bestowed on you by your peers in recognition of your past contributions to the project and your position of trust within the community. It is not tied to your job, your current employer, or your current activity level. We are interested in you as an individual and we understand that your interactions with the project may change over time. -

Roles are never rescinded because of inactivity, unless that inactivity is causing a problem for the project. Fortunately, our decision making process means that inactivity is very rarely a problem. Roles will be rescinded if the Project Management Committee (or PMC, see 2.4. below) believes the individual is no longer able to responsibly discharge the duty of the role. +

Roles are never rescinded because of inactivity, unless that inactivity is causing a problem for the project. Fortunately, our decision making process means that inactivity is very rarely a problem. Roles will be rescinded if the Project Management Committee (or PMC, see 2.4. below) believes the individual is no longer able to responsibly discharge the duty of the role.

We understand that you have many roles in life. We use a hat metaphor to talk about these roles. For instance, you might have your work hat as well as several ASF hats. We expect you to know when to wear the appropriate hat, and to comport yourself in a manner befitting the interests of the Foundation when interacting with the project. Failure to do this is a serious dereliction of duty.

Sometimes it is a good idea to tell people which hat you are wearing. For instance, the PMC Chair might start an informal email by stating they are not wearing the PMC Chair's hat, just to be clear about how the statements ought to be interpreted.

We expect you to act in good faith. This is very important for a community that depends so heavily on trust. @@ -146,8 +146,8 @@ "Extremely unhappy with this proposal." -1

There are three types of voting: informal, formal, and vetos. An informal vote is a quick way to get people's feelings on something. A formal vote, on the other hand, requires an approval model and a decision type. More detail on approval models, vetos and decision types is available in sections 3.4, 3.5., and 3.6. -

All formal voting must be done in an email thread with the appropriate subject tag. Formal votes may contain multiple items for approval and these should be clearly separated. Formal voting is then carried out by replying to the vote mail. Formal votes are open for a period of at least 72 hours to allow all active voters time to consider the vote. Votes can be held open longer than this at the discretion of the person who initiated the vote. -

Votes on PMC decisions are binding if they are cast by a PMC member. For all other purposes, votes are binding if they are cast by a committer. However, it is important to remember that all participants on a list get a vote. And you are encouraged to vote, even if your vote is not binding. This is a good way to get involved in the project and helps to inform the decision-making process. +

All formal voting must be done in an email thread with the appropriate subject tag. Formal votes may contain multiple items for approval and these should be clearly separated. Formal voting is then carried out by replying to the vote mail. Formal votes are open for a period of at least 72 hours to allow all active voters time to consider the vote. Votes can be held open longer than this at the discretion of the person who initiated the vote. +

Votes on PMC decisions are binding if they are cast by a PMC member. For all other purposes, votes are binding if they are cast by a committer. However, it is important to remember that all participants on a list get a vote. And you are encouraged to vote, even if your vote is not binding. This is a good way to get involved in the project and helps to inform the decision-making process.

You are encouraged to use an informal voting model to take a quick poll or to wrap up a discussion, whether you are a committer yet or not. These votes are informal and can be initiated by anyone. Binding votes are only needed for project-level decision-making.

3.4. Approval Models

We use four different approval models for formal voting: Modified: couchdb/site/bylaws.v2.html URL: http://svn.apache.org/viewvc/couchdb/site/bylaws.v2.html?rev=1615244&r1=1615243&r2=1615244&view=diff ============================================================================== --- couchdb/site/bylaws.v2.html (original) +++ couchdb/site/bylaws.v2.html Fri Aug 1 21:55:44 2014 @@ -6,7 +6,7 @@

Table of Contents

TODO

1. Introduction

-

This document defines the bylaws under which the Apache CouchDB project operates. It defines the roles and responsibilities within the project, who may vote, how voting works, how conflicts are resolved, and voting rules for specific decision types. +

This document defines the bylaws under which the Apache CouchDB project operates. It defines the roles and responsibilities within the project, who may vote, how voting works, how conflicts are resolved, and voting rules for specific decision types.

This document is written for anyone who wishes to participate in the project. If this is your first time through this document, read this introduction, then read all the bolded text for a summary of the bylaws. Then, as you need more detail, read past the bolded text for an expanded explanation.

CouchDB is a project of the Apache Software Foundation (ASF). Apache CouchDB, CouchDB, and the CouchDB logo are trademarks of the ASF. The project resources are licensed to the public under the Apache License 2.0. Releases are made in the form of official signed source code archives. The ASF FAQ explains the operation and background of the Foundation.

CouchDB operates under a set of common principles known collectively as the Apache Way: @@ -25,7 +25,7 @@

2. Roles and Responsibilities

The ASF defines 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.

Your role is bestowed on you by your peers in recognition of your past contributions to the project and your position of trust within the community. It is not tied to your job, your current employer, or your current activity level. We are interested in you as an individual and we understand that your interactions with the project may change over time. -

Roles are never rescinded because of inactivity, unless that inactivity is causing a problem for the project. Fortunately, our decision making process means that inactivity is very rarely a problem. Roles will be rescinded if the Project Management Committee (or PMC, see 2.4. below) believes the individual is no longer able to responsibly discharge the duty of the role. +

Roles are never rescinded because of inactivity, unless that inactivity is causing a problem for the project. Fortunately, our decision making process means that inactivity is very rarely a problem. Roles will be rescinded if the Project Management Committee (or PMC, see 2.4. below) believes the individual is no longer able to responsibly discharge the duty of the role.

We understand that you have many roles in life. We use a hat metaphor to talk about these roles. For instance, you might have your work hat as well as several ASF hats. We expect you to know when to wear the appropriate hat, and to comport yourself in a manner befitting the interests of the Foundation when interacting with the project. Failure to do this is a serious dereliction of duty.

Sometimes it is a good idea to tell people which hat you are wearing. For instance, the PMC Chair might start an informal email by stating they are not wearing the PMC Chair's hat, just to be clear about how the statements ought to be interpreted.

We expect you to act in good faith. This is very important for a community that depends so heavily on trust. @@ -79,15 +79,15 @@

This section explains our approach to decision making and the formal structures we have in place to make this as easy as possible.

In descending order of preference, we prefer that decisions are made via:

+
  • Lazy consensus or RTC +
  • Discussion-led consensus gathering +
  • Formal voting

    Our goal is to build a community of trust, reduce mailing list traffic, and deal with disagreements swiftly when they occur.

    All decision making must happen on the mailing lists. Any discussion that takes place away from the lists (for example on IRC or in person) must be brought to the lists before anything can be decided. We have a saying: if it's not on the lists, it didn't happen. We take this approach so that the greatest amount of people have a chance to participate.

    Decisions should be made on the mailing list associated with the decision. For example, marketing decisions happen on the marketing list. By default, anything without a specific list should be done in public on the main development list. Anything that needs to be private will be done on the private list.

    Our decision making processes are designed to reduce blockages. It is understood that people come and go as time permits. It is not practical to hear from everybody on every decision. Sometimes, this means a decision will be taken while you are away from the project. It is reasonable to bring such decisions up for discussion again, but this should be kept to a minimum.

    3.1. Lazy Consensus

    -

    When you are convinced that you know what the community would like to see happen, you can assume that you already have permission and get on with the work. We call this lazy consensus. You don't have to insist that people discuss or approve your plan, and you certainly don't need to call a vote. Just assume your plan is okay unless someone says otherwise. This applies to anything in the list of decision types in section 3.6. where lazy consensus is allowed. +

    When you are convinced that you know what the community would like to see happen, you can assume that you already have permission and get on with the work. We call this lazy consensus. You don't have to insist that people discuss or approve your plan, and you certainly don't need to call a vote. Just assume your plan is okay unless someone says otherwise. This applies to anything in the list of decision types in section 3.6. where lazy consensus is allowed.

    "It's easier to ask forgiveness than it is to get permission." — Grace Hopper

    Most actions are reversible. As long as you do your work in the open, the community has plenty of opportunities to object. If someone does object, you must be prepared to roll back your work.

    Lazy consensus has two effects: @@ -146,9 +146,9 @@ -1000 "Extremely unhappy with this proposal." -1 -

    There are three types of voting: informal, formal, and vetos. An informal vote is a quick way to get people's feelings on something. A formal vote, on the other hand, requires an approval model and a decision type. More detail on approval models, vetos, and decision types is available in sections 3.4, 3.5., and 3.6 respectively. -

    All formal voting must be done in an email thread with the appropriate subject tag. Formal votes may contain multiple items for approval and these should be clearly separated. Formal voting is then carried out by replying to the vote mail. Formal votes are open for a period of at least 72 hours to allow all active voters time to consider the vote. Votes can be held open longer than this at the discretion of the person who initiated the vote. -

    Votes on PMC decisions are binding if they are cast by a PMC member. For all other purposes, votes are binding if they are cast by a committer. However, it is important to remember that all participants on a list get a vote. And you are encouraged to vote, even if your vote is not binding. This is a good way to get involved in the project and helps to inform the decision-making process. +

    There are three types of voting: informal, formal, and vetos. An informal vote is a quick way to get people's feelings on something. A formal vote, on the other hand, requires an approval model and a decision type. More detail on approval models, vetos, and decision types is available in sections 3.4, 3.5., and 3.6 respectively. +

    All formal voting must be done in an email thread with the appropriate subject tag. Formal votes may contain multiple items for approval and these should be clearly separated. Formal voting is then carried out by replying to the vote mail. Formal votes are open for a period of at least 72 hours to allow all active voters time to consider the vote. Votes can be held open longer than this at the discretion of the person who initiated the vote. +

    Votes on PMC decisions are binding if they are cast by a PMC member. For all other purposes, votes are binding if they are cast by a committer. However, it is important to remember that all participants on a list get a vote. And you are encouraged to vote, even if your vote is not binding. This is a good way to get involved in the project and helps to inform the decision-making process.

    You are encouraged to use an informal voting model to take a quick poll or to wrap up a discussion, whether you are a committer yet or not. These votes are informal and can be initiated by anyone. Binding votes are only needed for project-level decision-making.

    3.4. Approval Models

    We use three different approval models for formal voting: