The Kotahi workflow is very configurable and can support very linear, to very concurrent, workflows. In addition, the submission types supported are configurable. These two features together mean that Kotahi can support a wide variety of use cases and workflow models.
This document outlines Kotahi as it is configured for a typical Journal workflow. Please note that this is just one configured pathway and many parts of what you will see in this document are configurable to meet your needs.
Please note—Kotahi is undergoing heavy continuous development. For an insight into
the current issues please see here<
Typical Journal Workflow
For the purposes of this document we will look at the following configuration which is being used by the Aperture Neuro journal (Organization of Human Brain Mapping).
The Aperture workflow in sequential notation looks something like this:
-
Author creates new submission (a link, attachment, or ingested docx)
-
Author completes submission data
-
Author submits
-
Managing Editor views manuscript
-
Managing Editor desk reject (can reject submission)
-
Managing Editor assigns to Senior Editor
-
Senior Editor checks manuscript
-
Senior Editor assigns to Handing Editor
-
Handling Editor assigns Reviewers
-
Reviewers accept / decline invitation
-
Reviewers review
-
Reviewers submit review
-
Handling Editor makes decision (accept/revise->goto 9)
-
Handling Editor publishes (production covered later in this document)
We can break the above into 4 high level stages:
-
Author submission (steps 1,2,3)
-
Editor Assignment (steps 4,5,6,7,8)
-
Reviewer Assignment and Review (steps 10,11,12)
-
Editor Decision (steps 13,14)
The following sections will look at each stage and the associated user Interfaces.
Author Submission
Login
All users authenticate before they can use Kotahi. Aperture supports the ORCID OAuth protocol and process. However this can be replaced by any shared login system or with a sign-up and sign-in process. Upon login all users are directed to their Dashboard where they can view all the manuscripts they are working on (as authors, reviewers, or editors).
Submission Types
Kotahi supports any type of filetype as a submission attachment as well as link submissions (for submitting code stored in repositories or Jupyter notebook instances etc).
In addition, if a submission is in MS Word docx format then Kotahi will ingest and convert the file into an internal stored and editable data format for editing in Kotahi’s internal Scholarly Word Processor. In this later mode, Kotahi becomes a complete Single Source Publishing system (more on this later).
Submission Form
Submission data can be captured by user entry with the Submission Form. The creation and ongoing maintenance of the Submission Form is done by the Journal Admin with the internal Form Creation user interface (see later in this document).
Please see below for the Aperture form captured in its entirety (click to see the entire form).
Submission
Upon completion of the submission form, the manuscript and its associated declarations and data can be submitted. The author will be asked to agree to any terms and conditions (configurable) before the material can be submitted. Upon submission, the state for the manuscript changes from ‘unsubmitted’ to ‘submitted’—this information (current state) is displayed on the Dashboard as well as in many other places throughout Kotahi.
Editor Assignment
Editors break down to the following generic roles:
-
Managing Editor
-
Senior Editor
-
Handling Editor
-
Editor (misc)
Editors can view manuscripts they are associated with via the Dashboard as well as seeing all manuscripts on the Manuscripts Page (permissions permitting).
Manuscripts Page
The Managing Editor can view new submissions via the Manuscripts Page (click to enlarge).
Columns can be sorted by Creation Dates, State etc.
Managing Editors (ME) can choose a new (or any) manuscript to view by clicking on ‘View’. Alternatively, the ME can click on ‘Control Panel’ to view the manuscript, submission data, and the submission’s associated workflow controls.
Control Panel
The Control Panel displays the Manuscript, Submission Data and workflow controls for the selected manuscript as per below (click to enlarge).
Please note, the above screenshot is soon to be replaced with three separate tabs for 1) workflow controls 2) manuscript 3) submission data (as per this issue).
From the Control Panel, the ME can reject the manuscript or assign a Senior Editor. Upon assigning a Senior Editor, the manuscript will appear on the Dashboard for that editor. The Senior Editor can then access the Control Panel for that manuscript, view the manuscript and data, and assign a Handling Editor.
Reviewer Assignment and Review
The Handling Editor (HE) can access the Control Panel for the manuscript from their Dashboard. They can then review the manuscript and submission data. The next step is for the HE to invite reviewers. The Invite Reviewers page is accessible via the Control Panel.
At this stage of invitation, the editor can also decide if the reviewer is doing their own review or a shared review.
Screenshot taken from CB (t.b.a) Instance
Reviewers receive an email with the invitation to review the manuscript. Contained in the email is additional information about the manuscript (this is set via the Form Builder, see below).
The reviewer can then accept or reject the invitation via their Dashboard (soon also via the email). The Reviewer can then access the manuscript, filtered submission data, and the review form via the Dashboard.
The Review Page has a section for writing the review and attaching files:
Editor Decision
When reviews are complete, the HE can access the reviews via the Control Panel for the manuscript and decide on whether to accept, reject, or request a revision. Secondary revision types are managed through email templates (see below).
The HE can write their response to the author in the panel provided. The text is shown to the author on the submission form (connected to versions, see below).
The author can then revise both the submission data and the manuscript and resubmit. The process continues until the article is ready to publish. Editors can assign the same reviewers, or new reviewers per round.
Communication
Kotahi leverages many realtime tools for communication as well as utlizing its own email template system. Realtime communication is supported by ‘presence indicators’ to indicate if a user is logged in at that time. Also supported is live video communication for the editorial staff (linked from the Manuscripts Page). Live chat is also available per submission for communication between authors and editorial staff, as well as private chats for the editorial staff to discuss the submission.
Author—Editor chat embedded in the author submission pane (click to enlarge).
Editorial chat for staff only (per manuscript).
Emails can be sent for each manuscript via the email template controls. The Publisher can configure as many templates as they like. Emails can be sent to existing users or people with no account. A record of all emails sent is kept as a retrievable log within the editorial staff chat.
Screenshot taken from the CB instance of Kotahi.
Versions
Submissions are managed per revision round. Each round creates a new version of both the submission data and the manuscript attachments/internal content store. Revision history can be browsed by authors and editorial staff alike. Earlier versions cannot (of course) be edited.
Single Source Publishing
If docx files are submitted, Kotahi can be a complete end-to-end Single Source Publishing System. Docx content is ingested and converted to Kotahi’s internal data format. The content is then editable via the Wax web-based word processor built into Kotahi.
JATS
The JATS production interface is currently being built. The JATS production interface will also support automated PDF output via pagedjs, and SEO optimised HTML for pushing to publish interfaces.
Publishing
Aperture is going live with the FLAX publish front end. Flax is a new product from Coko which is connects directly to Kotahi for realtime publishing of articles while being a completely extensible CMS for building entire Journal sites. Kotahi has an extensible ingestion API and publishing API. These APIs allow for a vast variety of (for example) publishing integrations. NCRC, for example publish to a Google spreadsheet (since they are processing existing preprint URLs) as well as registering reviews with DOIs on Crossref. If the target system for publishing offers an integration endpoint of any kind, then Kotahi can integrate with it.
The Form Builder
The Form Builder sounds humble but it is an immensely powerful tool. The Form Builder enables the admin/ME to build the submission forms using a web interface. However, the interface also allows for the tagging of each field with unique IDs (useful for building JATS/XML at export time), identifying which fields will be shown to reviewers when inviting them to review, controlling taxonomy, identifying which columns are displayed on the Manuscripts Page, and it can even be used to extend the Control Panel UI. The Form Builder will increasingly become an central part of the Kotahi platform. Form Builders are much underestimated.
Reports
Reports are integrated into Kotahi and are pretty comprehensive. We have opted for dynamic rendering to improve the user enjoyment of the Kotahi UI.
Workflow Configuration
There are immense workflow configuration options. So far, almost all are via config files but we have a UI config manager design. While we will use the above workflow, the following are two workflow examples for the Novel Coronavirus Research Consortium and CBinstances:
Summary
Kotahi is a modern scholarly publishing platform. It is built with modern technologies with modern, efficient workflows in mind. The platform is also very modular, extensible, and configurable. There is almost no element of the system that is immutable—all elements can be changed if required. In addition Kotahi leverages modern realtime communication protocols and together with the Single Source Publishing design the entire system offers publishers enormous futureproofing and workflow optimization opportunities.
Lastly, all aspects of Kotahi are open source and liberally licensed (MIT). Coko exists to support organizations wanting to hire us to extend Kotahi or go it alone. In all development scenarios, Coko facilitates the multiple organizations extending Kotahi to ensure the community is building upon each other’s work—this helps ensure lowering the burden of development cost and time as well as eliminating possible duplication of efforts.
For more information contact Adam Hyde—adam@coko