Collected Rust governance and conventions RFCs

[brson]

I feel like Rust policies are buried in the RFC repo and hard to discover, so I put together this list of RFCs about project policy. I originally had greater ambitions to try to summarize Rust governance but never finished it. Still, these are good to collect somewhere.

• The RFC README. This is the cannonical source for how the RFC process works, including practical advice on effective participation.
• RFC 0002. Established the RFC process. Most information here is probably in the README, which is also more up to date.
• RFC 0344. API naming conventions. Sets out the broad naming conventions used in software created by the Rust Project. Covers referring to types in method names, iterator type names, additional iterator method names, getter/setter APIs, associated types, trait naming, lint naming, suffix ordering, prelude traits.
• RFC 0430. More API naming conventions. This one includes a convenient table of the most common ones, how to deal with acronyms in CamelCase and snake_case, unwrap_* and into_* methods.
• RFC 0505. API commenting conventions.
• RFC 0507. Establishes release channels, Rust’s versioning scheme, feature gates, and the API stabilization cycle.
• RFC 0529. Conversion traits. Establishes AsRef, AsMut, Into and From along with conventions on how to use them.
• RFC 0531. Clarifies the scope of the RFC process, that it applies to Rust, Cargo, crates.io, and the RFC process itself. Leaving other rust-lang projects out-of-scope and not subject to RFCs.
• RFC 1068. Expands the Rust team beyond the core team, establishes there role. Clarifies various details of the RFC process.
• RFC 1105. API evolution. Describes which API changes are and aren’t allowed according to Rust’s interpretation of semver, and strategies for evolving APIs over time.
• RFC 1122. Language evolution. Describes which language changes are and aren’t allowed according to Rust’s interpretation of semver.
• RFC 1242. Various policies coving the crates that the Rust Project maintains. Establishes rust-lang-nursery.

[withoutboats]

531 needs to be amended to clarify its relationship with 1242.

It seems clear to me that the practice right now is that RFCs are used to induct crates into the nursery and promote or deprecate them out of it, but that while in the nursery those crates evolve and churn without any RFC process. The use of RFCs to manage this movement of crates seems contrary to 531 (to be 100% clear I’m not trying to challenge the process at all, I just want to clarify it).

Its unclear to me if, once promoted into rust-lang (as regex seems poised to do), crates would need to undergo the RFC process for API evolution the way std does. 531 suggests not, but it was written before there was a notion of a crate nursery.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.