I'm tempted to point out that this mainly affects new editors who cite their edits, other new editors will get bitten in other ways. But the internet is not the best venue for irony.
More practically, if you have a tame admin on tap then you can reduce this and other problems at editathons by setting those new accounts as "confirmed". And yes I know we also have a shortage of admins, and also that it is likely that only a tiny proportion of the editors we lose through this are at editathons.
Earlier this year as a result of the glam organisers event in Paris I made a proposal at bugzilla for an event organisers useright. This would have allowed us to circumvent this problem at those editathons that are targeted at newbies, and it got widely endorsed by GLAM editors from several languages. Sadly it got marked as resolved because there was something that looked similar to developers, though not of course to potential users. If anyone here knows how to bypass phabricator or how to mark a phabricator request as unresolved and still much wanted, then the link is https://phabricator.wikimedia.org/T91928 alternatively perhaps we could persuade the education community to endorse it, it should be just as useful to them and they seem to have more clout with the WMF than the GLAM community.
As for whether the capcha is useful in keeping out spammers, remember there are two capcha steps, one when you open a new account and the other when you use that to add links. Presumably any spam program that can pass the first hurdle can pass the second. But for new good faith human editors each capcha is a possible lost edit/editor. It would be good to test dropping the capcha requirement for adding new links, alternatively perhaps we could whitelist certain domains as likely to be reliable sources and unlikely to be spam.
Regards
Jonathan
Interesting. I see that you opened the task for the user-right, but this is a result of a decision to make a catch-all fix for several problems. I think the capcha problem is extremely annoying and goes way beyond the scope of the one-off edit-a-thon, so this specific issue should have its own task number. "Tame admins" are rarely on tap so not a solution for the user-right but does the throttle override work now? I can't see where that fix is confirmed anywhere.
On Fri, Jun 19, 2015 at 2:54 PM, WereSpielChequers < werespielchequers@gmail.com> wrote:
I'm tempted to point out that this mainly affects new editors who cite their edits, other new editors will get bitten in other ways. But the internet is not the best venue for irony.
More practically, if you have a tame admin on tap then you can reduce this and other problems at editathons by setting those new accounts as "confirmed". And yes I know we also have a shortage of admins, and also that it is likely that only a tiny proportion of the editors we lose through this are at editathons.
Earlier this year as a result of the glam organisers event in Paris I made a proposal at bugzilla for an event organisers useright. This would have allowed us to circumvent this problem at those editathons that are targeted at newbies, and it got widely endorsed by GLAM editors from several languages. Sadly it got marked as resolved because there was something that looked similar to developers, though not of course to potential users. If anyone here knows how to bypass phabricator or how to mark a phabricator request as unresolved and still much wanted, then the link is https://phabricator.wikimedia.org/T91928 alternatively perhaps we could persuade the education community to endorse it, it should be just as useful to them and they seem to have more clout with the WMF than the GLAM community.
As for whether the capcha is useful in keeping out spammers, remember there are two capcha steps, one when you open a new account and the other when you use that to add links. Presumably any spam program that can pass the first hurdle can pass the second. But for new good faith human editors each capcha is a possible lost edit/editor. It would be good to test dropping the capcha requirement for adding new links, alternatively perhaps we could whitelist certain domains as likely to be reliable sources and unlikely to be spam.
Regards
Jonathan
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 19 June 2015 at 13:54, WereSpielChequers werespielchequers@gmail.com wrote:
Earlier this year as a result of the glam organisers event in Paris I made a proposal at bugzilla for an event organisers useright. This would have allowed us to circumvent this problem at those editathons that are targeted at newbies, and it got widely endorsed by GLAM editors from several languages. Sadly it got marked as resolved because there was something that looked similar to developers, though not of course to potential users. If anyone here knows how to bypass phabricator or how to mark a phabricator request as unresolved and still much wanted, then the link is https://phabricator.wikimedia.org/T91928
I've reopened it - please comment there.
Hi all,
I know this might be a bit off topic but I'll risk it anyways.
One told me a couple weeks ago that CAPTCHA (at least one CAPTCHA) was created or used to transcribe documents bit by bit, each word you enter corresponds to a two word link, that when it reaches so many equal responses is marked as resolved and moved to the next word on a document.
Wouldn't be wonderful if we could use this idea to transcribe documents in Wikisource, create our own CAPTCHA for the benefit of our own projects.
Also, filling up a CAPTCHA this way, would make it count as one more edit.
Thus we will be more synergetic towards our own efforts, and have a CAPTCHA might make sense overall if needed.
Please fill free to separate the thread or correct me, since I only used my friends story as a source.
Best! El jun. 19, 2015 10:59 AM, "Andy Mabbett" andy@pigsonthewing.org.uk escribió:
On 19 June 2015 at 13:54, WereSpielChequers werespielchequers@gmail.com wrote:
Earlier this year as a result of the glam organisers event in Paris I
made a proposal at bugzilla for an event organisers useright. This would have allowed us to circumvent this problem at those editathons that are targeted at newbies, and it got widely endorsed by GLAM editors from several languages. Sadly it got marked as resolved because there was something that looked similar to developers, though not of course to potential users. If anyone here knows how to bypass phabricator or how to mark a phabricator request as unresolved and still much wanted, then the link is https://phabricator.wikimedia.org/T91928
I've reopened it - please comment there.
-- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Yes, I think it's a great idea! T34695 https://phabricator.wikimedia.org/T34695 has been assigned to me for a while, but I'd use some help.
Il 19/06/2015 16:17, Eduardo Testart ha scritto:
Hi all,
I know this might be a bit off topic but I'll risk it anyways.
One told me a couple weeks ago that CAPTCHA (at least one CAPTCHA) was created or used to transcribe documents bit by bit, each word you enter corresponds to a two word link, that when it reaches so many equal responses is marked as resolved and moved to the next word on a document.
Wouldn't be wonderful if we could use this idea to transcribe documents in Wikisource, create our own CAPTCHA for the benefit of our own projects.
Also, filling up a CAPTCHA this way, would make it count as one more edit.
Thus we will be more synergetic towards our own efforts, and have a CAPTCHA might make sense overall if needed.
Please fill free to separate the thread or correct me, since I only used my friends story as a source.
Best!
On 19 June 2015 at 14:58, Andy Mabbett andy@pigsonthewing.org.uk wrote:
On 19 June 2015 at 13:54, WereSpielChequers werespielchequers@gmail.com wrote:
Earlier this year as a result of the glam organisers event in Paris I made a proposal at bugzilla for an event organisers useright. This would have allowed us to circumvent this problem at those editathons that are targeted at newbies, and it got widely endorsed by GLAM editors from several languages. Sadly it got marked as resolved because there was something that looked similar to developers, though not of course to potential users. If anyone here knows how to bypass phabricator or how to mark a phabricator request as unresolved and still much wanted, then the link is https://phabricator.wikimedia.org/T91928
I've reopened it - please comment there.
It's been closed again. Nonetheless, please do comment.
ThrottleOverride extension is not deployed on WMF cluster[1] so your best bet is to create a new bug which is already deployed on WMF cluster.
[1] this means even if this is fixed, you will not see the fixed code on wikimedia wikis.
-- Revi https://www.revi.pe.kr -- Sent from Android -- 2015. 6. 19. 오후 11:31에 "Andy Mabbett" andy@pigsonthewing.org.uk님이 작성:
On 19 June 2015 at 14:58, Andy Mabbett andy@pigsonthewing.org.uk wrote:
On 19 June 2015 at 13:54, WereSpielChequers werespielchequers@gmail.com
wrote:
Earlier this year as a result of the glam organisers event in Paris I
made a proposal at bugzilla for an event organisers useright. This would have allowed us to circumvent this problem at those editathons that are targeted at newbies, and it got widely endorsed by GLAM editors from several languages. Sadly it got marked as resolved because there was something that looked similar to developers, though not of course to potential users. If anyone here knows how to bypass phabricator or how to mark a phabricator request as unresolved and still much wanted, then the link is https://phabricator.wikimedia.org/T91928
I've reopened it - please comment there.
It's been closed again. Nonetheless, please do comment.
-- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 06/19/2015 05:54 PM, WereSpielChequers wrote:
Earlier this year as a result of the glam organisers event in Paris I made a proposal at bugzilla for an event organisers useright. This would have allowed us to circumvent this problem at those editathons that are targeted at newbies, and it got widely endorsed by GLAM editors from several languages. Sadly it got marked as resolved because there was something that looked similar to developers, though not of course to potential users. If anyone here knows how to bypass phabricator or how to mark a phabricator request as unresolved and still much wanted, then the link is https://phabricator.wikimedia.org/T91928 alternatively perhaps we could persuade the education community to endorse it, it should be just as useful to them and they seem to have more clout with the WMF than the GLAM community.
I'm sorry that that task was closed (and that there has been no recent activity on it - excluding today's) but it really is a duplicate and was asking for functionality which ThrottleOverride extension already has (with other features). Phabricator tasks generally should ask for one single feature per task so that it is easy for developers to implement it. This particular task had lots of requests in it so it's not very clear. The extension is currently not deployed on Wikimedia wikis because it lacks some basic functionality like modifying and logging. You could probably file smaller tasks asking for several features which would allow the event organizer group to be implemented for real.
As for skipping CAPTCHA, this functionality is already available through 'skipcaptcha' right (which all autoconfirmed users have). If you want to ask for a new group, you can make a proposal on a local discussions venue like village pump. This user group (event organizer) would be able to grant users 'confirmed' group to other users so that the new users do not have to go through CAPTCHAs while trying to edit. If there is consensus for it, you can file a task on Phabricator to get the new group implemented.
As for whether the capcha is useful in keeping out spammers, remember there are two capcha steps, one when you open a new account and the other when you use that to add links. Presumably any spam program that can pass the first hurdle can pass the second. But for new good faith human editors each capcha is a possible lost edit/editor.
I also do agree that CAPTCHAs are not very user friendly and is bad for good faith newbie human editors. I have also sometimes had trouble solving CAPTCHAs myself on some occassions. However, spambots which are able to pass in one CAPTCHA test can easily pass the same type of CAPTCHA again so we can't assume that all accounts which are able to solve the captcha at registration are not bots. Currently, a non-trivial amount of time is spent by our wiki administrators and stewards just for fighting these spambots so we can't just turn CAPTCHAs completely.
It would be good to test dropping the capcha requirement for adding new links, alternatively perhaps we could whitelist certain domains as likely to be reliable sources and unlikely to be spam.
Whitelisting certain links is also currently technically available. See English Wikipedia's whitelist page for example [1] but this is not really used probably because many users are not aware of this feature.
It is also possible to exempt certain IP addresses or ranges from CAPTCHAs but this is only currently doable through server-side config but I don't remember seeing a request asking an IP to be whitelisted for an editathon. We could probably allow this whitelist list to also be also modified on wiki so that event organizers can ask for it without going through the hassle of asking on Phabricator and getting it deployed in a timely fashion. I've filed this as a task. [2] I would also like to suggest that editathon organizers ask for the IPs to be whitelisted on Phabricator when organizing events.
I think that using these suggestions I mentioned above would help in this issue during editathons but I'm not sure we've lots of alternatives for regular edits. We could probably allow all users with a confirmed email to bypass the captchas. What does others think about this idea?
There is a problem with CAPTCHAs but disabling CAPTCHAs completely is definitely not the solution, imo.
1. https://en.wikipedia.org/wiki/MediaWiki:Captcha-addurl-whitelist 2. https://phabricator.wikimedia.org/T103122
Events sometimes get whitelisted for account creation purposes: https://noc.wikimedia.org/conf/throttle.php.txt The exceptions there there could be made to set $wgCaptchaWhitelistIP too.
On Fri, Jun 19, 2015 at 8:54 AM, WereSpielChequers werespielchequers@gmail.com wrote:
alternatively perhaps we could whitelist certain domains as likely to be reliable sources and unlikely to be spam.
There actually already is a whitelist ($wgCaptchaWhitelist in https://noc.wikimedia.org/conf/CommonSettings.php.txt). Unfortunately, as far as I know, there's no on-wiki way to change it, but you could always compile a list of domains and submit it through Phabricator.
It's true that events *can* get whitelisted, but this is a very complex method. It relies on the organiser knowing the IP ranges in advance, and knowing who to contact at WMF - and on WMF having the time to deal with it. It would rapidly break down if we needed to use this method for every small training session. (I used to do two or three workshops a week...)
Andrew.
On 19 June 2015 at 19:16, Benjamin Lees emufarmers@gmail.com wrote:
Events sometimes get whitelisted for account creation purposes: https://noc.wikimedia.org/conf/throttle.php.txt The exceptions there there could be made to set $wgCaptchaWhitelistIP too.
On Fri, Jun 19, 2015 at 8:54 AM, WereSpielChequers werespielchequers@gmail.com wrote:
alternatively perhaps we could whitelist certain domains as likely to be reliable sources and unlikely to be spam.
There actually already is a whitelist ($wgCaptchaWhitelist in https://noc.wikimedia.org/conf/CommonSettings.php.txt). Unfortunately, as far as I know, there's no on-wiki way to change it, but you could always compile a list of domains and submit it through Phabricator.
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hi,
I agree with Andrew that is not practical to whitelist ip addresses as a primary method of overcoming account creation/ CAPTCHA issues at events. Organizers often will not know the ip range in advance because of changes in the address, or last minute changes in the location of the event.
The solution(s) needs to be something that is easy to use for people with minimal tech knowledge so we can expand the group of people who are sponsoring and holding events.
This problem goes back to a core issue that effect outreach efforts: Wikipedia was originally set up to be edited by people sitting alone with a PC/laptop.
Although today many outreach efforts are directed at group events or partner organizations, these new editors still need to fit into polices and a tech environment where editing solo is the norm.
To attract different groups of people to WMF projects, changing methods of dealing with group editing or the new account creation experience needs to be a priority.
Sydney
Sydney
Sydney Poore User:FloNight Wikipedian in Residence at Cochrane Collaboration
On Fri, Jun 19, 2015 at 2:24 PM, Andrew Gray andrew.gray@dunelm.org.uk wrote:
It's true that events *can* get whitelisted, but this is a very complex method. It relies on the organiser knowing the IP ranges in advance, and knowing who to contact at WMF - and on WMF having the time to deal with it. It would rapidly break down if we needed to use this method for every small training session. (I used to do two or three workshops a week...)
Andrew.
On 19 June 2015 at 19:16, Benjamin Lees emufarmers@gmail.com wrote:
Events sometimes get whitelisted for account creation purposes: https://noc.wikimedia.org/conf/throttle.php.txt The exceptions there there could be made to set $wgCaptchaWhitelistIP
too.
On Fri, Jun 19, 2015 at 8:54 AM, WereSpielChequers werespielchequers@gmail.com wrote:
alternatively perhaps we could whitelist certain domains as likely to
be reliable sources and unlikely to be spam.
There actually already is a whitelist ($wgCaptchaWhitelist in https://noc.wikimedia.org/conf/CommonSettings.php.txt). Unfortunately, as far as I know, there's no on-wiki way to change it, but you could always compile a list of domains and submit it through Phabricator.
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
--
- Andrew Gray andrew.gray@dunelm.org.uk
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Partially OT: re " Sadly it got marked as resolved because there was something that looked similar to developers, though not of course to potential users."
I've had a similar experience at Phabricator with respect to dump problems.
Phabricator as it is used is really for WMF pros only, even though users are often referred there to initiate bug reports.
On Fri, Jun 19, 2015 at 8:54 AM, WereSpielChequers < werespielchequers@gmail.com> wrote:
I'm tempted to point out that this mainly affects new editors who cite their edits, other new editors will get bitten in other ways. But the internet is not the best venue for irony.
More practically, if you have a tame admin on tap then you can reduce this and other problems at editathons by setting those new accounts as "confirmed". And yes I know we also have a shortage of admins, and also that it is likely that only a tiny proportion of the editors we lose through this are at editathons.
Earlier this year as a result of the glam organisers event in Paris I made a proposal at bugzilla for an event organisers useright. This would have allowed us to circumvent this problem at those editathons that are targeted at newbies, and it got widely endorsed by GLAM editors from several languages. Sadly it got marked as resolved because there was something that looked similar to developers, though not of course to potential users. If anyone here knows how to bypass phabricator or how to mark a phabricator request as unresolved and still much wanted, then the link is https://phabricator.wikimedia.org/T91928 alternatively perhaps we could persuade the education community to endorse it, it should be just as useful to them and they seem to have more clout with the WMF than the GLAM community.
As for whether the capcha is useful in keeping out spammers, remember there are two capcha steps, one when you open a new account and the other when you use that to add links. Presumably any spam program that can pass the first hurdle can pass the second. But for new good faith human editors each capcha is a possible lost edit/editor. It would be good to test dropping the capcha requirement for adding new links, alternatively perhaps we could whitelist certain domains as likely to be reliable sources and unlikely to be spam.
Regards
Jonathan
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
wikimedia-l@lists.wikimedia.org