Contributing to Pymaging


People interested in developing for the Pymaging should join the #pymaging IRC channel on freenode for help and to discuss the development.

Contributing Code


  • Code must be tested. Untested patches will be declined.
  • If a patch affects the public facing API, it must document these changes.
  • If a patch changes code, the internal documentation (docs/dev/) must be updated to reflect the changes.

Since we’re hosted on GitHub, pymaging uses git as a version control system.

If you’re not familiar with git, check out the GitHub help page.

Syntax and conventions

We try to conform to PEP8 as much as possible. This means 4 space indentation.


This is how you fix a bug or add a feature:

  1. fork us on GitHub.
  2. Checkout your fork.
  3. Hack hack hack, test test test, commit commit commit, test again.
  4. Push to your fork.
  5. Open a pull request.


If you’re unsure how to write tests, feel free to ask for help on IRC.

Running the tests

To run the tests we recommend using nose. If you have nose installed, just run nosetests in the root directory. If you don’t, you can also use python -m unittest discover.

Contributing Documentation

The documentation is written using Sphinx/restructuredText.

Section style

We use Python documentation conventions fo section marking:

  • # with overline, for parts
  • * with overline, for chapters
  • =, for sections
  • -, for subsections
  • ^, for subsubsections
  • ", for paragraphs