Closed maelle closed 1 year ago
That should be pretty easy to automate. The only real Q would be when? Putting that in checks would be a bit at odds with the general intentions of {pkgcheck}. "When both reviewers are assigned" would seem like a good point. We could get buffy to ping another {roreviewapi} end point to do that check, and dump a note if it fails.
good idea! If I were to write the code for that new roreviewapi thing, where would I start? :nerd_face:
A separate R file called something obvious like "peer-review-badge". Get the functionalty working first, and then just add a new plumber endpoint to call it. The README contents are not grabbed by any function at the moment, so you'll need to start a new readme_contents()
function or whatever to get that. Plus general approach there remains not to presume GitHub is always the place, and at least allow a couple of alternative re-maps to other host services.
Re-opening because the changes i implemented cause the roreviewapi
package to fail tests. The only way this can be tested is by reverting to a stand-alone "has_readme_badge" function which returns a single value, and which is exported.
Currently the peer-review badge Markdown is mentioned when editors use
@ropensci-review-bot seeking reviewers
. That command only changes the issue label and posts the Markdown code for the badge. It is easy to forget, and even if it is posted, the authors could forget to add the badge. I tend to see missing badges when I prepare the newsletter as the "new packages" lack any mention of software review when their README does not feature the badge.Where else in the process could we remind of the badge? When both reviewers are assigned?
I feel like it should not be added to the checklist at approval.
Should approval however trigger a check with a warning if the badge has not been added?
Thoughts @mpadge?