On Thu, Jul 12, 2018 at 7:38 AM Joe Watkins <pthre...@pthreads.org> wrote:
> Zeev, > > > I think our voting rules are in need of a much thorough review than just > pushing the limit to 2/3 - which also IMHO doesn't tackle the difference > scenarios that exist out there. > > Agree, they need reform, but rather than trying to discuss and pass a > monolithic RFC that tries to solve all problems, I chose (a year ago) to > start here; Simply raising the bar simplifies the rules we currently have > and so simplifies their reform (in detail and process). > 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. Also while generally I very much agree with the 'agile' sentiment of fixing things gradually instead of in one monolithic step - our voting rules are so lacking that it feels like putting a band aid on a gunshot wound... By the way, I still think there's a lot of work that still needs to happen on my proposal - perhaps factor in quorums, how votes relate to deadlines - we can probably learn quite a bit from our experience including in recent weeks - but I think it's mature enough for others to comment on it, and I would be very happy for others to join me in drafting it. I'm not following your logic for further delaying voting on this RFC, in > fact I don't see any logic, just an assertion ;) 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. On my logic for not dealing with it right now, it's twofold: 1. There's too much activity going on around last minute 7.3 RFCs for many people to have the bandwidth to discuss it in a serious manner. 2. It seems wrong to change the rules mid-flight in a way which might affect the current 7.3 votes which are already under way (not that I think it will affect most of them - but it still seems wrong). Sorry for not actually mentioning that previously :) Zeev
