Adding new reviewers - UX / QoL improvement about janeway HOT 6 OPEN

which brings us to a page where we must create a new user. This is where it gets clunky: not only does the page force us to enter a password for the new user, but the users apparently are not notified of this action

I think the reporter has a point here. Creating the account silently creates usability and data protection problems, even with the 1-click-access feature. If an account is created on someone's behalf, they should receive an email promptly letting them know about their account, and inviting them to change their password and fill in other details. This will then allow them to consent and request deletion, as required by GDPR. It will also help with usability in cases where the editors have not turned on 1-click-access, or when they need their account for something else in Janeway.

from janeway.

which brings us to a page where we must create a new user. This is where it gets clunky: not only does the page force us to enter a password for the new user, but the users apparently are not notified of this action

I think the reporter has a point here. Creating the account silently creates usability and data protection problems, even with the 1-click-access feature. If an account is created on someone's behalf, they should receive an email promptly letting them know about their account, and inviting them to change their password and fill in other details. This will then allow them to consent and request deletion, as required by GDPR. It will also help with usability in cases where the editors have not turned on 1-click-access, or when they need their account for something else in Janeway.

I think we might need to take a step back from this and rethink it entirely. The best approach for countries where GDPR is an issue (and those outside using EU/UK folks data) would be to have a workflow that allows an Editor to invite a user to peer review initially without an account. The accout can then be generated if the person agrees to undertake the review.

This ensures we toe the line with GDPR and ensures we don't annoy editors who don't want a system email going out to a user before they send the polite invite.

from janeway.

I believe a similar system to that implemented inFrozenAuthor is required here: Right of erasure shouldn't apply to the reviewer metadata linked to a given paper, especially for open reviews. Given your all the proposed ideas, here is a feature proposal using user stories

User stories

• As an editor, I can send an invitation to review to external users by entering a reviewer candidate email address, full name and optionally other metadata such as affiliation.
• As the Janeway peer-review system, when an invitation to a non-registered user is received, a unique access token is generated and provided reviewer metadata is captured (sans email address). An invitation is sent via email with a unique link that uses the access token and the email is logged.
• As a reviewer and when using the unique link received, I am first presented with the current acceptance dialog (accept or decline invitation).
• As a reviewer, when I accept the invitation, I can complete the peer review form (existing behaviour). At the end of the process I'm given the opportunity to create an account with the reviewer role.
• As a reviewer, when I decline the invitation I can indicate (optional checbox?) that I do not want to be invited again in the future.
• As the Janeway system, when an editor tries to invite a reviewer that has previously requested to not be invited again, I decline the request and present an error message

data modelling
In order to capture the proposed data above and to minimise disruption to the exsiting modelling I would propose something along these lines:

erDiagram
  Article ||--o{ ReviewInvitation : "invited"
  Article ||--o{ ReviewAssignment : "reviews"
  Account ||--o{ ReviewAssignment : "reviews"
  Account ||--o{ ReviewAssignment : "reviews"
  ReviewInvitation ||--|| ReviewAssignment : "invites"
  ReviewInvitation |o--o| ReviewAssignment : "invited"
  FrozenReviewer ||--|| ReviewAssignment : "frozen"
  ReviewInvitation {
    UUID token
    ID article FK
    ID account FK
}
  FrozenReviewer {
    string first_name
    string middle_name
    string last_name
    string affiliation
    ID review_assignment FK
  }

In summary, we slot the ReviewInvite as an alternative to the Account FK to grant permission over peer-reviews. Existing functionality is preserved with the relationship between Account and ReviewAssignment. When a user requests to delete their data under GDPR, we can safely remove the account, knowing reviewer metadata is preserved (similar to our privacy policy around author data )

from janeway.

Is your feature request related to a problem? Please describe. "We are now using Janeway to handle the new RHETM submissions. Mostly it’s been a breeze, but there is one thing we can’t seem to master very well: the process of adding new reviewers to the platform. Whenever we do this by clicking on ‘Add Reviewer’ in the peer review page, this prompts us to select a reviewer from the existing list. As most of our reviewers are not yet on the list, we then click on ‘Add New Reviewer’, which brings us to a page where we must create a new user. This is where it gets clunky: not only does the page force us to enter a password for the new user, but the users apparently are not notified of this action. They only receive an email later, when we assign them to the submission and invite them to write a review. But then they don’t know how to access the platform (and don’t receive any instructions to this effect). After simulating the situation with a fake user, I discovered the solution is to click on ‘Forgot my password’ and thus recover access to the account. But this is not very intuitive, and people keep writing us back to ask how to proceed."

Additional context Feedback from #FD8391

100% certain this journal needs to add 1 click access so they aren't asked to do any of this.

from janeway.

@ajrbyers I like that solution too. I think you suggested that in 2019 @mauromsl: #1106. Would the email address be recorded in the database though? If so, how would a user request deletion or know what information is held on them?

I'd just say we also need to make sure the usability issues around account creation and activation are also tackled with careful attention. They are a persistent usability problem in my view but I don't think we've quite reached consensus on that. See #2609, #2276, #3606, #3621

from janeway.

@ajrbyers I like that solution too. I think you suggested that in 2019 @mauromsl: #1106. Would the email address be recorded in the database though? If so, how would a user request deletion or know what information is held on them?

We'd definitley have to map it out. We could have a post-decline option for the user to have their data deleted. It does present a problem with them potentially being re-invited and relying on the editor to remember not to do so once their data has been removed.

from janeway.