hello @noamross 
- hm, interesting about the diverse reviewers. Though I’m not sure that quite describes the dynamic we had on our review, I can certainly see why that was/is an intention in choosing reviewers
- re: finding new reviewers, why not ask previous reviewers to nominate people they know? The network would then grow very quickly
- Indeed i’d seen your example and I’d considered emulating it. But then again, it’s not always a simple atomic change – sometimes more of a redesign is what the reviewer wants to suggest. Perhaps some guidelines about when and how to do a PR would be a good addition to the onboarding/ reviewing guides, rather than leaving it all up to taste.
An additional benefit is that, if changes as a result of the review are
done on the same branch, they will be visible in the review.
yes, that’s what i’d been thinking. I guess I was imagining something like this:
- ropensci creates a new, empty repo for the onboarding package
- adds a file to provide some boilerplate – perhaps the ropensci logo added to the top of README or something
- package author adds that repo as a remote, fetches and merges (so that there is at least 1 commit in common between the ropensci repo and their local version)
- author creates branch
onboarding, containing everything in the package - author pushes
onboardingbranch toropensci/coolnewpackage, creates pull request to master branch ofropensci/coolnewpackage - reviewers comment on the diff and on the PR
the review would be over when the PR is merged into master. Would that work? (perhaps that’s what you were thinking too – it just sounded like you meant conducting all this in the onboarding repo, which wasn’t quite what i had in mind so i wanted to clarify)