RFC: RFC Workflow & Voting (2019 update)

> 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. >

> Given how complex and controversial this question of restricting who can vote is, I propose that it be moved to its own RFC instead of being bundled with this one. It would certainly boost likelihood of passage, if nothing else, as there are a lot of good ideas in this RFC.

> On Thu, Jan 31, 2019 at 5:58 PM Kalle Sommer Nielsen <kalle@php.net> > wrote: > > > Hi Zeev > > > > Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski <zeev@php.net>: > > > > > > Without further ado, an RFC that’s attempting to comprehensively solve > > many of the issues that have plagued our RFC process since it was hastily > > introduced in 2011: > > > > > > > > > > > > https://wiki.php.net/rfc/voting2019 > > > > I wholeheartedly disagree with the PHP-FIG special exception to who > > can vote, call me biased but I do not believe it serves any purpose > > and is absurd. People who actively work on PHP, should be the ones to > > be able to have a choice, I think that should be reserved for any > > contributor who puts effort working on PHP. > > > > I do understand that we are the language and our work affects the > > others the most. However making special exceptions for who can vote > > and essentially having a say from an external source in what I in > > theory need to help maintain as a PHP Core Developer is terrible. Why > > not allow WordPress Core Developers to have a say instead, as their > > work has a larger impact on the usage of PHP? (That was obviously a > > bit of sarcasm, the last part). We are not allowed to vote at their > > individual projects features (nor do we need to have a say if we are > > not actively involved in the development of said projects or > > organizations) and I stand very strongly behind that belief. > > > > That's a very fair point. I'm personally undecided on this. It's fair to > say that in 2011, my thinking was that voting rights should be given pretty > much exclusively to contributors. It may sound like overreaching, but the > reality is that this is pretty much how ALL open source projects work (and > have been working). The reason it sounds overreaching, is that over the > several years following the ratification of the 2011 Voting RFC - a status > quo of "virtually anybody can vote" took hold, and it's now fairly > entrenched in people's minds. It's still very, very awkward when taken in > the context of how OS projects behave in general. > The thinking behind PHP-FIG (and for that matter, having some > representation from WordPress, yes, I'm not kidding...) was to create > something which goes a bit farther than what's usual in an OS project - > because of the status quo we have today. Making it a bit easier to > digest. But it may be that it's the wrong approach. I'll be interested to > see what others think about it as well. I'm personally open both for > extending that list further - or potentially trimming it down - making it > more of a meritocracy, as is customary in virtually all other OS projects. > > I don't know if there is a good way to implement it, but I definitely

> > Do I understand the PHP Packaging Decisions right that it requires to > > vote for a timeline for each version? I remember we have different > > opinions raised regarding the time to a new major version (should we > > have 7.4 vs go to 8.0, same for the 5 to 7 transition back then > > regarding a 5.7). This is the only issue I can think of and should be > > changed to requiring a vote if there is a dispute in regards to what > > the next version should be. As I don't really wanna vote just to vote > > for each of the minor versions of 8 once a year when its the most > > logical reason to go to 8.1 from 8.0, and so on until we reach the > > point where the next major is considerable. > > > > I agree. I'll look at the text and clarify it as needed. Of course it > makes no sense to have to vote on every version from scratch every time. > > > > I think changes like the requiring a patch for RFCs is a very welcomed > > addition. > > > > Thanks for the feedback! > > Zeev >

> Hi! > > I haven't fully read the RFC yet, so I'll come back with more formed > opinion about it probably, but wanted to comment about a couple of > points here: > > > Reasoning: If somebody is out of the project for 10 years they probably > > lost track on how the language and needs evolved and just voting since > > an old friend needed a deciding vote is bad. > > I agree, though "out of project" can differ... But I think if the person > had made no contribution for a decade, then probably he wouldn't be very > well informed voter. Easier way would be to make the list of such people > and let them ask on the list that their vote will be kept if they want > to, with explanation on how they plan to continue contribute (we don't > have to require actual contribution, just people promising to do so - we > are all volunteers here anyway). People that have long moved on would > just ignore that, and people who want to come back will do so. > > > For groups like FIG I am uncertain. I think it is a good thing if we > > push more things out of PHP itself into the userspace (JIT, FFI, ... > > allow more and more stuff to be done in userspace) and thus > > coordinating with userspace developers and setting standards and > > interoperability there is good. However it are the maintainers who > > (often voluntarily) have to maintain these things and overruling actual > > maintainers is bad as they lose interest. > > Yeah I'm feeling a bit uneasy about the FIG part too. I mean, having > input from major userspace groups is great. But having input and having > deciding voice is a different thing. Discussion and vote are different > processes, both important but with different results. So I wonder if we > can't find some venue to collect this feedback without having people who > aren't core developers decide for core developers what should they do. > This sounds like something that won't be healthy. > -- > Stas Malyshev > smalyshev@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >

> 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’s attempting to comprehensively solve > > many of the issues that have plagued our RFC process since it was hastily > > 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 the > 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), became > 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 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). 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. 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* 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) > - 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. > > 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 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". > > The goal of the voting eligibility section in the updated RFC is to clarify > this. It's clear we have more work to do in this front here - but ignoring > 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 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. 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. 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. > > 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. > > > 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 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 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. > > 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 unusually > busy weekend... > > Zeev >

> > On Fri, Feb 1, 2019 at 7:14 PM Dan Ackroyd <Danack@basereality.com> wrote: >> Hi Zeev, >> >> Please can you very clearly state what problem you are trying to solve >> by changing the rules about who can vote. > > Fair enough, I've heard that question from several others.

> 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.

> 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), became > 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 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).

> 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.

> 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* 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)

> - 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.

> 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 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".

> The barrier to obtaining a vote today is ridiculously low.

> 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.

> 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.

> 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.

> 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.

> > 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 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 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.

> 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.