[SPAM] re: any arguments against "free-range" proofing?
nobody came up with many objections to "free-range" proofing... *** keith said:
I do not see anything truely speaking against such a system. The only problems are the administrative tasks involved.
thanks for the feedback keith...
1) you have to track all this.
i think that's pretty easy. when they hit the "save/confirm" button, if there were changes made, then they have _saved_ a new version, which will then set up a "diff appointment" with any prior proofers. or, if there were no changes made, it's registered as a "certification". once a page has two consecutive certifications, it's marked as "done". (any free-range proofers can still proof the page, of course, but once all the pages are marked as "done", the book is ready to be finished.) the "diff appointment" can be resolved in one of three different ways. the first proofer can say "i goofed", or the second one can say "oops!" either of these actions mean one person loses points, and one gains... the third resolution -- when they can't come to a mutual agreement -- comes via a referee, who decides a winner and rewrites documentation so the issue doesn't come up again. points might or might not be lost. (or deducted points might be doubled, if a ref was called unnecessarily.) the purpose of diff review is simply to train correct proofing and coding. people who continue making bad changes might be asked to leave, but i don't anticipate it happening very often. people like to do a good job.
2) keep everything store somewhere
each subsequent saved-text will be stored, for subsequent diff tests. upon saving, it will be compared to all of the earlier saved versions, to see if it is a revert to an earlier save. if it is, it will be dealt with appropriately, depending on the resolution of that earlier version... any proofer will be able to step through all the versions of each file, viewing which changes were made. i expect that some proofers will specialize in this particular tactic, making sure every change is good.
3) keep everything in sync
i've had my share of sync problems in the past, coding e-book authoring-tools, so i think i know where all the pitfalls are now. :+) which is not to say i won't fall in some of 'em again sometimes. but i can usually figure out pretty quickly now what i did wrong.
you will need an authority/ies that finally certify that a page satisfies your criteria as being done.
that's easy. if the text is .zml that creates .html which looks like the page-scan, then that satisfies the criteria. the proofers view .html output, so can see for themselves.
Some may call it a administrative nightmare, but it should be workable.
yes, i think i can make it work. again, thanks for the feedback. -bowerbird
Hi BB, You are basically, taking the standard approach to the problem. You did not need to explain. More interesting would be how you track everything. I believe you will need some form of a database for the points system, who made what version, when, is a page done, etc.. I wish you luck. Looks promising. regards Keith. Referees will have to special rights for changing it. Am 14.03.2010 um 22:42 schrieb Bowerbird@aol.com:
nobody came up with many objections to "free-range" proofing...
***
keith said:
I do not see anything truely speaking against such a system. The only problems are the administrative tasks involved.
thanks for the feedback keith...
1) you have to track all this.
i think that's pretty easy. when they hit the "save/confirm" button, if there were changes made, then they have _saved_ a new version, which will then set up a "diff appointment" with any prior proofers.
or, if there were no changes made, it's registered as a "certification". once a page has two consecutive certifications, it's marked as "done". (any free-range proofers can still proof the page, of course, but once all the pages are marked as "done", the book is ready to be finished.)
the "diff appointment" can be resolved in one of three different ways. the first proofer can say "i goofed", or the second one can say "oops!" either of these actions mean one person loses points, and one gains...
the third resolution -- when they can't come to a mutual agreement -- comes via a referee, who decides a winner and rewrites documentation so the issue doesn't come up again. points might or might not be lost. (or deducted points might be doubled, if a ref was called unnecessarily.)
the purpose of diff review is simply to train correct proofing and coding. people who continue making bad changes might be asked to leave, but i don't anticipate it happening very often. people like to do a good job.
2) keep everything store somewhere
each subsequent saved-text will be stored, for subsequent diff tests.
upon saving, it will be compared to all of the earlier saved versions, to see if it is a revert to an earlier save. if it is, it will be dealt with appropriately, depending on the resolution of that earlier version...
any proofer will be able to step through all the versions of each file, viewing which changes were made. i expect that some proofers will specialize in this particular tactic, making sure every change is good.
3) keep everything in sync
i've had my share of sync problems in the past, coding e-book authoring-tools, so i think i know where all the pitfalls are now. :+)
which is not to say i won't fall in some of 'em again sometimes. but i can usually figure out pretty quickly now what i did wrong.
you will need an authority/ies that finally certify that a page satisfies your criteria as being done.
that's easy. if the text is .zml that creates .html which looks like the page-scan, then that satisfies the criteria. the proofers view .html output, so can see for themselves.
Some may call it a administrative nightmare, but it should be workable.
yes, i think i can make it work. again, thanks for the feedback.
-bowerbird _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
participants (2)
-
Bowerbird＠aol.com -
Keith J. Schultz