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.

Specs Update - Friday, September 27th, 2024

Workflows Affected by This Change

• Adding an extra step in the submission workflow.
• Displaying author-suggested reviewers under participants on submission workflow pages.
• Showing author-suggested reviewers again during the reviewer assignment process.
• Introducing a new checkbox on the settings page to enable/disable reviewer suggestions. (Mentioned in other considerations)
• Migrating the reviewer invitation process to the new user invitation workflow (mentioned in other consideration)

Detailed Specs

Adding an extra step in the submission workflow.

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.

Displaying author-suggested reviewers under participants on submission workflow pages.

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.

Showing author-suggested reviewers again during the reviewer assignment process.

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. In the image below 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.

Please note that, we can make the UX better by moving the "1 active" tag after the reviewer name than before it

Other Considerations

1. We'll be updating the "invite reviewers" process to align with the new user invitation workflow. The reviewer details suggested by the author will be pre-filled in the form when the editor sends the invite, removing the need for copy-pasting information.
2. 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.

Link to Figma Designs: https://www.figma.com/design/Wf7sDlUg2372jaKKTJ0Mgz/OJS-3.4-3.5?node-id=8874-11387&t=L8lZRbByMRi3ASfK-4

PRs

pkp-lib --> #10497
ui-library --> pkp/ui-library#426
ojs --> pkp/ojs#4459
omp --> pkp/omp#1835
ops -> pkp/ops#871

PRs (Minification Fix)

stable-3.5.0

pkp-lib --> #11354
ojs --> pkp/ojs#4862 [TEST ONLY]

main

pkp-lib --> #11355
ojs --> pkp/ojs#4863 [TEST ONLY]

[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

[touhidurabir]

From @asmecher

@touhidurabir, one thing still needing fixing here: the changes in the old JS framework break minification. Run lib/pkp/tools/buildjs.sh -n:

Compile (Check)...
	/tmp/tmp.6Jz93d87F4/lib/pkp/js/controllers/grid/users/reviewer/AdvancedReviewerSearchHandler.js:128: ERROR - [JSC_PARSE_ERROR] Parse error. primary expression expected
	  128| }(window.jQuery));
	        ^
	
	1 error(s), 0 warning(s)

Found Errors! Not minified.

Could you have a look?

[touhidurabir]

@asmecher , check the PRs at #4787 (comment), section PRs (Minification Fix) . I have tested it stable-3.5.0 using command lib/pkp/tools/buildjs.sh -n which complete the minification with following message

Please don't forget to set enable_minified=On in your config.inc.php.

Done!

[asmecher]

@touhidurabir, I merged the PRs -- I didn't test the feature, but the change looked trivial enough. The JS compiles and minifies now. If you smoke tested it (on stable-3_5_0, after compilation/minification, with enable_minified turned on in config.inc.php, that's good enough for me, thanks!