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
