Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74288
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.240 as permitted sender)
Content-Type: multipart/alternative; boundary="Apple-Mail=_35D11FBE-1130-44F0-A978-4640BEB73F23"
Message-ID: <A3E9D7E0-5C10-48AD-B141-F3D72B74A235@ajf.me>
Date: Sat, 17 May 2014 19:57:11 +0100
To: PHP internals <internals@lists.php.net>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Subject: Proposal to increase the required majority for all RFCs
From: ajf@ajf.me (Andrea Faulds)

--Apple-Mail=_35D11FBE-1130-44F0-A978-4640BEB73F23
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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 =
current voting rules[1].

Currently only 50%+1, a simple majority, is required to pass =
=91non-language changes=92. However, I feel that this is too small of a =
hurdle to pass. 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 and hence don=92t need wide approval. However, =
changes which don=92t affect the =91language=92 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 =
=91language=92 and what doesn=92t.

Hence, I propose that we require a supermajority of 2/3 to pass RFC =
votes. This system is currently used for =91language=92 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 =
than a 2/3 majority, and so would not have been stopped by this hurdle. =
Also, I=92m not sure it is fair if =91progress=92 happens when there is =
not broad consensus on an issue.

There is not yet an RFC for this, as I want to discuss the concept =
first. I=92d also rather not talk about other aspects of voting reform =
in this thread if possible, such as waiting periods or what karma is =
needed to vote, so I would ask that you please make a separate thread =
for that.

Thanks!

[0] irc://irc.efnet.org/#php.pecl
[1] https://wiki.php.net/rfc/voting
--
Andrea Faulds
http://ajf.me/





--Apple-Mail=_35D11FBE-1130-44F0-A978-4640BEB73F23--