Hi!
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.
I think we shouldn't over-formalize this. Certainly if about 50% of voters are against something, it does not have consensus. But I do not think specifying hard percentages would do us much good, especially if we do it without considering case in point. Some things are OK to decide on simple majority (like things that have two equally good options and we have to choose one, or things that are matters of taste/style, etc.), some may require more strong consensus, especially big changes, but I'd have very hard time formalizing this upfront.
Currently the "Feature selection and development" basically says "we'd have a public vote on features". It doesn't specify how exactly is the process for a vote, and while again I think your proposal is good, I don't see why it has to be part of this RFC - e.g., if we agree that we have to have RFCs and formal non-ML public vote, let's fix that and then talk about how exactly we do the vote. The RFC itself says nothing of "how", so I don't see why we should mix the question of "should we do it" with "let's decide how exactly we going to do it".
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
