Developer’s Guide

Schematics development is currently led by Kalle Tuure, but this project is very much a sum of the work done by a community.

List of Contributors

$ cd schematics
$ git shortlog -sne

Schematics has a few design choices that are both explicit and implicit. We care about these decisions and have probably debated them on the mailing list. We ask that you honor those and make them known in this document.

Get the code

Please see the Installing from GitHub section of the Install Guide page for details on how to obtain the Schematics source code.

Commit Message Guidelines

We use a standard format for the commit messages that allows more readable browsing of the project history, and specially to help in generating the change log.

Commit Message Format

Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

<type>(<scope>): <subject>

The header is mandatory and the scope of the header is optional.

Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.

The footer should contain a closing reference to an issue if any.

Allowed type values:

  • build: Changes that affect the build system or external dependencies
  • ci: Changes to CI configuration files and scripts
  • docs: Documentation only changes
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature (eg. renaming a variable)
  • style: Changes that do not affect the meaning of the code (formatting, missing semi colons, etc)
  • test: Adding missing tests or correcting existing tests

Example scope values:

The scope should be the name of the module affected.

  • types
  • models
  • serializable
  • schema
  • transforms
  • etc.


The subject contains a succinct description of the change:

  • use the imperative, present tense: “change” not “changed” nor “changes”
  • don’t capitalize the first letter
  • no dot (.) at the end


Just as in the subject, use the imperative, present tense: “change” not “changed” nor “changes”. The body should include the motivation for the change and contrast this with previous behavior.


Using pytest:

$ py.test


Schematics has the tradition of naming examples after music bands and artists so you can use your favorite ones when creating examples in the docs and for test fixtures.

If you are not feeling particularly creative, you can use one of @jmsdnns selections below:

  • Mutoid Man
  • Pulled Apart By Horses
  • Fiona Apple
  • Julia Holter
  • Lifetime
  • Nujabes
  • Radiohead
  • Stars Of The Lid

Writing Documentation

Documentation is essential to helping other people understand, learn, and use Schematics. We would appreciate any help you can offer in contributing documentation to our project.

Schematics uses the .rst (reStructuredText) format for all of our documentation. You can read more about .rst on the reStructuredText Primer page.

Installing Documentation

Just as you verify your code changes in your local environment before committing, you should also verify that your documentation builds and displays properly on your local environment.

First, install Sphinx:

$ pip install sphinx

Next, run the Docs builder:

$ cd docs
$ make html

The docs will be placed in the ./_build folder and you can view them from any standard web browser. (Note: the ./_build folder is included in the .gitignore file to prevent the compiled docs from being included with your commits).

Each time you make changes and want to see them, re-run the Docs builder and refresh the page.

Once the documentation is up to your standards, go ahead and commit it. As with code changes, please be descriptive in your documentation commit messages as it will help others understand the purpose of your adjustment.