[Taking this bug and changing status & adding the 'shell' keyword; I'm also CC-ing a few people that were CC'd to bug 41745 or who took part in that discussion.

This looks to me like a prime candidate for https://meta.wikimedia.org/wiki/Limits_to_configuration_changes, but I don't want to make any decisions here on my own.]

Thanks! At last after 7 months of waiting we know something about the community's wish, this is very good. I still have to review what that is, which I'll check later, but for now some quick notes on which I'd like more input from the reporter:

1. the request as summarised in comment 0 lacks a rationale, i.e. what this configuration wants to achieve;
2. the poll question looks one-sided, providing only the views of those who assume the standard CAPTCHA configuration harmful (*);
3. the community wasn't provided with data allowing an informed decision, instead they used some partial data covering less than half of the reversions of two weeks out of the two months. Fresh data has just been published. https://pt.wikipedia.org/?oldid=36158748

(*) «Vários usuários têm comentado sobre o aumento do número de vandalismos e sobre a incapacidade desta comunidade de lidar com esse aumento sem preparação ou alternativa à remoção do CAPTCHA.»

The voting rationale looks backwards. It's "Do we want to use CAPTCHA?" instead of "There's more vandalism, what shall we do?" with several options, from "None, I do not see such increase / it's not significative" to "Implement new bots" or "Make sure toolserver doesn't fail", as well as the "force the captcha for everybody" one. I particulary miss an option to have a better vandalism detection using the AbuseFilter. The abusefilter actions can range from just showing a warning message (a better one, actually, since it can be customized) but allowing the edit, to completely prevent it or even blocking the user.

There are core Wikimedia principles at stake here. CAPTCHAs present a real accessibility issue and there are ancient, fundamental ideas that adding a CAPTCHA would violate (cf. [[User:Jimbo Wales/Statement of principles]]).

There are hundreds of Wikimedia wikis, some of which are heavily spammed. None of them have taken a step this drastic or dramatic, as far as I'm aware. While I'm a big proponent of wiki sovereignty and autonomy, I don't see how this request can be fulfilled.

It was said on previous bug that:
"(If the community gets a consensus to put the wiki on EmergencyCaptcha mode
again, please fill a new bug.)"

The requested is done and that is the will of community. All requirements are fullfilled.

If you want to follow rules, the only argument you could provide refers to 'limits to configuration changes' and I can't see how some change that was used for five years can be considered a limit. If it was a limit, why it was done for so long? It is obviously not a limit.

It was considered by the community and it is sad to see that pt.wikipedia is being threated as a naive, unaware bunch of people that doesn't know what is doing. They obviously knew what they were doing when they said "yes" on vote page.

Vote page is a consequence of months of discussion. Some of them are linked on vote page. The point where we couldn't reach consensus is whether activate or not CAPTCHA and that is why it was made this clear question when voting. So, on the beginning, discussion was tried and where we could find an answer with discussion, we voted. That is how things works on pt.wikipedia and most wikipedias. And users 'massively' answered "yes", letting clear what is the unquestionable desire of community. It is not up to anybody here discredit this page. You are free to disagree with the solution taken, but you can't choose to discard valid community decisions.

(In reply to comment #5)

Vote page is a consequence of months of discussion. [...]

Comment 2 asked some clarifications (points 1-2) on the discussion precisely because it's a complex matter with many ramifications and we didn't get a good summary yet. The questions stand.

(In reply to comment #6)

(In reply to comment #5)

Vote page is a consequence of months of discussion. [...]

Comment 2 asked some clarifications (points 1-2) on the discussion precisely
because it's a complex matter with many ramifications and we didn't get a
good
summary yet. The questions stand.

I will answer any developer question or I can help them on how to ask community itself. I don't know who you are and what are your functions here. Meta page on how to make this change does not cite that this kind of question should be answered here. It says that here you can argue about any limit to configuration change.

But that is me. Why bringing that to community is a problem? I am sure that any of the other 53 users that voted would be fine to answer. Points 1 and 2 are only your opinion, which is different from the opinion of a whole community. You are implying that community didn't know what was doing or, worse, was fooled by the one that created the vote page. That is a fallacy to say the least; not a valid argument.

(In reply to comment #7)

[...] But that is me. Why bringing that to community is a problem? I am sure that
any
of the other 53 users that voted would be fine to answer.

Sure, nobody said it must be you.

Points 1 and 2 are
only your opinion, which is different from the opinion of a whole community.
You are implying that community didn't know what was doing or, worse, was
fooled by the one that created the vote page. That is a fallacy to say the
least; not a valid argument.

I didn't make any argument (yet). It's a fact that comment 0 doesn't provide a rationale (1); and yes (2) was worded as an impression ("looks"), not a statement: this is why they're questions, and rather basic ones I'd say.
You can *choose* to make this process antagonistic by refusing to even answer questions and let people understand (out of sincere interest for the project), and you'll force it to be an antagonistic yes or no; but it's your choice.

This issue was extensively discussed, all sides, for months. If "the poll question looks one-sided" is because it's the view of the community, which was proved by the pool itself. The vandalism rose, everyone noticed, nobody liked the way this change was made and, unfortunately, this led to such a deficient decision. It is, however, our decision. Please implement it.

Sorry any English mistakes.

jbribeiro wrote:

Please, guys. We arediscussing this issue for months now. We can ask that every single one of the users who voted there come here and confirm his/her option, but it clearly counterproductive. I cannot see why, with such a clear majority (85,7%), the wish of the community can't be speedly implemented... The mood against this kind of filibusting down there will eventually galvanize and cristalize a negative opinion that will be much harder to revert down the road. Harsher and harsher methods to avoid IP disruption will be implemented to circunvent this captcha problem if you do not trust that the community will, at some point, turn it off in the future when (and only when) those alternatives prove to be feasible in our reality (35 sysops for 800 0000 articles; almost anyone capable to operate bots; third world country mentality in regards to "public property" etc.). No one wish to keep this on forever, but we need time and some peace to try some other alternatives.

jbribeiro wrote:

A suggestion: why don't you turno it on and then some of you guys actually work with us to implement some of the alternatives proposed? And,moe important, train some of us to keep them running after you're gone. Then I think the support for unrestricted IP edits will come naturally, because now I think even a "revert on sight" policy against them would pass due to overwork we are subjected. Assume some good faith on our part.

(In reply to comment #7)

(In reply to comment #6)

Comment 2 asked some clarifications (points 1-2) on the discussion precisely
because it's a complex matter with many ramifications and we didn't get a
good summary yet. The questions stand.

[...] I don't know who you are and what are your functions here.

How is this even remotely relevant? You're being dismissive and outright rude here.

(In reply to comment #12)

(In reply to comment #7)

(In reply to comment #6)

Comment 2 asked some clarifications (points 1-2) on the discussion precisely
because it's a complex matter with many ramifications and we didn't get a
good summary yet. The questions stand.

[...] I don't know who you are and what are your functions here.

How is this even remotely relevant? You're being dismissive and outright rude
here.

The answer follows my phrase: "Meta page on
how to make this change does not cite that this kind of question should be
answered here. It says that here you can argue about any limit to configuration
change." He is following a step that is not even followed by system administrators. If not even sysadmins ask that, why is he asking? 'That' is dismissive. All I am asking was a confirmation from a sysadmin that this is the right procedure.

Is the procedure on these requests to suggest that the community was mistaken? That is it not really the community desire? A sysadmin would do that? What I am saying is that what is being questioned should not be and maybe it is outside of the sysadmin's decision to judge that. A sysadmin would know that, but I don't know if these out of nowhere imposed barriers are really procedural. That is why I am asking sysadmin review. We talk on community. Here, we show the result of something and the ones entitled will deny or accept with their reasons; we shouldn't start another conversation here and put invented barriers. This page [1] is not being followed.

Rude is discard a clean vote, with massive community participation. Rude is asking that we start a vote then when we do it, we are ignored.

I would have started another kind of vote, like a vote to force page preview or something that we don't depend on Bugzilla, if I knew that community desire would be thrown on garbage. Only community users know what is going on there. The one that should be heard is being ignored and all that matters is the of users that comment here, far away from community issues.

[1] https://meta.wikimedia.org/wiki/Wiki_configuration_change

(In reply to comment #13)

Is the procedure on these requests to suggest that the community was
mistaken?
That is it not really the community desire? A sysadmin would do that?

Yes, it is, if the request is seemingly in violation of the basic Wikimedia principles of openness and accessbility.

What I am
saying is that what is being questioned should not be and maybe it is outside
of the sysadmin's decision to judge that. A sysadmin would know that, but I
don't know if these out of nowhere imposed barriers are really procedural.

You seem to be under impression that you're speaking to your employees or subordinates. This is clearly a wrong impression, please snap out of it. Both Nemo and I are volunteers who ask people like you for answers and clarifications so that the sysadmins don't have to and the requests can be processed more quickly.

(In fact, every single person who responded on this bug until now is a volunteer.)

That
is why I am asking sysadmin review. We talk on community. Here, we show the
result of something and the ones entitled will deny or accept with their
reasons; we shouldn't start another conversation here and put invented
barriers. This page [1] is not being followed.

[1] https://meta.wikimedia.org/wiki/Wiki_configuration_change

That's not a rulebook, that's a guide. It also says that "Gaining on-wiki consensus and filing a shell bug does not guarantee that the request will be fulfilled. Ultimate authority lies with the system administrators, and shell bugs may be resolved INVALID or WONTFIX due to performance issues or other considerations.". Please consider this.

jbribeiro wrote:

A(In reply to comment #14)

(In reply to comment #13)

Is the procedure on these requests to suggest that the community was
mistaken?
That is it not really the community desire? A sysadmin would do that?

Yes, it is, if the request is seemingly in violation of the basic Wikimedia
principles of openness and accessbility.

What I am
saying is that what is being questioned should not be and maybe it is outside
of the sysadmin's decision to judge that. A sysadmin would know that, but I
don't know if these out of nowhere imposed barriers are really procedural.

You seem to be under impression that you're speaking to your employees or
subordinates. This is clearly a wrong impression, please snap out of it. Both
Nemo and I are volunteers who ask people like you for answers and
clarifications so that the sysadmins don't have to and the requests can be
processed more quickly.

(In fact, every single person who responded on this bug until now is a
volunteer.)

That
is why I am asking sysadmin review. We talk on community. Here, we show the
result of something and the ones entitled will deny or accept with their
reasons; we shouldn't start another conversation here and put invented
barriers. This page [1] is not being followed.

[1] https://meta.wikimedia.org/wiki/Wiki_configuration_change

That's not a rulebook, that's a guide. It also says that "Gaining on-wiki
consensus and filing a shell bug does not guarantee that the request will be
fulfilled. Ultimate authority lies with the system administrators, and shell
bugs may be resolved INVALID or WONTFIX due to performance issues or other
considerations.". Please consider this.

And that is exactly the kind of posture I'm talking about. The portguese community will, for sure, have its desires with or without this "community" help. For sure, the the final result of this whole debacle is that fundamentalist opinions are now being considered feasible, thank to bugzilla's lack of sensibility. At this moment, due to this sad development, proposals are being considered that will restrict IP edits much more than anything you are hoping to avoid by simply "WONTFIX" us.... It's a real shame that in the absence of a middle ground stance, the only winners are the radicals...

(In reply to comment #15)

It's a real shame that in the
absence of a middle ground stance, the only winners are the radicals...

And all this just because of a refusal to answer some simple requests for clarification.

(In reply to comment #14)

(In reply to comment #13)

Is the procedure on these requests to suggest that the community was
mistaken?
That is it not really the community desire? A sysadmin would do that?

Yes, it is, if the request is seemingly in violation of the basic Wikimedia
principles of openness and accessbility.

But it isn't. What is the "violation"? Comments 9 and 10 are more than enough to show why you have no reason to ignore the vote page. Usually, votes have the half of the participation we had and that is due to the long-term discussion we had and the way we announced the page to everybody.

What I am
saying is that what is being questioned should not be and maybe it is outside
of the sysadmin's decision to judge that. A sysadmin would know that, but I
don't know if these out of nowhere imposed barriers are really procedural.

You seem to be under impression that you're speaking to your employees or
subordinates. This is clearly a wrong impression, please snap out of it. Both

There is no logic on that assertion. I am only stating facts on my comments. All that I said is that it is up to sysadmins to decide and the some barriers being imposed are not on any written rule and are only personal opinions.

Nemo and I are volunteers who ask people like you for answers and
clarifications so that the sysadmins don't have to and the requests can be
processed more quickly.

(In fact, every single person who responded on this bug until now is a
volunteer.)

That
is why I am asking sysadmin review. We talk on community. Here, we show the
result of something and the ones entitled will deny or accept with their
reasons; we shouldn't start another conversation here and put invented
barriers. This page [1] is not being followed.

[1] https://meta.wikimedia.org/wiki/Wiki_configuration_change

That's not a rulebook, that's a guide. It also says that "Gaining on-wiki
consensus and filing a shell bug does not guarantee that the request will be
fulfilled. Ultimate authority lies with the system administrators, and shell
bugs may be resolved INVALID or WONTFIX due to performance issues or other
considerations.". Please consider this.

I am considering. Can you tell me a reason that would prevent to be done something that was done for five years? As I said, comments 9 and 10 clarify everything, but they still need to be "accepted" by somebody I don't know who is.

jbribeiro wrote:

(In reply to comment #16)

(In reply to comment #15)

It's a real shame that in the
absence of a middle ground stance, the only winners are the radicals...

And all this just because of a refusal to answer some simple requests for
clarification.

Nemo, I'm really sorry and I'm invested in trying to make this work, so I, respectfully ask you - and I'll take this to our community: what, exactly, is the clarification you need? In the vote we showed you, smost of our most active and respected members participated. The "core" of our community participated due to the importance of the issue at stake and them impact we had once captcha was turned of. EVERYONE complained and e everyone is open to try some other means, but (i) we don't know how; (ii) we don't have the skills among the very few sysops we have; (iii) the time we had, we now spend reverting, reverting and reverting....

jbribeiro wrote:

(In reply to comment #18)

(In reply to comment #16)

(In reply to comment #15)

It's a real shame that in the
absence of a middle ground stance, the only winners are the radicals...

And all this just because of a refusal to answer some simple requests for
clarification.

Nemo, I'm really sorry and I'm invested in trying to make this work, so I,
respectfully ask you - and I'll take this to our community: what, exactly, is
the clarification you need? In the vote we showed you, smost of our most
active
and respected members participated. The "core" of our community participated
due to the importance of the issue at stake and them impact we had once
captcha
was turned of. EVERYONE complained and e everyone is open to try some other
means, but (i) we don't know how; (ii) we don't have the skills among the
very
few sysops we have; (iii) the time we had, we now spend reverting, reverting
and reverting....

And, to make this perfectly clear, almost everyone commented that their support to turn captcha on was only until some other - better - way to avoid vandalisms was found. Please, take this into consideration and try to find any wiki where 800 000 articles are watched by 35 sysops (about half of them, "semi-active").

(In reply to comment #1)

This looks to me like a prime candidate for
https://meta.wikimedia.org/wiki/Limits_to_configuration_changes, but I
don't want to make any decisions here on my own.]

Copying Erik and Howie F. on this. I seem to remember the PageTriage extension coming about as the result of some vote or discussion on the English Wikipedia. It was a compromise measure. Something similar may work here.

I agree with Nemo that it would be better to focus on the actual issues here (which edits we want to prevent) instead of focusing on a CAPTCHA (which is a "solution" that really just adds to the problem).

(In reply to comment #4)

There are core Wikimedia principles at stake here. CAPTCHAs present a real
accessibility issue and there are ancient, fundamental ideas that adding a
CAPTCHA would violate (cf. [[User:Jimbo Wales/Statement of principles]]).

An additional link: [[m:Founding principles]].

(In reply to comment #0)

Portuguese Wikipedia already used CAPTCHA that way for five years. It was
removed in April (see bug 41745) as it was said a community decision was
necessary to keep it.

(In reply to comment #19)

And, to make this perfectly clear, almost everyone commented that their
support to turn captcha on was only until some other - better - way to avoid
vandalisms was found.

Hi.

Can one of you please provide examples of edits that you want to prevent? What edits would you like to stop that you believe adding a CAPTCHA will prevent? Please provide as many examples as you would like. The more examples you can provide, the better feedback you can get, I think. There are a number of developers actively watching this bug report. :-)

I think we should focus on the types of edits you want to prevent (the problem) rather than focusing on adding a CAPTCHA (a proposed solution).

And for what it's worth, a wiki can easily disable or deter edits by anonymous users by using [[w:pt:MediaWiki:Titleblacklist]] or [[w:pt:Special:AbuseFilter]]. Though you can't use the AbuseFilter to force a CAPTCHA (yet: bug 18110).

The problem is not the type but the amount of edits, we can not deal with the amount of vandalism.

See http://pt.wikipedia.org/wiki/Usu%C3%A1rio%28a%29:HAndrade_%28WMF%29/Pesquisa_Vandalismo/Segunda_Fase . The "Total de Edições feitas por IPs" in first table is "Total of edits made by IPs", which rise from 65748 in March to 107584 in May, an increase of 64%, thanks to the disable of CAPTCHA. With this increase the amount of vandalism has been increased too, but we have no enough users to combat this amount of vandalism. The users who combat vandalism were working harder to avoid the vandalism, thinking that its is a phase, that CAPTCHA will be re-enabled soon. But now these users are giving up, they can not deal with this amount of vandalism, and many articles are been vandalized without the vandalism be reverted. That is the problem.

We need something that decrease the amount of IPs edits, because now this is the unique way to decrease the amount of vandalism. If you think better, give us one year or six months to develop better ways to combat vandalism, we have already created a project to study the alternatives. But now we need the CAPTCHA, now this is the unique way to keep the vandalism in a level we can deal.

(In reply to comment #22)

[...] The users who combat vandalism were working harder to avoid the
vandalism, thinking that its is a phase, that CAPTCHA will be re-enabled
soon. [...]

This is because you only have less than 20 rollbackers dealing with it, a number targeted to old conditions; are you interested in a list of very active patrollers who could be nominated for election as rollbackers to help? Have you told the community more help is needed?

We need something that decrease the amount of IPs edits,

Thanks, I've updated the summary.

because now this is
the unique way to decrease the amount of vandalism. If you think better, give
us one year or six months to develop better ways to combat vandalism, we have
already created a project to study the alternatives. But now we need the
CAPTCHA, now this is the unique way to keep the vandalism in a level we can
deal.

I +1 this:

(In reply to comment #21)

Can one of you please provide examples of edits that you want to prevent?
What
edits would you like to stop that you believe adding a CAPTCHA will prevent?
Please provide as many examples as you would like. The more examples you can
provide, the better feedback you can get, I think. There are a number of
developers actively watching this bug report. :-)

We're only speaking of a handful thousands of reverted edits per month more. If you're interested in quick solution, you could ask User:HAndrade (WMF) (who has already been very helpful) to list all the reverted edits he counted, and I volunteer to inspect them for patterns. We could see if rate limits would help and so on; all those who follow this report without being pt.wiki users do so because they're interested in technical solutions, so I'm sure they'd help too.

I am the last person to want to see the CAPTCHA reinstated on pt.wikipedia, but I think we should have a clear answer on whether the proposed change is possible to implement or not. By possible, I mean, if there is anyone willing to implement it. There are a lot of other issues being discussed on this bug right now that are perhaps better done elsewhere. I agree with many of the objections to the way the voting was worded, alternatives not being discussed (and I mentioned these in the talk page of the proposal, being quickly dismissed). Many of the people that wanted to have CAPTCHA removed, ended up voting for the reinstatement because of perceived interference from the outside, so I think you should consider whether your actions are being counter-productive. So right now, all is needed is for a clear answer: Is it possible to reinstate the CAPTCHA for all anonymous edits or not? It is not good to waste everyone's time with data analysis, discussion, bitterness and so on, if when we are back here with all those questions answered, the decision would still be the same. In the meantime, I invite everyone (from all sides) to join the Antivandalism project https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Projetos/Antivandalismo and finally talk seriously about improving the other measures available.

I strongly agree with Goethe's statement. The community decided to reinstate the captcha, we can discuss if it was the best decision or not, but the fact is that there is a clear community decision. I've voted for the reintroduction of emergency captcha, but right now, i'm much more interested in getting my community peaceful again, and work for getting things prepared for the removal in a near future. What the removal showed was that we weren't prepared. We need to reinforce the number of rc's patrollers, improve our anti-vandalisms bots, improve our abuse filters and provably try some new approaches.

(In reply to comment #20)

Copying Erik and Howie F. on this. I seem to remember the PageTriage
extension
coming about as the result of some vote or discussion on the English
Wikipedia.
It was a compromise measure. Something similar may work here.

We already have a discussion about that extension (which is not related to the CAPTCHA discussion so far):
http://pt.wikipedia.org/w/index.php?oldid=36097623

jbribeiro wrote:

(In reply to comment #21)

(In reply to comment #0)

Portuguese Wikipedia already used CAPTCHA that way for five years. It was
removed in April (see bug 41745) as it was said a community decision was
necessary to keep it.

(In reply to comment #19)

And, to make this perfectly clear, almost everyone commented that their
support to turn captcha on was only until some other - better - way to avoid
vandalisms was found.

Hi.

Can one of you please provide examples of edits that you want to prevent?
What
edits would you like to stop that you believe adding a CAPTCHA will prevent?
Please provide as many examples as you would like. The more examples you can
provide, the better feedback you can get, I think. There are a number of
developers actively watching this bug report. :-)

I think we should focus on the types of edits you want to prevent (the
problem)
rather than focusing on adding a CAPTCHA (a proposed solution).

And for what it's worth, a wiki can easily disable or deter edits by
anonymous
users by using [[w:pt:MediaWiki:Titleblacklist]] or
[[w:pt:Special:AbuseFilter]]. Though you can't use the AbuseFilter to force a
CAPTCHA (yet: bug 18110).

I'm trying to ascertain if there is anyone in our community who knows how to implement those suggestions. Aparently, "easily" means something different down here...

(In reply to comment #21)

There are a number of developers actively watching this bug report. :-)

Would any of them be interested in improving gerrit Change-Id: I5ad1f8d51368645870da3fde79ea7d1b8e41e7a5 for solving bug 41522?

(In reply to comment #27)

I'm trying to ascertain if there is anyone in our community who knows how to
implement those suggestions. Aparently, "easily" means something different
down
here...

Bug 45066 comment 33 lists some possible solutions to the vandalism problem; you might want to have a look at it.

(In reply to comment #28)

(In reply to comment #21)

There are a number of developers actively watching this bug report. :-)

Would any of them be interested in improving gerrit Change-Id:
I5ad1f8d51368645870da3fde79ea7d1b8e41e7a5 for solving bug 41522?

Would be nice but not so useful here IMHO. Is there a bug for logging actions caught by rate limits (for the case a stricter one is set)?

Today I at last studied SQL "properly" just to provide pt.wiki a list of possible new rollbackers, so I feel I've done my wiki homework. :) https://pt.wikipedia.org/?oldid=36169678#.2Breversores

Here is some data on the current usage of the AbuseFilter on ptwiki[1]. There are:

• 82 filters enabled:
  • 8 private filters
  • 46 filters tagging edits
  • 34 filters warning users
  • 19 filters disallowing the matched edits
  • 3 filters with throttle
• 38 edits on filters in 2013:
  • each of them made by one of 10 different users[2].
  • a significant part (20) of these edits were not related to vandalism fighting, but to make "partial blocks" of specific users (e.g. from editing certain namespaces until bug 28530 is solved) or pages (to avoid edit wars).
  • there was only one filter changed from "warn" to "disallow"[3], but we still lack a good way to find good candidates for this kind of change (e.g. the "false positives count" mentioned on bug 28213).

There may be space for abusefilter-related improvements but I don't see enough people with the interest or skills needed for that.

[1] https://pt.wikipedia.org/wiki/Special:AbuseFilter?sort=af_hit_count&limit=500&desc=1&deletedfilters=hide&uselang=en
[2] https://pt.wikipedia.org/wiki/Special:AbuseFilter/history/?dir=prev&offset=20130101000000&uselang=en
[3] https://pt.wikipedia.org/wiki/Special:AbuseFilter/history/70/diff/prev/1354?uselang=en

Adding Anubhav, for the problem of determining spam edits, so perhaps his gsoc project can help ptwiki.

Goethe, the risk I see is that once the CAPTCHA is reinstated, the interest on getting the right solution may disappear, and ptwiki will be stuck with the “wrong” one for other 5 years.
On the other hand, if it was temporarily reenabling it for 2-3 months (with a disabling date clearly set) while actively looking for better solutions, recruiting more patrollers, etc. I think it can be acceptable

Helder, skills are less of a problem. Those patrollers should be able to detect and report some vandalism patterns they are encountering. The problem is to learn what actions to block.

Platonides, I agree and I mentioned that in the discussion and is one of the reasons I voted against the reinstatement of the CAPTCHA. I am not saying that this should be implemented, only that a clear path of possibilities should be laid out by you, so that we don't keep discussing and voting things that can not happen.

jbribeiro wrote:

(In reply to comment #30)

(In reply to comment #28)

(In reply to comment #21)

There are a number of developers actively watching this bug report. :-)

Would any of them be interested in improving gerrit Change-Id:
I5ad1f8d51368645870da3fde79ea7d1b8e41e7a5 for solving bug 41522?

Would be nice but not so useful here IMHO. Is there a bug for logging actions
caught by rate limits (for the case a stricter one is set)?

Today I at last studied SQL "properly" just to provide pt.wiki a list of
possible new rollbackers, so I feel I've done my wiki homework. :)
https://pt.wikipedia.org/?oldid=36169678#.2Breversores

I'm trying to correlate the list of possible rollbackers you created with the list of people who already are rollbackers. It seems to me that we have enough rollbackers, but very few who know how to use Huggle (or are willing to do so). We have 3 users who use it on a dayly basis and at most ten more who use it form time to time). And we have no "patrol projects" in place to watch Recent Changes and New Pages, although we do have a few users and sysops dedicated to the job. About filters, almost no one know (perhaps 5 guys) anything about them. There is a growing concern there that the situation could quickly escalate with the new Visual Editor next month, but there is very little interest in it as whole.

jose.mario.pires wrote:

The arguments of the all-mighty, all-wise developpers, guardians of the ''Wikimedia principles'', or whatever, can be resumed like that: 85% of the editors of one of the 10 wikipedias with more articles don't give a damn about the ''Wikimedia principles'' and basically are complete morons. Who cares about the the damage that IP's cause to the information that is in the articles? And so what that the editors can't cope with the amount of damage that comes from IP's? More important than the quality of the articles is that nice idea that everything is done to guarantee that whoever wants to put the dummiest joke on an article or any copy/paste isn't bothered; after all, the main job of the registered editors is to spend 80% of their time reverting and correcting the rubish and spam "contributed" by the others, all in the name of "anybody can edit", as if it was too complicated creating a login or writing down a captcha.

''"Oh, but there are are more effective methods of diminishing vandalism"''. Ok, again we are dumb because we weren't able to discuss and implement them. Maybe your paternalism and ''superior'' judgement would be more useful if you said something like "why don't you consider implementing this and that method and we'll talk about the captcha in one or two monthes?". Instead of that you, like the worst of the politians and used cars sellers, pretend that the perception of 85% of the people who are worried about vandalism and, instead of making beautiful speeches about the wiki spirit, do their best to preserve a minimum of quality to the "moron's" pt.wikipedia , are all wrong because nobody did a "study".

If you are worried about participation, if you have wee bit of life experience, you are shooting your feet with a canon, because there is nothing more harmful to a comunity (more if it is made of volontaries) than to call them morons with "paternalist" or "pseudo-moralist" atitudes like yours. If you knew how to read Portuguese you would notice that even people who are against the captcha are really angry with your atitude and now it will be much more difficult to refuse radical proposals that can be implemented without the the aproval of the all-mighty "guardians of the Wikimedia ethics". Supposedly powerful governments fall in the street for much less and remember that here the real danger isn't any kind of real rebellion, but something much more damageful to the project: the mass abandonment of the projet from editors that in one day bring more to the project that all the IP's in one week. Dismiss these arguments any way you want, you can call them exxagerated, catastrophic, radical, unpolite, subversive, whatever; I don't give a damn... After all, I am a volontary who has believed that my work of many hundred of hours doing my best to preserve and improving the quality of Wikipedia was part of something which was worth, a really free project where little big games of power, sex of the angels discussions and alikes were secondary. If you convince me that I don't belong here because my ideas are all wrong, better for me, and surely that the project will hardly notice that I finally decided that it's wiser to me to find another way of spending all the time I spend here. But remember that there will be much more people thinking and doing the same. But, as in real life, here we notice the same tendency of those who have a little power in their hands, that makes them think that they know better about what should be done than those who are on the terrain. I am too old for such a thing coming as a surprise, but while I almost gave up fighting against situations like this in professional life because there I am obliged to cope with that, in volontary projects is much harder to tolerate that anyone tells you that you and 85% of your peers that participate in a poll are complete moron proposing this or that.

Related URL: https://gerrit.wikimedia.org/r/69982 (Gerrit Change I3c6035ac747461f621c1698afaffec5abc3d5df4)

Stegop,

1. Nobody called you morons (or at least nobody intended to do so).
2. I just mentioned about reenabling it for a few months a few comments before.
3. No, if you don't know about X you're not dumb, that's called ignorance and is thanksfully much easier to fix. Sorry, I don't want to look pedantic on terminology or to bore you with silly samples, but the right thing would be to help (teach) you, not to leave ptwiki in stone age.
4. There were some studies (albeit small). See the discussion.
5. Yes, I can read Portuguese, even if not fluently.

I'm sorry you feel like that (not the best path for discussion, but I have also needed to rant my frustration from time to time :).

Yes, I would like to help ptwiki to overcome this, preferably without forcing the captcha to the users for other 5 years. BUT, I don't know exactly the best way to do so. Treating me as a dumb moron, how would you define the problem? Not having a patrol project? Not enough reviewers? Lots of people writing "learn English"? Lack of bots? Should we propose “huggle lessons for pt”?

(In reply to comment #37)
...

Not having a patrol project? Not enough reviewers? Lots of people writing
"learn English"? Lack of bots? Should we propose “huggle lessons for pt”?

There is some discussion on this subject at
https://pt.wikipedia.org/wiki/Project_talk:Projetos/AntiVandalismo

jbribeiro wrote:

(In reply to comment #37)

Stegop,

1. Nobody called you morons (or at least nobody intended to do so).
2. I just mentioned about reenabling it for a few months a few comments

before.

3. No, if you don't know about X you're not dumb, that's called ignorance and

is thanksfully much easier to fix. Sorry, I don't want to look pedantic on
terminology or to bore you with silly samples, but the right thing would be
to
help (teach) you, not to leave ptwiki in stone age.

4. There were some studies (albeit small). See the discussion.
5. Yes, I can read Portuguese, even if not fluently.

I'm sorry you feel like that (not the best path for discussion, but I have
also
needed to rant my frustration from time to time :).

Yes, I would like to help ptwiki to overcome this, preferably without forcing
the captcha to the users for other 5 years. BUT, I don't know exactly the
best
way to do so. Treating me as a dumb moron, how would you define the problem?
Not having a patrol project? Not enough reviewers? Lots of people writing
"learn English"? Lack of bots? Should we propose “huggle lessons for pt”?

:First things first. We're trying to sort out some users who could be more active on Huggle and - I'm impressed by this - some old timers even came back to reclaim their "buttons". But, I think we do have a really great gap to bridge when we talk about bots, filters and scripts. Look at comment 21 above (by user MZMcBride), for instance. I took it to our "Village Pump" three days ago and, discounting GoEThe (who also commented above), I got zip.... I could not find someone who could explain to me why it is "easy" or "obvious". And, going a bit further, we do have a lot of "dead bots". In this matter, if you really want to help (it would be appreciated), talk to our very short list of what I call "wise guys": Alchimista, !Silent, Danilo.mac and Helder.wiki. And, for filters, Kleiner. Those five are the only one (by now) capable of having a meaningful tech-talk with you guys.

jbribeiro wrote:

(In reply to comment #38)

(In reply to comment #37)
...

Not having a patrol project? Not enough reviewers? Lots of people writing
"learn English"? Lack of bots? Should we propose “huggle lessons for pt”?

There is some discussion on this subject at
https://pt.wikipedia.org/wiki/Project_talk:Projetos/AntiVandalismo

:Yes, as I said before, we're trying to sort out why active vandal fighters are not yet rollbackers. Sadly, most of the most active are also some of the more controversial and risk loosing them also if we poke them enough... Still working on this and at least three or four new rollbackers in the last couple of days.

jose.mario.pires wrote:

Thank you for your reply, Platonides.

Maybe your intention wasn't calling us morons, but it was exactly what was done when Nemo writes what he did 2013-06-20 12:19:00 about a poll with dozens with more than double or triple the usual participation in that kind of processes. Curiously that Nemo is the same guy who disabled the captcha without asking anyone and came to PT.WP writing in Italian (like it was a common language anywhere out of Italy), coming from nowhere saying that 2 weeks wasn't enough to decide a thing that the community has been discussing for months.

But let's hope that such thing is hope. Now, let's try to be objetive:

1. The PT.WP presents a noticeable raising in invalid editions that take time to editors to correct since the captcha was disabled.
2. No matter which are the reasons for that, the same way that there isn't any clear opposition the test new methods, nobody from those who propose such things took the initiative of saying "ok, I'll try to implement this or that".
3. Me, and I suppose many more editors, are too tired of listening that "there are more effective means" and "we need studies", but are there any studies about the alternatives? Because our problem now is *real*: we have a great increase of vandalism that we hadn't without the captcha.
4. Being an IT professional (it's because of that I am not much interested in the technical details of things as I don't want to see wikipedia like a second job) I am toooo used to the usual difficulties in communicating with non-techs. But even the most geeky blockheads can understand that saying "I disabled that because it isn't the best solution" without pointing out a concrete alternative minimally tested is completely useless and will do no good to the sympathy of the customer.

Note:

(In reply to comment #41)

[...] writing in Italian (like it was a common language
anywhere out of Italy), [...]

Unlike bugzilla, wiki talk pages don't have English as de facto only language, so people usually don't like to use English there. We're a multilingual community and all languages are well accepted were possible: es, pt, it wikimedians write to each other routinely without imposing the own language to others, depending on context. I'm willing to participate in the discussions as/when/where you like, that was confirmed to be ok in multiple places including https://pt.wikipedia.org/?diff=36171537&oldid=36167076

I don't see a reason to set this back from "shell" to "shellpolicy" as community consensus was clearly provided.

"shellpolicy" is not only about local consensus, but also general consensus and policy and technical reasons; the discussion about those is still ongoing, I don't know what's going to be the conclusion.
It's not *that* clear what the local consensus is for, anyway.

Nemo: Keyword description of "shellpolicy" says "Consensus is needed from someone who is familiar with community standards."
Who would you propose specifically, if not the affected community?
If consensus of the affected community is not sufficient, are those "community standards" defined somewhere?

the discussion about those is still ongoing

Not in the PT community, it seems (or am I missing links?).

but also general consensus and policy and technical reasons

I'd like to see proof that this is a common interpretation of "other considerations" on https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes - or wherever else that interpretation comes from (sources?).
So which exact actions would need to be taken to turn the "shellpolicy" keyword into a "shell" keyword then, to make it actionable?

I'm asking all this because I currently do not see a *clear* ground for rejecting this request, which seems to be supported by a large number of members of PT community.
I do see enough issues to discuss though and lots of different interpretations, and once clearer guidelines have been agreed on or better tools exist to fight the actual problem that led to this request, the potential to reevaluate or even revert the request to reenable the CAPTCHA.

Global consensus is unnecessary. No other request has to wait for that, you are putting the bar unfairly high here because you personally disagree with the change. I suggest you stop attempting to interfere with the ptwiki community's request, you have no more right to try to stop this than any other community member.

Do not modify the shell keyword again.

Oh, and to be clear: There are absolutely no technical issues with this, it was working fine for over 5 years until you got involved. Even if there were it wouldn't be shellpolicy.

As much as I disagree with reenabling the CAPTCHA, Alex and Andre are right here; this is a very very bad solution, but it seems to be a solution indeed.

And now for trying to do something else – I'm willing to help you with AbuseFilter filters and the title backlist mentioned earlier, if only there is a way for me to do that when I don't speak Portuguese :( (I speak a little Spanish, so can understand Portuguese with some help from Google Translate, though).

otavio1981.wiki wrote:

I'm sure lusophone community appreciate any help in developing better tools than captcha to reduce vandalism. We are already monitory the level of vandalism (HAndrade (WMF) is involved with this) and some discussion is going on at [1] regarding to Anti-Vandal project and [2] regarding to abusefilter. So, please what is the best way to contact you, guys (Excluding IRC)? Thanks!

[1] http://pt.wikipedia.org/wiki/Wikip%C3%A9dia_Discuss%C3%A3o:Projetos/AntiVandalismo
[2] http://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Filtro_de_edi%C3%A7%C3%B5es/Solicita%C3%A7%C3%B5es

Since the beginning, it was made clear in discussions that this change is thought to be temporary. Even those that live in the "stone age" - as kindly mentioned above - know that this is not the best solution and that is why it was taken as a way to reduce the amount of edits while we discuss other ways to improve page patrolling, which would replace CAPTCHA in a near future.

Better ways to deal with vandalism are very welcomed. My opposition was only for discussing the vote page itself and for questioning community desire (which is clear), putting non-procedural barriers to make this discussion take a non-resolvent path. The thing is that, while we discuss here, vandalism is happening on wiki and we have signs of overwork and even inability to deal in some periods of the day and we need to do something right now.

I am happy to see that others are willing to help on finding better ways and I am sure community will be pleased to discuss ways to remove CAPTCHA for good in a responsible way.

(In reply to comment #45)

but also general consensus and policy and technical reasons

I'd like to see proof that this is a common interpretation of "other
considerations" on
https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes - or
wherever else that interpretation comes from (sources?).

I think you want [[m:Limits to configuration changes]].

I'm asking all this because I currently do not see a *clear* ground for
rejecting this request, which seems to be supported by a large number of
members of PT community.

There are fundamental principles on Wikimedia wikis that cannot be violated. For example, even if a project really wanted to add Google Analytics or Google Adwords to its site (and had a vote with overwhelming consensus to implement the change), that would not be allowed.

Plenty of requests are unambiguous and easy to resolve. Some requests get murky when they threaten core principles. Using the "shellpolicy" keyword to mark bugs that fall into the latter category doesn't seem particularly inappropriate to me. But it seems like a silly thing to argue over.

The real question is whether any shell user is willing to merge and deploy the proposed change. My bet is that the answer is yes, but I'm still not sure merging the change is the best course of action. Perhaps as a temporary measure with a finite expiry.

(In reply to comment #51)

The real question is whether any shell user is willing to merge and deploy
the
proposed change.

Well, and also whether if it won't be reverted by another shell user. :)
Considering that we now have proof that the all-edits CAPTCHA didn't affect vandalism, but merely reduced (a lot) both good and bad edits, adding it would directly and blatantly contradict the WMF strategic plan (participation goal).
The strategy is at board level and not even WMF staff, but in this case the interpretation of it seems simple: it doesn't directly apply to everyone, though (e.g. pt.wiki probably doesn't care), so perhaps a volunteer shell user would be more confident about ignoring it; unless someone (the CTO?) redefines the strategy's interpretation...

On a community/general point of view, there's still much more to say about this request but the discussion is continuing at all levels so I'll leave it for later.

By the way, we have a new dump: http://dumps.wikimedia.org/ptwiki/20130622/ I eagerly wait for WikiStats. :)

With all due respect, but if this was such a clear and evident conflict with wikimedia principles or even with the strategic plans, why wasn't that fact brought up to light several months ago? The previous bug started on November 2012, and as far as i see, it was never brought up. In fact, it was stated that if a new resolution came out, it could be restored[1]. Right now, and without intent to offend anyone, and specially not MZM which has my respect and didn't participate in the previous bug, but this seems like a Kafkian situation.

It was disabled because the original vote wasn't clear, now that there's a clear and transparent community decision, the problem is the WMF ST, and what's next? The sun and the moon alignment isn't perfect? I'm provably being a little rude here, but honestly, it's so frustration to think that my community went to several wiki discussions, irc discussions, got stressed, and in the end, it was for nothing because what was valid and a sugested solution on April, now it's not.

And this brings an important point on a collaborative project. If things aren't clear and transparent, and there is not a mutual respect, it's condemned to failure, and we all should remember this point. Like many others said, there's been on wiki discussions, this situation has been discussed on bug 41745, so if it was such a violation, why didn't anyone reported yet, on the bug, or even on the wiki discussions?

Finally, what would fit more the WMF Strategic Plan: go against a clear and overwhelming community decision, causing the entropy and distrust that everyone can see in the wiki discussions and this two bugs, or, enabling captcha and work with the community in order that everyone (or at least the vast majority of the community) peaceful decide that it's everything prepared to live without emergencycaptcha?

1. https://bugzilla.wikimedia.org/show_bug.cgi?id=41745#c10

I think time's ripe for me to stop watching this bug and go waste my time somewhere else.

(In reply to comment #53)

Finally, what would fit more the WMF Strategic Plan: go against a clear and
overwhelming community decision, causing the entropy and distrust that
everyone
can see in the wiki discussions and this two bugs, or, enabling captcha and
work with the community in order that everyone (or at least the vast majority
of the community) peaceful decide that it's everything prepared to live
without
emergencycaptcha?

This looks like a false dichotomy and loaded rhetorical question.

As for the rest, there were no "promises", it was simply noted (bug 41745 comment 11, 13, 18, 26 etc,; comment 2) that discussion on wiki was needed and very useful (not that it was sufficient, see e.g. comment 14 or bug 41745 comment 31).
In any case, we can't be blind to the new information we have gained in the last months, just to prove a point.

Alchimista: What do you think about the idea of setting a fixed expiry for this setting (hard or soft)? A soft expiry would be an accompanying code comment saying "please remove this setting after 2014-06-25". A hard expiry would be PHP logic that automatically disables the setting after 2014-06-25.

My personal feeling (and I have no idea if this is shared) is that this is a very sub-optimal situation that everyone would like to address. I think setting a year expiry would alleviate some concerns about principles while allowing the temporary solution to function. A year seems like a sufficient amount of time to work together to fix the underlying issue and make the CAPTCHA no longer needed for these edits.

(In reply to comment #56)

Alchimista: What do you think about the idea of setting a fixed expiry for
this
setting (hard or soft)? A soft expiry would be an accompanying code comment
saying "please remove this setting after 2014-06-25". A hard expiry would be
PHP logic that automatically disables the setting after 2014-06-25.

My personal feeling (and I have no idea if this is shared) is that this is a
very sub-optimal situation that everyone would like to address. I think
setting
a year expiry would alleviate some concerns about principles while allowing
the
temporary solution to function. A year seems like a sufficient amount of time
to work together to fix the underlying issue and make the CAPTCHA no longer
needed for these edits.

This seems a very reasonable mid-term solution for the impasse. One year should be enough so that community can adjust it self for the non-captcha world, without the pressure of a tight schedule, and allowing to get ride of emergency captcha by it's own decision, and at the same time, a fixed one year deadline would, like you've said, alleviate some concerns about the principles. I believe that if this solution gets well explained to local community, it'll provably be understood, and i can try it if needed.

jbribeiro wrote:

(In reply to comment #57)

(In reply to comment #56)

Alchimista: What do you think about the idea of setting a fixed expiry for
this

I can agree to that too and I think we'll find no problems in the community. And since we have now lots of skilled people willing to help, I'm sure this whole thing will come to a sensible solution in the period. And, if this is done together with bug 41522 (as Helder proposed above), we surely can have, in a year, hard data on a major wiki about this thing that surely would be helpful no only to us but to support any research about CAPTCHA.

Thank you both for the feedback. It's been very helpful.

Alex M. (Krenair) is working on this at Gerrit changeset 69982. The change is nearly ready to be implemented, we just need to figure out whether to implement a hard expiry or a soft expiry (cf. comment 56). Once that's figured out, this change can be merged and deployed, I think.

Assuming no further objections or obstacles, I imagine Sam R. (Reedy) will be able to do this on Monday, July 1.

We'll have the new revert stats for June shortly after the month ends and discussions are still active on pt.wiki, so it doesn't make much sense to make hasty moves now.

As for the time needed, discussions on the matter on pt.wiki have never been active for more than a few consecutive days, so a year won't help figuring out anything; a couple months would be more than enough.

There is no active discussion on pt.wiki about CAPTCHA. Community already made it's decision.

Active discussions refers to other ways of dealing with vandalism, which will also be necessary on CAPTCHA removal, but won't be enough or won't be implemented soon. We are aware that CAPTCHA won't be there forever.

Thanks for attending this request.

That's what I said. How do you know they won't be enough? I don't see that in the discussions.

There is no "they" yet; only ideas, nothing really solid and still unlikely to be implemented in the next two months. What should we do in this meanwhile? Pretend that we are doing ok with vandalism?

I don't know what kind of argument is that... you are saying that recently created ideas will be enough because it not said that they won't be enough? There are infinite unsaid things there and I can't say they are true. There's an inversion here; it should be said that they 'are' enough for we start thinking on it.

(In reply to comment #63)

it should be said that they 'are' enough for we start
thinking on it.

This perfectly shows why pt.wiki had a CAPTCHA, now proven useless and counter-productive, for 5 years: *of course* you can't know if something works before trying it. But if you refuse to think about solutions, quite naturally solutions won't implement themselves.
You've not even tried to tell users that there's a problem with vandalism and they need to help with patrolling... no wonder they don't.

(In reply to comment #64)

(In reply to comment #63)

it should be said that they 'are' enough for we start
thinking on it.

This perfectly shows why pt.wiki had a CAPTCHA, now proven useless and
counter-productive, for 5 years: *of course* you can't know if something
works
before trying it. But if you refuse to think about solutions, quite naturally
solutions won't implement themselves.

So, if nobody says it is 'not' enough we implement it?

You've not even tried to tell users that there's a problem with vandalism and
they need to help with patrolling... no wonder they don't.

You really have no idea what you are saying. I don't even follow pt.wiki discussions to say that. I do that for years (example on a related discussion where that is exactly what I say: [1]). I always said we need more sysops, rollbackers, hugglers, patrollers or any kind of user willing to help with vandalism. That only proves your comments are false; just like this comment is false: "discussions on the matter on pt.wiki have never been
active for more than a few consecutive days". One more time, I have to come here and say what is already obvious for pt.wiki users and defend me from a false accusation.

It is obvious that we need more users and not only me but others say that too. But this way of trying to push a point of view is getting ridiculous and it is sad that you are starting to use false statements to defend your ideas. Readers should start being more careful when reading your comments.

[1] - https://pt.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:Esplanada/geral/Salebot_parado_(17mai2013)&diff=35793682&oldid=35792157

jbribeiro wrote:

(In reply to comment #64)

(In reply to comment #63)

it should be said that they 'are' enough for we start
thinking on it.

This perfectly shows why pt.wiki had a CAPTCHA, now proven useless and
counter-productive, for 5 years: *of course* you can't know if something
works
before trying it. But if you refuse to think about solutions, quite naturally
solutions won't implement themselves.
You've not even tried to tell users that there's a problem with vandalism and
they need to help with patrolling... no wonder they don't.

Please, Nemo, stop trying to talk for us because you ARE NOT one of us. Don't pretend to know the first thing about what happens down there. If you continue this path, you'll eventually be blocked and shunned there for gross misrepresentation. If you want to be a productive member of our community, learn to respect it first, specially when it disagrees with you.

Once again you two make use of personal attacks against anyone disagreeing with you. :) (As was previously done with half a dozen of pt.wiki users, see bug 41745 comment 39.)

I've never said what comment 65 claims I said and I never claimed to represent the pt.wiki community as comment 66 accuses.
I respect the community and I wouldn't be participating in this discussion if I didn't do so or if I didn't care about pt.wiki; however, I can't respect personal attacks and bullying.

I am sure you can show me where my comment has personal attacks. I say you have made false statements, because you did. You should be more careful with what you say. You said I didn't do something I do a lot.

(In reply to comment #67)

Once again you two make use of personal attacks against anyone disagreeing
with
you.

You said "Once again". Show me the other time I did it, please. Otherwise, that is another false accusation.

Like I said earlier, you seem to be looking for ways to lead this conversation to a non resolvent path. That is why I asked for review of a sysadmin, that I am sure would choose a better way to deal with that.

In general: Could we please move "Show me your personal attacks" questions and discussions outside of this bug report, e.g. into private emails? I'm interested in receiving bugmail about this ticket, not about personal misunderstandings.
Assume people mean well and have good intentions, please.

I hate to say this but I recommend that this be rejected and closed as WONTFIX. The CAPTCHA was intended to be a temporary measure that became all-too permanent; there exist better tools for addressing floods of bad edits (such as AbuseFilter).

I should be very interested to see how many *good faith* edits were rejected over the past several years, but I think that's a pipe-dream.

I think this request violates the spirit of our core principles if not the letter thereof.

jbribeiro wrote:

(In reply to comment #70)

I hate to say this but I recommend that this be rejected and closed as
WONTFIX.

I'm sad because we tried our best and so far, NOTHING happened. Most of our most active patrollers simply gave up (myself included) and not a *single alternative measure* has been implemented so far - or, should I note, perhaps we have now lots of inactive rollbackers recently promoted). But the damage is done and we *looove* this kind of thing since we're used to "luminars" using force (or avoiding to do so when asked) to keep a community in line: our beloved-coup d'etat-prone military! Technocracy, huh? And with WMF help! I'm shocked and I'm sure it'll help a lot with the credibility of the VERY FEW WMF members trying to implement "the official plan" in our community. It is very easy to preach the "'we need new editors' gospel" when, behind the scenes, this is the kind of s*** we get even with overwhelming community support (even if it is for a short time while, we hope(d), some of you guys would snap out of this DEVELOPER-PROTECTOR-OF-THE-WIKI-SPIRIT-ATTITUDE and actually DO SOMETHING to help us!). One year is to much, really? What about 3 months conditioned to something actually being done?

The Gerrit change 69982 is ready to be merged, so a temporary reinstatement of CAPTCHA is hopefully quite close.

(In reply to comment #72)

The Gerrit change #69982 is ready to be merged [...]

Gerrit changeset 69982 is currently marked as a work in progress ("[WIP]" in the commit message).

(In reply to comment #71)

[...] not a *single
alternative measure* has been implemented so far - or, should I note, perhaps
we have now lots of inactive rollbackers recently promoted). [...]

Just to mention one thing, this is actually not correct: pt.wiki community has managed to reverse the trend, with an increase of the number of active rollbackers and a decrease of the weight on the most active administrators.
https://pt.wikipedia.org/w/index.php?title=Usu%C3%A1rio%28a%29:HAndrade_%28WMF%29/Pesquisa_Vandalismo/Segunda_Fase&oldid=36301585#Combatentes

A thing that is perhaps not moving (enough): I see Helder has already worked on several abuse filters; but both him and others would be able to help more with abuse filter suggestions if you or someone else made a sample list of vandal edits, reasonably big (in the thousands) for study. You may know these edits, as you say "the damage is done".

Dear Portuguese Wikipedia community.

We've carefully reviewed the requested operations change to reinstate the emergency CAPTCHA on the Portuguese Wikipedia that forces all non-autoconfirmed users to complete a CAPTCHA for any edit.

Our understanding is that there is significant concern among the Portuguese Wikipedia community about an increase in vandalism and low-quality edits. These edits cannot be properly monitored and reverted without the CAPTCHA being in place, at least temporarily. We are aware that a CAPTCHA in emergency mode configuration was set up in January 2008, when there was a crisis, and since then it has not been removed until this year. We know there has been a lot of discussion lately about the use of a CAPTCHA, and the recent changes made by the MediaWiki community were controversial among the Portuguese Wikipedia community. Hence, we've carefully taken all perspectives into consideration.

We believe that a CAPTCHA implemented in this way is a very poor tool for managing vandalism or spam. The CAPTCHA presents a barrier to new contributors and lowers all edit rates both good and bad, which is the antithesis of our mission. The Wikimedia CAPTCHA is poorly readable, uses an English language dictionary, and does not work for users with impaired vision.

There are better tools, such as the AbuseFilter, Spam Blacklist, and Twinkle, as well as various vandalism monitoring tools that could be ported to the Portuguese Wikipedia. With the exception of Portuguese Wikipedia, *all* other Wikimedia projects use the combination of these existing tools to deal with vandalism, spam, and low-quality edits.

A CAPTCHA for non-autoconfirmed edits is not compatible with the Wikimedia movement's core values. Specifically, enabling every person on the planet to share in the sum of all knowledge.

At the same time, we recognize that the Portuguese Wikipedia community has been deliberating over this issue for some time, and that a sudden change of configuration may not have offered you sufficient time to explore alternative solutions. We are aware you are working on the anti-vandalism project (http://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Projetos/AntiVandalismo). Let us know if we can help with any type of support for that.

To this end, we agree to re-enable the emergency CAPTCHA for non-autoconfirmed users. However, we will permanently disable the emergency CAPTCHA mode by December 31, 2013, if no decision to disable it sooner is reached by the community. In the meantime, we will continue to engage in dialog about alternatives.

• Erik Moeller, Deputy Director, Wikimedia Foundation

(The Portuguese translation below was prepared by Oona Castro.)

Prezada Comunidade da Wikipedia em português,

Nós cuidadosamente avaliamos a solicitação de re-implantação do “CAPTCHA emergencial” na Wikipédia em Português, que força todos os usuários não autoconfirmados a preencherem o CAPTCHA para qualquer edição.

Nosso entendimento é de que há grande preocupação da comunidade da Wikipédia em português em relação ao crescimento de vandalismo e edições de baixa qualidade - que não teriam como ser propriamente monitoradas e revertidas sem o CAPTCHA emergencial em operação, pelo menos temporariamente. Estamos cientes de que essa configuração do CAPTCHA estava ativa desde janeiro de 2008, quando houve uma crise e, desde então, nunca havia sido retirado, até a remoção em abril de 2013. Sabemos que houve muitas discussões recentemente sobre o uso do CAPTCHA e que a mudança feita pela comunidade do Mediawiki gerou controvérsias na comunidade da Wikipédia em português. Por isso, tivemos o cuidado de levar as diversas perspectivas e opiniões em consideração.

Acreditamos que o CAPTCHA implementado desta forma é uma ferramenta pouco apropriada para gerenciar vandalismo ou SPAM, uma vez que representa uma barreira para novos editores e usá-la para reduzir o número de edições, boas ou ruins, é a antítese de nossa missão. O CAPTCHA da Wikimedia é quase ilegível, usa o inglês como dicionário e não funciona para deficientes visuais.

Há ferramentas melhores, como o AbuseFilter, Twinckle, assim como diversas ferramentas de monitoramento de vandalismo que podem ser localizadas para a Wikipédia em Português. Com exceção da Wikipédia em português, *todos* os outros projetos Wikimedia usam a combinação dessas ferramentas para lidar com vandalismo, SPAM e edições inapropriadas ou de baixa qualidade.

Um CAPTCHA para quais edições não autoconfirmadas não é compatível com os principais valores do movimento Wikimedia - em especial, permitir que todas as pessoas no mundo contribuam com o compartilhamento de todo o conhecimento do planeta.

Ao mesmo tempo, reconhecemos que a comunidade da Wikipédia em Português vêm discutindo a questão por um bom tempo, e que uma mudança repentina na configuração possa não ter oferecido tempo suficiente para vocês explorarem soluções alternativas. E estamos cientes de que a comunidade está trabalhando no projeto Antivandalismo (http://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Projetos/AntiVandalismo). Informe-nos se podemos ajudá-los com algum tipo de apoio específico nesta empreitada.

Para que consigam estruturar soluções alternativas, concordamos em reabilitar o CAPTCHA emergencial para usuários não autoconfirmados. Continuaremos engajados no diálogo sobre alternativas, mas vamos definitiva e permanentemente desabilitar o CAPTCHA emergencial em 31 de dezembro de 2013, se nenhuma decisão da comunidade por desabitá-lo ocorrer antes.

• Erik Moeller, Wikimedia Foundation Deputy Director

Another tool to consider: 1) https://meta.wikimedia.org/wiki/FlaggedRevs (used by pt.wikibooks, pt.wikisource, pt.wikinews), 2) Enable page creation only for confirmed users.

Before taking those two measurements, our (id.wp) community was vandalized more than the patrollers could handle, and our community voted to disable anonymous editing. Of course it was swiftly rejected ([[Bug 20666]]) because violation of core principles. In the end, we had those two vandalism prevention system (FlaggedRevs [[Bug 24010]]+AbuseFilter), and vandalism was decreased. Too bad there were no study (numbers) on this yet AFAIK.

It will be a pitty not to have any way to know how many users will give up of their edits after they are asked to solve the CAPTCHA during this new emergency period... :-(

(In reply to comment #77)

It will be a pity not to have any way to know how many users will give up of
their edits after they are asked to solve the CAPTCHA during this new
emergency period... :-(

From https://noc.wikimedia.org/conf/InitialiseSettings.php.txt:

'wgDebugLogGroups' => array(
'default' => array(
[...]

		'captcha' => "udp://$wmfUdp2logDest/captcha",

Perhaps ptwiki should be special-cased for the next few months (i.e., write to its own log file)? Feel free to submit a changeset. :-)

(In reply to comment #77)

It will be a pitty not to have any way to know how many users will give up of
their edits after they are asked to solve the CAPTCHA during this new
emergency
period... :-(

Well, we sort of know already from the stats of these months, though July is still missing: it is about 30-50 thousands productive (not reverted) edits per month, so around 150-250 thousands edits sacrificed to this "trial period", more or less like trashing half of an annual global Wiki Loves Monuments.
https://pt.wikipedia.org/?oldid=36301585

By the way, I was told that the search for alternatives to the CAPTCHA was stuck, with several community members refusing to run a campaign to recruit vandal-fighters before the CAPTCHA is enabled. https://pt.wikipedia.org/?diff=36511892&oldid=36329606
Is there any indication that this trial period with the editing activity killer enabled will actually be used to trial something and to find new solutions? I've not checked the local discussions in the last few days.

(In reply to comment #79)

Well, we sort of know already from the stats of these months, though July is
still missing: it is about 30-50 thousands productive (not reverted) edits
per
month, so around 150-250 thousands edits sacrificed to this "trial period",
more or less like trashing half of an annual global Wiki Loves Monuments.
https://pt.wikipedia.org/?oldid=36301585

Right now, we don't know if those edits are not reverted because they are productive or if the community is overwhelmed, so I wouldn't make that conclusion just yet.

By the way, I was told that the search for alternatives to the CAPTCHA was
stuck, with several community members refusing to run a campaign to recruit
vandal-fighters before the CAPTCHA is enabled.
https://pt.wikipedia.org/?diff=36511892&oldid=36329606

I don't think that is the case.

Is there any indication that this trial period with the editing activity
killer
enabled will actually be used to trial something and to find new solutions?
I've not checked the local discussions in the last few days.

Work in the abuse filters is ongoing, and someone proposed to have a vote whether or not to prevent anonymous editors of writing new articles, but hopefully this will be cancelled soon. https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Vota%C3%A7%C3%B5es/Cria%C3%A7%C3%A3o_de_artigos_por_usu%C3%A1rios_an%C3%B4nimos. Other measures, like porting other tools to Portuguese will probably take longer to implement.

(In reply to comment #80)

Right now, we don't know if those edits are not reverted because they are
productive or if the community is overwhelmed, so I wouldn't make that
conclusion just yet.

As far as I remember the unpatrolled edits stats don't show an increase in unreviewed edits, apart from being much better than in other big wikis like fr.wiki or it.wiki, so I doubt there are big portions of unreviewed vandalism. Of course this by itself doesn't mean that current antivandalism efforts are sustainable.

Helder's question however was simpler than this I think, I don't think the CAPTCHA log proposal is about measuring the quality of those edits? He's right that we should have at least have some way to monitor the situation and the consequences of the trial before starting it, though...

Change 69982 merged by Tim Starling:
Enable CAPTCHA for all edits of non-confirmed users on pt.wikipedia in order to reduce editing activity

https://gerrit.wikimedia.org/r/69982

(In reply to comment #75)

However, we will permanently disable the emergency CAPTCHA mode by
December 31, 2013, if no decision to disable it sooner is reached by the
community.

Hello Tim, the deadline is approaching: are you the one in charge of doing this, or someone else?

(In reply to comment #83)

Hello Tim, the deadline is approaching: are you the one in charge of doing
this, or someone else?

Hi Nemo,

Thanks for the ping. Reedy will deploy the config change on Dec 31st (given it is New Year's Eve, I can't promise a specific time). See:
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_December_30

Thanks all.

jbribeiro wrote:

(In reply to comment #84)

(In reply to comment #83)

Hello Tim, the deadline is approaching: are you the one in charge of doing
this, or someone else?

Hi Nemo,

Thanks for the ping. Reedy will deploy the config change on Dec 31st (given
it
is New Year's Eve, I can't promise a specific time). See:
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_December_30

Thanks all.

I was one of the most strongly opposed to this six months ago and I'm happy to declare that, although we have not done everything we could have done, we did the best we could knowing what would happen in advance. Thank you guys for giving us some space to work out our internal issues without loosing your own principles. This has reassured me that this is, in fact, a collaborative endeavour. ~~~~

(In reply to comment #84)

Reedy will deploy the config change on Dec 31st (given it
is New Year's Eve, I can't promise a specific time). See:
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_December_30

Just a quick update: To be safe, the change won't happen until Thursday the 2nd (the above link is still accurate). This is due to the 1st being a holiday (thus, not many people with access to fix brokenness will be online). We have a pretty firm policy of not deploying things on the day before people won't be working (ie: all Fridays, and days before holidays).

I know this seems straightforward, but we don't want anything odd to happen with this change.

Thanks for your understanding.

(PS: also, when looking at the [[:wikitech:Deployments]] calendar, be sure to take note of the UTC/Pacific columns, as the regularly scheduled "Lightning Deploy" window at 4pm Pacific appears to be on the next day, due to that being 24:00/0:00 UTC. Timezones are fun.)

CAPTCHA is now gone. Let's celebrate!