On Mon, Aug 19, 2019, at 1:26 AM, Zeev Suraski wrote: > I'm on vacation so only at a high level: > > - If it's anything remotely similar to the one for P++ (abrupt, done > without any coordination with the author, goes into a vote with > immediate effect, grossly misrepresents the idea while refusing to fix > that even after the fact, pretends to be an RFC even though it's not, > and with perceived mandate to shut down discussion) - then absolutely > not. The side effects from this instance still need to be cleaned up. > > But - I think it can actually be a good idea as a semi formal toll for > authors to know whether they should continue to invest their efforts in > a certain idea. As long as it is designed to be a helper tool for > authors - and not a method for folks to shutdown discussion. It can > also be a good indicator for authors whether their idea is likely to > pass or whether they should substantially evolve it (or better explain > it's merits) before moving on. > > Zeev > > > On 19 Aug 2019, at 7:55, Joe Watkins <krak...@php.net> wrote: > > > > Morning internals, > > > > I've got a sort of fuzzy idea to make provisions in the RFC process for > > preliminary polling. > > > > It seems there are several situations where a preliminary poll makes sense, > > it would have made sense for the p++ discussion and saved us a week of > > wasted time. It also makes sense when the RFC author is not sure whether > > they want to invest time in an implementation, or even long drawn out > > discussion. > > > > They would be non-binding, of course, and allowable from the time of RFC > > creation, with a limit of one preliminary poll per RFC. > > > > Is this making sense to anyone else ? > > > > Cheers > > Joe > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
I've used informal polls in FIG over the years to great effect. I think they're very valuable. For RFCs, I think the main requirements are that it's the author that calls them, not anyone else (Zeev's concern), and that what's being polled is *very* specific; viz, just the concept, not implementation, or "do you prefer path A or B", etc. Getting people to actually, you know, pay attention to the question being asked is the hard part. Also, allowing more robust polling types than just Yes/No would be helpful. In FIG I have become very fond of scale voting (rate 1-7 for agreement with two competing statements), and in case of multiple options ranked choice voting is almost always superior to simple plurality. I don't know if the Wiki is capable of those, but that's why I've generally used Google Forms for FIG polls. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
