Skip to content

Commit 2ab272f

Browse files
JoaoPedroAS51JoaoPedroAS51
committed
docs: add "contributing" page
1 parent 9f30a27 commit 2ab272f

File tree

1 file changed

+106
-0
lines changed

1 file changed

+106
-0
lines changed

‎docs/content/en/community/contributing.md‎

Lines changed: 106 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,106 @@
1+
---
2+
title: Contributing
3+
description: 'Contributing to this package.'
4+
position: 12
5+
category: Community
6+
---
7+
8+
## Commit Guidelines
9+
10+
We use [Angular Commit Message Conventions](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit).
11+
12+
### Commit Message Format
13+
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
14+
format that includes a **type**, a **scope** and a **subject**:
15+
16+
```
17+
<type>(<scope>): <subject>
18+
<BLANK LINE>
19+
<body>
20+
<BLANK LINE>
21+
<footer>
22+
```
23+
24+
The **header** is mandatory and the **scope** of the header is optional.
25+
26+
Any line of the commit message cannot be longer than 100 characters! This allows the message to be easier
27+
to read on GitHub as well as in various git tools.
28+
29+
### Revert
30+
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header
31+
of the reverted commit.
32+
In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit
33+
being reverted.
34+
35+
### Type
36+
Must be one of the following:
37+
38+
- **feat**: A new feature
39+
- **fix**: A bug fix
40+
- **docs**: Documentation only changes
41+
- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
42+
semi-colons, etc)
43+
- **refactor**: A code change that neither fixes a bug nor adds a feature
44+
- **perf**: A code change that improves performance
45+
- **test**: Adding missing or correcting existing tests
46+
- **ci**: Changes to continuous integration.
47+
- **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
48+
generation
49+
50+
### Scope
51+
The scope could be anything specifying place of the commit change. For example `model`,
52+
`builder`, `parser`, etc...
53+
54+
You can use `*` when the change affects more than a single scope.
55+
56+
### Subject
57+
The subject contains succinct description of the change:
58+
59+
* use the imperative, present tense: "change" not "changed" nor "changes"
60+
* don't capitalize first letter
61+
* no dot (.) at the end
62+
63+
### Body
64+
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
65+
The body should include the motivation for the change and contrast this with previous behavior.
66+
67+
### Footer
68+
The footer should contain any information about **Breaking Changes** and is also the place to
69+
[reference GitHub issues that this commit closes][closing-issues].
70+
71+
**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines.
72+
The rest of the commit message is then used for this.
73+
74+
## Branches
75+
76+
### `dev`
77+
78+
The `dev` branch is the default branch of the package. PR's should be based on it.
79+
80+
### `master`
81+
82+
The `master` branch is a protected branch and is only used for releases.
83+
84+
<alert type="danger">Do not commit directly to this branch. Use `dev` branch instead.</alert>
85+
86+
## Releasing a New Version
87+
88+
In order to release a new version, a new PR from `dev` branch must be opened and merged into the `master` branch.
89+
90+
**Github Action** will automatically make a release using
91+
[semantic-release](https://github.com/semantic-release/semantic-release).
92+
93+
94+
| Commit message | Release type |
95+
|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------|
96+
| `fix(pencil): stop graphite breaking when too much pressure applied` | Patch Release |
97+
| `feat(pencil): add 'graphiteWidth' option` | ~~Minor~~ Feature Release |
98+
| `perf(pencil): remove graphiteWidth option`<br><br>`BREAKING CHANGE: The graphiteWidth option has been removed.`<br>`The default graphite width of 10mm is always used for performance reasons.` | ~~Major~~ Breaking Release |
99+
100+
## Deploying Documentation
101+
102+
Documentation changes must be based on `dev` branch.
103+
104+
**Github Action** will automatically
105+
deploy the documentation when a new version is released.
106+

0 commit comments

Comments
 (0)