More Detailed Stage Status

[stranack]

Currently when viewing the dashboard, submissions have a stage status: Submission, Review, Copyediting, Production. Can we investigate having a finer level of detail?

For example, Submission: Awaiting Assignment; Review: Awaiting Reviews; Review: Awaiting Revisions; Copyediting: Awaiting Copyedits, etc.

[NateWr]

I'm curious about how we might use this as a feature prototype to explore using events internally as a way to better maintain and signal state with the workflow. This may involve dusting off some of our previous discussion around Notifications.

[asmecher]

Agreed -- the notifications stuff is a little byzantine and will be expensive to maintain as is.

[NateWr]

I think this has been addressed to some extent for the Submission and Review stages with the new list panel. Each Review Round has one of the following statuses:

// The first four statuses are set explicitly by EditorDecisions, which override
// the current status.
define('REVIEW_ROUND_STATUS_REVISIONS_REQUESTED', 1);
define('REVIEW_ROUND_STATUS_RESUBMITTED', 2);
define('REVIEW_ROUND_STATUS_SENT_TO_EXTERNAL', 3);
define('REVIEW_ROUND_STATUS_ACCEPTED', 4);
define('REVIEW_ROUND_STATUS_DECLINED', 5);

// The following statuses are calculated based on the statuses of ReviewAssignments
// in this round.
define('REVIEW_ROUND_STATUS_PENDING_REVIEWERS', 6); // No reviewers have been assigned
define('REVIEW_ROUND_STATUS_PENDING_REVIEWS', 7); // Waiting for reviews to be submitted by reviewers
define('REVIEW_ROUND_STATUS_REVIEWS_READY', 8); // One or more reviews is ready for an editor to view
define('REVIEW_ROUND_STATUS_REVIEWS_COMPLETED', 9); // All assigned reviews have been confirmed by an editor
define('REVIEW_ROUND_STATUS_REVIEWS_OVERDUE', 10); // One or more reviews is overdue

And this information is surfaced in various ways depending on which role is looking at the submission list.

If we want to do something similar for Copyediting and Production, we'll have to generate it for each request. Stages themselves have no saved status in the database.

@asmecher What do you think about adding a stage status to the submission_settings database? My thinking is that the status could be recalculated and saved whenever a file, discussion or stage participant is added.

Some possible stage settings:

STAGE_STATUS_PENDING_ASSISTANT // no copyeditor/layout editor assigned
STAGE_STATUS_PENDING_FILES // no copyedited files/proofs uploaded
STAGE_STATUS_FILES_READY // 1 or more copyedited files/proofs uploaded

@stranack Can you think of any other status flags we want to record?

[asmecher]

@NateWr, no objection to storing this data in the DB, as long as the update points aren't too scattered through the codebase.

[NateWr]

We've been having some discussions in the UI/UX group about generating useful status notifications for the Copyediting and Production stages.

The problem: journals may or may not use copyeditors or layout managers, and these roles are all lumped together as "assistants" under-the-hood. That means it's hard to say whether or not a copyeditor or layout manager should be assigned to a stage, whether one has already been assigned, and what that role is called.

One approach is to include a notification which appears based on conditions that should be mostly-accurate-enough for lots of journals but potentially confusing for some, eg:

• If the stage is copyediting and no assistant has been assigned and no copyedited file has been uploaded: "Assign a copyeditor or add a file that's ready for author approval."
• If the stage is production and no assistant has been assigned and no galleys have been uploaded: "Assign a layout editor or add a galley that's ready for publication."

Both user role names ("copyeditor" and "layout editor") may be incorrect for some journals.

[asmecher]

@NateWr, we may also be able to dodge the issue of naming roles explicitly if we refer to the workflow tasks (e.g. "Copyediting") rather than the users who do it ("Copyeditors").

[alexxxmendonca]

This probably would require a separate github issue, but somehow related to this: we should consider having due dates for each task.

This would allow flagging of overdue tasks, reporting by task (and timespans) and more control in general.

Ideally, the due dates for each task should be configurable at the journal level.

[NateWr]

@alexxxmendonca It's been hard for us to enforce things like this because, outside of peer review, journals vary widely in what they do or don't do on their way to publication. Before due dates can be set, tasks need to be defined as well, and I suspect we'll require them to be configurable in some way.

[asmecher]

@NateWr, is there part of this you'd like to consider for 3.1? I'm leaning towards deferring.

[NateWr]

Deferred.

[NateWr]

Closing this in favour of https://github.com/pkp/pkp-lib/issues/4172, which includes some example screenshots and more details about use cases.