Pkp-lib: [OJS] Revision 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! :laughing: 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!