Inviting to a role: propositions to improve this feature especially for reviewers

Sorry in advance for this long message but we want to alert on problems our editors encounter since the first day we upgrade to OJS 3.5 on March 31st. This message is meant to open discussions on this important but still limited feature in OJS.

Describe the problem you would like to solve
Editors are complaining about the way the invitation to a role feature is working right now. I will try to summarize the problems, basically they are 2-fold:

1) The invitation to role users’ responses are not logged anywhere in OJS.

The new table in the User and Role page lists the name of the users as long as they do not respond to the invitation. Once they do, their name disappears from the list, and no notification is sent to the journal. The only way for the editors to know is what was the user answer it to remember the name of the user and search for it in the user list: if the name is not there, the user has refused, if it is, the user will appear with the new role. This current behavior of the invitation to a role feature leaves the editors blind.

Propositions for improvements:

Invitation to role feature must be improved in the short run and different thing can be done to do so (in order of priority):

  • Ensure to log the activity so that the editors can know who has been solicitated and when especially for people who refuses. This will avoid the risk of solicitating the same people. Ex: it can look like the submission’s Activity log.
  • The editors must receive a notification when a user responds to an invitation. This could be an email notification to the journal add ress.
  • Editors should have the ability to send a reminder for the invitation to a role.
  • Editors may have the ability to configure a delay for the invitation to a role, i.e after 3 weeks, if no answer have been received, the invitation date tur ns r ed.

2) The one-click configuration that allow reviewer to access a submission expires after the reviewer click on it for the first time.

Though we understand the security reason behind this expiration, it creates a significant problem with OJS workflow.

For example: I have been invited as reviewer to a submission, I have clicked on the link to respond, accept to review and go to step 3 to see download the article. If I come back before the delay that have been set up to complete my review, there is no way for me to access it, and the editor cannot send me a new link. The only way the editor can do it, is to purposefully change the delay so that he/she can send a reminder email with a new link.

This is only one use-case, there are others: the user clicks on the link but do not respond right away and try to come back a second time; the user responds to the invitation but do not download the ar ticle, etc.

Propositions for improvement

Expiration may remain, but it must be improved:

  • Expiration can be triggered by an action rather than a click in the email.
  • Editor must have the ability to send a new link if a reviewer asks for it and is not late (no reminder email available). For example, by sending an email to the user, with the ability to select a specific email template containing the URL parameter.

Complementary approach

Another approach would consist not to rely on one click and fully use ORCID in OJS for reviewers. This path requires institutions to become members of ORCID, thus $ $.

Improvements:

· Add ORCID in the invite to a role acceptance workflow.

Thanks!

Pierre Lasou
Université Laval

Thanks for posting about these issues Pierre! We’re still on 3.4 but looking to move soon and it’s helpful to hear about these.

Just to add my $0.02 – if I had to pick one thing to fix first – the review link expiring after one click sounds super annoying! I have no idea what’s standard across other publishing platforms but increasing friction for reviewers seems bad for sure.

(The users invite sounds tricky to handle as well but at least the problem is internal to the editorial team…? obviously we want them to have a good time too but the audience for this problem is maybe a little smaller?)

1 Like

Not sure about expiration but ORCID is integrated with the new invitation system. You need to enable it first for it to show up.

It looks like this if you do :

1 Like

Thanks @ehopkins I also tend to see the link expiration as the problem to tackle first. We just need to see what approach will be better (i suggested 2 but there may be other ways).

Hi @grierb this integration with ORCID in the invitation to a role process is a good news! ORCID can also be a way to bypass the link expiration problems when reviewers are invited. However as it require journal to become an ORCID member, we still need to work on a way to solve the quick expiration problem.

Yes, I wonder if it just be set to a longer time period or something! I’m not sure why it’s been designed to expire so quickly but it seems easier to change that rather than requiring editors re-send links a bunch of times for sure.

Just to add to the 2nd problem (2) The one-click configuration that allow reviewer to access a submission expires after the reviewer click on it for the first time.), one our editor mentionned that it is not aligned with the way a review occurs usually, she describes it as follow:

  • 1st connexion is see what the submission is and answer to the invitation
  • 2nd connexion, I read instructions and download the text to review, and also look at the review form questions.
  • I read the article (2-3 hours), write a first review draft and finalize a few days later.
  • 3rd connexion : I complete the form, upload my files and send the review

Until version 3.5 it was possible for a reviewer to conduct all this step with the first link generate. Now to complete the process, 3 links (one for each connexion) should be generated (at a minimum).

1 Like

Cross-linking this conversation to a related one:

Just weighing in here to say that I don’t think this functionality should require buttons in emails at all, and that users should be able to accept role invitations in the dashboard itself when they login. I just want to make sure that’s captured somewhere in this conversation. If someone doesn’t get the email or there’s an issue with the way mail is configured, the only way to fix this invitation configuration as it is requires database manipulation. That’s not ideal. Things OJS does should happen as much as possible in the interface of the software.

I’ll note here that I say this as a user and community member, and not as a pkp guy.

1 Like

Hi, I am just referencing a Github ticket for the second problem discribed (2. The one-click configuration that allow reviewer to access a submission expires after the reviewer click on it for the first time): [OJS 3.5] The one-click configuration that allows reviewer to access a submission expires after the reviewer click on it for the first time. · Issue #12608 · pkp/pkp-lib · GitHub

Hi everyone, just an update on the Github ticket for the second problem discribed in this post (2. The one-click configuration that allow reviewer to access a submission expires after the reviewer click on it for the first time): a code has been shared that solved the problems (see PRs pkp-lib: #12612 OJS: pkp/ojs#5519). We have tested it and it solved the expiration problem. A code review is still need for it to be merged in OJS.

Hi, I have shared some thought on our to solved the first situation described in this post: (1) The invitation to role users’ responses are not logged anywhere in OJS) in another feature request:Journals should be notified when a user answer an invitation to a role

Bonjour, quick update, the link expiration problem is solved and is available in version 3.5.0.5 (LTS) see [OJS 3.5] The one-click configuration that allows reviewer to access a submission expires after the reviewer click on it for the first time. · Issue #12608 · pkp/pkp-lib · GitHub The fist issue decribed on this post remains (1) The invitation to role users’ responses are not logged anywhere in OJS.).