|
|
# Startin'blox contributions guidelines
|
|
|
|
|
|
As it's a public place, we should be careful not to cause too much disorder. To this end, we have agreed on certain rules, although they could be improved collectively.
|
|
|
As it's a public place, we should be careful not to cause too much disorder. To this end, we have agreed on certain rules.
|
|
|
|
|
|
|
|
|
|
|
|
## Specification change
|
|
|
|
|
|
Before making any change to a software that requires a specification updcate, please open an issue explaining why there is a need to do so. If possible, provide an example use case. If you think of a solution, you can provide it with a code example.
|
|
|
|
|
|
This issue *should* be shared with all the other contributors so that every one can discuss it, until a decision is made. Then new issues should be created to describe the technical details of implementation.
|
|
|
|
|
|
## Commit messages
|
|
|
|
... | ... | @@ -20,23 +28,19 @@ feature: representation of foreign keys as objects (fix #5) |
|
|
feature: Federation model (fix #7)
|
|
|
```
|
|
|
|
|
|
## Release notes
|
|
|
## 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.
|
|
|
|
|
|
## Experimental features
|
|
|
## We do experimental work
|
|
|
|
|
|
All new features should be marked in the release notes as *experimental*, and marked as such until their specification is validated.
|
|
|
|
|
|
An experimental feature is not guaranteed to work fully as expected, nor is it guaranteed to be maintained in future releases. Its specification can be changed at any moment in any commit.
|
|
|
|
|
|
## Specification change
|
|
|
|
|
|
Before making any change to a software that requires a specification updcate, please open an issue explaining why there is a need to do so. If possible, provide an example use case. If you think of a solution, you can provide it with a code example.
|
|
|
|
|
|
This issue *should* be shared with all the other contributors so that every one can discuss it, until a decision is made. Then new issues should be created to describe the technical details of implementation.
|
|
|
|
|
|
## Documentation
|
|
|
## Take care of the documentation
|
|
|
|
|
|
Every non experimental features *should* be documented in the repository README.md.
|
|
|
|
... | ... | |