Contributing

Turing is an open-source project and is hosted on GitHub. We welcome contributions from the community in all forms large or small: bug reports, feature implementations, code contributions, or improvements to documentation or infrastructure are all extremely valuable. We would also very much appreciate examples of models written using Turing.

How to get involved

Our outstanding issues are tabulated on our issue tracker. Closing one of these may involve implementing new features, fixing bugs, or writing example models.

You can also join the #turing channel on the Julia Slack and say hello!

If you are new to open-source software, please see GitHub’s introduction or Julia’s contribution guide on using version control for collaboration.

Documentation

Each of the packages in the Turing ecosystem (see Libraries) has its own documentation, which is typically found in the docs folder of the corresponding package. For example, the source code for DynamicPPL’s documentation can be found in its repository.

The documentation for Turing.jl itself consists of the tutorials that you see on this website, and is built from the separate docs repository. None of the documentation is generated from the main Turing.jl repository; in particular, the API that Turing exports does not currently form part of the documentation.

Other sections of the website (anything that isn’t a package, or a tutorial) – for example, the list of libraries – is built from the turinglang.github.io repository.

Tests

Turing, like most software libraries, has a test suite. You can run the whole suite by running julia --project=. from the root of the Turing repository, and then running

import Pkg; Pkg.test("Turing")

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

import Pkg; 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

Turing has a style guide, described below. 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.

Most Turing code follows 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