## Default Posture (No CONTRIBUTING.md)

When a project has no contributing guide, assume these defaults:

### Filing Issues

- **Bug reports** always include: OS, version, reproduction steps, expected vs actual behavior
- **Feature requests** always include: the problem, not just your solution
- Search existing issues first — duplicates annoy merchants
- Use a clear, descriptive title — "It crashes" is useless; "Null pointer in login redirect when session is expired" is helpful

### Pull Requests

- One PR per logical change (small and focused)
- Descriptive commit messages explaining *why*, not just *what*
- Include tests for new code
- Include relevant documentation updates
- Reference any related issues
- Ensure CI passes before requesting review
- Use `git commit -s` (Signed-off-by) unless you know the project doesn't require DCO

### Communication

- **Be respectful and constructive** — assume good faith, even when frustrated
- **Be patient** — maintainers are often volunteers with limited time
- **Explain your reasoning** — code reviews are asynchronous; your reviewer can't read your mind
- **Don't demand attention** — "any update?" once after 2 weeks is fine. Daily bumps are not.
- **Offer to fix things pointed out in review** rather than arguing about style preferences
- **Thank maintainers** for their time — it costs nothing and matters a lot

### Code of Conduct

Even without a documented CoC, follow these basic norms:
- No personal attacks, insults, or derogatory language
- No entitlement — maintainers don't owe you their time
- Respect project decisions you disagree with (you can always fork)
- Credit others' work — if you build on someone else's contribution, acknowledge it

---