On Sun, Feb 3, 2019 at 12:08 PM Nikita Popov <nikita....@gmail.com> wrote:
> >> 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. > Kris's point made me think about this issue, and I may still need to do some more thinking about whether the Workflow and Voting elements can be separated. It may be that they can. However, I don't see how the Voting element can be further separated into "voting eligibility" and "voting threshold", and other surrounding elements like a quorum which we may want to introduce. These are inherently interlinked. Moreover, there are elements where even the substance of the given RFC has - or at least *should* have - influence on the voting margins. Cases in point: - The PHP 6 vs PHP 7 naming RFC - The RFC to determine PHP 7's timeline - The PHP 5.6 EOL RFC - Any future RFC about timeline, naming, or other administrative, non-policy-binding decision These administrative decisions make no sense to require a 2/3 majority, but rather - a simple majority of the eligible voters, as ultimately, it's down to a matter of preference - without any long term (beyond a couple of years) commitments. The 2/3 majority was introduced to place a bias-towards-the-status-quo of the language, and make sure we don't create long-term commitments based on a temporary narrow majority. It simply does not apply in such cases. Further, it's difficult to separate the question of "what requires a vote" from a statement that "everything requires a 2/3 vote", although technically not entirely impossible. I'll do some more thinking about it and consider breaking the Workflow & Voting into two different RFCs if I can find an elegant way to solve these issues; But either way, focusing on the margins alone remains a non-starter for me. 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. > As demonstrated above, they actually have a lot to do with each other, and do have certain inter-dependencies. Thankfully, in our world, neither is a series of books with countless chapters like free trade and copyright law tend to be. I realize that there are some people here that want to simply focus on the 2/3 margin issue and call it a day, but to me it remains a very partial fix to a much bigger problem - that realistically, if we don't tackle now while we've got people's attention - we'll likely never tackle. 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?" > That's extremely fair feedback re the marginal cost of editing, and I think going along what Larry proposed later on this thread would make a lot of sense. It would balance your feedback with the need to avoid overburdening the RFC authors, while at the same time providing RFC voters with the time they need to analyze and discuss the merits of (and changes to) RFCs - as well as preventing any sort of foul-play. Essentially, "whenever's there's doubt, there is no doubt", but at the same time - if nobody raises doubts (which they shouldn't for small changes) - things can proceed without interruption. I'll try to embed it into the RFC. I still think that the new workflow proposed would keep the burden roughly the same as it is today (with the above fix factored in). Zeev
