The Nethermind team maintains guidelines for contributing to the Nethermind repos. Check out our docs page for more info about us.
Have you read the code of conduct?
Before you make your changes, check to see if an issue exists already for the change you want to make.
If you spot something new, open an issue using a template. We'll use the issue to have a conversation about the problem you want to fix.
When you're done making changes and you'd like to propose them for review, use the pull request template to open your PR (pull request).
Please do not open more than one PR at a time as stated below.
Suggest your change by opening an issue and starting a discussion.
Please do:
- DO give priority to the current style of the project or file you're changing even if it diverges from the general guidelines.
- DO include tests when adding new features. When fixing bugs, start with adding a test that highlights how the current behavior is broken.
- DO especially follow our rules in the Contributing section of our code of conduct.
Please do not:
- DON'T fill the issues and PR descriptions vaguely. The elements in the templates are there for a good reason. Help the team.
- DON'T surprise us with big pull requests. Instead, file an issue and start a discussion so we can agree on a direction before you invest a large amount of time.
- DON'T open more than one pull request at a time, unless agreed beforehand with a maintainer.
- DON'T submit code you haven't carefully reviewed and can't explain — whether you wrote it or an LLM did. You are responsible for every line in your PR.
These guidelines exist to welcome contributors who want to learn and help the project, while keeping out low-effort submissions. Low-effort PRs drain the team's energy: each one takes rounds of back-and-forth to reach a mergeable state, pulling maintainers away from their own work. Maintainers may close such PRs without detailed review, and repeated violations may result in a block from the repository.
Branch names must follow the kebab-case pattern. When possible, use the folder/<name> structure — typically feature/<name> or fix/<name> — and reference the issue number if applicable.