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: Amend RFC process with a defined scope. #531

Merged
merged 1 commit into from
Feb 2, 2015
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions text/0000-define-rfc-scope.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
- Start Date: 2014-12-18
- RFC PR:
- Rust Issue:

# Summary

According to current documents, the RFC process is required to make "substantial" changes to the Rust
distribution. It is currently lightweight, but lacks a definition for the Rust distribution. This RFC
aims to amend the process with a both broad and clear definition of "Rust distribution," while still
keeping the process itself in tact.

# Motivation

The motivation for this change comes from the recent decision for Crates.io to affirm its first come,
first serve policy. While there was discussion of the matter on a GitHub issue, this discussion was
rather low visibility. Regardless of the outcome of this particular decision, it highlights the
fact that there is not a clear place for thorough discussion of policy decisions related to the
outermost parts of Rust.

# Detailed design

To remedy this issue, there must be a defined scope for the RFC process. This definition would be
incorporated into the section titled "When you need to follow this process." The goal here is to be as
explicit as possible. This RFC proposes that the scope of the RFC process be defined as follows:

* Rust
* Cargo
* Crates.io
* The RFC process itself

This definition explicitly does not include:

* Other crates maintained under the rust-lang organization, such as time.

# Drawbacks

The only particular drawback would be if this definition is too narrow, it might be restrictive.
However, this definition fortunately includes the ability to amend the RFC process. So, this
could be expanded if the need exists.

# Alternatives

The alternative is leaving the process as is. However, adding clarity at little to no cost should
be preferred as it lowers the barrier to entry for contributions, and increases the visibility of
potential changes that may have previously been discussed outside of an RFC.

# Unresolved questions

Are there other things that should be explicitly included as part of the scope of the RFC process right now?