On Sun, Jun 5, 2011 at 10:55 PM, 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.
Getting it totally out makes little sense as it brings us to the point where we have no idea how we decide what gets in or not, the RMs, etc. > 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. That was not the reason, the lack of will to define such processes was the reason despite the numerous requests to have one from in and outside the core team. > 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'd to go with a 60% for language syntax, 50+1 for new exts or sapis. Other question is who can vote. For one, I like to have external people being able to vote, like frameworks/apps lead developers as well as @php.net in general (docs people at the same level than core devs, no diff). However I'd to say as well as I have no issue at all to define the basis of the voting system in it and add a note that it may be tuned later once we have more experiences. That's perfectly fine, nobody expects us to be perfect with the 1st shot. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
