Skip to content

Latest commit

 

History

History
64 lines (41 loc) · 3.12 KB

contributing.md

File metadata and controls

64 lines (41 loc) · 3.12 KB

Contributing to the SubQuery project

Welcome and a big thank you for considering contributing to this SubQuery project! Together we can pave the way to a more decentralised future.

What follows is a set of guidelines (not rules) for contributing to SubQuery. Following these guidelines will help us make the contribution process easy and effective for everyone involved. It also communicates that you agree to respect the time of the developers managing and developing this project. In return, we will reciprocate that respect by addressing your issue, considering changes, collaborating on improvements, and helping you finalise your pull requests.

Code of Conduct

We take our open source community projects and responsibility seriously and hold ourselves and other contributors to high standards of communication. By participating and contributing to this project, you agree to uphold our Code of Conduct.

Getting started

Contributions to our repositories are made through Issues and Pull Requests (PRs). A few general guidelines that cover both:

  • Search for existing Issues and PRs before creating your own.
  • We work hard to makes sure issues are handled in promptly but, depending on the impact, it could take a while to investigate the root cause. A friendly @ mention in the comment thread to the submitter or a contributor can help draw attention if your issue is blocking.

How to Contribute

Reporting Bugs

Bugs are tracked as GitHub issues. When logging an issue, explain the problem and include additional details to help maintainers reproduce the problem:

  • Use a clear and descriptive title for the issue to identify the problem.
  • Describe the exact steps to reproduce the problem.
  • Describe the behavior you observed after following the steps.
  • Explain which behavior you expected to see instead and why.
  • Include screenshots if possible.

Submitting Pull Requests

In general, we follow the "fork-and-pull" Git workflow

  • Fork the repository to your own Github account
  • Clone the project to your machine
  • Create a branch locally with a succinct but descriptive name
  • Commit changes to the branch
  • Following any formatting and testing guidelines specific to this repo
  • Push changes to your fork
  • Open a PR in our repository

Publishing to Github Releases

In order to publish to github release, there are prerequisites:

  • Firstly in the merged commit the phrase [release] must be present
  • Next, you must add a description of the release in the respective package's CHANGELOG.md
  • There must be some difference in the package compared with main
  • Lastly, the version must be in a format of x.y.z without '-'

When a pull request to main has been accepted the workflow will try to create releases for each package where possible.

Coding Conventions

Git Commit Messages

  • Use the present tense ("Add feature" not "Added feature")
  • Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  • Limit the first line to 72 characters or less

JavaScript Styleguide

  • All JavaScript code is linted with Prettier and ESLint