Skip to content

Latest commit

 

History

History
71 lines (42 loc) · 2.82 KB

CONTRIBUTING.md

File metadata and controls

71 lines (42 loc) · 2.82 KB
Raw

Contributing

🎈 Thanks for your help improving the project! We are so happy to have you!

🚨 Before making any non-trivial change, please first open an issue describing the change to solicit feedback and guidance. This will increase the likelihood of the PR getting merged.

In general, the smaller the diff the easier it will be for us to review quickly.

Please note that we have a Code of Conduct, please follow it in all your interactions with the project.

Pull Request Process

Steps for the PR author

We recommend using the Conventional Commits format on commit messages.

Before opening a PR:

  1. Ensure that tests pass and code is lint free. You can run yarn test and yarn lint locally to check.
  2. Update the README.md if your changes invalidate or extend its current content.
  3. Include tests for any new functionality.
  4. Ensure each section of the Pull Request Template is filled out. Delete any sections that are not relevant.

Unless your PR is ready for immediate review and merging, please mark it as 'draft' (or simply do not open a PR yet).

Bonus: Add comments to the diff under the "Files Changed" tab on the PR page to clarify any sections where you think we might have questions about the approach taken.

Response time:

We aim to provide a meaningful response to all PRs and issues from external contributors within 2 business days.

Steps for PR Reviewers

For all PRs

Reviewers should submit their review with either Approve or Request changes options (not Comment).

If the reviewer selects Request changes, they should clearly indicate which changes they require in order to approve.

If the reviewer selects Approves, they should either:

  1. immediately merge it, or
  2. indicate what further review they deem necessary (and from whom).

We further distinguish between two classes of PR those which modify production code (ie. smart contracts, go-ethereum), and those which do not (ie. dev tooling, test scripts, comments).

For PRs which modify production code

The reviewer's job is to check that the PR:

  1. Conforms to the specification (WIP, soon to be published here), or has an issue describing the additional functionality which a code owner has approved.
  2. Is appropriately tested.
  3. Does not introduce security issues.

Merge Criteria

  1. All CI checks MUST pass.
  2. At least 2 code owners must approve.
  3. In the case of very simple changes, a single code owner may choose to merge at their discretion.

For PRs which modify non-production code

For PRs which do not modify production code (ie. test, dev tooling),

The reviewer's job is to check that the PR:

  1. Is correct.
  2. Is desirable.

Merge Criteria

  1. All CI checks MUST pass.
  2. At least one code owner must approve.