Clarify what needs an RFC

[SimonSapin]

In #33 (comment), @cmr said:

Also, I don't think this deserves an RFC. RFCs should be for language changes and changes to items marked #[stable], I think.

It wasn’t clear to me based on https://mail.mozilla.org/pipermail/rust-dev/2014-March/008973.html (see also #31) if #33 required an RFC or not. It generated more discussion that I would have expected, but that discussion could just as well have happened in the main issue tracker.

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.

This changes libraries, but not the language.

• Changes to the interface between the compiler and libraries,
  including lang items and intrinsics.

Nope.

• Additions to std

Change, not addition.

Some changes do not require an RFC:

• Rephrasing, reorganizing, refactoring, or otherwise "changing shape
  does not change meaning".

Unsure about that one. Does MaybeOwned have the same "meaning" as ~str?

• Additions that strictly improve objective, numerical quality
  criteria (warning removal, speedup, better platform coverage, more
  parallelism, trap more errors, etc.)

I could make up a micro-benchmark with a numerical result, but there are also drawbacks.

• Additions only likely to be noticed by other developers-of-rust,
  invisible to users-of-rust.

This will definitely be noticed by users.

[thestinger]

There are many changes to the standard libraries that are not at all controversial and should not have to go through an RFC. I think it's usually easy enough to gauge this opinion on IRC or the mailing lists before going down the path of making either a pull request or formal RFC.

Occasionally, there can be a false positive and a pull request for something there appeared to be some consensus on might not be accepted. I don't think this is a big problem now that you can simply avoid the risk for a large change by doing an RFC from the start.

[SimonSapin]

Sounds good, but let’s have it written down in https://github.com/rust-lang/rfcs/blob/master/README.md please! (Again, see also #31.)

[nikomatsakis]

On Sat, Apr 05, 2014 at 02:03:43AM -0700, Simon Sapin wrote:

In #33 (comment), @cmr said:

Also, I don't think this deserves an RFC. RFCs should be for language changes and changes to items marked #[stable], I think.

It wasn’t clear to me based on https://mail.mozilla.org/pipermail/rust-dev/2014-March/008973.html (see also #31) if #33 required an RFC or not. It generated more discussion that I would have expected, but that discussion could just as well have happened in the main issue tracker.

I'm not sure I agree with @cmr. I personally think you did right to
file that RFC -- the decision of whether to expand the use of
MaybeOwned seems like a major one to me.

[alexcrichton]

We've since grown a lot of language about this, and now we've got a whole README section dedicated to this, so closing.