Skip to content

Latest commit

 

History

History
62 lines (36 loc) · 3.02 KB

CONTRIBUTING.md

File metadata and controls

62 lines (36 loc) · 3.02 KB
Raw

Contributing to sedge

The Nethermind team maintains guidelines for contributing to the Nethermind repos. Check out our docs page for more info about us.

Code of Conduct

Have you read the code of conduct?

Bugs and Feature Request

Before you make your changes, check to see if an issue exists already for the change you want to make.

Don't see your issue? Open one

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.

Open a Pull Request

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).

If your PR is not ready for review and merge because you are still working on it, please convert it to draft and add to it the label wip (work in progress). This label allows to filter correctly the rest of PR not wip.

Do you intend to add a new feature or change an existing one?

Suggest your change by opening an issue and starting a discussion.

Improving Issues and PR

Please add, if possible, a reviewer, assignees and labels to your issue and PR.

DOs and DON'Ts

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.
  • DO write idiomatic golang code

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.

Branch Naming

Branch names must follow kebab-case pattern. Follow the pattern feature/<name> or fix/<name> (folder/<name>) when it is possible and add issue reference if applicable.

Commit Naming

Commits must follow the <type>(<scope>): <subject> pattern, as stated in the Conventional Commits specification

Changelog

Sedge's changelog format is based on Keep a Changelog. Every PR must update the Unreleased section of the project CHANGELOG.md with the new changes. The changes must follow the following structure:

  • Added for new features.
  • Changed for changes in existing functionality.
  • Deprecated for soon-to-be removed features.
  • Removed for now removed features.
  • Fixed for any bug fixes.
  • Security in case of vulnerabilities.