couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nsla...@apache.org
Subject svn commit: r1615244 - in /couchdb/site: bylaws.v1.html bylaws.v2.html
Date Fri, 01 Aug 2014 21:55:45 GMT
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 @@
 <h1 id="roles">2. Roles and Responsibilities</h1>
 <p><strong>The ASF <a href="https://www.apache.org/foundation/how-it-works.html#roles">defines
a set of roles</a> 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.</strong>
 <p>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.
-<p>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 <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Project+Bylaws#ProjectBylaws-ProjectBylaws(WIP)-2.4.ProjectManagementCommittee">Project
Management Committee</a> (or <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Project+Bylaws#ProjectBylaws-ProjectBylaws(WIP)-2.4.ProjectManagementCommittee">PMC</a>,
see 2.4. below) believes the individual is no longer able to responsibly discharge the duty
of the role.
+<p>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 <a href="#pmc">Project Management
Committee</a> (or <a href="#pmc">PMC</a>, see 2.4. below) believes the individual
is no longer able to responsibly discharge the duty of the role.
 <p>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.
 <p>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.
 <p>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 @@
 <td colspan="1">"Extremely unhappy with this proposal."
 <td colspan="1">-1</table>
 <p>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.
-<p>All formal voting must be done in an email thread with the appropriate <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Project+Bylaws#ProjectBylaws-4.1.SubjectTags">subject
tag</a>. 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.
-<p>Votes on <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Project+Bylaws#ProjectBylaws-ProjectBylaws(WIP)-3.6.DecisionTypes">PMC
decisions</a> 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.
+<p>All formal voting must be done in an email thread with the appropriate <a href="#tags">subject
tag</a>. 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.
+<p>Votes on <a href="#types">PMC decisions</a> 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.
 <p>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.
 <h2 id="approval">3.4. Approval Models</h2>
 <p><strong>We use four different approval models for formal voting</strong>:

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 @@
 <h1 id="toc">Table of Contents</h1>
 <p>TODO
 <h1 id="intro">1. Introduction</h1>
-<p>This document defines the bylaws under which the Apache CouchDB project operates.
It defines the <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-2.RolesandResponsibilities">roles
and responsibilities</a> within the project, who may vote, how <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.3.Voting">voting</a>
works, how conflicts are resolved, and voting rules for specific <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.6.DecisionTypes">decision
types</a>.
+<p>This document defines the bylaws under which the Apache CouchDB project operates.
It defines the <a href="#roles">roles and responsibilities</a> within the project,
who may vote, how <a href="#voting">voting</a> works, how conflicts are resolved,
and voting rules for specific <a href="#types">decision types</a>.
 <p>This document is written for anyone who wishes to participate in the project. <strong>If
this is your first time through this document, read this introduction, then read all the bolded
text</strong> <strong>for a summary of the bylaws.</strong> Then, as you
need more detail, read past the bolded text for an expanded explanation.
 <p>CouchDB is a project of the <em>Apache Software Foundation</em> (ASF).
Apache CouchDB, CouchDB, and the CouchDB logo are trademarks of the ASF. The project resources
are licensed to the public under the <a href="http://www.apache.org/licenses/LICENSE-2.0.html">Apache
License 2.0</a>. Releases are made in the form of official signed source code archives.
The <a href="https://www.apache.org/foundation/faq.html">ASF FAQ</a> explains
the operation and background of the Foundation.
 <p>CouchDB operates under a set of common principles known collectively as <a href="https://www.apache.org/foundation/how-it-works.html">the
Apache Way</a>:
@@ -25,7 +25,7 @@
 <h1 id="roles">2. Roles and Responsibilities</h1>
 <p><strong>The ASF <a href="https://www.apache.org/foundation/how-it-works.html#roles">defines
a set of roles</a> 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.</strong>
 <p>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.
-<p>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 <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-2.4.ProjectManagementCommittee">Project
Management Committee</a> (or <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-2.4.ProjectManagementCommittee">PMC</a>,
see 2.4. below) believes the individual is no longer able to responsibly discharge the duty
of the role.
+<p>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 <a href="#pmc">Project Management
Committee</a> (or <a href="#pmc">PMC</a>, see 2.4. below) believes the individual
is no longer able to responsibly discharge the duty of the role.
 <p>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.
 <p>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.
 <p>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 @@
 <p>This section explains our approach to decision making and the formal structures
we have in place to make this as easy as possible.
 <p><strong>In descending order of preference, we prefer that decisions are made
via:</strong>
 <ul>
-<li><strong><a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.1.LazyConsensus">Lazy
consensus</a> or <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.5.RTCandVetos">RTC</a></strong>
-<li><strong><a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.2.Discussion">Discussion-led
consensus gathering</a></strong>
-<li><strong><a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.3.Voting">Formal
voting</a></strong></ul>
+<li><strong><a href="#lazy">Lazy consensus</a> or <a href="#rtc">RTC</a></strong>
+<li><strong><a href="#discussions">Discussion-led consensus gathering</a></strong>
+<li><strong><a href="#voting">Formal voting</a></strong></ul>
 <p>Our goal is to build a community of trust, reduce mailing list traffic, and deal
with disagreements swiftly when they occur.
 <p>All decision making must happen on <a href="https://mail-archives.apache.org/mod_mbox/#couchdb">the
mailing lists</a>. 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.
 <p>Decisions should be made on the mailing list associated with the decision. For example,
marketing decisions happen on <a href="https://mail-archives.apache.org/mod_mbox/couchdb-marketing/">the
marketing list</a>. 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.
 <p>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.
 <h2 id="lazy">3.1. Lazy Consensus</h2>
-<p><strong>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.</strong>
<strong>We call this <a href="http://www.apache.org/foundation/glossary.html#LazyConsensus">lazy
consensus</a>.</strong> 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 <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.6.DecisionTypes">decision
types</a> in section 3.6. where lazy consensus is allowed.
+<p><strong>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.</strong>
<strong>We call this <a href="http://www.apache.org/foundation/glossary.html#LazyConsensus">lazy
consensus</a>.</strong> 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 <a href="#types">decision
types</a> in section 3.6. where lazy consensus is allowed.
 <p>"It's easier to ask forgiveness than it is to get permission." — Grace Hopper
 <p>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.
 <p>Lazy consensus has two effects:
@@ -146,9 +146,9 @@
 <td colspan="1">-1000
 <td colspan="1">"Extremely unhappy with this proposal."
 <td colspan="1">-1</table>
-<p>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 <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Project+Bylaws"
>decision type</a>. More detail on <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.4.ApprovalModels">approval
models</a>, <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.5.RTCandVetos">vetos</a>,
and <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.6.DecisionTypes">decision
types</a> is available in sections 3.4, 3.5., and 3.6 respectively.
-<p>All formal voting must be done in an email thread with the appropriate <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-4.1.SubjectTags">subject
tag</a>. 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.
-<p>Votes on <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.6.DecisionTypes">PMC
decisions</a> 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.
+<p>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 <a href="#decisions">decision type</a>. More detail on
<a href="#approval">approval models</a>, <a href="#rtc">vetos</a>,
and <a href="types">decision types</a> is available in sections 3.4, 3.5., and
3.6 respectively.
+<p>All formal voting must be done in an email thread with the appropriate <a href="#tags">subject
tag</a>. 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.
+<p>Votes on <a href="types">PMC decisions</a> 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.
 <p>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.
 <h2 id="approval">3.4. Approval Models</h2>
 <p><strong>We use three different approval models for formal voting</strong>:



Mime
View raw message