Skip to main content

Contributing

Thank you for considering making contributions to Sedge and Nethermind related repositories!

Contributing with a new feature or fix​

  1. Start by browsing new issues or in our Discord. If you are looking for something interesting or if you have something in your mind, there is a chance it had been discussed.

  2. Determine whether a GitHub issue or discussion is more appropriate for your needs:

  3. If you want to propose something new that requires specification or an additional design, or you would like to change a process, start with a new discussion or under Sedge Discord server at the Nethermind Org. With discussions, we can better handle the design process using discussion threads. A discussion usually leads to one or more issues.

  4. If the issue you want addressed is a specific proposal or a bug, then open a new issue.

  5. Review existing issues to find an issue you'd like to help with.

  6. Participate in thoughtful discussion on that issue.

  7. If you would like to contribute:

  8. Ensure that the proposal has been accepted.

  9. Ensure that nobody else has already begun working on this issue. If they have, make sure to contact them to collaborate.

  10. If nobody has been assigned for the issue, and you would like to work on it, make a comment on the issue to inform the community of your intentions to begin work.

  11. To submit your work as a contribution to the repository follow standard GitHub best practices. See pull request guideline below.

Note: For very small or blatantly obvious problems such as typos, you are not required to an open issue to submit a PR, but be aware that for more complex problems/features, if a PR is opened before an adequate design discussion has taken place in a GitHub issue, that PR runs a high likelihood of being rejected.

Open a discussion​

Pull Requests​

Before submitting a pull request:

  • Merge the latest develop git merge origin/develop,
  • run make format and make test to ensure that all checks and tests pass.
  1. If you have something to show, start with a Draft PR. It's good to have early validation of your work, and we highly recommend this practice. A Draft PR also indicates to the community that the work is in progress. Draft PRs also helps the core team provide early feedback and ensure the work is in the right direction.
  2. When the code is complete, change your PR from Draft to Ready for Review.
  3. Go through the actions for each checkbox present in the PR template description. The PR actions are automatically provided for each new PR.
  4. Be sure to include a relevant changelog entry in the Unreleased section of CHANGELOG.md (see file for log format). The entry should be on top of all others changes in the section.

Coding style​

We follow the Golang Code Style and Formatting guidelines. Please run make format before submitting a PR.

Comments​

Try to add comments to your code. If you are not sure what to comment, comment what you are doing.

Functions that are exposed to the public API should have comments in the form of GoDoc comments.

Logging​

Logging is done using Logrus.

Testing​

For each feature that you might consider to add, please add a test case to the test suite. This will help us to avoid regressions and to make sure that the feature works as expected.