Skip to content
Snippets Groups Projects
CONTRIBUTING.md 3.22 KiB
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).
Alice Poggioli's avatar
Alice Poggioli committed
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)
Alice Poggioli's avatar
Alice Poggioli committed


## 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.
Alice Poggioli's avatar
Alice Poggioli committed

## 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. 

We name our branches like this : 
Alice Poggioli's avatar
Alice Poggioli committed

 * feature/#140
 * bug/#141

Where #140 and #141 is the number that refers to your issue or the issue you're solving
Alice Poggioli's avatar
Alice Poggioli committed

### 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 !**