On Sun, Feb 3, 2019 at 6:18 AM Zeev Suraski <vsura...@gmail.com> wrote:
> > > > -----Original Message----- > > From: Nikita Popov <nikita....@gmail.com> > > Sent: Saturday, February 2, 2019 6:24 PM > > To: PHP internals <internals@lists.php.net> > > Subject: [PHP-DEV] Alternative voting reform: Streamlining the RFC > process > > > > Hi internals, > > > > After discussing the topic with a number of current and former > contributors, I > > feel that the workflow & voting RFC currently under discussion is moving > us in > > the wrong direction. I will not comment on the rather questionable > proposed > > changes to voting eligibility, as these are already extensively > discussed in the > > RFC thread. > > Personally, I find any proposal that does not deal with clearly defining > voting eligibility not only questionable, but a non-starter, that has no > parallels in any other major Open Source projects. > Why? While I think the question of voting eligibility is worth discussing (though I also don't consider the problem pressing in any way and think that our current pool of voters works quite well, even if it may not be what people had in mind back then), it is, just like the question of voting margins, a rather independent issue from the remainder of the process. I think that these discussions and RFC can and should be split up into the question of voting margins, the question of voting eligibility and the question of the RFC procedure itself. While these things are of course related, they can also be decided independently. The problem with bundling together these changes is, if you will excuse the political parallel, akin to bundling changes to copyright enforcement together with a free trade agreement. Those two things have nothing to do with each other (though of course interested parties will argue that they are inseparable), but combining them into a single agreement makes it feasible to pass changes that would not otherwise be considered acceptable. At the same time, it also puts the overall agreement at the danger of failing, due to parts that are not related to its core purpose. I understand that there is also benefit in deciding related questions in conjunction, in that a decision in one area would only be acceptable conditional on a decision in another area. However, to get back to the specific topic here, this does not appear to be applicable. For example, your changes to the RFC workflow could be implemented independently of the voting eligibility changes and vice versa. The only possible dependency I see is that all proposals benefit from having the 2/3 voting margin as a baseline (which is consistent with that RFC proceeding first, of course). > The suggestion that the new RFC makes life more difficult, compared to the > current Voting RFC, is simply wrong. It is, in fact, very much the same - > except it's a lot more well defined in terms of 'what happens if' - which > in the years since the 2011 Voting RFC was enacted became a de-facto > wild-west. > As quite likely the single largest user of the RFC process, I beg to differ. I think your perspective here comes about, because your use of the RFC process is limited to rare, but large (in the sense of important) proposals. However, that's not the case for all or even most RFCs. It is already the case that RFCs are cumbersome for smaller changes, and all active contributors I know (apart from cmb maybe) will go out of their way to avoid going through the RFC process if it is at all avoidable. It is something of a social faux pas to tell another core contributor on a PR that their change might benefit from an RFC, because that generally means that the change will be dropped dead in the water instead. I think that we *should* encourage the use of RFCs for less significant changes, because it is useful to have design considerations spelled out in more detail than a two line commit message. Your proposal does not make things much more complicated, and doesn't make the RFC process take much more time. But it increases the marginal costs just enough to make RFCs even more annoying than they already are. You edit your proposal a few times at inopportune moments and bam, you have to wait one and a half months before it can land. That's okay if you're trying to introduce a JIT in PHP, but if you just want to add a function, that's the point where you say "Why do I even bother with this?" Regards, Nikita
