PKP Warsaw 2026: Flexible Workflow Stages
At the PKP Warsaw 2026 Sprint, the Flexible Workflow Stages group proposed a concept for reshaping OJS and OMP editorial workflow stages.
Group Members
Vitaliy Bezsheiko, PKP (Note Captain)
Joao Martins, University of Cologne, Germany
Rino Razzi, Archimede Informatica company, Pisa, Italy
Justyna Rolińska, Księgarnia Akademicka Publishing, Kraków
Aleksandra Sobańska, Księgarnia Akademicka Publishing, Kraków
Agnieszka Szulińska, IBL PAN, Warsaw
Abstract
This working group explored making OJS/OMP workflow stages more flexible, so the system can better adapt to different publishers’ editorial processes. Some publishers add extra proofreading after layout and before publishing; others skip copyediting entirely. The group considered options such as merging stages, splitting production into layout and distribution, repeating copyediting after layout, and allowing custom stages, descriptions, and role-based assignments. Beyond individual publisher workflows, the group noted this flexibility could also support broader academic or peer-review use cases, such as conference management or a standalone peer-review platform. The group’s main outcome was a concept outlining guiding principles, underlying logic, and open questions for a flexible workflow-stage system, to be evaluated and prioritized going forward.
Background
Publishers’ editorial workflows vary considerably. Some require additional proofreading after layout and before publishing; others do not use the copyediting stage at all. The group’s discussion explored a range of features to support this kind of flexibility: a configuration option to merge the copyediting and production stages, dividing production into separate layout and distribution stages, repeating copyediting after layout, adding descriptions to stages, and giving users separate assignments within a stage. The group also discussed adding custom data fields and forms. Any such configuration was understood to apply at the context, or journal, level, through a dedicated setting. The group also considered the ability to rename stages, change their ordering, and restrict access to certain stages by role.
Goals
- Discuss relevant use cases for more flexible editorial workflow stages.
- Create a concept for how flexible workflow stages could work.
Results
Guiding principles. A stage can be merged with another but never removed outright. Each stage needs a decision point to move a submission forward or back, and reordering stages should update those endpoints accordingly. The Submission stage must always be present and always come first. Custom stages could be built from templates, such as a review-related or production/copyediting-style template, and all stage history for a submission should be recorded.
Underlying logic. The group proposed a journal-level setting for adding custom stages, merging stages, reordering them, or resetting to defaults. Submission and Review would remain fixed in position, while other stages could be renamed, given descriptions, assigned role-based permissions, or skipped where necessary. A template system would define elements such as file uploads, descriptions, and assigned roles, including support for custom, named upload fields — for example, for proofread files or author revisions. Whether tasks could support this was left as an open question.
Custom stage actions. Proposed actions include moving to the next or previous stage, skipping a stage, uploading files, starting a task or discussion, and assigning participants.
Associated features. The group identified further possibilities: tracking stage history per submission, a dashboard view showing time spent in each stage, and associating task or email templates with specific stages.
Open questions. The group left several questions unresolved: how custom stages should be merged when resetting to defaults, whether custom stages should be permitted between Submission and Review, and whether Production should always be the final stage.
Next Steps
- Create a community survey on other possible editorial workflows.
- Address the open problems identified during the sprint’s concept work.
- Evaluate the priority of the flexible workflow stages feature.
- Consider decoupling the association between a submission and its stage.
Read the full notes here.