... | ... | @@ -35,18 +35,24 @@ This issue *should* be shared with all the other contributors so that every one |
|
|
|
|
|
If you see an issue which seems to you really easy and not urgent, you can let it to the new timers add a label "good first issue".
|
|
|
|
|
|
## Create your branch
|
|
|
[explanation Matthieu]
|
|
|
## Create your own branch
|
|
|
For each modification you add to a component, you must create a new branch. Each branch must be related to one issue only.
|
|
|
|
|
|
If you need to fix a bug, which will be added to the current version of the component, create your branch from `master`.
|
|
|
|
|
|
If you need to add a new feature, which will be released in the next version of the component, create your branch from `dev`.
|
|
|
|
|
|
Include the number of the issue your are working on in the branch name (ie: `12-fix-error`).
|
|
|
|
|
|
## Take care of your commit messages
|
|
|
|
|
|
Please prefix your commit message with the level of modification which can be :
|
|
|
|
|
|
* **feature** for modification that add a significant new behavior to the software
|
|
|
* **update** for any modification of the behavior of the software that requires a specification update
|
|
|
* **bugfix** for any modification making the software comply with the specification
|
|
|
* **ui** for any modification of the software that affect its appearance but not its behavior
|
|
|
* **syntax** for any modification that do not affect the user, like a refactoring
|
|
|
* **`feature`** for modification that add a significant new behavior to the software
|
|
|
* **`update`** for any modification of the behavior of the software that requires a specification update
|
|
|
* **`bugfix`** for any modification making the software comply with the specification
|
|
|
* **`ui`** for any modification of the software that affect its appearance but not its behavior
|
|
|
* **`syntax`** for any modification that do not affect the user, like a refactoring
|
|
|
|
|
|
Examples :
|
|
|
```
|
... | ... | @@ -55,6 +61,22 @@ update: configurable fields (fix #6) |
|
|
feature: representation of foreign keys as objects (fix #5)
|
|
|
feature: Federation model (fix #7)
|
|
|
```
|
|
|
These prefix are essential as they will trigger an automatic release for the component.
|
|
|
|
|
|
You can also add the id of the related issue, to link it automatically to the commit. (for the issue 12, add `#12` in your commit message).
|
|
|
|
|
|
## Propose your merge request
|
|
|
|
|
|
When your modifications are ready, create a merge request to `master` or `dev`, depending from which branch your created your own one.
|
|
|
|
|
|
The merge request should include:
|
|
|
|
|
|
- The id of the related issue (ie: `Fix error #12`)
|
|
|
- A simple example to test your modifications
|
|
|
- Every comment useful to understand your modifications
|
|
|
|
|
|
Assign it to someone which will review, test and approve the merge request.
|
|
|
|
|
|
## Documentation is everything
|
|
|
|
|
|
We all know how document our work is important. If you find that you can add an improvement, the community is grateful to you!
|
... | ... | @@ -70,7 +92,7 @@ Experimental features *can* be documented, but their documentation should mentio |
|
|
|
|
|
## Make beautiful release note
|
|
|
|
|
|
when releasing a new version of the software, add a tag on the repository. Name it with the version number of the release and add a release note. The release notes should have 3 sections: **New features**, **Other changes** and **bug fixes**. You should check the list of all commit messages since last release to make those release notes.
|
|
|
When releasing a new version of the software, add a tag on the repository. Name it with the version number of the release and add a release note. The release notes should have 3 sections: **New features**, **Other changes** and **bug fixes**. You should check the list of all commit messages since last release to make those release notes.
|
|
|
|
|
|
## We do experimental work
|
|
|
|
... | ... | |