Double Blind Review reveals authors to reviewers

OJS 3.3.0-10

Problem: For a journal that is configured as double blind peer review: When the editor informs the authors about the result of decision on a submission and tickmarks the “Send a copy of this email notification by BCC to the following reviewers” option (see screenshot 1), the e-mails received by the reviewers reveal both the TO: e-mail adresss of the author(s) and the name of the author in the e-mail body to the reviewer (screenshot 2). This isn’t anymore double-blind.

Proposal for a solution:
A different Email template should be used by the system in such a case,
All the mail addresses (authors and reviewers) must be used in the BCC: field only.

Screenshot 1: BCC_to_Reviewer
Screenshot 2: Editor_Decision_to_Reviewer_Mail_merge

Hi @mpbraendle,

Looks like there was some previous discussions about this here: CC other users on Editorial Decision emails - #5 by RickMath

And, there was an effort to move ahead with this despite the risk that editors may reveal an author’s identity: Re-add "blind copy reviewers on editor decision" feature · Issue #4834 · pkp/pkp-lib · GitHub

I’m not sure about future development planned around this - @asmecher may wish to speak to this?

PKP Team

I agree with @mpbraendle that this option is not common at all for many double-blind journals.

I had to hide this option editing its template file, because the journal editors can’t understand why this “trap” was there.

If part of the community want to move ahead with it, is it possible to add an option to manage the visibility of this feature in Setup>Workflow>Review? What’s your opinion about that?

Thanks for your feedback @Michevole,

I’m paging @NateWr to weigh in on the feasibility of developing such an option.

PKP Team

I agree that BCC’ing reviewers on an author email is a bad approach in general, and bound to cause problems. For the next major version (3.4), reviewers can be sent entirely separate notifications. You can see some examples of what the new editorial decision workflow looks like here:

We don’t have plans to revisit how this works in 3.3. However, if there is large enough community interest in addressing this during the 3.3 LTS lifecycle (until Jan 1, 2025), we may consider a change in a future 3.3.0-x line.