Editorial Workflow Modifications

[chansen4]

I have a request from one of the journals I support to change the editorial workflow.

Instead of allowing the Section Editors to make the final decision on a submission, this journal would like all final decisions to be left to the Editor of the journal. They would like the following workflow:
- Editor assigns submissions to a Section Editor
- Section Editor assigns Reviewers to the review the submission.
- Section Editor gathers Reviewers suggestions and comments.
- Section Editor makes recommendation to Editor.
- Editor makes final decision and informs the Author.

I was mainly wondering if there has ever been any talk about allowing for these kind of changes in the configuration of OJS or if there is something that would allow for these changes in a future version.

Thank you,
Chad

[jmacgreg]

Hi Chad,

I'm not sure if we'd necessarily hardcode something like this in: the workflow is easily possible informally, and even if SEs weren't necessarily 'trusted', Editors still have full control over making changes before or even after an SE has made them. We can consider it a vote though, and if others mention it we can look into providing the feature.

Cheers,
James

[cbel12]

Hi James,

Chad, who made the original post, is a colleague of mine. I made a proposal to the editor in question, trying to implement this system informally by asking the Section Editors just to send an e-mail with their decision/recommendation to the Editor but NOT to record the decision using OJS. It hasn't worked for this journal. The Section Editors find it a very natural thing to record the decision using OJS.

The crux of the issue is the key words in Chad's final bullet point "and informs the Author." Right now as soon as the Section Editor records the decision using the system, OJS automatically sends to the Author the EDITOR_REVIEW prepared e-mail communicating that decision. Unless we don't have OJS configured properly, I see no way of disabling that e-mail. And, even if the e-mail itself could be disabled, the decision is recorded and the Author can see it any time he or she logs into the system to check the status of the submission. Having the Editor later reverse the Section Editor's decision (which, admittedly, the system very easily allows) puts everyone (Editor, Section Editor, and Author) in an awkward position.

Did you have something different in mind than what I've described when you wrote that "the workflow is easily possible informally" that would avoid this potentially embarrassing scenario? Are you aware of any users who may have made the type of modifications Chad describes.

Thanks,
Jeff

[asmecher]

Hi Jeff,

Do you have anyone on hand with PHP experience? I'd suggest making a minor modification or two. You might consider:

• For Section Editors, disable the Editor Decision pulldown and "Record" button (or hide them entirely).
• For Section Editors, add an email icon and a link to allow the Section Editor to email their recommendation to the Editor. If you follow the same patterns for email icons elsewhere in the Section Editor's editing interface, these emails will be captured in the email log (when enabled).

Regards,
Alec Smecher
Public Knowledge Project Team

[cbel12]

Hi Alec,

Thanks for your quick response. I think this will meet with the editori's approval. I don't personally have the PHP experience but we have folks in house who do. We'll give it a try.

Thanks,
Jeff

[justingonder]

We have 1 journal that considers this feature request their highest priority. We'll give the PHP route a try, but I wanted to throw our +1 behind this request as well. In this journal's ideal world, it would be nice if the "Editorial Decision" workflow were partitionable in a fashion similar to the copyedit, layout and proofreading workflows.

-justin gonder
eScholarship Operations Coordinator
California Digital Library
510.987.9869
help@escholarship.org

[asmecher]

Hi all,

Just to link discussions together -- see also http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=3294. [Edit: Not the same issue; disregard.]

Regards,
Alec Smecher
Public Knowledge Project Team

[justingonder]

Hi Alec,

Though posted by our team around the same time, the bugzilla topic that you just linked to seems unrelated to this thread (to me). Sorry we've been barraging the forums today, but we've been saving up user requests

-justin gonder
eScholarship Operations Coordinator
California Digital Library
510.987.9869
help@escholarship.org

[asmecher]

Thanks for the heads-up, Justin -- that's what I get for assuming.

Regards,
Alec Smecher
Public Knowledge Project Team

[sagpub]

+1 on this issue from me. We need the exact same workflow as mentioned in the first post.

[geoffg]

Another +1 for this feature. Any chance this feature will make it into the OJS application?

[lschiff]

We have this modification built into our code for one journal and are almost ready to release it to another. We're going to be refactoring this into something we can release back to the OJS codebase though and are thinking it should be an option in the 5-Step setup process.

[sagpub]

We have this modification built into our code for one journal and are almost ready to release it to another. We're going to be refactoring this into something we can release back to the OJS codebase though and are thinking it should be an option in the 5-Step setup process.

Any update on this? I have to do something soon or our journal editors are going to revolt. I managed to prevent Section Editors from doing the final approval with some minor code changes. My solution is far from perfect though and does not truly address the needed process change.

[lschiff]

I'm not sure exactly when this will be submitted to the 5-step set-up, but for now you could look at our code on GitHub to see how we've implemented it just for the two journals that need it: https://github.com/cdlib/eschol-ojs/blo ... cision.tpl