Now THIS is a sensible proposal! It resolves the biggest issues in a very simple and straightforward manner. And unlike the other RFC, this proposal does not feel like an exclusionary power grab.
--Kris On Sat, Feb 2, 2019, 8:24 AM Nikita Popov <nikita....@gmail.com wrote: > 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. > > The remainder of the workflow & voting RFC is mostly concerned with > defining stricter rules and more rigid procedures for the RFC process. It > increases the amount of bureaucracy and overhead involved in the RFC > process, making the RFC processes even less suitable for smaller changes > than it already is. > > The proposal I would like to present in the following is not my own idea, > it has been suggested by Anthony Ferrara. Because I found the idea very > compelling, I'm presenting it to the list now. > > --- > > Instead of making the RFC process more complex and rigid, we should > simplify and streamline it. The RFC process is reduced to only two rules: > > 1. All primary RFC votes require a 2/3 majority, while secondary votes > resolving implementation details may use a simple majority. (This is > already proposed in the voting margins RFC, so discussion about this point > should be directed into the corresponding RFC thread.) > > 2. All RFCs must have a voting period of at least 14 days, announced in a > separate [VOTE] thread. > > --- > > That's it. More notable than the rules itself are probably the two main > omissions: > > 1. There is no required discussion period. However, if an RFC vote is > opened without leaving enough time for discussion, then voters can and > should vote the RFC down on the grounds of insufficient discussion. > > The motivation for not having a fixed discussion period (but a longer > minimum voting period) is that RFCs come in many different forms and sizes. > Some RFCs are long and complex (such as the recent typed properties RFC) > and require more time for an adequate discussion. Other RFCs are simple and > of limited scope (such as an extension function addition) and do not > require extensive discussion. > > While a two week discussion period should remain a good guideline for > language-related RFCs, it is up to the RFC author to decide when opening an > RFC vote is appropriate. This will depend both on the scope of the RFC > itself and the activity of the discussion. (It is an unfortunate fact that > many RFCs receive their first meaningful feedback during the voting > period.) > > 2. There is no moratorium period after an RFC vote fails. If you think that > you have made significant progress on an RFC and resolved the issues that > made the previous vote fail, you can give it another shot at any time, > without having to wait out some fixed period. > > A failed vote does not (necessarily) mean that a feature is not wanted. It > is quite common for significant changes to fail on first vote, due to > issues in the initial proposal. A failed vote should not be a > discouragement, but a motivation to address problems expressed during > discussion or voting. > > It should go without saying that if you restart a failed RFC vote without > making substantial changes to the RFC, the result is unlikely to change in > your favor, and that continued misbehavior might be seen as spam. > > --- > > Essentially, this is about making the RFC process more suitable for changes > small and large, and empowering both RFC authors and the voter base to make > decisions that are appropriate for each RFC. > > What do you think? > > Regards, > Nikita >
