*Given what has been said before, I see two options, [...]* Have you actually read anything that has been said before? We don't accept the discrimination of the IPs in our community. The thing your code-change forced us to do was that now always a registered user updates the status for the IP and then can not proofread that page himself anymore. The IPs simply note in the edit summary that he has done proofreading and the next registered user fixes the status. So any option that does not contain the possiblity for us to enable IPs doing proofreading is no option. Your other code changes made the extension just less practical, but the IP discrimination is the huge blocking point. IPs are much more reliable than bots. At least in the German community the IPs have done no damage, but the bots have so a lot and repairing this takes shitload of time. So your so-called option nummer 1 is unacceptable and that was said already several times. It would discriminate reliable users and force us to use a unreliable and error-prone mechanism. Oh, and just to enlighten you: a registered account does not mean a stable identity. I know several people who share their well-established accounts to camouflage their activities for real-life-reasons.
To your second option: how long will that work? With your next update you will most probably break all local programming again. And who should repair it each time after it is broken? We now have found a user who can program in php (that's why we have the patch), but at least I don't know anyone for JavaScript since Xarax is gone. Or can you guarantee that with your future updates you will not destroy it or that in that case you will repair it again? And how are your plans for future development look like? Do you actually have any plans to let us know now what features/surprises we can expect in the future? After all until now your concept was to let us know about a feature on the day of the update, usually at a time when we already noticed that there had to be changes because something didn't work
In any case (your second option or us forking the extension) I would be very much for getting rid of the buttons. The reasons for it I already mentioned even though there was no reaction to it. They are after all very unfriendly when it comes to one very important principle of web-programming: web accessibility. Even if you are not disabled you have to click on them and look in the edit summary to learn what they do. But if you are disabled then they are a nightmare. And yes, I already had to explain to a user how to find them by theoretically parting the monitor in fields and telling the user in what field to look. And he was not even colour-blind in which case the buttons would loose any worth anyway (two buttons are red and one is green, by far the most common trouble-colours of colour-blindness).
Cecil
2009/11/18 ThomasV thomasV1@gmx.de
As I already said in the bug, I do not want to enable this patch. Here is why.
First, I never said that I would accept a patch. I said that what these de.ws users want can be achieved by locally configuring their wiki, and that some of their admins should be able to do that, because they did it in the past. This does not require a patch. All they need is to change their local javascript, and to use again their former quality template instead of the pagequality tag. If they do that, of course, they will no longer be part of the common quality rating system. But my point is that this patch is, technically speaking, useless.
On the other hand, if this patch is activated, then the current quality rating system will simply break apart.
If the patch is activated, you do not need to be very smart to predict that other sub-domains will find it unfair not to have what the Germans have, and that they will soon request the option to be enabled on their domains. However, these other domains do not have the same level of discipline and organization as de.ws. The Germans are right to be proud about their quality standards; they have achieved a superior level of quality, and I do not question that. I do think, however, that the only thing that threatens the superiority of de.ws is ProofreadPage.
One fundamental component of the high quality standard achieved at de.ws is the double proofreading rule. This rule has been adopted years ago at de.ws, and enforced by admins. In my extension the same rule is enforced by software. However, if the patch was activated, the rule would no longer be enforced. It is obvious that some users, at some subdomains, will not comply with the double proofreading rule. These users will not necessarily do that because they want to break the rule (bad faith), but simply because they do not always know about it (lack of communication). Indeed, in the other Wikisources, we know that users have more freedom to start with a project, to work freely on it and to rate their own work, without communicating with others. If the double proofreading rule is not enforced by software, then we will progressively see users making their own interpretation of the meanings of the quality buttons. This already happened at fr.ws with the TextQuality template. And once users do not share the same interpretation of the quality levels, communities will follow; Each subdomain will decide of its own proofreading rules, different from the neighbours.
If this happens, the credibility of the extension will be damaged, and so will be the credibility of Wikisource. Instead of sharing a common "currency", each Wikisource will have its own currency, and their credibility will depend on the level of discipline and organisation that can be achieved by each community. There will be a difference of credibility between the subdomains where the community is able to strictly enforce double proofreading, and communities where admins do not like to play the police. Just like there used to be a difference between the german mark and other european currencies.
I suppose that some de.ws admins have no problem with such a situation. After all, they are very proud about their superior quality standards, and they have long enjoyed the idea of being number one. However, with the progressive generalization of ProofreadPage, other subdomains have made a big step forward in terms of quality and trustability. This simply threatens the superiority of de.ws.
The goal of my work is to improve the quality standards of all Wikisources, and to bring them at the level that was formerly achieved only by de.ws. I do believe that it is the community's best interest to use the same proofreading system, so that readers do not need to worry about the differences between text proofread at de.ws, fr.ws or it.ws.
So long for my reason to reject this patch.
Now, I cannot force de.ws to use the pagequality system of ProofreadPage. The decision remains with them. If they do not want to be part of it, they are free to leave it.
They can do this without the patch; the only thing that they need is to properly configure their wiki, as I already explained. However, one thing that I now realize, and that I did not know before, is that they might not have the technical capability to do this, because the de.ws admin who did it in the past is no longer active (xarax), and because nobody else did it so far. They have another admin with programming skills, but apparently he does not want to do it either.
So, here is what I suggest. Given what has been said before, I see two options, and I am willing to offer technical assistance for one of them.
The first option is that de.ws remains in the common page quality system, and that they use a robot to mark pages that have been validated previously. Indeed, the main reason why they complain is that the software restriction slows them down when converting already validated text to the proofreadpage format. I already said in the bug report that it is possible to link the quality buttons to a robot that would validate the pages. I am willing to program this for them, because I realize that their admins are not able or not willing to do it. However, if I do this for them, they should in turn accept the fact that users need to log in in order to modify the status of pages; the pagequality system needs users that have a stable identity, and IP adresses are unstable.
The other option is that de.ws completely stops using the common pagequality system. In order to do that they would need to convert the PageQuality template (or <pagequality/> tag) to the formerly used Seitenstatus template. A few months ago I converted all the pages at de.ws to use PageQuality instead of Seitenstatus, with a robot. They just need to do the reverse operation, which can be done in a few days. Once this is done, they can reprogram the quality buttons so that IPs can use them too, or they can just use the template without buttons, as they did a few months ago.
It goes without saying that I am strongly against the second option, and that I will not help them do that. I think that it would be much better if all Wikisource subdomains kept using the same quality system. When a book is proofread at Projet Gutenberg, there is no difference in the way it is proofread, whether it is written in English, French or German. Why should it be different at Wikisource ?
Thomas
Cecil a écrit :
Sorry, to once again start the same topic on this mailing list, but the last discussion ended without bringing a solution for the German wikisource community.
To bring back to your memory what this is about: German community wants to be able to allow IPs to also do proofreading as they could do before ThomasV disabled this a few weeks ago and declared that he will not programm solutions for German WS anymore: /Even if I am not willing to program an extra solution for de.ws <
I know that some de.ws http://de.ws admins are perfectly able to
program the
solution they want. They do not need me for that. They know it.
/
So after weeks of following IPs to update the status for them finally another programmer decided to help and started to look through ThomasVs code. He created a patch which would by default disallow IPs from proofreading, but in case that a community trusts his IPs would give them the change to locally configure the extension so that IPs can once again proofread.
So this patch seemed like a great solution. It would not change anything for any of the other Wikisources (unless they want it). But our programmer has no access to SVN and can't upload the patch himself and so we once again stand in front of a block: ThomasV is not willing to accept this patch (which probably means that even if our programmer would be able to update the code ThomasV would revert the patch).
So I would like to know the opinion from the other communities. Is it acceptable for you to add a patch that does not change anything in your system or would you prefer that the German community forks?
Cecil
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l