Contributing Rules

Contributing Rules

This document specifies the official list of contribution rules that every contributor to the repository is expected to maintain. These are have to, not is encouraged to instructions.

Code Content Requirements

Every new piece of code from contributors should come with:

1. Unit tests. We want to ensure the validity of your code and deploying unit tests is one of the most common approaches. If you are new to unit testing please don't be discouraged (this is an excellent occasion to add substantially to your tool chest) but rather have a look at:
   • Python 201. Part IV is wholly dedicated to testing, Chapter 24 to the unittest module.
   • Writing unit tests in Python: How do I start? from Stack Overflow. (Notice: it may contain references to outdated material that we do not encourage to follow.)
   • If you are already new to the paradigm of test-first (or just after) programming but not familiar with Python's ecosystem, simply head to Development Tools - unittest of the official documentation.
2. Proper docstring documentation. Any public (and, if need to, private) class, function, method or attribute should be properly documented according to the docstring conventions. Minor oversights in undocumented parameters or lesser code snippets will be tolerated, but adjusted prior to merging a pull request.
3. Support for Python 2. Although its EOL has been set for 2020, there still exist some legacy code and OSes that aren't completely up-to-date with the latest major Python release. Supporting Python 2 isn't particularly hard, it will need a little more patience.

Code Style Requirements

Along with functional requirements, any code that is read and maintained by humans should respect:

1. PEP 8 -- Style Guide for Python Code. In particular:
   • The nomenclature of private and public functions, methods, local (but not constant) variables and function parameters should come in the lower camelCase style, in coherence with the older version of the code and paragraph Function and Variable Names of PEP 8.
   • Do not surpass the limit of 79 characters per line. This rule applies to non-code (e.g. .md, .txt) files too. Set up your IDE or editor to display a threshold line.
   • Two newlines between global-scoped classes and functions.
2. Mark private attributes and methods of classes with a leading _, e.g. obj._selfpath or obj._reset().
3. If a feature of your code (or ours) isn't yet implemented, please place a # TO-DO <explanation> comment near its possible future location in the source code.
4. Other small but conventional rules apply too: right spacing between operators and operands, parentheses, etc.

Expanding the Contribution Guidelines

Keep it succinct. Developers might not have the time to fully peruse digital scrolls and the time required to read them might affect how much of the contribution guidelines is followed.