Hi Legale, internals, > I want to say that even a small and fairly simple code change, which I proposed to push through the bureaucracy, was difficult.
This, I am afraid is all too common. Many many times, while working through github issues, I will be uncomfortable with making a merge for someone without input from internals. I would tell that person to start a discussion on internals and they would be flat ignored, their change dead in the water, and their reason to continue contributing evaporates. I think these proposals have a chance of reducing the occurrences of those situations: We all know that for less interesting topics, vote time is crunch time and that is when internals pays attention. If there is no necessity to wait for X weeks between proposing a change that nobody really has a desire to discuss, and opening a vote, that person can move forward quickly, we get our bug/quick fix faster, everyone is happy, especially that contributor who feels valued, and who feels that PHP's development process is geared toward actual development of PHP. Cheers Joe On Sat, 2 Feb 2019 at 18:02, Legale Legage <legale.leg...@gmail.com> wrote: > Hello, internals. > I am with you recently. But as a person with a fresh look, let me insert my > 5 penny coin. > About half a year ago, I knew about the C language only that such a > language exists. > The reason I decided to contribute is curiosity. So I'm probably not as > motivated > as some of other internals. I want to say that even a small and fairly > simple code change, > which I proposed to push through the bureaucracy, was difficult. So If RFC > process > becomes more difficult this "road" will be closed for some sort of random > people like me. > I hope this doesn't happen. > > Best regards, Ruslan > > 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 > > >
