Patrick, My viewpoint is that options in an RFC are dangerous. I would much rather have a single RFC, with a single vote (yes/no). I think we should be discouraging the options as much as possible.
The reason is simple: an RFC should be an encapsulated idea, not a menu of options. The author should take a stance. If there are details that the author can't decide on, then either take a straw poll in the mailing list, or create a separate RFC for that option. The problem with options is that it makes the vote much more confusing. With 3 options, you have 3 different proposals. Some recent votes have had upwards of 12 different proposals built in to a single RFC (2 options + 3 options + 2 options). It's enough to ask someone to read and understand one proposal completely without having them have to comprehend all the possible permutations of voting outcomes. It also encourages weird voting patterns. Take your example of No/Yes, A/B/C. In that case, you have 4 permutations as you pointed out. But what's deeper, is how should someone vote if they are opposed to B? I mean opposed, not just preferring a different one? The tendency would likely be to watch the vote and if it looks like B will pass, vote no on the entire proposal. Can we please come down to a single RFC, with a single vote yes/no? It's easier to understand, easier to manage and has less possibility of gaming. Anthony On Tue, Mar 10, 2015 at 10:39 AM, Patrick ALLAERT <patrickalla...@php.net> wrote: > Hello, > > Le ven. 6 mars 2015 à 00:44, Marcio Almada <marcio.w...@gmail.com> a écrit : >> >> You are right about this. I'll setup a yes/no vote + a vote to decide >> between E_WARNING (for consistency), E_DEPRECATED or E_STRICT. For me this >> is just a detail but maybe it's very important to others, so better to let >> each voter decide upon it. >> > > In case of language changes, shouldn't the 2/3 of majority be required at > any levels? > > In situations like: > > Main feature: No/Yes > Option: A, B or C > > My gut feeling is that it would be better to rally a 2/3 majority of people > behind one of: > No / Yes (A) / Yes (B) / Yes (C) > in order to not dilute the importance of language changes. > > It would prevent accepting an important change where a lot of people agrees > on a general idea but have strong opinions/arguments on > implementation/details. > > Cheers, > Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
