Skip to content

Latest commit

 

History

History
83 lines (60 loc) · 3.97 KB

CONTRIBUTING.md

File metadata and controls

83 lines (60 loc) · 3.97 KB
Raw

Contributor Guidelines

Advice for new contributors

Start small. The PRs most likely to be merged are the ones that make small, easily reviewed changes with clear and specific intentions.

It's a good idea to gauge interest in your intended work by finding or creating a GitHub Issue for it.

You're most likely to have your pull request accepted if it addresses an existing GitHub Issue marked with the good-first-issue tag.

Of course, we encourage community developers to work on ANY issue, regardless of how it’s tagged, however, if you pick up or create an issue without the “Good first issue” tag it would be best if you leave a comment on the issue so that the team can give you any guidance required, especially around UI heavy features.

Developer Tips

See the development section of the README.md in the root of the repository. And please read the README.md of any app or package you are interested in contributing to.

Tests

Please write tests! Each app and package has a README.md file that explains how to write and run tests for that app or package.

You can run all tests at once with the following command:

pnpm test

GitHub Actions

You can mock all the GitHub actions by running the following command:

pnpm gh

This will run the linting, type checking, unit tests, and build scripts for all apps and packages.

Committing your changes

Before a commit is accepted the staged changes will be formatted using prettier and linted using eslint.

Commit Message Convention

This project follows Conventional Commits

Commit messages will be checked using husky and commitlint.

Pull requests

So you want to make a pull request? Please observe the following guidelines.

  • First, make sure that your pnpm test and pnpm build run passes - it's very similar to what our Continuous Integration servers do to test the app.
  • Be sure to add and run tests!
  • Rebase your changes on the latest dev branch, resolving any conflicts. This ensures that your changes will merge cleanly when you open your PR.
  • Make sure the diff between dev and your branch contains only the minimal set of changes needed to implement your feature or bugfix. This will make it easier for the person reviewing your code to approve the changes. Please do not submit a PR with commented out code or unfinished features.
  • Avoid meaningless or too-granular commits. If your branch contains commits like the lines of "Oops, reverted this change" or "Just experimenting, will delete this later", please squash or rebase those changes away.
  • Don't have too few commits. If you have a complicated or long-lived feature branch, it may make sense to break the changes up into logical atomic chunks to aid in the review process.
  • Provide a well written and nicely formatted commit message. See this blog post for some tips on formatting. As far as content, try to include in your summary
    1. What you changed
    2. Why this change was made (including git issue # if appropriate)
    3. Any relevant technical details or motivations for your implementation choices that may be helpful to someone reviewing or auditing the commit history in the future. When in doubt, err on the side of a longer commit message. Above all, spend some time with the repository. Follow the pull request template added to your pull request description automatically. Take a look at recent approved pull requests, see how they did things.