Skip to content

Commit 54468dc

Browse files
authored
Create CONTRIBUTING.md - WIP
1 parent 0195f72 commit 54468dc

File tree

1 file changed

+65
-0
lines changed

1 file changed

+65
-0
lines changed

CONTRIBUTING.md

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
# Contributing to `gren` 🍺🤖👍
2+
3+
❤️ Thanks for contributing to this project.
4+
Following, you can find a couple of things to keep in mind before contributing to gren.
5+
6+
7+
1. [Issues](#issues)
8+
2. [Commits](#commits)
9+
3. [Branches](#branches)
10+
4. [Pull Requests](#pull-requests)
11+
12+
## Issues
13+
14+
Every piece of work has to be related to an issue.
15+
The issue will have a capitalised title, which follows the same rules of [commits messages](#commits).
16+
17+
Every issue should contain one label that reflects the issue category.
18+
If the issue is going to be close with no development, use one of these labels:
19+
20+
- `wontfix`
21+
- `can't replicate`
22+
- `gren ignore`
23+
- `invalid`
24+
- `duplicate`
25+
26+
When a task is completed, create a [Pull Request](#pull-requests) which closes the issue.
27+
28+
## Commits
29+
30+
1. Start the subject line with a verb (e.g. **Change** header styles)
31+
2. Use the imperative mood in the subject line (e.g. **Fix**, not _Fixed_ or _Fixes_ header styles)
32+
3. Limit the subject line to about 50 characters
33+
4. Do not end the subject line with a period
34+
5. Separate subject from body with a blank line
35+
6. Wrap the body at 72 characters
36+
7. Use the body to explain what and why vs. how
37+
38+
## Branches
39+
40+
For every piece of development, create a branch. The naming convention for the branch is `lowercases-with-dashes`.
41+
Branch off `master` rebase on top of `master` and create a PR back to `master`.
42+
43+
The branch will be deleted straight after the pull request.
44+
45+
## Pull Requests
46+
47+
A PR has to close at least one issue and preferably only one. The less amount of work is in one PR, the easier is to review it.
48+
49+
The body of the PR should start with a [message that closes the related issues](https://help.github.com/articles/closing-issues-via-commit-messages/) and the actual description in a new lines.
50+
51+
The commit history in a PR should not contain `Merge` commits and should be rebased on top of `master`.
52+
53+
It's easier to review the PR, if you rebase your commits so that every commit represents a sub-piece of the development and can be independently reviewed or a clear list of the features on that branch.
54+
55+
e.g.
56+
```
57+
Closes #123
58+
59+
Here any further informations needed to the reviewer, e.g. run yarn before reviewing.
60+
```
61+
62+
### Checks
63+
64+
Every PR has to be reviewed before can be merged in.
65+

0 commit comments

Comments
 (0)