How many packages have you submitted for review?
How many packages have you reviewed?
For each of the packages you reviewed, how many hours would you estimate your initial review (not including follow-up) took? (Separate by commas)
What was the best thing about the software review process?
What was the worst thing about the software review process?
What was one thing you learned from the software review process?
|3/3/2016 19:38:55||Andy Teucher||0||1||5|
Meeting' people in the R community who I didn't know before, and strengthening ties to the community. Learning new R programming techniques and practices.
The time it took, and having an effective back and forth after the review was over.
|3/3/2016 19:41:26||Oliver Keyes||0||1||1||The authors!|
It wasn't immediately clear what to do
RefClasses are the devil
|3/3/2016 19:41:36||Lincoln Mullen||1||1||3|
Very detailed comments on how to improve the interface
I'm not sure the person whose package I reviewed is actually going to make the changes and complete the on-boarding process. I'd be very happy to be proven wrong about that.
|3/3/2016 22:43:52||Karthik Ram|
0 but I also work here and skip this step!
I learn a lot from closely reading other people's code and it is hard to do when I'm not forced to review so closely.
It's super time consuming to read code closely
|3/4/2016 3:32:35||Robin Lovelace||1||1||3|
It was open and I could ask questions to the author/others in real time
|Lack of time!|
A new proposed framework for storing package data (datastorr)
|3/4/2016 4:07:10||Maëlle Salmon||1||0|
That it was both serious and nice (supportive)
The readme could include emojis to look nicer, and arguments for submitting? This was the worst thing, so I guess I was happy with the process.
Not only one, several ones for R programming including the fact that learning the difference between NSE/SE in dplyr is not something to put off until later, it's something I could tackle. Moreover I learnt that code review is the best thing that can ever happen to your package!
|3/4/2016 9:48:41||Noam Ross||0||4||3.5, 4, 8, 8|
I get to see different approaches to package design
It takes a bunch of time
|How to use assertions|
|3/4/2016 10:09:16||Rich FitzJohn||0||2||2,2|
The constructive way everyone joined in. I'm a big fan of non-adversarial review so it was nice to see that working. (Disclosure: some of the current design is my fault, coming from a conference call that the rOpenSci leadership team had).
More things to do. Signing up for stuff always feels fine, but there's no getting away from writing up a bit of a report and that's a drag. I don't see a way around that.
Learned is probably the wrong word, so perhaps appreciated is better. I got a better appreciation of how hard it is to get _all_ of someone else's package into my head at once, so I could see where they were going and why. Differences in how people delineate functions, collect them into files, name things, etc all accumulate.
|3/4/2016 11:52:48||François Michonneau||1||0||NA|
Having an extra pair of eyes on the code is always a good idea. Too often, I find a package whose description seems to be interesting to me, but when I start reading the README, peruse through the vignettes, it's written in too technical, narrow terms that it doesn't seem worth the time investment to learn how to use it. To me, one of the major benefits of the review process is to make sure that the documentation can easily be understood by someone who is new to the package. For people who are newer to package development, the review system really helps navigating the intricacies of the process and highlight best practices.
|I can't think of any.|
The use of @template in roxygen documentation.
I don't really see myself writing another serious package without having it go through code review.
|3/4/2016 16:48:29||Scott Chamberlain||1||2||2,3|
Github flow made it very pleasant, esp. compared to journal reviews. The back and forth is especially productive, rather than the traditional journal review where there's months between the back and forth
As discussed in the forum, we could make it easier for reviewers to communicate so that there isn't duplicated effort.
Not a specific thing, but great to see how other people structure their code, functions, inputs, outputs, etc.
|3/5/2016 9:00:31||Kyle Bocinsky||1||0||NA|
It was *very* thorough. The review process taught me a lot about different tools available for making my code more robust and resilient to future changes.
For a lot of people in the scientific community, coding packages still feels more like community service than a professional obligation. It's taken me way longer than I intended to respond to all of the reviewer's comments.
I had never heard of continuous integration, and it is fantastic!
|3/7/2016 13:56:00||david winter||1||0||NA|
I found it very valuable to learn best practices for coding, and do "see" the package from a native perspective
I had nothing but positive experiences (note I have only been reviewed. i.e. I haven't acted as a reviewer)
How to properly deal with @import and @importFrom in docs/DESCRIPTION
|3/7/2016 17:35:14||Lauren Yamane||0||1||4-5?|
Playing around with the database (FishBase) for the first time; forcing myself to go on to GitHub, which I really should be doing.
Since I haven't ever developed a package or reviewed one, I wasn't sure what information would be useful to the developers.
What the review process might look like for a package
|3/7/2016 17:45:00||Andy South||1||0|
Reducing uncertainty about whether what I was producing was useful/'good'/not being done already/likely to be well received.
So far, although I'm not done yet, there isn't anything I would say that was 'worst'. A tiny suggestion is that I received two great reviews, then (following journal experience) I expected an editor to say yay or nay and collate the responses. It's fine that this didn't happen but it might be useful in the 'guidance for submitters' to make it clear that they can get started on addressing reviewers comments once they have come in. What happened with me is that because I was expecting something else I didn't do it straight away and it then got buried under other tasks (which to be honest may have happened anyway).
Current, and possibly future, good practice for dealing with large datasets in packages.
|3/10/2016 0:16:24||Julia Gustavsen||2||10, 3|
learning about new packages and seeing the editorial input. Also, seeing that my suggestions were valued and quickly incorporated.
One package was really hard to install and that took a lot of time.
I've learned more about package development best practices (especially including other packages). Also new approaches to retrieving data.
|3/23/2016 18:55:49||Peter Meißner||1||0||-|
To get code review ... to get another set of eyes commenting on design and implementation - getting assuring/improving feedback... to get comments from very R-skilled persons