On 12.07.2018 at 10:10, Zeev Suraski wrote: > I think the problem is that there are cases where a 2/3 vote (or a vote at > all) doesn't make sense. True, we didn't have too many of those in the > past - but as we reform, I think it's important to take note of them. > Things which don't effect the language, but are more of a question of > preference - e.g., the decision to name phpng as PHP 6 vs PHP 7 - or for > that matter, deciding about a different release cadence. It's one thing to > add a language construct, to change the behavior of a function or to > add/remove an extension - this bubbles into people's code and we'd have to > live with this decision and its implications even in a decade's time - > while we can change our release cadence 3 times in between (if we wanted > to), and obviously whether phpng ended up being called PHP 6 or PHP 7 had > no technical meaning, only a 'marketing' one. Then there are also > implementation decisions - where things in the past have been a bit unclear > - and I think it's needed to clarify that such decisions (including > substantial refactoring, as long as there's no negative end-user impact) > should not require voting, but are up for the folks actually maintaining > that particular piece of code to decide. > So while I think non 2/3 votes would be uncommon, I do think we need to > have provisions for them - and voting to make everything 2/3 right now > without discussing the wider scope is wrong IMHO.
Perhaps the most important factor is whether we actually *change* something (e.g. new feature, deprecation, voting process), or whether we merely have to make a decision about something that is not covered by existing rules (e.g. next version 7.4 or 8). Of course, that's still somewhat vague, but might be a good rule of thumb. > Here's one example of our lacking rules (IMHO of course) - this has been in > the attic for just under a year, and now we're considering to just move it > to a vote within days. I don't think that should be possible :) The way I > see it, the voting period has to happen immediately after the mandatory > discussion period - and in a very predictable manner . If an RFC goes > dormant, there should be a new discussion period prior to voting. ACK. In my opinion, we would profit from a more structured and automated RFC solution. As it is now, the administration of the RFCs need too much manual intervention. For instance, marking an obviously inactive RFC as such, requires to manually edit the RFC overview, *and* to modify the status on the actual RFC. Also it would be benefitial, if votes closed automatically on the scheduled end date. Or regarding this very case: if there are no further replies to the RFC discussion thread for a week or so, the RFC should automatically moved to “inactive”, if it hasn't been moved to voting in the meantime. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
