Skip to content

Latest commit

 

History

History
59 lines (40 loc) · 3.1 KB

CONTRIBUTING.md

File metadata and controls

59 lines (40 loc) · 3.1 KB

Contributing Guide

Welcome to the Verto developer community! We have spent many months developing this project, and we would love for you to get involved!

We've written a technical guide about how Verto works and how to contribute here. These docs should give you a good overview of how Verto is pieced together.

Below are a few more general notes to remember while you are working on Verto.

Code of Conduct

This project adheres to the Contributor Covenant code of conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected]

Reporting issues

This section guides you through submitting an issue for Verto. Following these guidelines helps maintainers and the community understand your findings.

Before submitting an issue, please take a look at the issues on the repository to check it hasn't already been reported.

Your first code contribution

Unsure where to begin contributing to Verto? Take a look at the issues on the repository.

Pull requests

  • Include a detailed explaination of the proposed change
  • Read and applied the style guides listed below.
  • Your pull request should be on a new branch from our develop branch (unless it's something tiny like a typo). The naming conventions of branches should be descriptive of the new addition/modification. Ideally they would specify their namespace as well, for example:
    • processor/image
    • issue/234
  • Linked any relevant existing issues.
  • Run the test suite and all tests passed
  • Added necessary documentation (if appropriate).

Style guides

Git

  • Commits should be as descriptive as possible. Other developers (and even future you) will thank you for your forethought and verbosity for well documented commits. Ideally follow this commit structure, otherwise in short:
    • Limit the first line to 72 characters or less
    • Reference issues and pull requests liberally
  • Use Vincent Driessen's Git Branching Model for managing development. Please read this document to understand our branching methods.

Programming

Every line of code should appear to be written by a single person, no matter the number of contributors.

These are our abridged guidelines for working on code within this repository:

  • Code should be easily readable (avoid abbreviations etc)
  • Files should be set to utf-8, use lf line endings, and have a final newline at the end of a file.
  • Functions should have comments/docstrings explaining their purpose.
  • Indents should be spaces (not tab characters)
  • Indent sizes:
    • HTML: 2 spaces
    • Python: 4 spaces

We aim to follow the PEP8 style guide and use Flake8 to enforce this.