---
# System prepended metadata

title: 'Steering 2021 april 23: Guiding Principles Doc'
tags: [' rustc', steering]

---

---
tags: steering, rustc
---

# Steering 2021 april 23: Guiding Principles Doc

## The doc

link: https://hackmd.io/TYGRjVIbSBmxpbcfDzll-w?view

## Feedback

some points are potentially wrong (e.g. "Rust is product")

There's too many; redundancy

## Over-arching principles

 * Kind to each other
 * Kind to our users
 * Kind to new contributors

(At the very least, we could easily *tag* each principle with which of the umbrella it best falls under.)

## Hard problems or tricky cases 

* Do we accept PRs that consist entirely of nits, spelling corrections, etc?
    * Conclusion: no, because they mess up commit history, take up reviewer time, and provide insufficient value.
* How to approach complex, experimental projects, tech debt
    * Case study: Parallel rust
        * We landed however initial PRs and iterated in place, because we wanted to not stall momentum
        * We decided to move forward but work stalled, many folks felt that the design was too complex
* Whether to revert a buggy PR, or a PR with unexpected impact, or to fix it in place
    * We tend to avoid reverts, but many folks also feel we should be more eager to revert and take the time to fix
* Whether to fix a bug immediately or to do a future-compatibility warning or perhaps just to accept the behavior as "unfortunate but binding"
    * The [bug fix procedure](https://rustc-dev-guide.rust-lang.org/bug-fix-procedure.html) encourages us to consider the impact of a change and to phase changes in that will affect existing code, even if they are 
* Do we build things in one repo vs multiple repos?
* How do we coordinate changes that affect other Rust tools, like clippy?
* What do we do with accidental stabilizations?
    * RFC xxX concluded that they are not stable
    * Similarly when we found bugs in our macro-rules future proofing rules, we tended to extend the language with the "spirit" of the original RFC
    * Both cases where we preserved our ability to make changes over existing users

## Do we talk about users or customers? Products or production-grade?

* General desire to avoid "commercial" terminology
* 

## Proposed smaller set of Principles

Go to next draft and write them there: https://hackmd.io/24XY68xUSkyqDAv0w8HmYw

## Reading List

Async Rust Guiding Principles: https://hackmd.io/haMJf784SAemBbGyO5Wi6Q

As a Designer, I Refuse to Call People "Users": https://medium.com/s/user-friendly/why-im-done-saying-user-user-experience-and-ux-in-2019-4fdfc6b7de23

Stack Exchange, "Better Term For User": https://ux.stackexchange.com/questions/11401/better-term-for-user

Jessica Lord, "Privilege, Community, and Open Source": http://jlord.us/blog/osos-talk.html

Niko, "More than Coders": https://smallcultfollowing.com/babysteps/blog/2019/04/15/more-than-coders/

