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 <http://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
> ------------------------------------------------------------------------