From 4a66aa57782c363a3a6431f43598a89eaea075de Mon Sep 17 00:00:00 2001 From: Kangjie Zhang <47867131+kaz462@users.noreply.github.com> Date: Fri, 17 Nov 2023 11:27:38 -0500 Subject: [PATCH] Closes #347: remove dev process (#348) * #347: remove dev process * update devel to main, update development process link --- _pkgdown.yml | 2 -- vignettes/development_process.Rmd | 57 ------------------------------- vignettes/package_extensions.Rmd | 6 ++-- vignettes/pr_review_guidance.Rmd | 4 +-- 4 files changed, 5 insertions(+), 64 deletions(-) delete mode 100644 vignettes/development_process.Rmd diff --git a/_pkgdown.yml b/_pkgdown.yml index 93f389c2..7d62bcf6 100644 --- a/_pkgdown.yml +++ b/_pkgdown.yml @@ -111,8 +111,6 @@ navbar: articles: text: Developer Guides menu: - - text: Development Process - href: articles/development_process.html - text: Programming Strategy href: articles/programming_strategy.html - text: Writing Vignettes diff --git a/vignettes/development_process.Rmd b/vignettes/development_process.Rmd deleted file mode 100644 index ba08fdfa..00000000 --- a/vignettes/development_process.Rmd +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "Development Process" -output: - rmarkdown::html_vignette - -vignette: > - %\VignetteIndexEntry{Development Process} - %\VignetteEngine{knitr::rmarkdown} ---- - -```{r setup, include = FALSE} -knitr::opts_chunk$set( - collapse = TRUE, - comment = "#>" -) -``` - -Once you’ve familiarized yourself with the `{admiral}` [contribution -model](https://pharmaverse.github.io/admiral/cran-release/articles/contribution_model.html) -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. -1. 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](git_usage.html#working-with-feature-branches-1) guide. -1. Familiarize yourself with the `{admiral}` [programming -strategy](programming_strategy.html), and then make the required code updates. -1. Before making a pull request, check the [Pull Request Review Guidance](pr_review_guidance.html) & the following checklist of common things developers miss: - a. Is all your code formatted according to the [tidyverse](https://style.tidyverse.org/) style guide? - a. Did you create/add appropriate [unit tests](unit_test_guidance.html#writing-unit-tests-in-admiral)? - a. If you removed/replaced any function and/or function parameters, did you fully follow the [deprecation guidance](programming_strategy.html#deprecation)? - a. Did you update the [documentation](programming_strategy.html#function-header-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](https://pharmaverse.github.io/admiral/cran-release/articles/admiral.html#starting-a-script) 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](../reference/index.html)" page? -1. Once happy with all the updates, make a [pull request](git_usage.html#pull-request) to merge to the development branch `devel` and link the issue so that it closes after successful merging. -1. Check that there are no merge conflicts. If there are any, fix them before requesting review. See [solving merge conflicts](git_usage.html#solving-merge-conflicts-in-the-terminal-on-rstudio) guidance. -1. Check the results of the automated `R-CMD check` and `lintr` checks and if any issues consult this [guide](pr_review_guidance.html#common-r-cmd-check-issues). -1. 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` tag to it. -1. 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](https://app.slack.com/client/T028PB489D3/C02M8KN8269). **Welcome to our -`{admiral}` community!**_ diff --git a/vignettes/package_extensions.Rmd b/vignettes/package_extensions.Rmd index e0075e74..e13c79a7 100644 --- a/vignettes/package_extensions.Rmd +++ b/vignettes/package_extensions.Rmd @@ -77,13 +77,13 @@ _Note: The ordering numbers below are suggested but don't all need to strictly b 1. Update the template license file in your repo by adding the co-development company names in place of Roche & GSK - for `{admiral}` package extensions we use Apache 2.0, which is our preferred permissive license. Agree with the co-development companies any required extra wording for the copyright/IP section. 1. Set up a project board, such as [this](https://github.com/orgs/pharmaverse/projects/12), to help manage your backlog. -![admiral core project board](https://github.com/pharmaverse/admiraldev/raw/devel/vignettes/project_board.png){width=100%} +![admiral core project board](https://github.com/pharmaverse/admiraldev/raw/main/vignettes/project_board.png){width=100%} 1. Assuming you work under agile/scrum, then create a product backlog, prioritize and make a sprint plan. -1. The intention is always to re-use as much as possible from `{admiral}` core package. If you find anything additional needed for the package extension, you should first question whether it might be a common need for other TAs and if so consider instead raising an issue to `{admiral}` core. When designing new functions always try to stay aligned with the [Programming Strategy](https://pharmaverse.github.io/admiraldev/articles/programming_strategy.html). +1. The intention is always to re-use as much as possible from `{admiral}` core package. If you find anything additional needed for the package extension, you should first question whether it might be a common need for other TAs and if so consider instead raising an issue to `{admiral}` core. When designing new functions always try to stay aligned with the [Programming Strategy](https://pharmaverse.github.io/admiraldev/articles/programming_strategy.html). -1. Start development of your foundational first release 0.1.0. Follow a consistent [Development Process](https://pharmaverse.github.io/admiraldev/articles/development_process.html) to `{admiral}`. +1. Start development of your foundational first release 0.1.0. Follow a consistent [Development Process](https://pharmaverse.github.io/admiral/articles/contribution_model.html) to `{admiral}`. 1. Line up testers from your companies and others and set expectations around when you believe a stable version would be available for user testing. You can use the admiral Slack community to raise interest to get involved. diff --git a/vignettes/pr_review_guidance.Rmd b/vignettes/pr_review_guidance.Rmd index 248936a5..24fe8c82 100644 --- a/vignettes/pr_review_guidance.Rmd +++ b/vignettes/pr_review_guidance.Rmd @@ -29,7 +29,7 @@ Closely following the below guidance will ensure that our all our "addressed" is For a pull request to be merged into `devel` it needs to pass the automated CI checks that will appear at the bottom of the Pull Request. In addition, the PR creator and reviewer should make sure that -- the [Programming Strategy](programming_strategy.html) and [Development Process](development_process.html) are followed +- the [Programming Strategy](programming_strategy.html) and [Development Process](https://pharmaverse.github.io/admiral/articles/contribution_model.html) are followed - the function is ADaM IG compliant @@ -61,7 +61,7 @@ Sometimes, the development of a function or a vignette falls under a specific-to # So much Red Tape! -The `{admiral}` development team is aware and sympathetic to the great many checks, processes and documents needed to work through in order to do a compliant Pull Request. The `task-list-completed` GitHub workflow was created to help reduce this burden on contributors by providing a standardized checklist that compiles information from the Pull Request Review Guidance, [Programming Strategy](programming_strategy.html) and [Development Process](development_process.html) vignettes. +The `{admiral}` development team is aware and sympathetic to the great many checks, processes and documents needed to work through in order to do a compliant Pull Request. The `task-list-completed` GitHub workflow was created to help reduce this burden on contributors by providing a standardized checklist that compiles information from the Pull Request Review Guidance, [Programming Strategy](programming_strategy.html) and [Development Process](https://pharmaverse.github.io/admiral/articles/contribution_model.html) vignettes. The next three sections give a high-level overview of what a contributor faces in opening a PR, and how a contributor interacts with the `task-list-completed` workflow in their PR.