Skip to content

Latest commit

 

History

History
70 lines (53 loc) · 3.6 KB

CONTRIBUTING.md

File metadata and controls

70 lines (53 loc) · 3.6 KB
Raw

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 you add a new endpoint or update an existing one (by modifying its parameters or output), you will also need to update the documentation (OpenApi specs). Here are some common steps to follow in order to do that:
    • Update this file by adding or updating the corresponding endpoint description in the paths and schemas sections.
    • After you complete the changes, verify that the yaml file has no errors by copying the contents of this file into the Swagger Editor or the New Swagger Editor.
    • If there are no errors, run yarn build:docs from the root directory of this repository. This will make sure that the dist is updated with the current changes.
    • Next, open the docs/dist/index.html page (by copying its path) in your browser to confirm that all changes have been applied and appear as expected.
    • If everything looks good, push the changes.

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