Wikimedia Bugzilla is closed!

Allowing IPs participating by anonymous editings is another of the fundamental principles. This useless restriction is absolutly unacceptable.

Please remove this contraproduktiv restriction which is clearly against the basic thoughts on
all wiki-projects. I know several of this ip's in the real life, they wanted to be anonymus
by private reasen, and are upset about this restriction 

A small Addendum to my comment
They know that they are more anonymus by using an nickname, but the don't want use a nickname.
Everybody should be free to participate and not to be urged to do something. If they are 
urged to do so they tipically leave.  And the silly comparison with flagged revisions, used
somewhere else is simply false. They can participate even in wiki's which are using flagged revisions
(de ws don't use this feature), but they are forbidden to participate here.

IPs are allowed to participate : they can proofread and correct articles. 
What you request is to let them flag an article as "proofread".

This would dramatically change the current 'double proofreading' system, 
because it relies on proofreading by two different users (unless the IP 
is using a fixed adress, and is whiteisted somewhere).

I would like to see a community consensus on this, outside of de.ws.
A similar proposal was made 3 months ago at ws.org and received no support
http://wikisource.org/wiki/Wikisource_talk:ProofreadPage#IP_not_allowed_to_proofread

To give a direct replay to this comment of ThomasV, the only person I know which wants to exclude IP'S from the proofreading process ist the developer of this extension ThomasV. He didn't get any positive feedback for his position in the article mentioned by him. 

You schould also see the discussions in the german wikisource. I'm sorry, but these comments are in german.
http://de.wikisource.org/wiki/Wikisource:Skriptorium#Code_Update for the last update, when there is interesst in the older problems we had, I can serch for the discussions in the german language ws scriptorim.

The same type of discussion we hav every time when there is an code change by ThomasV in his extension Proofread.  Everytime the only way we get information about code changes is when feateures dosn't work any longer, because of buggy, mostly untestet code  or by ThomasV intention. That is the reason I can't call his code changes updates.  

Also a reply to ThomasV: IPs can't proofread. Proofreading is a very concentrated reading of the text, comparing it systematically with the scan of the original work and then confirm that this meticulous reading was successfully done. Anything else is just spotting an error and correcting it. So you disabled them to do proofreading since they can't confirm it anymore by changing the status. And why should they do it if it is nothing worth anyway. It takes a lot of time and still two people with accounts have to do it too. So nobody benefits from it (unless you would call 3 rounds of correcting a benefit) but a lot of wasted time.

If somebody really wanted to sabotage the proofreading system, then he could also just create a sockpuppet. Nobody would ever be the wiser unless he makes it very obvious. Since there is no 'own work' included in proofreading we would never be able to guess that it is the same user with just two accounts. That's something that can be done in Wikipedia by comparing writing-style, typical grammer errors and stuff, but it is impossible in Wikisource since the writing-style is the one of Schiller, Goethe, Rilke, the brothers Grimm or some translator.

And yes, this similar proposal received no support in your way of counting, as you obviously don't count the reporter. But it also received no oppose in my way of counting since you are the programmer. That does not make you more important then the reporter of a proposal. This was a 1:1-situation and no consensus to forbid IPs to participate. And I'm sure if the reporter would have announced his proposal somewhere it would have gotten a lot of support. Most of us on de.WS spend our time with working on old texts and not doing meta-work by checking around on other projects, so we don't see them.

I understand your point: you want IPs to be able to indicate that they 
proofread the text. 

I will not implement the solution you propose, because it implies to remove 
the double proofreading system, and because this would affect all other 
wikisources; such a radical change should at least be discussed with 
them beforehand.

The double proofreading system of the extension is not meant to be secure 
or sockpuppet-proof. It is just meant to be unambiguous. If we remove the 
current restriction on double proofreading, then users could make their 
own interpretation of the meaning of the buttons, and this would break 
the system.

If there is local consensus at de.ws, I suggest you configure your wiki 
so that IPs can indicate they proofread a page. The germans used to do 
this with a template before I introduced this buttons system. This should 
still work. Using local javascript, you guys can even create buttons linked 
to this template, so that IPs will not notice any difference.

What do you mean with radical change? This existes until a few days ago when you just implemented something else without a consensus. You don't need to implement the solution. It already exists since several years and you changed it without any consensus.

Can you show us one case of miss-use on German Wikisource? Just one to show us that your dictatorship has at least a root? There never was any problem with IPs when it came to proofreading. They are a part of our community while you treat them like dirt, like cheaters, like people who are not to be trusted at all. That is disgusting. It is called discrimination what you are doing. 

For anyone looking into this, the code in question was added in r52508.
It should be very easy to make this configurable, assuming of course that different communities want to handle this differently.

This patch for ProofreadPage.php Revision 58865 should solve the problem:

954,959c954,957
<       if (!$wgProofreadPageAllowIPs) {
<             if( ($old_q != $q) && $wgUser->isAnon() ) {
<                 $wgOut->showErrorPage( 'proofreadpage_nologin', 'proofreadpage_nologintext' );
<                 return false;
<             }
<       }
---
>         if( ($old_q != $q) && $wgUser->isAnon() ) {
>             $wgOut->showErrorPage( 'proofreadpage_nologin', 'proofreadpage_nologintext' );
>             return false;
>         }

and then you must set $wgProofreadPageAllowIPs=true in LocalSettings.php

I can't test it, because I don't have an running installation of ProofreadPage.

correction:

909c909
<     global $wgOut, $wgUser, $wgProofreadPageAllowIPs;
---
>     global $wgOut, $wgUser;
954,959c954,957
<       if (!$wgProofreadPageAllowIPs) {
<             if( ($old_q != $q) && $wgUser->isAnon() ) {
<                 $wgOut->showErrorPage( 'proofreadpage_nologin', 'proofreadpage_nologintext' );
<                 return false;
<             }
<       }
---
>         if( ($old_q != $q) && $wgUser->isAnon() ) {
>             $wgOut->showErrorPage( 'proofreadpage_nologin', 'proofreadpage_nologintext' );
>             return false;
>         }

This seems to be the solution, we have been begging for in the german wikisource.

Could anyone be so polite to help Buxul T. to test it and if it's ok activate in wikisource.

I think it would be usefull to set the default for $wgProofreadPageAllowIPs to false.

This wouldn't change anything for the existing projects. And the projects, which wants to deviate
can set this to true. 

Created attachment 6788 [details]
Allows IPs in Proofread.php

Created attachment 6789 [details]
Allow IPs in prrofread.js

After testing my older patches on a ProofreadPage-Mediawiki Installation I must admit, that this first patches don't work. Now I uploaded two new patches for Proofread.php and proofread.js and in my installtion they work.

There must still be set $wgProofreadPageAllowIPs=true in Localsettings.php to use these patches.

Created attachment 6790 [details]
Allow Q4 and IPs in proofread.js

Created attachment 6791 [details]
Allow Q4 and IPs in ProofreadPage.php

The Patches 6790 and 6791 allow in addition to 6788 and 6789 the setting to quality level 4 to sysops, so that moving from older projects to PR2 is possible.

There must be set $wgProofreadPageAllowQ4=true in LocalSettings.php additional to $wgProofreadPageAllowIPs=true

I tested this patches in my local installation and there it work.

Sorry but I will not add those patches. 
Please check the discussions from last month in the mailing list about that decision.

Can anyone verify that the solutions of Buxul T. will work and find an developer to add this to the code.

As ThomasV clearly states here, he isn't willing -  in my opinion for very personal reasons -  to add these more than usefull extension to this script.

Please add this fix to the code

So, after much digging, the relevant post seem to be http://lists.wikimedia.org/pipermail/wikisource-l/2009-October/000604.html

and there ThomasV said:

"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."

And now I have wrote the patch and he is not willing to implement it. Very bad behaviour.

I think Buxul T. solution is a general one. It will fit on all projects. 

And it  gives the '''communities the choice''' to decide in which way they want to act. 

There is no problem that the communities which wants to stick to ThomasV opinion and ideas, can keep them by setting these two variables to false (which should be the default!). 

Communities which want to deviate, have now the possibilites to do so. 
* They can transfer old already proofread twice projects to this extension without additonal unneeded work. Buxul T. implementation to restrict this to admins sounds to be a good idea.
* They can allow ip's to proofread, because the haven't had any harm by ip's up to now. If there will be big problems in the future (I hope not) the community can decide to switch back to the ip restricted setting.

If this this patch is technical ok, i see no reason why this patch will not included. Other communities haves other criteria. German wikisource wants that any user can change the status of a page. Where is the problem?

Buxul : you misunderstood what I said. When I wrote in the 
ML that de.ws admins can program the solution they need, I 
was referring to local javascript, and to the solution 
implemented by user xarax 2 years ago.

If something can be achieved through local configuration, 
I do not see why I should add it to the core of the 
extension, especially when other subdomains do not want it.
Also, it will be much easier for you to develop and maintain 
code locally.

Just check how the quality buttons worked at de.ws 
before I introduced the pagequality system: categories 
were added to the pages by local javascript. This should 
still work. Using local javascript, you can add the 
categories you want to the pages you want. 

Please note that this solution does not require a robot;
My suggestion to use a robot was intended to facilitate 
migration of already proofed texts, and is interesting 
only if de.ws wants to stay in the common pagequality 
system. However, if de.ws wants IPs to be able to mark 
pages as proofread, then they do not want to use the 
common pagequality system. 

I find it very interesting how ThomasV is arguing about 9 lines of code, which would improve the extension. And his arguments, that if someone else would do it will be ok - we have misunderstood him we are only allowed by him to do it the second best way.

He is arguing that a user Xarax can do this for us whith a lot more of java script code. I'm sorry Xarax isn't active as an user anymore (we are quite unhappy about that, only Bot-activities can be seen within in the last 6 month). A experienced programmer - a person who we are laking at the moment - should write a lot of code to circumvent the obstacles, it must be tested in the real environment including removing the bugs, we haf bad experiences about that. 
 
And his argument other subdomains don't want it (which one? french community should be clear - or?). If you look at the communications,in total more people are arguing for enhancing the extension then against. 

Here you have a list of the communities working with proofread http://wikisource.org/wiki/Wikisource:ProofreadPage_Statistics

The biggest curiousity is ThomasV introduced a big change in the extension without talking to a lot of communities. We must learn it the hard way, by notifying that things which had run good for quite a long time, won't run anymore suddenly. I think most of the communites didn't know up to now, what had happened and therefore don't take part in the communication. (I don't think that a lot of communites are converting multithousand page projects to Proofread 2). 


I think you should also read this comment here 
http://lists.wikimedia.org/pipermail/wikisource-l/2009-November/000636.html


Greetings

p.s. we want to use the the page quality system but without beeing overruled. We believe in the wiki system and assume good faith (AGF) by the people which are contributing.

Please provide unified diffs using "diff -ur old/ new/"

More fundamentally, I think it is necessary for the Proofread Page extension to not include access control.  It should probably use the userCan hook, and let another extension implement access control.

http://www.mediawiki.org/wiki/Manual:Hooks/userCan

I would prefer to see a matrix that defines what user groups are able to perform tasks at various stages.

The following would prevent IPs from proofreading pages.

  $wgGroupPermissions['autoconfirmed']['proofread'] = true;
  $wgProofreadPageStageProtection['*'] = array( 'proofread' );

The following would prevent IPs from validating pages.

  $wgGroupPermissions['autoconfirmed']['validate'] = true;
  $wgProofreadPageStageProtection[3] = array( 'validate' );

It should be possible to add a sysop-only fourth stage with:

  $wgGroupPermissions['sysop']['finalise'] = true;
  $wgProofreadPageStageProtection[4] = array( 'finalise' );

Another approach would be:

  $wgProofreadPageMaxStage['anon'] = 1;
  $wgProofreadPageMaxStage['autoconfirmed'] = 3;
  $wgProofreadPageMaxStage['sysop'] = 4;

As I understand it, Thomas objects to this proposal and patch because the new <pagequality> tag integrates the various language domain implementations, allowing the automatic maintenance of pages like <http://wikisource.org/wiki/Wikisource:ProofreadPage_Statistics>. This page compares the progress of different domains, and therefore must use the same metric for each domain. Otherwise it is useless. The proposed patch changes how progress is measured for a single domain, and thus would invalidate the entire integration. This is why Thomas opposes it.

The choices, then, are:
1. Thomas could patch all of the domains... but this would require consensus across all of them, not just de.wikisource;
2. de.wikisource can withdraw from the integrated page quality system and fix their problem. No patch is needed for this; they need only revert their local Javascript to a version that does not use the <pagequality> tag.

I agree with Vandenberg's proposal. His point that there is no need for an alternative Access Control System is very important. We schould have one and exactly one user access control system. 

Therefore from my point of view. 
- There should be the possibility for IP's to contribute as before. 
- At least Admins should have the right to set the proofread level according to the needs, for converting older already proofreaded projects to the proofread extension. No curious / buggy workarounds by bots.
- Only one User access-system. Exactly speaking the access control system which is implemented in the mediawikisw  (userCan)

@Snottygobble, we don't have to fix aproblem we have. We want the unheralded change of the last update deactivated or changed to a community selectable access system. 

What I find funny, the we, who were the cutting edge in proofreading - as ThomasV statet - in Wikisource should be the bad guys which don't understand what happens (Is there a possibility that we have more experience, because we doing this job longer than most of the other projects?). The allegation that we are complaining because the other are luckily stepping up to us is ridiculous. The french and english wikisource have overhauled us a long time ago in some numbers. Nobody of us is complaining about that. Far from it, we are happy that all wikisources are coming up to a high level of quality. 

greetings

"We want the unheralded change of the last update deactivated." You've been told, repeatedly, that you don't need a patch applied in order to achieve this. Simply revert your javascript back to a version that uses your old page quality template, instead of the <pagequality> tag. This will give you precisely what you want. It will also effect the removal of de.wikisource from the global statistics pages; but this is not unreasonable, given you will have rendered your statistics incommensurable by opting for a different approach to validation.

Please bear in mind that this is a bug tracking system, and what is considered fair comment here is very different to what might be acceptable on Wikimedia discussion pages or the mailing lists. Comments here should be directed towards explaining or resolving the bug.

fixed in r69212 
(see http://lists.wikimedia.org/pipermail/wikisource-l/2010-July/000784.html )