Following on from the first post…https://www.adamhyde.net/kotahi-can-do-waaaaaat/ … some more thoughts for a post to Coko later on.
So… thinking about how to represent how one platform can encapsulate three workflow… i remember this post from a design session Dan, Alison and I did…
In this process we drew up the ‘high level’ architecture and mapped the flow of (what is now) Kotahi for a typical journal article. Some pics from that post and session here:
So…this is actually a nice way to show how preprints, micropubs and journal articles can fit within the same system…so here goes…pulling out the trusty drawing book…first image is a birds eye view of the Kotahi platform showing all of the related ‘pages’…
The spaces are connected through links. Only folks with the right permissions can see the links / can access certain spaces. The authors, for example, don’t get a link to the control panel…below is a description of each of the above spaces with a few notes…
- login
Where everyone logs in. At this stage Kotahi supports ORCID login only. - Dash
All folks logging in go to their dashboard. Linked from the dashboard is also a profile page (not shown) which is populated with info from ORCID plus some user contributed data. The dash shows only those items (articles/objects/manuscripts) you have a relationship to. - Submission
The submission page containing all the metadata added by the author. Linked to this is (not shown) the actual article if it has been added via MS word (converted into HTML and loaded in the Wax Editor). If the article is a link or a attached asset then that information is attached / linked to on this submission page. - Control Panel
This is where the editors manage the workflow of the paper. Managing Editors can assign Senior and Handling Editors. Reviews are read here. Decisions are made here. - Assign Reviewers
Where the editors assign reviewers. - Review
Where reviewers create and submit reviews.
OK…so… you now see the ‘work’ spaces… what is the ‘flow’ (geddit…’work-flow’) associated with each of the usecases (journals, micropubs, preprints)….
Ok… Journals….the Journal workflow more or less looks like this:
- Author – submits article
- Managing Editor – checks. Rejects if necessary, or sends on to be processed.
- Managing Editor – assigns Senor Editor
- Senor Editor – assigns Handling Editor
- Handling Editor – assigns reviewers
- Reviewers – accept / decline
- Reviewers – write reviews, make recommendations
- Handling Editor – makes decision to a) revise (goto 9) b) reject c) publish (goto 12)
- (review) Handling Editor – writes decision to authors
- (review) Author – revises manuscript and resubmits
- (review) Handling Editor – may assign reviewers (goto 5) or publish
- publish
Sure, any journal may deviate from this. Its a general case. One thing to try not to get caught up on is the naming of roles. For example, the micropubs folks we have worked with might have a Science Officer … but, as we shall see in the next workflow breakdown, that role does more or less the same as a second, consultative, Senior Editor.
Ok… so, the above list of steps flows through the spaces as so….(this looks sooo ugly, will find a nicer way for the coko post)….
Ok…so, you can (in ugly detail) see how the flow, flows (so to speak) across the workspaces…the color each numbers relating to roles as per the key..
oke…so…what does a micropub look like? maybe something like this (assuming the article goes through one review cycle):
- Author – submits article
- Managing Editor – checks. Rejects if necessary, or sends on to be processed.
- Managing – assigns Handling Editor
- Handling Editor – assigns reviewer
- Reviewer – accepts / declines
- Reviewer – write reviews, make recommendations
- Handling Editor – makes decision to revise (goto 8) or publish (goto 10
- (review) Handling Editor – writes decision to authors
- (review) Author – revises manuscript and resubmits
- publish
Mapped onto the spaces…
And lastly preprints might look like this…
- Author – submits article
- Managing – assigns Handling Editor
- Handling Editor – checks
- Handling Editor – makes decision to reject or publish
- publish
And mapped out…
That is the gist of it. As you can see, each usecase can fit into this one system. Of course, the above outlines do not capture every role name or flow – but these are just examples… the point is, any workflow like the above can fit into the Kotahi system…. next posts deal with special features and an examination of the role (so to speak) of permissions in such a system.
