From: Joe Watkins [mailto:pthre...@pthreads.org] Sent: Sunday, November 20, 2016 3:43 PM To: Zeev Suraski <z...@zend.com> Cc: Kalle Sommer Nielsen <ka...@php.net>; PHP internals <internals@lists.php.net> Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes
>Afternoon Zeev, >I am not sure how much of the voting RFC I want to reform right now. I am >responding to specific problems >that seem to be best fixed just by raising the acceptance criteria. I do >realize that these issues are difficult to >tease apart however, so intend to at least try to suggest reformations for >more than one section of the >voting RFC. Yes, I can relate to not wanting to tackle more than one issue at a given time. I think that depending on the proposal, it may be reasonable to tackle a change in what requires a super majority independently of other issues, without radically changing the current situation of how things work. My bigger concern is that conceptually, the way things work currently is very far from the original intent of the Voting RFC. I'm at least am not aware of any other large open source project out there that has something that's even remotely close to what we evolved into in the PHP project. The vast majority of community-based open source projects are various forms of meritocracy, where your ability to influence the direction correlates in some fashion with your level of contribution. In PHP the barrier to influence is almost not there. There are several ways to tackle this - one is one I brought up a while ago, that effectively raises the acceptance bar from 2/3 to 85-90% - given that the vast majority of proposals that passed, didn't only pass with ~2/3 of the votes, but with something much close to consensus (reminder - see the analysis and proposals in www.mail-archive.com/internals@lists.php.net/msg82852.html). A different way may be changing the (de-facto) rules on who gets to vote. Or perhaps a combination of both. >Maybe it is time to have some of these conversations again. I think it is. As draining as it may be, I think we owe it to ourselves and PHP to try and tackle some of the deficiencies of the rushed Voting RFC, before it's even later than it already is... >When you say that the voting RFC was rushed, this is news to me. In my opinion it was rushed. By the time we started working on it, we had about 13 years of working in a certain way, which obviously evolved over time, but was never ever even remotely similar to what's described in the Voting RFC. And then, over the course of less than a month, we had a piece of text that a bunch of people agreed on (with some major reservations), that was as hermetic as a thing slice of Swiss cheese; A completely different way of working quickly evolved, somewhat based on a very broadening interpretation of that text - and that new way of working became set in stone. Looking back at my email archive, I think we did recognize that there were some tricky parts in this RFC, and that it would be very difficult to change: "Making changes once we've approved this RFC is going to be much tougher. This is big stuff - it's no coincidence we didn't have such guidelines for almost 15 years. Honestly there are other parts about the voting process that are much hotter potatoes than the points I brought up - such as who gets to vote, is 50%+1 enough or do we need stronger majorities for substantial language changes (67%/75%), can someone who failed passing an RFC just put it up for another vote right away or is there some sort of a cool-off period, etc. etc. I think all of these need to be answered before we let this RFC govern how we do feature definition." ... and yet, there was a very strong bias to get *something* going, so my barely-first-draft on dealing with some of these topics became set in stone, with very few updates and little scrutiny from anybody. I think that there were large groups of people who believed (based on the discussion on the list) that we'd still first strive for near-consensus before even bringing up RFCs for voting, which as we all know - turned out to be very far from what happened in reality. Others thought that it wouldn't be a big deal to amend and improve this as we go along - which also turned out to be disconnected from reality as not a single change was made in the last 5 years (except the de-facto changes, like who gets to vote). I think the feeling back then was that "anything is better than nothing", and perhaps it was - but it certainly pushed us to move ahead with a half-baked solution. This RFC went to a vote two weeks after I made these statements and made my edits, with virtually no further discussion on internals during these two weeks, and was approved 6 days later. Yes, I'd call it rushed. > Perhaps you can understand it being treated as a bible if you consider that > we don't remember the bad old days, and these are the only rules we know how > to play by. Oh I certainly do. As you can see in my quote, I expected it to become that way. What I didn't expect us to do is ratify it so quickly, when it was only slightly better baked than when I made that statement... That's the same reason I was worried about other non-technical proposals that were raised over the years - I just don't think we're very good at this law-making stuff. Zeev
