In epijim/admiral: ADaM in R Asset Library

knitr::opts_chunk$set(
  collapse = TRUE,
  comment = "#>"
)

Once you’ve familiarised yourself with the {admiral} contribution model and you’re ready to make your first code contribution, this development process step-by-step guide will help tie all the other detailed vignettes together to give you the simplest experience of helping to grow and enhance our codebase.

1. To start, you will have either created an issue or commented on an existing issue to notify that you’d like to contribute code. Then one of the {admiral} core team will assign you to the issue.
2. Create a new feature branch from the development branch devel following the naming convention and pull the latest changes - as detailed on the github usage guide.
3. Familiarise yourself with the {admiral} programming strategy, and then make the required code updates.
4. Before making a pull request, check the Pull Request Review Guidance & the following checklist of common things developers miss: a. Is all your code formatted according to the tidyverse style guide? a. Did you create/add appropriate unit tests? a. If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance? a. Did you update the documentation? If so, remember to run devtools::document() and include the updated NAMESPACE and .Rd files in man/ a. Does your code update have any impact on the ADaM template R scripts stored in inst/templates? a. Does your code update have any impact on the vignettes stored in vignettes? a. Did you update the Changelog NEWS.md? a. Did you build {admiral} site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page?
5. Once happy with all the updates, make a pull request to merge to the development branch devel and link the issue so that it closes after successful merging.
6. Check that there are no merge conflicts. If there are any, fix them before requesting review. See solving merge conflicts guidance.
7. Check the results of the automated R-CMD check and lintr checks and if any issues consult this guide.
8. Assign a reviewer from the {admiral} core development team – this could be anyone you discussed the issue with previously via Slack or GitHub. If unsure, add a comment that the pull request is ready for review and add the @pharmaverse/admiral-devs tag to it.
9. Once the review is completed, the reviewer will merge the PR and this will then automatically delete the feature branch.

Finally, just a note to say from the core developers that we hugely appreciate you taking the time to contribute to {admiral}. Don’t be offended if during review we send requests back to you, as the expectations are high so that we can ensure the {admiral} codebase remains robust and consistent. The best way to learn here is always to jump in and get involved, so please don’t be afraid you’ll make mistakes along the way – we all have and continue to do so, and that’s what the reviews are for. Also if ever you get stuck don't hesitate to reach out for support via the Slack channel. Welcome to our {admiral} community!

epijim/admiral documentation built on Feb. 13, 2022, 12:15 a.m.