The Non-Euclidean workflow summary from the PKP Turin Sprint, hosted by the CRAFT-OA project in October 2024, is now available.
Sprints involve PKP community members joining diverse groups to work on PKP software and support. In October, the CRAFT-OA project and the University of Turin hosted eight working groups at the PKP Turin Sprint. This is a summary of one such group’s work.
Abstract
OJS currently follows a traditional, linear workflow where two stages cannot occur simultaneously. However, this structure doesn’t fully align with evolving workflows, such as open peer review, where stages may need to overlap.
We discussed the possibility of introducing a non-linear workflow within OJS to better support these modern practices. While this approach could provide flexibility, it also presents certain drawbacks. For example, implementing a non-linear structure would require significant changes to the existing workflow, adding complexity to both the user interface and system management.
Working Group members
- Devika Goel, Public Knowledge Project
- Magnus Lu, Public Knowledge Project
- Patricia, Public Knowledge Project
- Cecilia Bruno, Università degli Studi di Torino
- Martin Brändle, University of Zurich
- Davin Baragiotta, Erudit
- Oliver Krüger, Hamburg University Press
- Natalie Marty, Swiss Medical Weekly / SMW supporting association
Background
- Current Workflow Structure: OJS follows a traditional, linear workflow, where stages occur sequentially. This setup does not align well with modern or future workflows, such as open peer review, where stages may need to be more flexible.
- Considering a Non-Linear Workflow:
- Benefits: A non-linear workflow could offer more flexibility, allowing stages to overlap when necessary and possibly improving efficiency. This approach might better support open peer review by enabling multiple stages to occur simultaneously.
- Challenges: Potential drawbacks include increased complexity in communication and coordination, especially for larger editorial teams. Role conflicts could arise, and skipping stages might render the QuickSubmit plugin unnecessary.
- Prototype Development: If a viable non-linear prototype can be created, it could be considered for inclusion in version 3.6.
- Workflow Visualization and Considerations:
- Stage Skipping: Enabling the ability to skip stages may call for additional configurations, such as hiding skipped stages in the user interface.
- Acceptance Date Display: It’s important to show the Acceptance date on the front end for certain stages.
- Handling Revisions: In a non-linear setup, revisions would need re-uploading, as current versioning only allows metadata editing, not galley edits.
- Transitioning Workflows: Moving from linear to non-linear should be straightforward, but reverting back could be more complex. Warning prompts and options to delay changes until all settings are properly configured would be helpful.
- Review File Management: Each review stage would need a fixed file version to ensure clarity on which version is under review.
- Stages and Dependencies: Some stages may require specific steps to be completed before progressing. Additionally, the flexibility to assign tags instead of stages, similar to GitHub, could enhance organization and tracking.
- Team Size Consideration: As teams grow, structuring stages becomes increasingly important to manage roles, actions, and dependencies effectively.
- Key Questions to Address:
- Primary Objective: What problems are we aiming to solve with a non-linear workflow, and how will it support open peer review?
- Improvement Areas: Would redesigning specific aspects of the linear workflow better achieve our goals? For instance, moving author revisions outside of the review stage may simplify certain steps.
- User Demand: Gauging interest in these features among the user community will be crucial to prioritizing development.
- Important Considerations:
- Author Preferences: Many OJS users, especially authors, are accustomed to the linear workflow, which embodies standard industry practices. A non-linear setup might introduce delays and require re-training for authors and reviewers.
- Community-Specific Needs: Certain regions, such as Brazil, the Middle East, and Indonesia, may find significant workflow changes too progressive, particularly for older editors or those for whom English is a second language.
- Open Peer Review Workflow:
- Submission > Editorial Checks > Copyediting/Production Formatting > Online Publishing > Reviewers Complete Reviews > Editor Communicates Revisions to Author > Final Copyediting > Publish Online.
Challenges and Suggested Improvements for Current OJS 3.5:
- Feedback from Linear Workflow:
- Improvements in version 3.5 provide additional flexibility, though moving between stages still requires several clicks.
- Example Use Cases: “Living Reviews” in ejhc.org and “Letters of Inquiry” in journalqd.org illustrate alternative submission/review scenarios that could inform OJS updates.
- Proposed Enhancements:
- Improve dashboard statuses for better tracking and consider options to display different text for authors and editors, tailored by role.
- Reevaluate review status displays, such as “Review ¾,” to show fewer specific details.
- Ensure that actions like “Accept and Skip Review” capture an Acceptance date.
- Add clear indicators in the navigation to show completed stages.
- Keep options active under a “Send to” button for ease of transition between stages.
- Add a “Round Review” option specifically for Copyediting, and enable more configuration options to activate or deactivate stages based on role permissions.
- Stage Management:
- Provide warnings when deactivating stages, and include settings for stage configuration. For example, enabling additional rounds in Copyediting or categorizing stages based on their importance.
- Options to limit actions in disabled stages, preventing activity logging for these stages, and potentially using stage categorizations to improve workflow tracking.
These points aim to make workflows in OJS more adaptable to evolving publishing practices while remaining mindful of user needs and potential challenges in implementation.
Goals
- Decision on Non-Linear Workflow: After careful consideration, we concluded that pursuing a non-linear workflow may not be feasible due to software constraints and the potential complexity it adds to UI/UX and messaging.
- Alternative Focus: Instead, we’ll look at redesigning or enhancing parts of the existing linear workflow to improve efficiency and user experience.
- Reducing Stage Changes: Minimize the need for multiple clicks to switch stages, allowing for smoother transitions.
- Visual Indicators: Add checkmarks or icons to show editors which stages are complete, with these details optionally displayed on the article landing page. The user can customize visibility in the Section settings.
- Acceptance Options: There is some confusion between “Accept” and “Accept and Skip.” We’ll look into clarifying these options.
- Improving Error Correction: Simplify the process for fixing editorial errors, such as recording the wrong decision, to make corrections straightforward.
- Messaging Improvements:
- Refine in-app messaging across OJS to enhance clarity and guidance for users.
- Consider feedback from Alec: Skipping stages should be easy to implement, and editors might prefer configuring settings by section instead of a single, global setting. If feasible, we can avoid adding a settings page by offering a “skip” option.
- New Features in 3.6/ORE:
- Introduce the option to specify both sender and recipient for communications, adding flexibility for editors.
- Maintain activity (e.g., discussions) on complete stages, though we’ll need a way to prevent these from being overlooked. Relevant notifications from previous or complete stages should surface to avoid missing important updates.
Results
We explored the potential for a non-linear workflow within OJS and discussed whether this approach should receive support. After reviewing the possibilities, we determined that supporting a non-linear workflow would introduce significant constraints and require a complete overhaul of the current system to accommodate a limited set of scenarios where this structure might be needed.
In light of this, it’s essential to respect the established workflow stages for submissions while focusing on making workflows more customizable for users.
Adding the “Send to” editorial option to streamline transitions between stages should be straightforward to implement in OJS.
Next Steps
- Implement change in the Editorial action button ‘Send to’ which makes all available options in OJS 3.5 or 3.6.
Thank you
We once again thank the Sprint host institutions, and all participants for their valuable contributions to the PKP user community. Special thanks to the CRAFT-OA Project and the University of Turin for their support and partnerships.
