Tracking issue for beefing up contribution docs

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: https://github.com/rust-lang/rustfmt/pull/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

Start by reviewing Contributing.md and Design.md, then compare their guidance with the linked RFC and the listed contribution areas. Break the tracking issue into focused documentation tasks, including test infrastructure, review and triage guidance, release logistics, and contribution paths. Done means the selected scope is documented and any follow-up issue is clearly defined.