[blog post] Proposal for a staged RFC Process


#21

Overall, I like it a lot, because it tries to address some problems I’ve been seeing. Few of these I’d like to point out:

  • It tries to accommodate Rust getting „bigger“ (eg. more people participating).
  • It tries to make the „mess“ more organized and explicit. I like the flow-chart (though I’d like to see the back-edges and failure modes there as well, in the final version).
  • It makes it more useful for after-the-fact historical study. If I look through some features and try to get a grasp how and why a specific decision was made, it takes huge amount of effort, especially with features through several RFCs, tracking issues (shared with some other features), and one never knows if some important part is missing. The process shouldn’t be just to make a decision, but to be able to go back to it and learn from it, for those who came later.
  • I see the increased overhead of introducing and pushing an RFC through as a benefit (or at least not as a downside). As Rust is getting more adoption and gains maturity, it should „calm down“ in its development ‒ the cost of introducing a change to the language, in the amount of affected code and people, is growing with the number of code and users, so the cost to introduce the change to it should too, gradually.

Unlike some, I do think an explicit spitballing stage is a good thing (except the word „spitballing“ itself ‒ as a non-native english speaker, this is the first time I’ve seen it). It requires to stop and think even with „small“ features. If anything, I’d say it could be possible to move two stages in one team session if the result of the first stage is good enough than to officially skip the first one.

I’m a bit sceptical about the champion thing. It makes sense mandating the teams to participate (I guess it can’t really work without that). But, should there be a mandate for the community to participate too? Which is probably a bit related to a philosophical question, who „owns“ Rust? Is it the team, with community just helping out, or is it the community with the team just coordinating? I guess it is something in between, but despite the proposal stating it would like more community involvement, the whole champion thing seems to be pushing towards the other direction. But that could be just my private impression.

As for the format of discussion ‒ I don’t see either Discourse or Github as optimal platform. Github is not very good for discussion, Discourse seems not to be an excellent archeological source for the future generations. And both would need some amount of indexing to find the way around.


#22

Concerning the Discourse vs GitHub discussion, if neither of these fully fit the bill in isolation maybe the right thing to do would be to set up some kind of tighter integration between the two? Just throwing an idea up in the air, not sure what that should look like or how much work it would involve.


#23

Definitely. That’s why I mentioned Discourse’s customisable nature as a big plus. With GitHub you’re limited to its API, whereas with Discourse many parts of the standard UI can be changed as needed. We already have a working version of GitHub linkbacks, which is one of many integration features that could be further refined:


#24

Wow, thanks for the thoughtful feedback. Lots of good thoughts here. I don’t have time for a detailed response just now so let me just jot down some thoughts:

First, regarding the name “spitballing”, I think perhaps “brainstorming” would be a more widely understood choice (I’ve now seen two non-native speakers complain about it, so it seems like spitballing is clearly a confusing term).

Second, regarding the other detailed points, it occurs to me that the RFC process is probably not dissimilar from a lot of other design discussions, in that it is a bit hard to tell in advance just how everything is going to feel. I think it would probably make sense, before we convert wholesale to any new process, to do some kind of “trial run”, where we experiment with the new mechanisms. This would also give us time to try a variety of RFCs (both simple and complex, for example) and work out the kinks. I suspect we’ll immediately find a desire to make adjustments, no matter what system we wind up with.


Unbaked Idea: DRY using "parameterized inline modules"
#25

It’s really important to use language that native, as well as non-native, English speakers can relate to. With that in mind, “spit-balling” and “brainstorming” don’t really mean the same thing. Generally, when I think “brainstorming” I think of coming up with lots of different ideas and looking at them all for any gems (i.e. “Let it Rain (ideas)!”). When I think of “spit-balling” I think of proposing a particular idea and seeing if I can “sneak a win” with it (i.e. "Get this spit-ball past the batter’). I think the idea we’re going for here is definitely more of “Brainstorming” than “Spit-Balling” anyways (even if it weren’t difficult for non-English speakers to relate to).


#26

Discourse has support for ad-hoc tagging; it’s just turned off on Internals, and would need to be turned on for this.

Also, when you just link to a thread, Discourse does linkbacks the same way GitHub Issues do, so even without tagging, split discussions are about as manageable as a GitHub repository would be.

Add “view wiki post with quote-bearing replies as inline annotations” to that list, like what GitHub does with the “Files Changed” tab showing each thread. I’d be happy to help with that, if I thought it’d get used.


#27

As a native English speaker from the UK - I have no idea what spitballing is, and have just taken it to be equivalent to ‘brainstorming’. Regardless of the nuances between them, I would expect the latter to be much more familiar to native speakers outside the US, so I support that position


#28

I think we all agree we should change the term “spitballing” here to one that is more widely familiar =) But for those who are curious, here is an interesting article about its origins, and the various meanings that it has had leading up to the one that I intended ( “to suggest ideas, especially those that are jocular, improbable, or impractical”):

(I was not aware of the connection to baseball or softball)


#29

Against “Each RFC gets its own repository”, some RFCs are big, some are small, this will also cause the documents too fragmented. I think we should not depend too much on the github toolset, better to have a dedicated website for RFC process and still maintain the RFC docs in a single repository.


#30

I’m not 100% against a separate website, but:

  • The ability to edit the documents locally and offline, in a real editor and not in a browser is definitely a plus.
  • If you were designing such website, do you know how it would look like and what its features were? I believe the problem here is not exactly missing tooling, but not knowing what we want from the tooling in the first place.

#31

I like the discourse idea mentioned above and I would prefer it over the github each-rfc-gets-a-repo idea. Discourse has some good features such as bookmarking, ability to follow certain conversations (i guess dicourse summarises long conversations as well) rather than cluttering your inbox with Github mails.


#32

#33

Has anyone explored using Kialo to guide RFC discussions? I recently heard about it, so I’m not too familiar with it. It seems like a really cool way to enumerate pros and cons, while keeping discussion threaded on each individual point.


#34

Unfortunately I just clicked on it and it’s down for maintenance, which doesn’t fill me with confidence.


#35

So I had a mildly crazy idea the other day. The thing I like most about explicit stages is the clear separation of crystallizing a problem statement from designing a specific solution (we get more than a few RFCs that feel like a “solution in search of a problem”). But having a separate repo for every RFC feels like far more fragmentation than we really need.

But what if we had a repo for every complex problem statement? Rather than be predestined to produce a single RFC, such a repo might eventually help generate any number of related RFCs, or pre-RFC threads, or third party crates, or PRs to improve diagnostics, or merely document why the status quo is what it is and how we ended up there.

The orphan rules dilemma seems like a perfect candidate for testing this since it’s complex, subtle, has strong constraints people often miss, has associated jargon people often don’t know, affects many use cases, has many existing ideas to mitigate or address it, is mostly irrelevant to the 2018 edition work so there’s no time pressure, and we just reviewed the issue in excruciating detail last week so it’s fresh in at least my mind.

So unless someone tells me I’m actually crazy, I’ll probably create an unofficial “Orphan Rules RFCs” repo this weekend as an experiment. Hopefully I can at least manage to produce a README.md that can get any interested Rustacean “up to speed” on the jargon and design challenges in one sitting, and provide a place for them to submit use cases or proposals where they won’t get automatically forgotten about over time.


#36

This extends the idea I had about RFC refinement quite nicely:

And would also fit the model envisioned in the Language Warts RFC repo thread.

I also think it would be of great assistance in reconciling the various approaches to error management, especially with regard to development of the interaction of faults and their handlers (e.g. throw/catch).


#37

Oooh, that is a good candidate. Probably too heated/subjective for the initial experiment, but if the initial experiment pans out we could try this subject next.


#38

Yeah. It’s the subject that got me to stop lurking. :grin:

I’ve been avoiding bringing it up, though, as to not distract from 2018.


#39

what if we had a repo for every complex problem statement?

I think this is a great idea. It is part of the original blog post, though fairly far down into the weeds:

We can put more than one RFC into a single repository. Often, there are complex features with inter-related (but distinct) aspects, and this allows those different parts to move through the stabilization process at a different pace.

I’m happy to see it emphasized here.

A natural way for a new and complex problem statement to grow would be from an initial RFC that accumulates related RFCs as the difficulties and possibilities of the problem area emerge.

That gives at least some reason to start every RFC in it’s own repository (unless it fits naturally into an existing repository). Then we don’t have to move the documents related to the RFC into an independent repository when a related RFC comes along. (Documents plural: the proposal itself, a FAQ, explainers, discussions or links to discussions, etc.) Some RFCs would remain alone in their reposititories, of course. But that doesn’t seem an awful price to pay.


#40

In order to structure the pro’s and cons, my idea was to simply add these to the RFC repository (e.g. in a pro’s and cons section) via pull requests instead of via forum comments. That’s probably too heavy-weight, but maybe my idea triggers some better ideas by others…? :slight_smile:

I was also thinking about having release notes (beta notes) for the beta channel every six week: “Here’s a new beta version! We have discussed and implemented the following cool features for you to test: …”. I guess that at that point, it’s only bug hunting that is left and all design issues should have been discussed and accepted or solved before. @nikomatsakis, am I correct in this? Also, can you clarify at what point a feature goes to beta?