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 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
--- On Mon, 11/16/09, Cecil cecilatwp@gmail.com wrote:
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?
Either is acceptable to me. The most convincing reason to encourage de.WS forking is that it guarantees you all will not be back at this again the next time there is a code update complaining that de.WS was still not invited to review the code beforehand and approves all changes as you had demanded. Or whatever new things you might decide complain about. Merely putting the code in that allows customization, while unobjectionable, does nothing to resolve all the other outstanding accusations and demands that have been made. Forking, if not actually resolving all of those things, at least makes the remaining unresolved issues largely irrelevant.
Birgitte SB
On Mon, Nov 16, 2009 at 10:29 PM, Cecil cecilatwp@gmail.com wrote:
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).
Hello,
I think this patch is a good solution. Ideally the German community should have a developer of its own, to help de-Wikisource in the same way ThomasV helps en-Wikisource. Have you asked ThomasV if he would apply (or at least not revert) the patch?
Communities should avoid forking when possible, because this brings many problems (such as needing to worry about stability, hosting, ads, funding, brand recognition, trademarking, etc) while removing many advantages (such as benefiting from Wikimedia developers, sysadmins, fundraisers, interwiki linking, brand recognition, etc). Another consideration is that if the German Wikisource forked, it could no longer call itself "Wikisource" since that name is owned by the Wikimedia Foundation. The community would also need to find its own developers anyway, when those persons could have gained SVN access with Wikimedia without all the problems associated with forking.
There are NO considerations in the German Wikisource Community to fork in another way than technically, only regarding the Wikimedia Software.
We will definitively remain part of the Wikisource branches.
ThomasV has definitvely denied any cooperation with the German community. When choosen to administrator he had promised to make java script programming for the German community. In the now running deadministration process he has said that he is unwillingly to do so.
German Wikisource needs a developer with SVN access - that's the only solution IMHO.
Klaus Graf
2009/11/18 Jesse (Pathoschild) pathoschild@gmail.com:
On Mon, Nov 16, 2009 at 10:29 PM, Cecil cecilatwp@gmail.com wrote:
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).
Hello,
I think this patch is a good solution. Ideally the German community should have a developer of its own, to help de-Wikisource in the same way ThomasV helps en-Wikisource. Have you asked ThomasV if he would apply (or at least not revert) the patch?
Communities should avoid forking when possible, because this brings many problems (such as needing to worry about stability, hosting, ads, funding, brand recognition, trademarking, etc) while removing many advantages (such as benefiting from Wikimedia developers, sysadmins, fundraisers, interwiki linking, brand recognition, etc). Another consideration is that if the German Wikisource forked, it could no longer call itself "Wikisource" since that name is owned by the Wikimedia Foundation. The community would also need to find its own developers anyway, when those persons could have gained SVN access with Wikimedia without all the problems associated with forking.
-- Yours cordially, Jesse Plamondon-Willard (Pathoschild)
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
To clarify
I understand the forking discussion to mean soley forking the development of the Proofreadpage extension. This would result in two versions of the extension; each maintained by separate developers. The various Wikisource subdomains could each choose which version they wanted to have installed locally.
Birgitte SB
--- On Wed, 11/18/09, Klaus Graf klausgraf@googlemail.com wrote:
From: Klaus Graf klausgraf@googlemail.com Subject: Re: [Wikisource-l] Proofreading To: "discussion list for Wikisource, the free library" wikisource-l@lists.wikimedia.org Date: Wednesday, November 18, 2009, 11:43 AM There are NO considerations in the German Wikisource Community to fork in another way than technically, only regarding the Wikimedia Software.
We will definitively remain part of the Wikisource branches.
ThomasV has definitvely denied any cooperation with the German community. When choosen to administrator he had promised to make java script programming for the German community. In the now running deadministration process he has said that he is unwillingly to do so.
German Wikisource needs a developer with SVN access - that's the only solution IMHO.
Klaus Graf
2009/11/18 Jesse (Pathoschild) pathoschild@gmail.com:
On Mon, Nov 16, 2009 at 10:29 PM, Cecil cecilatwp@gmail.com
wrote:
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).
Hello,
I think this patch is a good solution. Ideally the
German community
should have a developer of its own, to help
de-Wikisource in the same
way ThomasV helps en-Wikisource. Have you asked
ThomasV if he would
apply (or at least not revert) the patch?
Communities should avoid forking when possible,
because this brings
many problems (such as needing to worry about
stability, hosting, ads,
funding, brand recognition, trademarking, etc) while
removing many
advantages (such as benefiting from Wikimedia
developers, sysadmins,
fundraisers, interwiki linking, brand recognition,
etc). Another
consideration is that if the German Wikisource forked,
it could no
longer call itself "Wikisource" since that name is
owned by the
Wikimedia Foundation. The community would also need to
find its own
developers anyway, when those persons could have
gained SVN access
with Wikimedia without all the problems associated
with forking.
-- Yours cordially, Jesse Plamondon-Willard (Pathoschild)
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
Brigitte, this is simply stupid (No I'm not saying that your a stupid). We are talking abot 9 lines of code, and the communities, which want to stick to no IP's, have this by default, without any change in behaviour und usage. This extension is fully form fit function compatible to the existing system. There is no reason of technically forking, and
I think the german language ws is the community with longest experience with the hard rules like -proofreading twice -the must of scans.
2009/11/18 Birgitte SB birgitte_sb@yahoo.com
To clarify
I understand the forking discussion to mean soley forking the development of the Proofreadpage extension. This would result in two versions of the extension; each maintained by separate developers. The various Wikisource subdomains could each choose which version they wanted to have installed locally.
Birgitte SB
--- On Wed, 11/18/09, Klaus Graf klausgraf@googlemail.com wrote:
From: Klaus Graf klausgraf@googlemail.com Subject: Re: [Wikisource-l] Proofreading To: "discussion list for Wikisource, the free library" <
wikisource-l@lists.wikimedia.org>
Date: Wednesday, November 18, 2009, 11:43 AM There are NO considerations in the German Wikisource Community to fork in another way than technically, only regarding the Wikimedia Software.
We will definitively remain part of the Wikisource branches.
ThomasV has definitvely denied any cooperation with the German community. When choosen to administrator he had promised to make java script programming for the German community. In the now running deadministration process he has said that he is unwillingly to do so.
German Wikisource needs a developer with SVN access - that's the only solution IMHO.
Klaus Graf
2009/11/18 Jesse (Pathoschild) pathoschild@gmail.com:
On Mon, Nov 16, 2009 at 10:29 PM, Cecil cecilatwp@gmail.com
wrote:
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).
Hello,
I think this patch is a good solution. Ideally the
German community
should have a developer of its own, to help
de-Wikisource in the same
way ThomasV helps en-Wikisource. Have you asked
ThomasV if he would
apply (or at least not revert) the patch?
Communities should avoid forking when possible,
because this brings
many problems (such as needing to worry about
stability, hosting, ads,
funding, brand recognition, trademarking, etc) while
removing many
advantages (such as benefiting from Wikimedia
developers, sysadmins,
fundraisers, interwiki linking, brand recognition,
etc). Another
consideration is that if the German Wikisource forked,
it could no
longer call itself "Wikisource" since that name is
owned by the
Wikimedia Foundation. The community would also need to
find its own
developers anyway, when those persons could have
gained SVN access
with Wikimedia without all the problems associated
with forking.
-- Yours cordially, Jesse Plamondon-Willard (Pathoschild)
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
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
It is stupid but it is not simple. Nor is it just nine lines of codes, unless you intend to withdraw all the rest. Frankly forking the extension is not my first preference. But I think it is improbable for the lot of you to act with either the cool rationality or the warm graciousness that would be required to heal the very complicated damage done to your relationship. I find ending the relationship entirely to be merely the better of the probable outcomes, not the absolute best. That is what leads me to encourage it.
Birgitte SB
--- On Wed, 11/18/09, Michael Jörgens joergens.mic@googlemail.com wrote:
From: Michael Jörgens joergens.mic@googlemail.com Subject: Re: [Wikisource-l] Proofreading To: "discussion list for Wikisource, the free library" wikisource-l@lists.wikimedia.org Date: Wednesday, November 18, 2009, 12:22 PM Brigitte,this is simply stupid (No I'm not saying that your a stupid). We are talking abot 9 lines of code, and the communities, which want to stick to no IP's, have this by default, without any change in behaviour und usage. This extension is fully form fit function compatible to the existing system. There is no reason of technically forking, and
I think the german language ws is the community with longest experience with the hard rules like-proofreading twice-the must of scans.
2009/11/18 Birgitte SB birgitte_sb@yahoo.com
To clarify
I understand the forking discussion to mean soley forking the development of the Proofreadpage extension. This would result in two versions of the extension; each maintained by separate developers. The various Wikisource subdomains could each choose which version they wanted to have installed locally.
Birgitte SB
--- On Wed, 11/18/09, Klaus Graf klausgraf@googlemail.com wrote:
From: Klaus Graf klausgraf@googlemail.com
Subject: Re: [Wikisource-l] Proofreading
To: "discussion list for Wikisource, the free
library" wikisource-l@lists.wikimedia.org
Date: Wednesday, November 18, 2009, 11:43 AM
There are NO
considerations in the
German Wikisource Community to fork
in another way than technically, only regarding the
Wikimedia
Software.
We will definitively remain part of the Wikisource
branches.
ThomasV has definitvely denied any cooperation with
the
German
community. When choosen to administrator he had
promised to
make java
script programming for the German community. In the
now
running
deadministration process he has said that he is
unwillingly
to do so.
German Wikisource needs a developer with SVN access -
that's the only
solution IMHO.
Klaus Graf
2009/11/18 Jesse (Pathoschild) pathoschild@gmail.com:
On Mon, Nov 16, 2009 at 10:29 PM, Cecil cecilatwp@gmail.com
wrote:
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).
Hello,
I think this patch is a good solution. Ideally
the
German community
should have a developer of its own, to help
de-Wikisource in the same
way ThomasV helps en-Wikisource. Have you asked
ThomasV if he would
apply (or at least not revert) the patch?
Communities should avoid forking when possible,
because this brings
many problems (such as needing to worry about
stability, hosting, ads,
funding, brand recognition, trademarking, etc)
while
removing many
advantages (such as benefiting from Wikimedia
developers, sysadmins,
fundraisers, interwiki linking, brand
recognition,
etc). Another
consideration is that if the German Wikisource
forked,
it could no
longer call itself "Wikisource" since
that name is
owned by the
Wikimedia Foundation. The community would also
need to
find its own
developers anyway, when those persons could have
gained SVN access
with Wikimedia without all the problems
associated
with forking.
--
Yours cordially,
Jesse Plamondon-Willard (Pathoschild)
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l
-----Inline Attachment Follows-----
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
On Thu, Nov 19, 2009 at 5:22 AM, Michael Jörgens joergens.mic@googlemail.com wrote:
Brigitte, this is simply stupid (No I'm not saying that your a stupid). We are talking abot 9 lines of code, and the communities, which want to stick to no IP's, have this by default, without any change in behaviour und usage. This extension is fully form fit function compatible to the existing system. There is no reason of technically forking, and I think the german language ws is the community with longest experience with the hard rules like -proofreading twice -the must of scans.
I agree this is stupid. Where is the 9 lines of code? I want to review the code.
-- John Vandenberg
https://bugzilla.wikimedia.org/show_bug.cgi?id=20812
Comments 16 and 17
2009/11/19 John Vandenberg jayvdb@gmail.com
On Thu, Nov 19, 2009 at 5:22 AM, Michael Jörgens joergens.mic@googlemail.com wrote:
Brigitte, this is simply stupid (No I'm not saying that your a stupid). We are talking abot 9 lines of code, and the communities, which want to stick to
no
IP's, have this by default, without any change in behaviour und usage.
This
extension is fully form fit function compatible to the existing system. There is no reason of technically forking, and I think the german language ws is the community with longest experience
with
the hard rules like -proofreading twice -the must of scans.
I agree this is stupid. Where is the 9 lines of code? I want to review the code.
-- John Vandenberg
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
On Fri, Nov 20, 2009 at 12:59 AM, Cecil cecilatwp@gmail.com wrote:
https://bugzilla.wikimedia.org/show_bug.cgi?id=20812
Comments 16 and 17
Thank you. I dont like special rules being created for IPs and sysops. I have proposed that the extension use an access control matrix.
It should be possible for projects to have differing number of stages. We should be able to configure it to have many stages like Distributed Proofreaders. If we did that, we could convince them to use our software ;-)
I'd like to hear what ThomasV thinks about my proposal to make access control more generic.
If it will make everyone happy again, I will write the code if nobody else wants to do it.
-- John Vandenberg
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
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
*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
Cecil a écrit :
Have you actually read anything that has been said before? We don't accept the discrimination of the IPs in our community.
However, you accept the fact that IPs are not allowed to upload files. As a consequence, IPs are not allowed to start a new project at de.ws, because the rule is "no scan, no text". You never complained about that. Could you explain why ? More generally, there are dozens of things that IPs are not allowed to do in MediaWiki.
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?
You seem to believe that I break things on purpose. This is not true. When I was maintaining code at de.ws, it is true that the local javascript sometimes was temporarily broken because of software updates, and that it had to be adapted. However, I was the person doing this, and I spent many hours just for de.ws. Maybe you could acknowledge this.
The second option that I mentioned means that you keep using ProofreadPage, without using the pagequality system that you do not like. However, if you do not trust me, if you really believe that I break things on purpose, then you should not use my software at all.
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
Indeed I do have plans for future developments. I usually discuss them with the people on IRC, and at ws.org. Sometimes new javascript features are tested at fr.ws and en.ws, before I move them into the extension's javascript. Once new features are added to the code, they are publicly visible in svn, weeks before their activation, just like any other developer's work. Every software modification at Wikimedia is public.
However, I cannot make announcements in every language, and for the last few updates I did not make the effort to write in German.
New developments imply new bugs, and some maintenance. This is normal. I try to do my best to avoid bugs, but nobody is perfect.
If you are scared about future developments, if you want to use software that is perfectly stable and frozen, then you should not use ProofreadPage, because there will be future developments. I could even add that if you want to use something perfectly stable, then you should not use MediaWiki at all. :-)
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).
sorry, but I did not know that you find these buttons unfriendly. If you are color blind, you can modify your CSS to change the colors, or to replace them with icons. I already explained how to do this in de.ws. If the problem is not color, but how to access them with keyboard instead of mouse, it is something that I can improve. I just need to know about it.
Now Cecil, I am very often available for discussion on IRC. I say this because you don't seem to be using this. However, the type of communication that you can have on IRC is very different than on a mailing list or wiki; some misunderstanding can be avoided by a more direct type of communication. I am willing to find a solution to your problem, and I would love to discuss with you more directly. The reason why I rejected your patch is not to harm you; I did this in order to protect the tool that I developed.
Thomas
2009/11/19 ThomasV thomasV1@gmx.de
Cecil a écrit :
Have you actually read anything that has been said before? We don't accept the discrimination of the IPs in our community.
However, you accept the fact that IPs are not allowed to upload files. As a consequence, IPs are not allowed to start a new project at de.ws, because the rule is "no scan, no text". You never complained about that. Could you explain why ? More generally, there are dozens of things that IPs are not allowed to do in MediaWiki.
First of all, images are uploaded on a different project and I have to accept that there are different rules. But it does not really matter: The IPs at German Wikisource are able to start new projects. We have a few accounts for uploading the images to Commons. Several of the registered users also never uploaded images to Commons despite starting projects. After all we are a community and we work together.
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?
You seem to believe that I break things on purpose. This is not true. When I was maintaining code at de.ws, it is true that the local javascript sometimes was temporarily broken because of software updates, and that it had to be adapted. However, I was the person doing this, and I spent many hours just for de.ws. Maybe you could acknowledge this.
I acknowledge that you spend a lot of time working on all that stuff and I believe that you are not breaking stuff on purpose. I believe that it is negligence. The problem is that you seem to usually work without consideration for other parts of media-wiki (like when PR2 suddenly didn't create any headers/footers anymore just because I had a different language for my UI). And you either don't test your updates at all or much too little. Testing when something is already active is not testing anymore (the programmer and his tester are responsible for quality code, not the customer in RL-environment). Then it is too late and the end-user has to suffer under it and then you have to understand that after seval of those occurences you will not meet any thankfulness anymore.
The second option that I mentioned means that you keep using ProofreadPage, without using the pagequality system that you do not like. However, if you do not trust me, if you really believe that I break things on purpose, then you should not use my software at all.
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
Indeed I do have plans for future developments. I usually discuss them with the people on IRC, and at ws.org. Sometimes new javascript features are tested at fr.ws and en.ws, before I move them into the extension's javascript. Once new features are added to the code, they are publicly visible in svn, weeks before their activation, just like any other developer's work. Every software modification at Wikimedia is public.
However, I cannot make announcements in every language, and for the last few updates I did not make the effort to write in German.
New developments imply new bugs, and some maintenance. This is normal. I try to do my best to avoid bugs, but nobody is perfect.
If you are scared about future developments, if you want to use software that is perfectly stable and frozen, then you should not use ProofreadPage, because there will be future developments. I could even add that if you want to use something perfectly stable, then you should not use MediaWiki at all. :-)
Nothing is ever really stable as long as there is development done. Actually even after development has stopped (users are creative). But I expect enough quality work that updates cause minor glitches or are removed again. And at least at German Wikipedia this usually is the case. The only real problems I ever had when working on Commons and Wikipedia were when the tool-server didn't work anymore and that has nothing to do with media-wiki.
And if you ever announce something on ws.org earlier than the day it is added then you hide it really well. The only information one can find there is either still in theoretical maybe-state or 'was just added'-state. So there is no project management on your side at all. IRC is no project management. If you wanna see how to not surprise users then check http://de.wikipedia.org/wiki/Wikipedia:Projektneuheiten (the points 3 and 4). If a programmer properly plans his work and not just hacks away then he should have no problem doing that kind of list. And obviously most programmers working on WP-updates plan properly. AFAIS it is just you who usually announces just after the fact. And that kind of total unreliability (yours, not the codes) makes it impossible to work on anything which has your work as a base. Expecting people to be 24/7 in IRC is no way to communicate SW-changes.
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).
sorry, but I did not know that you find these buttons unfriendly. If you are color blind, you can modify your CSS to change the colors, or to replace them with icons. I already explained how to do this in de.ws. If the problem is not color, but how to access them with keyboard instead of mouse, it is something that I can improve. I just need to know about it.
Now Cecil, I am very often available for discussion on IRC. I say this because you don't seem to be using this. However, the type of communication that you can have on IRC is very different than on a mailing list or wiki; some misunderstanding can be avoided by a more direct type of communication. I am willing to find a solution to your problem, and I would love to discuss with you more directly. The reason why I rejected your patch is not to harm you; I did this in order to protect the tool that I developed.
Correct, I don't use IRC at all. But incorrect, it is not my patch. The only script-language I used in the last eight years is Tcl. And AFAIK all code here is open source, which means that everybody is allowed to change it. Maybe you shouldn't programm stuff in open source if you don't like other people wanting to make it useable for themselves. So it really seems that forking the extension is our only possibility.
Thomas
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
wikisource-l@lists.wikimedia.org