Tasks

The vision for Tasks

Tasks were conceived as a way to provide a customizable workflow, but have so far been implemented in a very minimal form, with a design I find confusing.

When we first discussing tasks, we were also discussing replacing the dashboard with an activity feed; and tasks would be viewable as rows in that feed. Each task would be either:

• Some automatable process such as assigning a reviewer, which would be manually marked as done when a reveiwer was successfully invited and accepted; or
• Some out-of-system task that the user would have to manually mark as done.

Tasks were to be sequencable, so that one task being finished could automatically start the next task.

Tasks were to be able to spawn other tasks, e.g. an editor's task to invite a reviewer would spawn a task for the invited reviewer to respond to the invite.

Where practical, tasks were to provide the functionality needed to complete the task within the real-estate of the task row itself: so for instance a task to invite a reviewer would contain the invitation controls on the task itself, so the editor could address their tasks without changing screens.

A Task Template Builder page would allow creation and sequencing of tasks to represent the workflow. Any new manuscript would be populated with copies of the templated tasks, and extra tasks could be manually added for the manuscript at any point.

Current implementation

There is no real automation yet, apart from allowing tasks to automatically send emails. Each task has:

• a title and description for explaining what its assignee must do
• an assignee, who may be a role (reviewer, collaborative reviewer, editor, author) or a specific user.
• a duration in days, which may be left unset (none).
• a list of notifications (emails) that may be automatically or manually sent (you have to open an edit dialog to access this).

Tasks are started and completed manually, and largely serve as a checklist for editors to manually tick off. Before a task has been started, it has a duration but not a due date. After it has been started the first time it has a due date, calculated as start date plus duration. The task becomes overdue at 23:59:59.999 on the due date, in the team's timezone as set in the config manager. When a task is overdue, an in-app alert (a small red circle) is displayed on the Dashboard icon in the menu, and on the manuscript in the list of edited manuscripts in the dashboard.

Multiple notifications (emails) can be scheduled for a task. If the task has a duration or due date, then notifications can be configured to send when the task becomes overdue, or some number of days before or after the task becomes overdue. Task notifications are sent at midnight in the team's timezone. Notifications can also be sent early (immediately) using the "Send now" button. Note that task notifications don't yet use notificationCommsUtils (the notifications logic currently used for chat notifications), but we'd ultimately like all notifications to use that code.

Some clients currently use very fine-grained tasks to make up for the lack of automation. Because inviting a reviewer is not yet automated as a task, for instance, it has been replaced with multiple manual tasks to invite a reviewer, check for reply, etc.

There is some very simple automation attached to the sending of certain notifications: sending a reviewer invitation notification or an author invitation notification will register an invitation in the invitations table, and invited reviewers will show up in the reviews kanban board.