Write a brief description of the project, explaining what it does in a couple of sentences.
Add a build status badge from Travis-CI
Describe the installation or setup process, using inline code blocks
to indicate terminal commands.
Add usage instructions, including configuration details, settings or arguments available.
Add license. Where possible, specify that the code is released under the MIT License. Then edit MIT-LICENSE.md
included in this repository to include the date and include it in your repository as LICENSE.md
.
Add information about how to contribute to the project, such as by filing an issue or submitting a pull request.
If relevant, include standards for contributing code. This may include:
- style guidelines
- pre-commit configuration
- documentation
- tests
This project uses the Python PEP8 community style guidelines. To conform to these guidelines, the following linters are part of the pre-commit:
- autopep8 formats the code automatically
- flake8 checks for style problems as well as errors and complexity
- isort sorts imports alphabetically, and automatically separated into sections and by type
After locally installing pre-commit, install the git-hook scripts in the project's directory:
pre-commit install
Docstrings should explain what a module, class, or function does by explaining its syntax and the semantics of its components. They focus on specific elements of the code, and less on how the code works. The point of docstrings is to provide information about the code you have written; what it does, any exceptions it raises, what it returns, relevant details about the parameters, and any assumptions which might not be obvious. Docstrings should describe a small segment of code and not the way the code is implemented in a larger environment.
This project adheres to Google’s docstring style guide. There are two types of docstrings: one-liners and multi-line docstrings. A one-line docstring may be perfectly appropriate for obvious cases where the code is immediately self-explanatory. Use multiline docstrings for all other cases.
New code should have unit tests. Tests are written in unittest style and run using tox.
New code should have unit tests. Tests are written in unittest style and use the Django-provided TestCase. Tests are run using manage.py
.