On Sat, Feb 2, 2019 at 10:20 PM Zeev Suraski <z...@php.net> wrote: > On Fri, Feb 1, 2019 at 7:14 PM Dan Ackroyd <dan...@basereality.com> wrote: > > > On Thu, 31 Jan 2019 at 13:44, Zeev Suraski <z...@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 >
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
