n34/CONTRIBUTING.md

Contributing to n34

For basic information about the n34 project, please read the README.md. The project is licensed under GPL-3.0, and by contributing, your work will also be licensed under the same terms.

Before submitting changes, please read the Developer Certificate of Origin. All patches must include a Signed-off-by: NAME <EMAIL> line to acknowledge your agreement with the DCO.

We welcome all contributions, whether it be bug reports, fixes, feature submissions, feature requests, or improving documentation or testing. Enjoy collaborating!

Git Repository

The repository is hosted at https://git.4rs.nl/awiteb/n34.git, with master as the active development branch.

Nostr Repository Address

You can submit issues and patches via any Nostr-compatible client using the address: naddr1qqpkuve5qgsqqqqqq9g9uljgjfcyd6dm4fegk8em2yfz0c3qp3tc6mntkrrhawgrqsqqqaueq yf8wumn8ghj7mn0wd68yt35wfejumnvqyxhwumn8ghj7mn0wvhxcmmvqy28wumn8ghj7mn0wd68ytn00 p68ytnyv4mqwuj6xc

Contribution Workflow

Before submitting changes, open an issue to discuss your proposed contribution. Clearly indicate that you intend to work on it and wait for a maintainer's response. If the issue remains open, you may proceed with submitting your patch.

Reporting Issues

When opening an issue, include:

• Detailed steps to reproduce the problem
• Relevant error messages or logs (use the -vvvv flag for verbose output)
• Expected vs. actual behavior

Please label your issue appropriately (e.g., bug, feature, question) to help categorize it.

Your Patch

Ensure your patch submission tool notifies the maintainers and sends the patch to their read relays, most tools handle this automatically.

Patch Guidelines

• Keep patches small: Focused changes are easier to review and merge.
• Use Conventional Commits: Start the patch subject with one of these types:
  • feat: New feature
  • fix: Bug fix
  • docs: Documentation updates
  • refactor: Code restructuring without behavioral changes
  • deprecate: Marking code as deprecated
  • remove: Removing deprecated code
  • security: Security-related changes
  • perf: Performance improvements
  • test: Test additions or corrections
• For all other changes, use chore.
• Add ! to the subject if your patch contains a breacking change, e.g. remove!: text and fix(reply)!: text
• Run just ci before submitting your patch.

Code Style

When writing code, make sure to folow this:

• Using Rust's official formatting tool, rustfmt, to format your code.
• Writing clear and concise code with meaningful variable and function names.
• Adding comments to explain complex logic or algorithms.

Cover Letter Description

Your patch description should provide a clear and concise summary of the changes you have made. It should also include any relevant context or background information that will help the project maintainers understand the purpose of the changes. Make sure to reference the issue¹ that your patch is addressing, and note any breaking changes that your patch introduces.

---

1. When referencing, avoid URLs or nevent formats with relays. Instead, use only the note ID in note1 bech32 format. ↩︎