On Mon, 25 Mar 2019 at 13:04, Dan Ackroyd <dan...@basereality.com> wrote:
> I've written some suggestions on people could have more productive > conversations which I'm going to maintain here > (https://github.com/Danack/RfcCodex/blob/master/rfc_etiquette.md), and > have attached to the end of this email. > Hi Dan, Thanks for putting this together, I think it's a great addition to the current RFC guidance. The only part I can see being controversial is this: > It isn't the responsibility of voters to explain why they're voting no. It has actually been suggested multiple times that voters *should* justify their votes, so that it's clear whether a future RFC could address the perceived problems, or if similar RFCs are likely to receive the same votes against. I'm on the fence whether making it a hard requirement is reasonable, but I don't think we should enshrine the opposite. One suggestion for an additional section: update the RFC with feedback, particularly if it is withdrawn or rejected. If someone comes along with a suggestion that's been discussed before, it's really helpful if we can say "see this page for why it didn't happen last time, and see if you can fix those issues", rather than just "it didn't get very far before, but we can't remember why". This is something I intend to do with my own "locked classes" RFC: I'm probably going to withdraw it because I don't have time to rework it, but will try to summarise where a new RFC could pick things up. Regards, -- Rowan Collins [IMSoP]
