2014-03-12 2:11 GMT+01:00 Brian Anderson <bander...@mozilla.com>: [snip]
> ----- > > Many changes, including bug fixes and documentation improvements can be > implemented and reviewed via the normal GitHub pull request workflow. > > Some changes though are "substantial", and we ask that these be put > through a bit of a design process and produce a consensus among the Rust > community and the [core team]. > > The "RFC" (request for comments process) is intended to provide a > consistent and controlled path for new features to enter the language and > standard libraries, so that all stakeholders can be confident about the > direction the language is evolving in. > > ## When you need to follow this process > > You need to follow this process if you intend to make "substantial" > changes to the Rust distribution. What constitutes a "substantial" change > is evolving based on community norms, but may include the following. > > - Any semantic or syntactic change to the language that is not a bugfix. > - Changes to the interface between the compiler and libraries, including > lang items and intrinsics. > - Additions to `std` > > Some changes do not require an RFC: > > - Rephrasing, reorganizing, refactoring, or otherwise "changing shape > does not change meaning". > - Additions that strictly improve objective, numerical quality criteria > (warning removal, speedup, better platform coverage, more parallelism, trap > more errors, etc.) > - Additions only likely to be _noticed by_ other developers-of-rust, > invisible to users-of-rust. > > If you submit a pull request to implement a new feature without going > through the RFC process, it may be closed with a polite request to submit > an RFC first. > > ## What the process is > > In short, to get a major feature added to Rust, one must first get the RFC > merged into the RFC repo as a markdown file. At that point the RFC is > 'active' and may be implemented with the goal of eventual inclusion into > Rust. > > * Fork the RFC repo http://github.com/rust-lang/rfcs > * Copy `0000-template.md` to `active/0000-my-feature.md` (where > 'my-feature' is descriptive. don't assign an RFC number yet). > What about using the PR's number? That means we'll end up with some gaps between accepted RFCs but... just thinking aloud. > * Fill in the RFC > * Submit a pull request. The pull request is the time to get review of the > design from the larger community. > * Build consensus and integrate feedback. RFCs that have broad support are > much more likely to make progress than those that don't receive any > comments. > * Eventually, somebody on the [core team] will either accept the RFC by > merging the pull request and assigning the RFC a number, at which point the > RFC is 'active', or reject it by closing the pull request. > We should also use tags: `Rejected` / `Approved` I'm wondering if we should keep rejected RFCs too and not just as closed PRs. If for some reason, this repo is moved out of GH in the future, we'd loose a bunch of RFC history. We could keep the first rejected RFC for a type of change and reject future duplicated RFCs by linking them to that RFC. Not sure about this, though. Once an RFC becomes active then authors may implement it and submit the > feature as a pull request to the Rust repo. An 'active' is not a rubber > stamp, and in particular still does not mean the feature will ultimately be > merged; it does mean that in principle all the major stakeholders have > agreed to the feature and are amenable to merging it. > > Modifications to active RFC's can be done in followup PR's. An RFC that > makes it through the entire process to implementation is considered > 'complete' and is moved to the 'complete' folder; an RFC that fails after > becoming active is 'inactive' and moves to the 'inactive' folder. > We also need a way to track who's working on that RFC. Should an RFC bug be created in Rust's repo and be linked to the real RFC ? This way folks can raise their hands and work on the RFC, it's also a good place for follow-up discussions on the work happening for that RFC, etc. The person proposing the RFC is not necessarily the one that will work on it. I was going to suggest having a way to automatically close and move the active RFC under the complete folder but I think this process requires some double checking from the [core team] so I'd prefer keeping it that way. > ### Help this is all too informal! > > The process is intended to be as lightweight as reasonable for the present > circumstances. As usual, we are trying to let the process be driven by > consensus and community norms, not impose more structure than necessary. > 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. -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
