Thoughts on RFC/stabilization reform in 2019

internals policy
42

Summary

Things appear to have settled. I wanted to summarize the discussion a bit, since it would be ironic if I didn’t.

Meta-note: I tried to be “complete” and “concise”, erring on the side of “complete”. It’s kind of hard. Let me know what you think…

OP

  1. In the OP, I proposed a number of ideas. These don’t seem to have generated much controversy. My impression is that many people agree with them. Some also seem like incremental enough changes to be done without an RFC.
    • Centril points out closed/postponed RFCs are already easy to find; it’s just a matter of expending the effort to read them.
    • skade argues that adding automation without other changes will cause problems to get worse.

Thread summaries

  1. cartesiancat Posted some thoughts on how to implement good thread summaries for long discussions. Here are the high-level points (please point out if I missed anything):

    • Summaries should be “complete, clear, concise, and non-redundant”; “optimize for reading”
      • There was some discussion about what “complete” and “concise” means. scottmcm suggests framing it similarly to the Agile Manifesto, so I proposed “While we value concise and complete summaries, in situations where they conflict, I think we should completeness.”
    • cartesiancat suggests that if a summary comment would be too long, a sentence with a link to the original comment would be acceptable.
    • rfcbot used to update the top post or make a new post, ensuring everyone gets emailed. rfcbot collapses comments between summaries.
      • pietroalbini says there is not GitHub API for collapsing comments at the moment.
    • Frequency of summaries: we should define and enforce how frequent they should be.
      • I originally proposed every 30 comments, but there are other metrics, e.g. once per unit of time or once per unit in time in which there are at least N comments.
      • Another problem (pointed out elsewhere) is that initially there are usually a bunch of typo comments.
    • Who writes summaries
      • In a previous thread, I proposed that it should be a lang team member. cartesiancat proposes it should be the RFC author.
    • “Rules about comments should be strict and enforced”. The idea is to reduce noise and redundant commenting.

  2. I implemented a prototype in rfcbot…

    • varkor points out that it might be cleaner to have rfcbot make the first post to each issue and update that as the summary comment.

  3. CAD97 points out that summarizing a bikeshed is hard, especially when going for completeness.

Unintentional Bias

There were a few discussions that arose around how to reduce bias.

  1. cartesiancat proposed a “proponent/opponent” model, in which each summary should be written by two people: one in favor of the RFC (presumably the author), and one against the RFC, playing devil’s advocate.

  2. josh points out that proposing an FCP with a given disposition at the beginning gives that disposition “inevitable momentum”. Instead, they suggest that each team member should list their disposition and let discussion come to a consensus from there.

Deciding on Problems

  1. matthieum suggests that we should amend the RFC process to first formally acknowledge a problem using a “Request for Proposals” process. The intent is to reduce discussion of problems that may not be widely felt to be a problem.
    • Ixrec responds that “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”, but agrees that avoiding debates that don’t need to be had would be good.
    • fintelia worries that such an RFP process would identify difficult or impossible problems and devolve into discussions about the existence of some unlikely solution.
  2. I raise the question of how eRFCs and roadmaps tie into this problem. In a sense, they are about defining problems that the community finds important.

Negative Space, Exhaustion, and Resources

There were much discussion on exhaustion and negative space. skade first brings up the topic with regards to heated discussions. I later turned more towards prioritization and the use of community resources and effort.

  1. skade brings up the topic of “negative space”. (To my knowledge, this was first brought up by Graydon in their Rust2019 blog post).

    • (@skade: I tried to distill the main points, please feel free to correct me if I missed anything)
    • They point to the recent “Turbofish” and “await syntax” RFC discussions to illustrate some points.
    • They suggest “more roadmapping and sticking to it”. They also suggest creating mini-roadmaps to elaborate more on specific areas.
    • They suggest some ways of managing discussion threads: “call project members out more harshly if they aggressively discuss”, “actively pulling in people from relevant groups early”, “Frequent rechecking if we don’t go off track by absolutely wanting to solve a hard problem just for the sake of it”
    • In the case of heated syntax bikesheds, like the await one, the design space has become enormous and the discussion is exhausting.
      • Debate includes ideas that would need their own RFCs.
      • Pressure is high as the feature is in high demand.
      • The implementors often feel unappreciated because of the high rate of new ideas.
      • skade suggests listing the available options up front and limiting debate to those options. They also suggest raising effort the bar for commenting and prohibiting proposals that would require their own RFCs. They suggest that arbitrage and credit assignments should be made up front.

  2. skade points out the need to deal with “emotional real estate” (as defined by anp).

    • They point to “turbofish” and “await” syntax as examples.

  3. I raised a few questions about how we would implement negative space:

    • how to evaluate if a proposal falls into the negative space and should thus be closed?
    • how to prevent a flood of negative RFCs and thus waste time anyway?
    • how to prevent stagnation?

  4. Centril points to this useful discussion about negative space between Graydon, Centril, and others.

  5. Centril and I discuss temporary negative space and focusing of community resources in these comments: 1 2 3 4 5 6 7 8. A few interesting realizations came out of this discussion for me. Perhaps @Centril can point out if I missed anything or mischaracterized their views.

    • I feel that I spend above-average time on rust stuff, but still feel that the pace of change is overwhelming and that much technical debt has accumulated.
    • Centril (as a member of the Language team) finds that technical debt related to that team is triaged and handled regularly and not a source for concern. Moreover, much of the technical debt is blocked on items that are actively receiving attention.
    • I expressed that work on T-Lang items still consumes community time and attention away from other items and that refocusing community attention on a smaller set of things would improve productivity.
    • Centril disagrees that work could proceed much faster and that refocusing attention would have little effect because of difference in skill sets.
    • Centril argues that negative RFCs would just create more work for the language team.
    • Centril argues that much of the design work happening is technical debt and simplifies the language overall.

  6. davidtwco suggests that the pace of change is not the problem. Rather, the ability of the community to keep up is the problem.

    • They suggest that this is due to “large, sprawling, and unproductive” discussions and that " the discussions on RFCs quickly become unprofessional (definitely not everyone), propose often impractical solutions (eg. things would need RFCs themselves) or attempt to relitigate already settled discussions." and that “There’s just too much noise right now”.
    • They suggest that the solution is to raise the bar because “there’s a really high cost to commenting” and that “a handful of productive and professional individuals could discuss a topic as thoroughly in thirty comments as we currently do in hundreds”

  7. fintelia suggests that a negative RFC would not be well received and would generate even more contentious debates.

  8. Postitive roadmapping and sticking closer to the roadmap or some for of “guard rails” to prevent discussion from straying to far seem to be suggested often as an alternative to negative RFCs: 1 2 3

  9. Regarding refocusing effort, I suggested something like the impl Period of 2017.

    • petrochenkov recalls that this led to a pre-deadline flood of RFCs which was hard to handle. I claimed that this is a reflection on setting hard deadlines more than the impl Period itself.
    • samsieber suggests that negative RFCs might mitigate the pre-deadline flood.

Team and Community Perspectives

Another (unexpected, to me) theme was the difference in perspectives from the language team and the rest of the community. In particular, these seem to indicate to me some communication disconnect.

  1. Centril’s comments in the discussion above seem to focus largely on the view of the Language team (understandably). My impression is that team is pretty organized and does not feel an excess of tech debt. (TBH, I wasn’t really sure if this was the view of the whole team or just Centril as a member of the team?)

  2. samsieber suggests that “The organic attention of the “community” often does not line up with the attention of the “teams”.” and that negative RFCs might help with that but aren’t the only way to accomplish it.

  3. CAD97 notes “part of the disconnect is a perception of what’s “in progress” from “inside” versus “outside””. Specifically, team triages and decisions affect what’s worked on, but not what the community perceives as “in progress”:

    • “obviously not everyone’s present for steering/triage meetings so what’s covered there, while potentially guiding what that team considers “active”, has little to no effect on “outside” atmosphere.”
    • “the “atmosphere” is that they’re “open” and taking some “cost” to host (even if that’s just real-estate on a digital issue tracker) even if the team isn’t going to look at it for a year due to other priorities.”

  4. samsieber suggests that part of bridging the disconnect might be better tooling: “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.”

Unresolved Questions

  1. How to enact changes? One big reform or incremental progress?

  2. Do we want negative RFCs? My impression is that the leaning on this thread is “probably not” but we want more “guard rails” or something similar, though there are several who have expressed desire for negative RFCs. (Personally, I’m on the fence).

  3. I certainly missed a bunch, so please just ping me, and I will add them

7 Likes