Re: [PHP-DEV] RFC Process: Should we hold two different votes?
Le 05/11/2014 00:58, Andrea Faulds a écrit : Good evening, A lot of RFCs have been rejected because, while they proposed a feature people would like, the details were problematic. This has lead to these features sometimes being considerably delayed. So, in order to do something about this, here’s an idea: Why not hold two different votes on an RFC, similar to how legislation is passed in the UK’s House of Commons? The first is on whether the general principle of the RFC is sound. Once that’s passed, it’s clear the feature is wanted, so time can then be spent scrutinising the details of the proposal and making them acceptable. Then, a second vote can be held, which approves the RFC as a whole, and its patch (like our current votes do). This way: * Authors know quickly whether a feature has sufficient support (reading internals doesn’t necessarily tell you anything, as votes and numbers of positive/negative emails rarely align), without having to necessarily have done everything before the final vote * Bad ideas are rejected sooner * Good ideas with flawed implementations may succeed in the first vote and fail in the second, meaning there’s a clear agreement that it’s wanted but not with this implementation, allowing another RFC with an improved approach to perhaps be made later Does this sound like a good idea? I really like this idea, which might help the RFC process in several ways: People (especially those who are not involved much in PHP internals now) might hesitate less before working on a principle RFC, knowing they won't have to code a feature (which might take days or more) that may just not be accepted. People not knowing C / PHP internals might suggest more principle RFCs. And if those pass with an overwhelming yes, it might be easier for them to find support from current maintainers to help work on the implementation. Also, it might be the right time to have different people voting, like: * Community (representatives of frameworks, UGs, ...), who are close to users but don't know C / PHP internals, should be able to vote on the principle RFCs. * While voting on implementation RFCs might be restricted to people who are closer to PHP -- mostly, those who can already vote today (like people with karma, or working on doc) Like you said in your last point, it also allows for a more iterative work on implementation, if a principle is accepted but an implementation is not. Though, I think there might not always be a need for implementation RFCs: if the implementation of a principle is trivial enough (like, for instance, adding a simple new function or changing the default value of a parameter), having to vote on the implementation could be a too heavy process. -- Pascal MARTIN http://blog.pascal-martin.fr @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC Process: Should we hold two different votes?
-Original Message- From: Andrea Faulds [mailto:a...@ajf.me] Sent: Wednesday, November 05, 2014 1:59 AM To: PHP internals Subject: [PHP-DEV] RFC Process: Should we hold two different votes? Why not hold two different votes on an RFC, similar to how legislation is passed in the UK’s House of Commons? I can think of two key reasons for why not: 1. It's more hassle. Unlike parliament members, this work is voluntary and we should be respectful of people's time. While dividing this to two votes may save the RFC proposer some time, especially in case his proposal doesn't pass the initial vote (so that they won't have to invest efforts in creating a detailed proposal), for everyone else, this is going to be a lot more hassle. 2. In my experience, there are few cases where the details of the RFC don't affect my yes/no decision. Voting 'in principle' without having the details bares very little significance. Also, running two votes may also create perception in some people's minds that if an RFC passed the initial vote, it's now only a matter of deciding between options, when again, given that the devil is in the details, once these details are known there may not be a majority in favor of the feature in the first place. All in all, I don't see why this extra step cannot be simply replaced with an informal discussion on internals, before the RFC is even written, to gauge people's response. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Process: Should we hold two different votes?
On Wed, Nov 5, 2014 at 9:35 AM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Andrea Faulds [mailto:a...@ajf.me] Sent: Wednesday, November 05, 2014 1:59 AM To: PHP internals Subject: [PHP-DEV] RFC Process: Should we hold two different votes? Why not hold two different votes on an RFC, similar to how legislation is passed in the UK’s House of Commons? I can think of two key reasons for why not: 1. It's more hassle. Unlike parliament members, this work is voluntary and we should be respectful of people's time. While dividing this to two votes may save the RFC proposer some time, especially in case his proposal doesn't pass the initial vote (so that they won't have to invest efforts in creating a detailed proposal), for everyone else, this is going to be a lot more hassle. 2. In my experience, there are few cases where the details of the RFC don't affect my yes/no decision. Voting 'in principle' without having the details bares very little significance. Also, running two votes may also create perception in some people's minds that if an RFC passed the initial vote, it's now only a matter of deciding between options, when again, given that the devil is in the details, once these details are known there may not be a majority in favor of the feature in the first place. All in all, I don't see why this extra step cannot be simply replaced with an informal discussion on internals, before the RFC is even written, to gauge people's response. Zeev I like Zeev's answer here, in the meaning that I have the feeling that everyone would vote +1 to add many cool things to PHP. But internally, things are sometimes hard to implement, or just too big to get in without changing all the code or may have bad interaction with each other (like RFC-A will conflict in implementation with RFC-B). People with no idea on how things work internally would probably vote yes to every new idea, without really measuring the impact it will have on the code base, both on development *and* maintaining the new code base (which is pretty hard to do as well). It's like saying I'm +1 for having flying cars, now people I let you do it and I have no idea on how that will work. I don't really like such direction. We are all here technical people, and should vote global decision with a clue on how this will technically be achieved. I'm afraid such a new process will see everybody say +1 to everything, but barely few people really working on the real things = the code. Or having RFC voted +1 , but finally abandoned because of implementation details that had not been clear enough in the RFC. Also, an idea cannot come without specification details, as-is , an idea is just an idea = something really abstract and useless until you give some implementation details. Saying yes just to say yes, it's like Christmas : yes, I do want tons of present. That does not make thing move forward Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
