Andreas Mantke wrote:
Hi,
I'm willing to create a new customized workflow on OOoAuthors. Therefore I
need some suggestions, which status a document should run through before it
get his final status and is going to be published.
There might be new roles assocciated with this new workflow. We should decide,
whether every status of the document should be connected to a role.
Currently we have the status:
private, internal draft, pending review, internally published and external
published.
I think there are more than one status between the draft and the published
document. The workflow should represent this, because the roles are clear and
every document get the right status (it would not be necessary to copy from
one folder to another and to rename the document).
Regards,
Andreas
Hi, Andreas, Gary, all
Here's my 2¢, from a semi-outsider (I do almost no reviewing).
I suggest that we have four actual roles: visitor, reviewer, maintainer,
and editor (plus sysop, but that's not under discussion).
Visitor, reviewer, and editor are /people/ roles, with levels of
permission. /Maintainer/ is a role associated with a particular document
and a particular reviewer. What I think these role-players should do
should be obvious, in the following discussion of file statuses and
work-flow.
I suggest that the current crop of statuses is less useful than it could
be, because they focus on what has been done, rather than what happens
next. In the following discussion of work-flow, I have renamed the
statuses radically, focusing on the future of the document.
*Work-flow:*
Maintainer starts things, with a document of status "Ready for review".
Reviewer checks out a copy, setting status "Wait review by {name}".
(Problem #1:) Another reviewer works on the same document at the same
time. Document status should show "Wait review by {name1}" AND "Wait
review by {name2}".
The site should assume that the review(s) will be coming back, and make
preparations for that, i.e., assign slots in the "Feedback" folder.
These should show in the menu when the reviewer(s) upload(s) the
reviewed document. The uploads have status "To Maintainer, reviewed by
{name}". The filling of the pre-assigned slot should change the original
document's status from "Wait review by {name}" to "Review by {name} in
Feedback".
(More Problem #1:) Another reviewer checks out the original. Should be
handled as above, with multiple statuses.
(Problem #2:) Maintainer is busy, and another reviewer wants--or is
asked--to review the earlier review. Checking out the previous upload
should be handled as above, with multiple statuses. ("Wait..." status
added.) When the second review is uploaded, it gets a status of "To
Maintainer, Review by {name1} by {name2}", and the first review's second
status changes as above.
Maintainer downloads "To Maintainer" file(s). (If there are "Wait..."
statuses present, it's email time: "Hey, Joe, how are you doing on the
review of ..." Maintainer or original Reviewer can cancel "Wait"
statuses.) Downloaded files get "Wait, Maintainer at work" status.
After consolidating comments and changes, Maintainer uploads new
version, over the old one (Maintainer privilege). Site knows about all
associated files, and asks what to do with them (archive(?) or delete,
or nothing; if not archived / deleted, file with "Wait Maintainer"
status gets status "New copy available in Draft".). File may be assigned
"Ready for Review" status, cycling again.
File may be assigned (Maintainer privilege) status "Ready for final edit".
Editor downloads file. Status becomes "Wait editing by {name}". Slot
created in "Published" folder.
I see three major options for the Editor:
1) Publish the file. Editor uploads file into slot in "Published".
Depending on how well-informed the site is, Editor may have to choose
among radio buttons for (o)New, (o)Update {filename1}, (o)Update &c.
Previous status of old file changes from "Wait edit" to "Published -
Maintainer may delete".
2) Reject, "needs work". Editor may change status to "Ready for review"
again. (The ability to add notes, like "Section Foo needs work", would
be very helpful.) Slot cancelled in "Published".
3) Reject, with review. Editor changes status to "Wait review by", then
uploads new version into the newly-created slot in Feedback, just like
any other review / reviewer. Slot cancelled in "Published".
*Sidebars*
If possible, all statuses should include full date and UTC time, for
coördination purposes.
On occasion, a Reviewer will find problems in a published document, and
submit corrections. Reviewer should be able to upload to Feedback, with
a status of, "To Maintainer, published copy reviewed by {name}".
Maintainer may reject changes, or submit (upload) new version for
review, or for final edit/publish.
An Editor acting as Maintainer should have shortcut options to publish
the file, as-is (via move) or as corrected (with upload), by changing
the status of the reviewed copy appropriately.
HTH.
--
/tj/
