@Richard Yeah that sounds about right actually. That's probably exactly the reasoning behind the current model being what it is.
However, it seems to me that, especially in complex proposals, the "should we?" and the "how?" distinction becomes more and more difficult to avoid. If everyone supports an idea, but there are a hundred different viable ways to do it, having a hundred different competing proposals would be a nightmare IMHO (especially if fifty of them passed and are directly conflicting with one another lol). That's why I'm thinking, if you split them into separate questions but keep them in the same overall proposal, you can wind up with the best of both worlds. The "primary" question is whether or not this should be done to begin with; if it fails, then everything else is moot. If it passes, on the other hand, then the plurality on any secondary question(s) would allow us to simultaneously and efficiently decide *how* it should be implemented without having to create separate proposals or cause the support vote to become split (since your vote(s) to any secondary questions would have no bearing on your primary question vote). For example, let's time-travel ten years into the future. I wanted to modify PHP 7.3's configure script to use a botnet I control to increase PHP's processing power (as of PHP 7, PHP can exploit rootkits but it can't control entire botnets). If enabled, the RFC argues, I'd be able to increase my spam output tenfold and still have enough victim machines to carry out a DoS attack against FaceGoo+ (yep, they merged) and silence my many enemies. But then, there a serious problem surrounding this proposal that someone raises: Should there be a switch to activate this or should it simply be configure's default behavior? Also, should this include a switch that instructs PHP to install a rootkit on vulnerable systems automatically, and if so, should we integrate that with the main switch, make it a separate switch, or just make it the default behavior as well? Naturally, this would best be handled as a single RFC. The "primary" question would be something along the lines of, "Should PHP's built-in trojan management capabilities be expanded to allow for control of large botnets (yes/no)?" Then, there would be some secondary questions; for each one, the prefix "If implemented...." is assumed: "Should the the switch be enabled by default (yes/no)," "How should rootkit install toggling be handled (option on main switch/separate switch/just make it default)," and, "Should we commit another series of arsons at Semantic in order to slow the development of new security patches that might hinder our supreme objective?" Heh sorry, my examples tend to get a bit psychotic after a long day at work. But you have the gist of it, at least. ;) --Kris On Wed, Feb 29, 2012 at 6:32 PM, Richard Lynch <c...@l-i-e.com> wrote: > On Wed, February 29, 2012 6:55 pm, Kris Craig wrote: > > If not, I'll go ahead and draft an RFC for these proposed amendments > > sometime today or tomorrow when I get a spare moment. If anyone has > > any > > thoughts on this, please share them! Thanks! > > This is not an official answer. I don't have time to dig out references. > > I believe the PHP community settled on the idea of having a single > simple pass / fail vote without the complexity of branches / options. > > It was simply to hard to tally the votes once you open up the options, > because your support base ends up being split. > > NOTE: See current US Republican Primaries for examples of how complex > it gets. :-) > > There is nothing to stop one from drafting multiple proposals, with > alternative options, and each one getting vote upon, other than the > time available to the person drafting the proposals. > > And, of course, a reasonable expectation that with TOO many proposals > of the same idea, the community would quickly turn into robo-voting, > both for and against, as that's just human nature. > > Again, I say, I don't claim to speak for the whole community. This is > merely my interpretation from my faulty memory of past events. > > -- > brain cancer update: > http://richardlynch.blogspot.com/search/label/brain%20tumor > Donate: > > https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
