[blog post] Proposal for a staged RFC Process

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:

https://meta.discourse.org/t/the-github-linkback-plugin/66081

2 Likes

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.

7 Likes

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).

2 Likes

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.

2 Likes

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

2 Likes

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)

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.

1 Like

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.
2 Likes

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.

1 Like
1 Like

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.

2 Likes

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

1 Like

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.

10 Likes

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).

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.

1 Like

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.

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.

1 Like

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?

1 Like

Here it is: GitHub - Ixrec/rust-orphan-rules: An unofficial, experimental place for documenting and gathering feedback on the design problems around Rust's orphan rules

3 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.