сб, 2 февр. 2019 г. в 18:24, Nikita Popov <nikita....@gmail.com>:
> 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 > Hello Nikita, internals, as a user-land developer and at least a decade reader of internals (and basically seen it all on here) and occasional poster, I highly approve of your proposal. I like it very much. To me, this represents a great move towards a less bureaucratic and edge-case prone process, that requires a high bar of approval from the internal's community and ability to iterate on complex RFC's at a decent pace and not hinder small easy changes that are relatively a no-brainer like it is right now. I literally see no holes or edge cases in this proposal. Though I can't vote, this is a big +1 from me and a hope that this will calm down internals list going forward after what has happened this past week. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
