|
| 1 | +# How to contribute |
| 2 | + |
| 3 | +I'm really glad you're reading this, because we need volunteer developers to help this project evolve. |
| 4 | + |
| 5 | +If you haven't already, come find us on [Discord](http://discord.mlapi.network). |
| 6 | + |
| 7 | +## Submitting changes |
| 8 | + |
| 9 | +Please send a [GitHub Pull Request to MLAPI](https://github.com/midlevel/MLAPI/pull/new/master) with a clear list of what you've done (read more about [pull requests](http://help.github.com/pull-requests/)). |
| 10 | +Please follow our commit message conventions (below) and make sure all of your commits are atomic (one feature per commit). |
| 11 | + |
| 12 | +## Commit Message Guidelines |
| 13 | + |
| 14 | +We have very precise rules over how our git commit messages can be formatted. This leads to **more |
| 15 | +readable messages** that are easy to follow when looking through the **project history**. But also, |
| 16 | +we use the git commit messages to **generate the MLAPI change log**. We follow angular's message format. |
| 17 | + |
| 18 | +### Commit Message Format |
| 19 | +Each commit message consists of a **header**, a **body** and a **footer**. The header has a special |
| 20 | +format that includes a **type**, a **scope** and a **subject**: |
| 21 | + |
| 22 | +``` |
| 23 | +<type>(<scope>): <subject> |
| 24 | +<BLANK LINE> |
| 25 | +<body> |
| 26 | +<BLANK LINE> |
| 27 | +<footer> |
| 28 | +``` |
| 29 | + |
| 30 | +The **header** is mandatory and the **scope** of the header is optional. |
| 31 | + |
| 32 | +Any line of the commit message cannot be longer 100 characters! This allows the message to be easier |
| 33 | +to read on GitHub as well as in various git tools. |
| 34 | + |
| 35 | +The footer should contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any. |
| 36 | + |
| 37 | +Samples: |
| 38 | + |
| 39 | +``` |
| 40 | +docs(changelog): update changelog to beta.5 |
| 41 | +``` |
| 42 | +``` |
| 43 | +fix(release): need to depend on latest rxjs and zone.js |
| 44 | +
|
| 45 | +The version in our package.json gets copied to the one we publish, and users need the latest of these. |
| 46 | +``` |
| 47 | + |
| 48 | +### Revert |
| 49 | +If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted. |
| 50 | + |
| 51 | +### Type |
| 52 | +Must be one of the following: |
| 53 | + |
| 54 | +* **build**: Changes that affect the build system or external dependencies (example scopes: msbuild, xUnit) |
| 55 | +* **ci**: Changes to our CI configuration files and scripts (example scopes: AppVeyor, xUnit) |
| 56 | +* **docs**: Documentation only changes |
| 57 | +* **feat**: A new feature |
| 58 | +* **fix**: A bug fix |
| 59 | +* **perf**: A code change that improves performance |
| 60 | +* **refactor**: A code change that neither fixes a bug nor adds a feature |
| 61 | +* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) |
| 62 | +* **test**: Adding missing tests or correcting existing tests |
| 63 | + |
| 64 | +Always write a clear log message for your commits. One-line messages are fine for small changes, but bigger changes should look like this: |
| 65 | + |
| 66 | + $ git commit -m "A brief summary of the commit |
| 67 | + > |
| 68 | + > A paragraph describing what changed and its impact." |
| 69 | + |
| 70 | +Thanks, |
| 71 | +Albin Coŕen |
0 commit comments