Steering 2021 april 23: Guiding Principles Doc

--- 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/