User:Dkretz/DPToo/Ops
This section describes the workflow for projects as seen from the point of view of the proofer. (Proofer is used as an inaccurate but generic term for proofers, formatters, and others who perform the tasks that are guided by our system.)
With default settings, it can approximate quite closely the workflow as it exists on the legacy site.
Projects
Projects identify the same entities we use today under that name - typically one book, or one volume in a set of books.
Pages
No change here.
Rounds
None.
The legacy DP system is fundamentally built on the concept of a Round, defined as one of an ordered set of assigned States of a Project. Every page in the Project marches through the same sequence of the same Rounds. DPToo does not have Rounds.
What is a Task?
A Task is an activity applied to a Page. At DP there two Tasks - Proof and Format, each repeated in different Rounds. In DPToo, there can be many Tasks, and they can be assigned differently to different Projects and Pages. In addition to Proofing and Formatting, other good candidates are Tables, Indexes, and Greek.
At DP, we say that a Project is "In a Round". In DPToo, we can say that a Page is queued up for a Task. A given Project may have Pages queued up for a variety of Tasks.
Typically all the Pages in a Project flow according to a sequence of Tasks determined by the Project Manager. But deviations can be specified by Page as well. For instance, only the Index pages would need an Index Task.
A Page cycles within a Task until it qualifies as having completed the Task, and "completed" is determined by a configurable Rule. For instance, a Rule might require that a page would undergo some statistical test that would determine how perfect it is. Or a Rule might state that a Page be Proofed twice.
Task Sequences
What determines the sequence of Tasks for the pages in a Project? DPToo provides a set of standard Task Sequence templates. This is just a set of Tasks that are declared to be traversed in a defined order. The Template for today's process is, obviously enough, P1 -> P2 -> P3 -> F1 -> F2. (Ignoring skips, etc.)
In DPToo, the project manager chooses a Template, (or builds their own), and each page in the project is (by default) then assigned a sequence of Tasks which it must undergo.
Every Page in the Project therefore stands in a queue for its next Task, until someone begins working on that Page. And once a given Task is completed for a Page, that Page can proceed to the queue for the next Task, and is free to be checked out to a user from there.
However, it is not required that every Page follow the same Task Sequence. Each Page can have it's own Task Sequence override list. The list can include both additional Tasks to be inserted, and/or skips for Tasks from the Project Task Template.
Task Completion
It is possible for a given Page to cycle through a Task more than once. Along with each Task in the Task Sequence may be included a Task Completion Rule that specifies what must be accomplished for the Page to pass to the next Task. If the Page fails the Rule, it remains in the queue at the same position to be submitted to another user for the same Task.
Page Text Versions
When a User completes a Task for a Page and checks in a Page text, it becomes a new Version. There is no limit on how many Versions are allowed for a page, and not all pages will have the same number of Versions. Versions are chronologically cumulative; each Version, as it is checked in, becomes the starting point for the next User's Task (which might be the same Task again, or the next in the sequence.)
While a User still is the Owner of a Page (see below), he/she may be permitted to revise and resave it. These saved texts do not become new Versions, but rather they are the same Version updated, and only one copy (the most recent for the User for the Task) is stored. Once another user checks the Page out, it is no longer available to the preceding User for alteration.
Users
Same concept as currently. However, it's extended by the concept of--
User Qualifications
We've generalized the way users are provided with access to various tasks, by implementing Task Qualifications. A user can acquire a Task Qualification by assignment (an administrator can do this from a screen), or by achieving some triggering event (page counts, error measurements, etc.)
Available Projects and Pages
When a user logs on, they need to be able to view the work available for them to do. How is that determined? This derives from the matches that can be found between Page Tasks that are queued, and Task Qualifications for the user.
The user's procedure is just as today. They are presented with a list of Tasks for which they are qualified.
They choose a Task, and they get a list of Projects which have Pages available for that task. Note that the same project may have pages available for more than one Task, and therefore will appear in the list for each of those Tasks.
As today, a user selects a Project, and is assigned a Page. The page editing screen, options (Save, Return to Available, etc.) are the same. The logic in the background is different (and simpler), but the user experience should be familiar.
Page Stewardship
A Page may have a Steward who is responsible for it. Stewardship can only be bestowed upon one User at a time. This normally occurs (as it does now) when the Page is issued to the User from a queue (i.e. when they check it out for a Task.) (Alternatively, the Steward can be assigned administratively.)
That User remains the Steward until one of the following occurs:
- they Save As Done;
- they Return To Task Queue;
- the Page becomes the most eligible Page (for its Project) in a given queue, someone is requesting a Page for that project from that Queue, and the current Stewardship has exceeded some configurable minimum time limit without Stewardship being reasserted (essentially the same process as now, but with more granularity);
- the Page is administratively assigned another User as Steward, or their Stewardship is administratively cleared - draconian actions not to be taken lightly.
The most recent Steward has the ability to check out and make revisions to their Version, until the Page has another Steward (normally for the next Task.) Note that this increases the amount of time available for a Steward to return to a page and make corrections.