Open lwasser opened 3 months ago
Just to be clear about the case with the rdata package:
What happened in the rdata package case is that the API was considered stable by the author (me), given that it provided a useful and complete functionality: reading binary .rda and .rds files in Python. I did not expect to do any big change to it, as that functionality covered my use cases. However, as it happens in open-source software, a user wanted to be able also to do some features that fit perfectly in the package, and thus proposed several PRs during and after the review, that is:
Given that these features were very useful additions to the package, I though it was better to wait for them to be merged before submitting it to JOSS, and to propose that author to coauthor the JOSS paper. Of course, that would mean that there are some PRs not included in the pyOpenSci review, so fast-tracking might not be possible. If that is the case I would be happy to let the JOSS reviewers re-review the code (or just the diff, as they prefer).
@vnmabus i hear you. the problem is that this is still a review process. It's too hard to ask a review team to review a moving target (ie an API that is evolving and changing).
Our process:
My understanding from your comment here is that things got busy for you (i totally get it!). And then you decided to wait to submit to JOSS until a pr was merged. I totally understand the reasoning it just conflicts with our process.
That approach conflicts with our process because JOSS accepts our review as theirs when they publish - they don't re-review. A rereview of code is not a part of our fast track partnership. As such we are now potentially fast tracking new code that hasn't' been reviewed.
JOSS can do another full review. but that is also more resources (reviewer time) invested in reviewing a package! It's hard to find reviewers as they are volunteers and are busy too. So the ideal scenario is that there is one single review process on a somewhat stable API with 2 reviewers. Then things are fast tracked by JOSS. I hope that makes sense.
Yes, I totally get it. What I meant, mainly, is that the author may think 2 holds and submit it, but that can change as other people propose PRs with new functionality. Thus it is not really possible to promise that the API will not change in the future, even if the author thinks that.
Specifically this is a discussion happening in the rdata package review where the author is making changes in between the package being submitted , accepted and then fast tracked to joss. we need to clarify in our policies that