Topic on Talk:In-context help and onboarding

I've helped lots of newbies at editathons and elsewhere, and I agree that getting rid of unnecessary barriers is a worthwhile tactic. One of the barriers that weighs heaviest on our best new editors is the capcha process when you add links. It should be fairly easy to amend that process to whitelist certain websites that are known as reliable sources. We can mitigate this at editathons if we have an admin on hand, but our admins are getting fewer. We need to reduce our dependence on them

Thanks for your tip @WereSpielChequers. You cite the " the capcha process when you add links." I want to be positive I know just what you're referring to. Can you say more about when this happens and what happens? Thanks again!

For IP-editors and new-accounts (i.e. non-"autoconfirmed"), if their edit adds an external link, then they're required to solve a captcha before they can save the edit. Screenshot example where I've tried to add http://www.example.org to the page and save it.

(Captchas are also required when creating a new account.)

Admins are involved, because they can add the user-group "confirmed" to an existing account, which gives them the user-right "skipcaptcha".

We use extension:ConfirmEdit, and the "FancyCaptcha" module within that extension, on Wikimedia wikis. There is already site-whitelist functionality in that extension, described at Extension:ConfirmEdit#URL_and_IP_whitelists but the list on Enwiki is very short: https://en.wikipedia.org/wiki/MediaWiki:Captcha-addurl-whitelist. I don't know if there are already more complete lists of "known as reliable sources" sites that we could/should add there?

The list has just been GREATLY expanded and a process put in place to review new additions as proposed.

Thanks Quiddity, that about describes it. I've helped out at outreach events and appointed newbies as confirmed to reduce this problem, and I've made some suggestions on EN wiki. There are other problems such as the maximum number of edits per minute, but most people doing outreach know not to structure events along the lines of "all hit save now".

So I see a few different issues here. Among them:

• #1 The capchas are confusing to non-English speakers. This is captured in T7309

• #2 The capcha that comes up (under certain conditions?) when edits include a link—as documented in Screenshot example—includes messaging that is very confusing, IMHO.

• #3 Related to that, it seems likely that not enough sources have been added to the whitelist that would, I gather, preclude the capcha from appearing.

My initial reaction is that I'm not sure any of these are in-scope for In-Context Help and Onboarding, which is about providing better information to new users. Another layer of popup information on top of this Screenshot example would not, in my opinion, be welcome or helpful to a new user. So what can be done?

There is a ticket for #1. The issue there seems to be that, in the ticket's 10-year history, no one has made it their responsibility to address it. Do we know who this should belong to by rights? Is it something the communities involved can fix themselves?

Then, I'm wondering, are there tickets for #2 and #3? Could we write some? I still don't understand what the conditions are that cause #2 to happen. It doesn't, for example, come up every time a user adds a reference. When does it come up? What is the actual purpose of the function?

And re. #3, aren't there whitelists of reliable sources? E.g., this Spam Whitelist. Why not add the sources here or on other approved lists to the capcha list?

If there's bad information being presented then I'd have hoped it was in scope to replace that with better information. Remember much of our problem is distraction and unnecessary complication, so adding extra information is rarely going to be helpful. We need some of the existing information to be replaced with better information, or more accurately targeted information. Also the big problems with capchas are that they break people's flow of thought and distract them.

For #1, the extension/task belongs to the Editing team (or interested volunteer devs). The non-developer communities cannot do anything to help, at this moment.

For #2, I agree the messaging is confusing. That's the drawback of documentation-by-committee/random-participants! For the default string, anyone can write a task to change the wording in the i18n file. However, for English Wikipedia, they've overridden the string at w:en:MediaWiki:Fancycaptcha-addurl and it would either need to be updated there, or deleted locally in order to use the extension's default.

For #2, I believe it does (or should) ask for a captcha when adding references with external links. You can test with a new account at w:en:Wikipedia:Sandbox. (I managed 1 edit without a captcha, but I suspect that was simply a bug? All my other tests resulted in captcha-requests.)

For #2 and #3, the confirmedit extension was primarily/originally created to prevent bots from spamming wikis.

For #3, the spam-whitelist is only meant to be used for specific pages within a blacklisted site, and is not a list of reliable sites.

For #3, I see that WereSpielChequers has already proposed some additions at Enwiki's captcha-whitelist. However there are many thousands of potentially reliable sites (none of which are guaranteed reliable on every page, nor on every topic, and all on a spectrum with subjective fuzzy-lines) so making a complete list would be a massive endeavour. I don't think there are additional whitelists of reliable sources, beyond the small handful of lists in w:en:Category:WikiProject_lists_of_online_reliable_sources some of which are mis-categorized there.

Hope that helps!