First, thanks for your interest in contributing to this project! This document should help us expedite the process of reviewing issues and pull requests. For a quick look at all the issues that are up for grabs, take a look at the current unclaimed issues. If you claim an issue, use the Assignees setting to let us know that you’ve got it!


The scope of this project is to simplify and expedite analysis stemming from SERPENT outputs. In the future we may expand this project to expand to interacting heavily with input files, but that is currently beyond the scope of this project. Any and all issues, features and pull requests will be examined through this scope.


The goal for this project is to become the de facto method for processing SERPENT outputs and, if you’re looking at this, there is some way we can improve. The GitHub issue tracker is the preferred way to post bug reports and feature requests.

Bug Reports

The more information given, the quicker we can reproduce and hopefully resolve the issue. Please see issue-template for a template that should be used for reporting bugs. One of the developers will add a bug label and start moving to resolve the issue posthaste.

Feature Requests

We are very interested in adding functionality from the SERPENT community! Requests can be done through the issue tracker as well. You can create an issue on the issue tracker with [Feature] or [Request] in the title. Describe what you would like to add, some expected results, and the purpose behind the feature. The development team will apply an enhancement label and proceed accordingly.

Pull Requests

Pull requests are how we review, approve, and incorporate changes into the master branch. If you have code you want to contribute, please look at the content in the Developer’s Guide for things like Pull Request Checklist, Coding Style, and more.

When your content is ready for the pull request, follow the pull-request-template and make a request! Someone of the core development team will review the changes according to the criteria above and make changes and/or approve for merging!

The develop branch is the primary branch for this project. All pull requests, except for bugs on public releases, should be compared against this branch. When a pull request is approved and has passed the required checks, it should be squashed and merged into the develop branch. Squashing a branch converts a series of commits into a single commit onto the main branch, creating a tidy git history.

For pull requests into master, as in releases, these should simply be merged without squashing. When viewing the git log on the master or develop branches, one is presented only with approved and closed pull requests, not incremental commits that led to a PR being closed.