Hi! > Well a significant part of the purpose of the RFC is to make the case > for why it *should* be done, and the benefits in doing so, and only to
And the necessity of making the case also assumes it may, despite all the effort, fail. The community members may remain unconvinced the change that is proposed is beneficial. This is, ultimately, always the reason to vote no. > To vote yes is to state your overall agreement with the arguments made > in the RFC. If you've read up and want to vote "no", I think that is > perfectly fine and should be fully encouraged, but do the decent thing > for your fellow developers and explain why so they're not left trying to > guess. As I noted, the default reason is always "the author of the RFC failed to convince this change is necessary or beneficial". If somebody tries to sell you something, you may have some specific flaws to point out and may be even be fixed, or you may not be interested in the idea at all. In the latter case, it's also OK to say you aren't interested and in general case, you don't owe any improvement suggestions or detailed explanations about that. The proof of need - especially for a mature software like PHP - is always on the proposer. > > Ultimately, how can an RFC ever be improved to be more widely acceptable > if the people voting in the negative don't give feedback? Sometimes - not always, but sometimes - the best improvement to the idea is just not doing it. It's a valid outcome too. In the process of making new things, everybody is bound to have a bad idea once or twice. It's completely normal and once it is discovered it's a bad idea, there's no problem in discarding it and moving on. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
