pkp-lib
pkp-lib copied to clipboard
pkp
Permit declined reviews to be reinitiated
Describe the problem you would like to solve Example: Our editors need a way to respond to reviewers who decline reviews, but later indicate that they are willing to undertake it.
Describe the solution you'd like After the review is declined by the reviewer, an editor should be able to either reset its status (so the reviewer can accept it themselves) or accept it on the reviewer's behalf.
Who is asking for this feature? @ajnyga :)
Migrated from https://github.com/pkp/pkp-lib/issues/2508#issuecomment-494640952
I also support this feature request!
With the stipulation it also works vice-versa, in that if an editor accepts but later decides they cannot follow through the editor can respond to/un-assign them
Just adding a +1 to this feature request, one of our journals requested this feature today.
Adding a similar requested from a hosted client as well. For additional details of the use case: a reviewer declined, stating they can't make the review due date, but the editor actually has flexibility with the timelines and can accommodate the reviewer's schedule.
Imo either permit reinviting or communicate that reinviting reviewers is not possible better - I keep getting requests from editors who think they are doing something wrong, when in fact it is by design.
As an editor, right now I have need of changing a reviewer's decline decision to Accepted. But I see this is not (yet) possible in OJS 3 without database access (which I do not have).
Hi all -- in recent releases reviewers can be cancelled and reinstated, but reinstating a declined review does not currently reset the review request.
I propose the following workflow:
- A reviewer accidentally declines a review.
- The reviewer contacts the editor, wishing to undo this action.
- The editor cancels the review.
- The editor reinstates the review, contacting the reviewer in the process. This resets the decline/accept decision so that reviewer can choose again.
Would this workflow be OK? (@librariam and @pmangahis in particular?)
@asmecher this sounds good, I just wonder in this case which email template will be used to let the reviewer choose again? Right now you can cancel and reinstate after the reviewer has already accepted and even submitted a review. Those scenarios call for different templates - unless we could use one that generic enough and just includes a direct review link?
BTW, out of curiosity I just tested in the 3.3 sandbox which template is used on reinstate and it's blank.
@librariam, I'm not sure about the admin history of the sandbox, but here's the template that comes up for me:
@NateWr PRs to review
pkp-lib --> https://github.com/pkp/pkp-lib/pull/8242 ojs --> https://github.com/pkp/ojs/pull/3538
I will start testing it for OMP as we have Internal Review system, so some extra modification may require for OMP .
@NateWr updated PRs
pkp-lib --> https://github.com/pkp/pkp-lib/pull/8242 ojs --> https://github.com/pkp/ojs/pull/3538 omp --> https://github.com/pkp/omp/pull/1201
Hi everyone, @touhidurabir has just about implemented this but we still need to answer a question: what exactly is the editor doing when they permit a declined review to be reinstated? Are they re-sending the review request to the reviewer, and the review should accept/decline the assignment again? Or are they simply changing the reviewer's decision from decline to accept, and the reviewer should move to the "completing review" step?
This matters because of how we will communicate this action in the UI and the message in the email that will be sent to the reviewer. For example, if we are re-sending the request to the reviewer, we would have an email like this:
Dear Julie Janssen,
You have recently declined our request for you to review a submission, Sodium butyrate improves growth performance of weaned piglets during the first period after weaning, for Journal of Public Knowledge. We would like to request you to reconsider that decision and we hope that you are still able to conduct the review.
If you are able to assist with this journal's review process, you can login to the journal to view the submission, upload review files, and submit your review request.
If you have any questions, please contact me.
Kind regards,
{$signature}
However, if the editor is accepting this review request on the reviewer's behalf, then the email would need to be different. And we would probably need to log that an editor changed a reviewer's response from decline to accept.
Does anyone have some insight here? Especially pinging @librariam, @pmangahis, and @diegoabadan, but I'd invite comments from anyone who has been active on this issue.
Hi @NateWr. Patricia and I and the team chatted about this today. It looks like both scenarios are possible, but it would be preferable to resend an invitation to the reviewer so they could accept the privacy statement and check the review deadlines – which it seems they won’t be able to if the editor were to accept on their behalf.
IMO it's important that the reviewer be the one to accept/decline the invitation, rather than letting the editor do it on their behalf. I would favour something that reverts a reviewer's previous Decline and invites them to Accept the review themselves.
it would be preferable to resend an invitation to the reviewer so they could accept the privacy statement and check the review deadlines
IMO it's important that the reviewer be the one to accept/decline the invitation, rather than letting the editor do it on their behalf
In that case, should we let editor to sent the request to reconsider it only once or as many time as the editor want to ? current PR implementation let the reconsider request to sent only once as that seems like an appropriate behaviour rather than sending it many times if the reviewer keep declining it . So basically if the reviewer declined the reconsider request/invitation , no more reconsider request/invitation can be sent . But would like to know if we want to make it more flexible and such requirement(multiple reconsider request/invitation if reviewer keep declining it) may seems necessary .
Thanks @librariam and @asmecher, that makes sense.
should we let editor the sent the request to reconsider it only once or as many time as the editor want to ?
I'd say as many times as they want. An abusive editor is a human problem and one that should be resolved within the editorial team. Editors can already create users and do other potentially abusive things as much as they want.
@touhidurabir in light of these comments, can we update the naming of the classes and the terminology used in buttons and emails to reflect "Resend Request". Right now, it's written around language like "Reconsider Reviewer", but it's really the reviewer who is reconsidering. So I think from an editor's perspective the action that's happening is to resend the request to review. Once you've taken a pass at that, I'll do a final review and copyedit the email. :+1:
Agree with comments from @librariam and @asmecher -- scenarios for us where this has come up are (1) when reviewer has accidentally declined (2) when reviewer has declined because of logistical reasons (e.g. timeframe) that were able to be adjusted So I think that allowing the editor to resend the request as many times as they want is the best and clearest solution, and agree with terminology proposed by @NateWr . Thanks all!
@NateWr PRs to review
pkp-lib --> https://github.com/pkp/pkp-lib/pull/8242 ojs --> https://github.com/pkp/ojs/pull/3538 ui-library --> https://github.com/pkp/ui-library/pull/215
Once we finalize the changes for the OJS, I will port the changes for OMP .
@nate PR updates to review
pkp-lib --> https://github.com/pkp/pkp-lib/pull/8242 ojs --> https://github.com/pkp/ojs/pull/3538 ui-library --> https://github.com/pkp/ui-library/pull/215
@NateWr OMP PR updated . Final PRs
pkp-lib --> https://github.com/pkp/pkp-lib/pull/8242 ui-library --> https://github.com/pkp/ui-library/pull/215 ojs --> https://github.com/pkp/ojs/pull/3538 omp --> https://github.com/pkp/omp/pull/1201
if test pass, it's good to merge.
Hello Everyone,
Our attempt to redo the Submission Lists (#7495), often leads us through rabbit holes we didn't expect to glide through. One such rabbit hole came when we were working on redoing the review assignment details and progress trackers (#4172). Currently in the system, if the reviewer declines the invitation and or its overdue, the editor has an opportunity to resend the review request. On resending the review request however, it shows no other data other than the tag that the request has been resent. Even the due date remains unchanged even if it was months ago.
The dates can be modified through edit due date however the information the editor wants to see to manage the review and the cycle of a manuscript seems a bit shorthanded at this moment
Proposal
When resending the review request, it should allow to set a due date for the request resent and treat it as a new request sent inspite the indication on the tag that states Request Reshared. I think this will help to effectively manage the workflow and give the editors the correct data points. With new request I mean that the countdown to show the due date and indicate overdue when the due date is passed.
@jardakotesovec please cover anything you think I might have missed
@Vitaliy-1 can you review the PRs
pkp-lib --> https://github.com/pkp/pkp-lib/pull/9896 ojs --> https://github.com/pkp/ojs/pull/4246 [TEST ONLY]
This is for the additional enhancement proposed at https://github.com/pkp/pkp-lib/issues/4789#issuecomment-2014034378
@touhidurabir, sorry for the late reply. I did a review an left a minor comment
