tags: tenets
---

# \[draft\] rustc Contributor Guiding Principles \[23 apr 2021\]

----

**next draft is being composed here:** https://hackmd.io/24XY68xUSkyqDAv0w8HmYw

**old draft follows**

----

These are our guiding principles; they are meant to guide people in making decisions about how to make contributions to the rustc code base, and how to interact with others on the project.
* If you notice the word "tenet" in discussions of this document, it is a holdover from an earlier draft that called these things "tenets."
* Why "tenet:" Because pnkfelix was inspired to do this by the example set at his workplace, where they call such guiding principles "tenets."
* Why not "tenet": it was pointed out that the word is sufficient obscure as to be a road-block for non-native English speakers.

This list is open to change; if you have suggestions for:
1. new principles to add,
2. amendments to the existing ones,
3. an argument for why a proposed principle should not be on this list, or
4. an unaddressed domain that should be covered here,

then please do reach out to the compiler team leadership!

Sometimes these principles will conflict with one another. In those scenarios, the lowest-numbered principle (i.e. the one that comes earlier in the list) takes priority.

### *(These are still in draft status)*

* *Change Notes:*
- *2021-04-23: Miscellanous revisions based on [steering meeting][2021-04-23 mtg]*
- *2021-03-31: Added "Accommodate other cultures/perspectives"*
- *2021-03-24: Initial circulation amongst team leads*
- *2021-04-05: Added expository text for "Take team feedback seriously"; added "empathy" bullet to "Our community health matters most"*

*The general format is: 1. Succinct Title, 2. expository text explaining the principle in the abstract, 3. bullets with concrete illustrative examples.*

[2021-04-23 mtg]: https://zulip-archive.rust-lang.org/238009tcompilermeetings/95764steeringmeeting20210323GPscompilerteam424.html

## Our community health matters most

Without a healthy community, we don't have a project. Every contributor needs to respect the time and workload of other community members.

* Nearly every interaction is an opportunity to be *empathetic*: Listen well enough to put yourself in the shoes of others. Strive to understand their motivations.
* Be aware that everyone, be they volunteers or paid contributors, is balancing multiple priorities.
* You might have to wait to get feedback. Try to notice if you are putting a large workload on one or two people, and rebalance accordingly.

## All software has bugs

While Rust prides itself on its soundness and stability guarantees, the compiler team also recognizes that bugs are going to happen. We try to select designs that are simple enough to maintain. We expect problems to arise, and we establish mechanisms to limit the fallout from mistakes.

## Rust is Production-Grade

(formerly ~~Rust is a product~~)

Rust aims to be a production-grade piece of software. We have users who depend on Rust to remain high quality, while still delivering new features and updates.

* We will continue to encourage research efforts and hobbyist contributions, which have been responsible for many of Rust's advances. But we must prioritize Rust's needs as a product over its use as an experimental testbed.

## Our ownership is shared, not exclusive

Keep the team in mind when contributing. Code implementations and proposed solutions need to be designed in a way that ensures we can all maintain their consequences. Not just the designer, and not just the designer and the reviewer.

* We know not everyone can know everything. What we strive for is everyone *could* adopt ownership, utilizing associated documentation.

## Keep the trains running

Much of our operation as a team is oriented around our release channels.

* This means that developing new features for nightly often takes a back seat to resolving a problem on beta, before it becomes a problem for our stable users.

## Accommodate other cultures/perspectives

The contributors to Rust are distributed throughout the globe, and come from all walks of life. Not every contributor has a systems programming or even a computer science background.

* We tend to do our work in English; try to use words that are not obscure.

## Take our time now to save everyone's time later

We take our time in developing a design, though both ad-hoc discussion and concrete design documentation. We structure our code and pull requests to ease their interpretation by future readers.

* Example of taking time in design: We avoid jumping straight to Pull Requests for major changes to the code base. Instead, we establish processes to discuss changes before they are realized as code. (Examples of this include RFCs, MCPs, and design meetings.)
* Example of taking time in PR structure: Before putting a Pull Request up for review, first look over its commit history. If the commit history divided up well (e.g. keeping refactorings in a separate commit from behavioral changes, while coupling updates to unit tests with the commits that required those updates), it will ease subsequent reviews, including the ones that matter most to you: The initial review loops that get the Pull Request approved!

## Get Buy-In

We get buy-in from multiple stakeholders on any design proposal.

* Such buy-in includes at least one stake-holder agreeing to take on review responsibilities. (This is spelled out in our MCP process.)

## Challenge assumptions (your own and other people's)

We invite others to review our designs (both existing and proposed), and we actively seek people to disconfirm our beliefs and challenge our assumptions.

## Take team feedback seriously

The Rust compiler team wants to add members over time, and to achieve that goal, we invest effort in mentoring our contributors. If we tell you something, it is usually because we want to help you become a more effective contributor.

* If the team collectively discussed a matter and then sent their feedback on next steps, your first act should be to digest that feedback fully.
* Sometimes that feedback will not match your expectations. Challenging the feedback can be a reasonable response, *after* first demonstrating understanding of it.

## Aim high!

XXX (exposition needed)

* Rust is still young. pnkfelix suspects it is at, or near, a knee point at its adoption rate, where it may really skyrocket soon.
* That means we have an opportunity to land significant changes while the impact is (relatively) limited, and those changes can have huge follow-on effect as Rust's user base multiplies.

## Every little bit helps

Rust is still young. It has lots of papercuts still, and much low-hanging fruit for new contributors.

## Err on the side of exposition

The audience for Rust comes from many different backgrounds. We invest in providing high-quality diagnostic feedback and elaborate help messages in our compiler, in order to lift every programmer up to the same level of understanding.

## Value practical portabilty

XXX (exposition needed)

* Rust has various features and lints to encourage people to write portable software. We encourage this, but we also want our lints to have a high signal-to-noise ratio, which in this context means that we avoid lints that are accommodating esoteric targets that few of our users have access to.