@teak"A wake up call to the de.ws quality guru's: where would your quality be without the proofread tool?"
At least at the same point or better. We have introduced the process prior to the most ws's and we have been using a tool call profread before. (Better because, we converted a lot of projects to pr2, we lost time needed for that in the normal correcting porcess. We decided to do so and we don't blame anyone on that used time. But you hopefully understand, that you will get upset, when such converting actions are hampered by single point decisions and sillies in design or coding of the tools)
This tool is still working as you can see in this porject. http://de.wikisource.org/wiki/Die_Ursache_des_Einschlagens_vom_Blitze
Here a single page. you can use the button "Korrekturlesen", to see how it works. http://de.wikisource.org/wiki/Die_Ursache_des_Einschlagens_vom_Blitze:Seite_...
For convienence (index Pages for example or easier setup of an project, and for coworking with other ws projekts, we accepted after some discussions ThomasV extension which we normally call proofread 2. Most of the hampering processes where introduced and detected after we decided to use this extension. The first version was nearly without any curious restrictions.
But the way how to proofread http://de.wikisource.org/wiki/Hilfe:Korrekturlesen , and the rules started in august 2006 in written form as you can see here http://de.wikisource.org/w/index.php?title=Hilfe:Korrekturlesen&action=h...
after discussion and defining our goals. - No text without scan, - older projects without scans will be reworked with scans as soon as possible
If you are keen in statistics We have 154555 pages at de.ws roundabout 100.000 in pr2 and 55000 in older forms in both forms more than 60 % are at least corrected once and 30% proofread twice. The percentages are equal distributed to both methods.
And we know where our quality is. Quality is a question of the attitude of mind of the community. Only if I'm lacking a good community, then there is a need for a Big-Brother setup.
Adressing the without text question. There are two answer for that, First, we are not used to do so, and normally we see no need for difference between bookpages, This rule was introduced at a time we already had accepted proofread 2 and we had a lot of discussion why we cannot set the ready state.
Second, a lot of books have pages consisting of a picture and on ore two lines of text - simply giving a title to the picture. In our rule setup, people are allowed, to put such pages immediate to the ready state. For example http://de.wikisource.org/wiki/Seite:Anfangsgr%C3%BCnde_der_Mathematik_I_A_00... or http://de.wikisource.org/wiki/Seite:Topographia_Alsatiae_%28Merian%29_012.jp...
And ''without text'', will most of the time interpreted as without usefull contents.
Sincerly
Thanks, Michael Jörgens, for your extensive explanation of the adoption history of pr2. I am not quite convinced that the project would have been better off without the pr2, even if the time taken to convert to the new tool. From what I could see and understand about the original tool, it doesn't seem to be close to proofreadpage in its ease of use and logistic matters, which both would contribute to the rate of quality improvement. Some more statistics would be necessary (for the rate of proofreading) to make definite assertions about the usefulness of the tool in the de.ws realm.
In any case, you are certainly right about the crucial factor of dedication to the quality and building the community around it, and I applaud the de.ws community on the marvelous state of the project. I'm also happy to admit that I stand corrected in the way my words may have implied that pr2 is the sole driver of quality in de.ws.
However the way the de.ws community is handling the issue on this mailing list causes further animosity between the de.ws and the rest in the WS world. I agree that the proofreadpage extension had its share of nasty bugs and some of the updates severely broke compatibility with the prior proofreading process, and on more than one occasion this was done without any warning or even least bit of effort towards providing documentation, but calling names and shutting comments out of the discussion will not improve all that.
At this points (assuming the channel of communication between ThomasV and de.ws community cannot be established), if the version before the last update was satisfactory for the de.ws community, forking it and having it activated instead of the proofreadpage extension may be the best way out. And this will provide a time window before compatibility issues and/or alternative development path for the new branch can be sorted out.
teak
On Mon, Oct 12, 2009 at 6:15 AM, Michael Jörgens joergens.mic@googlemail.com wrote:
@teak "A wake up call to the de.ws quality guru's: where would your quality be without the proofread tool?" At least at the same point or better. We have introduced the process prior to the most ws's and we have been using a tool call profread before. (Better because, we converted a lot of projects to pr2, we lost time needed for that in the normal correcting porcess. We decided to do so and we don't blame anyone on that used time. But you hopefully understand, that you will get upset, when such converting actions are hampered by single point decisions and sillies in design or coding of the tools) This tool is still working as you can see in this porject. http://de.wikisource.org/wiki/Die_Ursache_des_Einschlagens_vom_Blitze Here a single page. you can use the button "Korrekturlesen", to see how it works. http://de.wikisource.org/wiki/Die_Ursache_des_Einschlagens_vom_Blitze:Seite_... For convienence (index Pages for example or easier setup of an project, and for coworking with other ws projekts, we accepted after some discussions ThomasV extension which we normally call proofread 2. Most of the hampering processes where introduced and detected after we decided to use this extension. The first version was nearly without any curious restrictions. But the way how to proofread http://de.wikisource.org/wiki/Hilfe:Korrekturlesen , and the rules started in august 2006 in written form as you can see here http://de.wikisource.org/w/index.php?title=Hilfe:Korrekturlesen&action=h... after discussion and defining our goals.
- No text without scan,
- older projects without scans will be reworked with scans as soon as
possible If you are keen in statistics We have 154555 pages at de.ws roundabout 100.000 in pr2 and 55000 in older forms in both forms more than 60 % are at least corrected once and 30% proofread twice. The percentages are equal distributed to both methods. And we know where our quality is. Quality is a question of the attitude of mind of the community. Only if I'm lacking a good community, then there is a need for a Big-Brother setup.
Adressing the without text question. There are two answer for that, First, we are not used to do so, and normally we see no need for difference between bookpages, This rule was introduced at a time we already had accepted proofread 2 and we had a lot of discussion why we cannot set the ready state. Second, a lot of books have pages consisting of a picture and on ore two lines of text - simply giving a title to the picture. In our rule setup, people are allowed, to put such pages immediate to the ready state. For example http://de.wikisource.org/wiki/Seite:Anfangsgr%C3%BCnde_der_Mathematik_I_A_00... or http://de.wikisource.org/wiki/Seite:Topographia_Alsatiae_%28Merian%29_012.jp... And ''without text'', will most of the time interpreted as without usefull contents.
Sincerly _______________________________________________ Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
Thanks *teak* for you trying to moderate that problem. Even if we are complaining about ThomasV attitudes, in general we (I hope I speak for the majority of the community- but I'm sure about that) like the tool, and we also would like to take benefit of it's advantages if possible even in the future. In general terms spoken it is an improvement in comparison to the old tool. That is the reason why we convert our old projects.
ThomasV basic ideas in the human interface of the tool are *not so bad [?]*. His new ideas with the index-page are good to (smaller quirks can be eliminated).
Our problem is, that there is no communication in advance what will happen and when. Every time we see the reaults after the change. The second thing is that ThomasV exactly knows what *our key points* are - they have been discussed to often, everytime he made an incompatible change in his tool - but from my personal point of view is not willing to find a solution which would be best for both sides.
I can accept, that he is searching for a way to assure a high level of quality - whether his way is the best I don't know. With a little bit of effort and having an open ear to all communities, I think he would be able to put some configration options in, that every community is capable to configure the tool according to their needs, without loosing quality. At the moment we are happy, that our IP's are willing to give us an excellent quality ( As I statet somewhere else, I know at least 3 of them who are working as an IP on a regular base for very personal reasons, this 3 all have academic background in ancient history). But - * I hope not* - there may be a future where there may be a need for excluding IP's because of the general behaviour of the IP's.
Maybe that we see more or different problems, because if our history. We are doing now a lot of work, especially in the process of the second proofreading, and we are converting a lot of older projects to the new standards.
I think, if we got more information in advance what will happen, if there is a possibility to discuss new features in advance (there is no need to discuss them in german), having the possibilty to give hints which things should be configurable, things would run smoother. Even the default configuration may ThomasV way of thinking. if we can deviate in some crucial points by configuration. (IP'S setting the ready state)
Even tests before release with the german ws are possible, if we get asked in advance an it's agreed by the communty (getting the agreement is not so hard).
Just for information, we had a really hard discussions about horizontal and vertikal layout. With nearly the same trouble. Now the layout ist configurable by the community. Nearly the same thing about the pre- and postamble (Thomas didn't see our needs of acces for adaption of older porjects) of each page, now there is a common solution. We had also a big discussion about showing the state in different colors. I for my person was massivly against it. But after the implementation by ThomasV, showing this colors only on the index page, I'm now happy about that, because I can check the state of projects on the index pages. In this case the misunderstanding was on my side.
_______________________________________________
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
wikisource-l@lists.wikimedia.org
