RFC: The Rust RFC Process

[bstrie]

No description provided.

[bstrie]

Too meta? :P If not, I propose that this become RFC #0.

[chris-morgan]

I see Motivation and Detailed design, but no Summary, Alternatives or Unresolved questions sections. I believe these should always be in, even if they are just about empty.

[bstrie]

@chris-morgan updated.

[flaper87]

What about using GH's PR number ? This will add some gaps between accepted RFCs, which is probably not good, but it'll at least keep the sequence of numbers related to the proposed PR.

[nikomatsakis]

We went back and forth this. There is really no good reason not to use the PR number except that continuous id numbers are more attractive than random numbers with gaps.

[steveklabnik]

I think coupling RFC #s to pull #s doesn't add a lot of benefit, but does cause lots of problems if we ever move off of GitHub.

[flaper87]

FWIW, I've seen a similar process being implemented in other projects. Using the review infrastructure to propose RFCs sounds like a good idea to me.

The only bit that worries me is having a good way to search through the RFCs history (like real search, not just git grep or GH's search field), hence the proposal of keeping some of the rejected RFCs. We could have a rfc.rust-lang.org with the RFCs indexed and allow people to navigate active, rejected and completed RFCs from there.

[nikomatsakis]

We should probably include a detailed check list of the steps to take on accepting an RFC, or perhaps put that on a wiki page. I think the steps are:

1. Assign a sequential id.
2. Add the file in the active directory.
3. Create a corresponding issue on Rust.
4. Add some kind of link from the RFC to the issue and the original PR.
5. Commit everything.

Arguably we could skip the sequential id part and just use the PR number. I thought this would be ugly but I guess I don't really care.

[bstrie]

@nikomatsakis Notably, PEP seems to not care a whit about sequential version numbers. I'd say we just tend to use the PR number, but leave ultimate discretion up to whoever merges it in. This also gives us the leeway to do fun things like, say, add 2000 to the number in order to denote RFCs that have been accepted, but will not be merged until Rust 2.0.

[bstrie]

Part of me also thinks that your "checklist of steps to be taken after acceptance" is the sort of implementation detail that's irrelevant to the proposal itself, but ultimately I'd rather see it documented here than thrown mercilessly to the wiki.

[bstrie]

Alternative numbering scheme to attempt to minimize confusion: when accepting an RFC, immediately open an issue for it in the Rust repo. Once done, take the issue number given and assign it to the RFC.

I still think I prefer the informal-and-flexible approach I outlined above, but this alternative would leave the fewest number of arbitrary numbers lying around.

[steveklabnik]

I would like to see RFCs that don't make it be saved in some kind of archive, similar to the way the IETF does it.

I am quite happy that we have SOME kind of RFC process.

[brson]

Updated in #6