RE: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

> -----Original Message----- > From: Dan Ackroyd <Danack@basereality.com> > Sent: Sunday, February 3, 2019 10:24 PM > To: Zeev Suraski <zeev@php.net> > Cc: PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update) > > On Sun, 3 Feb 2019 at 06:19, Zeev Suraski <zeev@php.net> wrote: > > > > 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. > > I've read all 1200 words of your reply, which is quite a few words. > > I still can't see a clear description of what problem you're trying to solve by > changing who can vote. To summarize the issues (all written in my response): - Voting rights today are assigned in a way that isn't consistent with our current Voting RFC, nor that was ever intended in any point. - Due to an unintended consequence of a Wiki implementation detail, the barrier to obtaining a vote is ridiculously low. - The current system has no parallels in the world of major OS projects - which I do view as a problem, as I don't think we're inherently different from every other major OS project out there. I realize we now have some sort of status quo that we're used to, but it does not mean it's a sensible status quo. > The reason I'm being pedantic about this, is that when people just discuss > possible solutions to a vague sense of "this situation isn't perfect", they will > often suggest things that don't actually address the underlying problem. Or > disagree about details that don't actually matter. > > We really can't have a clear conversation about what to change without a clear > description of the problem that ought to be solved. > > For example, if the fundamental problem you are trying to address is that it's too > difficult for people to get a vote, then I would support documenting what our > current system is, and allowing people to know what they need to do to acquire > a vote. If the fundamental problem the RFC is trying to address, is to bring in a > whole load of new voters, who don't know how PHP works internally, then I > wouldn't be as supportive. I've been doing a horrible job at explaining myself if that's what you think I'm trying to do. I'm certainly not trying to address a(n IMHO) non-existent problem that it's too difficult to get a vote, or getting a whole load of new voters. Quite the opposite - I think we have way too many eligible voters today, roughly an order of magnitude greater than originally intended. It's way too easy to obtain voting credentials, in a way that is, in my opinion, both problematic and unfair to the main contributors. The goal is to go back to the original definition from 7.5 years ago, make it clearer (there's more work to be done here), and then stick to it - without letting implementation details in the Wiki be the judge of who gets to vote. If we do it - the voting base will actually shrink from around two thousand today - perhaps even slightly more - to around 150-200. To put things in perspective - there was quite some backlash regarding providing PHP-FIG with voting rights, which is an entirely valid opinion. At the same time - any person that ever contributed to PEAR (and consequently has a php.net account) - has immediate full voting rights. The fact of the matter is that out of the ~2000 users we have on php.net, less than 200 actually clear the bar set in the RFC (which isn't particularly high - 25 commits, 500 lines of code added/changed in the project). Out of those, more than a thousand haven't submitted anything at all to php-src, but have potentially submitted to other php.net projects (e.g. PEAR, or the php.net website), and an additional ~200 have affected fewer than 10 lines in php-src. Personally, I think it does tell us something about the viability of the current voting qualifications, and I don't think what it's telling us is positive. Whether or not contributions to php-src should be the only criteria by which we admit voters is a good question. I'm personally still undecided on it - whether we should find a mechanism to admit non php-src contributors as voters (like folks from PHP-FIG, major PHP OS projects, etc.), or whether we should rely on their voices being heard in the discussions and then represented by the php-src contribs. What I personally think is clear, though, that the awkward status quo we currently live in needs fixing - and it's a good time to do it, as we discuss other elements such as voting margins and workflow. Zeev