Open ya-wang-git opened 1 year ago
Ya @ywang-gilead et al., thank you for the initiative and, as previously discussed via e-mail, I think that a relaunch of the task view would be good to make it more active and dynamic again. Also, I think it's great to build on existing initiatives under the umbrella of the ASA and R Consortium. However, some more work is needed before we can move forward:
ExperimentalDesign
task view has an explicit list of packages for design of clinical trials and they suggest that this should be moved to the ClinicalTrials
task view. Do you concur with this list or would you resolve this differently? Explain your strategy. My impression is that the issues are similar for Pharmacokinetics
where there could be more overlap while Survival
and MetaAnalysis
are separated a bit more clearly.Ratings: Task views should not rate the packages or endorse certain "best" packages but rather give an overview of what is available. A bit of emphasis to the more important packages can be given in two ways: (1) The most important packages can be flagged as "core" packages. (2) In the information text the more important packages can be listed first in the respective sections.
You don't have to respond to my comments right away but we can also wait for some more comments from my fellow CRAN Task View Editors @rsbivand @eddelbuettel @tuxette
Also I'm tagging here the maintainers of the other task views mentioned in case they want to add to the discussion: @ugroempi @tylermorganwall @aallignol @deweyme @wviechtb @billdenney
I don't know the specific quality metrics being considered. But, I have seen the quality metrics mentioned in multiple ways for R packages used in pharmaceutical development. The ways that I've seen them used align with some R core principles, and they are not necessarily ranking or endorsement but they are exposing objective quality metrics such as test coverage percent, maintenance activity, and duration of time on CRAN.
As it relates to the Pharmacokinetics view, I would assume that the Clinical Trials view would reference the Pharmacokinetics view. And, I would assume that there would be little overlap between packages.
Dear All
Most of the packages in the MetaAnalysis CTV could, in principle, be used for meta-analysis of clinical trials but none of them is restricted to such designs. So I would suggest a cross-reference from each to the other would suffice.
As far as quality is concerned I have not included a couple of packages in the past. One did not really do what it said on the tin and at least one more I completely failed to understand what it was claiming to do even after reading the entire manual. Apart from that they all go in and I leave it up to the user to check against their own criteria.
Michael
On 26/10/2023 02:51, Achim Zeileis wrote:
Ya @ywang-gilead https://github.com/ywang-gilead et al., thank you for the initiative and, as previously discussed via e-mail, I think that a relaunch of the task view would be good to make it more active and dynamic again. Also, I think it's great to build on existing initiatives under the umbrella of the ASA and R Consortium. However, some more work is needed before we can move forward:
The package inclusions/exclusion guidelines are a too vague. You say that you want "more hierarchies" but it is unclear to me what is the intended structure of the task view. And how will this help to determine whether a package should be included in the task view or not.
Similarly, more concrete discussion of how to handle the overlap with other task views is needed. For example, the |ExperimentalDesign| task view has an explicit list of packages for design of clinical trials and they suggest that this should be moved to the |ClinicalTrials| task view. Do you concur with this list or would you resolve this differently? Explain your strategy. My impression is that the issues are similar for |Pharmacokinetics| where there could be more overlap while |Survival| and |MetaAnalysis| are separated a bit more clearly.
You indicate that you want to move in the direction of labeling the quality of R packages, both within this task view and even across task views. Note that this is not within the scope CRAN Task Views. As the Documentation https://github.com/cran-task-views/ctv/blob/main/Documentation.md says: /"The views are intended to have a sharp focus so that it is sufficiently clear which packages should be included (or excluded) - and they are not meant to endorse the "best" packages for a given task"./ The Proposal guidelines https://github.com/cran-task-views/ctv/blob/main/Proposal.md explain this in a bit more detail:
Ratings: Task views should not rate the packages or endorse certain "best" packages but rather give an overview of what is available. A bit of emphasis to the more important packages can be given in two ways: (1) The most important packages can be flagged as "core" packages. (2) In the information text the more important packages can be listed first in the respective sections.
Regarding the maintainers: First, there has to be a single principal maintainer who is the principal contact for the task view. Thus, it's not possible to have two principal maintainers. Second, having several people from the openstatsware working group is fine because this is already a rather diverse intiative across companies. But rather than having all five contributors from the openstatsware group, I think it would be good to have some outside co-maintainers as well, ideally also including someone from academia.
You don't have to respond to my comments right away but we can also wait for some more comments from my fellow CRAN Task View Editors @rsbivand https://github.com/rsbivand @eddelbuettel https://github.com/eddelbuettel @tuxette https://github.com/tuxette
Also I'm tagging here the maintainers of the other task views mentioned in case they want to add to the discussion: @ugroempi https://github.com/ugroempi @tylermorganwall https://github.com/tylermorganwall @aallignol https://github.com/aallignol @deweyme https://github.com/deweyme @wviechtb https://github.com/wviechtb @billdenney https://github.com/billdenney
— Reply to this email directly, view it on GitHub https://github.com/cran-task-views/ctv/issues/59#issuecomment-1780291870, or unsubscribe https://github.com/notifications/unsubscribe-auth/AW7BJ5HIJZE2QXFCWQAKUH3YBG62JAVCNFSM6AAAAAA6QHDST6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBQGI4TCOBXGA. You are receiving this because you were mentioned.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Virus-free.www.avg.com http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-- Michael
Thank you for the proposal. I have not much to add to @zeileis 's comments. There might be a minor overlap with Epidemiology as well.
Thanks a lot for the comments. We have incorporated them into our revised proposal as follows.
This task view aims to collect information on R packages for clinical trial design, monitoring, analysis and reporting.
I have no general objections to the proposal. As co-maintainer of the Meta-analysis task view, I will just reiterate what @deweyme already touched on. It isn't really clear to me how one would define an R package for meta-analysis that is "designed for clinical trials". The same applies to the potential overlap with other task views (like ExperimentalDesign and Survival and 'Longitudinal data analysis' also overlaps with the MixedModels task view), that is, how does one determine whether a package from these other task views is designed for clinical trials?
@ywang-gilead : Thank you for your answer and the clarification / corrections. I think that they cover most of @zeileis 's comments. Additional remarks:
Your choices for core packages sound relevant but you still have to clarify inclusions/exclusion guidelines (probably by a short paragraph at the beginning of the task view). In relation with @wviechtb 's comment, I agree that it will not always be easy to define if an R package is a better fit for ClinicalTrial or for some other related task view. However, linking the other task view might be a solution (in combination with duplicating some of the most important packages if necessary). For instance, https://cran.r-project.org/web/views/OfficialStatistics.html#imputation has a link, a short discussion, and highlights two particularly relevant packages for both OfficialStatistics and MissingData.
Your proposal for themes should indeed clarify the task view. Depending on the number of packages in each theme, note that they can just be bullet "titles" in a list, like in https://cran.r-project.org/web/views/SpatioTemporal.html (in order to not overload the task view with many subsections).
Your proposal for a “Getting Started” section at the beginning of the task view is OK with me but be careful that the main point of the task view is to provide information on CRAN packages (so do not overload it with material on the topic). Also, as already pointed by @zeileis , this section should not sound like it endorses the "best" packages. For instance, https://cran.r-project.org/web/views/FunctionalData.html has a similar section, which presents the most general packages for the topic.
As far as I can tell, you complied to the initial request on maintainers.
I let @zeileis @rsbivand @eddelbuettel react as well but I think that the proposal is interesting and that you can go on working on it.
Hi @ywang-gilead,
We were directed here through our proposal for a new task view for the pharmaverse collection of packages, which we've submitted here. Per @zeileis, the suggestion is that may be logical to fold our collection of packages into the updates relevant to this proposal.
We've drafted the task view, which you can additionally review here and see why we've suggested a specific scope of packages.
Could you please share your thoughts on if/how you see value in combining these packages within the ClinicalTrials task view?
Hi @mstackhouse ,
Thanks a lot for the additional information. I'm thinking of scheduling a meeting for us (CTV ClinicalTrials maintainers and pharmaverse maintainers) to discuss the possibility to combine these two task views and how we could collaborate. I will send out an email to everyone and hopefully we can find some time next week that works for all of us. Does that sound good to you?
Just wanted to leave a note here that both groups of maintainers met as a team. We mutually decided that right now it's better to keep our proposed task views separate and reassess in the future if it makes sense to combine them. We will continue to address feedback in #60
Hi, I am not sure that the current Task View concept as a narrative list of packages for a specific scope is the best solution to inform users of relevant packages and whether this will scale with the increasing number of packages. I would suggest to allow package developers to add a field in the description file which says in which task views their package should be listed. The Task view could then be compiled automatically, eg the package name and description (oneliner) could be automagically extracted from the Description file. The Task view page/table could also show additional quality attributes for each package to guide users (first release, last release, number of users, user rating, author credibility, ...).
Dear Wilmar
In the MetaAnalysis CTV we try to provide some structure to the list of packages. It is hard to see how the software you propose would know which section(s) the new package might appear in. Several of the packages appear in more than one section. If we abandon the idea of curating and organising the list it will become much harder for people to find the relevant package which might fit their needs.
Michael
On 12/03/2024 15:35, Wilmar Igl wrote:
Hi, I am not sure that the current Task View concept as a narrative list of packages for a specific scope is the best solution to inform users of relevant packages and whether this will scale with the increasing number of packages. I would suggest to allow package developers to add a field in the description file which says in which task views their package should be listed. The Task view could then be compiled automatically, eg the package name and description (oneliner) could be automagically extracted from the Description file. The Task view page/table could also show additional quality attributes for each package to guide users (first release, last release, number of users, user rating, author credibility, ...).
— Reply to this email directly, view it on GitHub https://github.com/cran-task-views/ctv/issues/59#issuecomment-1991938918, or unsubscribe https://github.com/notifications/unsubscribe-auth/AW7BJ5CNZJ4RUTTY6T5ZFSTYX4OFVAVCNFSM6AAAAAA6QHDST6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJRHEZTQOJRHA. You are receiving this because you were mentioned.Message ID: @.***>
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Virus-free.www.avg.com http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-- Michael
Wilmar, thanks for your feedback. There are indeed different potential solutions for generating topic-related lists of packages - with differents strengths and different drawbacks. As Michael already explained, CRAN Task Views aim to be curated lists with a sharp focus. When package maintainers can self-select their package into the task views, this sharp focus would likely be lost. Both because some less relevant packages would be included - but also because some very relevant packages would not be. To learn more about the ideas and strategies behind the CRAN Task View Initiative, you can have a look at this paper: doi10.48550/arXiv.2305.17573:
Hi @ywang-gilead and col. We were very close to a final version for this proposal: do you want to implement the last suggested changes (see comments since your last proposal) so that we can proceed to the publication?
Hi @tuxette, we will implement the last suggested changes and provide a draft task view for review.
Prior to this proposal we have reached out to the CRAN task view editors regarding a possible update of the existing ClinicalTrial task view. They advised using this issue to propose a relaunch that can then be discussed.
Scope
This task view aims to collect information on R packages for clinical trial design, monitoring, analysis and reporting.
Packages
Overlap
Maintainers