-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggest Reviewers at the Time of Submission #4787
Comments
SciELO also requests this feature, along with the ability to contra-indicate reviewers. |
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:
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. |
@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? |
@asmecher minimum: Desired: |
Thanks, @alexxxmendonca; would there be a need to declare conflicts (or freedom from conflicts), i.e. a relationship between the author and reviewer? |
@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) |
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. |
@Devika008, thanks, that looks good! I have three suggestions:
|
🚨 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:
|
Hello @asmecher
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
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.
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 |
Good work! |
Yeah me too I agree :D with placing the bubble after the name |
@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):
|
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 ? |
Hello @alexxxmendonca
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.
Could you share more details about this and the benefits it offers? It would really help me get a better understanding of the feature.
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? |
@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 |
Responding to a few comments: From @Devika008's comment:
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 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. |
Hello @Devika008
This is used when there is bias or personal issues involved that could make the review less neutral.
@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. |
Hello, Two more issues were discussed as a part of this issue which will be tackled separately in the future:
|
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
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
Link to Figma Designs: https://www.figma.com/design/Wf7sDlUg2372jaKKTJ0Mgz/OJS-3.4-3.5?node-id=8874-11387&t=L8lZRbByMRi3ASfK-4
PRs (draft)
pkp-lib --> #10497
ojs --> pkp/ojs#4459
The text was updated successfully, but these errors were encountered: