Skip to content

Latest commit

 

History

History
67 lines (50 loc) · 2.75 KB

CONTRIBUTING.md

File metadata and controls

67 lines (50 loc) · 2.75 KB

Substrate Sidecar API is an open source project that welcomes new issues and PRs.

If you’re new to open source or interested in contributing, this guide is particularly helpful: How to Contribute to Open Source.

Contributing Code

To contribute to this repo, start by creating a GitHub Issue, which will allow you to gather feedback before writing any code. In the Issues tab, you’ll be able to select from a template to create an Issue.

To create a Pull Request after you’ve created an Issue, you’ll need to head over to the Pull Request tab. This will be where all the PRs will be located, and where reviewers will be able to review your changes made.

Before submitting a PR

  • yarn lint: Make sure your code follows our linting rules. You can also run yarn lint:fix or yarn lint --fix to automatically fix some of those errors.
  • yarn test: Make sure all tests pass.
  • If any changes are made to the OpenApi specs :
    • Verify the changes with an editor such as swagger as mentioned in the README.
    • Run yarn build:docs to make sure to rebuild the UI.

Rules

There are a few basic ground-rules for contributors (including the maintainer(s) of the project):

  • Try to avoid --force pushes or modifying the Git history in any way. If you need to rebase, ensure you do it in your own repo.
  • Non-master branches, prefixed with a short name moniker (e.g. gav-my-feature), must be used for ongoing work.
  • All modifications must be made in a Pull Request to solicit feedback from other contributors.
  • Contributors should adhere to the house coding style.

Reviewing Pull Requests:

When reviewing a Pull Request, the end goal is to suggest useful changes to the author. Reviews should finish with approval unless there are issues that would result in:

  • Buggy behaviour.
  • Undue maintenance burden.
  • Breaking with house coding style.
  • Poor performance.
  • Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on).
  • Uselessness (i.e. it does not strictly add a feature or fix a known issue).

Where to Ask for Help

Asking for help in the Parity community is encouraged and welcomed! The best ways to reach us are:

Heritage

These contributing guidelines are modified from the "OPEN Open Source Project" guidelines for the Level project: https://github.com/Level/community/blob/master/CONTRIBUTING.md