Describe the problem you would like to solve
After 20 years of working with OJS at Ibict, since version 1.5, we have been waiting for OJS to finally improve its editorial process management. Although submission, peer-review, publishing and distribuition have been pretty well solved, the other steps of the editorial process after peer-review have not.
Since 1.x it is known that the copyediting stage is “useless”. It has had improvements in 2.x and 3.x (haven’t fully tested 3.4 yet), but it still lacks all the possibilities journals like ours need. So, my first suggestion was to really act on the editorial workflow, so the editorial process is actually designed in OJS.
During the PKP Brasil 2023 meeting in São Paulo, we discussed this a bit, as we had little time. So, they requested I posted a detailed description of what we need and believe all journals need. I started by requesting that features already available in the peer-review process be implemented in all other steps, so we could finally manage each step correctly and have better statistics on execution time, rounds of review etc., but changing core features such as the editorial workflow is much harder than adding a navigation button to the next article in the queue, for example. Putting this as a priority needs to be convincing.
So, solutions were discussed and the already-known option to implement each step in the review process came up. Actually, this is what I suggested to editors when I provided OJS trainings in Brazil.
Although the review process in OJS is really advanced, and basically every other step involves reviews from all actors in someway (the activities or user case is very similar), there are limitations as to how much of preliminary analysis, normalization, copyediting, translation and production can be implemented correctly as it currently is in OJS’s review.
So, I’ll try to describe each step and see how all the questions and needs can be answered.
First, we need to understand the differences between a journal like ours’ editorial workflow and the one available in OJS. Note that some steps have important subprocesses as well.
Ibict’s workflow
- Submission
- Preliminary analysis
- Peer review
- Editorial Decision (doesn’t count as it is pretty much solved in OJS)
- Normalization
- Copyediting
- Translation: English, Spanish and Portuguese
- Layout (Production)
OJS’s workflow
- Submission: where new submissions are handled (rejected, assigned to section editors, etc.);
- Peer-review: where peer review and author reviews take place;
- Copyediting: where the text approved in the review is treated (spelling and normative review);
- Production: where the final version is prepared for production, in final publication formats.
The big questions:
- How many journals have an identical workflow as ours?
- How many have something similar?
- How many are happy with what OJS offers?
- How to best approach the required flexibility?
The pros and cons of using everything in the review process (in my humble opinion):
- Pro: Multiple rounds of review for each stage available, which is excellent!
1.1. Con: However, review recommendations are one sided (only “reviewers” have review forms, no “response to review” forms available for authors); - Con: Only a few recommendation options available and not all relate to other editorial steps
- Pro: Due dates available for each step and round;
- Con: Custom messages may not be available (apparently 3.4 has many improvements!)
- Con: All users must be registered as reviewers.
Questions:
- Since I’ve never really tested this as it has, in my opinion, more cons than pros, how are review reports useful in this case?
- How to identify which review round is which stage in order to provide useful statistics and editorial process analysis?
- How to create user_group “normalizer”, “copyeditor”, “translator”, “coauthor”, “designer” so that they have access to each stage with the correct permissions? This may solve the “all reviewers” issue, as the permissions for some or all would be of reviewer, allowing them access to the stage features.
- Changing the wording of the recommendations and editorial decision options may help with providing more generic decisions, which would eventually fit for “need response from author after normalization round”, “proof review”, “author response from normalization issues”, for example, but doesn’t seem to fulfill all the needs. Of course, the form has recommendations which will assist in the editorial decision, but the “reviewer” has to choose the final recommendation, and that is not customizable.
Describe the solution you’d like
If considered by PKP, the solution would provide:
- Custom title for “review round”, allowing editor to assing “Preliminary analysis”, “Normalization”, “Translation” to each round.
- Reports would need to show this info (and more) so that data can be filtered by round title (CSV export would be acceptable);
- Authors would need a review form to enable them to respond to the specific queries posted besides sending their updated document.
Who is asking for this feature?
This is a personal request from Ramón Martins Sodoma da Fonseca, current executive editor of journals Ciência da Informação and Inclusão Social. However, I believe this solution, or something close, would assist all journals that currently don’t use OJS’s full editorial workflow.
Additional information
Most journal editors actually must use spreadsheets and other software to manage the editorial process. They keep OJS as it is still better than the alternatives for other features it has. This would provide flexibility to OJS no other system will have and will allow removing the “editing stage” of the core, which is already unused. It would allow granularity in the editorial workflow if needed, adding steps inside a stage such as “Similarity check”, “Focus and scope analysis”, “Compliance to formatting rules and basic normalization guidelines” within the preliminary analysis. If reports provide all the required data, every step, every subprocess can be quantified and qualified, pinpointing precisely where bottlenecks really are and allow for new policies or actions for improvement.
It will, however, impact heavily in the database structure, as far as I can tell. I really can’t say how difficult it would be to implement, but if further discussion is required, I’d glad to help and would love to see this happen in a not so distant future (hopefully, not another 15 years…).
[UPDATE - 30/06/2023 @12h51]
Still on planning the use of the review process for all editorial workflow, we noticed there’s the Review Guidelines issue. All reviewers will see the same message. If that could be customizable by round or user group, that would provide specific reviewers with specific instructions.
I don’t know if that’s already available in 3.4.