Refining RFCs part 2: RFC staging

[glaebhoerl]

The same problem arises if you open your own RFC. As you are supposed to defend your RFC, you are also logically supposed to read all the comments. But instead of reading few constructive comments, you get flooded by walls of text. I personally have two RFCs in mind that I’d like to propose, but that I won’t because of this point alone.

This is a good point too… and this somewhat characterizes my own behavior as well. (It hadn’t even occurred to me that it could be otherwise…)

[rkjnsn]

The problem I find with Reddit is that in can be hard to find new posts during the discussion, since one has to figure out under which subthread it appears. If one is interested in following the entire conversation, Discourse’s linear format works better. Newsgroups seemed to have the best of both worlds (easy to identify new messages in any subthread, but the conversation tree was clear and it was easy to ignore parts of the conversation that went off the rails). I’m still surprised none of the current web-based options seem on par.

[steveklabnik]

The problem I find with Reddit is that in can be hard to find new posts during the discussion,

The real problem is that they provide this, but only for people with Gold

That said, I would pretty vehemently oppose Reddit being a part of any official Rust process; its format isn’t the problem though.

[tomaka]

Another appropriate format for example, is that if each RFC was a repository we would open an issue for each point to discuss.

Again, this is just an idea. But in my opinion, the current state where the discussion is linear is the worst possible system.

[nikomatsakis]

Another appropriate format for example, is that if each RFC was a repository we would open an issue for each point to discuss.

I’ve thought about this from time to time. I think another factor here is that some RFCs require more comments than others, and making a fresh repo for smaller RFCs feels a bit like overkill. Maybe the answer is that such things shouldn’t be RFCs at all, but something else, I don’t know.

[withoutboats]

It seems to me like a custom web app for discussing RFCs could be a worthwhile project, since there’s no prebuilt platform with the communication flows we want. Delegate auth to GitHub and probably have it automatically maintain the RFCs repo as well.

[nrc]

The one repo per RFC model seems like a good fit for more complex RFCs, in particular ones where we expect collaborative change and thus multiple PRs (PRs against PRs don’t seem very popular). However, I fear the details of this idea will kill it - who would manage the repo, where would it be hosted, how do we arrange the right admin rights, etc.

[yigal100]

I too think that a custom web app is a great idea.

I think that one of the issues here is the format of RFCs - a text document is a more centralized format which worked great so far for Rust. However, as the community grows and we tackle bigger and more complex issues together as a community, i think the process becomes a joint brainstorming more than a single person’s idea/design.

Therefore, I think we need a graphical format such as a mind-map at least for the initial stages. the RFC text IMO is just the final stage - it is the proposed spec doc of the proposed final design and it could be extracted semi-automatically from the mind-map.

[nikomatsakis]

This is a popular model for TC39 proposals.

[nrc]

I wonder if we can successfully predict whether an RFC would be better suited for a PR or repo? I would think we can, but maybe that’s just hindsight bias

[anp]

The one repo per RFC model seems like a good fit for more complex RFCs, in particular ones where we expect collaborative change and thus multiple PRs (PRs against PRs don’t seem very popular). However, I fear the details of this idea will kill it - who would manage the repo, where would it be hosted, how do we arrange the right admin rights, etc.

Another question about repo-per-RFC: how would discoverability be handled? Right now it’s very easy to go to the RFC repo and see the status of a variety of conversations, and it’d be a shame to fragment all of the conversations without some process for indexing and tracking the status of the various repositories.

[nikomatsakis]

I wonder if we can successfully predict whether an RFC would be better suited for a PR or repo? I would think we can, but maybe that’s just hindsight bias

Seems likely. I think it makes sense to assume we’ll have a “lightweight” process for smaller things – if someone erroneously submits an RFC to the lightweight process, or if an RFC turns out to have more complications than originally thought, we could always move it over to the “heavierweight” process. One might imagine giving these two distinct names. Something like a proposal (the lightweight version) versus an RFC (the heavierweight version).

Anyway, I think for now it makes sense to focus on “heavyweight” proposals (such as most, though not all, language changes) since I think that is where the problems are most acute.

[cbreeden]

Summary

Implementation Details:

• Consider non GitHub/Discourse RFC tracking system 1
• RFC PRs should be an RFC tracking system with links 1
• API-type access to relavent links, CMS-style summaries 1
• Summary points could have logical/topological relationships plotted 1
• Github/Discourse may not be sufficient to hold long conversations 1 / 2
• Heavy RFC get own repo? 1 / 2 / 3

Additions/Suggestions/Concerns:

• Alternative/Supplement: distinct problem forums and solution forums 1 / 2
• Incorporate clear/concise summaries on some cadence 1 / 2
• Too much work for shepherds? 1
• How to increase team/author communication? 1 / 2

[cbreeden]

So one issue with the summaries is that it’s somewhat subjective and requires a good deal of work. At first you would think it’s probably best to give the responsibility of summaries to the authors, but that may be asking for a lot. Is it possible to automate these somehow? What I do think is important, is that perhaps we could somehow require a single sentence summary of your post to be included in the summary (to help out whoever is doing the summary), and your post can be referenced for more details if need be. I am a little uncomfortable if we can find a good automated system, so I have a proposal:

Require the author of a response during the RFC discussion to include a concise summary in their post (if they feel that the post is significant enough to be in the summary, as opposed to say, questions for clarifications on someone else post). I feel that this will make the job of summarizing the current status of an RFC significantly easier, and it will make scrolling through the posts significantly easier while trying to keep track of certain topics in the linear structure that GitHub provides.

edit: Clarify post; forgot to include my own one sentence summary!

Topic: Incorporate clear/concise summaries on some cadence. Suggestion: Require concise summaries for (most) posts by author of post.

[nikomatsakis]

So one issue with the summaries is that it’s somewhat subjective and requires a good deal of work. At first you would think it’s probably best to give the responsibility of summaries to the authors, but that may be asking for a lot.

Agreed, for a busy RFC, it does! But it’s vital, I think, and all the more reason to find ways to spread the work around.

[cbreeden]

@nikomatsakis I think I wasn’t clear when I wrote the post you responded to, since “author” is ambiguous in that context. I was trying to propose a way to spread the work around by making it significantly easier to construct summaries of an RFC’s current standing for whoever (most likely the RFC author). So I wasn’t sure if you were just giving a or that I didn’t make that clear in my post

[nikomatsakis]

So, stepping back a bit, I’m a bit nervous about this proposed change escalating into a lot more complexity. It seems like there are a lot of things being discussed here – modeling problems, structuring conversations, etc. I’d like to try and dial it back a bit though, and try to find what is a small, simple set of things we can do as a first step.

To me there are a few key motivations:

1. Encourage more discussion on motivation:
   • Try to get consensus that on what precisely the problem is that is being solved first and on the most promising approach
   • Also get commitment from sub-team members to be more involved detailed design
   • Avoid RFCs that languish for a long time, awaiting attention
2. Structure conversations:
   • It can be really hard to follow a long RFC thread, particularly on GitHub
3. Increase bandwidth and mentorship:
   • Shepherd role for helping to summarize conversations and bring people to consensus
   • Makes a better path towards (e.g.) lang team membership

It’s interesting ponder what is a small set of changes that can work towards those goals. One thing I saw that seemed of interest also was D’s new RFC process, which definitely incorporates an explicit notion of “staging”.

[retep998]

Avoid RFCs that languish for a long team, awaiting attention

What exactly is a long team?

[nikomatsakis]

Sorry, I meant “long time”

[nikomatsakis]

More related work: https://github.com/golang/proposal