Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104057
MIME-Version: 1.0
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> <CA+kxMuTpM=kfLFUtxRY57eWT3N6jx2A9m7MumbSDj=OPuXcdAA@mail.gmail.com>
 <CAJHtznyqZOribu8iyat0i6kQdyyoFEf_jy0GgRy2cH3GWMB4xg@mail.gmail.com>
In-Reply-To: <CAJHtznyqZOribu8iyat0i6kQdyyoFEf_jy0GgRy2cH3GWMB4xg@mail.gmail.com>
Date: Sun, 3 Feb 2019 00:16:10 -0800
Message-ID: <CAKOpQSwpX6Wbn=B9NrUmBK-QOy-fSaZcqso4EDe48eHEjW2W+A@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Dan Ackroyd <Danack@basereality.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004349880580f8fefe"
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: kris.craig@gmail.com (Kris Craig)

--0000000000004349880580f8fefe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 2, 2019 at 10:20 PM Zeev Suraski <zeev@php.net> wrote:

> On Fri, Feb 1, 2019 at 7:14 PM Dan Ackroyd <Danack@basereality.com> wrote=
:
>
> > On Thu, 31 Jan 2019 at 13:44, Zeev Suraski <zeev@php.net> wrote:
> > >
> > > Without further ado, an RFC that=E2=80=99s attempting to comprehensiv=
ely solve
> > many of the issues that have plagued our RFC process since it was hasti=
ly
> > introduced in 2011:
> >
> > Hi Zeev,
> >
> > Please can you very clearly state what problem you are trying to solve
> > by changing the rules about who can vote.
> >
> > Without presenting the problem, and why your solution is the correct
> > one, it's not obvious that the change being proposed is either needed
> > or the right one choice.
> >
>
> Fair enough, I've heard that question from several others.
>
> I'll use your email to clarify my motivation for the RFC, primarily on th=
e
> voting eligibility part - in slightly more detail than my reply to Nikita
> on the other thread.
>
> Beginning with the latter, the reality of things that the Voting RFC of
> 2011 was written in what was supposed to codify, and also structure a bit
> more the already existing process of decision making that we had prior to
> it.  The structuring was mainly through the introduction of a voting
> process, as well as some elements such as a mandatory discussion period.
> However, it quickly became apparent that this RFC, that was written with =
a
> certain 'working knowledge' of what was already happening de-facto, and
> assuming these would continue - became treated as if it was the U.S.
> constitution, and whatever wasn't in it - did not exist.  Moreover - even
> elements which were in fact in it (such as the voting eligibility), becam=
e
> ignored - exclusively for the simple reason of the way the Wiki software,
> used for voting, was implemented.
>
> Edge cases came up over the years in all sorts of manners.  The most rece=
nt
> edge case which isn't handled by the terse, laconic 2011 Voting RFC is th=
e
> Abolishing Narrow Margins RFC, which went straight from de-facto
> hibernation into a "we're about to vote" stage overnight.  But there were
> many others (and yes, one of the common ones was 'how do we choose betwee=
n
> 50%+1 and 2/3', but it was by no means the only one).  The goal here is t=
o
> provide clear cut answers to these cases, instead of leaving it up to the
> RFC author to decide.  Over the years, it became clear that RFC authors h=
ad
> not only the ability to decide what goes into the RFC, but to also decide
> much of the process surrounding the discussion and acceptance of the RFC =
-
> filling the major voids that were present in the terse 2011 Voting RFC on
> demand.
>
> In terms of Voting Eligibility, here's what was written in the original
> RFC:
>
> ---quote---
> There's no way around this 'small' issue. Changes made to the PHP languag=
e
> will affect millions of people, and theoretically, each and every one of
> them should have a say in what we do. For obvious reasons, though, this
> isn't a practical approach.
>
> The proposal here is for two audiences to participate in the voting
> process:
>
> - People with php.net VCS accounts that have contributed code to PHP:
> - Representatives from the PHP community, that will be chosen by those wi=
th
> php.net VCS accounts
>    - Lead developers of PHP based projects (frameworks, cms, tools, etc.)
>    - regular participant of internals discussions
> ---end quote---
>
> Now, there are several things you can tell from the way this topic is
> treated that are evident from this text.  First, that the topic of Voting
> Eligibility wasn't taken lightly, nor was there any intention to provide =
a
> very low bar on who gets to vote.  Secondly, which is a lot more
> unfortunate, it's very terse and laconic - like the rest of the RFC - e.g=
.,
> when stating how the folks from the the 2nd group of eligible voters will
> be chosen - even though it's evident that the idea was that they *will* b=
e
> chosen, in one way or another;  Heck, even the first group is open to
> interpretation from the way it's written (although the intention was clea=
r)
> - code contributors to PHP - was supposed to mean folks that truly
> contributed code to PHP, and not every person with a VCS account (it's
> clearly a subset, even from the poor way it's written).  Bear in mind tha=
t
> Pierre Joye, that promoted this RFC - believed that we will be able to
> figure these parts out as we go along.  De-facto, what happened was very
> different - overnight, because of the way the Wiki software was
> implemented, anybody with a VCS account became an eligible voter, with th=
e
> same weight as Rasmus, myself, Nikita, or whomever else.  This was never
> the intention.
>
> What was the intention?  In a nutshell:
> - Code contributors to php-src get a vote
> - Everyone with a VCS account (wider audience) get the ability to choose
> folks that are beyond the first group, that will also get a vote (with th=
e
> assumption that the number of folks elected in this way will not be nearl=
y
> as high as the number of folks with VCS accounts, and in fact, a lot lowe=
r
> than the first group of code contributors - essentially, it was to bring
> outside voices, but not effectively overtake and marginalize the voice of
> the code contributors).  Regrettably, how that was to take place was left
> out of that laconic RFC - in the belief that "we'll figure it out".
>
> The goal of the voting eligibility section in the updated RFC is to clari=
fy
> this.  It's clear we have more work to do in this front here - but ignori=
ng
> this elephpant in the room shouldn't be an option anymore.  It's just as
> important, and arguably a lot more important, than the voting thresholds.
> To me, the two are clearly interlinked, as is the potential question of a
> quorum.
>
> The barrier to obtaining a vote today is ridiculously low.  Mostly anybod=
y
> I spoke with that I shared how easy it was to get a vote that's equal to =
a
> person that's been contributing for years and has proven knowledge about
> PHP for ages - was shocked.  And indeed, our system where a person can
> become an eligible voter almost overnight has no parallels (to the best o=
f
> my knowledge) in any other major OS project.  Virtually all of them are
> some form of meritocracy, and yes, that's despite all of them having impa=
ct
> on millions of users.  The situation where an open source project effects
> millions of users isn't uncommon - it's standard in virtually all major O=
S
> projects - and yet, none of them makes it this easy to have voting rights=
,
> literally overnight, and with 100% equivalence to folks who have
> contributed for years - the way PHP de-facto does.
>
> We were *supposed* to be more advanced than other projects, by providing
> folks that aren't code contributors with a way to also influence votes -
> and I still think it's worth exploring ways of doing it.  But at no point
> was the intention to lower the bar so much, providing a vote for anybody
> with a VCS account (which is very, very easy to get) with a vote.  This i=
s
> unfair to ones who actually take the time and effort to work on the proje=
ct
> itself.
>
>
> Additionally, giving a vote to members of PHP-Fig is not a good idea
> > for multiple reasons.
> >
>
> I'm not sold on it being a good idea either, especially seeing the level =
of
> controversy it stirred here (by the way - it accounts for most of the
> controversy on this thread, as far as I can tell - I think that the gener=
al
> idea of voting eligibility was actually supported by many folks replying =
to
> this thread, mainly because it's common sense and is present in all other
> major OS projects).
>
> I think we need to either come up with a mechanism - that's reasonably
> well-defined - to bring the 'voice of the masses' into the voting process=
,
> that would not be biased towards one particular group - or we simply stic=
k
> with the first group only, with the reasonable assumption that they'll
> factor in what they hear from these masses during the discussion period a=
s
> they come to vote.  That's mostly how all other major OS projects work.
>
> Another option might be going back to elements in the 2011 RFC (while
> clearly clarifying it).  Perhaps, defining some sort of a voting/election
> process where code-contributors can elect non-code-contributors that will
> also have a vote is a way to go.  What I definitely don't want to repeat,
> though, is having open-ended definitions.
>
> I'll reply to more elements in this thread later tonight - had an unusual=
ly
> busy weekend...
>
> Zeev
>

I just want to reiterate that there are other good ideas in this RFC that
would probably pass easily.  I strongly urge you to move the voting to a
separate RFC.

--Kris

--0000000000004349880580f8fefe--