Skip to content

Latest commit

 

History

History
54 lines (30 loc) · 2.58 KB

CONTRIBUTING.md

File metadata and controls

54 lines (30 loc) · 2.58 KB
Raw

Contributing to eigensdk-go

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

Before making a pull request, please fork the repository and create a new branch.

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

Security Bugs

Please report security vulnerabilities to [email protected]. Do NOT report security bugs via Github Issues.