After reading some of the Rust 2019 blog posts, such as Niko’s and withoutboats’s, I had some ideas on how the RFC process could be improved and one of the rust team members suggested that I should post it on internals.rust-lang.org, and this seemed like the right place to share my ideas. (I hope that’s okay with @mark-i-m?)
One thing that was brought up by multiple people in the previous thread is the need for regular summaries. What follows are my thoughts about what this might look like and how it might be achieved. I am not very involved in the RFC process myself, so please feel free to just disregard all of this entirely – I’m just posting it here in the hope that it might lead to some useful ideas and eventually changes.
Summaries
The motivation for this is as withoutboats said – some RFCs get hundreds of comments on them, and no-one wants to read through all of them, but to make matters worse this results in comments that are redundant or duplicating of earlier comments (since they didn’t read all of the comments) and now there are even more comments that nobody wants to read through and the problem is even worse.
Some people have proposed summaries as a solution to this, and here is how I think that could work. (This is similar, but different, to the “Table of Comments” idea.)
What is a summary
Each RFC should be summarised regularly. Those summaries should be complete, clear, concise, and non-redundant.
- Complete (or sufficient): The summary should include every point mentioned in the preceding comments. Thus by reading (only) the summary you can be sure that you are up-to-date on all points covered in the RFC comments.
- Clear: The summary should be at least as clear as the original comments, but ideally more clear. An unclear comment is not an excuse for an unclear summary.
- Concise: The summary should express all the points in the most concise way possible, collapsing related points together as necessary.
- Non-redundant (or necessary): If there have been multiple comments expressing the same point they should be summarised only once. (This is true across multiple summaries as well - if a point has been mentioned in an earlier summary then don’t repeat it unless there is new information.)
Summaries can include links to the relevant comments that are detail-heavy.
The purpose of this is to optimise for reading. I realise that this might be a lot of work for the summariser, but the net saving for everyone else should far outweigh this. Consequently time should be saved overall. (You probably only summarise one or two RFCs, and benefit from summaries of all the others.)
Implementation
Collapsing comments
Every time the summariser posts a summary, the rfcbot marks all non-summary comments above the summary as “resolved”.
Top comment
The summariser edits the top post themselves. (Or, every time the summariser posts a summary, the rfcbot edits the top post to include the latest summary.)
Updates
In the case that the summariser edits the top comment to include a full summary we might also like there to be update posts that just include the new points so that it is easy for people to “keep up” with an RFC by just reading the updates. In any case, the summary remains the canonical source of information.
I’m sure there are other techniques and automations that would work for this. I think the main issue is the procedure/protocol itself, and automation can follow once that is decided.
Frequency of summaries
The frequency of summaries will likely vary depending on the rate of comments on the RFC. It would be useful to define how frequent they should be, e.g. each RFC should be summarised at least once per a week (if there was at least one comment), or each RFC should be summarised at least once per 30 comments, or each RFC should be summarised every day in which it has more than 10 comments, or some combination thereof.
The goal is that anyone reading the RFC can know when there will next be a summary posted and make an informed decision as to whether they would just like to wait until then or delve into the new comments.
Who is the summariser
In the simplest model, the RFC author must summarise all the posts.
N.B. It need not be a Rust team member. Whilst there should be rust team members involved in every RFC, anyone can summarise it. The team members that are involved in the discussion will likely be aware of all the points in the discussion, but the actual task of summarising need not fall on them.
A proponent, opponent model
One concern I had with the above model is that there could be a conflict of interests if the RFC author is summarising the entire discussion. To address this I had an idea of a “proponent”, “opponent” model.
The proponent summarises all points in favour of the RFC, and the opponent summarises all points against the RFC. This also includes relevant counterpoints, which might develop over the course of the discussion. They should try to use a similar structure to their posts so that points and counterpoints can be compared.
The proponent would be the RFC author.
The opponent would be selected randomly. If they felt that they had a conflict of interests, or they could not commit to the task, then they can “defer” and someone else would be selected randomly. (If everyone defers then presumably the RFC has no-one against it and can trivially be accepted! [Or everyone is really really far too busy, which is another problem altogether!])
The opponent need not be against the RFC, they just need to summarise in good faith (so playing devil’s advocate is fine and good).
Ideally, by reading all of the summary of points in favour, and summary of points against, one should be able to make an informed conclusion or comment about the RFC.
Rules about comments
The rules for commenting on RFCs should be strict and enforced. For example, if someone agrees with another persons post then a thumbs up reaction on the comment is fine, but a new comment is not. I’m sure there are many other useful rules.