GitHub flow

.github/pull_request_template.md

@@ -1,6 +1,6 @@
 Thank you for your Pull Request! We have developed this task checklist from the [Development Process Guide](https://pharmaverse.github.io/admiraldev/articles/development_process.html) to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.   
 
-Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the `devel` branch until you have checked off each task.
+Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the `main` branch until you have checked off each task.
 
 - [ ] Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
 - [ ] Code is formatted according to the [tidyverse style guide](https://style.tidyverse.org/). Run `styler::style_file()` to style R and Rmd files

vignettes/development_process.Rmd

@@ -24,7 +24,7 @@ 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. Create a new feature branch from the development branch `main` 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:
@@ -36,7 +36,7 @@ strategy](programming_strategy.html), and then make the required code updates.
     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. Once happy with all the updates, make a [pull request](git_usage.html#pull-request) to merge to the `main` branch 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

vignettes/git_usage.Rmd

@@ -27,12 +27,11 @@ This article will give you an overview of how the `{admiral}` project is utilizi
 -	The `main` branch contains the latest **released** version and should not be used for development. You can find the released versions [here](https://GitHub.com/pharmaverse/admiral/releases) 
 -	The `devel` branch contains the latest development version of the package. You will always be branching off and pulling into the `devel` branch. This is set as the default branch on GitHub.
 - The `gh-pages` branches contains the code used to render this website you are looking at right now!
-- The `patch` branch is reserved for special hot fixes to address bugs. More info in [Hot Fix Release](release_strategy.html#hot-fix-release)
-- The `main`, `devel`, `gh-pages`, `patch` branches are under protection. If you try and push changes to these branches you will get an error unless you are an administrator. 
+- The `patch` branch is reserved for special hot fixes to address bugs and should rarely be used. More info in [Hot Fix Release](release_strategy.html#hot-fix-release)
+- The `main`, `gh-pages`, `patch` branches are under protection. If you try and push changes to these branches you will get an error unless you are an administrator. 
 
 -	**Feature** branches are where actual development related to a specific issue happens. Feature branches are merged into `devel` once a pull request is merged. Check out the [Pull Request Review Guidance](pr_review_guidance.html) for more guidance on merging into `devel`.
 
-
 # Working with Feature Branches
 
 Feature Branches are where most developers will work when addressing Issues. 
@@ -43,23 +42,21 @@ Each feature branch must be related to an issue. We encourage new developers to
 
 ### Naming Branches
 
-The name of the branch must be prefixed with the issue number, followed by a short but meaningful description and the `@<target_branch>` suffix. The latter would be `@devel` in most cases. As an example, given an issue #94 "Program function to derive `LSTALVDT`", the branch name would be `94_derive_var_lstalvdt@devel`.
-
-The `@<target_branch>` suffix is used in our CI/CD pipelines, e.g. when running `R CMD check`. It ensures that `{admiral}`'s dependencies such as `{pharmaversesdtm}` and `{admiraldev}` are installed from the specified target branch. So when the target branch is set to `@devel` the dependencies will be installed from those package's respective `devel` branches rather than installing the latest released version. This ensures that we test the development version of `{admiral}` against the development versions of its  dependencies. That way all packages are kept in sync.
+The name of the branch must be prefixed with the issue number, followed by a short but meaningful description. As an example, given an issue #94 "Program function to derive `LSTALVDT`", the branch name would be `94_derive_var_lstalvdt`.
 
-### Create a New Feature Branch from the Terminal (from `devel`)
+### Create a New Feature Branch from the Terminal (from `main`)
 
--	Checkout the devel branch: `git checkout devel`  
+-	Checkout the main branch: `git checkout main`  
 -	Pull the latest changes from GitHub: `git pull`  
--	Create a new branch off the devel branch and switch to it: `git checkout -b <new_branch_name>`
+-	Create a new branch off the main branch and switch to it: `git checkout -b <new_branch_name>`
 
-### Create a New Feature Branch from GitHub (from `devel`)
+### Create a New Feature Branch from GitHub (from `main`)
 
 You can also create a feature branch in GitHub. 
 
-- Switch to the `devel` branch
+- Switch to the `main` branch
 - Type in your new feature branch name
-- Click Create branch: `<your_branch_name>@devel` from `devel`
+- Click Create branch: `<your_branch_name>@main` from `main`
 - Be Sure to Pull down newly created branch into RStudio
 
 ```{r, echo = FALSE}
@@ -113,7 +110,7 @@ We recommend a thorough read through of the articles, [Pull Request Review Guida
 Once all changes are committed, push the updated branch to GitHub:  
 `git push -u origin <branch_name>`  
 
-In GitHub, under **Pull requests**, the user will either have a "Compare and pull request" button and/or a "Create Pull Request".  The first button will be created for you if GitHub detects recent changes you have made. The branch to merge with must be the `devel` branch (base = `devel`) and the compare branch is the new branch to merge - as shown in the below picture. Please **pay close attention** to the branch you are merging into!  
+In GitHub, under **Pull requests**, the user will either have a "Compare and pull request" button and/or a "Create Pull Request".  The first button will be created for you if GitHub detects recent changes you have made. The branch to merge with must be the `main` branch (base = `main`) and the compare branch is the new branch to merge - as shown in the below picture. Please **pay close attention** to the branch you are merging into!  
 
 The issue must be linked to the pull request in the "Development" field of the
 Pull Request. In most cases, this will linkage will automatically close the issue and move to the Done column on our project board.
@@ -153,10 +150,10 @@ knitr::include_graphics("github_done.png", dpi = 144)
 Merge conflict is a situation where `git` cannot decide which changes to apply since there were multiple updates in the same part of a file. This typically happens when multiple people update the same part of code. Those conflicts always need to be handled manually (as some further code updates may be required):
 
 ```
-git checkout devel
+git checkout main
 git pull
 git checkout <feature_branch>  
-git merge devel
+git merge main
 ```
 
 This provides a list of all files with conflicts In the file with conflicts the conflicting sections are marked with `<<<<<<<`, `=======`, and `>>>>>>>`. The code between these markers must be updated and the markers be removed. Source files need to be updated manually. Generated files like NAMESPACE or the generated documentation files should not be updated manually but recreated after the source files were updated. 

vignettes/package_extensions.Rmd

@@ -57,6 +57,7 @@ _Note: The ordering numbers below are suggested but don't all need to strictly b
 1. Agree on a charter and expectations of each company, e.g. we usually ask for at least 3 developers with at least 25% capacity and a mix of R, GitHub and TA experience. Within the charter make sure the scope and timelines are clear. _It is important here not to try to boil the ocean. Focus first on the very common endpoints required as a foundation and then the package can build up from here via contributions from both the co-development companies and also the wider across-industry admiral community. If useful, the `{admiralonco}` charter could be shared as a guide._
 
 1. Each company should start to identify the required developer resources. Then each developer is required to complete the `{admiral`} [dummy issue for onboarding](https://github.com/pharmaverse/admiral/issues/1839), as well as reading up on the [admiraldev documentation](https://pharmaverse.github.io/admiraldev/index.html), - especially the developer guides, which all need to be followed for package extensions.
+
 ![Dummy issue for new developers](https://github.com/pharmaverse/admiraldev/raw/main/vignettes/dummy_issue.png){width=100%}
 
 1. Optionally it can be useful to host a kick-off meeting to decide how the team will work, for which we recommend agile/scrum practices.
@@ -77,7 +78,7 @@ _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.
 

vignettes/pr_review_guidance.Rmd

@@ -21,13 +21,13 @@ knitr::opts_chunk$set(
 
 This document is intended to be guidance for creators and reviewers of pull requests (PRs) in the `{admiral}` package family. PR authors will benefit from shorter review times by closely following the guidance provided here.
 
-A pull request into the `devel` branch signifies that an issue has been "addressed". This issue might be a bug, a feature request or a documentation update. Once a Pull Request is merged into `devel` branch, then the issue(s) can be closed.
+A pull request into the `main` branch signifies that an issue has been "addressed". This issue might be a bug, a feature request or a documentation update. Once a Pull Request is merged into `main` branch, then the issue(s) can be closed.
 
-Closely following the below guidance will ensure that our all our "addressed" issues auto-close once we merge `devel`.
+Closely following the below guidance will ensure that our all our "addressed" issues auto-close once we merge `main`.
 
 # Review Criteria
 
-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
+For a pull request to be merged into `main` 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
 
@@ -83,15 +83,15 @@ knitr::include_graphics("./pr_review_checkbox.png")
 
 ## Complete the Pull Request checklist
 
-The check boxes are linked to the `task-list-completed` workflow. You need to check off each box in acknowledgment that you have done you due diligence in creating a compliant Pull Request. GitHub will refresh the Pull Request and trigger `task-list-completed` workflow that you have completed the task. The PR can not be merged into `devel` until the contributor has checked off each of the check box items.
+The check boxes are linked to the `task-list-completed` workflow. You need to check off each box in acknowledgment that you have done you due diligence in creating a compliant Pull Request. GitHub will refresh the Pull Request and trigger `task-list-completed` workflow that you have completed the task. The PR can not be merged into `main` until the contributor has checked off each of the check box items.
 
 ```{r echo=FALSE, out.width='120%'}
 knitr::include_graphics("./pr_review_actions.png")
 ```
 
 Please don't hesitate to reach out to the `{admiral}` team on [Slack](https://app.slack.com/client/T028PB489D3/C02M8KN8269) or through the [GitHub Issues](https://github.com/pharmaverse/admiral/issues) tracker if you think this checklist needs to be amended or further clarity is needed on a check box item.
 
-**Note for Reviewers:** We recommend the use of Squash and Merge when merging in a Pull Request. This will create a clean commit history when doing a final merge of `devel` into `main`.
+**Note for Reviewers:** We recommend the use of Squash and Merge when merging in a Pull Request. This will create a clean commit history.
 
 # GitHub Actions/CI Workflows