> -----Original Message----- > From: Derick Rethans [mailto:der...@php.net] > Sent: Wednesday, January 13, 2016 12:59 PM > To: Zeev Suraski <z...@zend.com> > Cc: John Bafford <jbaff...@zort.net>; PHP internals > <internals@lists.php.net> > Subject: RE: [PHP-DEV] Re: Internals and Newcomers and the Sidelines > (WAS: Adopt Code of Conduct) > > On Tue, 12 Jan 2016, Zeev Suraski wrote: > > > I think that no matter what we do, CoC, guidelines or teams we have in > > place - as long as there'll be divisive RFCs, there are going to be > > heated, toxic discussions. > > I think the main issue is the whole concept of "divisive RFCs" as a term. An > RFC is a request for *comments*. Instead of people saying > (paraphrased) "that is crap, unwanted, needless", the whole point of an RFC > is to improve the proposals - before a vote is arranged.
While RFC does stand for 'Request For Comments', in practice it's much more than that. It's the declaration of intent to introduce a change subject to a vote on a relatively short timeline. In some cases, the proposed ideas are awesome and enjoy consensus. In some cases, they're downright bad - or at least perceived to be bad by an overwhelming majority of the voters, or are even withdrawn before going into a vote. Then, there are those ideas that create two polar groups, both sizeable - with one thinking the idea is awesome, and the other thinking it's awful. Those are the ones that are causing the heated debates on internals, and those are the ones we need to find a way to avoid. Even though it's clearly not a 'defined term', and I will obviously not propose an RFC to ban 'Controversial RFCs' as they're impossible to define ahead of time, simply put they are RFCs that create controversy. Based on my analysis yesterday, I think there's a relatively easy way to spot them if you look at the numbers (for those reading this message out of context - bit.ly/php7rfcs), and I believe we can come up with a mechanism to minimize them or outright avoid them altogether. It would come at a price - we would have to agree that improving the atmosphere on internals by focusing on ideas that are enjoying widespread consensus is more important than approving any one particular idea. > The recent discussion on Antony's CoC RFC, has very little people/comments > trying to improve it, but instead trying to torpedo it because of "why do we > even need it? we're not 'toxic'" (again, paraphrased). I don't see it that way. I think I provided very relevant feedback - that yes, called for a very substantial revision of the proposal and a removal of a substantial part of it - but I still marked the concept of having a CoC as a good idea from the get go. Separately, I think that if people think that a given proposal is a bad idea and cannot be improved - it's perfectly fine that they would voice their opinion. Some ideas are just bad, and RFCs are often withdrawn or fail to pass. Personally I don't think the CoC proposal is inherently bad - quite the opposite - but I think its implementation the way it's currently phrased is quite negative. To be perfectly honest, I'm offended that despite spending literally hours on providing feedback and making my case for why even the latest draft is problematic (and how I think it can be improved to reach consensus) - feedback that were completely respectful - I received no response from any proponent of the RFC. The same holds true for several other people - who provided relevant feedback which went ignored. In fact, the response came as saying 'No more feedback please. My next email will be presenting a final draft, after which I'll go to a vote after the minimum allotted time'. I think the current CoC RFC is a perfect example of a controversial RFC. It's creating controversy. It doesn't matter if it's right or wrong. The chances of it hitting consensus (85-90% mark) seem very slim. It might reach 67%, I have no way to predict it - but having 9 supporters for every person thinking it's bad? Doesn't sound very plausible based on the internals discussion so far. Specifically the CoC discussion is also controversial for another reason - it's using the RFC process for a purpose it was never designed to fulfill. But I'd rather not discuss the specifics of the CoC RFC right now, and try to solve our fundamental problem instead. A problem which even the proponents of that RFC aren't saying it's supposed to solve. Another point to consider is that when as RFC authors, you have a 85-90% bar to clear - you're much less likely to be ignoring substantial amounts of feedback and just pressing on to a vote, which is what's happening here. > > Had we had a 90% bar, it does mean that STH wouldn't have made it into > > the language, but it also means that we would probably not have the > > discussion saga on internals either, and all of the bad vibes that > > surrounded it. > > That however, makes it very easy for a vocal majority to torpedo everything. I believe you meant a 'vocal minority', but that's the wrong way to describe it in my opinion - the right term is a substantial minority. Vocal minority makes sense when we're talking about a handful of people, or even less than a handful, that are vocal well beyond their representation in the voter base. I do think we need to find ways to prevent a true vocal minority from shooting down ideas, and I proposed a couple which I actually think aren't that bad. The problematic RFCs are the ones that generate a lot of interest, with a lot of people having an opinion about them - but opposing ones. RFCs that generate a lot of interest AND have close call votes are quite uncommon. Today, what happens is that these RFCs begin with large feedback threads, often heated, and they result in large voter turnarounds. Once the vote is over (whether it's approved or declined), it's a zero sum game - the winning side is happy, the losing side is sad. More importantly - we've already paid the price in terms of making internals a tiny bit more unattractive to everyone - not just newcomers. > I think this is only just going to cause more resentment to the few people > that tend to vote against nearly every RFC. I think the mechanisms proposed - either a 2/3 majority until 50 votes and 90% beyond that, or keeping the bar at 2/3 but having a 'double no vote' that voters will be able to use very selectively (because of limited supply) - can prevent that from being an issue. I'm sure people will be able to poke holes in these ideas, but I believe they can be solved. Again, the premise of this proposal is simple - do we care more about one particular idea, or about focusing on the areas we all agree on? For me it's a no brainer, and if we agree the consensus is more important than any one particular idea, I believe we can find the voting system to enforce it. > But - it's an interesting theory. Thanks! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
