[Bioc-devel] package review help

[Robert M. Flight]

Regarding Cytoscape, at least, I know RCytoscape and categoryCompare use
active Cytoscape sessions during vignette builds, but the build maintainers
need to know about it. I also don't know if the review builds would have
access to that.

Robert

On Fri, Sep 30, 2016, 9:53 PM Vincent Carey <stvjc at channing.harvard.edu>
wrote:

> i would have comments on StarTrek.  if you would like me to be reviewer of
> that i can do it.
>
> a query on policy
>
> how do you propose to handle needlessly repeated code?
>
> the code given below is repeated many many times with slight variations for
> selected KEGG_path.  i would ask the author
> to implement DRY (don't repeat yourself), find a functional approach to the
> repeated element, and
> simplify.  i can imagine that damping enthusiasm of the contributor but I
> think it is worth holding back
> until such a thing is accomplished.  too meddlesome?
>
> if (KEGG_path=="Carb_met") {
> pathways.list <- keggList("pathway", "hsa")## returns the list of human
> pathways
> mer<-select_path_carb(Carbohydrate)
> common<-intersect(pathways.list,mer)
> lo<-list()
> for (i in 1:length(pathways.list)){
> if (length(intersect(pathways.list[[i]],common)!=0)){
> lo[[i]]<-pathways.list[[i]]
> names(lo)[[i]]<-names(pathways.list)[[i]]
> }
> }
> pathways.list<-lo[lapply(lo,length)!=0]
> pathway.codes <- sub("path:", "", names(pathways.list))
> a<-do.call("rbind", pathways.list)
> }
>
> Another issue the author seems to raise is the need for "open cytoscape
> session" for meaningful tests.
> I think this will never happen on the build system.  So the author has to
> emulate the cytoscape behavior
> perhaps with some static objects that cytoscape might return on
> interaction.
>
>
>
> On Fri, Sep 30, 2016 at 5:22 PM, Martin Morgan <
> martin.morgan at roswellpark.org> wrote:
>
> > On 09/30/2016 12:05 PM, Michael Lawrence wrote:
> >
> >> I have been chipping in here and there, but I'm not sure if I'm
> >> causing more confusion than help. I just select packages that interest
> >> me and contribute bite size pieces, but I would be happy to assume a
> >> more formal role. It takes very little of my time.
> >>
> >> One suggestion is that reviews should be incremental, i.e., provide
> >> obvious feedback first, let the package authors respond, then dig
> >> deeper for more detailed comments.
> >>
> >
> > Michael, I've found your comments / reviews really helpful. They are
> > generally on-target and constructive, and help spur the authors to think
> > about what they are doing. They do in some ways 'confuse' the issue (how
> is
> > the package author to know that the 'assignee' is the official reviewer?
> > are the people commenting on the package providing a consistent
> message?),
> > but definitely a plus. I encourage others to participate in the public
> > review process in this way, too.
> >
> > It would be great to hear from people who would like to take on the role
> > of assigned reviewer. I'd suggest you identify package(s) that would be
> > interesting to you, and send email to me. I'll arrange for you to become
> > the assigned reviewer, and provide basic instructions and guidelines. In
> > the future, you will be able to take on a package more directly.
> >
> > From the formal review process, incremental additional comments are not a
> > good way to go, because the package author can feel like they are on a
> > never-ending treadmill of requirements. Instead I think the formal review
> > should more or less set out a contract -- do these things and your
> package
> > will meet reviewer requirements for inclusion in Bioconductor. This makes
> > it harder / more time consuming to review the package, because there is
> > only the one chance to identify the most important points. Also, one
> needs
> > to follow through and confirm that yes, the appropriate changes were
> made.
> >
> > It will be interesting to adjust the public review process, especially
> > after the next release. For instance, one approach I like is to provide a
> > review with editable check boxes, with the package author editing the
> > review with information about commits, etc, that satisfy the concerns
> being
> > expressed. I don't really like the canned check-list in the joss link Tim
> > mentions; they point to important areas but seem too generic to lead to
> > constructive changes to individual packages.
> >
> > Martin
> >
> >
> >> Michael
> >>
> >> On Fri, Sep 30, 2016 at 8:49 AM, Kasper Daniel Hansen
> >> <kasperdanielhansen at gmail.com> wrote:
> >>
> >>> One of the advantages of the Github review process is open review.  We
> >>> have
> >>> some amount of packages submitted in the last moment (and I am guilty
> of
> >>> one of these).  Is help with the reviews needed?  If so, how do we know
> >>> where to concentrate?
> >>>
> >>> Kasper
> >>>
> >>>         [[alternative HTML version deleted]]
> >>>
> >>> _______________________________________________
> >>> Bioc-devel at r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>>
> >>
> >> _______________________________________________
> >> Bioc-devel at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>
> >>
> >
> > This email message may contain legally privileged and/or...{{dropped:2}}
> >
> >
> > _______________________________________________
> > Bioc-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
>
>
> --
>
> Vincent J. Carey, Ph.D.
> Professor of Medicine
> Channing Division of Network Medicine
> Brigham and Women's Hospital
> Harvard Medical School
> 181 Longwood Avenue
> Boston, MA 02115 USA
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

	[[alternative HTML version deleted]]