On Mon, 25 Mar 2019 at 14:02, Dan Ackroyd <dan...@basereality.com> wrote:
> 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. > That feels pessimistic to me: is assumes that the author feels unhappy with the RFC failing, rather than taking on board the feedback. You already have a section headed "Don't be too put out if people don't like your RFC", and I think taking on board why people disagreed is a big part of that. > * 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. > That's certainly an issue, which I've suggested before in the form of an "Internals FAQ". However, it somewhat contradicts your previous point: you're now asking someone to do *even more work* after an RFC is rejected, to summarise it in a new format, in a new location. Either that's the RFC author, or it's someone interested enough that they could offer to write it in the RFC itself. As RFCs re-raising previous ideas, they can and should link to and explain their relationship to related RFCs, and this should probably be in the guidelines if it's not already. > > 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. > That's because it's an unhelpful comment. What does "terrible" mean? Other than "I assume you raised this in bad faith", there is *always* a more productive explanation than that - "I don't think this fits the style/purpose/scope of the language", "I think this would encourage/only be useful for bad practices", etc. > > 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. > Right, which is why I said I'm on the fence about *forcing* it, but that we should at least *encourage* it. > 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. > I don't think that follows. If the answer to "what would make you change your mind?" is "nothing", that's still useful feedback - it tells future RFC authors not to approach the suggestion at all. > 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. > Yes, the important thing is that the different reasons for no votes are captured, not that the exact counts for each are tallied. It's also a reason to add a text field to the voting widget: it doesn't invite responses in the same way a post to the mailing list thread does. I think a reasonable compromise is to say that voters should mention the reasons they're voting no if they have not already been mentioned; but that proposers should assume that votes without a reason are agreeing with previously stated reasons. That discourages voters assuming proposers can read their mind ("well, obviously it's bad") but also discourages proposer pestering and cross-examining voters. Regards, -- Rowan Collins [IMSoP]
