Add revision due dates and email reminders

[ajnyga]

Some of our journals have asked for a feature where the editor can send reminders to authors regarding the revisions of their articles. Basically the editor would define a default time limit for revisions like with the review requests. If the author takes more time than the defined time limit to return a revision of her paper, the system will send a "gentle reminder". Also, manual reminders should be possible.

The feature has been discussed at the forum https://forum.pkp.sfu.ca/t/ojs-can-ojs-send-automatic-reminder-emails-to-authors-whose-article-still-needs-revisions/16873

There are few key questions here (probably not all of them at this point):

1. How/where should we save the data regarding:
   a) how many weeks before automatic reminder (journal_settings)
   b) when is the revision due (submissions, submission_settings, something totally new?)
   c) when was the author reminded (submissions, submission_settings, something totally new?)
   d) was the reminder automatic?

2. Should this data be saved separately for each revision request? Or should the old data (revision due, date reminded etc.) be erased when a new revision is requested?

3. Should there be a totally new database table and functions for generic reminders which could be used for both review reminders and revision reminders, and possibly some other workflow reminders as well?

4. @asmecher had a comment regarding connected with the email templates, go ahead.

[ajnyga]

I guess a fast way of doing this would be to add the needed database fields to the review_rounds table, something like this:

Then you could check if the reviewRound status is "REVIEW_ROUND_STATUS_REVISIONS_REQUESTED" and see whether the given dates are expired and then trigger the automatic reminders and/or show in submission UI that the revision is due and allow the editor to send a manual reminder message.

[ajnyga]

@asmecher this is a old issue, but I would be interested working on this during the spring. We get frequent requests for this and have seen this mentioned on the forums as well.

I bet you remember the comment you had I mention above!

[asmecher]

I don't have a strong feeling about any of this, really, but I think it might be a good opportunity to introduce some generic tools for reminders -- @NateWr, back to your ideas about flexible workflow, this would be a way to create a new "card" based on a template and invite users to it. Do you have any mockups from that work at your fingertips after all this time?

[ajnyga]

generic sounds good. Would be great to see the concept you have talked about.

[NateWr]

One thing I've considered for a long time is the concept of an assignable task with due dates. People want this throughout the workflow. In addition to reviews and revisions, due dates could be used for initial submission acceptance/rejection, copyediting tasks, layout editing tasks, ask the author to send in metadata.

An old mockup of what it could look like inside each stage of the workflow.

If you're considering working on this for the sprint, I think you'd have to scope this down pretty tightly to just a new task entity in the database, a simple grid, and a create/edit form. However, there are other considerations we'll want to think about in the long term:

1. The ability to configure default tasks to be added when a submission is moved to a stage, when no editors are assigned, and other events in the workflow.
2. How to surface overdue tasks in the submissions list, and integrate with the overdue filter.
3. Default task duration with override on create/edit.

Alternatively, for this particular problem (revision reminders), it would be an interesting thing to try out as a plugin using the new context schema. You could add the context settings for revision duration, modify the settings forms, and set the scheduled task from a plugin. It would be a good way to try out the extensibility of the new architecture. The one tricky bit would be overriding the default revision duration on a case-by-case basis.

[ajnyga]

Thanks Nate.

Have you considered if the tasks could be combined into discussions (just a thought since these tasks are probably always also discussed in some way. Probably a separate task grid is better).

So to follow your logic, in the settings somewhere we could then have a grid where you create a new item and can choose an action within the workflow from a predefined list (for example request revisions) and define that when this action is triggered a new task is automatically created. You could also have a selection of a) who gets notified b) what is the default time limit and c) what email template is used for the notification and d) what action is needed for the task to be ready. For the reminders we already have, we could create default items that journals can edit if they want.

And of course you could create and edit tasks from within single submissions as well. The form would be pretty much the same with the exception that instead of roles, you could choose assigned people as recipients. If a predefined task was created for a submission you could then edit that task and for example change the time limit etc.

(I will probably miss sprint this time because of the time difference (would have to work starting from around 8 PM) and I can not travel to Vancouver. It is a bit too much distance for a two day event anyway)

[ajnyga]

I mean something like this. Of course there are a lot of questions involved. Like what is the relation between the message and predefined email templates.

[NateWr]

Yes, that's the general idea. But request revisions is probably a bad example, because that is an action that already has a setup step and a defined endpoint. Because of this, we can manage the task automatically. So it would be more likely that in the Request Revisions modal we would have a step that said "Revisions due" and we would could create the task, assign the participants, send the reminders, etc, without any journal settings.

The journal settings for default tasks would probably be for steps where things are more vague and we don't have the info we need to create a task ourselves. Moving to Copyediting stage is a good example, because all journals have different setups: some with dedicated copyeditors, some who just use editors or interns as copyeditors, some who just ask the author to do a final proof, etc.

In that case, they may set up a default task like:

• Copyedit files and send proof to author
• Create task in: Copyediting stage
• Default days to complete
• Automatically assign participants from these user groups

But when the submission is moved to copyediting, there is usually not a copyeditor assigned, so the task would have to be able to be created waiting for a participant(s) to be assigned. And since there is no clear "done", this task would have to be marked complete by the copyeditor.

I will probably miss sprint this time

Sorry, I thought "spring" was a typo in your previous message but you did mean spring! 😆 In that case, I'd recommend starting on the infrastructure of tasks. Keep it as simple as possible:

• id
• name
• stage
• description
• dueDate
• assignedTo

For now we will use a generic message for overdue task reminders, where the task name and description are injected into the message.

We can sort out default tasks, automated assignment, etc, down the road. But if we get the tasks in place it will help us start discussing all the ways they can be used to solve the problems we have with tracking submission progress passed review.

[NateWr]

And as part of keeping it simple, I'd recommend just focusing on manually marking tasks completed for now. I know that may not be the best for your particular use-case (revisions), but let's focus on that as a baseline.

If you want to set up an automatic revision task due date, with automated completion when a revision is submitted, you could easily hook in with a plugin to add the task and mark it complete at the correct times.

[ajnyga]

Sounds like a good concept. I will look through this.

[ajnyga]

(ps. I of course never do typos)

[Potomac54]

Hello,

I am also interested with this reminder feature for authors, I am working for a client who needs automatic reminders (email) for authors, it seems to be a recurent wish in OJS forum like Ajnyga noticed, and my client wants also a much more configurable reminder option (automatic reminder before the deadline with configurable value in days/weeks, automatic reminder after the deadline, and ability to schedule the repetition of the reminder if the author has still not sended the revision despite the reminders),

I think OJS should treat authors with the same care as the reviewers, so option like automatic reminder should be implemented, and some journals have much more interactions with authors than the reviewers (when editor asks directly revisions to the authors and wants to set a deadline date, with automatic email reminder),

I am also a developper and maybe I can help you, but I need to understand how the source code is structured in OJS 3.x, and how long the implementation of this feature can take,

it would be also interesting to improve the reminder options for the reviewers (ability to set the number of automatic reminders if the reviewer has still not sended his review)

thanks

[fgnievinski]

Just pinging back to the forum where a related wish has been posted:
https://forum.pkp.sfu.ca/t/reminder-for-reviewers-that-the-review-is-due-soon/51907/8
https://forum.pkp.sfu.ca/t/automatic-reminder-for-upcoming-review-deadline/50580
the feature request is for reminders that an upcoming review is due soon.

[librariam]

+1 from PKP|PS. A client is interested in having "Important dates" (e.g. "Revision Due Date") for authors in the same way they currently appear for reviewers in review request ("Response Due Date" / "Review Due Date"). These variables could then be used to populate dates in email templates in author-editor correspondence and for revision reminders as well. Thank you!

[pmangahis]

+1 from PKP|PS. A client is interested in having deadline reminders for Review, Copyediting and production as well.

[kshuttle]

+1 from PKP|PS. A client is interested in having automated reminder emails sent to authors when their review is due. They suggest separate email templates for "resubmit for review" and "revisions required" decisions. They also suggest having additional reminder email templates for authors that can be sent by the editor (as opposed to automatically).

[kshuttle]

Suggested title for new email template to send revision reminders to authors: REVISION_REMIND

Sent by: Editor
Received by: Author
Should the sender be able to preview and customize this email? Yes
Should the recipient be able to opt out of receiving this email? No

The following has been drafted for this new email template:

Email subject
A reminder to please send us your revisions

Email body
Dear {$authorName},

Just a gentle reminder for you to please upload the revised version of your submission, "{$submissionTitle}," for {$contextName}. We were expecting to have your revisions by {$revisionDueDate} and we would be pleased to receive the revised submission as soon as you are able to prepare it.

You can upload revised documents along with your response to the reviewers’ comments at your [submission dashboard] (links to {$submissionURL}).

If you have any questions, please contact me from your [submission dashboard].

We look forward to receiving your revised submission.

Kind regards,
{$signature}

Email description
This email is [automatically?] sent when an author has not uploaded their revisions by the due date.

The following work needs to be done:

• Decide if this email will go out automatically when the revision due date passes, or be sent by the editor
• Add this to [OJS/OMP].

[twakeford]

FYI - we have had a lot of requests for a function to log revision due dates and have reminder emails sent. One addition to the above is that we're often asked for a reminder email to be sent before the due date, so that the author then gets kicked into action beforehand. Editors often point out that waiting until the due date has passed means that revisions are still going to be late, whilst a kind reminder beforehand means that the chance of the due date being hit is significantly increased.

[pmangahis]

+1 from PKP|PS

[trobb49]

In addition to editing my own journal, I often review for other journals by major publishers such as Springer or Elsevier. These all have a reminder function for reviewers that sends out a message one week prior to the due date. I really appreciate this since it allows me sufficient time to finish the review by the due date and avoids embarrassment -- as well as "late" marks against my record.

[asmecher]

@trobb49, this issue is about reminders to authors, but OJS already supports automated reminders to reviewers:

[trobb49]

Hello Alan,

Thank you for your response, but what you mentioned is not the issue.

These reminders go out AFTER the relevant due date. What I (and a number of others) are requesting is a reminder PRIOR to the due date. This needs to be a separate function since the text itself would be different -- different verb tenses, tone, etc.

It should, however, be an easy modification of the current script.

ANOTHER ISSUE with the current function is that when implemented, it sends reminders to EVERYONE in the system that missed a deadline. The code needs to include a check to see if a decision is still pending.

Cheers,
Thomas Robb, Editor, TESL-EJ.org

[NateWr]

Hi @trobb49, review reminders before the due date are covered in this issue: #5885. I'd invite you to add your support there.

If you are encountering a different problem, please file a new issue. It helps us manage work over the long-term if we keep each bug or feature request separate.

[pmangahis]

+1 from PKP|PS client

[pmangahis]

+1 from another PKP|PS client

[fgnievinski]

maybe this issue could be closed as a duplicate of #5885 which has a narrower scope?
(just notice there are 7x "+1 from PKP|PS" here that you might consider carrying over.)

[twakeford]

maybe this issue could be closed as a duplicate of #5885 which has a narrower scope? (just notice there are 7x "+1 from PKP|PS" here that you might consider carrying over.)

Aren't the cards about different things?

#2687 (this card): adding a due date and reminders for Author Revisions
#5885: adding reminders before review due dates

[twakeford]

Ubiquity may look to try and get some progress on the issue of author due dates and associated reminders. Before spec'ing it out in too much detail, my understanding is that the below would be a good fit (essentially, replicate the reviewer settings), so that:

• the editor sets an author a due date when either of the REVISIONS decisions are selected
• the due date has an automatically set default, but is editable by the editor prior to finalising the decision
• the due date pulls into the email
• the due date is editable after the decision has been logged, in case the author requests an extension
• the due date pulls into the author interface
• automatic email is sent according to the journal’s settings near/at the time of the due date
• journal settings will require:
  • default due date (i.e. +X weeks from decision). Ideally there would be two:
    • Revisions without additional review (minor revisions)
    • Revisions with another round of review (major revisions)
  • auto email triggers if due date passes without revisions being submitted (i.e. X days from due date). Ideally there would be two:
    • X days prior to due date
    • X days after due date
• All emails should be in the Activity Log

Does that sound about right?

[Vitaliy-1]

I'd consider adding due dates in a more general scope. Now, when decision tools are in place, we can associated due dates with them. Due dates for authors to upload a revision is looking like a good exercise - they can be added to the notify author step. I'll take a look which decisions could benefit from setting due dates.

Once decision regarding revisions is made, we can show dates in the revisions grid, together with the edit button.

[Devika008]

Hello,

Here is my proposal for setting reminders for author revisions. As you can see in both videos, I have included the step of setting reminders as part of the "record decision" workflow for requesting revisions. I have also taken into account the considerations iterated by @twakeford above:

• the editor sets an author a due date when either of the REVISIONS decisions are selected
• the due date has an automatically set default, but is editable by the editor prior to finalising the decision
• the due date pulls into the email
• the due date is editable after the decision has been logged, in case the author requests an extension

I also believe that once the due date is edited, a new notification or email should be sent to the author. This ensures they are promptly informed of the updated timeline.

Prototype for Request Revisions which are not subjected to a new review round

https://youtu.be/qh_rFJ6ZWgw

PS: please ignore the little description written below the heading "Request Revision" I realised the error after uploading the video

Prototype for Request Revisions which are subjected to a new review round

https://youtu.be/FmtJp6-LZEg

According to the new submission lists protocol, if revisions have been requested, any other updates will be shown alongside the revision request. This way, there's no risk of missing the edit due date indication.

Also for settings, we can take cue from @touhidurabir 's work here to add reminders for uploading author revisions. Below are the design for the same

Let me know your opinions on this!

PPS: I have submitted a proposal to add revisions in the Desk Review Stage here, so a similar workflow can be followed here for requesting revisions minus the steps of Notifying Reviewer

[twakeford]

@Devika008 this looks good to me.

• It looks like the editor is being asked to select a due date (from a drop down?). Is this due to just being the mock up, or the intended workflow. Is the default due date going to be applied & show to the editor automatically on that first screen?
• do we also want to consider how/where the default values should be applied to the journal settings pages?

We'll obviously also need to add some email templates to account for the new auto emails. I agree that an email should be sent to the author to inform them when a due date has changed. I'd suggest that this is displayed to the editor when they save any change of revision due date, so that they can edit the template.

[Vitaliy-1]

Thanks, @Devika008. It looks great!

Regarding the link for editing due dates, it's placed in the notification area. I'm thinking about hypothetical situation when a new notification replaces the previous one. We haven't thought about step by step consistency between information and actions in that area before. So you right that there is a risk of missing the notification with a link for a user. Probably dashboard is enough if we ensure consistency there. Have you also considered making use of Revisions grid for that?

[Devika008]

Hello @twakeford and @Vitaliy-1

It looks like the editor is being asked to select a due date (from a drop down?). Is this due to just being the mock up, or the intended workflow. Is the default due date going to be applied & show to the editor automatically on that first screen?

This is the intended workflow! I feel that the cookie cutter approach of a standard due date might not cut it (5 days from when the revision is being asked) I think the editor should fill the due date based on the situation. From the dropdown the editor is to select a date. However if you feel, we need to add a default date, that would also be okay.

Regarding the link for editing due dates, it's placed in the notification area. I'm thinking about hypothetical situation when a new notification replaces the previous one.

Jarda and I are working on Notifications and Statuses on Workflow and Dashboard page that stay till the action is complete. this allows to show 2-3 notifications at once. let me know if this works

[twakeford]

Hi @Devika008

This is the intended workflow! I feel that the cookie cutter approach of a standard due date might not cut it (5 days from when the revision is being asked) I think the editor should fill the due date based on the situation. From the dropdown the editor is to select a date. However if you feel, we need to add a default date, that would also be okay.

I've done some canvassing and the feedback on our side is that a default revisions date for each of the revision decisions would be very beneficial. Two main points were made:

1. Most minor and major revisions will fall within a similar timeframe, so having a default for each makes this process easier for the editors. If the journal wishes to offer x weeks for minor revisions (not going back for review) and y weeks major revisions (going back for review) then we can cut down on additional clicks for every decision.
2. Journals will want some consistency over these decisions, with minor/major revisions expected to be returned within a certain timeframe. Having a journal default is a way that EiCs can encourage editors to stick with these times, but equally for editors to understand what their journal standards are. Having the specific editor decide each time will lead to a lot of variability between submissions (e.g. the system will push guest editors to the journal norms).

Having the ability to change the default is definitely required, but our editors think that most submissions would benefit as above.

[Devika008]

Hello @twakeford

Thank you so much for the feedback you collected! 😃

I've made a tweak to the workflow and added a default due date to the form field, with an option to change the due date via a dropdown.

I'm unsure whether we need a default date or options like "5 days from now" or "2 weeks from now" (which I'm not in favor of).

To set the default due date, we can go to the settings where we set the timelines for review reminders and select the duration (in days or weeks). I would need some guidance from you on whether it should be in days or weeks.

[twakeford]

Hi @Devika008

For the default due date in the decision workflow, I would:

• display the default date
• have a calendar icon that would bring up a calendar view where the editor can select a specific date

I don't think that it needs a '5 days from now' type option.

Perhaps for the default settings, there could be a new 'Revisions' tab in the Workflow menu (between Submission and Review), where these could go. I think that setting the default in days is probably best. There are some journals that do demand extremely quick turnaround times (rightly or wrongly), so we should try to incorporate such workflows and allow as much flexibility as possible.

[Devika008]

Hello @twakeford,

I recommend sticking with the dropdown for setting dates. Users are familiar with this method from other applications, making it an easy and intuitive action. Introducing a calendar icon would necessitate updating the entire system to use this icon consistently in similar workflows, which may not be necessary.

[twakeford]

Perhaps we're thinking of the same thing. This is how the due dates work for the reviewer dates (OJS 3.3). I'm imagining something similar when the default date is clicked on.

[Devika008]

Yeah exactly that but I would had a dropdown button which when clicked triggers this