See below in blue:
I feel compelled to voice just how extremely inappropriate it seems to me to delete the other side's argument on an RFC without any consultation. What I proposed was that Zeev and maintain the 7 argument and Andrea maintain the 6 argument. This effectively smells like blatant tampering to me. If Zeev says it was accidental, I'd be willing the to give him the benefit of the doubt and let that be the end of it, though it still troubles me that this happened. Hopefully, it will never happen again. The removed paragraphs were added in this context – a note from Andrea to me: > Third, numerous people (myself included) actively proposed we skip > version > 6 and go with version 7; Dismissing that with "I don't think the > alternative naming options are really much better" doesn't seem to > belong in an RFC. The merits of this option - which were really more > about the drawbacks of calling it '6' and the lack of drawbacks of calling it '7' > should be properly described in the RFC. I’ve covered the PHP 7 issue more now. The removed paragraphs were actually the RFC’s ‘case for PHP 7’. As the champion for the PHP 7 case, I was 100.0% entitled to remove it as I thought it wasn’t doing a good job at presenting that case, and replace it with some real pro-7 content. Moreover, after my edits, I proposed to Andrea that we take more time for discussion, make sure each ‘camp’ is good with the post-edits RFC (as they were substantial), and then restart the vote. Andrea initially didn’t feel it was necessary and wanted to simply extend the vote, which I was OK with. At this time I assumed she read the updated RFC but perhaps she hasn’t. Note that even after she restored the edits, she didn’t feel the RFC was suitable for vote as she no longer felt the PHP 6 case was being properly represented, with our without the old ‘case for PHP 7’ paragraphs. That said, I agree 100% that the vote should have been cancelled. Whether it was accidental or not, Zeev's unilateral gutting of the pro-6 argument contaminated the whole process and rendered any subsequent vote results unreliable. The only sensible and fair recourse at that point was to clear all votes, fix the RFC, then start the vote process over. She didn't do it because she didn't like the results. She did it because the RFC had been tampered with in such a manner as to likely influence the voting. It was not accidental and I said so almost immediately after Andrea sent the note to the list about the paragraphs being removed. Now, if you move away from your biased point of view, perhaps you’d notice some issues elsewhere too: 1. The vote started with no real case for PHP 7 in there. I made it clear in past weeks I intended to write one, and said it would take time. The supposed ‘case for PHP 7’ that was added there by PHP 6 proponents, is now turning out to be a further case for PHP 6. 2. When I asked the vote to be canceled, it was rejected – even though 20 people voted on a 100.0% one sided RFC before I put in a real case for 7. Let’s say it was wrong for me to edit these two paragraphs into a real case for 7 – why was it suddenly appropriate to cancel the vote immediately? How is it different from the situation on the ground when the RFC went for a vote with a one sided 6 position? 3. Fact it that when the vote was canceled, it was 25/15 in favor of 7 and with 7 gaining rapidly (it was 7 to 13 ~12hrs earlier). Another fact is that even once these paragraphs were restored, Andrea didn’t feel they were doing a good job representing the case for 6. On my side, I don’t feel I did **anything** wrong. I edited paragraphs that were supposed to be in my jurisdiction, at least according to the person who wrote them; I asked for an extended discussion time which would have immediately turn out the missing paragraphs had people thought they were in fact necessary for the PHP 6 case; And, last but absolutely not least, I’m fine with Andrea canceling the vote, as my goal from the get go (weeks ago) was that the best case would be made for 6, the best case would be made for 7, and people will vote accordingly. Given Zeev's current situation, I think we should grant his request for a delay in voting, especially since we had to start over, anyway. There's no rush and I think it's important that we get this right, given the passion there seems to be on both sides of this particular debate. I would also ask that Andrea do one final read-thru of the RFC before putting it to vote just to make sure there haven't been any new unexpected edits, and that everyone agree not to alter the RFC's contents (namely the arguments) once voting has begun. That should be a universal rule with RFCs, anyway, I think. There’s no need to delay on my account, we’re carrying on – I was just extremely busy in the last couple of weeks. I think that as soon as Andrea feels comfortable with the case for PHP 6 we can go to a vote. I do welcome other ideas for how to improve the case for 7, too. If we’re talking about universal rules for RFCs – a ‘choose between a and b’ RFC should never go into a vote with one of the cases clearly misrepresented in it. The ones to judge whether it’s properly represented need to be the proponents of each option. As an anecdote, yesterday morning, I got an email from a certain someone telling me he feels the RFC is balanced and represents 7 well; Needless to say, that person voted for 6. Now let’s focus on bringing this to revote and being done with it. And getting the kids to kindergarten J Zeev
