On 11/10/2011 01:17 PM, Pierre Joye wrote: > If that's not the case, and after a 2nd thought, it is actually not > the case, then we can just discard this whole thread and go back to > code and proposals. I only find very disturbing to have to explain and > argue so many times about that only because we have a edge case in a > proposal (which is perfectly valid, that happens, show must go on).
The problem with some RFCs is that it is not clear what people are voting on. In some cases people are voting for or against a proposal based solely on the concept while other people are looking at the nitty gritty details of the implementation and voting against it due to implementation problems. Then there are procedural problems like the RFC changing during the voting process. As long as it is completely obvious what is being voted on and the process is followed, the voting RFC rules are fine. It would be nice though if we could iterate in order to get 2/3 approval on most proposals. It is these 50/50 ones that are problematic and often boil down to half the people voting, "We want this feature!" and the other half voting, "Yes, but this implementation, as proposed, is half-baked." In cases like this where we end up in a 50/50 standoff instead of pushing thought with 50+1 I would much rather see each of the valid criticisms added to the RFC with an explanation of what the problem is and what is or isn't being done to address it and open the voting for another week to give the former no (or yes) voters a chance to be better informed and change or add their votes. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
