.. _contributing: ============ Contributing ============ 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! .. _project-scope: Scope ===== 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. .. _issues: Issues ====== 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 :ref:`dev-guide` for things like :ref:`pr-checklist`, :ref:`code-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.