1. Open an issue on github. To do so go to the repo with the code you want to request changes on and click on “Issues” in the top menu bar. Then click on the green “New Issue” button in the upper right corner.

   • Create an issue: Creating an issue - GitHub Docs

2. Select from one of our templates (CDPHE-bioinformatics github issue templates)- Bug template, Feature request template, or Requirement template - to format your issue; however these templates are flexible.

   • Bug template - use when you are addressing a bug in the code that must be fixed
   • Feature request template - use when you want to add additional features to the code or refactor the code to make it more streamlined
   • Requirement template - use when a change in workflow processes requires a change to the code to handle the workflow process (i.e. the new workflow process will break the code otherwise)

3. Labels are pre-assigned to each template, but you can add additional labels.

1. Weekly, the bioinformatics team will meet as a group and review all new issues. During this meeting, the bioinformatics team will rank the effort of the changes requested (minor change, medium change, major change) in the issue as well as the priority of the changes (urgent, high, medium, low) requested in the issue. The team will also decide if the change is ready or blocked/waiting.

   • Minor change - relatively easy change that does not require much effort; change can be made relatively quickly.
   • Medium change - medium change that requires some effort; change will take more than two weeks.
   • Major change - larger change that will influence upstream and downstream processes and will require a lot of effort; change will take more than 2 months.
   • Urgent - change must be made within 1 week to maintain turn around times
   • High - change must be made within 2-4 weeks
   • Medium - change can be made within 1-2 months
   • Low - change can be made within 3+ months
   • Ready - the issue can be addressed and is independent of other issues and code changes.
   • Blocked/Waiting - the issue is dependent on other issues/code changes being made prior to the issue being addressed or if the issue is a low priority issue, the issue can be in waiting until time becomes available to address the issue.

2. During this meeting, the bioinformatics team will also decide how issues should be grouped into GitHub milestones. A milestone is a way to group issues and pull requests together into a single “project”. It can allow you to better manage projects.

   • Create a milestone: Creating and editing milestones for issues and pull requests - GitHub Docs

3. The bioinformatics team will assign tasks to individual(s) that will work on the code development (assigned developers) as well as set target dates for review and final release.

1. The assigned developer will create a work in progress (wip) branch of the develop branch of the repo. This branch is where the developer will commit all changes during development. The developer should make frequent commits.
2. To create a new branch follow the github documentation: Creating and deleting branches within your repository - Github Docs
3. The developer will test all code changes using appropriate datasets to ensure they produce the expected results and do not unintentionally break other parts of the workflow. (See appendix section titled choosing appropriate datasets for testing.)
4. A summary of the testing will be recorded in the PR as well as a description of the dataset used for testing. TheiaValidate should be used when major changes that affect multiple sections of the workflow have been made to ensure that all expected results are generated.
5. TheiaValidate should be used in conjunction with other testing when major changes that affect multiple sections of the workflow have been made to ensure that all expected results are generated. (See appendix section titled TheiaValidate for further instructions regarding TheiaValidate).

This section is not required for all repos. Only repos with development branches (as determined necessary by the bioinformatics team) require this section. If no development branch exists, skip this section and move to the next section where you will create a pull request directory into the main branch.

1. Follow the Github documentation for creating a RR: Creating a pull request - Github Docs
2. Following completion of the testing by the developer, the developer will create a pull request to merge into development using the pre-set template (CDPHE-bioinformatics github PR template). Be sure to include the issues that the PR addresses in the PR by directly linking.
3. The developer will assign a reviewer for the PR. The reviewer will complete the PR and merge the wip branch into the development branch.
4. Multiple issues can be merged into develop until the bioinformatics team is ready to create a new release. When the team is ready to create a new release, we will perform a PR to main (see next section).

1. When we are ready to create a new release, a member from the bioinformatics team will create a PR to merge the development branch into main. The bioinformatics team member should either be the one who performed most of the code development or one of the reviewers.
2. The bioinformatics team member responsible for the PR will perform testing to ensure that all merged changes in development are compatible with one another and the expected results are produced.
3. A summary of the testing will be recorded in the PR as well as a description of the dataset used for testing.
4. TheiaValidate, in conjunction with other testing, should be used when major changes that affect multiple sections of the workflow have been made to ensure that all expected results are generated. (See appendix section titled TheiaValidate for further instructions regarding TheiaValidate.)
5. Following the completion of all testing, the bioinformatics team member will assign a reviewer for the PR. The reviewer is responsible for ensuring all testing was completed and was sufficient. The reviewer will then complete the PR and merge develop into main.
6. For our public facing repositories the main branch is designated as a protected branch meaning that a review is required prior to merging into main. If a team member attempts to merge a pull request with pending or rejected reviews into the protected branch the collaborator will receive an error message. For more including how to set up a protected branch see: About protected branches - GitHub Docs.

1. Create a version release: Managing Releases in a Repository - Github Doc
2. Once all changes have been merged into main, a new version release should be made following the semantic versioning style syntax. Please use the CDPHE-bioinformatics release notes template to format the release notes.
3. To create a version release you will be asked to create a new tag or choose from an existing one. The tag you choose should be the version release number, which should also be the title of the version release. Ensure the “Set as the latest release” checkbox is enabled to signify the release you are creating should be used in production.

Q: How do we handle a “hot fix” that needs to happen immediately when code breaks and we have an analysis deadline?

A: Document the issue using an issue request. Create a new “hot fix” branch based off of the current main branch. Make your changes. Use the “hot fix” branch to run the analysis until the “hot fix” branch can be merged into develop and then into main via the usual pull request process.