system_assignation/CONTRIBUTING.md

Contributing guidelines

Push Request Checklist

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

• Read contributing guidelines.
• Read Code of Conduct.
• Check if my changes are consistent with the guidelines.
• Changes are consistent with the Coding Style.
• Manually test your code and add Unit Tests.
• Document your work.

How to become a contributor and submit your own code

Contributor License Agreements

CERC Libs is an LGPL licensed software, so even if we'd love to accept your patches, Before we can take them, please be sure that you are the intellectual property owner of your code and that do you fully understand and respect our software license.

NOTE: Only source code that you own will go into the main repository.

Contributing code

If you have improvements to CERC Libs or want to extend the functionality, please send us your pull request as seen at git pull request documentation

Once the pull requests are approved and pass continuous integration checks, a team member will merge your changes on CERC Libs, and your code will become an integral part of Insel4D platform.

If you prefer to contribute, instead of adding new functionality, you can also take a look at our ticket system and try to fix any of the listed issues.

Contribution guidelines and standards

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

General guidelines and philosophy for contribution

• Include unit tests when you contribute new features, as they help to:

1. Prove that your code works correctly.
2. 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 backward compatibility in mind when you change code in CERC Libs, and if you need to broke the backward compatibility, please ensure that you:

1. Clearly indicate which features are affected by your changes.
2. Technical reasons for the changes.

• Tests should follow the testing best practices guide.
• Document your contribution

License

Include a small header with contact information and the code license at the top of any new file like in the following example.

"""
Name module
SPDX - License - Identifier: LGPL - 3.0 - or -later
Copyright © 2020 Project Author name mail@concordia.ca
"""

Coding style

Changes to CERC Libs python code should conform to our coding style Cerc Python Style Guide

As a general basis, all contributions need to be focused on the concept of code clarity and use pylint to check your Python changes. To install pylint and check your files against Cerc custom style definition:

To install pylint and check a file with pylint against Cerc custom style definition:

pip install pylint
pylint --rcfile=pylintrc myfile.py

Testing best practices

Before any pull request, the code must been manually and automatically tested to ensure at least some quality minimum. There are a few practices for unit tests that we believe are important, so we encourage you to follow it.

• The test should be self-contained, which implies that your tests will prepare and clean up everything before and after the test execution.
• We encourage you to create if possible functional tests that cover the complete workflow of the implemented functionality.
• Maximize your code coverage by ensuring that you are testing as much of your code as possible.

Documentation

In case of new functionality, a general overview, configuration, installation, and user manuals need to be provided by the developer; this will provide an excellent starting point for all the future users and help you detect any inconsistencies in your design.