[blog post] Proposal for a staged RFC Process

16

The RFC process, especially the early parts, is inherently chatty. GitHub excels at reviewing and pushing code, but that doesn't mean a discussion about code that might one day materialise ought to live there from day 1. I've suggested using Discourse to a larger extent in the Rust RFC process before. Since it received some quiet approval and no pushback I hope you don't mind if I bring it up again.

I really like the flow of the new process, but I'm not a fan of the separate repository per-RFC proposal. By committing hard to GitHub so early in the discussion process you're setting yourself up for a lot of busywork like keeping track of all these disparate repos via some mix of manual curation and GitHub API hacks. Good points have been raised about how this workflow is primarily designed for "epics" rather than minor RFCs that are adequately covered in a single topic of discussion.

Here's how I would structure the early parts of the RFC process in a way that scales from small to big RFCs with minimal friction:

Spitballing (Optional)

  • Create Pre-RFC topics on internals.rust-lang.org with a #pre-rfc tag to casually discuss any idea you might have. Minimal formalities.

Designing / Prototyping

  • Create an RFC in the #rfc category. (Any related pre-RFC should be closed with a link to this RFC).

    • Every RFC topic must have a descriptor tag attached to it, like #semicolons-as-items. Discourse allows you to require this.

    • Branching discussions about a complex RFC can easily be created by starting a linked topic.

      11
      Screen Shot 2018-06-23 at 10.49.11.png802×284 28.4 KB

      These new topics will automatically have the appropriate tag attached to them.

    • For extremely complex/controversial RFCs you might consider creating a whole new sub-category for discussion, e.g. #rfc:rust-epochs.

All of this categorisation is completely fluid and won't create any breaking links when changed.

Implementing

  • The bulk of the discussion moves to GitHub as code starts to be written.

Discourse will cover this part of the discussion process:

2018-06-20-rfc-stages
2018-06-20-rfc-stages.png893×760 135 KB

The way I see it, keeping everything in one place is a pipe dream. Before an RFC comes into existence there will always be informal discussions happening that can live just about anywhere. Better to use different platforms best suited for the different stages of discussion.

I see the stages of an RFC more like:

  1. Fragmented discussion (chat, forums, reddit, blogs)
  2. Centralised discussion (#rfc category)
  3. Code proposals & review (GitHub PRs)
  4. FCP (final GitHub PR)

During the early discussion-heavy phase you want to facilitate discussion as best you can, and Discourse does discussion much better than GitHub.

  • Split out or merge in posts
  • Moderate users and their posts
  • Easily quote or reply to specific posts
  • Granular notifications
  • Duplicate content warnings

And the open source nature of Discourse allows you to better formalise the RFC process, complete with UI conveniences, e.g.

  • Allow moderators to highlight certain posts, e.g. marking a post as "summary", which would be clearly called out in the sticky page counter on the right.
  • Visually highlight the posts of an RFC's champion, if one exists.

A lot of these are feature we'd be happy to sponsor.

13 Likes