Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: The Rust RFC Process #2

Closed
wants to merge 3 commits into from
Closed

RFC: The Rust RFC Process #2

wants to merge 3 commits into from

Conversation

bstrie
Copy link
Contributor

@bstrie bstrie commented Mar 12, 2014

No description provided.

@bstrie
Copy link
Contributor Author

bstrie commented Mar 12, 2014

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

@chris-morgan
Copy link
Member

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
Copy link
Contributor Author

bstrie commented Mar 12, 2014

@chris-morgan updated.

into Rust.

* Fork the RFC repo http://github.com/rust-lang/rfcs
* Copy `0000-template.md` to `active/0000-my-feature.md` (where

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link

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
Copy link
Contributor

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
Copy link
Contributor Author

bstrie commented Mar 12, 2014

@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
Copy link
Contributor Author

bstrie commented Mar 12, 2014

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
Copy link
Contributor Author

bstrie commented Mar 12, 2014

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
Copy link
Member

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 brson mentioned this pull request Mar 12, 2014
@brson
Copy link
Contributor

brson commented Mar 12, 2014

Updated in #6

@brson brson closed this Mar 12, 2014
alexcrichton referenced this pull request in alexcrichton/rfcs Jan 23, 2015
aturon pushed a commit that referenced this pull request Aug 7, 2015
Make this RFC be again about a single method
wycats added a commit that referenced this pull request Nov 16, 2015
nikomatsakis pushed a commit that referenced this pull request Apr 8, 2016
aturon pushed a commit that referenced this pull request Jun 27, 2016
aturon pushed a commit that referenced this pull request Oct 22, 2016
Refine rough edges wrt coercion
@llogiq llogiq mentioned this pull request Dec 9, 2016
withoutboats referenced this pull request in withoutboats/rfcs Jan 15, 2017
withoutboats pushed a commit that referenced this pull request Apr 24, 2017
fix object safety section
alexcrichton pushed a commit that referenced this pull request Jun 18, 2017
Updates and refinements to various apis and guarantees
aturon pushed a commit that referenced this pull request Jul 17, 2017
@Ixrec Ixrec mentioned this pull request Apr 5, 2018
Centril added a commit that referenced this pull request Jul 24, 2018
Associated type bounds: Fix desugaring + other house keeping
Centril pushed a commit that referenced this pull request Aug 19, 2018
Manishearth added a commit that referenced this pull request Oct 20, 2018
Update 0000-clippy-uno.md
@alercah alercah mentioned this pull request Mar 3, 2019
SimonSapin pushed a commit that referenced this pull request Apr 3, 2019
@jgarvin jgarvin mentioned this pull request Jul 30, 2020
@chorman0773 chorman0773 mentioned this pull request Nov 15, 2020
sophiajt pushed a commit to sophiajt/rfcs that referenced this pull request Mar 29, 2021
…letions-rfc

Signature-based completions
Turbo87 pushed a commit that referenced this pull request Nov 8, 2022
joshtriplett referenced this pull request in joshtriplett/rfcs Feb 28, 2023
Add blank lines between footnotes, to help mdbook
Veykril pushed a commit that referenced this pull request May 25, 2023
Revise guide-level explaination
traviscross pushed a commit to traviscross/rfcs that referenced this pull request Oct 12, 2023
* minor typos

* intro

* motivation

* guide

* reference

* implementation

* alternates

* rationale

* future

* whitespace
em-tg added a commit to em-tg/rfcs that referenced this pull request Dec 16, 2024
Co-authored-by: Wilfred Hughes <me@wilfred.me.uk>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants