-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Conversation
Too meta? :P If not, I propose that this become RFC #0. |
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. |
@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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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 |
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:
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. |
@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. |
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. |
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. |
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. |
Updated in #6 |
Make this RFC be again about a single method
Refine rough edges wrt coercion
mio: Retry poll if interrupted
fix object safety section
Updates and refinements to various apis and guarantees
Associated type bounds: Fix desugaring + other house keeping
…letions-rfc Signature-based completions
Add blank lines between footnotes, to help mdbook
Revise guide-level explaination
* minor typos * intro * motivation * guide * reference * implementation * alternates * rationale * future * whitespace
Co-authored-by: Wilfred Hughes <me@wilfred.me.uk>
No description provided.