Merge branch 'main' into 509_add_top_lev_div@main

Signed-off-by: Davide Garolini <[email protected]>

.Rbuildignore

@@ -28,3 +28,9 @@
 ^temp$
 ~$
 ^vignettes/dev-guide$
+pkgdown
+inst/extdata/Advanced_rtables_part1.pdf
+inst/extdata/Advances_rtables_part2.pdf
+inst/extdata/Clinical_Trial_Reporting_Tables_in_R.pdf
+inst/extdata/r_adoption_slides.pdf
+^pkgdown$

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+ advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+ address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+ professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [email protected]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at <https://www.contributor-covenant.org/version/1/4/code-of-conduct.html>
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+<https://www.contributor-covenant.org/faq>

.github/CONTRIBUTING.md

@@ -0,0 +1,77 @@
+# Contributing to {rtables}
+
+We welcome contributions big and small to the ongoing development of the {rtables} package. For most, the best way to contribute to the package is by filing issues for feature requests or bugs that you have encountered. For those who are interested in contributing code to the package, contributions can be made by working on current issues and opening pull requests with code changes. Any help that you are able to provide is greatly appreciated!
+
+Contributions to this project are [released](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license) to the public under the project's open source license.
+
+---
+
+## Filing Issues
+
+Issues are used to establish a prioritized timeline and track development progress within the package. If there is a new feature that you feel would be enhance the experience of package users, please open a [Feature Request issue](https://github.com/insightsengineering/rtables/issues/new?labels=enhancement&template=feature.yml&title=%5BFeature+Request%5D%3A+%3Ctitle%3E). If you notice a bug in the existing code, please file a [Bug Fix issue](https://github.com/insightsengineering/rtables/issues/new?&labels=bug&template=bug.yml&title=%5BBug%5D%3A+%3Ctitle%3E) with a description of the bug and a [reprex](https://reprex.tidyverse.org/) (reproducible example). Other types of issues (questions, typos you've noticed, improvements to documentation, etc.) can be filed as well. Click [here](https://github.com/insightsengineering/rtables/issues/new/choose) to file a new issue, and [here](https://github.com/insightsengineering/rtables/issues) to see the list of current issues. Please utilize labels wherever possible when creating issues for organization purposes and to narrow down the scope of the work required.
+
+---
+
+## Creating Pull Requests
+
+Development of the {rtables} package relies on an _Issue → Branch → PR → Code Review → Merge_ pipeline facilitated through GitHub. If you are a more experienced programmer interested in contributing to the package code, please begin by filing an issue describing the changes you would like to make. It may be the case that your idea has already been implemented in some way, and the package maintainers can help to determine whether the feature is necessary before you begin development. Whether you are opening an issue or a pull request, the more detailed your description, the easier it will be for package maintainers to help you! To make code changes in the package, please follow the following process.
+
+### Pull Request Process
+
+The {rtables} package is part of the NEST project and utilizes [staged.dependencies](https://github.com/openpharma/staged.dependencies) to ensure to simplify the development process and track upstream and downstream package dependencies. We highly recommend installing and using this package when developing within {rtables}.
+
+#### 1. Create a branch
+
+In order to work on a new pull request, please first create a branch off of `main` upon which you can work and commit changes. To comply with [`staged.dependencies`](https://github.com/openpharma/staged.dependencies) standards, {rtables} uses the following branch naming convention:
+
+`issue#_description_of_issue@target_merge_branch`
+
+For example, `443_refactor_splits@main`. In most cases, the target merge branch is the base (`main`) branch. 
+
+In some cases, a change in {rtables} may first require upstream changes in the {formatters} package. Suppose we have branch `100_update_fmts@main` in {formatters} containing the required upstream changes. Then the branch created in {rtables} would be named as follows for this example: `443_refactor_splits@100_update_fmts@main`. This ensures that the correct branches are checked out when running tests, etc.
+
+For more details on `staged.dependencies` branch naming conventions, [click here](https://github.com/openpharma/staged.dependencies#branch-naming-convention).
+
+#### 2. Code
+
+Work within the {rtables} package to apply your code changes. Avoid combining issues on a single branch - ideally, each branch should be associated with a single issue and be prefixed by the issue number.
+
+For information on the basics of the {rtables} package, please read the package vignettes, which are available [here](https://insightsengineering.github.io/rtables/latest-tag/articles/index.html).
+
+For advanced development work within {rtables}, consider reading through the {rtables} Developer Guide. The Developer Guide can be accessed from the {rtables} site navigation bar, and is listed here for your convenience:
+
+- [Developer Guide: Split Machinery](https://insightsengineering.github.io/rtables/latest-tag/articles/dev-guide/dg_split_machinery.html)
+- [Developer Guide: Tabulation](https://insightsengineering.github.io/rtables/latest-tag/articles/dev-guide/dg_tabulation.html)
+- [Developer Guide: Debugging in {rtables} and Beyond](https://insightsengineering.github.io/rtables/latest-tag/articles/dev-guide/dg_debug_rtables.html)
+- [Developer Guide: Sparse Notes on {rtables} Internals](https://insightsengineering.github.io/rtables/latest-tag/articles/dev-guide/dg_notes.html)
+
+##### Code style
+
+The {rtables} package follows the tidyverse [style guide](https://style.tidyverse.org/index.html) so please adhere to these guidelines in your submitted code. After making changes to a file within the package, you can apply the package styler automatically and check for lint by running the following two lines of code while within the file:
+
+```
+styler:::style_active_file()
+lintr:::addin_lint()
+```
+
+##### Documentation
+
+Package documentation uses [`roxygen2`](https://roxygen2.r-lib.org/index.html). If your contribution requires updates to documentation, ensure that the roxygen comments are updated within the source code file. After updating roxygen documentation, run `devtools::document()` to update the accompanying `.Rd` files (do not update these files by hand!).
+
+##### Tests
+
+To ensure high code coverage, we create tests using the [`testthat`](https://testthat.r-lib.org/) package. In most cases, changes to package code necessitate the addition of one or more tests to ensure that any added features are working as expected and no existing features were broken.
+
+##### NEWS
+
+After making updates to the package, please add a descriptive entry to the NEWS file that reflects your changes. See the [tidyverse style guide](https://style.tidyverse.org/news.html) for guidelines on creating a NEWS entry.
+
+#### 3. Make a Pull Request
+
+Once the previous two steps are complete, you can create a pull request. Indicate in the description which issue is addressed in the pull request, and again utilize labels to help reviewers identify the category of the changes contained within the pull request.
+
+Once your pull request has been created, a series of checks will be automatically triggered, including `R CMD check`, tests/code coverage, auto-documentation, and more. All checks must be passing in order to eventually merge your pull request, and further changes may be required in order to resolve the status of these checks. All pull requests must also be reviewed and approved by at least one of the package maintainers before they can be merged. A review will be automatically requested from several {rtables} maintainers upon creating your pull request. When a maintainer reviews your pull request, please try to address the comments in short order - the {rtables} package is updated on a regular basis and leaving a pull request open too long is likely to result in merge conflicts which create more work for the developer.
+
+## Code of Conduct
+
+Please note that this project is released with a [Contributor Code of Conduct](CODE_OF_CONDUCT.html). By participating in this project you agree to abide by its terms.

.github/ISSUE_TEMPLATE/cran-release.yaml

@@ -0,0 +1,124 @@
+---
+name: 🎉 CRAN Release
+description: Template for release to CRAN
+title: "[Release]: <version>"
+labels: ["release"]
+assignees:
+  - KlaudiaBB
+  - cicdguy
+  - shajoezhu
+body:
+  - type: markdown
+    attributes:
+      value: |
+        ⚠️ Please do not link or mention any internal references in this issue. This includes internal URLs, intellectual property and references.
+  - type: textarea
+    id: blocked-by
+    attributes:
+      label: Blocked by
+      description: Any PRs or issues that this release is blocked by.
+      placeholder: Add a list of blocking PRs or issues here.
+      value: |
+        ### PRs
+
+        - [ ] PR 1
+
+        ### Issues
+
+        - [ ] Issue 1
+    validations:
+      required: true
+  - type: textarea
+    id: pre-release
+    attributes:
+      label: Pre-release
+      description: Pre-requisites that must be fulfilled before initiating the release process.
+      placeholder: Add your list of pre-requisites here.
+      value: |
+        - [ ] Make sure you adhere to CRAN submission policy: https://cran.r-project.org/web/packages/submission_checklist.html; https://cran.r-project.org/web/packages/policies.html.
+        - [ ] Make sure that high priority bugs (label "priority" + "bug") have been resolved before going into the release.
+        - [ ] Review old/hanging PRs before going into the release (Optional).
+        - [ ] Revisit R-package's lifecycle badges (Optional).
+        - [ ] Make sure that all upstream dependencies of this package that need to be submitted to CRAN were accepted before going into release activities.
+        - [ ] Make sure integration tests are green 2-3 days before the release. Look carefully through logs (check for warnings and notes).
+        - [ ] Decide what gets merged in before starting release activities.
+  - type: textarea
+    id: release
+    attributes:
+      label: Release
+      description: The steps to be taken in order to create a release.
+      placeholder: Steps to create a release.
+      value: |
+        ### Prepare the release
+
+        - [ ] Create a new release candidate branch
+          `git checkout -b release-candidate-vX.Y.Z`
+        - [ ] Update NEWS.md file: make sure it reflects a holistic summary of what has changed in the package.
+        - [ ] Remove the additional fields (`Remotes`) from the DESCRIPTION file where applicable.
+        - [ ] Make sure that the minimum dependency versions are updated in the DESCRIPTION file for the package and its reverse dependencies (Optional).
+          - [ ] Increase versioned dependency on {package name} to >=X.Y.Z (Optional).
+        - [ ] Commit your changes and create the PR on GitHub (add "[skip vbump]" in the PR title). Add all updates, commit, and push changes:
+          `# Make the necessary modifications to your files
+          # Stage the changes
+          git add <files your modified>
+          # Commit the changes
+          git commit -m "[skip vbump] <Your commit message>"
+          git push origin release-candidate-vX.Y.Z`
+
+        ### Test the release
+
+        - [ ] Execute the manual tests on Shiny apps that are deployed on various hosting providers (Posit connect and shinyapps.io) - track the results in GitHub issue (Applicable only for frameworks that use Shiny).
+        - [ ] Monitor integration tests, if integration fails, create priority issues on the board.
+        - [ ] Execute UAT tests (Optional).
+
+        ### CRAN submission
+
+        - [ ] Tag the update(s) as a release candidate vX.Y.Z-rc<iteration-number> (e.g. v0.5.3-rc1) on the release candidate branch (release-candidate-vX.Y.Z).
+          `# Create rc tag for submission for internal validation
+          git tag vX.Y.Z-rc<iteration number>
+          git push origin vX.Y.Z-rc<iteration number>`
+        - [ ] Build the package locally using the command:`R CMD build .` which will generate a .tar.gz file necessary for the CRAN submission.
+        - [ ] Submit the package to https://win-builder.r-project.org/upload.aspx for testing, for more details please see "Building and checking R source packages for Windows": https://win-builder.r-project.org/.
+        - [ ] Once tested, send the package that was built in the previous steps to CRAN via this form: https://cran.r-project.org/submit.html.
+        - [ ] Address CRAN feedback, tag the package vX.Y.Z-rc(n+1) and repeat the submission to CRAN whenever necessary.
+        - [ ] Get the package accepted and published on CRAN.
+
+        ### Tag the release
+
+        - [ ] If the additional fields were removed, add them back in a separate PR, and then merge the PR back to main (add "[skip vbump]" in the PR title). If nothing was removed just merge the PR you created in the "Prepare the release" section to 'main'. Note the commit hash of the merged commit. **Note:** additional commits might be added to the `main` branch by a bot or an automation - we do **NOT** want to tag this commit.
+
+        ### Make sure of the following before continuing
+
+        - [ ] CI checks are passing in GH before releasing the package.
+        - [ ] Shiny apps are deployable and there are no errors/warnings (Applicable only for frameworks that use Shiny).
+
+        - [ ] Create a git tag with the final version set to vX.Y.Z on the main branch. In order to do this:
+          1. Checkout the commit hash.
+          `git checkout <commit hash>`
+          2. Tag the hash with the release version (vX.Y.Z).
+          `git tag vX.Y.Z`
+          3. Push the tag to make the final release.
+          `git push origin vX.Y.Z`
+        - [ ] Update downstream package dependencies to (>=X.Y.Z) in {package name}.
+        Note: Once the release tag is created, the package is automatically published to internal repositories.
+  - type: textarea
+    id: post-release
+    attributes:
+      label: Post-release
+      description: The list of activities to be completed after the release.
+      placeholder: The steps that must be taken after the release.
+      value: |
+        - [ ] Ensure that CRAN checks are passing for the package.
+        - [ ] Make sure that the package is published to internal repositories.
+        - [ ] Make sure internal documentation is up to date.
+        - [ ] Review and update installation instructions for the package wherever needed (Optional).
+        - [ ] Update all integration tests to reference the new release.
+        - [ ] Announce the release on ________.
+  - type: textarea
+    id: decision-tree
+    attributes:
+      label: Decision tree
+      description: Any decision tree(s) that would aid release management
+      placeholder: Any decision tree(s) that would aid release management.
+      value: |
+        Click [here](https://github.com/insightsengineering/.github/blob/main/.github/ISSUE_TEMPLATE/RELEASE_DECISION_TREE.md) to see the release decision tree.