Round reform

From DPWiki
Jump to navigation Jump to search

Over the years, people have proposed significant changes to DP's system of rounds. Much of it amounts to relaxing one or more constraints that the code currently imposes.

Constraints:

These are constraints of the current system code & documentation.

Constraint 1: One round at a time

At any given time, all of a project's pages must be in the same round.

In fact, in the current system, a Round is an attribute of a Project. Pages are associated with Rounds only by virtue of the Project to which they belong.

The existence of this constraint means that a) we need to split beginner and qual projects into small chunks in order to reduce their time-in-round, and thus their time-to-feedback/diffs; and b) when missing pages are discovered, they have to go through as a separate project, at least until they catch up to the main project. In each case, the duplication at one end and the merging at the other end take time (CP/PM and db-req), and leave husk projects that cause problems of their own.

Moreover, this constraint effectively prevents experimenting with schemes such as this. (You could do it by splitting the project, but see above.)

If we eliminated this constraint, allowing a project's pages to be spread over more than one round, ...

  • We could no longer talk of the project being in a single round. Would all the in-round project-states collapse into one amorphous "somewhere in the rounds" state? Instead of searching for projects in a particular round-state, we might have to support searching for projects with (some) pages in a particular round.
  • How would pages advance from one round to another? It could be that as soon as the proofer clicks "Save as Done", the page would be whisked off to the next round. However, that might lead to some frustration. Probably there would be a "grace period" during which the proofer could go back and change something in the page. Perhaps the length of the grace period would be a property of the project. What would be a reasonable default? Would the grace clock restart each time the user went back and re-saved?
  • What about queues? A queue of projects waiting to be released would still make sense for P1, but not for subsequent rounds. Instead, would those rounds queue individual pages, releasing them (potentially) one at a time?
  • Maybe we shouldn't eliminate the constraint entirely. Maybe some projects would observe the constraint, and some would ignore it. Maybe a project could have a mix of styles over its lifetime (e.g., pages can proceed on their own from P1 to P2, but then the project as a whole goes to P3 or F1). What does this mean for all the preceding questions?

Constraint 2: All pages the same

Over the lifetime of a project, all of its pages are proofed (once per round) in the same sequence of rounds.

The problem with this constraint is that some pages get more attention than they need (which presumably is a waste of proofer time) and some get less than they need (which presumably results in lower quality material going into PPing, which means lower quality end product or else more work for the PPer).

It's also possible that this constraint contributes to bottlenecks in the system.

If we eliminated this constraint, ...

  • What would determine the sequence of rounds that a page goes through? (Possible answers: Page metadata might pre-determine some rounds that the page needs. We might dynamically estimate the current "quality" of the page (and thus whether it needs further work) based on the error-finding skill of the proofers that have looked at it so far; see Proposal 1.)
  • What should the Page Details (Images & Diffs) table look like?

Constraint 3: Chain

For any given page, the proofings form a chain, with the output of one becoming the input of the next.

This isn't really seen as causing problems per se, but it does prevent experimenting with alternative schemes, such as "do two independent proofings and merge the results". (See Proposal 3.)

If we eliminated this constraint, ...

  • How would the PM specify the details of a non-chain scheme? Or would we simply allow the PM to pick from a set of canned schemes?
  • As with Constraint #2, what would the Page Details table look like?

Constraint 4: States are Assigned, not Derived

There is currently a complex array of rules for assigning States to Projects (not Pages). This makes it impossible to determine the sequence of steps dynamically based on cumulative information.

Proposal 1: Pseudo-Roundless System

2 UBER rounds (Proofing/Formatting) where each page is read at least twice and possibly many more times are needed until a certain "confidence level" is reached about that page.

Proofing round flow

Book enters Proofing round

  • Each page is proofed just like now. Two items are saved. The proofed text and a "confidence in proofer" number generated at save time. CiP = There are many proposals for how to generate this number.
  • The CiP could also signify Confidence in Page. It's really the page whose future tasks need to be determined, and the Proofer is only one of the possible considerations.
  • This value could also be (and perhaps should be) determined on the fly, rather than stored. There are dynamic values (time since previous task completed, cumulative information about other pages in project) that would contribute to CiPage.
  • Once all pages are proofed, or at any other time, the system looks at each page's CiP score. If that value is greater than a number chosen to ensure that at least 2 people see each page it is considered "done". The value we look for or the way CiP is calculated may need tweaking.
  • Any pages not meeting minimum CiP score are recycled and project is put back into the proofing round for another go. Or, based on the score, the page could just be presented to another (appropriately skilled) proofer.

Formatting round flow

Same as proofing round just look for formatting instead of proofing.

There will possibly be new types of rounds as well - table rounds, illustration rounds, etc. Perhaps the binary Proofing/Formatting distinction can be softened.

Pros

  • As time goes by, more pages will be marked complete, but "hard" pages will be seen by more and more eyes. Each page is theoretically seen as often as needed.
  • The round system is still there behind the scenes and a lot of code could be reused.
  • Begin/mentor system can still work by change project to mentor state after first pass through the round.
  • Removes the "caste" system that has been engendered by the P1/P2/P3 with rising requirements. From the outside, everything looks the same and everyone can get in. The system makes a determination behind the scenes on how skilled you've been so far.
  • As other "meta data" rounds are brought on line, they could be added at the "UBER round" level and fit into the existing system with little disruption.

Cons

  • We can't guarantee every page is seen by a P3 level proofer. There is some argument over whether 3 "good" proofers are equal to 1 "excellent" proofer.

Proposal 2 - Template Driven Workflow

Several workflow templates are provided from which to choose. Each template specifies a default sequence of steps for the pages in a project. Each page is assigned its own workflow, which initially is a clone of the selected Template.

Then, on a per-page basis, the template could be overridden for pages with special needs.

Proposal 3 - Parallel proofing

Each page is proofed by two proofers separately, then a third person merges the pages together, hopefully eliminating any errors from one with the fixes in the other.

Past Discussions

Here's an (incomplete) list of links to discussions in the forums:

See Also