Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
Hi! >> I want to say that even a small and fairly > simple code change, > which I proposed to push through the bureaucracy, was difficult. > I think this is what Nikita wants to change with this simpler procedure. > More RFCs even on smaller changes, so that more broad input can be > gathered before doing any kind of change. If so, this is IMO a bad idea. We don't need to make contributing harder, and have a formal two-week vote on each change. But, since the original quote talks about the past, then it can't be about RFCs, because in the past we didn't require RFCs for small changes (and shouldn't in the future). -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
On Mon, Feb 4, 2019 at 9:00 AM Stanislav Malyshev wrote: > Hi! > > >> I want to say that even a small and fairly > > simple code change, > > which I proposed to push through the bureaucracy, was difficult. > > We're discussing RFCs. Small and fairly simple code change does not need > an RFC. I think this is what Nikita wants to change with this simpler procedure. More RFCs even on smaller changes, so that more broad input can be gathered before doing any kind of change. > So either: > > a) this change is indeed small and simple, and does not belong to the > topic about RFC process, maybe about code review process, which is no > less important, but different talk. > > b) this change wasn't as small and simple as it appeared, it did require > the RFC, but you didn't know that. It's not your fault, no shame here - > but this shows the process worked as it should have. > > > 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. > > But how this relates to RFCs? Certainly not every patch needs an RFC. > > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
Hi! >> I want to say that even a small and fairly > simple code change, > which I proposed to push through the bureaucracy, was difficult. We're discussing RFCs. Small and fairly simple code change does not need an RFC. So either: a) this change is indeed small and simple, and does not belong to the topic about RFC process, maybe about code review process, which is no less important, but different talk. b) this change wasn't as small and simple as it appeared, it did require the RFC, but you didn't know that. It's not your fault, no shame here - but this shows the process worked as it should have. > 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. But how this relates to RFCs? Certainly not every patch needs an RFC. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
Hi! > Without a required discussion period, there could be slightly more > 'incentive' for RFC authors to respond as quickly as possible, to 'get > the discussion out the way'. I see it exactly opposite - since we have no quorum requirement, declaring the vote as soon as possible if a couple of people like your proposal and nobody objected yet seems to be winning strategy. By the time people analyze it more in detail and decide to voice objections the vote would be half done, and by the time they read the answers and want to continue the discussion, the vote would be finished. The right thing in this scenario would be to vote "no" immediately to any RFC that you didn't read yet and then start the discussion. This looks like rather wrong process. > It should be made really clear to people raising RFCs, that choosing > to have the minimum voting time, particularly if the discussion didn't > seem to produce a clear consensus can be, and possibly should be, > interpreted by voters as a reason to vote against an RFC. The problem, again, is, as you said, you don't read internals for weeks. I may also have periods where this happens, and I suspect others too. Now you come back and discover a blitz RFC already in the second week of voting, and you don't even know what it's about. So your choice is - read it and ask questions now, and take chance that the vote would be done before you even get an answer, or immediately vote "no" on all unknown RFCs and then maybe change your vote later. I don't think encouraging such things would create a good process or be encouraging to new RFC authors. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
Hi! > 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. I don't think this is a good idea. I see no scenario it improves - there's nothing in any RFC that can't wait for a week or two. However, there can be then a situation where somebody sees something as obvious and declares immediate vote, while others think it's not obvious at all but by the time they get there the vote is already done. I see absolutely no need to speed it up - the RFCs that ever got stalled didn't get stalled because of mandatory discussion period. This tries to solve a problem we don't have with something that may have bad consequences. > 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. Yes, some RFCs are simple. But none of them are urgent. And frankly if the proposed can't stay on track for two weeks > 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 This is also not a good idea - I can easily see unexperienced RFC author setting discussion period too short, because it's obviously a good idea, people that didn't have time to understand the RFC vote no, as you recommended, and then RFC fails not on merits but because of easily avoidable process issue. Better to avoid it upfront. > 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. Obvious failure scenario is to submit the same RFC with minimal cosmetic changes in hope detractors gave up or don't pay attention (either explicit or implicit - i.e. genuinely thinking the RFC was fixed but not actually fixing it) and essentially subverting the consensus. Coupled with no minimum discussion period I think this can happen a lot, especially given that many people don't have time to read all discussion on all topics on the list in real time (I don't for example). > 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. True, but I don't see how having cooldown period contradicts this. That's exactly when the problems have to be fixed. What's the point of putting up for vote an RFC that just yesterday have failed a vote (your reform allows this)? > 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. I do not see which decisions it enables that will improve the process. So far I only see the decisions that if enabled would likely to lead to more controversial decisions passing and more people being left behind or unable to properly participate in the process. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
On Sun, Feb 3, 2019 at 12:08 PM Nikita Popov wrote: > >> Personally, I find any proposal that does not deal with clearly defining >> voting eligibility not only questionable, but a non-starter, that has no >> parallels in any other major Open Source projects. >> > > Why? While I think the question of voting eligibility is worth discussing > (though I also don't consider the problem pressing in any way and think > that our current pool of voters works quite well, even if it may not be > what people had in mind back then), it is, just like the question of voting > margins, a rather independent issue from the remainder of the process. > Kris's point made me think about this issue, and I may still need to do some more thinking about whether the Workflow and Voting elements can be separated. It may be that they can. However, I don't see how the Voting element can be further separated into "voting eligibility" and "voting threshold", and other surrounding elements like a quorum which we may want to introduce. These are inherently interlinked. Moreover, there are elements where even the substance of the given RFC has - or at least *should* have - influence on the voting margins. Cases in point: - The PHP 6 vs PHP 7 naming RFC - The RFC to determine PHP 7's timeline - The PHP 5.6 EOL RFC - Any future RFC about timeline, naming, or other administrative, non-policy-binding decision These administrative decisions make no sense to require a 2/3 majority, but rather - a simple majority of the eligible voters, as ultimately, it's down to a matter of preference - without any long term (beyond a couple of years) commitments. The 2/3 majority was introduced to place a bias-towards-the-status-quo of the language, and make sure we don't create long-term commitments based on a temporary narrow majority. It simply does not apply in such cases. Further, it's difficult to separate the question of "what requires a vote" from a statement that "everything requires a 2/3 vote", although technically not entirely impossible. I'll do some more thinking about it and consider breaking the Workflow & Voting into two different RFCs if I can find an elegant way to solve these issues; But either way, focusing on the margins alone remains a non-starter for me. The problem with bundling together these changes is, if you will excuse the > political parallel, akin to bundling changes to copyright enforcement > together with a free trade agreement. Those two things have nothing to do > with each other (though of course interested parties will argue that they > are inseparable), but combining them into a single agreement makes it > feasible to pass changes that would not otherwise be considered acceptable. > At the same time, it also puts the overall agreement at the danger of > failing, due to parts that are not related to its core purpose. > As demonstrated above, they actually have a lot to do with each other, and do have certain inter-dependencies. Thankfully, in our world, neither is a series of books with countless chapters like free trade and copyright law tend to be. I realize that there are some people here that want to simply focus on the 2/3 margin issue and call it a day, but to me it remains a very partial fix to a much bigger problem - that realistically, if we don't tackle now while we've got people's attention - we'll likely never tackle. The suggestion that the new RFC makes life more difficult, compared to the >> current Voting RFC, is simply wrong. It is, in fact, very much the same - >> except it's a lot more well defined in terms of 'what happens if' - which >> in the years since the 2011 Voting RFC was enacted became a de-facto >> wild-west. >> > > As quite likely the single largest user of the RFC process, I beg to > differ. I think your perspective here comes about, because your use of the > RFC process is limited to rare, but large (in the sense of important) > proposals. However, that's not the case for all or even most RFCs. It is > already the case that RFCs are cumbersome for smaller changes, and all > active contributors I know (apart from cmb maybe) will go out of their way > to avoid going through the RFC process if it is at all avoidable. It is > something of a social faux pas to tell another core contributor on a PR > that their change might benefit from an RFC, because that generally means > that the change will be dropped dead in the water instead. > > I think that we *should* encourage the use of RFCs for less significant > changes, because it is useful to have design considerations spelled out in > more detail than a two line commit message. Your proposal does not make > things much more complicated, and doesn't make the RFC process take much > more time. But it increases the marginal costs just enough to make RFCs > even more annoying than they already are. You edit your proposal a few > times at inopportune moments and bam, you have to wait one and a half > months before it can land.
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
On Sat, 2 Feb 2019 at 16:24, Nikita Popov wrote: > > What do you think? > All RFCs must have a voting period of at least 14 days, announced in a > separate [VOTE] thread. That sounds mostly good to me. My feedback would be: First, I wish people (including RFC authors) took more time to think about other people's feedback before replying. There have been some discussions around RFCs where people appear to be sending email responses within minutes of receiving them, which gives the appearance of not carefully evaluating that feedback, and trying to dominate a conversation through volume. Without a required discussion period, there could be slightly more 'incentive' for RFC authors to respond as quickly as possible, to 'get the discussion out the way'. I can't think of a way to codify rules against this behaviour. But perhaps it could be noted in an updated RFC document something like "to allow careful consideration, discussions should be allowed to take time to resolve. It is more appropriate to send a carefully considered response the next day, than to send a quick response." Second, two weeks minimum is still quite short. This may astound people, but I often go weeks at a time without wondering what is happening in PHP internals. I believe other people might also have a life outside of PHP internals. It should be made really clear to people raising RFCs, that choosing to have the minimum voting time, particularly if the discussion didn't seem to produce a clear consensus can be, and possibly should be, interpreted by voters as a reason to vote against an RFC. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
On Sunday, February 3, 2019 4:07:46 AM CST Nikita Popov wrote: > On Sun, Feb 3, 2019 at 6:18 AM Zeev Suraski wrote: > > The suggestion that the new RFC makes life more difficult, compared to the > > current Voting RFC, is simply wrong. It is, in fact, very much the same - > > except it's a lot more well defined in terms of 'what happens if' - which > > in the years since the 2011 Voting RFC was enacted became a de-facto > > wild-west. > > As quite likely the single largest user of the RFC process, I beg to > differ. I think your perspective here comes about, because your use of the > RFC process is limited to rare, but large (in the sense of important) > proposals. However, that's not the case for all or even most RFCs. It is > already the case that RFCs are cumbersome for smaller changes, and all > active contributors I know (apart from cmb maybe) will go out of their way > to avoid going through the RFC process if it is at all avoidable. It is > something of a social faux pas to tell another core contributor on a PR > that their change might benefit from an RFC, because that generally means > that the change will be dropped dead in the water instead. > > I think that we *should* encourage the use of RFCs for less significant > changes, because it is useful to have design considerations spelled out in > more detail than a two line commit message. Your proposal does not make > things much more complicated, and doesn't make the RFC process take much > more time. But it increases the marginal costs just enough to make RFCs > even more annoying than they already are. You edit your proposal a few > times at inopportune moments and bam, you have to wait one and a half > months before it can land. That's okay if you're trying to introduce a JIT > in PHP, but if you just want to add a function, that's the point where you > say "Why do I even bother with this?" > > Regards, > Nikita If I may, it seems like the intended goal is to ensure that a proposal gets "enough" attention, "enough" time for people with other priorities to find, read, digest, and decide on it, and to avoid last minute changes in the RFC so that people don't fully realize what they're voting on (for some definition of "enough"). To that end, what about simply a "fallow period" before a vote can be called? To wit: "Once an RFC has been announced, the proposal may call a vote on it at any time provided that there have been no substantive changes within the past 2 weeks. If there is reasonable dispute over whether a change is 'substantive', then it is assumed to be substantive." That assures that there is always at least a 2 week discussion period, but you could still go from proposal to vote in 2 weeks. It also ensures that if you've read an RFC in the last 2 weeks when the vote is called that you're still up to date. However, minor changes (wording, revising an argument for something but not changing the actual thing, etc.) don't cause an RFC to sit in limbo for months. Of course, if the RFC is still changing regularly then that would continue to kick the voting period further down the line, which is what you want in that case since it's still being revised. It also has the advantage of being really short and easy to grok. --Larry Garfield signature.asc Description: This is a digitally signed message part.
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
On Sun, Feb 3, 2019 at 6:18 AM Zeev Suraski wrote: > > > > -Original Message- > > From: Nikita Popov > > Sent: Saturday, February 2, 2019 6:24 PM > > To: PHP internals > > Subject: [PHP-DEV] Alternative voting reform: Streamlining the RFC > process > > > > 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. > > Personally, I find any proposal that does not deal with clearly defining > voting eligibility not only questionable, but a non-starter, that has no > parallels in any other major Open Source projects. > Why? While I think the question of voting eligibility is worth discussing (though I also don't consider the problem pressing in any way and think that our current pool of voters works quite well, even if it may not be what people had in mind back then), it is, just like the question of voting margins, a rather independent issue from the remainder of the process. I think that these discussions and RFC can and should be split up into the question of voting margins, the question of voting eligibility and the question of the RFC procedure itself. While these things are of course related, they can also be decided independently. The problem with bundling together these changes is, if you will excuse the political parallel, akin to bundling changes to copyright enforcement together with a free trade agreement. Those two things have nothing to do with each other (though of course interested parties will argue that they are inseparable), but combining them into a single agreement makes it feasible to pass changes that would not otherwise be considered acceptable. At the same time, it also puts the overall agreement at the danger of failing, due to parts that are not related to its core purpose. I understand that there is also benefit in deciding related questions in conjunction, in that a decision in one area would only be acceptable conditional on a decision in another area. However, to get back to the specific topic here, this does not appear to be applicable. For example, your changes to the RFC workflow could be implemented independently of the voting eligibility changes and vice versa. The only possible dependency I see is that all proposals benefit from having the 2/3 voting margin as a baseline (which is consistent with that RFC proceeding first, of course). > The suggestion that the new RFC makes life more difficult, compared to the > current Voting RFC, is simply wrong. It is, in fact, very much the same - > except it's a lot more well defined in terms of 'what happens if' - which > in the years since the 2011 Voting RFC was enacted became a de-facto > wild-west. > As quite likely the single largest user of the RFC process, I beg to differ. I think your perspective here comes about, because your use of the RFC process is limited to rare, but large (in the sense of important) proposals. However, that's not the case for all or even most RFCs. It is already the case that RFCs are cumbersome for smaller changes, and all active contributors I know (apart from cmb maybe) will go out of their way to avoid going through the RFC process if it is at all avoidable. It is something of a social faux pas to tell another core contributor on a PR that their change might benefit from an RFC, because that generally means that the change will be dropped dead in the water instead. I think that we *should* encourage the use of RFCs for less significant changes, because it is useful to have design considerations spelled out in more detail than a two line commit message. Your proposal does not make things much more complicated, and doesn't make the RFC process take much more time. But it increases the marginal costs just enough to make RFCs even more annoying than they already are. You edit your proposal a few times at inopportune moments and bam, you have to wait one and a half months before it can land. That's okay if you're trying to introduce a JIT in PHP, but if you just want to add a function, that's the point where you say "Why do I even bother with this?" Regards, Nikita
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
> Am 03.02.2019 um 06:18 schrieb Zeev Suraski : > >> -Original Message- >> From: Nikita Popov >> Sent: Saturday, February 2, 2019 6:24 PM >> To: PHP internals >> Subject: [PHP-DEV] Alternative voting reform: Streamlining the RFC process >> >> 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. > > Personally, I find any proposal that does not deal with clearly defining > voting eligibility not only questionable, but a non-starter, that has no > parallels in any other major Open Source projects. > > The suggestion that the new RFC makes life more difficult, compared to the > current Voting RFC, is simply wrong. It is, in fact, very much the same - > except it's a lot more well defined in terms of 'what happens if' - which in > the years since the 2011 Voting RFC was enacted became a de-facto wild-west. > > It may initially feel warm & fuzzy to have vague, fluid rules that are > remarkably open to interpretation. But it's not a good idea at all. > > Zeev Hey Zeev, why is dealing with voting eligibility a requirement for a new RFC dealing with the RFC process? Everything which is not dealt with, is simply inherited from status quo. And I personally don't think the current rules regarding voting eligibility, while possibly not perfect, are in such a bad state that they immediately need a rework. The door to concrete, separate proposals fixing voting eligibility is not closed with this RFC. You are always free to open a new specific RFC and discuss about a voting eligibility proposal. In addition, the newly proposed RFC here is absolutely not vague. It is pretty well defined, showing a few clear boundaries. For everything else it is the task of the voter to establish whether a RFC is ready and shall be voted in as is. It's precisely that which makes a great voting process. In particular with a 2/3 required majority, I strongly doubt that bullshit RFCs which are quickly proposed and moved to vote, will ever be accepted. I trust our voters enough to know when something should definitely not be accepted. And I strongly hope that you are not lacking faith in us PHP RFC voters, that you feel like you couldn't trust us to apply sensible judgement to each RFC. Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
> -Original Message- > From: Nikita Popov > Sent: Saturday, February 2, 2019 6:24 PM > To: PHP internals > Subject: [PHP-DEV] Alternative voting reform: Streamlining the RFC process > > 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. Personally, I find any proposal that does not deal with clearly defining voting eligibility not only questionable, but a non-starter, that has no parallels in any other major Open Source projects. The suggestion that the new RFC makes life more difficult, compared to the current Voting RFC, is simply wrong. It is, in fact, very much the same - except it's a lot more well defined in terms of 'what happens if' - which in the years since the 2011 Voting RFC was enacted became a de-facto wild-west. It may initially feel warm & fuzzy to have vague, fluid rules that are remarkably open to interpretation. But it's not a good idea at all. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
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 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 >
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
Just a quick note ... I should say that bug fixes should not require an RFC at all, but the line between bug, quick fix and feature is blurry. Sometimes it is necessary to gather consensus and voting is the most effective way we have to do that. Cheers Joe On Sat, 2 Feb 2019 at 18:13, Joe Watkins wrote: > 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 > 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 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
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
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 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 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
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
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 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 >
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
сб, 2 февр. 2019 г. в 18:24, Nikita Popov : > 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
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
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 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 >
