- Check the open issues.
- View the open mileposts. (see: Milepost Methodology)
- Check especially what's
up for grabs
,high priority
, orlevel: starter
. - Read some docs, like: 📖 Frontend: Getting Started
Then, tell folks what you'll be working on, and:
Everyone must follow the rules below (inspired by the C4.1 process) to submit code (documentation may be edited directly by maintainers):
- Always work in your own fork and submit pull requests (PRs) to
master
. - Always submit a minimal and accurate answer to any issue. The simplest solution is the best solution.
- Always add/update tests for any new/modified functionality. (:exclamation:)
- Always make sure your PR passes all tests (
grunt test
). - Always ensure your PR adheres to the Contribution Policy described below.
This contribution policy will evolve over time. For now it is based on a mixture of the Mileposts Methodology and a slightly modified subset of C4.1.
- All contributions to the project source code ("patches" or "pull requests") SHALL use the same license as the project.
- All patches are owned by their authors. There SHALL NOT be any copyright assignment process.
- Each Contributor SHALL be responsible for identifying themselves in the project Contributor list.
- A PR SHOULD be a minimal and accurate answer to exactly one identified and agreed problem.
- A PR SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code.
- A PR MUST pass all tests on at least the principle target platform.
- A PR MUST include new tests for any new functionality introduced.
- A PR SHOULD avoid "callback-hell" style and instead prefer "async/await" style.
- A PR MUST follow the requirements spelled out in this project's Style Guide.
- Check if there's an open/closed issue that answers your question.
- Read troubleshooting docs.
- Create an issue in the required problem-solution or milepost format.