Interacting with Whedon¶
@whedon on GitHub, is our editorial bot that interacts with authors, reviewers, and editors on JOSS reviews.
@whedon can do a bunch of different things. If you want to ask
@whedon what it can do, simply type the following in a JOSS
# List all of Whedon's capabilities @whedon commands # Assign a GitHub user as the sole reviewer of this submission @whedon assign @username as reviewer # Add a GitHub user to the reviewers of this submission @whedon add @username as reviewer # Re-invite a reviewer (if they can't update checklists) @whedon re-invite @username as reviewer # Remove a GitHub user from the reviewers of this submission @whedon remove @username as reviewer # List of editor GitHub usernames @whedon list editors # List of reviewers together with programming language preferences and domain expertise @whedon list reviewers # Change editorial assignment @whedon assign @username as editor # Set the software archive DOI at the top of the issue e.g. @whedon set 10.0000/zenodo.00000 as archive # Set the software version at the top of the issue e.g. @whedon set v1.0.1 as version # Open the review issue @whedon start review EDITORIAL TASKS # All commands can be run on a non-default branch, to do this pass a custom # branch name by following the command with `from branch custom-branch-name`. # For example: # Compile the paper @whedon generate pdf # Compile the paper from alternative branch @whedon generate pdf from branch custom-branch-name # Remind an author or reviewer to return to a review after a # certain period of time (supported units days and weeks) @whedon remind @reviewer in 2 weeks # Ask Whedon to do a dry run of accepting the paper and depositing with Crossref @whedon recommend-accept # Ask Whedon to check the references for missing DOIs @whedon check references # Ask Whedon to check repository statistics for the submitted software, for license, and # for Statement of Need section in paper @whedon check repository EiC TASKS # Flag submission for editoral review, due to size or question about being research software @whedon query scope # Invite an editor to edit a submission (sending them an email) @whedon invite @editor as editor # Reject a paper @whedon reject # Withdraw a paper @whedon withdraw # Ask Whedon to actually accept the paper and deposit with Crossref # (supports custom branches too) @whedon accept deposit=true
@whedon’s functionality can only be used by the journal editors.
Assigning an editor¶
Editors can either assign themselves or other editors as the editor of a submission as follows:
@whedon assign @editorname as editor
Inviting an editor¶
Whedon can be used by EiCs to send email invites to registered editors as follows:
@whedon invite @editorname as editor
This will send an automated email to the editor with a link to the GitHub
Adding and removing reviewers¶
Reviewers should be assigned by using the following commands:
# Assign a GitHub user as the sole reviewer of this submission @whedon assign @username as reviewer # Add a GitHub user to the reviewers of this submission @whedon add @username as reviewer # Remove a GitHub user from the reviewers of this submission @whedon remove @username as reviewer
assign command clobbers all reviewer assignments. If you want to add an additional reviewer use the
Starting the review¶
Once the reviewer(s) and editor have been assigned in the
pre-review issue, the editor starts the review with:
@whedon start review
If a reviewer recants their commitment or is unresponsive, editors can remove them with the command
@whedon remove @username as reviewer. You can also add new reviewers in the
REVIEW issue, but in this case, you need to manually add a review checklist for them by editing the issue body.
Setting the software archive¶
When a submission is accepted, we ask that the authors create an archive (on Zenodo, figshare, or other) and post the archive DOI in the
REVIEW issue. The editor should add the
accepted label on the issue and ask
@whedon to add the archive to the issue as follows:
@whedon set 10.0000/zenodo.00000 as archive
Changing the software version¶
Sometimes the version of the software changes as a consequence of the review process. To update the version of the software do the following:
@whedon set v1.0.1 as version
Accepting a paper (dry run)¶
Whedon can accept a paper from the review issue. This includes generating the final paper PDF, Crossref metedata, and depositing this metadata with the Crossref API.
JOSS topic editors can ask for the final proofs to be created by Whedon with the following command:
On issuing this command, Whedon will also check the references of the paper for any missing DOIs. This command can be triggered separately:
@whedon check references
Whedon can verify that DOIs resolve, but cannot verify that the DOI associated with a paper is actually correct. In addition, DOI suggestions from Whedon are just that - i.e. they may not be correct.
Accepting a paper (for real)¶
If everything looks good with the draft proofs from the
@whedon accept command, JOSS editors-in-chief can take the additional step of actually accepting the JOSS paper with the following command:
@whedon accept deposit=true
This command is only available to the JOSS editor-in-chief, or associate editor-in-chiefs.