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.

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:

Definition of the core and what we want to include into it. how we include and remove extensions 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---

php.net VCS accounts 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:

. We need to clarify what is core, what is not core. how we handle extensions (addition/removal/default enabled or not) 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 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