Afternoon Nikita, internals, In stark contrast to the proposals being made to make contributing to PHP more complex, slower, and burdened with bureaucracy: These are elegant proposals that I think will invite new contributors to join our ranks, which we no doubt need. They will allow current contributors to work faster on PHP without reducing the quality of their work or the input the rest of internals has on their contributions. I would hope that it would reduce the number of RFC that sit on the Wiki for years at a time also, but this is only my hope.
While these are quite drastic changes, let us try to resist a knee jerk response to them. >From me, it's +1 Cheers Joe On Sat, 2 Feb 2019 at 17:24, 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 >
