Hi! Reading the RFC, here's my thoughts:
1. Do we really need different classification of changes? I think having one single vote procedure would have larger benefit, and RFC that fails 2/3 requirement would be suspect anyway. RFCs can have parts - "whether we do it" and "how exactly we do it" - the former would be 2/3 requirement, the latter can be simple plurality even - e.g. if we decide to have an extension for libfoobar, that should have 2/3 vote, but then decision between whether to name it foobar or barfoo can be decided by majority or plurality. 2. The RFC deals simultaneously with two questions - whether vote is needed for certain changes and how the voting process is performed. I am not sure these issues should be handled together - they are substantially different. 3. Requiring patch for each RFC is kinda high bar - if I propose some functionality, I don't really want to spend months on implementing it only to see it voted down and my time completely wasted. 4. I am feeling a bit uneasy about any change requiring a week's waiting period - read literally, that means you'd better not fix typos in your RFC if you don't want for it to take forever, and certainly not address feedback like "X is not documented enough" or "Y description could be clearer". I do think substantial changes require discussion and in some cases even full re-launch of the RFC but requiring a week's wait for any change, even the trivial one, seems going to far to me. 5. The RFC changes [VOTE] subject that we've used before to [RFC VOTE]. I know it's a nitpick but is that change necessary? If people had filters to match such things, the change would break them and I'm not sure it improves anything. 6. I think we should allow longer voting periods than 1 week. In fact, I'd go as far as recommend longer minimum even, but even if we keep minimum of 1 week, there would be cases - holidays, conferences, sports events ;) - where a lot of people could be offline for prolonged time and 1 week won't be nearly enough. 7. For the sake of clarity, we should define what 2/3 threshold means - is it: a) $voted_yes >= 2 * $voters / 3 b) $voted_yes > 2 * $voters / 3 c) $voted_yes >= floor(2 * $voters / 3) + 1 d) something else? 8. 6 months seems a bit too long for rejected RFC. I'd probably shorten it to something like 2 months, maybe even less. But include the language that the feedback provided on the previous discussion stage should be addressed (of course we can't control it, but we can establish the norm). 9. I'm not sure I understand the purpose of "RFCs that targeted the next mini version, and are moved back to the Discussion Stage after a Hibernation Period, may not target that same mini version" - why not? 10. I like the idea of no discussion during vacation time - though, frankly, I've been using some vacation days to catch up with Internals in the past... 11. 5 people to object to restart vote looks relatively high, and in fact the procedure looks rather complicated... Is it a frequent occurrence that needs special mention? 12. I think we need more work on eligibility criteria. Specifically, I think we should aim for: a) including everybody who made contribution to PHP project in the past, if their contribution are recent or they plan to keep contributing (simple public declaration of intent should be enough). I am not sure yet if we need minimal conribution size - depends on whether it actually changes anything or not (should we make some tools that allow us to see what changes with and without minima?). I think the process should be biased to the side of inclusion - one more voter wouldn't hurt, but one person unjustly excluded from voting would feel very bad and it may lead to bitter discussions that don't help anything. b) including important non-code contributors c) having the mechanism to periodically remove participants that have left the project and have no intent to contribute anymore, and to restore their voting eligibility if they come back d) as I said before, I certainly do not feel comfortable with including all 50-strong PHP-FIG membership, and all future members, given that we have no say about how they are selected. We may want to think about mechanism to include their feedback somehow but current proposal seems to broad. 13. Quorum question would be an interesting one to tackle. Some votes are being decided by very low number of votes, however I am not sure whether or not it's a problem... Probably will have more, but it's long enough for now :) Also, I realize the above has a bit of a negative tint because I have mostly addressed things that I disagree with or think may be improved, so I want to explicitly state that I think it's great we are discussing these things, and explicitly thank Zeev for working on it. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
