Thanks for looking. This is the default guidance for SCCSSAR repositories; where a repository has its own CONTRIBUTING.md, follow that one.
Open an issue first for anything larger than a fix. These tools run during live callouts, so a change that looks like an improvement can break an assumption that a search team depends on. A short conversation up front saves rework.
Small corrections, typos, broken links and documentation fixes need no ceremony. Send the pull request.
- Never commit real incident data. No coordinates from an actual search, no map identifiers, no photographs, no subject names, no dates tied to a real callout. This applies to test fixtures, docstrings, example output and commit messages, which is exactly where it tends to slip through. Use obviously synthetic values.
- Never commit credentials. API keys, tokens and
.envfiles stay out. Secret scanning and push protection are on, and they are the backstop rather than the plan. - Keep the diff to one logical change. If you find a second problem, note it and open a separate issue.
- Match the surrounding style even if you would write it differently.
If the repository has tests, run them and add one for what you changed. A test that passes proves less than a test that fails when the code breaks, so where you can, check that yours actually catches the bug it describes.
Explain what failed and why the change fixes it. A PR that says what it does is fine. A PR that says what went wrong is better, because the next person hits the same thing.
Every pull request is reviewed before merge. Expect questions, and expect that some of them are about operational consequences rather than the code.
Contributions are accepted under each repository's license, which is BSD-3-Clause unless the repository says otherwise.