Contributing to Thicket
If you are interested in contributing a new data reader, a feature, or a bugfix to Thicket, please read below. This guide discusses the contributing workflow used in the Thicket project, and the granularity of pull requests (PRs).
The develop branch in Thicket that has the latest contributions is named
All pull requests should start from
develop and target
There is a branch for each minor release series. Release branches originate from
develop and have tags for each revision release in the series.
Thicket uses GitHub Actions for Continuous Integration testing. This means that every time you submit a pull request, a series of tests are run to make sure you did not accidentally introduce any bugs into Thicket. Your PR will not be accepted until it passes all of these tests.
Currently, we perform 2 types of tests:
Unit tests ensure that Thicket’s core API is working as expected. If you add a new data reader or new functionality to the Thicket API, you should add unit tests that provide adequate coverage for your code. You should also check that your changes pass all unit tests. You can do this by typing:
Thicket is in active development, so the
develop branch in Thicket has frequent
merges of new pull requests. The recommended way to contribute a pull request is to fork
the Thicket repo in your own space (if you already have a fork, make sure is it
up-to-date), and then create a new branch off of
We prefer that commits pertaining to different components of Thicket (core Thicket API,
visualization tools, etc.) prefix the component name in the commit message (for example
<component>: descriptive message.
GitHub provides a detailed tutorial on creating pull requests.