Tracking issue for beefing up contribution docs

[jieyouxu]

As part of the effort to onboard new contributors and maintainers, we probably want to extend contribution docs across several aspects:

• rustfmt's test infra and present test suites, and how to work with them
• What exactly constitutes breaking changes (cf. https://github.com/rust-lang/rustfmt/blob/5e937e0800ac2b3d7baee168f63f24ee01ccae6d/Contributing.md#gate-formatting-changes and https://rust-lang.github.io/rfcs/3338-style-evolution.html)
  • For the different
• Review guideline and advice
• Issue triage
• PR triage
• Issue prioritization
• PR prioritization
• Experimenting and assessing ecosystem impact
• Subtree syncs: Add a rustfmt-specific copy of subtree sync procedure #6740
• Producing MCVEs
• Interactions with rust-lang/rust and compiler internals (since rustfmt is a rustc_private-tool)
• Release notes
• Backport nomination, approval and logistics
• Reverts
• Walkthrough-esque guides for different kind of common contribution "paths"

And probably from POV of both PR authors and reviewers. Could consider a doc approach like https://diataxis.fr/.

We probably want to also double-check the present design docs at https://github.com/rust-lang/rustfmt/blob/5e937e0800ac2b3d7baee168f63f24ee01ccae6d/Design.md.

Potential follow-ups

• Issue template for tracking issues