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
--project=. -e 'import Pkg; Pkg.test(; test_args=ARGS)' -- optim hmc --skip ext julia
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 overInt64( 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!