Thoughts on RFC/stabilization reform in 2019

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

@Centril Thanks for point me to that reddit thread.

I would say that I also don’t fully agree with the everything Graydon says about negative space. I think we should make sure that Rust is relevant to whatever the current state/needs of technology are, especially in such a fast-moving field as computer science

However, I do see a need for temporary negative space: ruling out an area of exploration for a time (e.g. an edition) to be reevaluated later. In particular, I think that would allow us to focus community efforts and improve scalability.

We have tons of work in progress and not nearly enough bandwidth to keep up; tons of stuff is semi-perma-unstable because it’s just not getting worked on. We have 344 open tracking issues (https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AC-tracking-issue), and as of now, all but about 30 haven’t been touched since October 2018. Half haven’t even been touched since 2017.

I don’t think temporary negative space will hamper Rust’s growth in the future, but I do think we need to make some hard choices about where to focus efforts. I think that necessarily means we will need to make some sacrifices and some will be disappointed (I’ve been on the receiving end of that too sometimes).

See, I don't think it will; rather, it will just waste time on deciding on what to not consider for now and so on. We also have mechanisms today that allow for a measure of negative space: closing RFCs, postponement, and the roadmap. The latter already states what the major priorities are, and other things are by definition not major priorities (there will always be small things that don't take a lot of time that we can work on...). I think this works well. It's better to positively state what we believe is important right now rather than stating what isn't.

At the time of writing, there are 124 open T-lang C-tracking-issues (I cannot speak for other teams... not my business...). I have reviewed all of these 124 issues several times. Many of them are small things, others are old crap we want to remove but cannot yet because e.g. servo depends on it. Others are waiting on architectural changes like Chalk or on making NLL the default. Some things were made very recently to make tracking more fine grained. Some things are really small issues that cannot and should not be compared with bigger things. Other things are done or close to completion.

This is all to say that using this list as a measure of things to do is a extremely blunt instrument that doesn't account for differences and the weight of various items in the list. Many things in this list are being actively and quickly worked on. Negative RFCs and whatnot will not help, it will just give me more work and take time away that I would like to devote to this list instead.

The nice thing about our current process is that it deals with priorities, backlog, and bandwidth organically. Language team meetings start with going through triage (nominated issues, PRs, bugs, etc.); we then proceed to RFCs... If we don't have time for RFCs, it will just wait until we have time. This happens a lot; most meetings we don't discuss new RFCs.

3 Likes

Community efforts include more than just the efforts of the official teams.

Aside: I'm going to be use quotes (") in this post to differentiate between people belonging to teams ("team") and those who aren't ("community") - in practice team members are part of the community, and it's more about differentiating those keeping very close tabs on wide part of rust development/RFCs vs those who are less acquainted with what's going on.

When I hear "focus community effort" I don't think of the teams, I think of "community" attention - involvement in RFCs from people not on the official rust teams: reading the huge comment threads, adding comments, critiques and feedback, trying out the unstable features, etc.

The organic attention of the "community" often does not line up with the attention of the "teams". Consider RFC's written and postponed, or RFCs that garner lots of comments without team attention. I think in part the drift between "community" and "team" focus has gradually grown as the community has gotten bigger. It's easier to follow what's going on when less is going on.

I think negative RFCs would be useful for "community" involvement - I think that with negative RFCs/space there would be a fair number of RFCs that would be unwritten, instead of written and then postponed. Knowing something won't get much attention beforehand is pretty valuable. And it's hard from a community perspective to know what that is.

I think negative RFCs / negative space is only one approach to this though, so don't take this as endorsement.

I do think in these discussions it's useful to keep in mind that that what helps "team" members might actually inconvenience "community" members, and vice-versa.

TL;DR - "team" members and "community" members interact differently - I think the negative space RFC stuff was for the benefit of "team" members, not "community" members. I think it's important to consider both though.


Personally, I'd go for more tooling making it easier for team members to mark where their attention is, and aggregating it into an index / portal that makes it easier for "community" members to see where attention is allocated.

Also, I'd gladly accept a slower pace of rust language development for better rust community involvement.

2 Likes

Also, @Centril, thank you for your comment. I got a better insight into how at least one team operates, and it gave me lots of food for thought.

1 Like

I agree that it handles priorities, but I’m not convinced that it handles backlog/tech debt, at least not as much as I would like to see (and others seem to agree judging from Rust2019). Also, a huge portion of technical debt is from non-T-Lang work, but T-Lang work still consumes community attention/effort/resources that otherwise go to other tech debt; there’s only so much that can happen in parallel. The systems we have should consider the resources of the entire community, rather than being on a team-by-team basis IMHO.

Also, to be clear, I’m not bashing on T-Lang or anything. I’m super appreciative of the team’s efforts and work and your persistent triaging.

I think an interesting alternative to negative space might be “positive space with guard rails”. For example, we define a roadmap and only accept RFCs for roadmap items.

1 Like

What I'm not convinced of is that it could go much faster than it is right now. Some of the tech debt is from all the way back in 2015. It won't be solved unless we land Chalk and such things and only so many people can work on that at the same time; the speed with which we remove technical debt doesn't scale linearly with the number of people willing to do that work. We are also limited purely by the bors queue, even if we had more people working on it the PRs might not get merged any faster. I want to see concrete evidence (not just abstract arguments) that refocusing will substantially solve the technical (design) debt quicker.

T-Lang work, for example on designing associated type defaults, type ascription, already is focused on fixing technical debt to a large extent. Some technical debt or unfinished things can only be solved with new language design (e.g. I'd be uncomfortable with stabilizing much of implied bounds without where clauses on enum variants, or trait aliases without quantification over traits...). There is other types of debt, e.g. lack of documentation about the compiler -- but that is not something I could substantially help with since I'm not a compiler dev and don't know all the components. Having new designs to implement are also a way to get people into compiler work and moreover, I think that a consequence of less design is just fewer people working on things -- it won't result in all language designers suddenly doing more compiler work.

Thanks for sharing this reddit thread @Centril, it was a very interesting read. I really appreciate all the conversation going on here.


I'm not completely convinced that the language is growing too complex, but I can understand those concerns and I think that it's important that this is always considered and that the language team consists of individuals who have different opinions on where the line is (this isn't to suggest that isn't the case currently, I'm very appreciative of all the hard work that T-Lang do).

However, I do think there is a problem with how challenging it is to follow the changes being proposed to the language (even at a high-level) and how quickly these discussions become draining (even just to follow along, I can't imagine trying to participate). I spend probably an above-average amount of time following Rust's development with my semi-regular contributions to the compiler and if there's something I'm interested in keeping a tab on, it just isn't feasible (eg. I couldn't keep on top of the await syntax discussion this weekend). I think it's important for the community to be able to keep up (with some reasonable time investment).

I don't think that the issue is that there are too many RFCs. I think the issue is that the discussion on these proposals often end up large, sprawling and unproductive.

In my opinon, the discussions on RFCs quickly become unprofessional (definitely not everyone), propose often inpractical solutions (eg. things would need RFCs themselves) or attempt to relitigate already settled discussions.

One of the great things about Rust is how transparent and open the processes are, and how the community around the language can get involved - but I do feel the bar for participation in RFC discussion needs to be higher - there's a really high cost to commenting (which is why I very rarely participate on RFC discussions myself - I'm in no way qualified and don't want to introduce noise).

I would love to be able to look at an RFC proposal and see mostly discussion from the Rust teams, some regular contributors and the occasional community member where all comments are professional, considerate and contribute to the discussion meaningfully. I'd like to walk away understanding what different members of the team think about a proposal and having read a really good discussion (like that happening in the previously linked reddit thread or in this internals topic).

There's just too much noise right now, there should be much less discussion than there currently is - that isn't to say that the topics aren't important and don't warrant discussion - they absolutely do - but a handful of productive and professional individuals could discuss a topic as thoroughly in thirty comments as we currently do in hundreds.

I'm concerned that the team members doing a great job could get burnt out and stop enjoying the work they do on Rust if some changes aren't made to these processes - and I think that's a concern shared by many given all the Rust 2019 posts that hit on these issues (although they may not see things exactly as I do, that's fine).


That's just my 2c, some (ironically) half-baked thoughts - it's not intended to be a criticism of any team or individuals, or to suggest that we do anything radical to limit discussion and shut down any opinions. I also recognize that this post isn't particularly useful as I've not proposed any particular solutions, just enumerated the problems as I see them.

9 Likes

This is fair. I can't really give authoritative statements for most things, but I can give my observations for the parts of the project I know.

I firmly believe that there is lots of work that just hasn't gotten any love recently due to a mix of bandwidth constraints and lack of attention. Refocusing community attention and effort at these would accelerate development.

Here are some examples that are closer to me (and I suspect others could point out more work):

Note: I'm not complaining. Just pointing out that we already have lots of stuff we can work on that is just wanting community attention.

  1. Documentation:

    • The rustc-guide has tons of available work and not enough helpers. Most of this work could happen in parallel. Also, some of the last missing chapters (e.g. LLVM) kind of require a knowledgeable/experienced compiler dev to write them or mentor someone writing them, but those people tend to be way oversubscribed and too busy to help (and understandably so).
    • RBE has "languished"
    • The cookbook was not finished
  2. Design and implementation of old unstable features that we already know we want: much of this work is undone due to bandwidth, as well.

    • Things like inline asm, custom testing/benchmarking frameworks have all had some discussions 1 2 3 4, but my strong impression is that there are not many people available to work on them.
  3. Much tooling could use more love.

    • cargo and rustup have been frozen for the time being due to bandwidth constraints and planning needs. cargo has 712 open issues, 84 of which are labeled C-bug, along with 18 PRs, the oldest of which was opened in March 2018. The rustup repo doesn't even appear to be triaged regularly, and my own experience of trying to add a useful note to the README saw the PR left untouched from Nov 2017 to May 2018.

    • RLS/IDE integration is a field where a lot of work is going on, but my impression is that it is largely due to the heroic efforts of a few dedicated individuals like nrc and matklad. My own experience with RLS is that it's not quite there yet, and many of the Rust2019 posts also mention it 1 2 3 4 (<- there are others, but these are the first few on Read Rust)...

    • There have been some interesting experiments 1 2 aimed at improving rust documentation and code search, but these seem to be primarily the work of a small handful of people. rustdoc itself seems to be mainly managed by a handful of people.

  4. I would also like to point to the impl Period of 2017 as a demonstration of what might be possible if the community attention is directed in a given direction. It was highly successful: the ergonomics initiative, libzblitz, and working groups made significant progress during that time 1 2.

For the compiler I can't call the "impl period" 2017 successful at all.
Do you remember what happened due to the pre-impl-period RFC deadline? I remember.

Last month(s) before the impl period:

  • Compiler contributors - work less than usual due to constant distraction by the flood of pre-deadline RFCs.
  • Compiler non-contributors - write RFCs as if it's the last day of their life.

The impl period itself:

  • Compiler contributors - work as usual.
  • Compiler non-contributors - relax on the pile of RFCs.
2 Likes

Ideally, negative-space would prevent the flood of pre-deadline stuff.

The other point about the impl period itself seems more salient - as Centril as said about himself and his team, (and according to you applies to most (if not all) compiler contributors): compiler contributors already know what they’re working on and what comes next (and they don’t want more busy work).

But that’s just the compiler team. I think guard rails or guidance of some sort could help direct people to areas of rust that are more … in need of love.

Well, I definitely remember that there were too many RFCs running at the same time, but I see that more as a reflection about setting hard deadlines for things, rather than doing them when they are ready. I think a similar observation can be made about the Edition 2018 rush (e.g. the website stuff).

1 Like

I’m not very convinced that negative RFCs would be received well by the community. In order to serve their intended purpose they have to be respected. And there hasn’t been a great track record of that happening. The crates.io team made a “negative policy decision” regarding crate squatting, but since then there have still been a bunch of contentious debates on that topic…

4 Likes

You mean that it would be perceived as a dismissal of some sub-community’s concerns?

Do you think a positive roadmap with guard rails would alleviate some of your worries?