Contribution Statement

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.