Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104220
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: Wed, 6 Feb 2019 12:44:09 +0700
Message-ID: <CAEZPtU5g2e=o-iurXe7HQktiMAOG3bk-2cKFVSEqWg4xTxsMpg@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Dan Ackroyd <Danack@basereality.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: pierre.php@gmail.com (Pierre Joye)

Good morning Zeev&al :)

Thanks you for this RFC. I think it is long due to get a status of
where we are, what we like to have and what we can improve. My
apologize for the long reply, and as I got a mention in this reply, I
felt the need to put my grain of salt in this discussion. I hope you
don't mind.

I am not sure it makes sense to have all in one RFC however I fully
agree that the time has come to know where we are and improve things.
I am trying to explain in this reply.

On Sun, Feb 3, 2019 at 1:19 PM Zeev Suraski <zeev@php.net> wrote:

> Fair enough, I've heard that question from several others.
>
> I'll use your email to clarify my motivation for the RFC, primarily on the
> voting eligibility part - in slightly more detail than my reply to Nikita
> on the other thread.

I think it would be better to clarify the RFC itself.


> 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.

Exactly.

The goal was also to streamline the introduction of features and
ensure a fully transparent decision can be taken. Mainly initiated by
some core developers and led by Lukas and myself to bring the 1st
version of the RFC process to life. It was cruelly required after the
6.0 fiasco and the long periods of no releases (ended by 5.3 and with
5.4 being the first release under the new rules).

> 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), became
> ignored - exclusively for the simple reason of the way the Wiki software,
> used for voting, was implemented.

I think it is a bit of an extreme comparison here. However some
strictness were required to actually get things done and stop the
(benevolent or not) dictatorship which has brought the core to its
knees, divisions and a very unhealthy environment on internals. This
were a very dark moment in PHP history. We have grown and I am so
happy to see that things have changed in so many ways since then
(thanks to all devs).


> Edge cases came up over the years in all sorts of manners.  The most recent
> edge case which isn't handled by the terse, laconic 2011 Voting RFC is the
> 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 between
> 50%+1 and 2/3', but it was by no means the only one).

This one was supposed to be clear (I will leave to the reader to go
through the archives), ala, it was not so clear after all. The 2/3
were about everything affecting the language, the core part of it. An
extension f.e. was not thought to be part of the language. But almost
anything under /Zend, ext/standard, main/ or stream would (or
similar). Now with massive changes in how the web is developed,
something considered as a core critical feature 10 years ago is
totally useless now. We need to adapt.

What is core and what is an extension need to be clarified and I would
suggest to have a specific discussion about that. This discussion
could also include:

1. Definition of the core and what we want to include into it.

2. how we include and remove extensions

3. Do we want to always bundle all these extensions? as in. Should we
not focus on the core language and use distribution mechanisms for
anyone willing to add more exts. The extensions remaining should then
be considered as part of the core because of the critical need for PHP
as a language. Reflection, Xml, Json, reflection for example are very
good candidates. Databases extensions on the other hand make less
sense and should deserver their own releases cycles (which is
happening already anyway).

I am not sure if it makes sense to be in the same RFC. Maybe easier to
have a separate discussions about that as well. More discussions, but
smaller, clearer RFCs very crystal clear goals and expectations.

> The goal here is to
> 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 had
> 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 language
> 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 with
> 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.

Agreed.

> Secondly, which is a lot more
> unfortunate, it's very terse and laconic - like the rest of the RFC - e.g.

The RFC was not laconic but was supposed to be clarified if needed or
desired, regular updates should have been done as we learned. We fail
on the latter part.

> 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* be
> 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 clear)

Absolutely, this needs clarifications.

> - 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 that
> 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 the
> same weight as Rasmus, myself, Nikita, or whomever else.  This was never
> the intention.

This should not have happened. Also please note that, as I would
gladly take the honor of it, I was not alone. Lukas and other (either
listed or in the background) did it.

By the way, I would greatly appreciate that we acknowledge the
benefits the RFC (and the 1st RFC about release process) gave to PHP,
even with its flaws and our failure to follow up in a timely manner.

> What was the intention?  In a nutshell:
> - Code contributors to php-src get a vote

Indeed.

> - 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 the
> assumption that the number of folks elected in this way will not be nearly
> as high as the number of folks with VCS accounts, and in fact, a lot lower
> 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".

We fail to follow up, for 7 years. I will take the blame personally as well.

PS: may I suggest to remove this negativity and rough rhetoric, they
are neither actual nor bringing the discussion anywhere.

> The barrier to obtaining a vote today is ridiculously low.

Agreed.

> Mostly anybody
> 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.

I have different feedback, while everyone agrees that there should be
better rules.

> And indeed, our system where a person can
> become an eligible voter almost overnight has no parallels (to the best of
> my knowledge) in any other major OS project.

By the way, may I ask you to provide me clear examples of such voters?

The idea was to have a given person to send an introduction/request on
internals with a clear description of which group this person would
represent (for example, Symfony or Drupal). I have to say I do not
such much of these requests. Again, we fail to follow and control
that.

Take out #2:

This specific thing should be a separate RFC and we should clearly
define how, when voter(s) addition happens.

> Virtually all of them are
> some form of meritocracy, and yes, that's despite all of them having impact
> 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 OS
> 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.

I agree here too.

I however disagree with the way you present it. It sounds like we need
a wall as we are submerged by thousands of illegal voters. I do not
think this is the case. We may get some data out of all RFCs, compare
to contributions activities (docs, code, tests, core, bugs, web or
systems) vs all other. I believe in data, feelings are good and
welcome but are distracting me from facts.

> 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 is
> unfair to ones who actually take the time and effort to work on the project
> itself.

To be honest, I can count with three fingers the core developers who
actually mentioned this unfairness or unwillingness to open RFC
decisions to a wider public.

Note to reader: Maybe raise your voice if you feel being treated
unfairly. We are here to move forwards. :)


>
> 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 general
> 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 am very neutral when it comes to FIG (or any other groups). As many
mentioned, PHP is a constellation of a lot of communities. Each of
them have their own habits. It would be very idealistic to think that
one single group could control all these communities (from a code,
norms, standatds, etc.).


> 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,

Yes, see my aforementioned comment about this. To make my point clear:
this should be a separate RFC with the clear and only goal to
streamline the addition of voters.

> that would not be biased towards one particular group - or we simply stick
> with the first group only, with the reasonable assumption that they'll
> factor in what they hear from these masses during the discussion period as
> they come to vote.  That's mostly how all other major OS projects work.

Not really my feeling. Please bring in some data to support your feeling.

> Another option might be going back to elements in the 2011 RFC (while
> clearly clarifying it).

Absolutely required. However I would not do it like this RFC: Too many
topics, too many controversial points, born to fail in the endless
threads hell and ending in a rushed vote.

> 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.

To close this reply, some final words/summary:

We need:
1. . We need to clarify what is core, what is not core.
2. how we handle extensions (addition/removal/default enabled or not)
3. A clear definition of the process to add voter(s)
  3.1 do we need groups represent their own project/community
  3.2 Do we want only actual projects to be represented
4. last but not least. Life is not fair but php can be. Make php fair
again. Clearly define what is required to be seen as a PHP contributor
and have the contributor status (I mentioned my view on that in this
reply)

I am not sure in which order this should be done. However I am deeply
convinved that these topics cannot covered by one single
RFC/discussion. This is also something to be discussed with community
leaders and understand better how they actually see that (aka data).

A last note, and coming from me and for those who know me for too
long, it is kind of ironic. May I ask everyone posting here and other
threads to chill a little bit and stick to facts and propositions. It
will drastically help everyone to understand the challenges we are
facing and move towards solutions.

Best,
-- 
Pierre

@pierrejoye