Thanks for your interest in contributing to the project! We don't have a specific contribution process for this project yet, but here are some general guidelines.
Check the README first to see if this project accepts contributions. Most of my projects do, but some projects are not maintained or are for personal use only. If you're not sure, create a dicussion to ask.
Not a coder? See the support resources for information on how to:
- request features
- report bugs
- ask questions
- report security vulnerabilities
Issues with the 🚦 ready label are ready to be worked on. If you comment on an issue, I can assign it to you.
Issues with the 🚦 needs triage label generally need some more information before they can be worked on, but if you
start a discussion about it or leave a comment on the issue, I can likely get it ready for you.
If an issue is unclear or you have any questions about how a feature should be implemented, reach out before making any changes so we can discuss the best way to do it.
There are usually installation and usage instructions in the README, so check there first for what you need to get started. If the README doesn't have this information, you might need to take a peek at the source code.
Here's a quick example of how to contribute a new feature or bug fix:
-
Fork and clone the repository:
git clone https://github.com/OWNER/REPO.git cd REPO -
Create a new branch:
git checkout -b feat/your-feature-name
You can also do this from the relevant GitHub issue.
See the Branch Names section below for how to name branches.
-
Make your changes
-
Write or update tests as needed
-
Write or update docs as needed
-
Run any other commands you can find for verifying code quality (ex. linting, formatting, typechecking, etc.)
You can often find these commands in the README or in the project's
package.json. -
Commit your changes:
git add . git commit -m "feat: add your feature description"
See the Commit Messages section below how to write commit messages.
-
Push and create a pull request:
git push origin feat/your-feature-name
-
Request a review from a maintainer and wait for feedback
See below for more details.
See the existing source for examples of how to write code that fits with the project's style.
My projects are generally auto-formatted with tabs and single quotes. Check the README or package.json for details on the exact tool used.
Make sure code is formatted correctly before creating a pull request.
Documentation should be kept up-to-date with code changes.
The README usually contains everything you need to know to use the project. Contributing information and other documentation can usually be found in the docs/ directory.
Some larger projects have a dedicated documentation site.
If the project has tests, make sure they pass before creating a pull request.
Check the README or package.json for details on how tests are set up.
We follow Conventional Commits:
feat:- New featuresfix:- Bug fixesdocs:- Documentation changesrefactor:- Code refactoringtest:- Test additions or modificationschore:- Maintenance tasks
If you are making a breaking change, add an exclamation mark after the type and a BREAKING CHANGE: footer further
explaining the breaking changes for users. For example:
feat!: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config filesThis text is included in release notes, so it should be clear and concise.
We prefix branch names with types from Conventional Commits. For example:
feat/some-feature
fix/some-bug
docs/update-readmeBy contributing to this project, you agree that your contributions will be licensed under the project license.