Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103950
MIME-Version: 1.0
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> <CAKOpQSwTneMrNnN=RAKUU2uU5JVEUoJkXwuO_5ymxBarBJNR7Q@mail.gmail.com>
 <CAJHtznwtMDyQg5gvUjmEzfVqGOjnm-3neq=tPJxUbamPub=4ng@mail.gmail.com>
In-Reply-To: <CAJHtznwtMDyQg5gvUjmEzfVqGOjnm-3neq=tPJxUbamPub=4ng@mail.gmail.com>
Reply-To: bishop@php.net
Date: Thu, 31 Jan 2019 14:28:00 -0500
Message-ID: <CAEYWF=7fCDBv8M1XUi865Dn92p4CA8w+DviFfcWwC5GfijEQ9A@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b4fbde0580c607d9"
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: bishop@php.net (Bishop Bettini)

--000000000000b4fbde0580c607d9
Content-Type: text/plain; charset="UTF-8"

On Thu, Jan 31, 2019 at 9:07 AM Zeev Suraski <zeev@php.net> wrote:

> On Thu, Jan 31, 2019 at 3:53 PM Kris Craig <kris.craig@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

--000000000000b4fbde0580c607d9--