I'm generally not a believer in "more tooling fixes broken things", but I have 2 cents to this. FWIW, I'm a believer in "more tooling supercharges working things". We should get RFC changes in and then pull the tools.
I would like to write down a couple of thoughts on recent debates. I'll want make clear that I don't necessarily agree with all the feelings noted down there, but I believe I have seen them. I don't want to sidestep and pull my debate here. My opinions on those debates can be found there, I don't want to discuss the direct subject matter here.
Turbofish
This is an RFC, so an open debate is encouraged and wanted. As painful as it is, RFCs, even the FCP period, are meant to guide the discussion. I like the discussion as an investigation subject because there's a base agreement that turbofish can go away, but a lot of disagreement on the methods.
I think this one is the classic case of a discussion that may have overlooked a couple of tensions points. Those items have the potential to ignite at any breaking point, in this case it entering the FCP phase. The more tension points you collect, the more problematic the discussion will become, especially if people don't agree on the tension point.
I think there's potential pain points here:
-
A lot of people have the feeling that this is not a priority, which sets a base disagreement in pushing it forward.
1.1. The feeling that the change is to miniscule for the amount of work involved.
-
It occured to me that some people, Graydon included, consider the LL(1) parser a language feature, not an implementation detail. Given that this is a fact known to many and promoted in the early days of Rust quite a bit, I can see their point. At least, they consider parser complexity a property of the language.
2.1. Some people expressed the notion that this might act as a floodgate, leading to gradual increase over time after years of stability in that area.
2.2. Dismissing tone towards people voicing that concern, even without them clearly stating that notion (through inability to express it or ortherwise) has not removed the tension.
-
The motivation became fuzzy through relying on metrics hard to measure (learnability, readibility), which make it easy to disagree on a level that can't be moved beyond.
-
Some people with relevant opinions, even project members, missed the debate until way too late. This impacts me, as I have to carefully choose the time I spend on RFCs and cannot follow all.
-
Turbofish is a huge emotional target. Who kills turbofish kills a legend. I'm not joking here, anp calls this "emotional real estate". People have a good gut feeling for situations like this that implementers often miss.
All of these, in my opinion, need different action. I have a couple of actionable suggestions:
-
More Roadmapping and more sticking to it. Especially creating "negative space". While some people will not enjoy having their feature on hold, the ability to point to "this is an RFC under Roadmap point X" is a powerful one. As our open roadmapping process works better than the RFC process, this helps a lot. Maybe topic-specific mini-roadmaps could be introduced, outside of the yearly cycle. "Improve language ergonomics" could be such a thing, giving a better view on what else might be on the table, which might also benefit from the changes in the RFC.
-
This needs, IMHO, to be investigated and clarified. If parser complexity is an implementation detail, anything goes. If it is considered a language feature, a change of parser complexity needs to be RFCed separately.
2.1. Along the same lines, even if the change goes ahead, we should set a clear boundary and then RFC from there.
2.2. I'm sorry that I haven't done so more clearly, but we should also call project members out more harshly if they aggressively discuss. I've seen this happen to a lot of people here (me included), a voice that says "step away from the keyboard and take a walk" helps a ton. Discussion guidance documents can also help.
-
We should improve on these notions. Given that both are a research problem, that doesn't make it easy.
-
Actively pulling in people from relevant groups early. Let's set up mention groups for specific categories of problems in RFCs. This pushes these discussions more to the front and makes sure that people we know of are included. It doesn't bar community members to participate, but they may see their concerns addressed more early.
-
Frequent rechecking if we don't go off track by absolutely wanting to solve a hard problem just for the sake of it. This is a hard problem and there will be many disagreements on where the cut-off is.
async/await
This is a different case: we're talking about an RFCed feature, with a final decision to be made about a syntax detail.
The discussion becomes hugely draining, due to a large discussion on a feature that needs to be done. Many opposing opinions also means there will be a lot of bad emotions about the final decision, whatever that may be. It feels like an RFC debate, but it actually isn't, the RFC is written and accepted
- The discussion wanders of into people discussing a ton of aspects, including coming up with all-new ideas, blowing up the decision space.
- A lot of discussion works on very small code examples, many just discussed as pure code, not what it represents. Also, some of it is based on current API (e.g. of
reqwest), which could be changed. - There's a growing feeling of low appreciation by the maintainers actually building the feature, as their work is steamrolled by new ideas.
- The debate is very open, including ideas that need to be separately RFCed (postfix macros, method-like macros)
- Pressure is high, as the feature is delayed.
- Again, high emotional real estate, this time on the community side, you'll be influencing one of the biggest new Rust features in a very visible fashion.
Here's a couple of suggestions here:
- Consent-finding processes often fail due to this aspect. One strategy is to name all solutions that are up for debate upfront, allowing only discussions on those. As this is not an RFC, this privilege should lie solely on the implementing team. New suggestions may only be searched if none of the suggestions is found acceptable. There's a couple of consent/consensus techniques around this. Make more effort to introduce discussions and what should be discussed and what not.
- Make clear expectations on what a discussion example needs to fulfil, maybe provide a template. Raise the bar of effort.
- Make it clear who's finally deciding stalemates. IMHO, in this case, it should be boats and cramertj.
- In this phase, anything that hints at needing and additional RFC should be curbed, unless new suggestions have to be searched.
- This should inform the decision: the damage to ecosystem by delaying the feature further has to be factored into all suggestions that vastly improve scope of work.
- I think it should be clarified in some way that this feature is a huge part @withoutboats work and ultimately both their responsibility and their credit to take. Take up available emotional estate.
Additionally, we should make it clear why these actions are taken and why we believe they improve the community interaction.
To make it clear: I see a huge problem in maintainer burnout from allowing inflating discussion space. We need to get more clear about when is the time for what and find ways to keep discussions in those boundaries. The syntax was eRFCed in 2017 and RFCed in 2018. Substantial deviation from what's in the RFC (e.g. postfix macros) should be separately RFCed.
Also, as a final note, I think GH is becoming a problematic medium for this, especially it's handling of quotes and encouragement of quick and fast responses with low context.
I hope these thoughts help in finding a way to better lead those discussions, by discriminating better and writing up playbooks on how to lead them. They serve as a kickoff, not as a final answer.