Use these examples to decide whether a request fits the Tiny GitHub Fix Sprint.
- Fix a broken README command after a package or CLI flag changed.
- Replace dead documentation links with current public links.
- Add one missing install note that is already known from a public issue.
- Correct a small example so it matches the current documented API.
- Add a regression test for one public bug with clear expected behavior.
- Fix one small failing test where the failure is reproducible from the public repo.
- Patch a small docs/example bug and include the command used to verify it.
- Update a tiny CI/docs check when the expected output is objective.
- “Fix my app” or “make all tests pass” without a narrow failing command.
- Large migrations, rewrites, architecture/refactor requests, or subjective design work.
- Private repositories, private logs, production access, paid tools, credentials, API keys, cloud consoles, or customer data.
- Security exploit work, scraping abuse, spam/outreach, auth/payment/wallet logic, or KYC/tax/bank/identity work.
- Mobile/hardware-only testing unless a public simulator/repro path is enough.
- Public repo URL.
- Issue link or exact problem statement.
- Current behavior.
- Expected behavior.
- Acceptance criteria.
- Test command or verification path, if known.
- Whether a pull request is accepted or a patch file is preferred.
Please open a sprint request only after the scope is this narrow and public.