Thoughts on RFC/stabilization reform in 2019

While I really want this to be a good idea, I’ve personally avoided proposing separation of problem from solution because in practice it’s often impossible to decide “this problem isn’t serious enough to warrant a language change” without knowing what the language change to solve it would actually look like. For example, I was on the fence about Ok-wrapping and related issues until https://github.com/rust-lang/rfcs/pull/2107#issuecomment-323515036. Having a concrete RFC to study was what it took to finally convince me it’s just not worth the cost.

But there’s probably something salvageable there about deliberately not engaging in surface debates when deeper potentially blocking issues remain unsolved. In the anon enums case, I remain unconvinced they’re worth their cost (and I’m fairly sure that’s not an uncommon opinion), so we should really not be debating the details of their syntax yet. The real debate probably ought to be “do nothing” vs enum impl Trait vs “anonymous enums” or something like that, but iirc that’s not the debate being had on those RFCs right now.

3 Likes

Collapsing comments and having a proponent/opponent system are really interesting ideas! I especially like the key point you pulled out: optimize for reading.

Perhaps one modification of the ToC idea would be to add some sort of rfcbot summary command that appends the body of the post to the OP and collapses all other comments. This would allow people to get the github email notification too.

Regarding frequency of summaries, I still think it should be after a certain number of comments, especially after all the initial typo comments subside.

I tend to agree that separating the design from the problem might make it hard to evaluate. On the other hand, there is something to be said for finer-grained roadmap-like discussions where we discuss future directions and explicitly acknowledge certain problems we would like to work on.

Currently, I think that is the main role of eRFCs. Going forward, perhaps the right balance would be to use the annual roadmap to layout a broad vision, and use eRFCs to flesh out parts of it by choosing specific problems to focus on?

I don't know how to do "complete" and "concise" in the same thing.

I do like the the proposal the the For and Against summaries are made by different people. My experience is that trying to summarize both side just gets people mad at me.

2 Likes

I'd also be afraid you'd run into cases where someone identifies a problem that is completely legitimate, but either very difficult or impossible to solve. This can quickly devolve into a completely nonconstructive discussion arguing whether a solution exists, rather than debating the merits of a given solution.

1 Like

I’ve started a prototype implementation of some sort of @rfcbot summarize command here: https://github.com/anp/rfcbot-rs/compare/master...mark-i-m:summaries?expand=1

Basically one uses it as follows:

@rfcbot summarize

This is my summary.

Blah blah blah
- a
- bunch
- of
- points

This would cause rfcbot to update the OP by appending the summary (i.e. everything from “This is my summary.” to “- points”.

Does anyone know how to use the Github API to collapse comments? Also, any other feedback is appreciated.

There is no API for that AFAIK.

1 Like

Perhaps "concise" is too strong. I think that anything can be made more verbose, either by adding redundancy, or just by explaining the same things but more laboriously, and the complete summary should be neither of those things. So I suppose what I'm looking for is the "minimal complete summary".

Yes - I hope this would avoid a problem where people who were against the RFC felt like their points were not being understood or not being heard because they were all going through the RFC author.

1 Like

I wonder whether it would be clearer to have rfcbot always post the first reply to any pull request (à la rust-highfive) and then update that post, rather than editing the original. It's a fairly minor difference, but it seems like there'd be less room for error that way.

5 Likes

That was my original proposal in the other thread, but it seemed simpler to do this. Is there a particular problem or error you had in mind?

The kind of complaints I've gotten on summaries have included disagreements on whether two points are the same, and thus the second should have been mentioned.

I like aping the Agile Manifesto as a way to phrase things such that they lead to actual guidance rather than lists of adjectives: "While we value both AA and BB, in situations where they're in conflict we will prefer AA over BB". That's way harder to get agreement on, but it's also way more useful.

(Or, said otherwise, if there are no arguments for the opposite it's unnecessary to state: for example, nobody will say that summaries should be "incomplete and loquacious".)

2 Likes

While we value concise and complete summaries, in situations where they conflict, I think we should completeness. Otherwise, people have to read arbitrary parts of the thread anyway despite the summaries.

1 Like

I’ve been thinking about a possible change to the rfcbot fcp process:

Rather than being opened with a specific direction in mind (merge or close), I think proposing FCP should allow each team member to say “merge” or “close”, and then the team needs consensus to move forward in that direction. If all but 1-2 members of the team say “close” and the remainder don’t respond, then it closes (as today); if all but 1-2 members of the team say “merge” and the remainder don’t respond, then it merges (as today), but if all but 1-2 members of the team say one direction and 1-2 say the other direction then the process continues until there’s a consensus, treating the divergence as indicating objections.

That would avoid the “inevitable momentum” problem where it feels like there’s no way to change direction once a direction is set.

8 Likes

I think this is what I mean by "minimal complete summary".

It has occurred to me, however, that the criteria could be relaxed slightly: If there is a comment that contains many details and sub-points, it could be acceptable in the summary to include just a sentence (or a paragraph) about it and then link to the relevant comment which contains all the details. (Rather than the summary just copying out all of the details.)

2 Likes

As a real example, how’s this summary I just did for the await bikeshedding? https://github.com/rust-lang/rust/issues/57640#issuecomment-455836523

(I sure hope it doesn’t get totally lost)

This is an interesting example since it’s such a bikesheddable topic (any syntax at all) and most of the “arguments” boil down to "I like how this feels: [example]`. That’s why the summary is really just a big matrix of examples.

2 Likes

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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:

  1. 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.

  2. 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.

  3. We should improve on these notions. Given that both are a research problem, that doesn't make it easy.

  4. 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.

  5. 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

  1. The discussion wanders of into people discussing a ton of aspects, including coming up with all-new ideas, blowing up the decision space.
  2. 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.
  3. There's a growing feeling of low appreciation by the maintainers actually building the feature, as their work is steamrolled by new ideas.
  4. The debate is very open, including ideas that need to be separately RFCed (postfix macros, method-like macros)
  5. Pressure is high, as the feature is delayed.
  6. 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:

  1. 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.
  2. Make clear expectations on what a discussion example needs to fulfil, maybe provide a template. Raise the bar of effort.
  3. Make it clear who's finally deciding stalemates. IMHO, in this case, it should be boats and cramertj.
  4. In this phase, anything that hints at needing and additional RFC should be curbed, unless new suggestions have to be searched.
  5. 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.
  6. 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.

10 Likes

(@mbrubeck I think it would be good to split mine and @skade's comments into a new topic...)

I think the time spent debating the RFC has already wildly exceeded the implementation work time required.

To me, it does not seem productive to decide whether parser complexity is a language feature or not (my view: LL(k) isn't a language feature but that doesn't mean there are no limits...) separate from the turbofish RFC since the facts of the syntax changes in the RFC are what is actually on table and not any unbounded complexity in the grammar. For example, we might accept backtracking in this pathological case, but not in cases where it isn't.

The await future syntax has not been accepted. It was explicitly left unresolved in favor of a temporary solution await!(...) much like existential type was. There is not consensus within the language team for either the temporary syntax or prefix await.

The final syntax won't be decided upon until there is full language team consensus.

1 Like

Instead of splitting off a new thread for the LL(k) thing, I'd rather you just stop beating that dead horse entirely. It already got locked on the RFC repo; moving the exact same war over to the Internals forum doesn't seem to match the intent of the moratorium.

1 Like

@Centril I think you are perhaps missing @skade’s point. I believe they are making the case that defining negative space and setting guard rails for discussions would make the community more focused and scalable. I think we should try to avoid discussing the specifics of async or turbofish here.

Personally, I tend to agree with those ideas. One challenge is how to specify negative space. I would recommend the following requirements:

  • we must be able to easily and unambiguously evaluate whether a proposal falls into the negative space. For example, a “negative RFC” ought to target a specific feature (e.g. ok wrapping) or class of features (e.g. work integrating cargo with xargo).
  • it must include things that are likely to be discussed if we don’t explicitly blacklist them; otherwise, a lot of time could be spent discussing hypothetical negative space that does have long term impact.
  • it should be re-evaluated every once in a while as technology changes. I would propose every edition, for example.
2 Likes

I understand that point, and I disagree with it. In particular, I strongly disagree with Graydon's notion of negative RFCs. I've elaborated on it here.

Believe me when I say that the turbofish RFC was extremely draining for me personally so I'm not interested in discussing the specifics here of those proposals here; but only to correct factual errors @skade made and insofar as the points that are relevant to RFC reform itself (e.g. that some language team members get to break the stalemate and decide, or that a separate RFC is required...).

1 Like