The contribution bar
The bar is evidence, not enthusiasm. A change should be reproducible, bounded, and testable. The project is small on purpose; a large pull request is not automatically valuable.
- A clear problem statement and the failure it causes.
- A threat model for any new edge, credential, or network path.
- Tests that fail before the change and pass after it.
- Documentation for behavior, limits, and status labels.
- No secrets, tokens, personal data, or generated vendor dumps.
- License compatibility and provenance for new dependencies.
How review works
- A written problem statement, not a screenshot of a chat.
- A scope check: does this fit one operator and the product boundaries?
- A security review for new inputs, outputs, and authority.
- Tests and a failure-mode review, including timeouts and recovery.
- A docs update with the correct status label.
- Merge only when the claim matches the evidence.
Review is not a popularity vote. A feature can be useful and still be out of scope.
Security reports
Keep reports out of public threads
Do not post exploit details, tokens, or personal data publicly. Share them directly with the maintainer.
A public dump can harm operators who are running the source tree. Keep reports scoped and reproducible.
Community principles
- Evidence over volume. A small test beats a long opinion.
- Scope is a feature. “No” is a valid answer when the boundary matters.
- No hidden authority. Do not ask for access you cannot explain.
- No secret sharing. Never paste keys, vault contents, or private logs.
- No fake affiliation. Do not claim to represent DreenMind.