| • ppelberg | |
| Nov 28 2023, 2:13 AM |
| F41665543: image.png | |
| Jan 11 2024, 11:58 AM |
In T347531, we designed and defined the initial reference reliability user experience. This task involves the work of implementing it.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Query editcheckreferenceurl and show error message | mediawiki/extensions/Citoid | master | +80 -12 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T265163 Create a system to encode best practices into editing experiences | |||
| Open | None | T276857 [Check] Offer volunteers feedback about the reliability of the source they are attempting to add | |||
| Open | None | T351779 [MILESTONE] Offer Reference Reliability Check at partner wikis | |||
| Resolved | Ryasmeen | T352134 Build reference reliability check MVP (mobile + desktop) | |||
| Resolved | Esanders | T354846 Citoid: Improve copy in 'auto' panel | |||
| Resolved | Esanders | T354847 Citoid: Move 'insert' button to inspector header when only one result is presented | |||
| Open | None | T354848 Citoid: Improve onboarding UI |
Change 990146 had a related patch set uploaded (by Esanders; author: Esanders):
[mediawiki/extensions/Citoid@master] [WIP] Query editcheckreferenceurl and show error message
"This source is considered unreliable" feels a little off for the blocklist -- it's generally more for abusive sites, rather than just "unreliable sources". (A later iteration of this that actually includes the gradations of reliability would let that be accurate... but then we wouldn't actually be blocking you from adding an unreliable source.)
I agree @DLynch, and +1 to the later iteration. What would you recommend for the copy?
frwiki use MediaWiki:Spam-blacklist and MediaWiki:BlockedExternalDomains.json for general purposes: spams, block URL shorteners to prevent bypassing, sites used only by banned contributors, promotional sources. And when bypassing is carried out by experienced MediaWiki users, a private AbuseFilter is used. So, "unreliable" seems fine, but "source" doesn't seem totally representative. Maybe just "this website", "this link", "this domain name"?
Maybe just "This URL has been blocked by our community, and therefore is not allowed. Please choose a different source."?
(Then later, once we've integrated more data, we'll have things like "this source is considered unreliable by our community; it can be added, but can only be used to reference itself, not to support any claims", "this source is considered of mixed reliability by our community; it can be added, but might be subject to scrutiny on review", etc etc etc.)
And when bypassing is carried out by experienced MediaWiki users, a private AbuseFilter is used.
I wasn't actually thinking of this case, I'll admit. Do you think that such a bypass is sufficiently niche that people doing it won't mind being pushed to source-mode to make those edits? As-is, I'm pretty sure Visual Editor will wind up refusing to allow the citation to be made because AbuseFilter is a whole separate stage of the process.
"URL adress", maybe? Also, I don't understand you later-examples... MediaWiki:BlockedExternalDomains.json is a list of blocked domains, no? They can't be added?
Source-mode or visual-mode, the edit will be still blocked by the filter anyway. They won't get a sympathetic warning for the moment BEFORE trying to publish, but they'll be just fine until AbuserFilter is supported by the visual mode.
Also, I think it's fair to say that filter editors tend to avoid creating private filters. They do exist, but this runs counter to the total transparency of community processes. It's really a last resort.
Also, I don't understand you later-examples... MediaWiki:BlockedExternalDomains.json is a list of blocked domains, no? They can't be added?
Sorry, there's some context needed to understand what I was talking about which isn't really present in this task -- our future goal for this feature is to let communities incorporate data from things like the perennial sources list on enwiki, at which point we'll have various categories of URL that range from outright-blocked to known-good. This initial version is using the only machine-readable data source that we have currently, i.e. the blocklists, but we want to make sure we're planning ahead so we won't need to rework it.
Alright, it seems a cool feature, but also a pretty big one. I took the time to read about EditCheck and wrote a bit on frwiki.
For context, French journalists behind Le Monde newspaper created the Les Décodeurs project several years ago. Then one day they released a browser extension (deleted now)/website called Le Décodex. In a nutshell, the journalists had sorted through the websites they came across as part of their job of debunking erroneous news, viral lies or simple misinformations. There were several levels: reliable, unreliable, to be taken with caution, and so on. https://www.lemonde.fr/verification/ ; https://www.lemonde.fr/les-decodeurs/article/2017/02/01/decodex-des-extensions-pour-verifier-l-info-directement-dans-votre-navigateur-internet_5072850_4355770.html
One day, the community wondered whether they should import their lists so that AbuseFilter would automatically block sources considered unreliable by journalists. External quality analysis of sources by a single entity and automatic blocking didn't please the whole community. The idea was abandoned.
All this to say that the subject is very interesting, but we'll have to take things slowly and test the waters. Your tool adds granularity, whereas for the moment, you could only block or not block without informing the contributor.
Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/97c4358d77/w
Change 990146 merged by jenkins-bot:
[mediawiki/extensions/Citoid@master] Query editcheckreferenceurl and show error message
Test wiki on Patch demo by ESanders (WMF) using patch(es) linked to this task was deleted: