Selective anonymity of reviewers

[freelanceastro]

The reviewers' identities need to be hidden from the authors; the reviewers' identities need to hidden from each other; but the editors need to know who the reviewers are, and everyone should know who the authors are, and who the editor is.

[marcrohloff]

Are reviewers going to choose per paper they review or as a global setting?

[marcrohloff]

I;m still waiting for an answer on this question

[freelanceastro]

These are global settings that (for now) nobody can change. We will eventually allow reviewers to change some of these settings, but don't bother with that for now -- that's #176.

[marcrohloff]

I may not be able to do this 100%, we need to include the reviewers sha/id everywhere so in theory a user can find a place where the user is public, get their sha and see where else it is used (using the API)

If we think this is a serious enough loophole then we should provide a sha for each user/paper association.

​

[marcrohloff]

I am going to rework it to use association sha's for proper anonymity control (its easier to do now than when we have users). The one question is how do we handle editor's? Can editors make comments? Do editors have to be associated with a paper or can any editor comment (or for that matter add reviewers) on any paper?

[freelanceastro]

For now, I think it works this way:

• Editors can comment on the papers where they're assigned as editors.
• Editors who aren't associated with a paper can't comment or add reviewers. This raises the question of how editors get assigned to papers in the first place. I think the best solution there is to say that a couple of users are higher-level editors (editors-in-chief) who can assign any editor to any paper. Ultimately, that's the kind of role that will fall to someone like Peter and/or Chris. But editors-in-chief can't comment on papers or add reviewers to papers, unless they assign themselves as editors for those papers.

[freelanceastro]

As for the API: my inclination is to say that if it's a hassle to maintain privacy in the API, we should just turn it off for now, or make it totally private. It'd be nice to have a working API, but we don't need one at launch. @arfon, @stuartlynn, do you agree?

[marcrohloff]

So do we need to add the ability for super-editors to assign editors to this milestone? ​

[arfon]

As for the API: my inclination is to say that if it's a hassle to maintain privacy in the API, we should just turn it off for now, or make it totally private.

I'm inclined to agree. It's much more important to have a functional application than it is to have an API for others to use.

[arfon]

So do we need to add the ability for super-editors to assign editors to this milestone?

Also, I'm not sure that I understand the use-case of 'super-editors'. Editors can/should all be equal right?

[marcrohloff]

OK. Choose a name for someone who can 'assign editors to papers'. We could of course use the existing admin permission for this. ​

[arfon]

OK. Choose a name for someone who can 'assign editors to papers'. We could of course use the existing admin permission for this.

That's just the thing: I think editors are effectively admins in terms of how they can handle papers. I had (perhaps naïvely) assumed that we'd only had a single editor here, at least to start with.

[marcrohloff]

So I'm not entirely sure how things work in the 'real world' but I assume that someone like PLOS has a bunch of editors but a single editor is assigned to a paper through the process as opposed to it just being randomly evaluated by different editors at different steps in the process.

Once/if we get at all large this will become an issue. An editor won't want to see hundreds of papers in their view and receive e-mails for every single paper under review as its state changes.

​

[freelanceastro]

@marcrohloff, that's essentially correct. A single editor is assigned to a paper at the beginning of the editorial process. @arfon, I don't think it's safe to assume we're only going to have a single editor. There should be at least one person with admin-level privileges that can assign editors to papers. We don't need that to be anything fancy, at least not yet; giving that power to one person won't scale, but we can worry about that if and when we get big. For now, let's just say that there's an admin (super-editor) who can assign editors. The existing admin permission is probably the right way to do this, but I don't have a clear sense of how the admin interface works now. @marcrohloff, can you shed some light on this?

[marcrohloff]

As far as I can tell the current admin role doesn't have any associated code yet.

My thoughts were to add a paper list for admins that only contains papers that haven't been assigned to editors. They would then get an interface similar to the current one for editors but instead of assigning reviewers they would be assigning editors. ​ The current 'papers I am editing' list would then be limited to papers you are an editor on.

[freelanceastro]

Yep, that works. I'll add an issue for this to the current milestone.

[marcrohloff]

This is done:

• Only reviewers can change anonymity and only on a paper that is not superceded (all other users are currently always public)
• If they change their anonymity it is updated for all versions of a paper
• If they make their name public and a new version of the paper is uploaded then they will be public on the new paper too.