CONTRIBUTING.md

# Contributing to IRRd

Looking to contribute something to IRRd? **Here's how you can help.**

Please take a moment to review this document in order to make the contribution
process easy and effective for everyone involved.

Following these guidelines helps to communicate that you respect the time of
the developers managing and developing this open source project. In return,
they should reciprocate that respect in addressing your issue or assessing
patches and features.

## Reporting a Vulnerability

If you have found an issue, strange behaviour, possible oversight,
or anything else that may have security implications, please do not
report it in the GitHub repository, but email irrd@reliablycoded.nl.
See the [security policy](SECURITY.rst) for additional details.

## Using the issue tracker

The [issue tracker](https://github.com/irrdnet/irrd/issues) is
the preferred channel for [bug reports](#bug-reports), [features requests](#feature-requests)
and [submitting pull requests](#pull-requests)

## Bug reports

A bug is a _demonstrable problem_ that is caused by the code in the repository.
Good bug reports are extremely helpful, so thanks!

Guidelines for bug reports:

1. **Use the GitHub issue search** — check if the issue has already been
   reported.

2. **Check if the issue has been fixed** — try to reproduce it using the
   latest `main` branch.

3. **Isolate the problem** — ideally create a reproducible process which
   the maintainers can use to reproduce the problem. Include any error messages,
   tracebacks, or details about your system, or other details about your installation
   which may be of value to the maintainers.

However, if you're unable to do some of these while suspecting a bug,
please file the bug report anyways.

## Feature requests

Feature requests are welcome. Please do explain the
context of your feature request, so that the maintainers can see how
and where it may fit into the project, and what other solutions may
be possible.

## Pull requests

Good pull requests—patches, improvements, new features—are a fantastic
help. They should remain focused in scope and avoid containing unrelated
commits.

**Please ask first** before embarking on any significant pull request (e.g.
implementing features, refactoring code, porting to a different language),
otherwise you risk spending a lot of time working on something that the
project's developers might not want to merge into the project.

Please adhere to the coding guidelines used throughout the
project. There is continuous integration that checks for code style and
code coverage. Most changes should be included in the release notes,
and new features should be documented. IRRd is also fairly strong in
maintaining backwards compatibility, but there are exceptions.

If you have difficulties with your PR, for example in adjusting the tests,
the maintainers are happy to help out.

**IMPORTANT**: By submitting a patch, you agree to allow the project owners to
license your work under the terms of the [BSD-2-Clause](LICENSE).

## License

By contributing your code, you agree to license your contribution under the [BSD-2-Clause License](LICENSE).