[Bioc-devel] package review help

[Martin Morgan]

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}}