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
