To be clear, I fully agree with this. What I worry is point 8 and 10. If I imagine I’m in the position to decide: I’m looking at the RFC and deciding if I should OK it or not. I read the proposal. Then go through the comments. And I have to make a decision. Sometimes, it is clear-cut. But sometimes it feels like I’m not sure ‒ there were many comments, emotions, many people who want the proposal and many that don’t. How do I decide? I don’t know if you people in the teams have some way to handle this, but for me, my gut feeling would have a lot of say in the decision ‒ and my gut decides on quite many things, not all of them really relevant to the question ‒ like, what argument feels stronger, which is not always which one is better.
I’m trying to suggest to include things in the main RFC text (because it’s the part that influences the decision most) to include most of the relevant information ‒ to guide the subconsciousness to decide more on facts and less on feelings and random influences. Because, no matter the length of the process, this is the point where the actual decision is made.
With the risk someone will get too attached to specifics, the one I had in mind was 1925. The lesser problem is I don’t like it. The fact there were many thumbs-down is some indication about people’s feelings about it, but that’s also not my main concern. What I find most disturbing about it is (It’s always easy to criticize in hindsight, so I apologise for doing just that ‒ but I want to provide the specifics asked for):
- The RFC is missing several sections. Why wouldn’t they apply? And why nobody (if I scanned the comments correctly) even mentioned it and asked if there really are no downsides to that?
- The RFC was merged in confusion about which version people commented on, because there were two very different versions during the discussion.
- There was no strong argument for it. Making it easier for macros was mentioned in the comments, but nobody actually brought an example of a macro that showcases that. The RFC wasn’t updated to reflect that.
- The thumbs-down count was dismissed as unimportant, on the bases that they were probably for the leading+trailing version and without further investigation.
- It was stabilized without seeking further feedback from community, even though that was mentioned after merging it and even though there was the confusion.
I wouldn’t have counted it as an error in the process if the RFC was better written, or if ‒ upon the confusion ‒ the discussion was restarted (eg. the merge request closed and a new one started) to gather new thumbs-up/thumbs-down counts instead of just dismissing them (I know this is only one of the decision inputs, but still) and if it was clear how the decision was made. In that case I would still not like the feature, but would be content knowing that it was reached in a fair way and pros and cons properly weighted, so I’m just the one being weird. But looking at so many „oddities“ around it, it feels somewhat unfortunate, and some reactions from community suggest I’m not the only one. In other words, I believe in this case, the decisions were influenced more by some random noise than actual facts, because most of the discussion has a lot of interference. And I’m still not sure what problem was this meant to solve.
Now, I don’t want to overblow this one, because the feature itself is no big deal. But it shows there can be errors in the process. And I think it also somewhat undermines the trust in the process, which is unfortunate. I could probably come up with few more examples of something that felt like the consensus wasn’t really clear and strong, but I think it’d only be twisting knifes in wounds and I don’t want to do that.
I don’t really want to change the process itself ‒ as you say, it is working well most of the time. I just want it fed with better input. Currently I believe the best way would be to compose some micro-guide (or a checklist) for RFC authors. As I argue above, I think it should help (somewhat, it wouldn’t be a silver bullet, of course), but I guess nobody knows without trying. So in that sense, is there any risk in trying to compose such a short guide? I can give a shot at first version, but I’ve only read RFCs, not written them (I have the editor open right now, with the RFC for announcing things about to stabilize in TWIR, but that’s a tiny one and I have no idea yet how that’ll go ‒ but if there was a guide to help me with that, I’d definitely go and read it) ‒ so to have any validity, it’d need some help from others, who do write RFCs.
So, if I start writing it, are there people who would like to help? Or, is there some reason why I shouldn’t do that?
That’s good to know, with that knowledge, the process does look more balanced. Are these things documented somewhere (eg. how the teams reach their decisions)?