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
Third, numerous people (myself included) actively proposed we skip
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
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
Now let’s focus on bringing this to revote and being done with it. And
getting the kids to kindergarten J