couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Vatamaniuc <vatam...@gmail.com>
Subject Re: [VOTE] Bylaws change: Establish a Request For Comments (RFC) process for major new contribution (revised)
Date Wed, 06 Mar 2019 21:45:32 GMT
+1

On Wed, Mar 6, 2019 at 1:36 PM Andy Wenk <andywenk@apache.org> wrote:

> +1
>
> > On 6. Mar 2019, at 10:41, Jan Lehnardt <jan@apache.org> wrote:
> >
> > +1
> >
> >> On 5. Mar 2019, at 21:18, Joan Touzet <wohali@apache.org> wrote:
> >>
> >> (Revised: The Reply-To field on the last email was incorrect. I am
> >> also including the diff of the proposed changes to this email per
> >> request.)
> >>
> >> ------------
> >>
> >> PMC Members,
> >>
> >> This is a VOTE to create or amend our official documents.
> >>
> >> It establishes a new Request For Comments (RFC) process through which
> >> all major changes to Apache CouchDB must pass.
> >>
> >> This includes modifying the Bylaws to explain the process, as well as
> >> adding the new RFC template.
> >>
> >> There are also minor changes proposed to the Bylaws to improve links to
> >> external information resources, such as the new Pony Mail mailing list
> >> interface.
> >>
> >> The git branch with the proposed changes is here:
> >>
> >> https://github.com/apache/couchdb-www/compare/asf-site...add-rfc
> >>
> >> Two commits have been used to make it clearer which changes are purely
> >> cosmetic, and which directly affect the text of the bylaws.
> >>
> >> An important note: this vote explicitly excludes the mechanics of the
> >> process in GitHub, focusing only on the proposal and voting procedures.
> >> (Whether we store the RFCs in our main tree or the docs tree, and
> >> whether we use issues or PRs for them don't have to go in the bylaws.)
> >>
> >> Per our process, this vote occurs on the Main development list (dev@),
> >> and requires a Lazy 2/3 majority, meaning it requires three binding +1
> >> votes and twice as many binding +1 votes as binding -1 votes. Only PMC
> >> Members can vote on this issue, and no veto is allowed.
> >>
> >> This vote will run for one week, ending on 12 March 2019 23:59 UTC.
> >>
> >> -Joan
> >>
> >>
> >> ---------------------------------------------------
> >>
> >> diff --git a/bylaws.html b/bylaws.html
> >> index 77ad2c0..4aea136 100644
> >> --- a/bylaws.html
> >> +++ b/bylaws.html
> >> @@ -8,7 +8,8 @@
> >>
> >> <h1>CouchDB Bylaws</h1>
> >>
> >> -<p><em>This document was officially adopted by the CouchDB PMC
as of
> 31 July 2014.</em>
> >> +<p><em>This document was officially adopted by the CouchDB PMC
as of
> 31 July 2014.</em></p>
> >> +<p>A full changelog is available <a href="
> https://github.com/apache/couchdb-www/commits/asf-site/bylaws.html">on
> GitHub</a>.</p>
> >>
> >> <h2>Table of Contents</h2>
> >>
> >> @@ -35,7 +36,7 @@
> >>
> >> <p>We value the community more than the code. A strong and healthy
> community should be a fun and rewarding place for everyone involved. Code,
> and everything else that goes with that code, will be produced by a healthy
> community over time.
> >>
> >> -<p>The direction of the project and the decisions we make are up to
> you. If you are participating on <a href="
> https://mail-archives.apache.org/mod_mbox/#couchdb">the mailing lists</a>
> you have the right to make decisions. All decisions about the project are
> taken on the mailing lists. There are no lead developers, nor is there any
> one person in charge.
> >> +<p>The direction of the project and the decisions we make are up to
> you. If you are participating on <a href="
> https://couchdb.apache.org/#mailing-lists">the mailing lists</a> you have
> the right to make decisions. All decisions about the project are taken on
> the mailing lists. There are no lead developers, nor is there any one
> person in charge.
> >>
> >> <p>Anyone can subscribe to the public mailing lists, and in fact, you
> are encouraged to do so. The development mailing list is not just for
> developers, for instance. It is for anyone who is interested in the
> development of the project. Everybody's voice is welcome.
> >>
> >> @@ -59,7 +60,7 @@
> >>
> >> <p><strong>The most important participants in the project are people
> who use our software.</strong>
> >>
> >> -<p>Users can participate by talking about the project, providing
> feedback, and helping others. This can be done at the ASF or elsewhere, and
> includes being active on <a href="
> https://mail-archives.apache.org/mod_mbox/couchdb-user/">the user mailing
> list</a>, third-party support forums, blogs, and social media. Users who
> participate in this way automatically become contributors.
> >> +<p>Users can participate by talking about the project, providing
> feedback, and helping others. This can be done at the ASF or elsewhere, and
> includes being active on <a href="
> https://lists.apache.org/list.html?user@couchdb.apache.org">the user
> mailing list</a>, third-party support forums, blogs, and social media.
> Users who participate in this way automatically become contributors.
> >>
> >>  <h3 id="contributors">2.2. Contributors</h3>
> >>
> >> @@ -152,9 +153,9 @@
> >>
> >> <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>All decision making must happen on <a href="
> https://couchdb.apache.org/#mailing-lists">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>Decisions should be made on the mailing list associated with the
> decision. For example, marketing decisions happen on <a href="
> https://lists.apache.org/list.html?marketing@couchdb.apache.org">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.
> >>
> >> @@ -177,7 +178,7 @@
> >>
> >> <p>For this to work properly, active committers are expected to be
> paying attention to the project. Objecting a long time after a change has
> been made may require large amounts of additional work to be thrown away or
> redone.
> >>
> >> -<p>Sometimes, you might not be sure what the community would want. If
> this is the case, you can post a note to the appropriate <a href="
> https://mail-archives.apache.org/mod_mbox/#couchdb">mailing list</a> with
> an outline of what you intend to do. If nobody objects after 72 hours, you
> can safely assume consensus and proceed with your plan.
> >> +<p>Sometimes, you might not be sure what the community would want. If
> this is the case, you can post a note to the appropriate <a href="
> https://couchdb.apache.org/#mailing-lists">mailing list</a> with an
> outline of what you intend to do. If nobody objects after 72 hours, you can
> safely assume consensus and proceed with your plan.
> >>
> >> <p>An important side effect of this policy is that <em>silence is
> assent</em>. There is no need for discussion, and no need for agreement to
> be voiced. If you make a proposal to the list and nobody responds, that
> should be interpreted as implicit support for your idea, and not a lack of
> interest. This can be hard to get used to, but is an important part of how
> we do things.
> >>
> >> @@ -251,7 +252,7 @@
> >>    </tr>
> >>  </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="#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>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">RTC and technical
> vetos</a>, <a href="#rfc">RFCs</a>, <a href="#api">API changes
and
> deprecations</a> and <a href="#types">decision types</a> is available
in
> the following sections.
> >>
> >> <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.
> >>
> >> @@ -286,11 +287,9 @@
> >>
> >> <p>For electing a new Chair, the PMC may opt to use <em>Single
> Transferable Vote</em> (STV) which comes with its own rules. <a href="
> http://steve.apache.org/">Apache STeVe</a> was specifically designed to
> enable this process.
> >>
> >> -<h3 id="rtc">3.5. Review-Then-Commit, API Changes and Technical
> Vetos</h3>
> >> +<h3 id="rtc">3.5. Review-Then-Commit and Technical Vetos</h3>
> >>
> >> -<p>Typically, CouchDB uses the <a href="
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit">Review-Then-Commit</a>
> (<em>RTC</em>) model of code collaboration. RTC allows work to proceed on
> separate feature or bugfix branches, and requires at least one other
> developer to review and approve the changes before they are committed to a
> release branch. A release branch is any branch that a release might be
> prepared from, such as <code>master</code>, <code>1.6.x</code>,
and so on.
> Notifications of these changes are sent to <a href="
> https://mail-archives.apache.org/mod_mbox/couchdb-commits/">the commits
> mailing list</a>. It is expected that the rest of the community is
> regularly reviewing these changes.
> >> -
> >> -<p>Whenever a change is proposed to a release branch or
> <code>master</code> that removes or changes an existing HTTP API endpoint
> in a way that breaks backwards compatibility with a released version of
> CouchDB, the proposed change <strong><em>must</em> be announced on
the
> developer mailing list, and a minimum of a <a href="#lazy">lazy
> consensus</a> decision is required.</strong> This policy is not intended
to
> preserve bugs in HTTP API endpoints across released versions of CouchDB in
> perpetuity, nor shall it be used to assert consistency of undocumented,
> implementation-specific behaviour across major releases. Additions of new
> endpoints, or changes that do not affect backwards compatibility, do not
> require this notification and process, but announcement to the developer
> mailing list is still strongly encouraged.</p>
> >> +<p>Typically, CouchDB uses the <a href="
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit">Review-Then-Commit</a>
> (<em>RTC</em>) model of code collaboration. RTC allows work to proceed on
> separate feature or bugfix branches, and requires at least one other
> developer to review and approve the changes before they are committed to a
> release branch. A release branch is any branch that a release might be
> prepared from, such as <code>master</code>, <code>1.6.x</code>,
and so on.
> Notifications of these changes are sent to <a href="
> https://lists.apache.org/list.html?commits@couchdb.apache.org">the
> commits mailing list</a>, with GitHub discussion appearing on <a href="
> https://lists.apache.org/list.html?notifications@couchdb.apache.org">the
> notifications mailing list</a>. It is expected that the rest of the
> community is regularly reviewing these changes.
> >>
> >> <p><strong>Any change made to a release branch or to the
> <code>master</code> branch is a <em>technical decision</em> of
the project.
> If a committer wants to object to a technical decision, they have the
> option of casting a -1 vote. We call this a veto.</strong> Vetos can only
> be made for technical reasons. A -1 vote is not considered a veto in any
> other context. Vetos should be used sparingly, and only after careful
> consideration.
> >>
> >> @@ -308,7 +307,25 @@
> >>
> >> <p>If the discussion did not reach consensus, Alice could challenge the
> validity of Bob's justification. At that point, the PMC would vote on the
> issue. If the PMC found that the justification was valid, Alice would have
> to revert the change or petition Bob to withdraw the veto. If the PMC found
> the justification invalid, the veto is null and void.
> >>
> >> -<h3 id="types">3.6. Decision Types</h3>
> >> +<h3 id="rfc">3.6 Request For Comment (RFC) process</h3>
> >> +
> >> +For major changes to the fuctionality of CouchDB, a Request For
> Comment (RFC) process has been established. The intent of an RFC is to
> ensure sufficient public discussion has occurred on the design of new
> features, that the proposal is adequately captured in a summary document,
> and that there is community acceptance of the proposal. The completed RFC
> template for the proposal then becomes the basis for the new
> functionality's documentation.
> >> +
> >> +The process is:
> >> +
> >> +  <ul>
> >> +    <li>Start a [DISCUSS] thread on <a href="
> https://lists.apache.org/list.html?dev@couchdb.apache.org">the developer
> mailing list</a>. Discuss your proposal in detail, including which
> modules/applications are affected, any HTTP API additions and deprecations,
> and security issues.</li>
> >> +    <li>When there is consensus on the approach from the community, <a
> href="https://s.apache.org/CouchDB-RFC">complete the RFC template</a> and
> work through any final revisions to the document, with the support of the
> developer mailing list.</li>
> >> +    <li>Start the RFC <strong>vote</strong> on the developer
mailing
> list. Hold the vote according to the <em>lazy majority process</em>: at
> least 3 +1 votes, and more binding +1 than binding -1 votes.</li>
> >> +  </ul>
> >> +
> >> +<h3 id="api">3.7 API changes and deprecations</h3>
> >> +
> >> +<p>Whenever a change is proposed to a release branch or
> <code>master</code> that removes or changes an existing HTTP API endpoint
> in a way that breaks backwards compatibility with a released version of
> CouchDB, the proposed change <strong><em>must</em> be announced on
<a href="
> https://lists.apache.org/list.html?dev@couchdb.apache.org">the developer
> mailing list</a>, and a minimum of a <a href="#lazy">lazy consensus</a>
> decision is required.</strong>
> >> +
> >> +<p>This policy is not intended to preserve bugs in HTTP API endpoints
> across released versions of CouchDB in perpetuity, nor shall it be used to
> assert consistency of undocumented, implementation-specific behaviour
> across major releases. Additions of new endpoints that fall short of the
> need for an RFC, or changes that do not affect backwards compatibility, do
> not require this notification and process, but announcement to the
> developer mailing list is still strongly encouraged.</p>
> >> +
> >> +<h3 id="types">3.8. Decision Types</h3>
> >>
> >> <p><strong>This section describes the various decision types and
the
> rules that apply to them.</strong></p>
> >>
> >> @@ -326,12 +343,22 @@
> >>    <tr>
> >>      <td>Technical decision
> >>      <td>A technical decision is any change made to a release branch.
> >> -      <td><a href="
> https://mail-archives.apache.org/mod_mbox/couchdb-commits/">Commits
> list</a>
> >> +      <td><a href="
> https://lists.apache.org/list.html?commits@couchdb.apache.org">Commits
> list</a>
> >>      <td>Allowed for trivial changes
> >>      <td>RTC
> >>      <td>No
> >>      <td>Committers
> >> -      <td> Yes
> >> +      <td>Yes
> >> +    </tr>
> >> +    <tr>
> >> +      <td>Request For Comments (RFC) decision
> >> +      <td>A decision on a specific proposal to alter CouchDB in a
> significant way.
> >> +      <td><a href="
> https://lists.apache.org/list.html?dev@couchdb.apache.org">Main
> development list</a>
> >> +      <td>No
> >> +      <td>Lazy majority
> >> +      <td>No
> >> +      <td>Committers
> >> +      <td>No
> >>    </tr>
> >>    <tr>
> >>      <td>Non-technical decision
> >> @@ -354,7 +381,7 @@
> >>   <br>
> >>   <br>
> >>   A veto is only valid when it is justified with a sound technical
> argument.
> >> -      <td><a href="
> https://mail-archives.apache.org/mod_mbox/couchdb-dev/">Main development
> list</a>
> >> +      <td><a href="
> https://lists.apache.org/list.html?dev@couchdb.apache.org">Main
> development list</a>
> >>      <td>No
> >>      <td>Lazy 2/3 majority
> >>      <td>No
> >> @@ -368,7 +395,7 @@
> >>   <br>
> >>   <br>
> >>   Release candidates can be prepared by anyone.
> >> -      <td><a href="
> https://mail-archives.apache.org/mod_mbox/couchdb-dev/">Main development
> list</a>
> >> +      <td><a href="
> https://lists.apache.org/list.html?dev@couchdb.apache.org">Main
> development list</a>
> >>      <td>No
> >>      <td>Lazy majority
> >>      <td>No
> >> @@ -446,7 +473,7 @@
> >>    <tr>
> >>      <td>Create or amend official document
> >>      <td>Create or amend any document marked as official.
> >> -      <td><a href="
> https://mail-archives.apache.org/mod_mbox/couchdb-dev/">Main development
> list</a>
> >> +      <td><a href="
> https://lists.apache.org/list.html?dev@couchdb.apache.org">Main
> development list</a>
> >>      <td>No
> >>      <td>Lazy 2/3 majority
> >>      <td>No
> >
> > --
> > Professional Support for Apache CouchDB:
> > https://neighbourhood.ie/couchdb-support/
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message