On Mon, 25 Mar 2019 at 13:30, Rowan Collins <rowan.coll...@gmail.com> wrote: > > One suggestion for an additional section: update the RFC with feedback, > particularly if it is withdrawn or rejected.
I think that knowledge could live separately from the RFCs, which is why I'm maintaining https://github.com/Danack/RfcCodex The reasons for doing it separately are: * the last thing someone wants to do after having their RFC voted down is spending more time documenting it. * some ideas have had multiple RFCs, while other ideas are proposed on the list without having a formal RFC. For both scenarios documenting why it failed in a single place needs to be elsewhere than an RFC page. > It has actually been suggested multiple times that > voters *should* justify their votes, Yes. However that is unlikely to provide a useful conversation. Thinking that the RFC is just a terrible idea is always a valid reason to vote no. Having people say that "this RFC is terrible" doesn't lead to a productive conversation. > so that it's clear whether a future RFC could address the > perceived problems, I don't believe forcing people to explain their votes actually does that. It does something quite similar, of forcing people to try to articulate how the RFC needs to change for them to change their vote from a no to a yes. At least that is how I have perceived the intentions of people who have asked for 'no' voters to explain their vote. The problem with that is that some RFCs are just fundamentally not good and so there isn't any changes that could be made that would make the RFC acceptable. In those scenarios, putting pressure on 'no' voters to say what needs to be fixed, is just putting pressure on people to not vote no. Additionally in some of the RFC discussions we've had, where the author has asked for people to explain the 'no' votes, the reasons have already been said clearly in the discussion phase. But the RFC author has dismissed those reasons as 'invalid'. Again, trying to force people to justify their reasons, to the satisfaction of the RFC author isn't going to lead to a productive conversation. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
