8000 Release v1.3.0 by mattroumaya · Pull Request #868 · Gilead-BioStats/gsm · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Release v1.3.0 #868

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 351 commits into from
Nov 11, 2022
Merged

Release v1.3.0 #868

merged 351 commits into from
Nov 11, 2022

Conversation

mattroumaya
Copy link
Contributor
@mattroumaya mattroumaya commented Nov 8, 2022 •
edited
Loading

Release Description

Release v.1.3.0

Assessments Updated

  • Includes addition of normal approximation statistical method, with added functions Analyze_NormalApprox(), Flag_NormalApprox(), and Analyze_NormalApprox_PredictBounds().
    • The normal approximation method is now the default for AE_Assess(), Disp_Assess(), LB_Assess(), and PD_Assess().
  • Significant documentation and vignette updates.
  • Supports QTLs run via Study_Assess() and Make_Snapshot()

Milestone

Milestone: v1.0.0

Overall Risk Assessment

Overall Risk: Medium

Notes:
Designating medium risk because a new default statistical method was added to qualified assessment functions.

Release Checklist

  • Version number has been updated in DESCRIPTION
  • NEWS.md has been updated
  • Ensure all unit tests are passing
  • Ensure all qualification tests are passing and report has been rerun
  • All QC Checklists in this PR are complete
  • GitHub actions on this PR are all passing
  • Formatted code with styler
  • Run spell_check()
  • Completed QC of documentation including README.md and relevant Vignettes
  • Build site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.
  • Draft GitHub release created using automatic template and updated with additional details. Remember to click "release" after PR is merged.
 8000

mattroumaya and others added 30 commits October 18, 2022 18:46
@mattroumaya
revert AE and LB
d04f4f1
@mattroumaya
update tests and docs
3608668
@mattroumaya
remove AE and LB workflows
f7e5fbb
@collleenmclaughlin
More Cookbook updates
fb169af
@samussiah
Merge pull request #814 from Gilead-BioStats/fix-tests
e53aa47 
update tests and docs
@collleenmclaughlin
Make_Snapshot
f376085
@mattroumaya
update qtl functions
725daae
@mattroumaya
Merge remote-tracking branch 'origin/dev' into fix-782-matt
4ff403f
@mattroumaya
pkgdown
72f59e1
@mattroumaya
Merge remote-tracking branch 'origin/dev' into fix-706
756d6e1
@mattroumaya
update LB KRI'
2dacb21
@mattroumaya
Merge remote-tracking branch 'origin/dev' into fix-635
9316abc
@mattroumaya
add qtl to default run
bc8beaa
@collleenmclaughlin
Unit tests
047158e
@collleenmclaughlin
Added snapshot date to results_summary of Make_Snapshot
5edc838
@mattroumaya
unit tests
ce6a7ba
@Zhongkai-Wang
Merge pull request #820 from Gilead-BioStats/fix-750-mr
7a2ca90 
Fix unit tests for new stats methods
@mattroumaya
Merge pull request #819 from Gilead-BioStats/fix-811
ff02c3f 
Fix 811 - Added Snapshot Date to results_summary of Make_Snapshot()
@mattroumaya
update pkgdown index
d5d707d
@mattroumaya
Merge remote-tracking branch 'origin/dev' into fix-782-matt
5cf573a
@collleenmclaughlin
Updated test data for Study_Assess()
45c0986
@collleenmclaughlin
Delete test-Get_Enrolled.R
36a00e0
@collleenmclaughlin
Delete test_Make_Snapshot.R
c524a6c
@collleenmclaughlin @mattroumaya
Update vignettes/gismo_outputs.csv
4b7f8d6 
Co-authored-by: Matt Roumaya <40671730+mattroumaya@users.noreply.github.com>
@mattroumaya
updates
eb0e975
@mattroumaya
Merge pull request #816 from Gilead-BioStats/fix-706
1c77134 
Fix 706 - Finalize Lab KRI Workflow
@mattroumaya
Merge remote-tracking branch 'origin/dev' into fix-635
9abb8aa
@collleenmclaughlin
Unit tests for Get_Enrolled(); Also updated Get_Enrolled() documentat…
4153374 
…ion for expected output
@mattroumaya
Merge pull request #803 from Gilead-BioStats/fix-635
9382f8c 
Fix 635 - Add country to grouping
@collleenmclaughlin
Removing old code (had inconsistent naming)
3cb2966
@mattroumaya mattroumaya changed the base branch from dev to main November 8, 2022 22:27
@mattroumaya mattroumaya self-assigned this Nov 8, 2022
@mattroumaya
Copy link
Contributor Author
mattroumaya commented Nov 9, 2022 •
edited
Loading

Adverse Event (AE) Assessment Checklist

  • Documentation
    • Function name captured in roxygen2 title (e.g., "Adverse Event Assessment")
    • Assessment purpose captured in roxygen2 description (e.g., "Evaluates adverse event (AE) rates to identify sites that may be over- or under-reporting AEs")
    • Input data requirements are captured in a dedicated roxygen2 details section under Data specification (#' @section Data specification, or # Data specification if storing data specification in a .md file).
    • Statistical methods and assumptions are captured in a dedicated roxygen2 details section under Statistical assumptions (#' @section Statistical assumptions, or # Statistical assumptions if storing statistical assumptions in a .md file). This section should link to the relevant Analyze_ function(s) for further details.
    • All function parameters are described with a @param tag. Each parameter description should include its name, type, purpose, usage details, default value (if applicable), requirement, and valid options (if applicable).
    • All external dependencies are captured. Use @importFrom _package_ _function_ when importing five (5) or fewer functions, and @import _package_ otherwise.
    • Function output is captured with a @return tag. Each output description should include output type, structure, and data specification (if applicable).
    • At least one (1) example is provided under an @examples tag.
  • Error Checking
    • Basic checks for all parameters should be included using stopifnot() or similar logic (e.g., stopifnot("dfInput is not a data frame" = is.data.frame(dfInput)))
    • Tests confirm that stopifnot() parameter checks are working as expected.
    • Tests confirm that the input data has required columns (if any).
    • Tests confirm that the output data has expected columns/structure.
    • Tests confirm intended functionality for each parameter.
    • Tests confirm that missing data in required columns is handled appropriately and errors/warnings are produced if needed.
  • Basic QC
    • Assessment has User Requirements + Qualification tests captured using qualification framework. A QC report is generated as expected and all checks pass successfully.
    • Code is well commented and easy to read/understand.
    • No file paths or other company-specific data are present.
    • Function called from non-tidyverse dependencies are called via ::.
    • devtools::check() passes with no errors/warnings/notes.
    • Package documents are up to date, and running devtools::document() does not change any files.
    • Codes use {tidyverse} best practices for standard data manipulation. If unclear, reviewer should start a discussion thread.
    • All new dependencies add significant value. If unclear, reviewer should start a discussion thread.
    • All GitHub Actions run with no errors.

Notes:

  • Now that NormalApprox is the default method, add unit test(s) for poisson method
  • For AE_Assess(), add test that metadata has not changed, like what's done for AE_Map_*
  • Update default param or build in logic to ensure a smoother boundary for Analyze_Poisson_PredictBounds():
df_ae <- AE_Map_Raw()

ae <- AE_Assess(df_ae, strMethod = "poisson")

print(ae$lCharts$scatter)

image

@mattroumaya
Copy link
Contributor Author
mattroumaya commented Nov 9, 2022 •
edited
Loading

Consent Assessment Checklist

  • Documentation

    • Function name captured in roxygen2 title (e.g., "Adverse Event Assessment")
    • Assessment purpose captured in roxygen2 description (e.g., "Evaluates adverse event (AE) rates to identify sites that may be over- or under-reporting AEs")
    • Input data requirements are captured in a dedicated roxygen2 details section under Data specification (#' @section Data specification, or # Data specification if storing data specification in a .md file).
    • Statistical methods and assumptions are captured in a dedicated roxygen2 details section under Statistical assumptions (#' @section Statistical assumptions, or # Statistical assumptions if storing statistical assumptions in a .md file). This section should link to the relevant Analyze_ function(s) for further details.
    • All function parameters are described with a @param tag. Each parameter description should include its name, type, purpose, usage details, default value (if applicable), requirement, and valid options (if applicable).
    • All external dependencies are captured. Use @importFrom _package_ _function_ when importing five (5) or fewer functions, and @import _package_ otherwise.
    • Function output is captured with a @return tag. Each output description should include output type, structure, and data specification (if applicable).
    • At least one (1) example is provided under an @examples tag.

  • Error Checking

    • Basic checks for all parameters should be included using stopifnot() or similar logic (e.g., stopifnot("dfInput is not a data frame" = is.data.frame(dfInput)))
    • Tests confirm that stopifnot() parameter checks are working as expected.
    • Tests confirm that the input data has required columns (if any).
    • Tests confirm that the output data has expected columns/structure.
    • Tests confirm intended functionality for each parameter.
    • Tests confirm that missing data in required columns is handled appropriately and errors/warnings are produced if needed.

  • Basic QC

    • Assessment has User Requirements + Qualification tests captured using qualification framework. A QC report is generated as expected and all checks pass successfully.
    • Code is well commented and easy to read/understand.
    • No file paths or other company-specific data are present.
    • Function called from non-tidyverse dependencies are called via ::.
    • devtools::check() passes with no errors/warnings/notes.
    • Package documents are up to date, and running devtools::document() does not change any files.
    • Codes use {tidyverse} best practices for standard data manipulation. If unclear, reviewer should start a discussion thread.
    • All new dependencies add significant value. If unclear, reviewer should start a discussion thread.
    • All GitHub Actions run with no errors.

  • For Consent_Assess(), add test that metadata has not changed, like what's done for AE_Map_*

@mattroumaya
Copy link
Contributor Author
mattroumaya commented Nov 9, 2022 •
edited
Loading

Disposition Assessment Checklist

  1. Disp_Map_Raw()
  2. Disp_Assess()
  • Documentation
    • Function name captured in roxygen2 title (e.g., "Adverse Event Assessment")
    • Assessment purpose captured in roxygen2 description (e.g., "Evaluates adverse event (AE) rates to identify sites that may be over- or under-reporting AEs")
    • Input data requirements are captured in a dedicated roxygen2 details section under Data specification (#' @section Data specification, or # Data specification if storing data specification in a .md file).
    • Statistical methods and assumptions are captured in a dedicated roxygen2 details section under Statistical assumptions (#' @section Statistical assumptions, or # Statistical assumptions if storing statistical assumptions in a .md file). This section should link to the relevant Analyze_ function(s) for further details.
    • All function parameters are described with a @param tag. Each parameter description should include its name, type, purpose, usage details, default value (if applicable), requirement, and valid options (if applicable).
    • All external dependencies are captured. Use @importFrom _package_ _function_ when importing five (5) or fewer functions, and @import _package_ otherwise.
    • Function output is captured with a @return tag. Each output description should include output type, structure, and data specification (if applicable).
    • At least one (1) example is provided under an @examples tag.
  • Error Checking
    • Basic checks for all parameters should be included using stopifnot() or similar logic (e.g., stopifnot("dfInput is not a data frame" = is.data.frame(dfInput)))
    • Tests confirm that stopifnot() parameter checks are working as expected.
    • Tests confirm that the input data has required columns (if any).
    • Tests confirm that the output data has expected columns/structure.
    • Tests confirm intended functionality for each parameter.
    • Tests confirm that missing data in required columns is handled appropriately and errors/warnings are produced if needed.
  • Basic QC
    • Assessment has User Requirements + Qualification tests captured using qualification framework. A QC report is generated as expected and all checks pass successfully.
    • Code is well commented and easy to read/understand.
    • No file paths or other company-specific data are present.
    • Function called from non-tidyverse dependencies are called via ::.
    • devtools::check() passes with no errors/warnings/notes.
    • Package documents are up to date, and running devtools::document() does not change any files.
    • Codes use {tidyverse} best practices for standard data manipulation. If unclear, reviewer should start a discussion thread.
    • All new dependencies add significant value. If unclear, reviewer should start a discussion thread.
    • All GitHub Actions run with no errors.

Notes:

  • Now that NormalApprox is the default method, add unit test(s) for fisher method
  • Either add tests for nConfLevel or remove from function and hardcode for each assessment.
  • Add tests for strMethod == "qtl"

@mattroumaya
Copy link
Contributor Author
mattroumaya commented Nov 9, 2022 •
edited by Zhongkai-Wang
Loading

Lab Abnormalities Assessment Checklist

  1. LB_Map_Raw()
  2. LB_Assess()
  • Documentation
    • Function name captured in roxygen2 title (e.g., "Adverse Event Assessment")
    • Assessment purpose captured in roxygen2 description (e.g., "Evaluates adverse event (AE) rates to identify sites that may be over- or under-reporting AEs")
    • Input data requirements are captured in a dedicated roxygen2 details section under Data specification (#' @section Data specification, or # Data specification if storing data specification in a .md file).
    • Statistical methods and assumptions are captured in a dedicated roxygen2 details section under Statistical assumptions (#' @section Statistical assumptions, or # Statistical assumptions if storing statistical assumptions in a .md file). This section should link to the relevant Analyze_ function(s) for further details.
    • All function parameters are described with a @param tag. Each parameter description should include its name, type, purpose, usage details, default value (if applicable), requirement, and valid options (if applicable).
    • All external dependencies are captured. Use @importFrom _package_ _function_ when importing five (5) or fewer functions, and @import _package_ otherwise.
    • Function output is captured with a @return tag. Each output description should include output type, structure, and data specification (if applicable).
    • At least one (1) example is provided under an @examples tag.
  • Error Checking
    • Basic checks for all parameters should be included using stopifnot() or similar logic (e.g., stopifnot("dfInput is not a data frame" = is.data.frame(dfInput)))
    • Tests confirm that stopifnot() parameter checks are working as expected.
    • Tests confirm that the input data has required columns (if any).
    • Tests confirm that the output data has expected columns/structure.
    • Tests confirm intended functionality for each parameter.
    • Tests confirm that missing data in required columns is handled appropriately and errors/warnings are produced if needed.
  • Basic QC
    • Assessment has User Requirements + Qualification tests captured using qualification framework. A QC report is generated as expected and all checks pass successfully.
    • Code is well commented and easy to read/understand.
    • No file paths or other company-specific data are present.
    • Function called from non-tidyverse dependencies are called via ::.
    • devtools::check() passes with no errors/warnings/notes.
    • Package documents are up to date, and running devtools::document() does not change any files.
    • Codes use {tidyverse} best practices for standard data manipulation. If unclear, reviewer should start a discussion thread.
    • All new dependencies add significant value. If unclear, reviewer should start a discussion thread.
    • All GitHub Actions run with no errors.

Notes:

  • Check that metadata hasn't changed for LB_Assess unit test
  • Now that NormalApprox is the default method, add unit test(s) for fisher method

@mattroumaya
Copy link
Contributor Author
mattroumaya commented Nov 9, 2022 •
edited
Loading

Inclusion/Exclusion (IE) Assessment Checklist

  • Documentation
    • Function name captured in roxygen2 title (e.g., "Adverse Event Assessment")
    • Assessment purpose captured in roxygen2 description (e.g., "Evaluates adverse event (AE) rates to identify sites that may be over- or under-reporting AEs")
    • Input data requirements are captured in a dedicated roxygen2 details section under Data specification (#' @section Data specification, or # Data specification if storing data specification in a .md file).
    • Statistical methods and assumptions are captured in a dedicated roxygen2 details section under Statistical assumptions (#' @section Statistical assumptions, or # Statistical assumptions if storing statistical assumptions in a .md file). This section should link to the relevant Analyze_ function(s) for further details.
    • All function parameters are described with a @param tag. Each parameter description should include its name, type, purpose, usage details, default value (if applicable), requirement, and valid options (if applicable).
    • All external dependencies are captured. Use @importFrom _package_ _function_ when importing five (5) or fewer functions, and @import _package_ otherwise.
    • Function output is captured with a @return tag. Each output description should include output type, structure, and data specification (if applicable).
    • At least one (1) example is provided under an @examples tag.
  • Error Checking
    • Basic checks for all parameters should be included using stopifnot() or similar logic (e.g., stopifnot("dfInput is not a data frame" = is.data.frame(dfInput)))
    • Tests confirm that stopifnot() parameter checks are working as expected.
    • Tests confirm that the input data has required columns (if any).
    • Tests confirm that the output data has expected columns/structure.
    • Tests confirm intended functionality for each parameter.
    • Tests confirm that missing data in required columns is handled appropriately and errors/warnings are produced if needed.
  • Basic QC
    • Assessment has User Requirements + Qualification tests captured using qualification framework. A QC report is generated as expected and all checks pass successfully.
    • Code is well commented and easy to read/understand.
    • No file paths or other company-specific data are present.
    • Function called from non-tidyverse dependencies are called via ::.
    • devtools::check() passes with no errors/warnings/notes.
    • Package documents are up to date, and running devtools::document() does not change any files.
    • Codes use {tidyverse} best practices for standard data manipulation. If unclear, reviewer should start a discussion thread.
    • All new dependencies add significant value. If unclear, reviewer should start a discussion thread.
    • All GitHub Actions run with no errors.

@mattroumaya
Copy link
Contributor Author
mattroumaya commented Nov 9, 2022 •
edited
Loading

Protocol Deviation Assessment Checklist

  • Documentation
    • Function name captured in roxygen2 title (e.g., "Adverse Event Assessment")
    • Assessment purpose captured in roxygen2 description (e.g., "Evaluates adverse event (AE) rates to identify sites that may be over- or under-reporting AEs")
    • Input data requirements are captured in a dedicated roxygen2 details section under Data specification (#' @section Data specification, or # Data specification if storing data specification in a .md file).
    • Statistical methods and assumptions are captured in a dedicated roxygen2 details section under Statistical assumptions (#' @section Statistical assumptions, or # Statistical assumptions if storing statistical assumptions in a .md file). This section should link to the relevant Analyze_ function(s) for further details.
    • All function parameters are described with a @param tag. Each parameter description should include its name, type, purpose, usage details, default value (if applicable), requirement, and valid options (if applicable).
    • All external dependencies are captured. Use @importFrom _package_ _function_ when importing five (5) or fewer functions, and @import _package_ otherwise.
    • Function output is captured with a @return tag. Each output description should include output type, structure, and data specification (if applicable).
    • At least one (1) example is provided under an @examples tag.
  • Error Checking
    • Basic checks for all parameters should be included using stopifnot() or similar logic (e.g., stopifnot("dfInput is not a data frame" = is.data.frame(dfInput)))
    • Tests confirm that stopifnot() parameter checks are working as expected.
    • Tests confirm that the input data has required columns (if any).
    • Tests confirm that the output data has expected columns/structure.
    • Tests confirm intended functionality for each parameter.
    • Tests confirm that missing data in required columns is handled appropriately and errors/warnings are produced if needed.
  • Basic QC
    • Assessment has User Requirements + Qualification tests captured using qualification framework. A QC report is generated as expected and all checks pass successfully.
    • Code is well commented and easy to read/understand.
    • No file paths or other company-specific data are present.
    • Function called from non-tidyverse dependencies are called via ::.
    • devtools::check() passes with no errors/warnings/notes.
    • Package documents are up to date, and running devtools::document() does not change any files.
    • Codes use {tidyverse} best practices for standard data manipulation. If unclear, reviewer should start a discussion thread.
    • All new dependencies add significant value. If unclear, reviewer should start a discussion thread.
    • All GitHub Actions run with no errors.

Notes:

  • Now that NormalApprox is the default method, add unit test(s) for poisson method
  • Either add tests for nConfLevel or remove from function and hardcode for each assessment.
  • Add tests for strMethod == "qtl"

@mattroumaya
Copy link
Contribu 9E88 tor Author
mattroumaya commented Nov 9, 2022 •
edited by Zhongkai-Wang
Loading

Analyze Function Checklist - Kai

Functions:

  • Analyze_Fisher()

  • Analyze_Identity()

  • Analyze_NormalApprox()

  • Analyze_Poisson()

  • Analyze_NormalApprox_PredictBounds()

  • Analyze_Poisson_PredictBounds()

  • Documentation

    • Function name captured in roxygen2 title (e.g., "Adverse Event Assessment")
    • Assessment purpose captured in roxygen2 description (e.g., "Evaluates adverse event (AE) rates to identify sites that may be over- or under-reporting AEs")
    • Input data requirements are captured in a dedicated roxygen2 details section under Data specification (#' @section Data specification, or # Data specification if storing data specification in a .md file).
    • Statistical methods and assumptions are captured in a dedicated roxygen2 details section under Statistical assumptions (#' @section Statistical assumptions, or # Statistical assumptions if storing statistical assumptions in a .md file). This section should link to the relevant Analyze_ function(s) for further details.
    • All function parameters are described with a @param tag. Each parameter description should include its name, type, purpose, usage details, default value (if applicable), requirement, and valid options (if applicable).
    • All external dependencies are captured. Use @importFrom _package_ _function_ when importing five (5) or fewer functions, and @import _package_ otherwise.
    • Function output is captured with a @return tag. Each output description should include output type, structure, and data specification (if applicable).
    • At least one (1) example is provided under an @examples tag.

  • Error Checking

    • Basic checks for all parameters should be included using stopifnot() or similar logic (e.g., stopifnot("dfInput is not a data frame" = is.data.frame(dfInput)))
    • Tests confirm that stopifnot() parameter checks are working as expected.
    • Tests confirm that the input data has required columns (if any).
    • Tests confirm that the output data has expected columns/structure.
    • Tests confirm intended functionality for each parameter.
    • Tests confirm that missing data in required columns is handled appropriately and errors/warnings are produced if needed.

  • Basic QC

    • Assessment has User Requirements + Qualification tests captured using qualification framework. A QC report is generated as expected and all checks pass successfully.
    • Code is well commented and easy to read/understand.
    • No file paths or other company-specific data are present.
    • Function called from non-tidyverse dependencies are called via ::.
    • devtools::check() passes with no errors/warnings/notes.
    • Package documents are up to date, and running devtools::document() does not change any files.
    • Codes use {tidyverse} best practices for standard data manipulation. If unclear, reviewer should start a discussion thread.
    • All new dependencies add significant value. If unclear, reviewer should start a discussion thread.
    • All GitHub Actions run with no errors.

@mattroumaya
Copy link
Contributor Author
mattroumaya commented Nov 9, 2022 •
edited by Zhongkai-Wang
Loading

Data Transformation and Flagging Checklist - Kai

Functions:

  • Flag()

  • Flag_Fisher()

  • Flag_NormalApprox()

  • Flag_Poisson()

  • Transform_Count()

  • Transform_Rate()

  • Summarize()

  • Documentation

    • Function name captured in roxygen2 title (e.g., "Adverse Event Assessment")
    • Assessment purpose captured in roxygen2 description (e.g., "Evaluates adverse event (AE) rates to identify sites that may be over- or under-reporting AEs")
    • Input data requirements are captured in a dedicated roxygen2 details section under Data specification (#' @section Data specification, or # Data specification if storing data specification in a .md file).
    • Statistical methods and assumptions are captured in a dedicated roxygen2 details section under Statistical assumptions (#' @section Statistical assumptions, or # Statistical assumptions if storing statistical assumptions in a .md file). This section should link to the relevant Analyze_ function(s) for further details.
    • All function parameters are described with a @param tag. Each parameter description should include its name, type, purpose, usage details, default value (if applicable), requirement, and valid options (if applicable).
    • All external dependencies are captured. Use @importFrom _package_ _function_ when importing five (5) or fewer functions, and @import _package_ otherwise.
    • Function output is captured with a @return tag. Each output description should include output type, structure, and data specification (if applicable).
    • At least one (1) example is provided under an @examples tag.

  • Error Checking

    • Basic checks for all parameters should be included using stopifnot() or similar logic (e.g., stopifnot("dfInput is not a data frame" = is.data.frame(dfInput)))
    • Tests confirm that stopifnot() parameter checks are working as expected.
    • Tests confirm that the input data has required columns (if any).
    • Tests confirm that the output data has expected columns/structure.
    • Tests confirm intended functionality for each parameter.
    • Tests confirm that missing data in required columns is handled appropriately and errors/warnings are produced if needed.

  • Basic QC

    • Assessment has User Requirements + Qualification tests captured using qualification framework. A QC report is generated as expected and all checks pass successfully.
    • Code is well commented and easy to read/understand.
    • No file paths or other company-specific data are present.
    • Function called from non-tidyverse dependencies are called via ::.
    • devtools::check() passes with no errors/warnings/notes.
    • Package documents are up to date, and running devtools::document() does not change any files.
    • Codes use {tidyverse} best practices for standard data manipulation. If unclear, reviewer should start a discussion thread.
    • All new dependencies add significant value. If unclear, reviewer should start a discussion thread.
    • All GitHub Actions run with no errors.

@mattroumaya
Copy link
Contributor Author
mattroumaya commented Nov 9, 2022 •
edited
Loading

Workflow and Reporting Function Checklist

  • Get_Enrolled()

  • Make_Snapshot()

  • RunQTL()

  • SaveQTL()

  • Study_Assess()

  • Study_AssessmentReport()

  • Study_Report()

  • Study_Table()

  • Documentation

    • Function name captured in roxygen2 title (e.g., "Adverse Event Assessment")
    • Assessment purpose captured in roxygen2 description (e.g., "Evaluates adverse event (AE) rates to identify sites that may be over- or under-reporting AEs")
    • Input data requirements are captured in a dedicated roxygen2 details section under Data specification (#' @section Data specification, or # Data specification if storing data specification in a .md file).
    • All function parameters are described with a @param tag. Each parameter description should include its name, type, purpose, usage details, default value (if applicable), requirement, and valid options (if applicable).
    • All external dependencies are captured. Use @importFrom _package_ _function_ when importing five (5) or fewer functions, and @import _package_ otherwise.
    • Function output is captured with a @return tag. Each output description should include output type, structure, and data specification (if applicable).
    • At least one (1) example is provided under an @examples tag.

  • Error Checking

    • Basic checks for all parameters should be included using stopifnot() or similar logic (e.g., stopifnot("dfInput is not a data frame" = is.data.frame(dfInput)))
    • Tests confirm that stopifnot() parameter checks are working as expected.
    • Tests confirm that the input data has required columns (if any).
    • Tests confirm that the output data has expected columns/structure.
    • Tests confirm intended functionality for each parameter.
    • Tests confirm that missing data in required columns is handled appropriately and errors/warnings are produced if needed.

  • Basic QC

    • Assessment has User Requirements + Qualification tests captured using qualification framework. A QC report is generated as expected and all checks pass successfully.
    • Code is well commented and easy to read/understand.
    • No file paths or other company-specific data are present.
    • Function called from non-tidyverse dependencies are called via ::.
    • devtools::check() passes with no errors/warnings/notes.
    • Package documents are up to date, and running devtools::document() does not change any files.
    • Codes use {tidyverse} best practices for standard data manipulation. If unclear, reviewer should start a discussion thread.
    • All new dependencies add significant value. If unclear, reviewer should start a discussion thread.
    • All GitHub Actions run with no errors.

@Zhongkai-Wang
Copy link
Contributor

I'll QC Analyze and Data Transformation and Flagging

@mattroumaya
Copy link
Contributor Author
mattroumaya commented Nov 9, 2022 •
edited
Loading

Utility Function Checklist

  • CheckInputs()
  • ConsolidateStrata()
  • FilterData()
  • FilterDomain()
  • is_mapping_valid()
  • MakeStratifiedAssessment()
  • MakeWorkflowList()
  • MergeSubjects()
  • ParseWarnings()
  • RunStep()
  • RunStratifiedWorkflow()
  • RunWorkflow()

Functions listed above were reviewed without a formal checklist, but the functions and unit tests were reviewed, and tested with R code to check for any edge cases.

Nothing to report ✅

@mattroumaya
Copy link
Contributor Author
mattroumaya commented Nov 9, 2022 •
edited
Loading

Visualization Function Checklist

Functions:

  • Visualize_Scatter()
  • Visualize_Score()
  • Visualize_Workflow()

Functions listed above were reviewed without a formal checklist, but the functions and unit tests were reviewed, and tested with R code to check for any edge cases.

Nothing to report ✅

@mattroumaya
Copy link
Contributor Author

@Zhongkai-Wang - my review is complete! Let me know when you are all set, and I'll request review from Jeremy.

@Zhongkai-Wang
Copy link
Contributor

@mattroumaya - My review is complete as well! Only review note is test_Analyze_NormalApprox and test_Flag_NormalApprox need to be added. Everything else looks good!

@mattroumaya
Copy link
Contributor Author

Awesome, thanks @Zhongkai-Wang! I'll file an issue to add those tests.

@jwildfire all yours to review!

@jwildfire jwildfire changed the base branch from main to dev November 11, 2022 17:36
jwildfire
jwildfire approved these changes Nov 11, 2022
View reviewed changes
Copy link
Contributor
@jwildfire jwildfire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

@jwildfire jwildfire changed the base branch from dev to main November 11, 2022 17:43
@mattroumaya mattroumaya merged commit 4e0143e into main Nov 11, 2022
@mattroumaya mattroumaya mentioned this pull request Nov 11, 2022
Closed
@samussiah samussiah deleted the release-v1.3.0 branch December 19, 2022 20:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jwildfire jwildfire jwildfire approved these changes

Assignees

@mattroumaya mattroumaya

Labels
release
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@mattroumaya @Zhongkai-Wang @jwildfire @collleenmclaughlin @samussiah
156E
0