Wikipedia:Bots/Noticeboard

From PsiForum
< Wikipedia:Bots(Redirected from WP:BOTN)
Jump to navigation Jump to search

Wikipedia:Bots/Noticeboard/Header

Bot that applied ShadowsCommons tags

I distinctly remember that several years ago a bot ran that automatically applied {{ShadowsCommons}} tags to Wikipedia files that had a non-identical file on Commons with the same name. Is it just a figment of my imagination, or did it actually exist? Jo-Jo Eumerus (talk) 16:28, 25 October 2021 (UTC)

It was User:GreenC bot/Job 10 * Pppery * it has begun... 16:31, 25 October 2021 (UTC)
User:Jo-Jo Eumerus it was offline since May due to changes at WMF that disallowed cross database searches. As of November 8 it is up working again with a new solution (GitHub also updated). I'm not 100% confident it is finding everything it should, but it is getting some things example just not at the same rate before May. If you are aware of anything it might be missing, or other processes doing this, that would be helpful to know. -- GreenC 03:38, 24 November 2021 (UTC)
Oh. See, my impression was that back then ShadowsCommons situations were far more common than they are now. I've seen that many of the files on Wikipedia:Database reports/Non-free files shadowing a Commons file didn't have a shadows commons tag so I was wondering if the bot was tagging these. Jo-Jo Eumerus (talk) 10:48, 24 November 2021 (UTC)

DumbBOT

Hello, Bot group,

I rely on DumbBOT which updates the PROD lists but since September, the updating schedule has shifted several times. I have left inquiries about this on DumbBOT's talk page but today, after another updating change, I went to the user page of the bot operator, Tizio, and saw that he hasn't logged in for over a year. I don't want the bot disabled but it seems like it should have an active operator who still works on Wikipedia. In fact, I don't understand how the updating schedule keeps shifting if the bot operator has been absent so long! Any chance that someone else could take over as operator? Thanks for any assistance you can offer. Liz Read! Talk! 00:37, 24 November 2021 (UTC)

Hi Liz, not a member of BAG but I've sent them an email pointing them to this thread. Their user page says I rarely log in lately. In case of problems with the bot email me. so perhaps we'll get a reply. I agree that bot operators should be active, and would urge a RfC on adding this to policy File:Face-smile.svg ~TheresNoTime (to explain!) 00:48, 24 November 2021 (UTC)
I seem to recall discussion about adding this to policy wayyyyyyy back in the past when I was on BAG (you know, when we had to use punch cards and snail-mail them to the WMF :P). Clearly it didn't happen! I entirely agree that bot operators should be responsive to concerns/bug reports/etc. I'm less sure about them being active in terms of some minimum edit requirement - as long as they respond to bot issues, that'd be good enough for me. (Which reminds me, I owe Liz a reply about the G13-warning task...) firefly ( t · c ) 08:39, 24 November 2021 (UTC)
It never occurred to me that the schedule of updates was important to some people. I sometimes do test runs, but other than this I haven't changed the times the bot runs. Except for the last couple of days, due to hardware maintenance; this may last some other time. Still, the bot is still working properly, and doesn't seem to me that updates were delayed that much. Tizio 09:50, 24 November 2021 (UTC)
We recently changed policy such that the operator needs to be available by talk page notification at a minimum. See this diff and instituting discussion. As for activity, I believe you're looking for this 2018 discussion, which I am not going to hunt down the specific change. Izno (talk) 17:25, 24 November 2021 (UTC)
I ended up activating email notifications, so that I will know when someone writes something to my talk page or the bot's.Tizio 14:38, 25 November 2021 (UTC)

Double redirects not fixed for several days

Even double redirect-fixing bots, like humans, like to procrastinate. At Special:DoubleRedirects, there is a list of hundreds of double redirects that have not been fixed for several days. Could this be considered "bot procrastination", then? GeoffreyT2000 (talk) 15:00, 29 November 2021 (UTC)

@GeoffreyT2000: These are fairly easy to fix with the pywikibot script, mw:Manual:Pywikibot/redirect.py ― Qwerfjkltalk 20:08, 29 November 2021 (UTC)
Futher instructions

Follow the instructions on mw:Manual:Pywikibot/PAWS to create a server and set everything up, then open a terminal. Type pwb.py redirect.py double, and then review each change it suggests. Some example edits I just did:

 ― Qwerfjkltalk 17:26, 30 November 2021 (UTC)

When editing through your main account, don't put "Bot: " in the edit summary. – SD0001 (talk) 17:45, 30 November 2021 (UTC)
@SD0001: How do you change the summary? ― Qwerfjkltalk 18:46, 30 November 2021 (UTC)
Xqbot already runs that exact script, so I don't think there's any value in running it manually. If it's missing some page moves or edits, that should be reported as a bug against Pywikibot. Legoktm (talk) 22:17, 1 December 2021 (UTC)

XLinkBot has forked an article! 😲

XLinkBot (t⧼dot-separator⧽c⧼dot-separator⧽del⧼dot-separator⧽cross-wiki⧼dot-separator⧽SUL⧼dot-separator⧽edit counter⧼dot-separator⧽pages created (xtools • sigma)⧼dot-separator⧽non-automated edits⧼dot-separator⧽BLP edits⧼dot-separator⧽undos⧼dot-separator⧽rollbacks⧼dot-separator⧽reviews⧼dot-separator⧽logs (blocks • rights • moves)⧼dot-separator⧽rfar⧼dot-separator⧽spi) (assign permissions)(acc · ap · fm · mms · npr · pm · pcr · rb · te)

On 2020 July 3, XLinkBot has overwritten a redirect with the content of its target article, effectively creating a fork! Here's the diff: [1] - Waysidesc (talk) 18:32, 2 December 2021 (UTC)

XLinkBot reverted content for no apparent reason. Not the first time I have seen (on my watchlist) XLinkBot reverting content incorrectly. -- GreenC 18:42, 2 December 2021 (UTC)

I guess this should be reported to User:Versageek. -- GreenC 18:42, 2 December 2021 (UTC)
Operators notified of this discussion. — xaosflux Talk 19:10, 2 December 2021 (UTC)
The first one is 1.5 years ago, odd but untraceable why that happened (unless people can show me a pattern).
I hoped that I resolved the second last week, but apparently there is still an issue there. If that one persists please turn off editing in the settings until I can solve it). Dirk Beetstra T C 13:19, 3 December 2021 (UTC)
@GreenC: I applied a new patch to both m:User:LiWa3 (who is at the core of the problem) and User:XLinkBot (who should properly check that what LiWa3 is telling him is true). It is running from now, please ping me if you see the wrong reverting problem appear again from, say, tomorrow (there may still be old edits in parserqueues somewhere, though it should be instant - XLinkBot should throw an error on what LiWa3 still had in parserqueues was wrongly parsed). Dirk Beetstra T C 08:36, 4 December 2021 (UTC)
Thought I did .. seems like I broke the bots. --Dirk Beetstra T C 10:51, 5 December 2021 (UTC)
And fixed again. Dirk Beetstra T C 18:27, 5 December 2021 (UTC)
@Beetstra: happening again. -- GreenC 17:38, 7 December 2021 (UTC)
Bot is off for now. Dirk Beetstra T C 04:07, 8 December 2021 (UTC)
I did a handful of adaptations to both LiWa3 and XLinkBot, it looks better now. I have turned XLinkBot back on, but please check whether I really solved it (proof is in the pudding). --Dirk Beetstra T C 11:27, 14 December 2021 (UTC)

Template Editor permission for bot

@Xaosflux and Ymblanter: In reference to this discussion, my bot was approved for another task that requires template-editor permission. After the issues with the last request, I completely forgot to request it again when the task was approved, and just realized now why edits haven't been going through. --Ahecht (TALK
PAGE) 17:18, 6 December 2021 (UTC)

@Ahecht: it looks like @El C: just upgraded the protection on that page from ECP to TEP - perhaps ECP will suffice? — xaosflux Talk 17:32, 6 December 2021 (UTC)
@Xaosflux: I have no idea what page you're referring to. El_C 17:51, 6 December 2021 (UTC)
@El C: sorry, it is Special:Redirect/logid/123242534. — xaosflux Talk 18:50, 6 December 2021 (UTC)
@Ahecht: and you are the one that asked for this to be protected - breaking yourself! Why do these pages need TE protection? What is the actual usage count realized? — xaosflux Talk 18:52, 6 December 2021 (UTC)
That page is read by the WP:AFCH gadget (which is actively used by about 600 editors and was used to place WikiProject banners 110 times in the last month per quarry:query/60495), MediaWiki:AFC-add-project-tags.js gadget (which was used 867 times in the last month per quarry:query/60494, and which was switched to that file based on your comments here about not having mediawiki js pages calling a userspace page), and MediaWiki:AFC-submit-wizard.js (which was used 2802 times in the last month to add WikiProject banners per quarry:query/60496). It's also used by User:SD0001/draft-sort-burst.js and User:Ahecht/Scripts/draft-sorter.js. --Ahecht (TALK
PAGE) 23:09, 6 December 2021 (UTC)
OK, so seems like ECP should be fine here - it is in relatively low use by a gadget and as a json page can't be used to inject commands? — xaosflux Talk 00:01, 7 December 2021 (UTC)
Done. At your command, technocrats! El_C 00:11, 7 December 2021 (UTC)

Unattended bots

Robert McClenon posted on the Teahouse (permalink to thread) about an action of Yapperbot (talk⧼dot-separator⧽contribs⧼dot-separator⧽deleted contribs⧼dot-separator⧽logs⧼dot-separator⧽filter log⧼dot-separator⧽block user⧼dot-separator⧽block log), whose maintainer Naypta has not edited since August 2020. While the issue they mentioned could be closed ("working as intended"), they mention that a bot should not run without supervision even if it works fine. I think that is correct; as WP:BOTCOMM requires bot maintainers to promptly reply to any concern about their bot operation, they should be active on the project or at least responsive to pings/talk page messages.

Are we really going to block Yapperbot in the absence of a malfunction? Yapperbot is only one example, I imagine[dubious – discuss] that there are quite a few bots that still run without a human at the other end of the leash. The question is what to do to enforce BOTCOMM.

I suspect the actual current enforcement scheme is that such "zombie" bots are left alone until they misbehave badly enough, at which point they are blocked, though no example comes to my mind (even though I have been reading this noticeboard for a few years). I also suspect that zombie bots would get blocked at the first sign of mischief, whereas bots with a responsive maintainer (who promises a fix is on the way) would be cut more slack. That is probably not what the letter of the policy says, but it is reasonable. TigraanClick here for my talk page ("private" contact) 13:09, 7 December 2021 (UTC)

Personally speaking, if a bot is acting as intended, I say let it run until a) its use is no longer required, or b) it starts messing up. I do agree with your hypothetical that we are often more lenient for an active-operator bot that is malfunctioning, but as has been seen with a few bots in the relatively-near past, sometimes they need to be blocked anyway. Primefac (talk) 13:15, 7 December 2021 (UTC)
I talk to the owner, if the owner does not respond after a 'real' error and the error repeats, I bluntly block the bot. If the owner does respond after the first error and promises to maintain I will allow for some more errors, but will then eventually also block the bot if the error is not resolved. I guess we will not know whether Naypta is responsive on the bot-error-part until we encounter bot errors. (P.S. did we try to email Naypta?). Dirk Beetstra T C 13:54, 7 December 2021 (UTC)
If a bot is malfunctioning, blocking is always an option. If it gets blocked and the operator is unresponsive then it just stays blocked. I'm not up to block a bot that is working properly just because the operator is slow to respond. This noticeboard is a fine place to discuss such situations case-by-case. — xaosflux Talk 14:26, 7 December 2021 (UTC)
User:Tigraan - Thank you for raising the issue here. First, to clarify, Yapperbot is working properly and is doing a service for the community. It should be allowed to continue running. The situation that I tried to report was something of a corner case in which an RFC was tinkered with in a way that the bot did not understand. Second, I agree with the other editors about the blocking of bots. They should be blocked quickly if there is no responsible human, and if there is a human, there should be discussion with the human. Third, however, is someone willing to take responsibility for the bot? This is a case where we only noticed that the bot is running correctly but without a human because the behavior of the bot was suboptimal when the behavior of a human editor was suboptimal. Is this the right place to call attention, non-urgently, to bots that don't have a bot operator? Robert McClenon (talk) 16:40, 7 December 2021 (UTC)
To answer your last question in as few words as necessary, yes. Primefac (talk) 20:50, 7 December 2021 (UTC)
Even if the operator were active and simply didn't want to fix the 'bug' in this example (due to time constraints etc), it wouldn't really warrant blocking the bot. An odd notification about a closed RfC due to some rare bug is not much of an inconvenience and it's very small in proportion to all edits. More could probably be done to aid in the maintainability of bots, like with scripts any IA is technically able to edit a script if required (for maintenance/bug fixes); not as simple for a bot which runs on a server of its operator (or even Toolforge, given the strict policy for unmaintained tools). ProcrastinatingReader (talk) 23:19, 7 December 2021 (UTC)

An extreme case of this issue was Cydebot, which for about 15 years processed categories which WP:CFD had agreed to merge, rename, or delete. Cydebot did about 6.8 million edits in that time.

In the latter years, the bot owner @Cyde was around very rarely. That didn't matter while the bot did great work, but it became an issue when changes in bot functionality were needed. So a new bot was created, and when it was ready to roll, Cydebot was blocked to avoid clashes between two bots.

Cyde had done a magnificent job in creating a bot which ran error-free on such a huge scale for so long (average 1,200 edits per day for 15 years). There was no question of blocking the bot just 'cos Cyde wasn't around for chatter.

So I agree with Primefac: if a bot is acting as intended, I say let it run until a) its use is no longer required, or b) it starts messing up. --BrownHairedGirl (talk) • (contribs) 01:52, 16 December 2021 (UTC)

We have a bot that's supposed to patrol new redirects, but there are hundreds of unpatrolled ones from November

In Special:NewPagesFeed, filtering for redirects and sorting by oldest brings up hundreds of month-old redirects from November 9. Some of them are recently-redirected articles and similar things with complicated page histories, but others (like this one at American Chemical Manufacturing and Mining Company) have only had one revision that whole time. I see that DannyS712 bot III's Task 66 was approved to patrol redirects automatically (following this RfC)-- indeed, the bot's log shows it patrolled some new redirects just a few minutes ago, and its to-do list is empty -- so what's going on here? jp×g 23:38, 7 December 2021 (UTC)

Nota bene: I am posting this here because the bot's creator and maintainer, @DannyS712:, has said he's not around much anymore and hasn't edited since November 19. jp×g 23:40, 7 December 2021 (UTC)

Never mind, I am a fool -- in the bot's source code it fetches a whitelist from pageid 62534307, which is Wikipedia:New pages patrol/Redirect whitelist. jp×g 23:52, 7 December 2021 (UTC)

Bots Newsletter, December 2021

Bots Newsletter, December 2021
BAG laurier.svg
BRFA activity by month

Welcome to the eighth issue of the English Wikipedia's Bots Newsletter, your source for all things bot. Maintainers disappeared to parts unknown... bots awakening from the slumber of æons... hundreds of thousands of short descriptions... these stories, and more, are brought to you by Wikipedia's most distinguished newsletter about bots.

Our last issue was in August 2019, so there's quite a bit of catching up to do. Due to the vast quantity of things that have happened, the next few issues will only cover a few months at a time. This month, we'll go from September 2019 through the end of the year. I won't bore you with further introductions — instead, I'll bore you with a newsletter about bots.

Overall

September 2019

File:Frankenstein1931CliveKarloff (cropped).jpg
Look! It's moving. It's alive. It's alive... It's alive, it's moving, it's alive, it's alive, it's alive, it's alive, IT'S ALIVE!
  • File:Symbol confirmed.svgY Monkbot 16, DannyS712 bot 60, Ahechtbot 6, PearBOT 3, Qbugbot 3 · 20pxN2 DannyS712 bot 5, PkbwcgsBot 24 · Blue question mark? DannyS712 bot 61, TheSandBot 4
  • TParis goes away, UTRSBot goes kaput: Beeblebrox noted that the bot for maintaining on-wiki records of UTRS appeals stopped working a while ago. TParis, the semi-retired user who had previously run it, said they were "unlikely to return to actively editing Wikipedia", and the bot had been vanquished by trolls submitting bogus UTRS requests on behalf of real blocked users. While OAuth was a potential fix, neither maintainer had time to implement it. TParis offered to access to the UTRS WMFLabs account to any admin identified with the WMF: "I miss you guys a whole lot [...] but I've also moved on with my life. Good luck, let me know how I can help". Ultimately, SQL ended up in charge. Some progress was made, and the bot continued to work another couple months — but as of press time, UTRSBot has not edited since November 2019.
  • Article-measuring contest resumed: The list of Wikipedians by article count, which had lain dead for several years, was triumphantly resurrected by GreenC following a bot request.

October 2019

November 2019

Error creating thumbnail:
Now you're thinking with portals.

December 2019

In the next issue of Bots Newsletter:
What's next for our intrepid band of coders, maintainers and approvers?

  • What happens when two bots want to clerk the same page?
  • What happens when an adminbot goes hog wild?
  • Will reFill ever get fixed?
  • What's up with ListeriaBot, anyway?
  • Python 3.4 deprecation? In my PyWikiBot? (It's more likely than you think!)

These questions will be answered — and new questions raised — by the January 2022 Bots Newsletter. Tune in, or miss out!

Signing off... jp×g 04:29, 10 December 2021 (UTC)

(You can subscribe or unsubscribe from future newsletters by adding or removing your name from this list.)

Bot to tag unused fair use files for deletion

Hello! Does anyone know of a bot that tags unused fair use files for delayed speedy deletion under criterion F5? I'm going through the list of them right now, and some have been unused for a while — for example, File:"Mookajjiya Kanasugalu", Film Poster.jpg, which hasn't been used in Mookajjiya Kanasugalu (film) for more than seven weeks. (If there isn't a bot, I think I'd like to make one.) Tol (talk | contribs) @ 00:18, 16 December 2021 (UTC)

@Tol: I think that B-Bot does this (recent taggings) you could ask the operator about their process first. — xaosflux Talk 00:23, 16 December 2021 (UTC)
@Xaosflux: Thank you, that was what I was looking for! It looks like B-Bot tends to tag the file a few days after it's no longer used — I'm not sure why some files slip through the cracks. I'll contact the operator. Thanks again! Tol (talk | contribs) @ 00:29, 16 December 2021 (UTC)
@Tol and Xaosflux: I'm out of the country at the moment (returning December 24) so I can't make changes to my code until I get back. The list of orphans I am using is Wikipedia:Database reports/Unused non-free files. Further, it's waiting 24 hours after it first sees a file appear on that list before tagging it (so due to when the list is updated vs when I am tagging it may be 2 days). The reason for the wait is that when the bot was approved, one of the concerns expressed was that some users considered it obnoxious if a page was undergoing revision or was vandalized and we tagged an image as an orphan moments later. (I don't share this concern - but this was requested in the approval discussion.) I was previously doing a direct database query using Quarry and using this database report page only as a backup, but the Quarry page changed and I need to update my code to use the new version of it. I'm not sure why File:"Mookajjiya Kanasugalu", Film Poster.jpg wasn't picked up, but it's not on the database report page and from spot-checking the history, I don't see where it ever has been listed there. So I'm not sure where the breakdown is. When I get back, I will update the code to use the new version of Quarry and we can see if that works better. --B (talk) 20:49, 18 December 2021 (UTC)
Alright; thank you! Tol (talk | contribs) @ 21:46, 18 December 2021 (UTC)

BHGbot 9 review sought

Yesterday, I sought outside views on Wikipedia:Bots/Requests for approval/BHGbot 9, after failing to reach agreement with Headbomb and ProcrastinatingReader. See this request[2], at WP:Bots/Requests_for_approval/BHGbot_9#Other_views_sought

Unfortunately, instead of leaving it to previously-uninvolved BAG members, Headbomb decided to respond aggressively,[3] accusing me of being a dumb-as-a-brick-no-context-mindless-automaton, and falsely accusing me of making a personal judgement about the validity of a ref which had ben correctly tagged by another editor 4 years ago.

Headbomb has now declined[4] the BRFA, bizarrely accusing me of taking a general WP:BATTLEGROUND mentality -- even though it was Headbomb who responded with a BATTLEGROUND mentality to a reasoned request.

When I had specifically sought the views of BAG members other than PR & Headbomb, it was thoroughly inappropriate of Headbomb to close the BRFA before those outside views had been given.

Please can an uninvolved BAG member either reopen this BRFA, or review it? BrownHairedGirl (talk) • (contribs) 17:04, 16 December 2021 (UTC)

Oh my, there certainly seems a lot to unwind there. At its face, this seems like it should be a fairly uncontroversial task (remove a cleanup banner that is no longer needed) - something that I would expect an editor would do unceremoniously; it also seems fairly low volume. The impasse seems to be around what page conditions should or shouldn't warrant this template's use, and those same use cases should be or not be a problem for a human editor as well I would think? Is that being an unresolved question for human editors the crux of the conflict? — xaosflux Talk 17:17, 16 December 2021 (UTC)
@Xaosflux: the sticking point is quite simple, and quite bizarre.
In some rare cases, a tag such as {{better source needed}} has been mistakenly applied inside <ref>...</ref> tags. Even if the link is otherwise bare, the misplaced tag causes the bot to not recognise it as bare.
However, my view is that this actually a good glitch, because it is utterly daft to retain the big banner {{Cleanup bare URLs}} tag on a page where the only URL which could be counted as bare is one which has already been tagged for removal or replacement. That is in effect an inviting editors to fix a ref before someone removes it 'cos it should never have been there. Basically, "improve this before we bin it".
My view is supported by WP:CLEANUPTAG guidance: "If an article has many problems, tag only the highest priority issues" and "Don't insert tags that are similar or redundant".
Headbomb has chosen for some reason to take a stand to insist that the bot must leave such inappropriate {{Cleanup bare URLs}} tags in place, and do so with aggression which they have most unpleasantly tried to blame on me. BrownHairedGirl (talk) • (contribs) 17:49, 16 December 2021 (UTC)
@BrownHairedGirl: OK, so there is some sort of edge case where the page may be tagged that there are bareurls, when there are actually bareurls, for example if it included something like <ref>http://bare.url{{Better source needed}}</ref> correct? A wise human editor cleaning up that page should move that template to where it belongs, and then also improve the ref, then remove the bareurl cleanup tag - correct? I wouldn't expect a bot to be able to do all of that appropriately of course, however a bot could still detect that a bareurl is in ref tags, so long as it is also wrapped in a template, yes - that seems like the real check - a url in a ref should only be allowed if that url is contained within SOME template, or the url includes any other labeling. Yes, this would lead to some false negatives (extra skips) but that's OK. Can something like that be accommodated - and if so, will it resolve the dispute? I'd rather a bot skip something that is better done by a human in most cases. — xaosflux Talk 19:34, 16 December 2021 (UTC)
@Xaosflux: Your description of the issue and the human response sounds good. However, I am sorry, but I am not clear on what you are proposing the bot should do.
If it was easy to code for these exceptions, I would have sighed and done the coding, and accepted a few un-needed skips. However, it's actually quite a complex bit of coding (a monster regex to include a dozen template names and all their many redirects), which will be error-prone and not transparent.
I am also convinced that it is not just unnecessary, but actually undesirable. The effect of detecting these glitches would be to detect that a page which has a ref such as (in the disputed trial edit) <ref>https://www.imdb.com/title/tt0108956/technical?ref_=tt_dt_spec {{better source needed|date=October 2017}}</ref>, and treat that as a bare URL, and retain the {{Cleanup bare URLs}} tag.
That would be deeply undesirable and contrary to WP:CLEANUPTAG. I can see no circumstances whatsoever in which we should have a banner at the top of the page inviting editors to fill a bare URL ref in a case where that ref has already been identified as something which should be removed. Can you?
Headbomb wants to retain the {{Cleanup bare URLs}} tag in such circumstances, but has offered zero justification of how or why that is desirable or how it is compatible with WP:CLEANUPTAG. BrownHairedGirl (talk) • (contribs) 20:09, 16 December 2021 (UTC)
PS @Xaosflux: to simplify matters, please look at the diff[5] of the contested edit.
Was it appropriate to have the {{Cleanup bare URLs}} banner on that page as it then stood?
I say it would have been clearly wrong to retain that banner, and that the bot correctly removed it. What say you? BrownHairedGirl (talk) • (contribs) 20:15, 16 December 2021 (UTC)
I don't want perfection to get in the way of good; in this case there actually is a "bare url", having the page tagged as having a bad url seems appropriate, it is usually hard to determine the motivations of some editors - and it is also possible that whomever added the better sources tag is overruled, perhaps the source is a good enough source already. As to the perfection argument - this is garbage in garbage out, as the editor that added that tag inside the ref added "garbage". Do we have any feeling for how prevalent this type of edge case is? — xaosflux Talk 20:49, 16 December 2021 (UTC)
@Xaosflux: I am sorry to say that the declining of this bot request is not even a case of perfection to getting in the way of good. It is a case of narrow pedantry missing the point of the banner template, and demanding that the bad triumphs over the good. Face-sad.svg
Cleanup tags are not a scientific classification system. They are an invitation to editors to fix a problem, and the guidance at WP:CLEANUPTAG is very clear that we should focus on the actual problem: "If an article has many problems, tag only the highest priority issues", and "Don't insert tags that are similar or redundant".
In this case, the {{Cleanup bare URLs}} banner is redundant to the {{better source needed}} tag, because the priority is to replace the ref, not to fill it.
In fact, far from tagging that IMDB ref as bare and in need of filing (as Headbomb wants), it would be much better to have an opposite tag: one which says "this ref is a bare URL, but for god's sake don't waste your time filing it".
It may be that in some cases {{better source needed}} may be applied inappropriately, but that applies to any cleanup tag. I think this bot should act on the assumption that the {{better source needed}} tag has been reasonably applied, as it has clearly been in this case.
I would not object to the IMDB ref being tagged with a {{Bare URL inline}} tag; superfluous, but not harmful. However, we really do not need a a big fill-the-ref banner at the top of the page for a single bare ref which should NOT be filled.
I did a quick scope check. {{better source needed}} has 15,127 transclusions. Of those, 117 are inside the <ref>...</ref> tags. That's 0.77%.
So this bot has been declined because of Headbomb's desire that less than 1% of the pages should retain a banner which WP:CLEANUPTAG tells us doesn't belong there. Bizarre. BrownHairedGirl (talk) • (contribs) 21:19, 16 December 2021 (UTC)
Your summary of dumb-as-a-brick-no-context-mindless-automaton mischaracterizes what Headbomb said. He is characterizing the bot as such an automaton, not the proposed bot operator. I've only just gotten to this line, so there may be other merit to the OP. --Izno (talk) 19:10, 16 December 2021 (UTC)
@Izno: Headbomb may be referring to the bot, but by extension that is an attack on the bot-owner who programmed it.
Such pejorative language is inflammatory and uncivil. Even if Headbomb was referring to the bot, it's a pointless comment, because every bot is an automaton. If being an automaton is grounds for rejecting a bot, we should shut down all bots.
And this bot is clearly not dumb-as-brick". It includes (in step 5) a deep layer of sophistication which I think is superfluous and which no other commenter at BRFA wanted, but which I added at Headbomb's request.
I strongly object to the fact that Headbomb used this BATTLEGROUND language, and then accused me of having a BATTLEGROUND mentality. BrownHairedGirl (talk) • (contribs) 19:23, 16 December 2021 (UTC)
I think you're seeing intent there that doesn't exist as, since you agree, it is more or less a statement of fact to call it a no-context-mindless automaton. I won't comment too much more on the one point. Izno (talk) 19:32, 16 December 2021 (UTC)
@Izno: that comment was at best redundant, and the hyperbolic hostile terminology does not belong in a civil discourse. BrownHairedGirl (talk) • (contribs) 21:56, 16 December 2021 (UTC)
  • My take from reading that entire BRFA: Bot as written will remove bare urls - including ones which are valid but other issues apply (eg better source required). Despite going over these issues over an extended period of time (the comment from Headbomb as to the bot's mindlessness is entirely appropriate given the context of the discussion and the point at which it was made), bot operator is not interested in altering bot to accomodate this and cannot demonstrate consensus for the task. Absent any community consensus for the automated task, bot not approved.
Even given my repeated and extensive criticism of BAG's lax attitude to BOT oversight (I doubt I am on any of their christmas cards lists), I cant find any fault here bar perhaps Headbomb's techyness after going round in circles. To be blunt BHG, you failed to both understand and take note of issues which were explained a number of times and in different ways and repeatedly kept pressing for a resolution (to let you do what you want) without substantively addressing them. Asking for an answer repeatedly after being given an answer is enough to try anyone's patience. You were given a way forward: demonstrate with a clear RFC at an appropriate venue that the task should go ahead. Perhaps you should try that, because absent consensus to perform the task *with its shortcomings clearly explained* the decision is the correct one. Only in death does duty end (talk) 09:52, 17 December 2021 (UTC)
@Only in death: on the contrary, I understand the issues very well and have taken full note of them.
In a nutshell: the bot does have a glitch which remove the {{Cleanup bare URLs}} banner from a small number of pages which do have a bare URL. On that we all agree.
But the crucial point which most commentators here (including yourself) overlook, in every such case, the URL in question is also tagged with a more specific and appropriate tag. Therefore, per WP:CLEANUPTAG, the big banner tag at the top is superfluous ... and the glitch is not just a non-problem, it's a helpful (tho unintended) bonus.
Since that is existing, stable, guidance, no RFC is required. Consensus is demonstrated by WP:CLEANUPTAG's bolded guidance:
  • "If an article has many problems, tag only the highest priority issues"
  • "Don't insert tags that are similar or redundant"
So I'll ask you the same two question as I have asked others:
  1. how does it help editors to have at the top of the page a big banner message saying that refs should be filled, when the actual action needed is that the ref should be removed or replaced? That banner is telling editors to fill an ref before removing it
  2. How is such a banner compatible with WP:CLEANUPTAG? BrownHairedGirl (talk) • (contribs) 17:26, 17 December 2021 (UTC)
Or you could take the advice you have been given. As it stands you are either unable to understand your problem, or you are deliberately engaging in sealioning in order to wear people out. We are well past the point where having a discussion with you is productive, and I am uninterested in re-running a BRFA (here) where people with greater knowledge than you and more patience than me have devoted more than a reasonable amount of time to discussing this with you. Suffice to say, unless you make changes to address the issues, or gain some community consensus to perform the automated task despite its shortcomings, you are not going to get the result you want. This could have been resolved months ago and you know what you have to do. Only in death does duty end (talk) 19:04, 17 December 2021 (UTC)
@Only in death: that is a very arrogant and uncivil response.
I have demonstrated a clear understanding of the problem, and have asked you to explain your position on it. Sadly you have chosen not address the substance, but to attack me for asking that you address the core issue: that in my view, the existing guidance at WP:CLEANUPTAG supports the bots actions, which is evidence of consensus.
Your dismissal of that simple question is very poor conduct, and your choice to criticise me for asking it is even worse. It seems from your response so far that you are wholly uninterested in the existing guidance, and are concerned only to support a colleague. I hope you will correct that impression. BrownHairedGirl (talk) • (contribs) 19:14, 17 December 2021 (UTC)
So sealioning it is then. Good luck in your endevours. I will significantly oppose any bot request you now put forward unless you can clearly demonstrate community consensus for the task. Only in death does duty end (talk) 19:31, 17 December 2021 (UTC)
@Only in death: wow!
You adamantly refuse to answer the simple question of why I should seek an RFC for a side-effect which is supported by existing guidance, and which in any case effects only a trivial number of articles.
And you follow that up with a promise of ongoing prejudice against me: that your grudge at being asked a simple, civil question is enough for you to promise ongoing hostility. That is WP:BATTLEGROUND conduct taken to an extreme. BrownHairedGirl (talk) • (contribs) 19:58, 17 December 2021 (UTC)
  • If it was easy to code for these exceptions, I would have sighed and done the coding, and accepted a few un-needed skips. However, it's actually quite a complex bit of coding (a monster regex to include a dozen template names and all their many redirects), which will be error-prone and not transparent.
Correct me if I am wrong, but it seems to me the basic problem is one of design/flow logic. The current design matches bare URLs fairly strictly, and then does an action only if URLs were not matched, which results in people getting potentially angry because actions are taken too liberally. Accepting to over-match bare URLs, and therefore under-remove tags, would be the obvious option.
How about accepting as bare URLs stuff that is tagged with any template? I suppose in the regex <ref[^>]*?>\s*\[?\s*https?:[^>< \|\[\]]+\s*\]?\s*<\s*/\s*ref, this can be done by replacing the bolded part: \s* → ({{.*}}|\s)*. (Not tested, possibly there is some greedy match issue etc. etc. but even as a regex newbie I feel this can be done). Surely this would cause false positives (i.e. non-bare URLs that are considered bare), but I speculate it would still cause very few cases to not be detagged by the bot.
The only comment I will make about how the BRFA played out is that there are two very stubborn people and it would not be very productive to try to assess who is the stubbornest and by how much. (Unless my proposal above is insufficient for some reason obvious to both of those people, I see them missing it as strong evidence of my "stubborn" assessment.) TigraanClick here for my talk page ("private" contact) 14:40, 17 December 2021 (UTC)
I think that the approach here of trying to parse wikitext is a bit backwards. The better solution would be to grab the parsed page (via the API action=parse, for example) and look for /(?<!href=")https?:\/\//. Of course, that would require a little more coding knowledge that just plugging a regex into AWB. --Ahecht (TALK
PAGE) 15:46, 17 December 2021 (UTC)
@Ahecht: parsing wikitext is AFAIK the only option available to an AWB module.
I someone wants to code a bot for this task in some other language or framework, then good luck. BrownHairedGirl (talk) • (contribs) 17:33, 17 December 2021 (UTC)
@Tigraan: the reason for not ignoring any template inside the <ref>...</ref> tags is that one template inside the ref tags is a valid reason for not treating the URL as bare for the purposes : {{Dead link}}. That is because it would be absurd to ask editors to fill a link which is dead.
I explained this several times in the BRFA. BrownHairedGirl (talk) • (contribs) 17:30, 17 December 2021 (UTC)
Still requires human judgement. If an archive is available (on web.archive.org or archive.is, for example) then it wouldn't be absurd to ask editors to fill a link which is dead. ProcrastinatingReader (talk) 21:34, 17 December 2021 (UTC)
@ProcrastinatingReader: if a suitable archived copy is found, then of course the the ref should be filled. But unless and until the archive is found, it cannot be filled.
So if a bare URL tagged as dead, the first step is to find an archive. So adding a "bare URL" tag to a tagged dead link is redundant ... and that is just the sort of issue covered by WP:CLEANUPTAG's guidance "Don't insert tags that are similar or redundant" and "If an article has many problems, tag only the highest priority issues".
I find it frustrating and depressing to have to repeatedly draw the attention of BAG members to existing guidance which they seem determined to ignore. BrownHairedGirl (talk) • (contribs) 22:21, 17 December 2021 (UTC)
Retrieved from "https://wiki.tachyony.co.uk/w/index.php?title=Wikipedia:Bots/Noticeboard&oldid=4523"