On Jan 28, 2013, at 2:14 PM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> Hey all, > > After reading the Voting Periods email thread, I'm left wondering a simple > question (which has a difficult answer): > > What should we be voting on when voting on an RFC: on the RFC proposed > feature, or on the patch itself? Personally, I'm discussing/voting on the feature. We do tend to combine our discussions, but voting seems to be directly for the proposed feature. I don't necessarily disagree with this approach, as we tend to hash out the implementation during the discussions. It might save RFC authors a lot of time and keyboard taps if we discussed/voted on a feature prior to discussing implementation. This could open the door for a flood of feature requests in the form of RFCs, but I don't believe that would happen. One of the advantages of combining the patch(es) with an RFC is it shows the author has put forth an effort in thinking the idea through. That said, a "rule of thumb" (or official rule) that RFC authors should provide a patch once the feature has been approved might work. In the end, separating the two would end up saving the RFC's author and this list time as to whether a feature should be considered. However, there are times where the implementation could change the outcome of the feature vote itself. > > I've always approached it as we're voting for the concept (and details) > provided in the RFC. But it appears that other people have been voting on > the specifics of the attached patch (so theoretically an RFC could be > rejected entirely because some people don't like part of the implementation > in C, but are fine with the PHP details). > > I'll leave out my opinion (and justification) for now, I'm curious what you > all think... > > Thoughts? > > Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
