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
