Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74321 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5716 invoked from network); 17 May 2014 23:48:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 May 2014 23:48:47 -0000 Authentication-Results: pb1.pair.com header.from=kris.craig@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=kris.craig@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.51 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 209.85.192.51 mail-qg0-f51.google.com Received: from [209.85.192.51] ([209.85.192.51:46386] helo=mail-qg0-f51.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D5/E1-28415-E55F7735 for ; Sat, 17 May 2014 19:48:46 -0400 Received: by mail-qg0-f51.google.com with SMTP id q107so6546865qgd.24 for ; Sat, 17 May 2014 16:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k2XXxdQHpUw6UNSrpE7EJmHqfIlGFb4CuVO1RtDqYyQ=; b=kjK48+iA099gpo0CkTUuMAz8QFom+KMWdpP8/MxHa9J27ImJFxdj3GfB78Jo6kHI9A jnRKhK4dAP3WOZhO1+dS8fwXtb1HH4xwJGUsitglNNqgboKYKTlOS0SmNJ/aV61U5TsW ONmRKrR/DxIKHb5NFx9kXgsh7r/mwouBYMl252rJq565RMthlU+MJApCEWBPYAH1NrcF kfX2xvExw84X7qPNJFTO4s0lE2EXRES8KGJDiU/v1QHMnBZamR7fPwjJ0Kjd1oOxzvul vDMLy2xYCrj421F6GlksHZd27yl3m5x7nf3RdPlzzvbQV5p9/p60723tsPPi/caWNWDX H50w== MIME-Version: 1.0 X-Received: by 10.224.169.6 with SMTP id w6mr35508050qay.102.1400370523459; Sat, 17 May 2014 16:48:43 -0700 (PDT) Received: by 10.140.88.164 with HTTP; Sat, 17 May 2014 16:48:43 -0700 (PDT) In-Reply-To: References: Date: Sat, 17 May 2014 16:48:43 -0700 Message-ID: To: Andrea Faulds Cc: PHP internals Content-Type: multipart/alternative; boundary=089e0160c2309ad62204f9a12bb0 Subject: Re: [PHP-DEV] Proposal to increase the required majority for all RFCs From: kris.craig@gmail.com (Kris Craig) --089e0160c2309ad62204f9a12bb0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, May 17, 2014 at 11:57 AM, Andrea Faulds wrote: > Good evening, > > Given the recent controversy on the 64-bit patch vote, and after some > discussions on IRC[0] with some others, I think we should amend the curre= nt > voting rules[1]. > I agree that they need to be amended, but.... > > Currently only 50%+1, a simple majority, is required to pass =E2=80=98non= -language > changes=E2=80=99. However, I feel that this is too small of a hurdle to p= ass. Under > this rule, contentious changes can pass despite a very thin majority. The > rationale seems to be that non-language changes have less broad effect an= d > hence don=E2=80=99t need wide approval. However, changes which don=E2=80= =99t affect the > =E2=80=98language=E2=80=99 can still have wide-ranging effect and be very= problematic. It > is also a quite vague requirement, as it is not always clear what change > affects the =E2=80=98language=E2=80=99 and what doesn=E2=80=99t. > > Hence, I propose that we require a supermajority of 2/3 to pass RFC votes= . > This system is currently used for =E2=80=98language=E2=80=99 votes, but I= feel it ought to > extend to everything. This a much bigger hurdle to climb over than only a > simple majority, but it means that only changes with broad consensus are > likely to pass. It also means that the results of a vote will be less > contentious, as there need to be at least twice as many votes in favour > than against for it to pass. Finally, this change would mean there would = be > no interpretation issues as to what constitutes a language change, as all > changes must meet the same bar. > > To those who say this might impede progress, I would like to point out > that every single RFC accepted for PHP 5.6 so far was accepted by more th= an > a 2/3 majority, and so would not have been stopped by this hurdle. Also, > I=E2=80=99m not sure it is fair if =E2=80=98progress=E2=80=99 happens whe= n there is not broad > consensus on an issue. > Requiring a supermajority for every single change wouldn't impede routine progress, but it would impede meaningful progress. Why? Because it would essentially prevent us from making a collective decision on any contentious issue. Just look at the United States Senate. They can't get anything done because a 60% supermajority is required on just about everything now that the filibuster has become routine. It's frustrating when 59% votes in favor of a routine funding bill and it still fails. What you're talking about would be an even greater hurdle, 2/3. Now I will concede that, thankfully, we tend to get along better than members of the U.S. Senate, but we're still human and we're still going to have heated disagreements on issues that need to be addressed. If we start having RFCs failing with 65% in favor of passage, that would have a paralyzing effect and we'd risk falling into the same trap that befell the Senate. They weren't always this dysfunctional. It used to be that 60% was only required for major things with wider implications. Stuff actually got done back then. Just like stuff gets done now in PHP. If we go to a 2/3-only model, we'll make it impossible to make any collective executive decisions on controversial matters. It's arbitrary (why 2/3 and not 60% or 55%?), ignores the will of the majority, and is simply not sustainable. A much better solution would be to amend the voting RFC to provide more clarity as to when 2/3 is required and when it's not. The current language is too vague and open to interpretation. --Kris --089e0160c2309ad62204f9a12bb0--