This page is under development. We’d love your help making it better!
Hello! Thank you for your interest in contributing to the PREP pacakge. This page provides guidelines for technical contributors to this project. . If you can’t find what you need on this page, don’t hesitate to email Kyle with questions.
The ASA Biopharm software group creates open source software that seeks to improve and standardize statistical computing in Biopharmaceutical research. The rest of this document provides details about our technical approach.
This guide assumes a basic understanding of GitHub. If you’ve never used GitHub, I strongly recommend reading through their help pages and/or doing some online learning.
To gain access, send Kyle your GitHub user name, and he will grant you access to the organization and add you to the appropriate teams.
All repos have active issue trackers. All issues should, at a minimum contain a name, description, assignee and release version (tracked using a GitHub “Milestone”).
Each release has it’s own GitHub project board containing all issues being resolved in the release. We typically use columns for ‘To Do’, ‘In Progress’, ‘Ready for review’ and ‘Done’. Developers should update the project board as they go.
We typically use three types of branches:
master - The production version of the repository. Commits directly to the master branch are not permitted, so all code development must be done in development and feature branches as described below.vX.X.X-dev. When the work on the release is complete, the development branch will be merged to master via a pull request.add-participant-filter). Once all issues are resolved, the feature branch should be merged into a development branch.For a large release, there will likely be several feature branches merged to the development branch before the development branch is merged to master. Commits directly to development branches are discouraged since we generally recommend making a feature branch/PR instead. However, for a small release that only resolves a few features, a single development branch may be sufficient. Following this Branch structure is important since our quality control is built using this framework.
All merging should be done via pull requests. More details of our merge/PR process are provided in the Quality Control section below.
We pay great attention to the quality of our tools, and all repos are subject to significant testing and quality control and have detailed documentation. More detail is provided in the links below. That said, none of our repositories are currently validated per the 21 CFR Part 11 guidelines. We also have several team members who are actively involved in the R Validation Hub effort.
For R packages, we follow the guidelines in Hadley Wickham’s R Packages book. And include tests via the testthat package.
This page was adapted from these guidelines.