Re: [Wikisource-l] Proofreading
On Mon, Oct 12, 2009 at 9:45 PM, Syagrius syagr...@gmx.fr wrote: This problem of proofreading IPs concerns the whole Wikisources. If all Wikisources don't have the same rules, what it the point to make a comparison with figures and graphics. For example, de.WS doesn't want to mark the empty pages as 'Without text', as en.WS and fr.WS did. It distorts the statistics... IP edits do not distort the statistics. The statistics are about the content of the pages, rather that who did the edits. If de.WS is confident that IPs can be trusted to validate pages, that means that their project community is better able to monitor their IP edits. I think allowing IPs to validate pages is sensible if the community is able to monitor it. I do not understand why de.WS does not want to mark empty pages as 'Without text'; that sounds like a different issue, and one which would distort statistics. Perhaps a de.WS contributor could explain the reason in a new thread; maybe we can learn from de.WS, or agree to disagree. -- John Vandenberg ___ Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
[Wikisource-l] Proofreading
I think German Wikisource has a rather high quality standard compared to a lot of other Wikisource projects. There are several projects which don't do proofread at all or request scans. That is where we should start to unify the Wikisources. German Wikisource is also one of the project which have the longest time experience with PR. In all this time we never had problems with IPs proofreading. The community is small and it's usually the same few people. Our contributions by IPs are overviewable (check Latest Changes for it) and AFAIK we never had miss-use by IPs. That's why I have problems to understand why a plugin gets developed in a way that is more secure but less user-friendly when there never were problems with security but some with user-friendlyness (e.g. currently you should not be colour-blind if you want to change the status after proofreading because there is no description of the radio-buttons; I don't consider having to create a special monobook as user-friendly, especially considering that not everybody is able to do that just like that). Next thing: if somebody wants to cheat he will cheat. Switching of IPs does not bring anything since there is sockpuppeting. It actually causes the opposite. While we can see the IP-adresses and can check if they are from the same range, we can't do the same with accounts. Only checkuser can do that and German data privacy law is rather rigorous when it comes to that kind of activity. It is not at all like on Commons (the only other project where I have CU-experience), where you have a suspicion and ask a CU to check it. On German projects (and that is something we can't change) the hurdle is much higher. For those who speak German, you could check the CU-request-page at German Wikipedia to see what kind of information collection is necessary to get a CU ([ http://de.wikipedia.org/wiki/Wikipedia:Checkuser/Anfragen]). So actually the chance to detect a cheater is now much lower than before. To the suggestion of 'searching a new developer': I don't know how much quality ThomasV produces in his code (comments, format, speaking names for variables/...; bugs are normal, but the amount of bugs in each release is not a good sign), but one thing I know from several years experience: taking over the code of somebody else is no fun at all. Often enough I ended up rewriting the whole code. Getting a second developer to work on the same plugin is a bad idea from my point of view as a developer, even if it is in a second branch (to prevent conflicts). It usually takes months until the first working output gets generated (one that does not cause troubles at zig other places, because you had not yet had the overview and did not know that changing something at this place will cause consequenses in a totally different area). Sorry, but I suppose that Birgitte does not know what developing a working software (not speedily hacking some emergency-tool) includes, because we are having the problem now and not in half a year (just a estimate as I have not seen the sourcecode of PR2). And we are stuck with PR2. It IS a good idea, and it is more encouraging for those who do the proofreading, because they can do one page now and then later another without a huge text complex. So in the last few years German Wikisource has transfered a majority of its projects to this solution (especially the large ones). Thus switching off the PR2-extension is not an option, since it would break most of our projects and converting them back would probably take several man-months (even with the help of bots). We don't want to get rid of PR2, we just want to be able for everybody to use it, not discriminating a few users who for whatever reason prefer to work without an account. They are as valuable to the German community as registered ones. Sorry, that got a bit longer, so I will stop now. Regards, Cecil ___ Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
[Wikisource-l] Proofreading
@teakA 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_70 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:Korrekturlesenaction=history 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_001.jpg or http://de.wikisource.org/wiki/Seite:Topographia_Alsatiae_%28Merian%29_012.jpg 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
Re: [Wikisource-l] Proofreading
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 330.gif___ Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
Re: [Wikisource-l] Proofreading
--- On Mon, 10/12/09, Michael Jörgens joergens@googlemail.com wrote: From: Michael Jörgens joergens@googlemail.com Subject: Re: [Wikisource-l] Proofreading To: discussion list for Wikisource, the free library wikisource-l@lists.wikimedia.org Date: Monday, October 12, 2009, 2:00 PM 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. *** The thing you are missing is that this is not what ThomasV wants vs. what de.WS wants. It is making the tool compatible with the workings of multiple Wikisources or one Wikisource. That he has chosen to no longer spend time on custom configurations for the one Wikisource that wants it differently is his choice. It is his time after all. Regarding advance communication. Certainly there must be advance copies of these updates out there in test environments if you were to look for them, just as there is with any code updates. No one makes such advance announcements about any changes in code that I have ever seen. At least no one tells en.WS. Yet I am sure the information is being discussed and tested somewhere in development circles. I can't understand why ThomasV should be obliged to go around to all the different Wikisources announcing his plans when no other developer does this. While I agree that communication about these things could be better, it is not a fault against ThomasV but rather a systematic issue. There should be a central place to follow all updates in the pipeline. (Maybe there even is one already, but I don't know about it) Birgitte SB ___ Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
Re: [Wikisource-l] Proofreading
Thanks Thomas for your big reply I have seen it after I've written my last reply. The first thing is, the rule of proofreading twice is one of the lowest level to achieve quality. The question wether it must be enforced by software or not. If it would be easy to configure this problem will be solved. The default setting should be software control enabled. The solution we had with horizontal and vertikal layot (nearly the same as a fork) was not the best at all - you mentioned the problems correctly. The new solution to incorporate as an integral part of the system is perfect. Using horizontal on a pivot 24 monitor and vertical on 22 widescreen is perfect. The next thing. OK your not the guy who decides when a code update goes alive, but if you could tell everbody that there is a code change to come in the near future, because you've finished your work for the next update, together with an information what is new or what will change, would help to inform the people in advance that something will happen. Frustration will be minimised by that. A link in the scriptorium to the information would be enough. The information should be in english, because we are laking french speakers, but even german will fit :) One of the things we are really missing are programmers with good kowledge of js. We will have a look at your idea within the bugzilla 20817#c7 an may come up with a lot of questions. I could understand your frustration, because of the ''dictating local admins. I m sure that I am one of these bad guys. But we have to cope with the frustration of our community members, when things don't work the same way they are used to, or when the aren't allowed to proofread any more. And things like that su... If there is information in advance, i could say didn't you read the scriptorium, instead of searching for the reasons. After some research - uups there was an update, I for my person need in such a situation someone to blame it on, especially if this is not the first time for this special extension. Hopefully understandable. We should find a way of cooperating. I think when the information flow increases, and you give us hints (preferably in advance) how we can achieve our goals with your new releases, we could have a much better climate. A lot of good things in your extension will not be recognised, because of the things were are upset And I agree ThomasV it would be more than foolish working on a fork - and loosing the future enhancements - or on a new proofread extension (Version 3). There is an existing system which works (except for our principal differences) really well. And one configurable extension for all is the only usefull system. And if you can tell me names of js specialists which are *active*administrators on de.ws I would be really happy. greetings joergens.mi ___ Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
