On 2011-06-05, Zeev Suraski <z...@zend.com> wrote: > I'm fine if the entire 'Feature selection and development' part goes > out of the RFC, but if there's any reference to how features are > determined, we'd better get it right. > > Making changes once we've approved this RFC is going to be much > tougher. This is big stuff - it's no coincidence we didn't have such > guidelines for almost 15 years. > > 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,
This is a tough one. I'm typically in favor of having the vote be completely open to anybody. However, since we're talking language features, there are a lot of other considerations -- internals folks will have a much better idea of what the BC and support ramifications are. Perhaps two votes should be considered? A "general population" vote, and an "internals" vote? This would show discrepancies between what users of PHP want, and how internals is voting. If internals votes against a feature that the general population has approved, I would expect to see some sort of "executive summary" showing what technical issues are at play that led to the internals vote. This would serve as a good historical record -- and also potentially show where bias lies within the internals community. > is 50%+1 enough or do we need stronger majorities for substantial > language changes (67%/75%), I think anything less than a strong majority (2/3 or 3/4) often is indicative of either ambivalence or strongly competing ideas. The question is where that threshold should be set (I'd lean towards 2/3 vote.) > 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, I'd argue a 2-3 week period in which to re-work the proposal and incorporate feedback from the prior discussion/voting periods. > etc. etc. I think all of these need to be answered before we let this > RFC govern how we do feature definition. > > Zeev > > > -----Original Message----- > > From: Stas Malyshev [mailto:smalys...@sugarcrm.com] > > Sent: Sunday, June 05, 2011 11:17 PM > > To: Zeev Suraski > > Cc: Pierre Joye; PHP Internals > > Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on > > the wiki! (Was: [PHP-DEV] 5.4 moving forward)) > > > > Hi! > > > > > I'd still like to hear from others what they think about my > > > proposal. I'd like to update the Release Process RFC with these > > > suggestions if people like them. > > > > I think these voting process additions totally make sense. But I am > > not sure it makes sense to put everything in one release RFC. The > > reason for that is that we don't want to endlessly amend and improve > > the RFC without having it actually agreed upon, I would rather > > prefer to agree on what we agree, have it as base for the future and > > then add other stuff. I've noticed a tendency on the list to lose > > the major goal behind endless amendments and tweaks and not doing > > what we agree on because we disagree on some minor detail. So maybe > > it would make sense to have release RFC separate (without spelling > > out the voting process there) and voting RFC separate which would > > define the voting process? -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
