Newer
Older
# Coopedia's contributions guidelines
These guidelines are an extension of the [Startin'blox guidelines](https://git.startinblox.com/framework/sib-core/blob/master/CONTRIBUTING.md).
See the [documentation of the framework](https://docs.startinblox.com/) and [contribute to the FAQ documentation](https://git.startinblox.com/documentation/doc) if you're not able to find the answer you're looking for.
If you have any question left, come to meet us on [community.startinblox.com](https://community.startinblox.com)
## Reporting a bug or propose a new feature
Feel welcome to open an issue. Before submitting one, have a look on the already opened ones to avoid duplication.
Templates are at your disposal for bug report or feature suggestion . They will help you describe your contribution properly. Be the more explicit you can in the title to help futures contributors.
## Improve the code
### Create your own branch
For each modification you want to propose, you must create a new branch.
Each branch must be related to one issue only.
Where #140 and #141 is the number that refers to your issue or the issue you're solving
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
### 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
Examples :
```
bugfix: set lookup field on @id
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.
### Good First Issue
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".
## Documentation is everything
We all know how much documenting our work is important. If you find that you can add an improvement, the community is grateful to you!
### Experimental features
Every non experimental features *should* be documented in the repository README.md.
Experimental features *can* be documented, but their documentation should mention clearly that the feature is experimental and is not guaranteed to continue to work in the future.
**Thank you very much for your contribution !**