Contributing

Turing is an open-source project. If you feel that you have relevant skills and are interested in contributing, please get in touch. You can contribute by opening issues on GitHub, implementing things yourself, and making a pull request. We would also appreciate example models written using Turing.

Turing has a style guide. Reviewing it before making a pull request is not strictly necessary, but you may be asked to change portions of your code to conform with the style guide before it is merged.

What Can I Do?

Look at the issues page for an outstanding issue. For instance, you could implement new features, fix bugs or write example models.

Git Workflow

For more information on how the Git workflow typically functions, please see the GitHub’s introduction or Julia’s contribution guide.

Tests

Turing, like most software libraries, has a test suite. You can run the whole suite the usual Julia way with

Pkg.test("Turing")

The test suite subdivides into files in the test folder, and you can run only some of them using commands like

Pkg.test("Turing"; test_args=["optim", "hmc", "--skip", "ext"])

This one would run all files with “optim” or “hmc” in their path, such as test/optimisation/Optimisation.jl, but not files with “ext” in their path. Alternatively, you can set these arguments as command line arguments when you run Julia

julia --project=. -e 'import Pkg; Pkg.test(; test_args=ARGS)' -- optim hmc --skip ext

Or otherwise, set the global ARGS variable, and call include("test/runtests.jl").

Style Guide

Most Turing code follows the Blue: a Style Guide for Julia. These conventions were created from a variety of sources including Python’s PEP8, Julia’s Notes for Contributors, and Julia’s Style Guide.

Synopsis

  • Use 4 spaces per indentation level, no tabs.
  • Try to adhere to a 92 character line length limit.
  • Use upper camel case convention for modules and types.
  • Use lower case with underscores for method names (note: Julia code likes to use lower case without underscores).
  • Comments are good, try to explain the intentions of the code.
  • Use whitespace to make the code more readable.
  • No whitespace at the end of a line (trailing whitespace).
  • Avoid padding brackets with spaces. ex. Int64(value) preferred over Int64( value ).

A Word on Consistency

When adhering to the Blue style, it’s important to realize that these are guidelines, not rules. This is stated best in the PEP8:

A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.

But most importantly: know when to be inconsistent – sometimes the style guide just doesn’t apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don’t hesitate to ask!

Back to top