Skip to content
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.

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

Package goals for (the rest of) 2023 #298

Open
emilliman5 opened this issue Jun 9, 2023 · 2 comments
Open

Package goals for (the rest of) 2023 #298

emilliman5 opened this issue Jun 9, 2023 · 2 comments
Assignees
Labels
Discussion Looking for input Strategy Strategy discussion

Comments

@emilliman5
Copy link
Collaborator

Here are my thoughts on totential goals/strategy for 2023 (or next 1 year). Any and all input is welcome. This initial list is meant to start the discussion.

  1. Consistency and completeness: implement assessment/metrics for as many ref_source types as possible
  2. Implementation paradigm for 3rd party packages: see Add security assessment via {oysteR} #272
  3. Cohort metrics implementation and rollout, scoring a set of packages in its totality: Dev/cohort assess #248, Define methods for cohort metric class #199 Define a class for a cohort of R packages and its metrics  #198 Strategy for cohort metrics  #174 Package assessment challenge example: labeling -> ggplot2 #160
  4. Enable ease of use: wrapper function Consider adding a wrapper function #276 , expand ref_source types (e.g. PositPM, pharmaVerse), reporting/output functionality

Please feel free, to add any priorities you think should be considered, or comment on the ones suggested here.

@AARON-CLARK
Copy link
Contributor

Agree! It's a good list.

  1. Consistency and completeness: implement assessment/metrics for as many ref_source types as possible

Created a few issues we discussed that are associated with # 1. Specifically, #300, #299, and #294. #296 is sort of related... it's within the same family.

@AARON-CLARK
Copy link
Contributor

I also love # 4 proposed by @parmsam-pfizer: helping users (especially newbies) get to the risk score faster with a wrapper function. I think implementing #299 will help take away some of the pain points / reservations associated with with a wrapper function since the pkg_ref cache would be populated with the maximum assessment info, presenting a risk score not burdened with the drawbacks of any one pkg_ref source type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Looking for input Strategy Strategy discussion
Projects
None yet
Development

No branches or pull requests

7 participants