feature request: reshoot + insert-spread stats

Bug #875753 reported by paul.n
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Scribe2
New
Undecided
Unassigned

Bug Description

The act of reshooting or inserting a spread should be viewed as an inefficiency within the book scanning workflow. Currently we are not tracking this inefficiency even though it has an impact on our overall production figures. If we knew the frequency of these actions, and where they were coming from, we could take corrective action as necessary.

Proposal:

We should 1) track these actions and 2) provide clear reports to let us know where the reshoots/inserts are coming from.

Notes:

* Currently the Folio workflow makes use of reshoots in order to capture images at the foldout station. There is a new folio workflow coming soon that should remove the need to use reshoots in this fashion

* It would be great if the report could have a high level view (all centers), history (eg. % +/- over previous week), and the ability to drill down to an individual center report. I can draw a mock-up if needed when we're ready to start discussing this

Thanks!

Paul

Revision history for this message
paul.n (paul-n) wrote :

Just realized there was a dupe request on the development plan wiki (https://wiki.archive.org/twiki/bin/view/BooksGroup/DevelopmentPlan)

The first request says :

"Graphite visibility on inefficiencies --
Wtih graphite, we can easily visualize any actions which we consider inefficient (deleting a book, re-republishing, gutting, etc.) and use this data to help stamp out these inefficiencies and investigate root causes"

While Graphite may or may not be the right tool for this, I do think expanding the report to more broadly track inefficiencies is the way to go....

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.