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 <krakjoe@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
