Set project contribution guidelines
During the last months, we didn’t thought about what were our main guidelines regarding how to contribute to this project (or, at least, they were not written somewhere).
Contributions guidelines are important as they allow other people (ie, people coming from outside the project core developers community) to get up with the project more quickly.
In this manner, we should definitely think about what are the different rules that have applied on this project development during the past months, review them, and then make sure that they are written somewhere (for example, in the
CONTRIBUTING.md file of this very project) for future use.
This issue is meant for the core developers to agree on what rules should be retained in these guidelines.
This project is using a MIT license (see https://opensource.org/licenses/MIT) registered in the name of the Association ATILLA. Therefore, every code addition made on this project repository should agree with this license and, by doing so, the original code author agrees that he can’t be held liable for the work he has done on the platform (for more resources, see https://tldrlegal.com/license/mit-license).
Every code added, modified or deleted on the platform should be linked to a GitLab issue such as this one.
The project is composed of 3 main branches :
masteris updated every time a new version or a hotfix is released, every new commit on
mastergets a tag assigned to specify the platform version.
preprodis (sometimes) used to test the platform versions before released.
devcontains the last version of the platform currently in development. Theoretically, every new code added, modified or deleted on the platform should come from a merge request made on
devis merged onto
As we need to keep our code base as clean as possible, currently, no direct commit are allowed on
The naming of development branches isn’t really restricted, we can encourage the use of prefixes in branch names such as
fix/ in order to make them more distinguishable.
We don’t have commit name guidelines either, it would be nice to encourage mentioning the issue ID of every commit for easier code tracking.
Code usually goes through
pep8 (see https://www.python.org/dev/peps/pep-0008/) validation. Apart from that, no particular guidelines are made for code quality.
Currently, we don’t have any guideline regarding code documentation, if we want the project to evolve cleanly, we might have to fix that.
The discussion is now open. If you feel that some of the guidelines provided in this issue does not match what has been done until now, feel free to raise your concern. My guess is that we can stop our discussion about defining those guidelines and apply them when this issue will reach 3 days of inactivity.