From dev-return-48411-archive-asf-public=cust-asf.ponee.io@couchdb.apache.org Tue Mar 5 20:29:14 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 3B17118067C for ; Tue, 5 Mar 2019 21:29:14 +0100 (CET) Received: (qmail 24804 invoked by uid 500); 5 Mar 2019 20:29:13 -0000 Mailing-List: contact dev-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 dev@couchdb.apache.org Received: (qmail 24736 invoked by uid 99); 5 Mar 2019 20:29:12 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Mar 2019 20:29:12 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 1D2401828C5 for ; Tue, 5 Mar 2019 20:29:12 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=6.31 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id IdBf1imecX1U for ; Tue, 5 Mar 2019 20:29:09 +0000 (UTC) Received: from smtp.justsomehost.net (smtp.justsomehost.net [204.11.51.157]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 8DCF95F433 for ; Tue, 5 Mar 2019 20:19:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.justsomehost.net (Postfix) with ESMTP id 5CDAA580070 for ; Tue, 5 Mar 2019 15:19:42 -0500 (EST) Received: from smtp.justsomehost.net ([127.0.0.1]) by localhost (smtp.justsomehost.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QXwKE35IWhuN for ; Tue, 5 Mar 2019 15:19:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.justsomehost.net (Postfix) with ESMTP id A6401582379 for ; Tue, 5 Mar 2019 15:19:41 -0500 (EST) X-Virus-Scanned: amavisd-new at smtp.justsomehost.net Received: from smtp.justsomehost.net ([127.0.0.1]) by localhost (smtp.justsomehost.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VEE-aX3UhuJ0 for ; Tue, 5 Mar 2019 15:19:41 -0500 (EST) Received: from smtp.justsomehost.net (smtp.justsomehost.net [204.11.51.157]) by smtp.justsomehost.net (Postfix) with ESMTP id 8B41D580070 for ; Tue, 5 Mar 2019 15:19:41 -0500 (EST) Date: Tue, 5 Mar 2019 15:19:41 -0500 (EST) From: Joan Touzet Reply-To: wohali@apache.org To: CouchDB Developers Message-ID: <815507211.3469.1551817183076.JavaMail.Joan@BRAIN> In-Reply-To: <50667209.3468.1551817114016.JavaMail.Joan@BRAIN> Subject: [VOTE] Bylaws change: Establish a Qualified Lazy Majority vote type for the RFC process (revised) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [204.11.51.157] X-Mailer: Zimbra 8.8.9_GA_3026 (Zimbra Desktop/7.3.1_13063_Windows) Thread-Index: /ivIu2B2elLZNL2J6MLYMZEv0qWFIA== Thread-Topic: Bylaws change: Establish a Qualified Lazy Majority vote type for the RFC process (revised) (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 Qualified Lazy Majority voting type, and amends the bylaws to use this new type for RFC votes only. This vote depends on the RFC vote passing. The git branch with the proposed further changes to the bylaws, beyond the RFC process itself, is here: https://github.com/apache/couchdb-www/compare/add-rfc...add-qualified-lazy-majority 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 4aea136..7503b88 100644 --- a/bylaws.html +++ b/bylaws.html @@ -262,7 +262,7 @@

3.4. Approval Models

-

We use three different approval models for formal voting: +

We use four different approval models for formal voting:

  • RTC (see section 3.5) @@ -273,6 +273,11 @@
    • Requires three binding +1 votes and more binding +1 votes than binding -1 votes
    +
  • Qualified lazy majority +
      +
    • Requires three binding +1 votes and more binding +1 votes than binding -1 votes +
    • In addition, at least one binding +1 vote must be from an individual not directly affiliated with the proposer's employer (if applicable) +
  • Lazy 2/3 majority
    • Requires three binding +1 votes and twice as many binding +1 votes as binding -1 votes @@ -281,6 +286,8 @@

      RTC is only ever used in the context of a code review or a pull request, and does not require a separate vote thread. Each of the other approval models requires a vote thread. +

      Qualified lazy majority is only used for the RFC process.

      +

      A -1 vote is never called a veto except when using the RTC approval model. This is because a single -1 vote never has the power to block a vote outside of RTC.

      Which approval model to use is dictated by the table in section 3.6. This is project policy, and can be changed by amending this document. @@ -316,7 +323,7 @@ The process is:

      • Start a [DISCUSS] thread on the developer mailing list. Discuss your proposal in detail, including which modules/applications are affected, any HTTP API additions and deprecations, and security issues.
      • When there is consensus on the approach from the community, complete the RFC template and work through any final revisions to the document, with the support of the developer mailing list.
        • -
      • Start the RFC vote on the developer mailing list. Hold the vote according to the lazy majority process: at least 3 +1 votes, and more binding +1 than binding -1 votes.
        • +
      • Start the RFC vote on the developer mailing list. Hold the vote according to the qualified lazy majority process: at least 3 +1 votes, more +1 than -1 votes, and at least one +1 vote must be from someone not directly affiliated with the proposer's employer.

      3.7 API changes and deprecations

      @@ -355,7 +362,7 @@ The process is: A decision on a specific proposal to alter CouchDB in a significant way. Main development list No - Lazy majority + Qualified lazy majority No Committers No