From dev-return-48412-archive-asf-public=cust-asf.ponee.io@couchdb.apache.org Tue Mar 5 20:38:43 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 29A2E180648 for ; Tue, 5 Mar 2019 21:38:43 +0100 (CET) Received: (qmail 47611 invoked by uid 500); 5 Mar 2019 20:38:42 -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 47598 invoked by uid 99); 5 Mar 2019 20:38:42 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Mar 2019 20:38:42 +0000 Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 4DBC634D6 for ; Tue, 5 Mar 2019 20:38:41 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id D66D72202A for ; Tue, 5 Mar 2019 15:38:40 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute4.internal (MEProxy); Tue, 05 Mar 2019 15:38:40 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeefgddugeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdftohgsvghrthcupfgvfihsohhnfdcuoehrnhgvfihsohhn segrphgrtghhvgdrohhrgheqnecuffhomhgrihhnpehhthhtphgrphhirgguughithhioh hnshgrnhguuggvphhrvggtrghtihhonhhsrghnughsvggtuhhrihhthihishhsuhgvshdr lhhipdgvmhhplhhohigvrhdrlhhipdgrphgrtghhvgdrohhrghdpghhithhhuhgsrdgtoh hmnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrnhgvfihsohhnodhmvghsmhhtphgruhht hhhpvghrshhonhgrlhhithihqdelfeegvddtvdejvddqudduleegjedtjeejqdhrnhgvfi hsohhnpeeprghprggthhgvrdhorhhgsehfrghsthhmrghilhdrfhhmnecuvehluhhsthgv rhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 842987C1EB; Tue, 5 Mar 2019 15:38:40 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5 X-Me-Personality: 93420272 Message-Id: <385f764b-f199-4b0e-90e7-18d7b5b899f4@www.fastmail.com> In-Reply-To: <815507211.3469.1551817183076.JavaMail.Joan@BRAIN> References: <815507211.3469.1551817183076.JavaMail.Joan@BRAIN> Date: Tue, 05 Mar 2019 15:37:52 -0500 From: "Robert Newson" To: dev@couchdb.apache.org Subject: =?UTF-8?Q?Re:_[VOTE]_Bylaws_change:_Establish_a_Qualified_Lazy_Majority_?= =?UTF-8?Q?vote_type_for_the_RFC_process=09(revised)?= Content-Type: text/plain -1 for the following reason: "https://apache.org/foundation/how-it-works.html#hats INDIVIDUALS COMPOSE THE ASF All of the ASF including the board, the other officers, the committers, and the members, are participating as individuals. That is one strength of the ASF, affiliations do not cloud the personal contributions." The Qualified Lazy Majority explicitly links an individual contributors actions with their employee (where they have one) and therefore, in my opinion, presumes bad faith. I agree that some ASF projects appear to have been co-opted by a single company, that some people may believe this is true of CouchDB and this deserves a response. I would vote _for_ a bylaw change that addressed this head-on. For example, if we established a remedy for when this occurs (temporary or permanent suspension, for example) or a definition of what we would consider an occurrence. Obviously that is a hard problem and presumably the reason it hasn't yet been proposed. B. -- Robert Samuel Newson rnewson@apache.org On Tue, 5 Mar 2019, at 20:29, Joan Touzet 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 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 href="https://lists.apache.org/list.html?dev@couchdb.apache.org">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, href="https://s.apache.org/CouchDB-RFC">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. > href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main > development list > No > - Lazy majority > + Qualified lazy majority > No > Committers > No >