Skip to content

Latest commit

 

History

History
123 lines (85 loc) · 4.56 KB

CONTRIBUTING.rst

File metadata and controls

123 lines (85 loc) · 4.56 KB
Raw

Contributing guidelines

Pull Request Checklist

Before sending your pull requests, make sure you followed this list.

How to become a contributor and submit your own code

Contributor License Agreements

In order to become a contributor of Giotto, the first step is to sign the contributor license agreement (CLA). NOTE: Only original source code from you and other people that have signed the CLA can be accepted into the main repository.

Contributing code

If you have improvements to Giotto, do not hesitate to send us pull requests! Please follow the Github how to (https://help.github.com/articles/using-pull-requests/). The Giotto Team will review your pull requests. Once the pull requests are approved and pass continuous integration checks, the Giotto team will work on getting your pull request submitted to our GitHub repository. Eventually, your pull request will be merged automatically on GitHub. If you want to contribute, start working through the Giotto codebase, navigate to the GitHub issue tab and start looking through interesting issues. These are issues that we believe are particularly well suited for outside contributions, often because we probably won't get to them right now. If you decide to start on an issue, leave a comment so that other people know that you're working on it. If you want to help out, but not alone, use the issue comment thread to coordinate.

Contribution guidelines and standards

Before sending your pull request for review, make sure your changes are consistent with the guidelines and follow the coding style below.

General guidelines and philosophy for contribution

  • Include unit tests when you contribute new features, as they help to a) prove that your code works correctly, and
    1. guard against future breaking changes to lower the maintenance cost.
  • Bug fixes also generally require unit tests, because the presence of bugs usually indicates insufficient test coverage.
  • Keep API compatibility in mind when you change code in core Giotto.
  • Clearly define your exceptions using the utils functions and test the exceptions.
  • When you contribute a new feature to Giotto, the maintenance burden is    (by default) transferred to the Giotto team. This means that the benefit    of the contribution must be compared against the cost of maintaining the    feature.

C++ coding style

Changes to Giotto C/C++ code should conform to Google C++ Style Guide. Use clang-tidy to check your C/C++ changes. To install clang-tidy on ubuntu:16.04, do:

apt-get install -y clang-tidy

You can check a C/C++ file by doing:

clang-format <my_cc_file> --style=google > /tmp/my_cc_file.ccdiff <my_cc_file> /tmp/my_cc_file.cc

Python coding style

Changes to Giotto Python code should conform to PEP8 directives. Use flake8 to check your Python changes. To install flake8 just do

pip install flake8

You can use flake8 on your python code via the following instructions:

flake8 name_of_your_script.py

Git pre-commit hook

We provide a pre-commit git hook to prevent accidental commits to the master branch. To activate, run

cd .git/hooks
ln -s ../../.tools/git-pre-commit pre-commit

Running unit tests

There are two ways to run Giotto unit tests.

  1. Using tools and libraries installed directly on your system. The election tool is pytest. To install pytest just do
pip install pytest

You can use pytest on your python code via the following instructions:

pytest name_of_your_script.py
  1. Using Azure (azure-pipelines.yml) and Giotto's CI scripts.