Wikipedia:Village pump (miscellaneous)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The miscellaneous section of the village pump is used to post messages that do not fit into any other category. Please post on the policy, technical, or proposals sections when appropriate, or at the help desk for assistance. For general knowledge questions, please use the reference desk.

Discussions are automatically archived after remaining inactive for a week.

« Archives, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78

Seeking recent editor stratification research

Does anybody know of recent work that updates the findings of m:Research:Editor classes or strategy:Editor Trends Study? I have poked around a bit but haven't found anything that works on the same issues; stats.wikimedia.org doesn't quite get into those issues AFAICT. Doesn't need to be formal research; I'd be interested in anything that people have found from just tooling around on toolserver or diving in the dumps. -- Visviva (talk) 18:06, 20 July 2022 (UTC)

As an update, I have been doing some initial poking around in the latest stub-meta-history dump. One thing that jumps out at me is that something odd was happening in 2014: that year saw a dramatic jump in new users in the 1-9 mainspace edits band (>70k absolute, >15% YoY), but also saw sharp drops in the absolute number of edits being made by editors in the 1k-9k and 10k+ mainspace-edit bands (which were largely reversed in subsequent years). I looked through the Signpost archives but didn't see anything that would indicate a titanic shift in wiki practice that year. But I wasn't very active at that time, so I don't really know what might have been happening that would have made 2014 special. Any ideas? -- Visviva (talk) 21:38, 23 July 2022 (UTC)

Interesting work. The only thing I can think of re 2014 was that it was the first full year when both the VisualEditor and the notifications feature were enabled, though I'm not sure how much effect either of these things might have had. Mobile viewing and editing were becoming more popular as indicated by this, but once again, that probably wasn't a seismic shift. Graham87 08:42, 24 July 2022 (UTC)

Ooh, thanks, good thought. Intuitively, that makes a lot of sense: barriers to editing come down so long-tail activity picks up, while "power users" get annoyed and their activity drops. (I recall having some rather cranky things to say about the VisualEditor myself, although my power user days were long behind me at that point.) And that same annoyance could explain the subsequent reversion to trend: annoyed power users make changes to policy and practice that push the balance back toward exclusion. Will be interesting to see if this holds once I've cleaned up the data a little better. -- Visviva (talk) 22:09, 24 July 2022 (UTC)

@Visviva, is that the all-wikis database? If so, then I believe you will see a quite dramatic effect at the Portuguese Wikipedia, which (if memory serves) had unusually stringent CAPTCHA rules in place until December 2013. Whatamidoing (WMF) (talk) 20:55, 25 July 2022 (UTC)

@Whatamidoing (WMF): I've never heard of a database dump for all wikis and I can't find it on the relevant page. Can you point me to such a thing if it exists? Graham87 05:34, 26 July 2022 (UTC)

I don't know how the dumps are arranged. I just saw on the page that there were 16,666,393 pages in the mainspace, which is 10 million more than our current 6,824,714 mainspace articles, and it sounded approximately plausible to me as the number of articles if you added all the Wikipedias together. Whatamidoing (WMF) (talk) 18:09, 26 July 2022 (UTC)

It's just the EN database. I believe 16.7M is accurate as the approximate total number of pages in mainspace (i.e. including redirects and other very short pages that NUMBEROFARTICLES excludes.) I found a version of that number ... uh, somewhere ... that jibed with my result, which was a nice feeling at the time -- although now I can't seem to find it. -- Visviva (talk) 22:00, 26 July 2022 (UTC)

It's at Wikipedia:Database reports/Page count by namespace. We have a grand total of about 59,000,000 articles on all Wikipedias. Graham87 12:53, 27 July 2022 (UTC)

• In case any of my fellow randos wander across this conversation, I'll note for posterity that after removing bots, there is still something of an anomaly, but it can be further qualified by two things: (1) the increase in long-tail registered user edits was only a small fraction of the decrease in IP edits during the same year, so it may just reflect an interface change that nudged people away from anonymous editing; (2) with bots removed, it is clearer that the drop in power user activity in the four-digit band was a continuation of a long-term downward trend from 2007 to 2014 (subsequently partially reversed), while the five-digit band didn't really move much (this was obscured by the 2013 surge in bot activity in relation to the transition of interwiki links to Wikidata, which made 2014 look like a sharp drop). There were clearly some significant shifts happening around 2014, but exactly what they were remains unclear to me. -- Visviva (talk) 18:23, 3 August 2022 (UTC)

  The 2007 trend was probably due (at least in part) to a declining need for anti-vandal patrolling. In 2005, obvious vandalism was reverted manually. By 2007, the bots would revert it before you could even get the diff open.

  As for things leveling off around 2014 trend, I think you'd want to investigate the rise of the visual editor, and the introduction of Wikidata (which should decrease local edits).

  The research that I've long wished for is about the difference between "edits" and "writing articles". I can make copyedits like this one in my sleep. But this content-heavy edit likely benefits the world more. Whatamidoing (WMF) (talk) 00:31, 11 August 2022 (UTC)

News about Wikipedia in Lokmat

There is a change of cabinets in the state of Maharashtra, India. Today in Lokmat there is a negative media regarding vandalism of MLA's article on Wikipedia. (Read news here). Requesting Admins to take note and take appropriate actions if necessary. Thanks and regards --✝iѵɛɳ२२४०^{†ลℓк †๏ мэ} 04:11, 11 August 2022 (UTC)

The article is in Marathi and Google Translate doesn't work on it, but I dug a bit and think I found the issue. A rogue editor (Sahil193319) changed the party affiliation of several politicians; the articles in question can be seen in their contribs. I think they're all fixed, but if any were missed, please link them, as again that article is in Marathi and Google Translate isn't working on it. Curbon7 (talk) 06:37, 11 August 2022 (UTC)

Discord ban

I got banned from the Wikipedia Discord with no reason, my username is h moment#9731 UnnamedWasTaken (talk) 18:07, 11 August 2022 (UTC)

That's run by different people. See Wikipedia:Discord#How is Wikimedia Community Discord related to Wikipedia?. If you're asking to be unbanned, you need to address that to the people who run the Discord server. -- RoySmith (talk) 18:15, 11 August 2022 (UTC)

But there is no dicussion board there, if you have no answer, don't give an reply. UnnamedWasTaken (talk) 18:33, 11 August 2022 (UTC)

User was banned for trolling immediately after joining Discord. Nothing further to add. Ponyo has blocked on-wiki. -- ferret (talk) 22:40, 11 August 2022 (UTC)

New Upload Tool - Sunflower

Hey folks, I recently created a new upload tool for Commons called Sunflower. If you have a Mac, I'd greatly appreciate it if you could try it out and share your feedback. Thanks! -FASTILY 08:27, 12 August 2022 (UTC)

@Fastily, have you talked to the GLAM folks about this? Batch upload tools are usually interesting to them. Whatamidoing (WMF) (talk) 18:54, 15 August 2022 (UTC)

And have you listed it at m:Toolhub? Whatamidoing (WMF) (talk) 18:55, 15 August 2022 (UTC)

Thanks for the suggestions! I've listed the tool on Toolhub. Do you have any recommendations on how to go about talking to GLAM folks? Is it the mailing list? Thanks, FASTILY 04:05, 16 August 2022 (UTC)

Input needed

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Please comment in the RfC about the first sentence in Jimmy Savile sexual abuse scandal. Cheers! Thinker78 (talk) 23:54, 14 August 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Look at your list of created articles with the Xtools Page API

I've created a new tool which gives insights about your list of created articles using xtools page prise API : https://observablehq.com/@pac02/look-at-your-list-of-created-articles-with-the-xtools-page-ap. It provides statistics about the actual number of words, references and sections in each article you've created.

Your feedback would be greatly appreciated.

Do you know if there is some page in Wikipedia where we could list this kind of tools? PAC2 (talk) 05:19, 15 August 2022 (UTC)

There's Wikipedia:Tools ... Graham87 11:02, 15 August 2022 (UTC)

Thanks --PAC2 (talk) 05:56, 16 August 2022 (UTC)

Wikimedia Foundation English fundraising campaign - further pre-test updates

Hi everyone,

As previously mentioned here, I will continuously inform you of pre-tests on English Wikipedia as the Wikimedia Foundation prepares for the English fundraising campaign later this year. As part of the English campaign we test our infrastructure on a regular basis throughout the next few months and you might see banners every now and then on Wikipedia if you are not logged in.

The next scheduled dates are:

• The 17th of August - a 100% traffic three hour test
• The 22nd to the 29th of August - a low level week long test (During the test, a banner will only be shown to users 5% of the time until the maximum of 10 impressions (1 big and 9 small banners) is reached.)
• The 1st of September - a 100% traffic three hour test
• The 8th of September - a 100% traffic three hour test
• The 16th to the 18th of September - a 10% traffic weekend test — Preceding unsigned comment added by JBrungs (WMF) (talk • contribs) 06:38, 16 August 2022 (UTC)
• The 22nd of September - a 100% traffic three hour test

Generally, before and during the campaign, you can contact us:

• On the talk page of the fundraising team
• If you need to report a bug or technical issue, please create a phabricator ticket
• If you see a donor on a talk page, VRT or social media having difficulties in donating, please refer them to donatewikimedia.org

Please let me know if you have any questions.

Thanks you and regards, JBrungs (WMF) (talk) 07:35, 15 August 2022 (UTC)

Thanks. Please note there is also a community review of the Wikimedia Foundation's English fundraising emails ongoing at Wikipedia:Village_pump_(proposals)#Review_of_English_Wikimedia_fundraising_emails. This has the complete wording of the sample emails provided by the WMF to date. These emails go out to millions of existing donors, widely shaping perceptions of Wikipedia and our financial situation. Please have a look and comment. (The email campaign will kick off soon; it is scheduled to run from 6th of September to 20th of November.) Best, --Andreas JN466 10:05, 15 August 2022 (UTC)

Mass addition of Cleanup bare URLs template

The task of encyclopaedia cultivation generates vast amounts of paperwork that, if left unaddressed by volunteers, accumulate into enormous backlogs.

{{Cleanup bare URLs}}

The community will never keep-up with this mass spamming (63,051 pages)....sometimes 2000 are added a day. .this banner has zero benefits for readers at the top of articles.....perhaps add this to the top of the "References" section for editors. Is there going to be any effort to actually fix the problem .....that in many cases is just a few sources? Moxy- 16:53, 15 August 2022 (UTC)

First off, you seem to have made no attempt to notify the person who is doing it. Second, Is there going to be any effort to actually fix the problem -> yes, she's personally fixed tens of thousands of bare URLs. Third, 63,051 pages is a massive overestimate, as {{cleanup bare URLs}} is only transcluded on 17K pages * Pppery * _{it has begun...} 17:04, 15 August 2022 (UTC)

Yup many have raised concerns....only one person has done all this? Is the bot approved?Moxy- 17:07, 15 August 2022 (UTC)

See also the cross-post at Template talk:Cleanup bare URLs#Mass spamming - you shouldn't start discussions in multiple places * Pppery * _{it has begun...} 17:07, 15 August 2022 (UTC)

No reply to last few post...moved here now......lets assume we are trying to start a good talk. Any reply to the proposal made? Again is there a plan to go back and fix the articles now tagged?Moxy- 17:08, 15 August 2022 (UTC)

Most likely yes, but does it matter? These tags will likely succeed in turning the task of fixing the longstanding backlog of bare URLs into something other than an near-Herculean effort by one editor. Why is this a problem, and why should the existence of bare URLs be swept under the rug? * Pppery * _{it has begun...} 17:27, 15 August 2022 (UTC)

We are getting banners added to the top of article all over..for just a few bare urls....these deter readers...as we know most only scroll one time. Why not add it to the ref section? Should be doing what is best for readers ...not editors. Moxy- 17:30, 15 August 2022 (UTC)

I think putting the banner in the ref section is an excellent idea. That narrowly targets it to the type of reader/editor most likely to be inclined to act on it. EEng 19:11, 15 August 2022 (UTC)

@Moxy's conduct here is very poor: they opened in two places a discussion about my edits, without making any attempt to notify me about either discussion. No ping, no mg on my talk, no email. Nada.

But despite this, Moxy complains No reply to last few post.

WTAF??? How on earth does Moxy expect a reply when then chose to not notify the editor who they know is doing most of these edits? Is this a display of cluelessness, or some sort of game?

Note that Moxy has bad history on this issue of bare URLs. Back in March, Moxy objected to me adding the inline tag {{Bare URL PDF}} to thousands of articles; but they did so by sniping in edit summaries rather than starting a discussion. So I started a discussion on Moxy's talk, but Moxy was not interested in anything I had to say. Instead, they deleted[1] the discussion with the edit summary "back to content", so our unfruitful exchange is available only in the page history: https://en.wikipedia.org/w/index.php?title=User_talk:Moxy&diff=1077213739&oldid=1077213451

So I am sadly unsurprised to find the deplorable antics displayed here: no notification, and a WP:ABF prejudicial heading which describes WP:V-related cleanup as {{spamming}}. BrownHairedGirl (talk) • (contribs) 21:52, 15 August 2022 (UTC)

Anyway you can adrdress the proposal raised here. As per your post on my page and a few others.....people have some concerns about the editor's adding these all over.... or more specifically their placement. looking for more fruitful talk than my talk page where I'm told what to do .Moxy- 22:18, 15 August 2022 (UTC)

A decent, civil editor would have taken this opportunity to apologise for the lack of notification, for the prejudicial WP:ABF heading, and for deleting a discussion.

But no, @Moxy does none of those. Quelle surprise. BrownHairedGirl (talk) • (contribs) 22:30, 15 August 2022 (UTC)

We will simply have to move forward without your input on this point. Moxy- 22:43, 15 August 2022 (UTC)

@Moxy: thank you for clarifying that your failure to notify was an intentional attempt to exclude me from a discussion about my work.

And no, you will not proceed without my input. (I see no "we"; just you with that attitude). I have added my substantive comments below, but judging by our previous discussions and your misconduct here, I expect that you will not be interested in anything I have to say. BrownHairedGirl (talk) • (contribs) 22:53, 15 August 2022 (UTC)

What do you think about moving the banner? Moxy- 23:06, 15 August 2022 (UTC)

@Moxy: I oppose moving it.

And you should already know that I oppose it, because you have already replied to the discussion following my comment opposing it. So what game are you playing by asking me? BrownHairedGirl (talk) • (contribs) 23:13, 15 August 2022 (UTC)

I raised moving this template to the "References" section on the talk page of the template. It's great that cleanup work is being done, and I don't mind tracking this. However, as I brought up on the talk page, this isn't appropriate for the top of the article. Cleanup banners are meant for readers first and foremost (as a warning), with the fact that they encourage editors a happy byproduct. This template is 100% editor-focused, and furthermore, only on a subset of editors. Readers don't care if citations are properly formatted. Readers might care if the citations are "bad", but that isn't what this template is about: it's entirely possible for a bare URL to be an accurate and sufficient reference for the content. Sticking it in References will ensure editors notice, but don't trouble readers who both don't care and can't fix the problem. (And more generally, as anyone who has gone to edit-a-thons aimed at attracting new editors can tell you, stuff like "how to format your references" is the absolute last priority when teaching someone how to Wikipedia - it's not what we expect most newbie editors to do, and "use a bare URL or text, someone else will fix it later" is fine.)

As for the comments by *Pppery* above on "why is this a problem", the problem is banner blindness. A bunch of irrelevant-to-readers banners teaches them to ignore the content warning templates more than they already do. Even worse, a reader who gets a vague sense of distrust of articles when seeing cleanup banners (but doesn't closely read / understand this one to realize it's no big deal) might conclude that the banner means the article is unreliable, when in fact an article could well be featured-article quality but have one random bare URL added 6 months ago. This is definitely bad. For example, if a citation template has an error, there'll be a warning to editors in "preview" mode, but it won't show in normal display after saving, because regular readers do not and should not care if somebody misspelled a parameter in their citation template or whatever, while editors capable of fixing the problem can be casually warned at the next opportunity.

Do we need an RFC for this, or can we just convince BHG & others to move this template to References? It seems like an obvious win-win that leaves each side happy. SnowFire (talk) 19:31, 15 August 2022 (UTC)

• Comment by BHG, in response to @EEng & @SnowFire.

EEng: I am concerned about that phrase the type of reader/editor most likely to be inclined to act on it

WP:V is a core policy of Wikipedia, and high-quality references are the core of what we do here. Bare URLs are bad for readers, because they make it hard to identify and assess the source without opening the links, and because they are prone to WP:Linkrot.

As I have worked my way through the backlog of over 470,000 articles with bare URL which we had in May 2021 (now down to ~100,000, with a much higher proportionate reduction in the total number of individual bare URLs), I have been heartbroken to find how many refs were dead and irretrievable, and now effectively useless. The URL alone often gives little or no clue as to the actual content of the web page, and many webpages are not archived the Wayback Machine and other tools. As a result, many older articles are in large part unverifiable, because the sources used are unavailable. If we were really serious about WP:V, we'd be systematically ripping out all the content which can no longer be verified, unless we can find another sources; and we be flagging up with much greater prominence the article text which is not verifiable.

This is a huge problem. We are serving up to our readers content which fails our core policies. Our readers rely on us to assert facts which they can verify, and by tolerating bare URLs we deprive them of that chance ... because most URLs eventually rot and die.

After huge progress in the last year, there are now two issues with bare URLs:

• The backlog of old bare URLs; there are about 150,000 individual bare URLs on about 100,000 articles
• The flood of new bare URL refs, added at a rate of over 300 per day. Using various tool, about 80% of those are filled within a month, but tool-filing of refs is in most cases mediocre, and that leaves about 2,000 articles every month getting new bare URLs.

This is time-critical work. The longer a URL is left unfilled, the more likely it is to have rotted and become unfillable, or to have changed its content. Some URLs, such as those based on news agency reports, are systematically removed by their publishers after a fixed time period (usually a few months, sometimes much less); some because the website retains only fresh content; others are lost because websites die or are restructured.

That's why a prominent notice is valuable: because unless a ref is filled soon, it may not be fillable.

So, yes, it would be possible to add the banner to the references section. But I think that doing so would be a very bad idea, because it would give the false impression that crap referencing is not important enough to flag up prominently. I strongly oppose @SnowFire's view that bare URLs are no big deal. WP:V is very clear: good referencing is not just a big deal; it is the absolute core of what we all do here. --BrownHairedGirl (talk) • (contribs) 21:37, 15 August 2022 (UTC)

I'd like to see some actual statistics on the kinds of URLs typically found being used as article references. I suspect a substantial proportion of them are Googlebooks, Jstor, and similar links not reasonably subject to rot. If a particular article's bare URLs are entirely of that kind, then cleaning up that article is due much lower priority, and maybe doesn't call for the banner -- perhaps such articles should just go in a category. I wouldn't be suprised if this cuts the banner-ing substantially. EEng 14:46, 16 August 2022 (UTC)

That may have been true originally, but in the specific case of JSTOR and Google Books, Citation bot has likely handled the bare URLs to those websites months ago. See the comment about the 80/20 rule below. * Pppery * _{it has begun...} 16:12, 16 August 2022 (UTC)

@EEng: @Pppery is right about progress. e.g. All new JSTOR refs are filled every day, because I use them in the daily set of ~100 searches which I use to make worklists for @Citation bot.

As to the wider sets: about a month ago, I made a list of all the then extant bare URLs, and then turned that into a spreadsheet listing the number by domain.

The results surprised me: much less clustered than I expected. The biggest set at the time was WaPo (washingtonpost.com), with just over 900 entries. I was expecting that, 'cos @Citation bot doesn't handle WaPo, so I wrote and deployed a tool to automatically fill (most) WaPO refs.

AFAICS, that lack of clustering makes analysis-by-quality of website near-impossible; it would take far too much work, and the effort would be much better placed into filling/tagging-dead/removing/replacing the bare URLs. However, if you (or anyone else) would like a copy of my data, pls just send me an email with the subject line "bare URL website distribution spreadsheet". BrownHairedGirl (talk) • (contribs) 18:50, 17 August 2022 (UTC)

I've seen these coming up on multiple watchlisted articles and have been going along behind and fixing. For me these are helpful. Valereee (talk) 21:55, 15 August 2022 (UTC)

That's great, but you'd have seen it on your watchlist if it was added to the "References" section too, right? SnowFire (talk) 21:59, 15 August 2022 (UTC)

I have also been fixing these as they come across my watchlist. Most take a minute or two of work. Often the tag signifies a permanently dead link, meaning that a new source must be found. I don't see this as materially different from a "more sources needed" tag, which would always go at the top of the page. BD2412 T 22:32, 15 August 2022 (UTC)

Thanks, @BD2412. That's how I view it too.

Straightforward dead URLs are not too hard to deal with: a HTTP 404 or 410 response can be detected by tools and tagged wit {{dead link}}. In February & March this year I added that tag to bare URLs on about 80K articles.

At this stage, a high proportion of the remaining bare URLs are various forms of "dead": soft 404s, site usurped by one of the domain-reseller parasites, or requests time out, or DNS fails. It's very difficult to reliably detect many of those with tools, so most of them need manual attention ... which is why a prominent tag is so helpful, to encourage more editors to take that minute or two. BrownHairedGirl (talk) • (contribs) 22:49, 15 August 2022 (UTC)

Re BHG: To be clear, let me state again that it's great you're doing this clean-up work. I don't think fixing citations is bad. I don't think adding this template is bad when they can't be fixed. However, there exist many problems which are important but only solvable by a very small subset of people - and further, we'd only even really want that small subset to do it. We don't post nuclear reactor safety procedures on highway billboards, because there is simply no expectation random passerby drivers will decide to drop everything and become atomic technicians. Learning the intricacies of the Wikipedia citation system is simply not something we expect most people to know - I would wager most editors (by number, not edit count) don't know it (the people who post on Village Pump are the hardest of the hardcore, we're not a good sample set here). Basically, even if we accept for a moment that this is of towering importance, merely being important doesn't have anything to do with the proper way to flag the problem, in the same way that important software bugs need to be filed against the devs who can do something about it, not to random readers. I will again my raise my example of errors in citation templates from misspelled parameters and the like. Serious question - if you were emperor of Wikipedia for a day, would you make it so that a bad citation template caused a warning seen by everyone, rather than just editors in preview mode? Because it seems like the exact same argument could be used to highlight this kind of problem. But it simply isn't important for readers, and editors can notice and fix it on their time.

On my earlier comment, let me be precise: when I say that bare URLs are no big deal, I mean that an edit that adds content with a bare URL is no big deal. Obviously, for Wikipedia-as-a-whole, it'd be good to fix it. But an individual contributor can contribute how they like or is convenient for them, and they shouldn't be shamed for it. The important thing is that it is an accurate reference as far as content - a simple URL or piece of text that's helpful is great, and a perfectly formatted citation that does not really reflect the source is a big problem. This edit added an extraordinarily vague text reference... but it was enough for me to find it, and confirm it was real, and format it all nicely (diff). The original edit that added this absolutely helped Wikipedia. It wasn't a "problem" or a big deal. That's what I'm saying. SnowFire (talk) 21:59, 15 August 2022 (UTC)

@SnowFire: Thanks for your kind words. They are v much appreciated, because this year of bare URL filling an tagging has been lonely work, with far more angry outbursts directed at me than thanks or encouragement.

But we still disagree radically, over your comment there exist many problems which are important but only solvable by a very small subset of people.

I really really really hope that you are completely wrong about that, because adding decent refs is the core task of any content editor. If that really is the preserve of a tiny minority, we should all just give up pretending that this is an encyclopedia. BrownHairedGirl (talk) • (contribs) 22:37, 15 August 2022 (UTC)

Funny, I got here searching for mentions of {{Cleanup bare URLs}} at WP:VPT (I don't usually come to WP:VPM), and didn't expect to find such a debacle about it. I'm one that takes great satisfaction in calling ref fix tools on pages that BrownHairedGirl tags for ref cleanup. I like first running BrandonXLF's fast and easy ReferenceExpander for basic expansion, then WP:REFILL, which is particularly good at eliminating duplicate refs, and finally WP:Citation bot for the finishing touches. I'm indifferent as to whether the tag should be up top or at the reference section; the important thing is that the article be included in the Category:All articles with bare URLs for citations. But the actual reason I came here is bc I think +63K pages is nowhere near enough (let alone 17K!)—I find over 657K articles with bare url refs—and wanted to go about mass tagging them all. — Guarapiranga ☎ 07:25, 16 August 2022 (UTC)

I think that BHG is right when it comes to verifiability. If we call this effort useless just because some don't like it, it brings into question other policies. I agree the average Wikipedia reader might not care for it - so maybe make it so only editors can see the banner. But the general idea of bringing it to peoples attention is abosuletly necessary. Rlink2 (talk) 23:06, 16 August 2022 (UTC)

Analysis of new articles

I looked at the last 10 articles in Special:NewPagesFeed (an easy way to get a random sampling of articles by random editors):

1. Krapopolis has properly formatted refs
2. Shelley, Victoria has no refs at all
3. Draft:Killing of Christian Obumseli has non-bare, but incompletely filled, refs
4. Karambalangan has properly formatted refs
5. 2022–23 Xavier Musketeers men's basketball team has non-bare, but incompletely filled, refs
6. Alternative Mitte has properly formatted refs, although it also has a bunch of "Cite error: reference named X was invoked but never defined".
7. Club Leoncio Prado has a non-bare, but incompletely filled, ref.
8. Mamma, 'k wil 'n man hê has no refs at all
9. List of countries by net reproduction rate has properly formatted refs.
10. Justin Garza High School has properly formatted refs.

So, overall, 5 articles with properly formatted refs, two with none at all, and three with incompletely filled refs (and no bare URLs, although I certainly have seen bare URLs at New Page Patrol elsewhere). Each of these was created by a different editor. I'd say that refutes SnowFire's claim.

While I was composing this comment, Anne-Sophie Lavoine was created with bare URLs. But it's still the case that from that sample that most editors can fill refs properly. * Pppery * _{it has begun...} 22:50, 15 August 2022 (UTC)

Re * Pppery * and "this refutes SnowFire's claim": first off, let's not get distracted on a side matter. The exact proportion isn't really that important and it doesn't solve the other issues I brought up, most pertinently that of the reader experience (e.g. articles with no active editors whatsoever, but that has readers who are warned that 1 of the 20 references is a bare URL). But if we're going to discuss it - no, it doesn't refute it. You're saying that 3/8 of the articles with references don't have properly formatted citations. That is a huge amount. Even if a larger sample size shows it's less, say 20%, that is still a gigantic amount! Remember, we are hypothetically talking about informing editors who A) view a page, but B) don't have this page already watchlisted. Many of these will be people who edit very rarely and don't show up in new page patrol anyway, because IP editors can't create new articles directly. So we're talking about the least active of active editors (in the sense of people, not accounts). Surely, surely you've run into such editors who clearly aren't that familiar with Wikipedia and stop by for the occasional edit. These editors are unlikely to fix a bare URLs cleanup request, whether they're 20% or 50% or some other amount of the total editor base. The editors who will fix it are hardcore editors who have the article on their watchlist, and they'll see the notification regardless of where it's placed, on top, in references, even if it was placed on the talk page. SnowFire (talk) 00:20, 16 August 2022 (UTC)

@SnowFire, I don't agree with your analysis of incidence, but let's set the numbers aside for mo.

It seems to me that you are asking for those editors who are unaware of a problem with their edits to be shielded from notices which show them that bare URLs are a problem.

And that seems to me to be the precise opposite of that we should be doing. Obviously, we should not be rude or hostile, but a polite and non-personal notice warning of a problem on a page attributes no blame and is no way the "shaming" which you referred to above. BrownHairedGirl (talk) • (contribs) 00:29, 16 August 2022 (UTC)

You consider the addition of bare URLs a problem, BrownHairedGirl. I consider their addition a valuable contribution. The encyclopedia has survived very long without so severely increasing the visibility of bare URLs. Nothing in your work requires a topside banner. All in all, I think your chosen approach is overly confrontative. CapnZapp (talk) 17:47, 16 August 2022 (UTC)

Conduct allegations

So to the point at hand about this good work. Should we move the non reader warning out of the lead and to the ref section. Not one person here has claim this work is a problem.....but accessibility and reader retention is the concerned raised about Banner placement. Wonderful to see the work being done.....just the approach could have some amendment to it .Moxy- 22:55, 15 August 2022 (UTC)

Sigh. That is a bare-faced lie by @Moxy, in their assertion that not one person here has claim this work is a problem.

On the contrary, Moxy opened[2] this discussion with a headline complaint that it is Mass spamming, and used that same phrase in the first para.

And in their discussion on their talk, Moxy called tagging mass bare URLs simply crazy.

I don't see why we should tolerate having any discussion polluted by an editor who brazenly lies about their conduct.

If Moxy has changed their mind and recognised the value of this work, then they should says so. BrownHairedGirl (talk) • (contribs) 23:10, 15 August 2022 (UTC)

It is crazy to add thousands of these to the top of articles like a bot. Working of fixing refs is great....but banner spam is a problem....as outlined by a few here. Moxy- 23:16, 15 August 2022 (UTC)

Yet again, @Moxy's reply is simply to insult my work as crazy, instead of explaining in civil terms why they think that it is a problem.

And of course, Moxy makes no effort to retract their lies. Instead they try to limit their use of the word crazy to the top of articles. But in March, on their talk, Moxy used the phrase simply crazy to describe my addition of the inline tag {{Bare URL PDF}}.

Other editors are discussing this with reasoned civility, and without denying their own stance. Please, Moxy, either stop lying and stop insulting ... or leave this discussion. BrownHairedGirl (talk) • (contribs) 23:27, 15 August 2022 (UTC)

Never said anything personal about you here. More then willing to leave the talk to others as its clear you can't communicate normally with me.... it's a long standing problem with me and others. Good luck..... hoping that we favor reader retention and accessibility as the outcome over this. Moxy- 23:37, 15 August 2022 (UTC)

@Moxy: you have lied repeatedly, and now you lie again, by denying that calling an editor's work crazy is a personal attack.

If you regard that sort of conduct as normal, then god help us. BrownHairedGirl (talk) • (contribs) 00:04, 16 August 2022 (UTC)

Jesus have you seen the above. 204.237.48.146 (talk) 01:40, 17 August 2022 (UTC)

Bot request process

One thing that's clear is if this is being added in a bot-like manner, this is covered by WP:MEATBOT. If the mass addition of bare URL banners are considered desirable, the community should consider having an actual bot handle things and have all the benefits this entails. Headbomb {t · c · p · b} 23:41, 15 August 2022 (UTC)

@Headbomb: a bot might be desirable in theory, but it is unlikely in practice, since WP:BRFA is so massively dysfunctional.

My last BRFA was for a bot to remove {{Cleanup Bare URLs}} banner when it was no longer needed. That BRFA derailed by your extreme aggression, abuses of process and repeated counter-factual assertions. It was a hideous, horrible experience, and after that I decided not to open a BRFA again. Instead, I took the code that I had written, modified it slightly, and have been running it repeatedly for 8 months without a single objection from anyone.

If BRFA can be reformed to be more responsive (it's horribly laggy) and to exclude your appalling conduct, then I will consider a BRFA for this task. But I have had two very unpleasant experiences in which BAG members have just piled on to endorse your aggressive misjudgements. BrownHairedGirl (talk) • (contribs) 00:01, 16 August 2022 (UTC)

Funny how everyone is wrong and that you get no single issues except multiple comments on your talk page and elsewhere asking you to stop, and the community asking for alternatives to what you're doing. There was no abuse of process, you just decided not to comply with the requirement for bots because you didn't agree with them. You had your review, which concluded with

The discussion seems to be going round in circles a bit. To summarise: 5 BAG members have now reviewed the situation, along with other community members, and those opining on the issue overall seem to support the declining BAG member's rationale. Feedback has been provided on how a future bot request could be modified to address the concerns and gain approval. BHG's 14:56, 23 December 2021 comment indicates to me she understands what these steps are, even if she doesn't agree with them. Alternatively, an editor can put the question to the community via RFC. If the community decides the bot task is acceptable as-is, without any modifications, then the bot request can be looked at again. ProcrastinatingReader (talk) 20:47, 23 December 2021 (UTC)

If you don't want to code such a bot for whatever reason, then you can always make a WP:BOTREQ and let someone else handle it.

Headbomb {t · c · p · b} 00:08, 16 August 2022 (UTC)

On the contrary, @Headbomb, the problem was simply that you read the bot's purpose literally, and missed the key point that the purpose of the bot was to remove the {{Cleanup Bare URLs}} banner from pages where it was no longer needed.

You throw a massive wobbly over the code ignoring refs which have already been tagged as inappropriate, as if there was some purpose in retaining a big banner asking editors to fill refs where the required action is to remove or replace them. And the rest of BAG weighed in behind you, which looks like a very unfortunate episode of groupthink.

And yes, there was abuse of process. After I had asked for input from other BAG members, you kept on piling on, and you made counterfactual assertions which you failed to retract, and then you closed the BRFA before other BAG members could offer input. That, my friend, is multiple abuses of process.

And the aftermath is that in the last 8 months I have made well over 10,000 edits using a slightly-modified version of that code, with lots and lots of thanks notifications from editors, and not a singe complaint. So no, I will not take that back for another hazing at BRFA.

If you want to open an RFC, then feel free to do so. But I think that 8 months of objection-free removal of redundant {{Cleanup Bare URLs}} banners is good evidence that the community does not endorse your view. BrownHairedGirl (talk) • (contribs) 00:22, 16 August 2022 (UTC)

"that the purpose of the bot was to remove the {{Cleanup Bare URLs}} banner from pages where it was no longer needed"

Indeed. And your bot would have removed the tag from pages where it was still needed (i.e. pages with bare urls remaining), and therefore was declined because it failed to behave in line with its purpose. You may disagree with it, but you haven't shown that the behaviour you're seeking (the removal of cleanup tags from pages with bare URLs tagged with other cleanup issues) has consensus, and so the bot remained unapproved.

As mentioned several times, you could at any time have made an RFC demonstrating consensus for your bot's proposed behaviour, or modify the bot to behave as one would expect. You haven't, so here we are. Headbomb {t · c · p · b} 00:30, 16 August 2022 (UTC)

And where we are is that after 8 months of use and over 10,000 edits there has bot been a single objection to my AWB job.

Nobody at all, not even one person, has commented to me that we should retain at the top of an article a big banner about filling bare URLs which should actually be replaced or removed. Nobody. Nada. Zilch.

And even after 8 months, it seems that you still do not comprehend that simple issue. Which is one of the reasons why I am bot going back to BAG to face more such absurdities. BrownHairedGirl (talk) • (contribs) 00:38, 16 August 2022 (UTC)

PS just to clarify: I don't want to code such a bot for the simple reason that it would be superfluous to the AWB job which I have been running for 8 months since my BOTREQ was hazed out, with zero objections.

And I also do not want to make a BOTREQ, because I see no purpose in your vision of a hobbled bot doing a subset of tasks which are already in hand. BrownHairedGirl (talk) • (contribs) 00:33, 16 August 2022 (UTC)

PS @Headbomb: if you still cling to your view, then please you go open that RFC you talk of.

The RFC question is simple: "Should we retain at the top of an article a big banner about filling bare URL refs which have already been tagged as unsuitable, and which should therefore be replaced or removed".

Lemme know how you get on. BrownHairedGirl (talk) • (contribs) 00:45, 16 August 2022 (UTC)

Fine, you want an RFC, I'll give you an RFC. Headbomb {t · c · p · b} 00:59, 16 August 2022 (UTC)

But not on the topic where I challenged you. The TFC below looks time very much like you playing games out of revenge, because you lack the confidence to ask for community input input on the stance which I did suggest you hold an RFC.

Instead, you open another RFC with a loaded question in which you don't even acknowledge the reason why I have not opened an RFC for adding the banner tags. Very poor conduct, Headbomb, BrownHairedGirl (talk) • (contribs) 01:07, 16 August 2022 (UTC)

I agree an RfC on "Where should the Cleanup bare URLs template be placed? 1. At the top of the page (current practice) 2. At the top of the references" would be better than the offerings below. If people want we can have a "3. Template should be depreciated" but I don't see anyone advocating for that in this discussion. Best, Barkeep49 (talk) 01:10, 16 August 2022 (UTC)

@Barkeep49: such an RFC might have some merit, but it's going to cause overload if this page also contains Headbomb's two disruptive revenge-RFCs. BrownHairedGirl (talk) • (contribs) 01:26, 16 August 2022 (UTC)

There is a reason I suggested it instead of the two RfCs below. It's a question in one of the RfCs but I'm not sure how much actionable feedback we'll get for a close. Best, Barkeep49 (talk) 02:01, 16 August 2022 (UTC)

Alternate technical solution possibilities? Requesting input

Alternate technical solution possibilities? Requesting input @ Wikipedia:Village pump (technical)#Color differentiation in reference numbering

Thanks

Bookku, 'Encyclopedias = expanding information & knowledge' (talk) 04:18, 16 August 2022 (UTC)

@Bookku: this an accessibility issue. See MOS:COLOR: "Ensure that color is not the only method used to communicate important information".

So the use of color in problematic refs may be an a helpful addition (if technically possible; I can see some difficulties), but it cannot replace textual notifications. BrownHairedGirl (talk) • (contribs) 04:57, 16 August 2022 (UTC)

RFC: Should the mass ADDITION of Cleanup bare URLs be done by bots or meatbots?

There are two questions.

1. Should the mass ADDITION of {{Cleanup bare URLs}} be done by bots or meatbots?
2. At what location in articles should these be added? At the top of the page, or in the reference section?

Headbomb {t · c · p · b} 01:01, 16 August 2022 (UTC)

Discussion (mass addition of Cleanup bare URLs)

1. It would be highly preferable to do this by bot IMO. Additionally, these should be at the top of the page since you can have bare URLS in many place other than reference sections. These bare URLs could be in a further reading section, external links section, in the main text, or anywhere else. Headbomb {t · c · p · b} 01:14, 16 August 2022 (UTC)

• Speedy close this blatantly bad faith RFC. This is a deliberately disruptive exercise, opened as revenge for the fact that I explained above to Headbomb how his objection to removal had no support, and how his aggressively process-abusing closure of WP:BHGbot 9 had not prevented me from removing redundant banners from over ten thousand articles over the last 8 months, without a single objection from anyone. --BrownHairedGirl (talk) • (contribs) 01:24, 16 August 2022 (UTC)

  I rather tire of these WP:ABF accusations. You wanted an RFC, I gave you one. There is no 'revenge'. The wording is neutral, and covers all relevant issues. Headbomb {t · c · p · b} 01:26, 16 August 2022 (UTC)

  @Headbomb: your bad faith is as plain as a very plain thing.

  This is just an exercise in wasting my time, motivated by revenge. BrownHairedGirl (talk) • (contribs) 01:29, 16 August 2022 (UTC)

  Listen to yourself for a second. Revenge? For what? For doing cleanup work? For wanting clear guidance on an issue where there is disagreement? For wanting a productive path forward? Again, read what you wrote in light of WP:AGF. Headbomb {t · c · p · b} 01:32, 16 August 2022 (UTC)

  No, you listen to yourself.

  This is transparent revenge for the fact I explained to you how your tantrums and process abuse at BRFA did not prevent me from doing valuable and uncontroversial cleanup work by ignoring your absurdist demands. BrownHairedGirl (talk) • (contribs) 01:38, 16 August 2022 (UTC)

• Note that I suggested to Headbomb that they open an RFC on the substantive issue in his dispute with me: "Should we retain at the top of an article a big banner about filling bare URL refs which have already been tagged as unsuitable, and which should therefore be replaced or removed".
  Sadly, Headbomb has chosen not to ask this question, and also makes no attempt to explain tye reasominh for his demand that editors should be faced with a big banner asking them to fill a bare URL ref which actually be removed or replaced.
  This reminds me of the Kerryman joke about the Kerryman who wrote a book which was so bad that the publisher rewrote it before binning it. Except that in this case, Headbomb is not joking: he genuinely wants editors to waste their time filling refs to unreliable sources ... which will then be removed.
  Why on earth would anyone demand that? ---BrownHairedGirl (talk) • (contribs) 01:50, 16 August 2022 (UTC)
• Already had a bot at Template:Cleanup_bare_URLs/bot which had BRFA approval. It was made for this reason: there are so many pages with bare URLs, adding banners automatically is too disruptive. So we came up with this tagbot solution. It worked well. However once the banners started being added at a mass rate, it broke the model. Tagbot will only run if there are less than 5 or so existing banners, they need to be fixed before new ones are added. That was the idea. Fix em before you add em. But with 60k+ unresolved banners, the tagbot model is rendered useless. -- GreenC 02:07, 16 August 2022 (UTC)

  ... and the tagbot model didn't work. Template:Cleanup_bare_URLs/bot has 407 revisions, half of which are the bot setting the page to STOP and the other half of which are a human requesting a run. That means around 200 * 5 = 1000 pages with bare URLs have been tagged by GreenC bot. For comparison, BrownHairedGirl has filled thousands of pages with bare URLs in a matter of days or weeks. * Pppery * _{it has begun...} 02:23, 16 August 2022 (UTC)

  Probably because you can't run it if there are > 5 in the tracking cat so once things got too large no one could use it. -- GreenC 03:09, 16 August 2022 (UTC)

  Not true. Tagbot ran from May 2019 to May 2021, which is about 2 years. It's been less than 2 years since tagbot last ran, so if BrownHairedGirl had not done bare URLs one can extrapolate and say tagbot would have run on at most another 1000 pages. That would not change my conclusion meaningfully. * Pppery * _{it has begun...} 03:15, 16 August 2022 (UTC)

  @GreenC, you are missing @Pppery's point. In all the months that Tagbot ran, before it was displaced by wider tagging, it identified only 1,000 bare URLs in need of filling.

  As Pppery has noted, I fill more than that on many individual days, and much more than that every week. And the wider tagging allows many more editors to see that an article's URLs need filling.

  As I wrote below, tagbot was an honourable effort done in good faith, but the whole concept of only ever tagging a tiny subset of the problem was misguided. BrownHairedGirl (talk) • (contribs) 03:17, 16 August 2022 (UTC)

  Ok ok followed up below. (Tagbot was only as useful as people willing to use it, which was largely one person occasionally.) -- GreenC 03:35, 16 August 2022 (UTC)

  Yes @GreenC, that's it. And if I had listened to that one person's sniping at me, the last year's progress on bare URLs would never have happened.

  Thankfully, because this place is not a bureaucracy, I was able to find other ways to get most of the job done. That's why I am annoyed by Headbomb's vengeful attempts here to tie me up in bureaucracy about issues which he doesn't understand, and which I have learnt over the last year are rarely understood by editors who have not actually worked on these issues at scale. BrownHairedGirl (talk) • (contribs) 03:54, 16 August 2022 (UTC)

  @GreenC: there are not 60,000 banners. After my latest addition of a batch of 14,700 banners in thye last few days, there are about 18,000 banners. The other articles in Category:All articles with bare URLs for citations are there because of inline tags, e.g, {{Bare URL inline}} and {{Bare URL PDF}}

  Tagbot was made for a very different purpose, in a very different context.

  When Tagbot last ran, there were about 470,000 articles with bare URLs. Now, after a year of intensive cleanup by me, there are about ~100K. Many of the remaining articles with bare URLs have had one more URLs either filled or tagged as dead, so the actual progress is much greater than the article count implies.

  Tagbot was an honourable idea, but it was fundamentally flawed. It was designed to serve the needs of a small group of editors who worked slowly to fill a few bare URLs per day, and basically it just used tags to give that wee group a job list. Their work was of course valuable, but it was on far too small a scale to even keep up with the flood of new bare URLs, let alone dent the backlog. The problem was steadily getting worse. Evert day, new bare URLs were being added about ten times faster than others were filled.

  That is why I set about a different approach. After some trial and error, the method I developed was fourfold:

  1. Feed endless streams of huge lists to Citation bot to fill as many refs as possible
  2. apply inline tags where they would not impede other tool: i.e. non-HTML pages, and those which cannot be filled by WP:ReFill (see User:BrownHairedGirl/No-reflinks_websites)
  3. Develop other tools to identify dead links, and tag them with {{dead link}}.
  4. Identify sets of URLs which I could easily fill manually, and work on them.

  After a year of this. my approach has been a proven success. We now have ~90% fewer bare URLs than a year ago, and the widespread inline tagging of bare URLs helps any editors to identify bare URLs in articles within their interest. The small group of pioneers can still do their work, but now far more editors can find articles with bare URLs.

  Until the start of August 2022, I refrained fro systematically adding the {{Cleanup bare URLs}} banner, because some editors find it too intrusive. However, by this month the reduced bare URL count a massive increase in the capacity of Citation bot allowed me to do multiple passes of lists each month. Until May, I could not in any one month get Citation bot to process the full list of articles with HTML-format bare URLs, but after the upgrade I made a lot more progress and was able to process not just the whole set, but to do multiple passes on big lists.

  In July, I took my list of new bare URLs and processed the set 10 times (see User:BrownHairedGirl/Articles with new bare URL refs), until Citation bot could do no more. After some thought, I reckoned that we are now into the mopping-up phase of bare URLs, where manual input is needed: so I then applied the {{Cleanup Bare URLs}} banner to the articles in that set which still had one or more untagged bare URL refs (there were about 1150 articles remaining from July's two database dumps). I did not use the {{Bare URL inline}} tag, because that would prevent the use of WP:REFILL.

  Then I did the same thing with the new bare URLs from the 20220801 database dump. And when that was done, I made a list of 20,000 randomly-selected articles with bare URLs, and I got Citation bot to process that whole set 7 times.

  After those 7 passes by Citation bot (plus any other work on the set), that left 14,700 articles in the set which still had one or ore bare URLs. That's the set which I have just finished tagging.

  Please please let's not go back to the bad old days when most bare URLs were untagged and uncategorised, and where bare URL cleanup was the preserve of a small and formal group as the problem grew bigger and bigger.

  And please please, don't tie my work down in bureaucracy. WP:NOTBURO, and my approach is delivering results. Headbomb has twice abused BRFA as a hazing process against me, and I don't want my work to again be impeded by bureaucracy. BrownHairedGirl (talk) • (contribs) 03:02, 16 August 2022 (UTC)

  Sounds right, the volume of incoming bare URLs was larger than tagbot users were willing or able to keep up with. Maybe tagbot could be done a different way, would have to think about it. Your method of breaking the problem down into steps using various tools seems to be working for you. At some point you got all the low+medium hanging fruit and whatever left is a hard problem. The 80/20 Rule, I guess somewhere around 20% remaining? Generally Wikipedia follows the 80/20 Rule. The last 20% is harder than the first 80%. So we banner the 20%. I think that's important to understand this is the final step representing the hard cases. -- GreenC 03:31, 16 August 2022 (UTC)

  Thanks, @GreenC. I think we are on the same page now.

  Depending on whether we count bare URLs or articles with bare URLs, we either 95% done or 80% done. But either way, we are at the hard cases stage, where Citation bot's efforts now consist mostly of long waits for HTTP requests which timeout after a 45 second limit. (See User_talk:BrownHairedGirl#Zotero_only, where I talk to @AManWithNoPlan about his wonderful work in developing a bare-URLs-only mode which I suggested for Citation bot. That man's work is brilliant, and he deserves heaps more praise than he gets!)

  So yes, this is tagging the hard cases. BrownHairedGirl (talk) • (contribs) 03:45, 16 August 2022 (UTC)

  Headbomb has twice abused BRFA as a hazing process against me

  This is an utterly ridiculous and incorrect claim, and I would ask that you stop making it. There was unanimous agreement in the review that my closure was correct. Headbomb {t · c · p · b} 08:03, 16 August 2022 (UTC)

1. Yes, absolutely. I find over +640K articles with bare url refs without the tag.
2. Top, but only to editors, not readers. There's a lot of things that shouldn't be shown to readers; redlinks for a start (but I digress).

— Guarapiranga ☎ 08:08, 16 August 2022 (UTC)

Utter nonsense, @Guarapiranga. There are not 640K articles with bare URLs, and AFAIK there never has been.

You got that nonsense number because your search is broken: it wrongly assumes that bare URLs (and only bare URLs) are wrapped in square brackets, e.g. [http://example.com/foo].

Neither assumption is true: almost zero bare URL refs use square brackets; and most refs which do use square brackets are filled, e.g. [http://examplew.com/balagan Balagan Today]

You might have spotted your error if you had checked your search results. For example, the first result in your broken search is [[Midfielder], which has no bare URL refs. BrownHairedGirl (talk) • (contribs) 11:20, 16 August 2022 (UTC)

RFC: Should the mass REMOVAL of Cleanup bare URLs be done by bots or meatbots?

There are two questions.

1. Should the mass REMOVAL of {{Cleanup bare URLs}} be done by bots or meatbots?
2. Should bare URLs tagged with issues, like <ref>https://example.com {{deadlink}}</ref> be ignored in this mass removal? Meaning that the {{Cleanup bare URLs}} tag would be removed in those cases.

Headbomb {t · c · p · b} 01:04, 16 August 2022 (UTC)

Discussion (mass removal of Cleanup bare URLs)

1. It would be highly preferable to do this by bot IMO. I don't have any real objection to having this done semi-automatically, but in all cases the removal should only be done when all bare URLs have been taken care off. Headbomb {t · c · p · b} 01:15, 16 August 2022 (UTC)

(edit conflict × 3)

1. I have, in one case (List of Polish mathematicians), seen {{cleanup bare URLs}} from an article that did in fact contain bare URLs. But some sort of automated process should do this anyway, since (a) bare URLs are often filled in using bots/scripts (b) confirming an article does in fact contain bare URLs is tedious work when done manually. (c) I'm not seeing any real harm this bot task causes. I don't really care whether this is a bot or a meatbot.
2. Yes at least in the case of {{dead link}}, as the dead link tag effectively supersedes the bare URL tag since as one cannot fill in a dead link any further. For other maintenance tags such as {{user-generated source}}, the case is less clear, and I have no strong position.

* Pppery * _{it has begun...} 01:17, 16 August 2022 (UTC)

as the dead link tag effectively supersedes the bare URL tag since as one cannot fill in a dead link any further You can certainly fill dead links further. I do so routinely. For example

• https://www.gamedeveloper.com/api/redirects?to=/view/feature/3565/the_history_of_panzer_dragoon.php

can be fixed to

• Torres, Ricardo (December 11, 2002). "Panzer Dragoon Orta Preview". GameSpot. Archived from the original on 2022-05-05. Retrieved May 22, 2022.

This also would apply to non-dead links like

• https://example.com

Headbomb {t · c · p · b} 01:23, 16 August 2022 (UTC)

This is absurdist nonsense:

1. A dead link cannot be filled. How hard is that to understand?
2. A dead link may be rescued by a link to an archive. If that archive link is bare, the ref can be filled ... but until and until it is rescued, it cannot be filled.
3. For the love of al that is highly, what on earth is the pint of retaining at the top of an article a big banner asking editors to fill a ref to a URL which has already been identified as unreliable source?

Why is my work being disrupted by such utter folly? BrownHairedGirl (talk) • (contribs) 01:34, 16 August 2022 (UTC)

A dead link cannot be filled.

See above for how it can be filled. See also below for why bots cannot assume that links tagged by maintenance tags need to be removed. Headbomb {t · c · p · b} 08:04, 16 August 2022 (UTC)

Yet again, @Headbomb, your stubbornness blinds you the details. So you are wrong, and yet again you are doubling down on your wrongness.

Those details have already been explained to you, but I will repeat:

1. A dead link bare URL ref cannot be filled, because no info is available with which to fill it
2. If an archived copy is found, that archived copy is not dead and cannot be filled.

So, the response to a dead link bare URL is to try to find that archived copy. Unless and until that archived copy is found, it is pointless asking editors to fill the ref. The {{Dead link}} tag is sufficient. BrownHairedGirl (talk) • (contribs) 11:13, 16 August 2022 (UTC)

A dead link bare URL ref cannot be filled, because no info is available with which to fill it

Which is demonstrably wrong, as evidenced above. Headbomb {t · c · p · b} 12:01, 16 August 2022 (UTC)

No, @Headbomb. I am right, and you are wrong again

This is very very simple.

A dead link cannot be filled.

An archived copy of a dead link can be filled.

You are unable or unwilling to understand that crucial distinction, and your stubbornness is turning into disruptive timewastasting. BrownHairedGirl (talk) • (contribs) 12:20, 16 August 2022 (UTC)

It can sometimes be filled, but it's a two-stage process. Sometimes organisations will restructure their website so that all the old links either take you to the website's main page, to a generic landing page, or fail entirely. Stage 1 is to identify where the page has gone to; as an example, consider http://curvebank.calstatela.edu/newmath/newmath.htm - clicking that link actually takes you to http://web.calstatela.edu/curvebank/ - a landing page. Acting on the advice there, and using the search facility at nationalcurvebank.org, yields http://old.nationalcurvebank.org/newmath/newmath.htm with which I was able to make this edit. If that dead URL had been inside ref tags, stage 2 would have been to fill it in with title, author, date etc. --Redrose64 🌹 (talk) 14:32, 16 August 2022 (UTC)

• Speedy close this blatantly bad faith RFC. This is a deliberately disruptive exercise, opened as revenge for the fact that I explained above to Headbomb how his objection to removal had no support, and how his aggressively process-abusing closure of WP:BHGbot 9 had not prevented me from removing redundant banners from over ten thousand articles over the last 8 months, without a single objection from anyone. --BrownHairedGirl (talk) • (contribs) 01:23, 16 August 2022 (UTC)

  Same as above. Headbomb {t · c · p · b} 01:27, 16 August 2022 (UTC)

  @Headbomb: your bad faith is as plain as a very plain thing.

  This is just an exercise in wasting my time, motivated by revenge. BrownHairedGirl (talk) • (contribs) 01:29, 16 August 2022 (UTC)

• Note that I suggested to Headbomb that they open an RFC on the substantive issue in his dispute with me: "Should we retain at the top of an article a big banner about filling bare URL refs which have already been tagged as unsuitable, and which should therefore be replaced or removed".
  Sadly, Headbomb has chosen not to ask this question, and also makes no attempt to explain tye reasominh for his demand that editors should be faced with a big banner asking them to fill a bare URL ref which actually be removed or replaced.
  This reminds me of the Kerryman joke about the Kerryman who wrote a book which was so bad that the publisher rewrote it before binning it. Except that in this case, Headbomb is not joking: he genuinely wants editors to waste their time filling refs to unreliable sources ... which will then be removed.
  Why on earth would anyone demand that? --BrownHairedGirl (talk) • (contribs) 01:52, 16 August 2022 (UTC)

  Because bots are dumb, and cannot determine if a source is reliable or not, nor if it should be removed or not. This is something that requires human review. If there are bare URLs remaining, the bare URL tag should remain. That's a rather simple thing to understand. Headbomb {t · c · p · b} 02:44, 16 August 2022 (UTC)

  @Headbomb: it seems that not only bots are dumb.

  Bots do not determine whether a source is reliable or not. Those tags are added manually by humans.

  My approach to those tags is to respect the judgement made by those human editors. The Headbomb approach is to disregard those judgements, and to ask human editors to devote some of their limited time on this earth to filling a ref which another human has assessed as unreliable, and to fill the ref even if they agree that it is unreliable. That is a spectacularly dumb stance, and it is a sad reflection of BAG's tendency to herd-like groupthink that several other BAG members supported this spectacularly dumb stance. BrownHairedGirl (talk) • (contribs) 03:09, 16 August 2022 (UTC)

  "Those tags are added manually by humans." And humans can be wrong for a plethora of reason. Some random person can add, in good faith, to anything. That doesn't make the source reliable, or even improperly cited. Bots cannot determine that context, and cannot assume that just because there is some sort of maintenance tag, that the correct outcome is the removal of the source. Headbomb {t · c · p · b} 08:00, 16 August 2022 (UTC)

  Again, @Headbomb, your binary logic and refusal to listen blinds you to the simple explanations offered by an editor who has worked on this stuff every day for a year.

  Consider these two examples:

  1. Article1 has one bare ref: a ref to a flaky blog tagged as unreliable.
     My AWB job removes the {{Cleanup bare URLs}} banner, correctly
  2. Article1 has one bare ref: a ref to a highly-cited academic journal which some IP vandal has tagged as unreliable.
     My AWB job removes the {{Cleanup bare URLs}} banner, correctly.
     However, when someone else spots the bogus tag and remove the unreliable tag, my other job will add the banner back again.

  So there is no need to retain the banner just on the outside chance that a ref has been wrongly tagged.

  Note too, that you have contradicted yourself. Here you say that Bots cannot determine that context ... but up above, you wrote Feedback has been provided on how a future bot request could be modified to address the concerns and gain approval.

  You are facing both ways, and the only consistency in your antics is your transparent determination to impede my work. BrownHairedGirl (talk) • (contribs) 11:08, 16 August 2022 (UTC)

  In both cases the removals are inappropriate because bare URLs remain. It really is that simple. Headbomb {t · c · p · b} 12:02, 16 August 2022 (UTC)

  Again, @Headbomb, after 8 months you still stubbornly refuse to acknowledge the core purpose of {{Cleanup bare URLs}} banner.

  It is not some sort of linnean classification system.

  It is a request to editors to fill one or more bare URL refs.

  And I repeat: it is absurd to ask editors to fill a ref which has been identified as being unsuitable, an which should be removed or replaced.

  Your conduct is like the dumb as a brick tag which you rudely applied to my code in BhGbot9: you completely refuse to grasp the simple point that the purpose {{Cleanup Bare URLs}} is to ask editors to fill a ref. What is so hard to understand? BrownHairedGirl (talk) • (contribs) 12:28, 16 August 2022 (UTC)

1. Yes, absolutely. I find +13K articles with the tag without bare url refs. Not sure what reliability has to do with it.
2. No, leave them, and let editors remove them manually, along with the dead refs.

— Guarapiranga ☎ 07:59, 16 August 2022 (UTC)

@Guarapiranga: your number of 13k+ is utter nonsense.

You got that nonsense number because your search is broken: it wrongly assumes that bare URLs (and only bare URLs) are wrapped in square brackets, e.g. [http://example.com/foo].

Neither assumption is true: almost zero bare URL refs use square brackets; and most refs which do use square brackets are filled, e.g. [http://examplew.com/balagan Balagan Today]

See e.g. the first article in your search results: Manchester Airport, which has three inline-tagged bare URLs.

Before you make snarky comments about reliability, please check your own data. BrownHairedGirl (talk) • (contribs) 10:54, 16 August 2022 (UTC)

1. No need to be wp:uncivil, BrownHairedGirl. I didn't mean to be snarky; I genuinely did not understand what reliability has to do with any of this. It seems to me a completely separate issue; there are perfectly formatted refs that are unreliable, and bare url refs that are at the top of wp:reliability.
2. You're right; correcting the search to exclude articles with refs without braces (instead of refs with brackets), yields 455 tagged articles without bare url refs.

  — Guarapiranga ☎ 02:52, 18 August 2022 (UTC)

@Guarapiranga: your comment about reliability was in a sentence about numbers, so I read it as being about the reliability of the numbers. Please do not call me uncivil for responding to what you actually wrote, instead of whatever you actualy meant.

Your revised search is still broken, because it is far too simplistic.

For examples, your search will not recognise inline tagged bare URLs : <ref>http:/foobar.com/foo {{Bare URL inline|date=June 2022}}.

There are articles with multiple inline-tagged bare URLs, and a {{Cleanup bare URLs}} banner. I don;t remove the banner unless the total number of bare tagged URLs is less than three.

For a year now, I have been working every day with regexes to identify bare URLs. It's a bit wearing to find someone coming to a discussion like this and repeatedly posting as fact nonsense data which they clearly have not even tested. BrownHairedGirl (talk) • (contribs) 03:22, 18 August 2022 (UTC)

• Speedily close per BHG and others. Rlink2 (talk) 22:58, 16 August 2022 (UTC)
• Leave no reason to remove, unless the problem has been fixed, which should be done by the person doing the fix. As per other tags which remain in place until the problem is deamed fixed. Keith D (talk) 17:32, 17 August 2022 (UTC)

  @Keith D: the fixes may be done manually, or by a tool, or by a bot such as @Citation bot.

  For example,

  • an editor may fill the ref manually, or may use a tool such as WP:ReFill or WP:Reflinks
  • the ref may be filled by Citation bot
  • the ref may be tagged as a {{dead link}} (and hence unfillable)
  • the ref may be tagged with {{Bare URL inline}} by my regular AWB job User:BrownHairedGirl/No-reflinks_websites, making the banner redundant in some cases
  • the ref may be converted by InternetArchiveBot to the "Archived copy" format using {{cite web}}, and hence be no longer bare. (Those cases are automatically tracked in Category:CS1 maint: archived copy as title; we don't need the banner as well)
  • the ref may be tagged with of the many inline tags which mark it as unsuitable: unreliable, nonspecific, user-generated, self-published, circular ref, primary source etc. In such cases, the banner is no longer needed, because the remedy with those refs is not to fil them: it is to remove or replace them.

  Note that only the first of those six scenarios necessarily involves an actual human, and humans do not always know when to remove a banner. See e.g. User talk:BrownHairedGirl#Michael,_Row_the_Boat_Ashore (permalink), where an editor does a great job of filling cite templates, but doesn't know whether to remove the banner, and misses one bare URL.

  So if we leave it to humans to remove the banners, we will retain a lot of un-needed banners, and have some inappropriate removals. In the last 8 months, I have used my AWB Custom Module to remove well over 10,000 redundant {{Cleanup bare URLs}} banners, without a single objection from anyone at all. This semi-automated removal is working. BrownHairedGirl (talk) • (contribs) 18:32, 17 August 2022 (UTC)

Moving the template to the references section

This worthy suggestion has all but drowned in all the discussion (and sniping) going on above.

EEng was one editor suggesting it, BrownedHairGirl opposed it. Then discussion veered elsewhere.

Lets get back on track: I agree tucking the banner away from the article header is a really good thing, and placing it in the references section is as good as any suggestion. CapnZapp (talk) 17:40, 16 August 2022 (UTC)

It's not, because the bare links could be anywhere in the article: references, external links, body of the article, footnotes, bibliography section, etc... The only sure way to have it apply correctly is to have it at the top. Headbomb {t · c · p · b} 00:27, 17 August 2022 (UTC)

I think it should stay at the head of the article, where it is more likely to provoke action on clearing the problem. - Donald Albury 18:12, 16 August 2022 (UTC)

How about we just put this energy into fixing the URLs, rendering the tag obsolete? BD2412 T 23:05, 16 August 2022 (UTC)

A) This logic could be used to stick every issue ever as a cleanup issue on top of the article. Yet we don't highlight many similar maintenance tasks and instead track them in-line, or with maintenance categories, or with talk page notifications. There needs to be an affirmative case for how sticking this on top helps compared to the other options - that it's really attracting random passerby to fix the issues. B) BD2412, even in the unlikely scenario of fixing all of the bare URLs on Wikipedia, new ones will get added. So this is an on-going policy concern as to how to handle this kind of a problem. C) As I've mentioned before, even if we grant for a moment bare URLs are catastrophic (I don't), cleanup templates on top of a page are generally reader focused, not editor focused. And bare URLs aren't really a concern for readers. ("Bad sourcing" tags might be, but that's a separate issue, and such cleanup templates already exist.) This template has been added to the top of perfectly valid, well-sourced articles that happen to have a single bare URL in them somewhere. Now, if an editor fixes that, great, but if no such fix happens, why are we marking the article as a whole unreliable to readers? SnowFire (talk) 05:35, 17 August 2022 (UTC)

CapnZapp (talk) 12:17, 17 August 2022 (UTC)

@SnowFire, I am still horrified that you place such a low priority on good citations. This is an encyclopedia, not a collective blog, and good quality references are the absolute core of why were are here.

There are two parts to that concept of "good quality references":

1. that the source itself should be of a high-quality: reliable, scholarly, and supporting the assertions in the articles.
2. that the citation should identify that source in a clear and informative and consistent way, in accordance with the citation style in use.

A bare URL ref may meet the first criterion, but if it fails the second test, or clear presentation, then it is much harder for a reader to assess whether it meets the first criterion, i.e. of being a suitable source.

So I am horrified that you say bare URLs aren't really a concern for readers. The reality is entirely the opposite: references are the way by which our readers can verify what we publish, and bare URLs make it harder for them to do that. BrownHairedGirl (talk) • (contribs) 16:42, 17 August 2022 (UTC)

@SnowFire: Two of the issues you raise are technical points, which I reckon are better separated from the issues of principle.

The first is your assertion that we don't highlight many similar maintenance tasks and instead track them in-line. In principle, I partly agree: where possible, single instances should be tagged inline. However, there is a technical problem with that: WP:REFLINKS does not support the {{Bare URL inline}}, and it is in my experience the best tool (or rather the east worst) for filling bare URLs. A I discovered painfully at the end of June 2021, mass adding {{Bare URL inline}} has the undesired effect of being a barrier to actually filling the refs. Yes, ideally the tool would be fixed; but it is unmaintained.
So that is why I apply the inline tags only to refs which I know that RefLinks cannot fill: see User:BrownHairedGirl/No-reflinks_websites. For the other refs, banners are all that is available.

If WP:Reflinks supported inline tags, then I would add the banner only to articles with three or more bare URLs. But I see no chance of an upgrade for Reflinks. BrownHairedGirl (talk) • (contribs) 17:00, 17 August 2022 (UTC)

@SnowFire: another separate reply, for ease of threaded discussion.

You write: even in the unlikely scenario of fixing all of the bare URLs on Wikipedia, new ones will get added. So this is an on-going policy concern as to how to handle this kind of a problem.

So what would that scenario look like? Actually, after 13 months of work on this, I have already collected and published good data sets which allow me to describe quite accurately what that situation would look like.

• new bare URLs are added every day to an average of about 300 articles. (the daily number can fluctuate wildly, and there are some glitches in the counting, but 300/day is a fairly stable long-term average) I call these "Articles With Bare URLs" (ABURs), so we are looking at about 9,000 "New ABURs" per month.
• About 20% of those New ABUR have all their bare URLs filled with in a week or so by normal editing processes.
• Currently, I am using various methods to track New ABURs on a daily basis, and filing about 30% of them using @Citation bot. That is labour-intensive work, and I am won't be able to sustain it for long.
• The remaining 50% (and the 30% currently tackled on a daily basis, whenever I stop doing that) are picked up in my scans of the twice-monthly WP:Database downloads.
  Those new ABURs from each database dump are repeatedly-processed by me through Citation bot until progress stalls. This has all been documented publicly for 9 months, in the hundreds of revisions of User:BrownHairedGirl/Articles with new bare URL refs. See for example the results from July, which left only 1,069 new ABURs (excluding any which are inline-tagged):
  1. 8 passes of the New ABURs from the 20220801 database dump: 2,675 new ABURs, 443 remaining.
  2. 7 passes of the New ABURs from the 20220720 database dump: 2,671 new ABURs, 626 remaining.
• While writing this post, I just re-scanned those 1,069 new ABURs from July, and found that only 677 of those 1,069 New ABURs still have untagged bare URLs.

However, @AManWithNoPlan's diligent development work on Citation bot has just in the last few days increased the bot's cleanup rate. I will feed these remaining 677 New ABURs from July to the bot, and report back on the results. BrownHairedGirl (talk) • (contribs) 17:50, 17 August 2022 (UTC)

BHG, you would likely not experience so much blow-back had you not come across as ultimately uncompromising. What made you start this crusade against bare URLs I will never know. At the very least, please consider all the voices telling you you're making a mountain of a molehill - might it be that your stance is not the only reasonable to take? Why not take a moment to ask yourself WHY you are horrified when so many of your fellow editors aren't? CapnZapp (talk) 18:46, 17 August 2022 (UTC)

@CapnZapp: I do indeed believe your assertion that what made you start this crusade against bare URLs I will never know. In this and in two other venues, you have made it abundantly clear (at great length) that you have no interest in or understanding of the importance of referencing techniques, and that you are actively hostile to efforts to improve refs.

Luckily, most editors do not support your disdain for good citations, and you wholly misrepresent the discussion: you are in fact the only editor here to make a stand in favour of bare URLs. Otherwise the disagreement is imply about how and where to tag the remaining bare URLs after over 90% of them have been resolved.

There seems no possibility that you will desist from opposing good referencing, but other editors can find plenty of established guidance on why it matters: see e.g. WP:HOWTOCITE and WP:Bare URLs. BrownHairedGirl (talk) • (contribs) 19:04, 17 August 2022 (UTC)

You believe yourself a good neutral cool-headed editor, but in reality you are trying to crush your way through. If you were cool and levelheaded you'd realize this is blown out of all proportions, just look at this page! It's a full on wikipedia war, and YOU are the instigator. Please stop and reconsider your relentless barrage. You're in full-on defensive move where nothing anyone tells you gets through. If you only could realize everybody likes your actual work, just not the way you insist on billboarding your every move. If you could just drop the idea every single bare URL must be announced to the world as if somehow it turns its article into shit. Articles with bare URLs are fine, just not perfect. There is zero reason to suggest otherwise to readers. CapnZapp (talk) 21:15, 17 August 2022 (UTC)

@CapnZapp: nobody else on this page agrees with your view that Articles with bare URLs are fine. Nobody.

So I will go back to ignoring you and your nasty personalised commentary, and your bogus allegations of "war". BrownHairedGirl (talk) • (contribs) 21:22, 17 August 2022 (UTC)

As a Twinkle programmer, I'd be inclined to keep all maintenance tags together at the top. This is easier programatically, and also allows the use of the {{Multiple issues}} template. It also follows the principle of least astonishment, since almost every other full article maintenance tag goes there. The only exceptions are {{Uncategorized}} and {{Improve categories}}, which go second from the bottom. Those two exceptions have been a pain and required an RFC over at MOS:ORDER to sort out. The lesson I learned from that is that when we have a standard place for things, it is usually best to use the standard place, rather than making a bunch of exceptions. Just my two cents though, don't take it too seriously :) –Novem Linguae (talk) 05:57, 17 August 2022 (UTC)

About Wikipedia:Changing username/Usurpations

Hello, I have a question regrading Wikipedia:Changing username/Usurpations. I have found that there is a local page for usurpation. However, all the other languages listed (d:Q4615956) are closed or inactive. Moreover, like Global locks, users are globally renamed. As a result, I would like to ask why Wikipedia:Changing username/Usurpations is currently still available on making requests and would it be possible to merge the requests to the the same page on metawiki (i.e. Stop allowing making requests in enwiki). 132.234.112.11 (talk) 04:11, 16 August 2022 (UTC)

Makes sense. We now have single unified login and follow the global usurpation rule anyway. —CX Zoom[he/him] ^{(let's talk • {C•X})} 04:46, 16 August 2022 (UTC)

Because we are huge and host many only-one-wiki users; this allows for a quicker process when only enwiki is involved (1 week vs 1 month). — xaosflux ^Talk 14:09, 16 August 2022 (UTC)

phabricator requested I report this

Report it in a support forum of English WP. If this isn't the right place (I'm not the most knowledgeable WP-editor), I assume/hope somebody here will send it to the right place. You can read the problem here:
https://phabricator.wikimedia.org/T314837 Dutchy45 (talk) 07:51, 16 August 2022 (UTC)

Resolved

CapnZapp (talk) 18:48, 17 August 2022 (UTC)

#WPWP

It looks as if someone is running a campaign to add images to enwp articles with edit summaries containing #WPWP or #‎WPWPNG. This also occurred in August 2021, with the good-faith addition of many images, some of which were inappropriate. Does anyone know who is behind this campaign? Are there any opinions as to whether it's useful and what, if anything, we should do about it? Certes (talk) 00:58, 18 August 2022 (UTC)

WP:Administrators' noticeboard/Archive344#WPWP query. —Cryptic 01:10, 18 August 2022 (UTC)

@Certes: any diffs or links or other ways to see what's happening? BrownHairedGirl (talk) • (contribs) 01:59, 18 August 2022 (UTC)

https://hashtags.wmcloud.org/?query=WPWP&project=en.wikipedia.org. The most recent edit as of now (other than this discussion) is typical. —Cryptic 02:12, 18 August 2022 (UTC)