Suggest Reviewers at the Time of Submission

[shaharyarahmad]

Describe the problem you would like to solve
Our editors have requested a feature to enable authors to recommend 2-3 reviewers at the time of submission. This would facilitate the review process and would be a useful feature for many journals.

Describe the solution you'd like
The feature could be implemented similar to the way we currently list contributors. A similar section could be added in the "Enter Metadata" section of the submission form.

After submission we can list the reviewer suggestions in the 'Metadata' section for each manuscript.

[asmecher]

SciELO also requests this feature, along with the ability to contra-indicate reviewers.

[lpanebr]

Issue #5885 (more automatic reminders) should have orders of magnitude more priority.

That is also true for other reviewer related draft issues like: assign from submission list, single click decline, automatic thank you letter and alternate invite upon decline/delivery, just to mention a few.

This is just based on aspects purely related with making the system more useful and enjoyable to it's key-users (editors and reviewers).

If we also stop to think we'll find some reasons for why asking authors to suggest reviewers should be way low on priority:

• It's usually a pain for authors so they are naturally prone to suggest colleagues out others from the same institution.
• Editors have a really hard time finding reviewers. Giving editors a tempting and convenient way to invite author suggested reviewers should be the last feature ojs copies from big publisher systems.

Just add a final note: Scholarone very recently added a dedicated report for journals to be able to gage the source from where editors invite reviewers. One of the sources tracked is Authors suggested reviewers.

[asmecher]

@alexxxmendonca, I'm curious about what SciELO envisions for this; would authors be suggesting reviewers by name, email, ORCiD? What do editors need in order to efficiently take the author suggestions in cases where the reviewer might not yet be in the system?

[alexxxmendonca]

@asmecher minimum:
First name
Last name
Email
Institution
+(any other fields that OJS may require for account creation)

Desired:
Department
ORCID
Reason for suggesting

[asmecher]

Thanks, @alexxxmendonca; would there be a need to declare conflicts (or freedom from conflicts), i.e. a relationship between the author and reviewer?

[alexxxmendonca]

@asmecher yes, the "reason" field sort of plays that role. It works well witn ScholarOne (they don't collect conflicts, but they collect reason for recommending or not recommending)

[Devika008]

Hello,

Based on the above discussions, here's my UX/UI proposal for the feature:

Let's include a 'Suggested Reviewers' section in the submission process, right after 'Comments for the Editors.' This section will gather information similar to what we collect when adding contributors.

In the submission workflow, we can display the suggested reviewers right below the participants section. Including it in the metadata was suggested, but I feel that might complicate the process unnecessarily.

The 'More Options' menu will display additional options, but the 'Add Reviewer' button will be disabled here since we're on the submission page.

Once the submission moves to the review stage, we'll keep showing the suggested reviewers below the participants and enable the 'Add Reviewer' button in the 'More Options' section.

When the editor clicks 'Add Reviewer' in the workflow, let's display the author-suggested reviewers at the top, followed by other associated reviewers. If an email provided by the author matches an existing reviewer in the journal, we'll show all their details which we currently show like active reviews ; if not, we'll only show the name, affiliation, and interests

If the editor adds an author-suggested reviewer who isn't already a user in the journal, we'll follow the process of creating a new reviewer. All the form fields will be pre-filled with the information provided by the author to make this process smoother.

[asmecher]

@Devika008, thanks, that looks good! I have three suggestions:

• Let's try to cut down on the fields the author needs to fill out per reviewer suggestion. At a glance, I think "Interests" and "Department" are unnecessary. Once a reviewer is invited, we can get them to populate their profile fully.
• Let's have the process for editors to add a reviewer based on a suggestion pre-fill the most appropriate existing form, rather than come up with another (unfamiliar) form. (This process will be revised by TIB per GDPR already.)
• We'll need a field in Journal Setup to enable/disable author suggestion of reviewers. I think a global checkbox in Settings > Workflow > Review will be enough, and the suggestion box will be hidden for sections that are not identified as peer reviewed in the section settings.

[lpanebr]

🚨 It should be very friction less for the Editor to see the author's reason for suggesting reviewers, and to differentiate them in added reviewers list.

Please, consider making the "Reason for suggesting reviewer" visible:

1. below the "Name of Affiliation" (in the sidebar), and
2. below the "Reviewer name" (in the Added Reviewers list).

[Devika008]

Hello @asmecher

Let's try to cut down on the fields the author needs to fill out per reviewer suggestion. At a glance, I think "Interests" and "Department" are unnecessary. Once a reviewer is invited, we can get them to populate their profile fully.

I've revised the form for suggesting a reviewer, streamlining it to just a few key fields: Given Name, Family Name, Email Address, ORCID ID, Affiliation, and the reason for suggesting. This matches the information editors use when inviting
user and reviewer

Let's have the process for editors to add a reviewer based on a suggestion pre-fill the most appropriate existing form, rather than come up with another (unfamiliar) form. (This process will be revised by TIB per GDPR already.)

I did not understand this. The form below is the form which is currently used.

The form fields I’ve suggested for authors to recommend reviewers are the same ones I’ve proposed for the new reviewer invitation workflow. This approach helps streamline the input process for both editors and authors. You can get a quick look at it here.

If the editor chooses an author-suggested reviewer, the form fields will be pre-filled with the author's provided information. However, the reviewer will still need to accept the invite and confirm or update the details, just like any other user.

We'll need a field in Journal Setup to enable/disable author suggestion of reviewers. I think a global checkbox in Settings > Workflow > Review will be enough, and the suggestion box will be hidden for sections that are not identified as peer reviewed in the section settings.

I agree. We can put it in the Setup tab below

Also as suggested by @ipanebr I've included the 'reason for suggesting' in the reviewer panel on the side, but I think adding it to the main Reviewer Panel would be too much information for the editor, especially since they're already waiting for acceptance or review.

The editor will still see the reason when they click 'Add Reviewers' and view the list of all author-suggested and other reviewers in the journal.

In the image above the assumption is that Serena Williams and Richard Tellebaums are not user in the journal. But Kathy Singley was not only suggested by the author but has collaborated with the journal as an author before.

PS: apologies for the quick untidy mockups

[lpanebr]

Good work!
Regarding the last mockup.
I don't remember if the position of the active works bubble before the person name is the default, but I'm pretty sure it would be better to position it after the name.

[Devika008]

Yeah me too I agree :D with placing the bubble after the name

[alexxxmendonca]

@Devika008 great work!

I am not sure if there is the need for an ORCID field. I think it should go with "reviewer interests" and "department" to the list of things the reviewer will add themselves later -- particularly since for ORCID it's better when the owner of the ORCID record does it in an authenticated way.

For the settings, apart from turning it on or off, I would also recommend having a minimum number of required reviewer recommendation.

Also to be considered (for now or later):

• Allow authors to suggest opposed reviewers.
• Highlighting when the reviewer institution is the same as the authors' (this would apply not only for suggested reviewers, it would be good if this could work for the entire reviewer results list overall).

[lpanebr]

Perhaps this form could be called Suggested or opposed reviewers and the author instructed to state the case in the field Reason for suggesting or opposing.

As for the ORCID I feel that nowadays it should be required. Not only for it will make it harder for fake suggestions, but mainly for it would stimulate editors to do their due diligence since all they need to do is click the ORCID. As a matter of fact, I believe it should also be readily shown and available right besides their name in the sidebar. (Using a link in the ORCID icon takes virtually no ui space)

Regarding the settings I agree with Alex. I believe that a single input with a default value of 0 (zero), making the suggestion optional, is enough.

What do you think @alexxxmendonca ?

[Devika008]

Hello @alexxxmendonca

I am not sure if there is the need for an ORCID field. I think it should go with "reviewer interests" and "department" to the list of things the reviewer will add themselves later -- particularly since for ORCID it's better when the owner of the ORCID record does it in an authenticated way.

I agree with this. In our new User Invitation Journey, we’ve also decided not to let the Editor input the ORCID. So, I’ll go ahead and remove that field from the spec.

Allow authors to suggest opposed reviewers.

Could you share more details about this and the benefits it offers? It would really help me get a better understanding of the feature.

Highlighting when the reviewer institution is the same as the authors' (this would apply not only for suggested reviewers, it would be good if this could work for the entire reviewer results list overall).

Ubiquity is implementing this as part of the Editor Load feature, where we display editors from the same institution as the author. @asmecher, do you think we could extend this to show reviewers from the same institution as well?

[Devika008]

@ipanebr

As part of the New User Invitation Process, ORCID is being integrated. The only difference is that editors won’t be able to input it themselves—it's up to the users to provide. You can find more details about the process here: https://github.com/orgs/pkp/projects/32/views/1?pane=issue&itemId=51310226.

You will also see the ORCID verification next t the user's name:https://github.com/orgs/pkp/projects/32/views/1?pane=issue&itemId=51310320

[asmecher]

Responding to a few comments:

From @Devika008's comment:

@asmecher, do you think we could extend this to show reviewers from the same institution as well?

No, I think it's more important to reduce the amount of info an author is expected to enter, and let the editor make informed decisions. Authors should be suggesting reviewers that don't have conflicts; if they break that practice, the existing proposal from Ubiquity should help the editor catch the conflict, I think. The Ubiquity work is intended to help the editor avoid making a mistake when managing a large reviewer pool, and that's different than handling author suggestions.

From @alexxxmendonca and @Devika008's comment:

I am not sure if there is the need for an ORCID field. I think it should go with "reviewer interests" and "department" to the list of things the reviewer will add themselves later -- particularly since for ORCID it's better when the owner of the ORCID record does it in an authenticated way.

I agree with this. In our new User Invitation Journey, we’ve also decided not to let the Editor input the ORCID. So, I’ll go ahead and remove that field from the spec.

I do think ORCiDs are generally a good idea to encourage, as we want to provide flexibility in how authors identify potential reviewers (and co-authors etc), and by nature an unambiguous ID like an ORCiD is a great way to do that. Ideally there's a GDPR-safe, ORCiD-supported, invitation-based way for a reviewer who is identified by an ORCiD as a potential reviewer for an article to receive an invitation when appropriate. If there's not now, I'm pretty sure one will become available in the future. But I'll ping Erik specifically on that workflow to see what he thinks.

[alexxxmendonca]

Hello @Devika008

Could you share more details about this and the benefits it offers? It would really help me get a better understanding of the feature.

This is used when there is bias or personal issues involved that could make the review less neutral.

Ideally there's a GDPR-safe, ORCiD-supported, invitation-based way for a reviewer who is identified by an ORCiD as a potential reviewer for an article to receive an invitation when appropriate.

@asmecher Agreed. I am in favor only if it's a GDPR-safe, ORCiD-supported, invitation-based solution.

And I wasn't aware of the Ubiquity solution. Good to know that there is something being developed in that regard.