Rather than discuss this here, let's start dogfooding: https://github.com/rust-lang/rfcs/pull/2
On Wed, Mar 12, 2014 at 3:54 AM, Flaper87 <flape...@gmail.com> wrote: > > > > 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 > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
