CONTRIBUTING: small updates

CONTRIBUTING.md

@@ -1,32 +1,43 @@
 # Contributing to ROOST
-Thank you for being interested in contributing to ROOST! Together we’re making Trust & Safety tools available to all. Please take a moment to review our Contributing guidelines. 
 
-## Ways to Contribute
-### Bugs and docs fixes
-For small, easily reproducible bugs or small documentation changes, you can directly open a PR. Please identify it as a bug or fix in the subject line, and write a succinct commit message.
+Thank you for being interested in contributing to ROOST! Together we’re making Trust & Safety tools available to all. Please take a moment to review our contributing guidelines. 
 
-For medium-sized to big bugs or for feature enhancements, please start with an Issue. _(We don’t yet have an issue template; perhaps you could contribute one?!)_
+## Ways to contribute
 
-If auto-generated Issues don’t provide meaningful suggestions and a way of following up with a human author, we will consider these spam and close them. 
+### Small fixes
 
-### Code contributions
-Code contributions and significant pieces of documentation (aka Pull Requests) should have a corresponding Issue. We do this to make sure there’s lazy consensus on an idea before someone puts effort behind it, and let the community give feedback on the design.
-If you’re eager to start contributing code to ROOST, start with an open Issue!
+For small, easily reproducible bugs or small documentation changes, you may directly open a PR. Please identify it as a fix in the title, and write a succinct explanation of the change in the description.
+
+For medium- to large-sized bugs, feature enhancements, or larger documentation changes, please start by **creating an issue**.
+
+If issues are overly verbose/difficult to parse, don’t provide meaningful suggestions, and/or don't provide a reliable way to follow up with a human author, project maintainers may consider these spam and close them. 
+
+### Nontrivial contributions
+
+**Pull requests with nontrivial code or documentation contributions should be linked to a corresponding issue.** We do this to ensure there’s lazy consensus on an idea before someone puts effort behind it, to enable the community give feedback on the design, to aid triage and prioritization, and to improve milestone tracking and release management.
+
+If you’re eager to start contributing code to ROOST, start with an open issue!
 
 ### Tutorials and demos
-We’re excited to see you try ROOST tools! For now, please start Tutorial or Demo contributions as Issues. This bird is young and we’re still building our nest. We’ll help find a good place for these on a case-by-case basis.
+
+We’re excited to see you try ROOST tools! For now, please start tutorial or demo contributions as a GitHub Discussion. This bird is young and we’re still building our nest. We’ll help find a good place for these on a case-by-case basis.
 
 ### Testing and code review
-Even if you don’t have merge permissions on ROOST repos, you can still help by reviewing code. This means reviewing PRs, their corresponding Issues, and validating solutions, and providing feedback and suggestions to the author.
-General ideas
-Have a thought but not sure it’s “Issue ready”? Throw it in a GitHub Discussion or our Discord channel! 
+
+Even if you don’t have merge permissions on ROOST repos, you can still help by reviewing code. This means reviewing PRs and their corresponding issues, validating solutions, and providing feedback and suggestions to the author.
+
+### General ideas
+
+Have a thought but not sure it’s “Issue ready”? Share it in a GitHub Discussion or our [Discord server](https://discord.gg/5Csqnw2FSQ)!
 
 ### AI-assisted coding policy
-Contributors are responsible for submitting original work to ROOST projects. This does not preclude the use of developer tools and aids, including AI coding assistants, but the final product must be the contributor's original work. Regardless of development aids, contributors should always submit work that they can explain and that follow good practices for de-buggable and maintainable code.
 
-## Code Review Process
-We follow the principle of two party review, which means that an author cannot “self approve” their submission. While we’re defining our maintainership ladder, a code owner must merge code in. You can help by “+” or “thumbs up” other PRs that you’d like to see merged.  
+**Contributors are responsible for submitting original work to ROOST projects.** This does not preclude the use of developer tools and aids, including AI coding assistants, but the final product must be the contributor's original work. Regardless of development aids, contributors should always submit work that they can explain, that is reasonably reviewable by the maintainers, and that follows good practices for debuggable and maintainable code.
+
+## Code review process
+
+We follow the principle of two party review, which means that an author cannot “self approve” their submission. Project [maintainers](https://roostorg.github.io/community/roles#maintainers) or trusted community contributors must review and approve contributions before merging them.
 
-ROOST is focused on building high-quality, functional infrastructure tooling. That means that not every feature or refactor is going to be accepted right now (even if it’s a good idea long term). Please be gracious if your proposal is tabled or added to the future roadmap instead of merged.
+ROOST is focused on building high-quality, functional infrastructure tooling. That means that not every feature or refactor is going to be accepted right now (even if it’s a good idea long term). Please be gracious if your proposal is put on hold or added to the future roadmap instead of merged.
 
-Thank You!
+Thank you!