Re: : the sitka book from fadedpage is now posted

rfrank has responded, over on the fadedpage forums, to the note i sent yesterday on the posted "sitka" book. as i might have expected, he fell on his sword and took full blame for the errors that were present... in some part, that's correct, because some errors _had_ been reported, and he simply failed to check the forum. but that's not really the proper take-away message here. a proofer can miss things, and still hit the "done" button, just because they honestly felt they'd caught everything. even the best proofer, with an accurate self-perception. 2 of the 6 errors that i reported were cases just like that. if the only person who's gonna serve as "back-up" for that proofer is the post-processor, that puts too much stress on the post-processor. that's exactly what d.p. has done, and that's why they have so few volunteers for that task... rfrank is willing to take on that stress, which is why he has fallen on his sword. but that's the wrong approach to take. rfrank is also improving his tools, so they catch those glitches. that's good, and it's part of the reason i reported these errors. plus he'd already improved his workflow, to catch _italics_... his improved workflow might work, _if_ the o.c.r. recognizes the styling correctly. but on any books with heavy formatting, going back and reinserting the formatting might be a real pain. a better approach, in my view, would be the one that rfrank started with, when he put up his site, which is to encourage the volunteers to do _both_ the proofing and the formatting. it's really _not_ that difficult to do both these tasks together. this is especially true if you give people a _formatted_display_, because then the obtrusive markup is cleared from the screen, and it's replaced by a rendering that resembles the actual scan. i demonstrated this technique with my own proofing site, and showed the additional strength that questionable words can be highlighted in a different color, maximizing the value of a flag. *** rfrank said:
But the most important thing I've concluded is that the majority of reportable errors in Sitka are chargeable to the post-processor (me) and not the roundless system.
see, there's the "experimenter bias" that i was talking about; he'd rather take the blame himself than blame his system... i believe in the roundless system too. i believe in it so much, so strongly, that i believe the evidence can stand up for itself.
We don't have nearly enough participation by a realistic cross-section of typical users here at fadedpage to conclude anything based on real science or real statistics. All I can say is that I am liking the roundless system more and more. It seems to be doing its part well and continues to improve.
there isn't a "cross-section" of "typical" proofers over at fadedpage, it's true. the proofers there are probably much better than average. and, as shown, even these better-than-average proofers can _miss_ errors. we're all human. we make mistakes. we need to be checked. -bowerbird

On 06-Apr-2010 18:48, Bowerbird@aol.com wrote:
a proofer can miss things, and still hit the "done" button,
What would happen if the proofing system occasionally *inserted* an error into the page and the double-checked that the known error had been found and fixed? eg: find a correctly spelled word with "m" in it and change to "rn". Choose from amongst a list of 100 similar things. It might be a little paternalistic towards the proofreader, but would give the automated system some basis for judging whether the proofreader had *actually* proofed the the page or not. It might also help to keep proofers paying attention. The final test for correctness is then that (1) the fake error is found and fixed, and (2) nothing else changed. I haven't been paying much attention to this thread, so apologies if you've all covered this ground already. ============================================================ Gardner Buchanan <gbuchana@teksavvy.com> Ottawa, ON FreeBSD: Where you want to go. Today.

This comes up all the time. a. It's socially unacceptable by acclamation. b. All you prove is that the proofer did or didn't catch an error you already knew about. On Tue, Apr 6, 2010 at 6:20 PM, Gardner Buchanan <gbuchana@teksavvy.com>wrote:
On 06-Apr-2010 18:48, Bowerbird@aol.com wrote:
a proofer can miss things, and still hit the "done" button,
What would happen if the proofing system occasionally *inserted* an error into the page and the double-checked that the known error had been found and fixed? eg: find a correctly spelled word with "m" in it and change to "rn". Choose from amongst a list of 100 similar things.
It might be a little paternalistic towards the proofreader, but would give the automated system some basis for judging whether the proofreader had *actually* proofed the the page or not. It might also help to keep proofers paying attention.
The final test for correctness is then that (1) the fake error is found and fixed, and (2) nothing else changed.
I haven't been paying much attention to this thread, so apologies if you've all covered this ground already.
============================================================ Gardner Buchanan <gbuchana@teksavvy.com> Ottawa, ON FreeBSD: Where you want to go. Today. _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

What would happen if the proofing system occasionally *inserted* an error into the page and the double-checked that the known error had been found and fixed? eg: find a correctly spelled word with "m" in it and change to "rn". Choose from amongst a list of 100 similar things.
The problems I see is that it would be hard for the system to "model" the kinds of errors that remain unseen in the book, thus it would train proofers to look for the wrong things. Also, if the system can introduce errors, it had better know how to take them back out. And its not fair to introduce errors on pages that a particular individual has already proofed, for example if for a given page I P2 and PP then I do NOT want to have to go into "paranoid mode" and look during PP for errors introduced after I had already P2'ed. Proofing *already* leads too much to the feeling that one is chasing one's tail, going around in circles, and "didn't I already fix that one already!"

if the only person who's gonna serve as "back-up" for that proofer is the post-processor, that puts too much stress on the post-processor. that's exactly what d.p. has done, and that's why they have so few volunteers for that task...
Agreed that PP at DP is stressful, in part because of the high standards expected there of PPs -- don't see how one can meet their expectations without at least doing a SR pass oneself, which supposedly isn't required. But to me a more fundamental part of the problem is that it is relatively easy to start a book at DP and then expect someone else to fix the "problems" at the other end, leading a PP to stare at a potential PP book and say "why in g--- name would someone have started this book project in the first place???" Again, its pretty easy to find a book project where one can pretty easily predict it will be read 1000 times more than some other book. Which one would you rather PP? A book that gets read 1000 a year, or a book that gets read 1 time a year? If one can "solo" a compelling book myself, or "PP" a drab book at DP, which would you choose? The other problem is if you PP a book you haven't lived with through the entire process then you "start from scratch" with your knowledge of the book, its author, its proofing problems, etc, and getting up to speed IMHO is almost as painful as doing the whole project "solo" in the first place. Don't get me wrong, I *love* the feeling of having others proof one's choice of books at DP and say "wow, this is a really cool book to be proofing!"
participants (4)
-
Bowerbird@aol.com
-
don kretz
-
Gardner Buchanan
-
Jim Adcock