To maintain the integrity and quality of the rust-nostr codebase, we do
not accept contributions that contain code generated by LLMs (AI). You are
welcome to use LLMs to explore ideas or describe features and bugs when
opening an issue, but any pull requests or patches must consist of code
written directly by the contributor.
Before writing code, please read our code style.
To contribute a patch:
- Fork the repository
- Create a topic branch
- Commit patches (PR, emails, nostr, ...)
In general, commits should be atomic and diffs easy to read.
Where possible, breaking existing APIs should be avoided. Instead, add new APIs and mark the old ones as deprecated.
Deprecated APIs are typically maintained for one release cycle. In other words, an API that has been deprecated with the 0.10 release can be expected to be removed in the 0.11 release. This allows for smoother upgrades without incurring too much technical debt inside this library.
If you deprecated an API as part of a contribution, we encourage you to "own" that API and send a follow-up to remove it as part of the next release cycle.
Concept ACK — Agree with the idea and overall direction, but haven't reviewed the code changes or tested them.
utACK (untested ACK) — Reviewed and agree with the code changes but haven't tested them.
tACK (tested ACK) — Reviewed the code changes and have verified the functionality or bug fix.
ACK — A loose ACK can be confusing. It's best to avoid them unless it's a documentation/comment-only change in which case there is nothing to test/verify; therefore, the tested/untested distinction is not there.
NACK — Disagree with the code changes/concept. Should be accompanied by an explanation.