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 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.
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?!)
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.
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!
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.
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!
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.
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.
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.
Thank You!