Skip to content

Contributing

Thanks for taking the time to contribute!

From opening a bug report to creating a pull request: every contribution is appreciated and welcome. If you're planning to implement a new feature or change the API please create an issue first. This way we can ensure that your precious work is not in vain.

Setup with make

  • Clone the repo git clone https://github.com/deel-ai/oodeel.git.
  • Go to your freshly downloaded repo cd oodeel
  • Create a virtual environment and install the necessary dependencies for development:

make prepare-dev && source oodeel_dev_env/bin/activate.

Welcome to the team!

Tests

To run test make test This command activates your virtual environment and launch the tox command.

tox on the other hand will do the following: - run pytest on the tests folder with python 3.8, python 3.9 and python 3.10

Note: If you do not have those 4 interpreters the tests would be only performed with your current interpreter - run flake8 on the oodeel main files, with python 3.8, 3.9 and python 3.10. Note: It is possible that flake8 throws false-positive errors. If the linting test failed please check first flake8 output to point out the reasons.

Please, make sure you run all the tests at least once before opening a pull request.

We advise that you run docsig before each push. Docsig is an utilitary checking for the coherence between docstrings and functions' signatures. You can obtain a report by running:

docsig -c -D -o -P -p -i oodeel

This awesome repository is way underrated (14 stars only at the time of the present commit), so drop by and add a star to help them!

A word toward flake8 for those that don't know it:

Flake8 is a Python static code analysis tool which looks for programming errors, helps enforcing a coding standard, sniffs for code smells and offers simple refactoring suggestions.

Basically, it will check that your code follows a certain number of conventions. Any Pull Request will go through a Github workflow ensuring that your code respects the flake8 conventions (most of them at least).

Submitting Changes

After getting some feedback, push to your fork and submit a pull request. We may suggest some changes or improvements or alternatives, but for small changes, your pull request should be accepted quickly (see Governance policy).

Something that will increase the chance that your pull request is accepted:

  • Write tests and ensure that the existing ones pass.
  • If make test is successful, you have fair chance to pass the CI workflows (linting and test)
  • Follow the existing coding style and run make check_all to check all files format.
  • Write a good commit message (we follow a lowercase convention, see below).
  • For a major fix/feature make sure your PR has an issue and if it doesn't, please create one. This would help discussion with the community, and polishing ideas in case of a new feature.

pre-commit : Conventional Commits 1.0.0

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

The commit contains the following structural elements, to communicate intent to the consumers of your library:

  • fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).

  • feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).

  • BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.

  • types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.

  • footers other than BREAKING CHANGE: may be provided and follow a convention similar to git trailer format.

  • Additional types are not mandated by the Conventional Commits specification and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE). A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add the ability to parse arrays.