# How to contribute

## Code
### Linting
We use `flake8` python module to enforce a consistent style in the CI.

### Testing
Unit testing.  For Python we use the `pytest` module and alternate between `unittest` and `pytest` syntax. 
For `Matlab` we use the embedded test framework.

### Continuous Integration
For production repositories such as ibllib and alyx, continuous integration is set on Travis to install the application and run the tests on pull request.


## Contributions and releases
### Contributions and code review
The branches `develop` and `master` are protected.

Contributions are developed either:
-   on a separate branch
-   on a separate fork of the repository

and then merged in `develop` through a pull request.


#### Practical tips:
-   to avoid merge conflicts merge `develop` into your branch (or rebase your branch) before submitting the PR !
-   make sure your branch passes tests:
    -   before pushing by running unit tests and flake8 locally 
    -   after pushing looking at continuous integration results on Github 
-   go through the review process with maintainers on the pull request interface on GitHub. Remind them if not done in a timely manner. Github sends them a bazillion emails daily.


### Branching model: gitflow
Branching model as close as possible to gitflow, i.e. one master branch with every commit tagged with a version number: one develop branch to integrate the different volatile feature branches.
**Both develop and master should pass CI tests**

### Releasing scheme: semantic versioning
If any releasing scheme (such as ibllib), we use semantic versioning using the major.minor.micro or major.minor.patch model. patch/micro for bugfixes; minor for augmented functionality; major for retrocompatibility breaks.
Version 0.*.* are developing versions w/ no guarantee of retrocompatibility.

It is a good practice to document the changes in a `RELEASE_NOTES.md` document at the root of the repository.  
NB: those notes should be geared towards users not other fellow contributors.