When contributing to this repository, please check our open issues and whether there is already an issue related to your idea. Please first discuss the change you wish to make in a GitHub issue and wait for a reply from the maintainers of this repository before making a change.
We have a code of conduct; please follow it in all your interactions relating to the project.
Develop locally using the
VSCode Remote Container
extension and Docker.
To develop on your machine, install the following (and please submit issues if errors crop up)
- Deno
- Docker
- NodeJS (only necessary if you're going to run the dnt task)
- dprint
There are a few basic ground-rules for contributors:
- All modifications must be made in a pull-request to solicit feedback from other contributors
- Contributors should attempt to adhere to the prevailing code-style
For a pull request to be merged it must at least:
✅ Pass CI
✅ Have one approving review
✅ Have the PR title follow conventional commit
Ideally, a good pull request should:
🕒 Take less than 15 minutes to review
📖 Have a meaningful description (describes the problem being solved)
1️⃣ Introduce one feature or solve one bug at a time, for which an open issue already exists. In case of a project wide refactoring, a larger PR is to be expected, but the reviewer should be more carefully guided through it
🧩 Issues that seem too big for a PR that can be reviewed in 15 minutes or PRs that need to touch other issues should be discussed and probably split differently before starting any development
🎯 Handle renaming, moving files, linting and formatting separately (not alongside features or bug fixes)
🧪 Add tests for new functionality
Draft pull requests for early feedback are welcome and do not need to adhere to any guidelines.
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 behavior
❌ Undue maintenance burden
❌ Measurable performance issues
❌ 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)
❌ Disabling a compiler feature to introduce code that wouldn't compile
We use the following tools to enforce linting rules, formatting and spell checking
We encourage adding the recommended (or similar) extensions to your IDE.
To run a project wide check you can use:
deno lint
dprint fmt # or dprint check
cspell "**/*"Declaring formal releases remains the prerogative of the project maintainer(s).
By contributing to project, you agree that your contributions will be licensed under its Apache license.
This is an experiment and feedback is welcome! This document may also be subject to pull-requests or changes by contributors where you believe you have something valuable to add or change.
These contributing guidelines are modified from
- the "Substrate Project" guidelines https://github.com/paritytech/substrate/blob/master/docs/CONTRIBUTING.adoc
- the "Substrate Contracts UI" guidelines https://github.com/paritytech/contracts-ui/blob/master/CONTRIBUTING.md