Initial commit
This commit is contained in:
@@ -0,0 +1,64 @@
|
||||
# Contributing
|
||||
|
||||
[](http://commitizen.github.io/cz-cli/)
|
||||
[](http://semver.org/spec/v2.0.0.html)
|
||||
[](https://matrix.to/#/#CleverThis:qoto.org)
|
||||
|
||||
When contributing to this repository, it is usually a good idea to first discuss the change you
|
||||
wish to make via issue, email, or any other method with the owners of this repository before
|
||||
making a change. This could potentially save a lot of wasted hours.
|
||||
|
||||
Please note we have a code of conduct, please follow it in all your interactions with the project.
|
||||
|
||||
## Development
|
||||
|
||||
### Commit Message Format
|
||||
|
||||
All commits on this repository must follow the
|
||||
[Conventional Changelog standard](https://github.com/conventional-changelog/conventional-changelog-eslint/blob/master/convention.md).
|
||||
It is a very simple format so you can still write commit messages by hand. However it is
|
||||
highly recommended developers install [Commitizen](https://commitizen.github.io/cz-cli/),
|
||||
it extends the git command and will make writing commit messages a breeze. All CleverThis
|
||||
repositories are configured with local Commitizen configuration scripts.
|
||||
|
||||
Getting Commitizen installed is usually trivial, just install it via npm. You will also
|
||||
need to install the cz-customizable adapter which CleverThis repositories are configured
|
||||
to use.
|
||||
|
||||
```bash
|
||||
|
||||
npm install -g commitizen@2.8.6 cz-customizable@4.0.0
|
||||
```
|
||||
|
||||
Below is an example of Commitizen in action. It replaces your usual `git commit` command
|
||||
with `git cz` instead. The new command takes all the same arguments however it leads you
|
||||
through an interactive process to generate the commit message.
|
||||
|
||||

|
||||
|
||||
Commit messages are used to automatically generate our changelogs, and to ensure
|
||||
commits are searchable in a useful way. So please use the Commitizen tool and adhere to
|
||||
the commit message standard or else we cannot accept Pull Requests without editing
|
||||
them first.
|
||||
|
||||
Below is an example of a properly formated commit message.
|
||||
|
||||
```
|
||||
chore(Commitizen): Made repository Commitizen friendly.
|
||||
|
||||
Added standard Commitizen configuration files to the repo along with all the custom rules.
|
||||
|
||||
ISSUES CLOSED: #31
|
||||
```
|
||||
|
||||
### Pull Request Process
|
||||
|
||||
1. Ensure that install or build dependencies do not appear in any commits in your code branch.
|
||||
2. Ensure all commit messages follow the [Conventional Changelog](https://github.com/conventional-changelog/conventional-changelog-eslint/blob/master/convention.md)
|
||||
standard explained earlier.
|
||||
3. Update the CONTRIBUTORS.md file to add your name to it if it isn't already there (one entry
|
||||
per person).
|
||||
4. Adjust the project version to the new version that this Pull Request would represent. The
|
||||
versioning scheme we use is [Semantic Versioning](http://semver.org/).
|
||||
5. Your pull request will either be approved or feedback will be given on what needs to be
|
||||
fixed to get approval. We usually review and comment on Pull Requests within 48 hours.
|
||||
Reference in New Issue
Block a user