On Thu, Jan 31, 2019 at 9:07 AM Zeev Suraski <z...@php.net> wrote: > On Thu, Jan 31, 2019 at 3:53 PM Kris Craig <kris.cr...@gmail.com> wrote: > > > I think you may be over-reaching a bit on the eligible voters part. Keep > > in mind that all those who would be affected would still be able to vote > on > > this RFC. I think it's too restrictive on that part. > > > > I realized that this part of the RFC is likely to be challenging. I'm open > to additional ideas (or tweaking of existing ones) - but at the same time, > I think the current situation is not sustainable - nor can I think about > any other (large) Open Source project that employs anything similar. > Today, any person can become a voter, with identical rights to long time, > committed contributors - virtually overnight, with very little (or > virtually no) commitment on their part. Open Source project governance > tends to be a meritocracy - and even this proposal sets a fairly low bar to > having the very same voting rights as Rasmus, me, Nikita or Dmitry. Again, > I'm very open to ideas on how to improve on it, it's not an easy task to > tackle. >
I favor changing how we vote, but I disagree with the proposed unilateral vote stripping. As requested, I will offer an idea. We have two disparate groups contributing to PHP. One the one hand, we have the "core developers" who disproportionally carry the most burden to build and maintain the source. On the other hand, we have "the community" who consume, organize, and evangelize PHP (and who may, or may not, commit). Both of these groups change over time. What outcomes do we desire? - A change Wanted by the simple majority of Both core developers and the community should Pass. - A change Unwanted by the simple majority of Both should Fail. - We require a higher standard of consensus when the majority of Either cannot agree. I counter-propose the following voting rules, modeled after Robert's Rules for voice and rising votes, which encourages a wider audience to join and vote or to strive to contribute more to the engine: 1. Anyone can register as a community member, and can vote on any RFC as a community member. 2. Core developers are defined as the top 13 committers within the period of two years since voting began. A core developer is a de facto community member, but caucuses as a core developer. 3. Voting occur in rounds. 4. Round one is the opening vote. If the simple majority of both parties consents, the vote passes. If the simple majority of both parties dissents, the vote fails. In either of these cases, the vote ends as consensus has been reached. 5. Round two occurs when there is disagreement between parties. In this round, a 2/3 super-majority consent from one party carries the vote, unless there is a 2/3 super-majority dissent from the other party. If carried, the vote ends as "sufficient" consensus has been reached. 6. Round three occurs when there is "excessive" disagreement on the topic. In this round, the elected tie-breaking member shall cast the deciding vote. If there is no elected tie-breaking member in service, the vote fails. Administrative miscellany: 1. Core developers' vote requires a quorum. 2. Community members' voting does not require quorum. 3. Voting rounds are open for one week from the opening date time. If a round times out without decision, the vote fails. 4. The definition of core developers may itself be voted upon under these rules. 5. The tie-breaking member shall be elected every two years under these rules. I believe these rules respect the order we have now, while evening out the representation and raising the bar on contentious votes. As with Zeev's proposal, gone is the idea that RFC authors choose the bar, but instead of mandating 2/3, this proposal focuses on the idea of consensus, and what it means quantitatively. Added, as mentioned in Zeev's proposal as a Todo is quorum, which protects the language from changes snuck in without the explicit review of at least those who will be most responsible for it. Of course unlike Zeev's proposal this encourages more involvement from the community by saying "yes you have a vote". Diverse representation, quantitative consensus, and mandatory quorum work together to ensure we can continue collaboration under a rational framework where everyone's voice is recorded and the majority does become tyrannical. Thanks everyone for all you do and your consideration of this alternative, bishop
