March 2010 - gutvol-d - lists.pglaf.org

Re: Processing eTexts
by Bowerbird＠aol.com 04 Mar '10

04 Mar '10

carel said: > Yes, we have been doing a semantic dance ok, that's kinda what i thought. > I just feel that a final 'proofing' stage before release > would assist in locating errors that were either > missed or introduced by the processing. well, having "one more proofing" is _always_ a great thing. provided that somebody else is willing to _do_ it, that is... the acid test is whether you deem it to be so necessary that you will do it yourself. that's a nice way to help you decide whether the _cost_ of that additional proofing is _worth_it_, whether it will provide enough _benefit_ in the text accuracy. once you gain enough trust in your tool and its performance, believe me that you'll decide that it performs "well enough"... but yes, it is important to gauge the accuracy of your tool... my goal is less-than-1-error-every-10-pages, and my tool and workflow consistently delivers better results than that. > A human will do the processing and humans > can make mistakes and some of the mistakes > that could be made in what would be both > error and formatting processes could be quite grand. i don't worry about errors that are "quite grand"... they're easy to spot, and obvious to debug and fix. my experience is small errors are more troubling... > I feel that a second set of eyes can never be > a bad thing when it comes to something like this. that's easy to say until we ask you to be "the second set" on a million e-texts, all of which are almost perfect now. you -- and anyone else we ask -- will say "good enough". at some point, the benefit of greater accuracy isn't worth it. and then we say, "if the people reading this book because they _want_ to read it cannot find any errors in it, then that's their problem, but we cannot spend any more time having innocent people re-proof this book _once_again_ simply because there _might_ still be an error in the thing." again, i draw the line quite specifically. if a page has been looked at by 2 people in a row who could not find an error, then i certify that page as "good enough for the public" and stop looking at it. you can make it 1 person, or 3 people, or 4 people or 8 people or 22 people, whatever you like, but nobody would ever suggest we keep proofing a book forever. now, let me be clear that i understand that you only said "a second set of eyes" and not 22 sets of them. i agree... and that's specifically why i use the comparison method, because it gives us two sets of eyes on a book, essentially. > And, those with less experience (or no experience) > in shaping the output of a text may feel more confident > about doing the process if they know someone else will > provide a checksum for their work before it goes public. except that the _public_ provides that checksum for them. they constitute your "second set of eyes", your 3rd, your 23rd. > the text would be released to PG and then should be > placed in some environment that allows for editing it > to 'perfection.' it would be nice if p.g. did this. or d.p. but neither does. -bowerbird

2 1

Re: the d.p. opinion on "prerelease" of e-texts
by Bowerbird＠aol.com 03 Mar '10

03 Mar '10

bob said, to jim- > I'm not going to argue this any further with you, though. truth be told, you've haven't provided any argumentation anyway. you ignored jim's main point, to argue some legalistic crap which jim knows quite well and was never in dispute. indeed, it is precisely the troubling fact that material which _is_ "in the public domain" in a _legal_ sense, but is only _available_ for sale, because d.p. can't get it out the door, that's the point... and if you have nothing to say in regard to that point, then it's probably a good thing that you stop posting replies of any type. (except that you've illustrated jim's point about d.p. apologists.) -bowerbird

4 6

Re: do not listen, pray
by Bowerbird＠aol.com 03 Mar '10

03 Mar '10

i said: > thousands/hundreds/dozens and just to remind everybody, the solution is very clear, and has been for a very long time, ever since we learned -- by my careful analysis of the many d.p. experiments -- that p1 proofers find as many errors in subsequent proofings as p2 proofers and even p3 proofers do. (indeed, of the 3, the p2 proofers were the least good at locating the errors.) so it's obvious that we can move text to perfection by simply running it through p1 repeatedly. one problem with that -- as we've already found -- is that sometimes p1 proofers will change correct text to incorrect text. that problem can be eliminated easily with a policy to review and reconcile diffs. (this policy is easy to implement roundlessly, and will also serve to train up your low-quality proofers, so it's win-win.) the other problem currently with repeated p1 is that d.p. hasn't created an unambiguous set of proofing instructions -- i know, you'd think the need for that would be obvious -- and thus sometimes proofers "cycle through" corrections... (e.g., a first proofer dehyphenates, a second rehyphenates, a third asterisks the hyphen, a fourth dehyphenates, etc.) i haven't discussed the f1/f2 problem, because it's a mirror of the p1/p2/p3 problem. a quick-and-easy confirmation of the f1 by a subsequent f1 view, and we're off to the races. likewise, i have not discussed the postprocessing problem, not explicitly for the most part, because it's the microcosm of the thousands/hundreds/dozens problem, it certainly is. and once again, the problem is the workflow. by the time all of its pages have been proofed and formatted, the book should fall in place more or less naturally and automatically. the fact that it does not, in the d.p. workflow, is a shortfall... it indicates that the workflow is deficient in some major way. but correcting the postprocessing problems is relatively easy. you simply need to analyze each page that needs "finishing" and determine how the proofers could've provided that for it, and you modify the proofing instructions appropriately. easy. -bowerbird

1 0

Re: do not listen, pray
by cmiske＠ashzfall.com 03 Mar '10

03 Mar '10

1 0

Re: Processing eTexts
by cmiske＠ashzfall.com 03 Mar '10

03 Mar '10

1 0

Re: Processing eTexts
by cmiske＠ashzfall.com 03 Mar '10

03 Mar '10

1 0

roundlessness -- 009
by Bowerbird＠aol.com 03 Mar '10

03 Mar '10

in our "glass-is-one-quarter-full" news today, i note that rfrank has this to say about using reg-ex tests on his roundless site: > It seems to be a big win to make REs that usually are used > during post-processing available to users during proofing. now if roger would realize those reg-ex checks would be even _more_ useful if they were done in book-wide preprocessing, we could award him the "glass-is-three-quarters-full" prize... but let's be thankful for the huge progress he's made thus far. -bowerbird

1 0

Re: Processing eTexts
by Bowerbird＠aol.com 03 Mar '10

03 Mar '10

so, carel, i hope i didn't scare you away... ;+) -bowerbird

1 0

Re: the d.p. opinion on "prerelease" of e-texts
by Greg M. Johnson 02 Mar '10

02 Mar '10

From: don kretz <dakretz(a)gmail.com> > And what's the message that we send when we use someone > else's work (the book) that someone else scans, and > someone else collects, posts, and manages (TIA) and a > bunch of other people proof and/or format, and then keep > that accumulated and integrated value that's been generously > and freely provided for us to use locked away exclusively > for several years for one Post Processor to work on, > when they get around to it? Is something else happening to the work during this time-- like papers, etc., being written on it? -- Greg M. Johnson http://pterandon.blogspot.com

1 0

Re: the d.p. opinion on "prerelease" of e-texts
by Bowerbird＠aol.com 02 Mar '10

02 Mar '10

jim quoted someone as saying: > The negative reaction you're getting > is to your tone and tactics, not your news flash. now, i didn't see this quote when it came up originally, meaning that it probably came from someone who is in my spam folder, which would mean marcello or zora. i'm betting it's zora, the supreme apologist here for d.p. this is the kind of "blame-the-messenger" crap that they _love_ to do over at d.p. they can't argue with the message, so they talk about your "tone" instead, when it's their own damn fault that you had to adopt that tone in the first place, because they're bound and determined to ignore you totally. and that's because they are incapable of solving anything. and it's interesting to see _why_ d.p. can't solve anything, as the d.p. people here -- right on up to board member newby -- are unable to avoid dragging a thread off-topic. (although we must give marcello credit for a serious detour, by raising a phantom that files are being _stolen_ from d.p.) i mean, seriously, you want to witness something _amazing_, just take a look at recent posts in this thread, were _jim_ is the one who manages to (a) stay on topic! and (b) make sense. jim!, for crying out loud, the same jim who often has difficulty arguing his way out of a wet paper bag, and he's the one here who is doing the _best_, absolutely outshining all of the rest! so, of course, let's attack jim, and his "tone and tactics"... let me break it down to a nutshell... d.p. has thousands of proofers doing p1, the first proof pass. d.p. has hundreds of proofers in p2, the more-careful pass. d.p. has dozens of proofers for p3, the "final final pass" pass. i don't know about you, but i'd expect that a "final pass" will take a closer reading (and thus more time) than a first-pass, but assume p1 and p2 and p3 proofers all take the same time. somehow, however, the fundamental workflow at d.p. expects dozens of p3 people to keep up with thousands of p1 people... this is ridiculous on the face of it. and this is the main problem. or perhaps the _main_ problem is that the d.p. "powers that be" could seriously install such a ridiculous-on-its-face workflow... whichever way we look at it, it's purely and absolutely ludicrous. (quick, somebody please give me more synonyms for "ridiculous.") -bowerbird

1 0