Re: [PHP-DEV] Capturing reasons for votes for historical sake?

  109159
March 20, 2020 04:36 smalyshev@gmail.com (Stanislav Malyshev)
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 smalyshev@gmail.com
  109160
March 20, 2020 11:31 marandall@php.net (Mark Randall)
On 20/03/2020 04:36, Stanislav Malyshev wrote:
> 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.
IMO "You have failed to convince me of the benefits" etc is exactly the kind of feedback that would be beneficial to authors, and by extension the wider process. There's lots of reasons to vote no after all. A vote that is rejected because the majority of those voting against don't see the benefit, has a very different future to one where those voting against had a specific objection that could be fixed with further development. Ultimately what we don't want is people spending lots of time trying to fix things which weren't the actual cause of failure, or worse, feeling fed up and losing interest in future contributions because they've failed and have no idea why. Mark Randall