issue template

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,23 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: 'Bug Report: <Describe bug>'
+labels: ''
+assignees: ''
+
+---
+
+Do not use this form to ask a question, or ask for assistance. Instead, ask on <https://stackoverflow.com/> using the `r-cards` tag.
+Questions about a function's use will be closed without a response.
+
+If you have found a bug, please briefly describe your problem and what output you expect.
+
+INCLUDE a *minimal* reproducible example (AKA a reprex). If you've never heard of a [reprex](https://reprex.tidyverse.org/) before, start by reading <https://www.tidyverse.org/help/#reprex>. It'll take minutes to master creating a reprex.
+
+---
+
+Brief description of the problem.
+
+```r
+# insert reprex here
+```

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,5 @@
+blank_issues_enabled: true
+contact_links:
+  - name: Ask a Question
+    url: https://stackoverflow.com/questions/ask?tags=r-cards,r
+    about: Question must include a minimal reproducible example, aka a reprex.

.github/ISSUE_TEMPLATE/cran-release.yaml → .github/ISSUE_TEMPLATE/cran-release.yml

@@ -1,12 +1,11 @@
 ---
 name: 🎉 CRAN Release
 description: Template for release to CRAN
-title: "[Release]: <version>"
+title: "[CRAN Release]: <version>"
 labels: ["release"]
 assignees:
   - KlaudiaBB
   - cicdguy
-  - shajoezhu
 body:
   - type: markdown
     attributes:
@@ -19,12 +18,10 @@ body:
       description: Any PRs or issues that this release is blocked by.
       placeholder: Add a list of blocking PRs or issues here.
       value: |
-        ### PRs
-
+        #### PRs
         - [ ] PR 1
 
-        ### Issues
-
+        #### Issues
         - [ ] Issue 1
     validations:
       required: true
@@ -35,7 +32,9 @@ body:
       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 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).
@@ -49,46 +48,46 @@ body:
       description: The steps to be taken in order to create a release.
       placeholder: Steps to create a release.
       value: |
-        ### Prepare the release
-
+        #### 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
+          ```r
+          # 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
 
+        #### 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
-
+        #### 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
+          ```r
+          # 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>`
+          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
-
+        #### 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
-
+        ##### 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).
 
@@ -100,7 +99,7 @@ body:
           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.
+        **Note:** Once the release tag is created, the package is automatically published to internal repositories.
   - type: textarea
     id: post-release
     attributes:
@@ -112,7 +111,6 @@ body:
         - [ ] 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

.github/ISSUE_TEMPLATE/feature.yml

@@ -1,35 +1,8 @@
 ---
 name: ✨ Feature Request
 description: Request or propose a new feature
-title: "[Feature Request]: <title>"
-labels: ["enhancement"]
-body:
-  - type: textarea
-    attributes:
-      label: Feature description
-    validations:
-      required: true
-  - type: checkboxes
-    id: code-of-conduct
-    attributes:
-      label: Code of Conduct
-      description: By submitting this issue, you agree to follow our [Code of Conduct.](https://insightsengineering.github.io/cardx/CODE_OF_CONDUCT.html)
-      options:
-        - label: I agree to follow this project's Code of Conduct.
-          required: true
-  - type: checkboxes
-    id: contributor-guidelines
-    attributes:
-      label: Contribution Guidelines
-      description: By submitting this issue, you agree to follow our [Contribution Guidelines.](https://insightsengineering.github.io/cardx/CONTRIBUTING.html)
-      options:
-        - label: I agree to follow this project's Contribution Guidelines.
-          required: true
-  - type: checkboxes
-    id: security-policy
-    attributes:
-      label: Security Policy
-      description: By submitting this issue, you agree to follow our [Security Policy.](https://github.com/insightsengineering/cardx/security/policy)
-      options:
-        - label: I agree to follow this project's Security Policy.
-          required: true
+title: 'Feature Request: <Description>'
+labels: ''
+assignees: ''
+
+---

.github/ISSUE_TEMPLATE/release.yaml → .github/ISSUE_TEMPLATE/release.yml

@@ -18,12 +18,10 @@ body:
       description: Any PRs or issues that this release is blocked by.
       placeholder: Add a list of blocking PRs or issues here.
       value: |
-        ### PRs
-
+        #### PRs
         - [ ] PR 1
 
-        ### Issues
-
+        #### Issues
         - [ ] Issue 1
     validations:
       required: true
@@ -48,46 +46,48 @@ body:
       description: The steps to be taken in order to create a release.
       placeholder: Steps to create a release.
       value: |
-        ### Prepare the release
-
+        #### 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, check README.
         - [ ] 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.
-        - [ ] Increase versioned dependency on {package name} to >=X.Y.Z.
+          - [ ] Increase versioned dependency on {package name} to >=X.Y.Z.
         - [ ] 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`
+          ```r
+          # 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
 
+        #### 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).
 
-        ### Validation loop
 
-        Note: This section is applicable only for regulatory packages.
+        #### Validation loop
+
+        **Note:** This section is applicable only for regulatory packages.
 
         - [ ] 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
+          ```r
+          # 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>`
+          git push origin vX.Y.Z-rc<iteration number>
+          ```
         - [ ] Submit the package for internal validation.
         - [ ] Address any feedback (internal validation/user testing), retag the package as a release candidate vX.Y.Z-rc(n+1). Repeat the submission for internal validation if necessary.
         - [ ] Get the package validated.
 
-        ### Tag the release
-
+        #### 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 with the release:
-
+        ##### Make sure of the following before continuing with the release:
         - [ ] CI checks are passing in GH.
         - [ ] Shiny apps are deployable and there are no errors/warnings (Applicable only for frameworks that use Shiny).
 
@@ -99,7 +99,7 @@ body:
           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.
+        **Note:** Once the release tag is created, the package is automatically published to internal repositories.
   - type: textarea
     id: post-release
     attributes: