mirror of
https://github.com/ueberdosis/tiptap.git
synced 2024-12-18 13:17:49 +08:00
cdc147a7f0
* chore: add commitizen cli added cz-conventional-changelog to make commiting easier with the new linter * docs: add commiting information to CONTRIBUTING.md Added information on how to commit to the codebase via conventional commits
55 lines
2.7 KiB
Markdown
55 lines
2.7 KiB
Markdown
# Contributing
|
|
|
|
Contributions are **welcome** and will be fully **credited**.
|
|
|
|
Please read and understand the [contribution guide](https://www.tiptap.dev/overview/contributing/) before creating an issue or pull request.
|
|
|
|
## Etiquette
|
|
|
|
This project is open source, and as such, the maintainers give their free time to build and maintain the source code
|
|
held within. They make the code freely available in the hope that it will be of use to other developers. It would be
|
|
extremely unfair for them to suffer abuse or anger for their hard work.
|
|
|
|
Please be considerate towards maintainers when raising issues or presenting pull requests. Let's show the
|
|
world that developers are civilized and selfless people.
|
|
|
|
It's the duty of the maintainer to ensure that all submissions to the project are of sufficient
|
|
quality to benefit the project. Many developers have different skillsets, strengths, and weaknesses. Respect the maintainer's decision, and do not be upset or abusive if your submission is not used.
|
|
|
|
## Viability
|
|
|
|
When requesting or submitting new features, first consider whether it might be useful to others. Open
|
|
source projects are used by many developers, who may have entirely different needs to your own. Think about
|
|
whether or not your feature is likely to be used by other users of the project.
|
|
|
|
## Procedure
|
|
|
|
Before filing an issue:
|
|
|
|
- Attempt to replicate the problem, to ensure that it wasn't a coincidental incident.
|
|
- Check to make sure your feature suggestion isn't already present within the project.
|
|
- Check the pull requests tab to ensure that the bug doesn't have a fix in progress.
|
|
- Check the pull requests tab to ensure that the feature isn't already in progress.
|
|
|
|
Before submitting a pull request:
|
|
|
|
- Check the codebase to ensure that your feature doesn't already exist.
|
|
- Check the pull requests to ensure that another person hasn't already submitted the feature or fix.
|
|
|
|
Before commiting:
|
|
|
|
- Make sure to run the tests and linter before committing your changes.
|
|
- Write [conventional commit messages](https://www.conventionalcommits.org/en). You can use `npm run cz` for that.
|
|
|
|
## Requirements
|
|
|
|
If the project maintainer has any additional requirements, you will find them listed here.
|
|
|
|
- **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date.
|
|
|
|
- **One pull request per feature** - If you want to do more than one thing, send multiple pull requests.
|
|
|
|
- **Send coherent history** - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](https://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting.
|
|
|
|
**Happy coding**!
|