Wikipedia:Bots/Noticeboard/Archive 19

Add links
From Wikipedia, the free encyclopedia
Archive 15 ← Archive 17 Archive 18 Archive 19

Flooding watchlists

Kanashimi has had a procession of editors turn up to his talk page to complain that his bot's edits are flooding their watchlists. They have all chosen to override the default setting that hides bot edits. Do people think these complaints are reasonable or unreasonable? Is there any guidance on what speed bots should edit at? Is there anything useful we can say to these people? Thanks — Martin (MSGJ · talk) 15:15, 10 January 2024 (UTC)

Umm, if you opt-out of the default "hide: bots" on your watchlist preferences, you don't really get to complain that there are bot edits all over your watchlist. — xaosflux Talk 15:24, 10 January 2024 (UTC)
They can of course still raise other issues - such as if they think the bot is operating outside of its approval, the bot is making bad edits, etc. They also could raise a point that the task is useless and should be deauthorized. The argument of people who say this bots non-article edits are interfering with their ability to view bot changes to articles can simply select the ns:0 filter on their watchlist as well. — xaosflux Talk 15:29, 10 January 2024 (UTC)
This time the bot's editing namespace is talk, so I had suggested that the talk page could be filtered out. Kanashimi (talk) 22:05, 10 January 2024 (UTC)
I don't think that's a fair characterisation of the edits to the botop's usertalk, many of which are pointing out errors and helping to debug the bot, not just complaining about its activity. I didn't expand every thread, but most seem to be constructive. Folly Mox (talk) 01:37, 11 January 2024 (UTC)
Agreed. Kanashimi is very good about responding (positively and quickly) to feedback about the bot not operating as intended. Those who are pissed off about watchlists have already been told how to deal with it. Primefac (talk) 08:22, 11 January 2024 (UTC)
I'm not talking about the constructive posts. I am just talking about the complaints that his bot's edits are flooding their watchlists — Martin (MSGJ · talk) 10:07, 11 January 2024 (UTC)
The current wording of WP:BOTPERF suggests that non-urgent tasks should be capped at 6epm and urgent tasks capped at 12epm; if CewBot is holding to within those values, then their complaints are unreasonable. If the bot is exceeding those rates then it should be ramped down slightly. Primefac (talk) 10:21, 11 January 2024 (UTC)
Thanks. This task is certainly not urgent, so 6epm seems reasonable. The only problem is that the task will probably take over a year to complete at that speed! Perhaps when the bot gets off the vital articles and onto the more obscure articles, it could be allowed to speed up a bit? — Martin (MSGJ · talk) 10:27, 11 January 2024 (UTC)
Likely, as they are going to be less-watched pages. Primefac (talk) 10:29, 11 January 2024 (UTC)
Why is it a problem if this task takes a year to complete? All it is doing is rearranging talk page banners. It is not urgent. —David Eppstein (talk) 01:12, 15 January 2024 (UTC)
I think one of the problems is that a year here is already an unacceptable speed for you. It would probably take several times as long to get to your acceptable speed. So I think we may have to think of other ways to solve similar problems to achieve a solution that you can understand or accept. Kanashimi (talk) 01:24, 15 January 2024 (UTC)
I also don't think it's particularly charitable to characterise as unreasonable complaints about watchlist flooding just because Cewbot is operating within the rate limits specified by WP:BOTPERF, which doesn't seem like it was written with the idea in mind of a single bot task making edits to n million different pages, with the activation on any given page due merely to BRFA approval, where even a conservative estimate for n would seem to place it as greater than 2.
I said at a recent ANI that I'm not having a problem ignoring Cewbot, but for people with watchlists in the thousands or tens of thousands, I could see it being a serious issue, and I sympathise with their concerns.
For clarity, I have no particular opposition to this task, although I do think that our model of content assessment is not useful enough to necessitate making so many edits. Does anyone have a good idea of the total number of pages affected? There's none listed at the BRFA, nor the PIQA RFC, nor the initial implementation discussion, and {{PAGESINNAMESPACE:1}} is disabled for performance reasons. Folly Mox (talk) 20:00, 13 January 2024 (UTC)
For those who do want to hide Cewbot edits, see my post of 13:51, 13 January 2024 (UTC) below; or, if you don't want to work it out, put this CSS rule 
/* hide edits by Cewbot */
li.mw-changeslist-bot:has(a[href="/wiki/User:Cewbot"]) {
  display: none;
}
into Special:MyPage/common.css. --Redrose64 🌹 (talk) 21:27, 13 January 2024 (UTC)
I finally grew weary of sorting through these bot edits and added the css rule to my css. For me, because I have the 'Expand watchlist to show all changes' and 'Use non-JavaScript interface' options checked at Special:Preferences#mw-prefsection-watchlist, I had to change the rule to be:
/* hide edits by Cewbot */
table.mw-changeslist-bot:has(a[href="/wiki/User:Cewbot"]) {
  display: none;
}
The code editor complains that it expects an RPAREN at column 28 (for li.mw-changeslist-bot:has(a[href="/wiki/User:Cewbot"])) or column 31 (for table.mw-changeslist-bot:has(a[href="/wiki/User:Cewbot"])). Saved the edit anyway and the rule hides these bot edits.
—Trappist the monk (talk) 13:11, 24 January 2024 (UTC)
At this edit, Editor Qwerfjkl's bot made an edit that would not have shown up on my watchlist because I have a css rule for Qwerfjkl (bot). But then, in a separate edit 16 minutes later, Qwerfjkl (bot) returned to the talk page to delete one line of whitespace. I am making this post to note that for those (probably few) editors like me who use a non-standard form of watchlist, the css rule above won't hide all of a named bot's edits. Were both of Qwerfjkl (bot)'s edits justified, I would have no problem with the occasional appearance in my watchlist but that second edit was surely wholly unnecessary. Editor Qwerfjkl, please fix your bot: don't make a cosmetic edit to fix what should have been fixed in the first place.
—Trappist the monk (talk) 16:12, 24 January 2024 (UTC)
Trappist the monk, it's a minor bug from duplicating the job on Toolforge, so it ran on the page twice. It shouldn't be a problem any more. — Qwerfjkltalk 17:12, 24 January 2024 (UTC)
Looks like the job was still running, so I manually killed it (if anyone's curious the jobs can be seen here). — Qwerfjkltalk 17:32, 24 January 2024 (UTC)
@Trappist the monk: I also have those two options enabled, I think that the reason that you needed to use table instead of li is because at Preferences → Recent changes, you have "Group changes by page in recent changes and watchlist" enabled, whereas I don't. The problem with that is that if there have been multiple edits to the page within the same day, and you expand the row to show the individual edits, the Cewbot edits are not hidden. Try this rule, which has a more comprehensive selector list: 
/* hide edits by Cewbot */
li.mw-changeslist-bot:has(a[href="/wiki/User:Cewbot"]),
table.mw-changeslist-bot:has(a[href="/wiki/User:Cewbot"]),
tr.mw-changeslist-bot:has(a[href="/wiki/User:Cewbot"]) {
  display: none;
}
It is independent of the pref setting that I just mentioned. You can test this out on Talk:Yemeni civil war (2014–present) for 12 January. --Redrose64 🌹 (talk) 21:31, 24 January 2024 (UTC)
Thank you. I thought about doing that but decided that I wouldn't bother after Editor Qwerfjkl reported that the minor bug...shouldn't be a problem any more. If it is still a problem, I'll change my css to use your selector list.
—Trappist the monk (talk) 00:15, 25 January 2024 (UTC)

Here now after Cewbot has once again ramped up these unimportant edits to unacceptable levels, filling my watchlist with hundreds of them to the point where nothing else is visible.

I have repeatedly asked on Cewbot's talk for a slowdown, only to be met with either a very temporary slowdown that is ramped up again as soon as I seem to have stopped paying attention, or demands that I stop watching Cewbot's edits. I do not want to stop watching Cewbot's edits. I do not trust bots to be so perfect that their edits can escape scrutiny. I want the edits to be at a level where I can watch them and spot-check that they remain ok.

Please shut down this antisocial bot behavior. —David Eppstein (talk) 01:11, 15 January 2024 (UTC)

@Kanashimi: why is your bot editing at 40+ edits/min? Galobtter (talk) 02:06, 15 January 2024 (UTC)
Certainly I don't see any reason not to limit 6 edits/minute for vital articles and 12 edits/minute for the rest of the task which would minimize watchlist spam. Galobtter (talk) 02:13, 15 January 2024 (UTC)
I changed it to follow maxlag=5 when I ran one of my tasks, and I haven't gotten it back yet. I'm sorry I may have to wait until the end of work today to get it back. The vital article part is now complete. However, my previous setting of 12 edits per minute caused this problem. The 12 edits per minute does not solve the watchlist problem. So I'm afraid we need a better solution. Kanashimi (talk) 02:27, 15 January 2024 (UTC)
Has the bot done non-vital articles at 12 epm (rather than 40 epm, which is obviously going to cause complaints)? Presumably those articles are much less watchlisted so there should be less complaints with 12 epm + non-vital articles.
The problem here might be that the bot is going through the articles wikiproject by wikiproject (right now it seems to be doing {{WikiProject Anglicanism}}). So someone who has all the articles in that watchlisted is going to be really annoyed. Some back of the envelope math suggests that at 12 epm the bot will edit 12 * 60 * 24 = 17280 pages per day, and if there are if there are 4 million articles to do, that means that ~0.4% of those articles are going to be edited every day. If someone has 10000 articles watchlisted, that's an average of 40 edits per day on their watchlist, which probably wouldn't result in too much complaints. A sufficiently randomized way of picking articles to edit would probably help. Galobtter (talk) 02:52, 15 January 2024 (UTC)
OK. I'll start with User:Qwerfjkl's strategy of traversing all pages. It looks like his strategy won't cause complaints even in high speed. I am curious to know if his strategy is feasible, we may be able to complete the assignment within six months. Kanashimi (talk) 03:32, 15 January 2024 (UTC)
@David Eppstein: If you don't want to hide them entirely, you can make then distinguishable at a glance so that you can skip over them. Two suggestions: (i) make the text smaller: 
/* make edits by Cewbot smaller */
li.mw-changeslist-bot:has(a[href="/wiki/User:Cewbot"]) {
  font-size: 75%;
}
(ii) change the background: 
/* make edits by Cewbot grey background */
li.mw-changeslist-bot:has(a[href="/wiki/User:Cewbot"]) {
  background-color: #eeeeee;
}
these CSS rules go in Special:MyPage/common.css. --Redrose64 🌹 (talk) 15:18, 15 January 2024 (UTC)

Would/Should it be possible to hide/show the edits of specific bots?

The above is a concern that arises periodically, often because of mass edits by a useful but very noisy bot. Changes to Wikimedia code, HTML standards, guidelines, or policies will occasionally mean that millions of pages need to be modified. That's just a fact of life on Wikipedia. I was wondering how we might thread this Watchlist needle, allowing editors to monitor bot edits but avoid excessive noise, or hide bot edits but follow the edits of one or two bots that concern them. It occurred to me that it would be useful for editors to be able to explicitly include or exclude the edits of specific bots in their Watchlist. For example, I want to hide all bot edits, but I want to see all edits by FooBOT, or I want to see all bot edits, but exclude all edits by BarBOT and BazBOT.

Has this option been explored in any of the discussions where WMF developers solicit ideas for technical feature requests? I used to participate in those, but my niche ideas never got any traction, so I burned out on them. (Aside: I'm still hoping for a Watchlist that groups all edits by page without regard to calendar days, but that doesn't seem to bother enough people.) – Jonesey95 (talk) 23:31, 11 January 2024 (UTC)

@Jonesey95: looks like a combination of phab:T2470 and phab:T159192. — xaosflux Talk 00:01, 12 January 2024 (UTC)
Yes, that second one looks like a pretty good summary of the above. It was proposed in 2016, so it should be almost ready for deployment, right? – Jonesey95 (talk) 00:20, 12 January 2024 (UTC)
Ah, you wish. Someone has to do the work, or otherwise the task just languished in the backlog forever, as has happened to both of those. * Pppery * it has begun... 00:59, 12 January 2024 (UTC)
I think that was a rhetorical question :D – SD0001 (talk) 01:53, 13 January 2024 (UTC)
It should be possible to hide specific bots using CSS. Someone should document this at Wikipedia:Bots#How to hide a specific bot from your watchlist. The existing instructions are heavily outdated – it suggests a user script that hasn't been updated in a decade so it would be very surprising if it still works. Even if it does, it's only supposed to work with the no-JS watchlist. – SD0001 (talk) 01:53, 13 January 2024 (UTC)
@Jonesey95: If your browser has implemented the relational pseudo-class, ':has()', you can hide the entire list entry (row) using CSS. Let's assume that you want to hide edits by Legobot and Qwerfjkl (bot), but leave all other bot edits visible: the CSS rule would be 
/* hide edits by Legobot and Qwerfjkl (bot) */
li.mw-changeslist-bot:has(a[href="/wiki/User:Legobot"]),
li.mw-changeslist-bot:has(a[href="/wiki/User:Qwerfjkl_(bot)"]) {
  display: none;
}
This goes in Special:MyPage/common.css, because it works in all current skins. It operates on Special:Watchlist and Special:RecentChanges but is ignored by user contributions and page history. --Redrose64 🌹 (talk) 13:51, 13 January 2024 (UTC)
I haven't tried it, but it looks like that would hide a row that contained both a human edit and an edit by the specified bot. I don't want that. – Jonesey95 (talk) 14:59, 13 January 2024 (UTC)
The .mw-changeslist-bot class selector makes sure that only bot edits are selected. The equivalent for non-bot edits would be .mw-changeslist-human. --Redrose64 🌹 (talk) 17:25, 13 January 2024 (UTC)
There's also WP:HIDEBOT Headbomb {t · c · p · b} 21:38, 13 January 2024 (UTC)
Headbomb, The existing instructions are heavily outdated – it suggests a user script that hasn't been updated in a decade so it would be very surprising if it still works. Even if it does, it's only supposed to work with the no-JS watchlist.— Qwerfjkltalk 21:52, 13 January 2024 (UTC)
It still works. Feel free to update/supplement the instructions for the JS watchlists. Headbomb {t · c · p · b} 21:56, 13 January 2024 (UTC)
Can this particular bot task (changing every talk page on the site to add the "banner shell" template) be given a new "tag", so that it can be expressly filtered out in watchlists? –jacobolus (t) 09:07, 17 January 2024 (UTC)

WP becomes more complex daily on a linear curve with no end in sight. This is due to 1. more articles 2. longer articles 3. more template varieties. Meanwhile, the number of experienced editors remains static. As such, we need to lean more on bots. These two factors - increased complexity, more bots - means watchlists will see increasing levels of bot activity, and increasing irritation at bots. This later phenomenon will discourage bot authors, resulting in fewer bots. Meanwhile, WP becomes more complex daily.. (repeat this cycle). -- GreenC 03:48, 15 January 2024 (UTC)

Personally I find the large number of bots making masses of mostly unnecessary (often incorrect and/or directly contrary to human editors' preferences) edits to be one of the least pleasant parts of Wikipedia. Have you considered that the bots may be reducing the capacity of experienced editors by wasting their time on nonsense? –jacobolus (t) 09:04, 17 January 2024 (UTC)
If a bot is making edits that are incorrect and/or directly contrary to human editors' preferences then it should be brought here for review. What you view as unnecessary, however, does not necessarily fall into that category. Primefac (talk) 09:10, 17 January 2024 (UTC)
Bringing any bot task to this noticeboard for review is a pretty major step, and requires previous talkpage communication. Not well suited to edge cases, especially for popular scripts with broad remit. Sometimes all that's really required is to stop a bot from editing a particular page or even just a portion thereof. It would be nice if all bots (and edit-publishing userscripts activated manually) that have unlimited scope (rather than a closed set of pages put forth in the BRFA) were required to be exclusion compliant. Right now WP:BOTCONFIG only states that they can be. It's really dispiriting to edit war with a bot that doesn't know what it's doing wrong, and not every edge case requires a patch. Folly Mox (talk) 14:03, 17 January 2024 (UTC)

Tag discussion

I think @Jacobolus raises an interesting point above. An admin can create a specific tag for this via Special:Tags and if the bot applies the tag to its edits, it can be used as a filter for users to omit them from watchlists. Bots already have the permissions to tag edits. – SD0001 (talk) 14:22, 17 January 2024 (UTC)
SD0001, if an admin creates a tag I am happy to apply it. — Qwerfjkltalk 14:40, 17 January 2024 (UTC)
We certainly don't want a tag for every bot; but if there is a general very high volume task, especially one used by multiple bots, we could (something like "lintcleaning" perhaps. I would not want to see "and also use a tag" become a requirement for any bot task, but could be used opt-in by an operator. — xaosflux Talk 14:56, 17 January 2024 (UTC)
We're just talking about this single specific action of adding a "banner shell" to every talk page on the site, which is going to be millions of edits flooding every watchlist for an extended period of time (above I saw estimates of a year). This is a different situation than other kinds of bot edits. –jacobolus (t) 15:16, 17 January 2024 (UTC)
👆🏽 Agree with this. Bots making a million or more edits across an equal amount of pages should be open to different treatment, without any special measures taken needing to apply to all bots in general. Folly Mox (talk) 16:30, 17 January 2024 (UTC)
Watchlist flooding isn't going to be well fixed with TAGS, as tag filter isn't part of watchlist. — xaosflux Talk 16:51, 17 January 2024 (UTC)
I don't understand what you mean. If I go to Special:Watchlist there is a long list of filters which can be applied, with the various "tags" among them. Each filter applies to some subset of edits, and can be applied either directly or negated to either show only those edits matching the filter or to exclude edits matching the filter. If all of the "adding a banner shell" edits had a specific tag, then this tag could be excluded from the watchlist, and someone like @David Eppstein who has many thousands of watched pages and keeps an eye on other kinds of bot edits could conceivably continue doing his work without being overwhelmed by a flood of trivial talk-banner twiddles. –jacobolus (t) 17:22, 17 January 2024 (UTC)
Oops, sorry forgot about the several different ways WL can be laid out. Not sure "put a template on a talk page" is really tag-worthy though? — xaosflux Talk 17:44, 17 January 2024 (UTC)
This is the single most tag-worthy subject of the immediate future, if it's going to involve literally millions of edits. –jacobolus (t) 18:37, 17 January 2024 (UTC)
@Jacobolus seems ok enough I suppose - got a good "short tag" name and a description? It shouldn't be "bot x's edit" it should be something about the change or how the change was made that ideally could be reused by others. It may link to a description page with more info (such as a list of bots). Bot ops would need to ensure to only use the tag for that sort of edit, not for other kinds of edits their bot may be making. — xaosflux Talk 23:23, 17 January 2024 (UTC)
"Audited mass edit" or "trusted mass edit"? Kanashimi (talk) 23:32, 17 January 2024 (UTC)
@Kanashimi that's too generic. That's like saying "bot edit" and any bot might use that - and filter by bots is already native. — xaosflux Talk 23:35, 17 January 2024 (UTC)
I would recommend something along the lines of "talk banner shell conversion". –jacobolus (t) 23:42, 17 January 2024 (UTC)
@Xaosflux: At Preferences → Watchlist, you need to disable "Use non-JavaScript interface" in order to filter with tags. --Redrose64 🌹 (talk) 22:09, 17 January 2024 (UTC)
Yup, realized that too late, thought it was just my skin and checked another project, but forgot I had that off in global prefs. — xaosflux Talk 23:23, 17 January 2024 (UTC)
@Qwerfjkl: I'll be happy to create a tag for you for this task. Just tell me the values (tag name, "appearance on change lists" name, and description) you want. Anomie⚔ 22:21, 17 January 2024 (UTC)
Anomie, as jacobolus said above, "talk banner shell conversion" sounds good to me, probably with a link to WP:PIQA. — Qwerfjkltalk 07:15, 18 January 2024 (UTC)
I would be in favour of a short tag, maybe even just "WP:PIQA", since that is what the bots are doing. Primefac (talk) 12:19, 18 January 2024 (UTC)
Tag created. The visible text can be updated at MediaWiki:Tag-talk banner shell conversion by any admin. Anomie⚔ 12:30, 18 January 2024 (UTC)
All my bot edits will now be tagged with this tag. — Qwerfjkltalk 16:28, 18 January 2024 (UTC)

User script

FWIW I've written a user script to deal with this problem: User:Nardog/RCMuter. It just hides specific users' edits so it won't completely help if a bot inundates your watchlist so much you can't see older edits, but in most situations it helps. Nardog (talk) 23:30, 17 January 2024 (UTC)
I think options like that may not fix the other "a bot flooded my watchlist" problems though? If your WL is 100 items, and 50 are bots, well - you are just going to have 50 items now. Also the problem of the bot will be the most recent edit and "obscure" an edit before it -- as this is being done client side. — xaosflux Talk 23:37, 17 January 2024 (UTC)
That's pretty much what I said. A feature to mute users sever-side would be nice, but while that's not available, the script can be a band-aid to it. Nardog (talk) 01:31, 18 January 2024 (UTC)
@Nardog i installed it last week but couldn’t find out how to configure it. I probably overlooked something obvious. Doug Weller talk 20:25, 19 January 2024 (UTC)
@Doug Weller: On watchlist or recent changes, click "Edit muted" below the top heading and enter the name of a user you want to mute, or click "Show toggle buttons" and click "mute" next to the name of a user you want to mute. Nardog (talk) 17:57, 20 January 2024 (UTC)
@Nardog thanks. I’ll do that. Doug Weller talk 20:28, 20 January 2024 (UTC)

the problem of the bot will be the most recent edit and "obscure" an edit before it -- as this is being done client side

That problem exists even if the filtering is server-side (phab:T11790). – SD0001 (talk) 06:21, 20 January 2024 (UTC)

A decentralized approach to solve the watchlist problem

User:Qwerfjkl and I worked together on this task, but it was only my robot that was causing the problem. Qwerfjkl's strategy was to edit the articles in alphabetical order. I observed user:Qwerfjkl (bot)'s editing, and realized that this method doesn't seem to be a problem for users, even when only maxlag is observed. I think the reason for this is the method of distributing the topics. When a specific topic is dealt with intensively, it is easy to cause disturbance to users who are concerned about the specific area. Qwerfjkl's strategy is better than mine, so I'm going to use alphabetical order for the rest of my work. I suspect that if I just follow maxlag, I might be able to complete the job in less than six months. At 12 edits per minute, it might take more than a year. So my question is, since he has demonstrated that following only maxlag doesn't seem to be a problem for users when using alphabetical order, can this strategy be continued, or do we all have to limit ourselves to 12 edits per minute? --Kanashimi (talk) 04:56, 15 January 2024 (UTC)

@Kanashimi: I agree with the alphabetical order strategy. WP:BOTPERF states "bots doing non-urgent tasks may edit approximately once every ten seconds, while bots doing more urgent tasks may edit approximately once every five seconds." This doesn't seem to be an urgent task. GoingBatty (talk) 05:20, 15 January 2024 (UTC)
That seems like a good idea, like what I was saying above. Would it really take a year with two bots running at 12epm? (4M pages is 231 days at 12epm, half that if there are two bots running). I definitely don’t see the rush for 40epm - there’s no rush here. Galobtter (talk) 15:47, 15 January 2024 (UTC)
@GalobtterI've changed it back to 12 edits per minute, please help me unblock the bot, thank you. However you can see user:Qwerfjkl (bot)'s edits. I think my bot may run in the same algorithm and the same speed. isn't it? --Kanashimi (talk) 21:46, 15 January 2024 (UTC)
@Galobtter Since I borrowed user:Qwerfjkl (bot)'s algorithm for alphabetical order instead, and he has proven it to be a sustainable editing speed, I will follow his editing speed. If you think this is unreasonable, please tell me again if only my bot should slow down, or if we both should follow the same rules. Also, I've structured the bot stopping mechanism so that I don't have the problem of not being able to stop the bot manually. Please let me know if you need me to stop the robot at any time, thank you. Kanashimi (talk) 23:18, 16 January 2024 (UTC)

Randomize

If the bot would form a list of all the pages it wants to get to eventually (all article talk pages, potentially?) and then randomized that list, so that it wasn't hitting all of one Wikiproject -- or all of one topic area, or all of one anything -- in a given hour or day, I doubt anyone would notice this at all. Problem solved. EEng 15:28, 18 January 2024 (UTC)

I've suggested this at bots' individual talk pages, but since there's more visibility here, I'll try again:
Another alternative that would make the edits truly close to zero disruption would be to only do one of these bot edits along immediately after any other edit to the same page, e.g. when someone makes a talk-page comment. I'd call this the "piggyback method". This would have the effect of naturally matching the ordinary edit rate of each talk page (many of which are extremely low, on the order of 1 new topic per year) so there would be no unusually high watchlist activity for any human editor, and, moreover, these edits would "fold" together, not taking up any extra space on watchlists. After handling every popular page via this piggyback method, the the remaining long-tail cleanup of pages that haven't been edited within, say, 6 months could be randomized and finished off at whatever arbitrary speed over X months after that – there shouldn't be any urgency for such pages with demonstrably extremely low view/edit rate, as nobody is going to see what kind of banners they have anyway.
This project seems high-impact enough – if it is truly going to take months or even years to finish, touching millions of pages – that it would be worth putting some extra effort up front into bot programming to reduce the impact on human editors. If the current bots' authors don't know how to implement a scheduling system based on watching for other user edits, perhaps other bot authors following along here could offer technical assistance? –jacobolus (t) 15:52, 18 January 2024 (UTC)
I wonder whether the "piggyback method" would result in complaints related to phab:T11790. Anomie⚔ 22:38, 18 January 2024 (UTC)
Oh yikes, that seems like a pretty serious bug! I've been watching all bot edits for a while, but for other people's sake I hope that can be fixed ASAP. –jacobolus (t) 00:08, 19 January 2024 (UTC)
It has been open since 2007, so I wouldn't count on it being fixed any time soon. Anomie⚔ 01:39, 19 January 2024 (UTC)
Indeed; same with the reverse direction. Primefac (talk) 09:46, 19 January 2024 (UTC)
That sort of piggybacking would have a negative effect. If I'm looking at my watchlist, and I see there was an edit by some not-addressing-an-immediate-edit bot (i.e., not a "that user forgot to put their signature on their talk page message"-type bot) on an infrequently-edited talk page, my first reaction will not be "oh, I better check if there was a non-bot edit just before that". It will be that I don't have to check that page, that it was just a bot edit, and thus I will miss the talk page comment. -- Nat Gertler (talk) 16:41, 22 January 2024 (UTC)
The order of one of the bots was recently switched to alphabetical, which should introduce a lot of randomness, except for maybe some unlucky ranges such as years. Has the randomness been a problem within the last couple of days, after this switch was made? Or is it possible the problem is already solved? –Novem Linguae (talk) 15:58, 18 January 2024 (UTC)
WP:Tree of life pages/participants would also be adversely affected by an alphasort (not me, just fyi), where many <genus> <species> articles exist for a particular <genus>.   ~ Tom.Reding (talk ⋅dgaf)  16:10, 18 January 2024 (UTC)
For that very reason, I wrote Module:Sandbox/trappist the monk/random sort to randomize article title lists (an example of its use is shown in Module talk:Sandbox/trappist the monk/random sort). Didn't really help, Monkbot/task 18 still got shutdown.
—Trappist the monk (talk) 16:57, 18 January 2024 (UTC)
If anyone knows an efficient way to do this then I'm more than happy to. I assume it wouldn't be a good idea to spam api calls for this, though. — Qwerfjkltalk 16:30, 18 January 2024 (UTC)
Whatever way & rate Listen to Wikipedia is using is probably sustainable. I'd be interested to hear the output with a piggyback bot running too (I image it grabbing recent changes every X seconds, then repeating them).   ~ Tom.Reding (talk ⋅dgaf)  16:50, 18 January 2024 (UTC)
Tom.Reding, it looks like that looks at recent changes. I'm also not sure piggybacking would work, as it would require me to track which pages need editing and which don't (to say nothing of the other practicalities). — Qwerfjkltalk 17:13, 18 January 2024 (UTC)
@Qwerfjkl you need (1) a list of all pages that haven't had their banners "fixed" yet (initially all article talk pages on the site), and (2) a running feed of recent changes to article talk pages. At any particular time, you compare each new incoming talk-page change to list 1, and if the page is not on the list you ignore it, while if it is on the list you trigger the bot to do the banner update then remove that page from list 1. If the bot arrives at the page to do the banner update and it turned out to be unnecessary, you should also remove it from the list. This can conceivably be put into 2 separate bots: one to scan the recent changes and figure out which ones are on the "need fixing" list which could then feed the page titles needing fixing to a second bot which actually did the work. –jacobolus (t) 17:30, 18 January 2024 (UTC)
Jacobolus, yes, (1) is the hard part. There is no straightforward way that I know of to achieve this, so if anyone knows how, that would be helpful. Regarding (2), I do run another task that monitors reference errors from recent changes, so that part wouldn't be so hard. (Believe me, I do actually understand how to code.) — Qwerfjkltalk 18:22, 18 January 2024 (UTC)
(Sorry, wasn't trying to give any offense; while I pinged you specifically, please consider my comment an explanation primarily directed at any non-programmers in the audience here.) Surely there has to be some way to get a list of all article titles in English Wikipedia. Maybe someone else has an idea for how to do that? –jacobolus (t) 18:33, 18 January 2024 (UTC)
Jacobolus, there is, I could probably get that from a database dump. But I would then also need a way to filter those titles. — Qwerfjkltalk 19:33, 18 January 2024 (UTC)
Why do you need to filter the titles? Every (article namespace) talk page is supposed to get a 'banner shell', right? As far as I can tell the only ones that need to be skipped are redirects which do not already have any wikiproject banners. –jacobolus (t) 19:50, 18 January 2024 (UTC)
@Jacobolus: I suggest also skipping disambiguation pages that do not exist, for the same reason we don't create a new page just to add {{WikiProject Disambiguation}}. GoingBatty (talk) 20:19, 18 January 2024 (UTC)
Jacobolus, because I don't want to rerun the bot on pages that have already be worked, as that is liable to produce cosmetic edits. — Qwerfjkltalk 20:26, 18 January 2024 (UTC)
The bot is hopefully smart enough to notice when there's already a banner shell with a unified rating and no other necessary changes, and do nothing in that case? –jacobolus (t) 00:09, 19 January 2024 (UTC)
┌───────────────────────────┘
Jacobolus, to put it simply, no. — Qwerfjkltalk 07:09, 19 January 2024 (UTC)
Well it should be fixed then. This bot is trying to do a change of «wrap the wikiproject banners in a banner shell, compare all their quality ratings, and also copy the most popular one into the banner shell, deleting equivalent ratings from the now-wrapped banners».
If the banners are already wrapped, have a quality rating applied to the banner shell template, and have no quality ratings matching that one among the wrapped banners, then the bot should do absolutely nothing. If the bot is not currently implemented to be capable of this, then it should be fixed before being applied millions of times. –jacobolus (t) 07:46, 19 January 2024 (UTC)
Jacobolus, it also moves around the wikiprojects and wikiproject banner shell (to comply with MOS:TALKORDER), and the way I've implemented that makes it hard to check if it's actually doing anything or not. — Qwerfjkltalk 07:50, 19 January 2024 (UTC)
Anecdotally, the change has made a huge difference for my watchlist, the 18 January entries (on standard UTC) show just 19 relatively scattered entries whereas before there would regularly be entire screens worth. It slightly spiked when hitting a few "Elections in X" articles, however this isn't a problem that wouldn't have happened if it was done by WikiProject. In addition to the TOL concerns above, problems will arise when the bot hits "List of...". CMD (talk) 01:45, 19 January 2024 (UTC)
What I could do is work on Category:WikiProject banners without banner shells instead. I don't think there's a way to randomly fetch pages from a category, though. — Qwerfjkltalk 10:11, 20 January 2024 (UTC)
It is possible, see quarry:query/79763. – SD0001 (talk) 11:26, 20 January 2024 (UTC)
SD0001, I more meant with the API, good to know it can be done with a SQL query. I'll have to run the code directly on Toolforge to query the wiki replicas, though. — Qwerfjkltalk 22:17, 20 January 2024 (UTC)
Anyway, I've setup my bot to run off that. — Qwerfjkltalk 16:29, 22 January 2024 (UTC)

A semi-centralized approach to solve the watchlist problem

What about having a centralized page where editors can opt-in to a "watchlist greylist", and put whatever pages they want in, say, User:Tom.Reding/Watchlist greylist (maybe a name without a grey/gray variant), in some uniform, machine-readable format that's clearly stated on the centralized page? Bot ops would then be required, for very big jobs only, to add all pages listed at each opted-in users' subpage, and only edit those pages at a very slow rate. A large, but reasonable, limit could be set on the # of pages listed to prevent abuse.

The piggyback method is very interesting and superior though, since it requires no user input.   ~ Tom.Reding (talk ⋅dgaf)  16:36, 18 January 2024 (UTC)

Wouldn't that be a list of like a million talk pages or something in this case? I don't think listing per page per user would be efficient. A better technique might be a user script combined with a centralized list of bot usernames to (temporarily?) hide. –Novem Linguae (talk) 16:53, 18 January 2024 (UTC)
Well, the bot op would remove duplicates on their end as part of the collection process. There's going to be computational overhead with any method. The benefit of a greylist over temporararily hiding bots (or accidentally-permanently hiding a bot - i.e. the user forgets they have a bot, or bots, hidden), is that it would allow for highspeed editing while still showing bot edits to those that want to see bots but not be flooded either.   ~ Tom.Reding (talk ⋅dgaf)  17:07, 18 January 2024 (UTC)
I don't think this would scale very well. Users would have to list their (large) watchlists and keep it up to date, and bots would have to read many users' lists to collect the list of pages. Anomie⚔ 22:42, 18 January 2024 (UTC)
  • Watchlists are private for a good reason. We mustn't ask key people to disclose their watchlists, because they might unthinkingly do it, to the delight of spammers, marketers and people who're in bad faith around the world.—S Marshall T/C 18:20, 19 January 2024 (UTC)

Cosmetic edits

Edits like this are real watchlist-cloggers. I'm calling WP:COSMETICBOT on that. --Redrose64 🌹 (talk) 21:54, 24 January 2024 (UTC)

With my BAG hat on... I agree. Primefac (talk) 12:45, 25 January 2024 (UTC)
Redrose64, are there a large volume of them, or is it just a few? I know my bot sometimes does this, but it shouldn't happen very often. — Qwerfjkltalk 16:04, 25 January 2024 (UTC)
I don't know the actual figures, I was making tests before posting this further up this page. Basically, for the purposes of my tests, I needed to find a talk page which had been edited both by a bot and a human within the same day, so that I could analyse the HTML of the row in the watchlist. In the course of this search I happened to find one where the bot edit was, essentially, pointless. It didn't take long to find: it was, in fact, only the second page that I found meeting my criteria. --Redrose64 🌹 (talk) 21:15, 26 January 2024 (UTC)
 Doing... I've coded up a quarry query and am in the process of roughly analysing the results. ‍—‍a smart kitten[meow] 22:42, 26 January 2024 (UTC)

 Done (to some degree): I coded up an extremely rough query at quarry:query/79969 that looked for the 500 most recent edits by Qwerfjkl (bot) that had a size change of between 0 and -5, and then skimmed through the diffs manually. While I can't promise I didn't miss anything (or that the -5 ≤ diff_size ≤ 0 heuristic I used caught everything), I came across the following edits (made between 2024-01-23T21:16 & 2024-01-26T22:23) that could be considered purely cosmetic:

List of potentially cosmetic edits
  1. Special:Diff/1199369821 - rearranged the order of the talk page banners (the WikiProject template was already in a banner shell)
  2. Special:Diff/1199366248 - removed whitespace & 1= in the banner shell wikitext
  3. Special:Diff/1199362275 - removes a line of whitespace (also worth noting that the previous edit on this page was from Cewbot, which had already performed the banner shell conversion for this talk page)
  4. Special:Diff/1199335335 - same as #3
  5. Special:Diff/1199066300 - same as #3, although the previous edit on this page was instead from Qwerfjkl (bot) & less than two hours beforehand
  6. Special:Diff/1199029200 - same as #3
  7. Special:Diff/1199027869 - same as #2
  8. Special:Diff/1198984120 - same as #2
  9. Special:Diff/1198976926 - same as #3
  10. Special:Diff/1198943758 - same as #3
  11. Special:Diff/1198940537 - changed start to Start in the class= parameter
  12. Special:Diff/1198928103 - same as #2
  13. Special:Diff/1198917290 - same as #3
  14. Special:Diff/1198914531 - same as #2
  15. Special:Diff/1198912764 - same as #3
  16. Special:Diff/1198908927 - same as #2
  17. Special:Diff/1198904578 - same as #3
  18. Special:Diff/1198898739 - same as #2
  19. Special:Diff/1198894911 - same as #3
  20. Special:Diff/1198890387 - same as #3
  21. Special:Diff/1198887482 - same as #2
  22. Special:Diff/1198881947 - same as #2
  23. Special:Diff/1198875182 - same as #3
  24. Special:Diff/1198856999 - same as #3
  25. Special:Diff/1198843075 - same as #1
  26. Special:Diff/1198821829 - same as #3
  27. Special:Diff/1198812271 - same as #1 (worth noting the previous edit was from Cewbot)
  28. Special:Diff/1198756928 - same as #3
  29. Special:Diff/1198744058 - same as #2
  30. Special:Diff/1198639678 - same as #5
  31. Special:Diff/1198638524 - same as #5
  32. Special:Diff/1198636387 - same as #5
  33. Special:Diff/1198633249 - same as #3
  34. Special:Diff/1198627528 - same as #27
  35. Special:Diff/1198625321 - same as #2
  36. Special:Diff/1198625200 - same as #5
  37. Special:Diff/1198624901 - same as #5
  38. Special:Diff/1198623732 - same as #3
  39. Special:Diff/1198622218 - same as #5
  40. Special:Diff/1198621039 - same as #5
  41. Special:Diff/1198620358 - same as #5
  42. Special:Diff/1198619737 - same as #5
  43. Special:Diff/1198618306 - same as #5
  44. Special:Diff/1198617319 - same as #5
  45. Special:Diff/1198611293 - same as #5
  46. Special:Diff/1198611122 - same as #5
  47. Special:Diff/1198610868 - same as #5
  48. Special:Diff/1198610465 - same as #5
  49. Special:Diff/1198607796 - same as #5
  50. Special:Diff/1198606895 - moved an empty class= parameter to the (pre-existing) banner shell
  51. Special:Diff/1198606102 - same as #27
  52. Special:Diff/1198606042 - same as #5
  53. Special:Diff/1198604643 - same as #5
  54. Special:Diff/1198604506 - same as #5
  55. Special:Diff/1198601809 - same as #5
  56. Special:Diff/1198601488 - same as #5
  57. Special:Diff/1198600313 - same as #27
  58. Special:Diff/1198599841 - same as #5
  59. Special:Diff/1198595606 - same as #5
  60. Special:Diff/1198594672 - same as #5
  61. Special:Diff/1198593136 - same as #5
  62. Special:Diff/1198589078 - same as #5
  63. Special:Diff/1198588661 - same as #5
  64. Special:Diff/1198588350 - same as #5
  65. Special:Diff/1198587364 - same as #5
  66. Special:Diff/1198584086 - same as #5
  67. Special:Diff/1198583883 - same as #5
  68. Special:Diff/1198581699 - same as #5
  69. Special:Diff/1198581553 - same as #5
  70. Special:Diff/1198578042 - same as #5
  71. Special:Diff/1198577331 - same as #5
  72. Special:Diff/1198577221 - same as #5
  73. Special:Diff/1198576064 - same as #3
  74. Special:Diff/1198575826 - same as #5
  75. Special:Diff/1198574242 - same as #27
  76. Special:Diff/1198572434 - same as #27
  77. Special:Diff/1198571620 - same as #5
  78. Special:Diff/1198570688 - same as #5
  79. Special:Diff/1198570301 - same as #5
  80. Special:Diff/1198569163 - same as #2
  81. Special:Diff/1198565113 - same as #5
  82. Special:Diff/1198563829 - similar to #11, changed stub to Stub in the class= parameter
  83. Special:Diff/1198561575 - same as #5
  84. Special:Diff/1198560640 - same as #5
  85. Special:Diff/1198560412 - same as #5
  86. Special:Diff/1198558890 - same as #5
  87. Special:Diff/1198558756 - same as #5
  88. Special:Diff/1198557529 - same as #5
  89. Special:Diff/1198553514 - same as #5
  90. Special:Diff/1198550161 - same as #5
  91. Special:Diff/1198547858 - same as #5
  92. Special:Diff/1198546417 - same as #5
  93. Special:Diff/1198543325 - same as #5
  94. Special:Diff/1198542800 - same as #5
  95. Special:Diff/1198538713 - same as #5
  96. Special:Diff/1198537513 - same as #5
  97. Special:Diff/1198536939 - same as #5
  98. Special:Diff/1198536077 - same as #5
  99. Special:Diff/1198535921 - same as #5
  100. Special:Diff/1198531575 - same as #5
  101. Special:Diff/1198527583 - same as #5
  102. Special:Diff/1198526987 - same as #5
  103. Special:Diff/1198525299 - same as #5
  104. Special:Diff/1198523806 - same as #5
  105. Special:Diff/1198523276 - same as #27
  106. Special:Diff/1198521155 - same as #5
  107. Special:Diff/1198521041 - same as #5
  108. Special:Diff/1198519479 - same as #5
  109. Special:Diff/1198512390 - same as #3
  110. Special:Diff/1198508245 - same as #3
  111. Special:Diff/1198506878 - same as #27 (& also removed a line of whitespace)
  112. Special:Diff/1198501167 - same as #27
  113. Special:Diff/1198498440 - same as #27
  114. Special:Diff/1198496973 - same as #27
  115. Special:Diff/1198494289 - same as #27
  116. Special:Diff/1198474446 - same as #27
  117. Special:Diff/1198474111 - same as #27
  118. Special:Diff/1198472001 - same as #27 (& also removed a line of whitespace)
  119. Special:Diff/1198334695 - same as #27

All the best, ‍—‍a smart kitten[meow] 02:22, 27 January 2024 (UTC)

@A smart kitten I looked at the edits cewbot made before Qwerfjkl (bot), and made a request at User talk:Kanashimi#Talk page layout. GoingBatty (talk) 02:51, 27 January 2024 (UTC)
I fixed the bug in the program and it looks much better now. [1] [2] [3] Kanashimi (talk) 06:35, 27 January 2024 (UTC)
User:Qwerfjkl: please don't ever have your bot just change the capitalization of stub -> Stub or start -> Start, even as part of another edit. If anything, the lower-case variants are frankly preferable (less distracting) as they match the capitalization of the parameter names, but this kind of cosmetic change is pure churn for no benefit at all. –jacobolus (t) 08:00, 27 January 2024 (UTC)
Jacobolus, I believe I've already expressed my view on this. Yes, it would be preferable if the bot neve made cosmetic edits; but it is hard to detect whether the bot is actually making a cosmetic edit or not. Right now the bot is running on a category of pages that need fixing, so it shouldn't make any comsetic edits. — Qwerfjkltalk 11:45, 27 January 2024 (UTC)
@Qwerfjkl yes but beyond that, what I am saying is that the bot should never be changing the capitalization of these parameters. You should take out the part of your program that makes this type of change. –jacobolus (t) 16:35, 27 January 2024 (UTC)
Jacobolus, that's not how the code works. It doesn't have an normal form that it capitalsises, because it takes the classes from the wikiprojects which can have mixed capitalisation. What I could do is make every class= lowercase, but I don't see how that would be any better. — Qwerfjkltalk 17:33, 27 January 2024 (UTC)
Is the source code published somewhere? I would not expect this to be an inordinately difficult bug to fix. –jacobolus (t) 17:52, 27 January 2024 (UTC)
Jacobolus, https://public-paws.wmcloud.org/User:Qwerfjkl%20(bot)/PIQA.ipynb is an slightly outdated version of the code, but that part of the logic should be the same. — Qwerfjkltalk 18:14, 27 January 2024 (UTC)
The class handling logic starts at the line classes = [— Qwerfjkltalk 18:18, 27 January 2024 (UTC)
You have a test already if len(page_wpbs) == 1 and page_wpbs[0].has('class', ignore_empty=True) ...
In this case that the banner shell already has a class set you should not change it, and can short-circuit most of the following code, because there is already an explicit "unified_class".
In the case that some of the contained wikiproject banners contain a matching class, you can still remove them, but if the only class is in the shell, you should not be changing it. –jacobolus (t) 18:46, 27 January 2024 (UTC)
Jacobolus, that code is for considering the wpbs' class to find the unified class.
I could change the line
page_wpbs.get('class').value = capitalised_unified_class # will only be non-cosmetic if class= nothing
so that it ensures it only does it if class is blank. — Qwerfjkltalk 21:22, 27 January 2024 (UTC)
My point is there's no need to find a "unified class" in this case; the class on the banner shell has already been "unified". –jacobolus (t) 21:49, 27 January 2024 (UTC)
Jacobolus, I've updated the live code without testing (so hopefully nothing goes wrong). The updated code will take a while to take effect (because the bot's still running). — Qwerfjkltalk 21:58, 27 January 2024 (UTC)

Why is Qwerfjkl (bot) signing my post?

Here.[4]. Doug Weller talk 15:47, 30 January 2024 (UTC)

@Doug Weller: In this edit, when you added ~~~~, it didn't automatically turn into your signature. (Maybe due to the unclosed <ref> tag?) The next two posts from Macrakis and you also did not have ~~~~ converted into signatures, and SineBot added {{Unsigned}} to your last post. I tried reverting the bot's edit, but then it changed the signatures to me! Oops! So I edited again to remove the tildes and add {{Unsigned}} instead. GoingBatty (talk) 16:40, 30 January 2024 (UTC)
Because that page was a hot mess, looks like ever since you added an unmatched ref tag years ago. I wouldn't worry about that. — xaosflux Talk 16:45, 30 January 2024 (UTC)
@GoingBatty@Xaosflux Thanks all. Doug Weller talk 17:06, 30 January 2024 (UTC)

Request for global bot flag for CommonsDelinker

Hello!

This is a notification to let you know that a new request for the global bot flag for CommonsDelinker has been started.

Please note that the request will remain open for 14 days starting today. You can leave a comment or opinion on the relevant page!

Best regards --Superpes15 (talk)

Note, per local policy, only global approvals for updating interwiki links are valid here on the English Wikipedia. This bot is already approved locally for its task at Wikipedia:Bots/Requests for approval/CommonsDelinker. Anomie⚔ 13:08, 6 February 2024 (UTC)

Lifting the ban?

Hello, I had an User:Dušan_Kreheľ (bot) bot, it was banned for some activity. I am not interested in performing any tasks with a bot for which I do not have approval. That is the past for me (unless it is approved). Is it possible to cancel the ban? Dušan Kreheľ (talk) 16:47, 13 February 2024 (UTC)

When it is ready to be used again, just file a new Wikipedia:Bots/Requests for approval, unblocking will be done when a trial is approved. — xaosflux Talk 16:50, 13 February 2024 (UTC)

Inactive bots (February 2024)

It's that time again:

Bot account Operator(s) Last activity (UTC) Last operator activity (UTC)
Cerabot~enwiki Ceradon 03 Jul 2015 21 Jan 2022
CeraBot Ceradon 07 Jul 2012 21 Jan 2022
JBradley Bot Jamo2008 07 Jul 2013 01 Feb 2022
BotPuppet Master of Puppets 01 Feb 2013 04 Feb 2022

Plus TohaomgBot who was indeffed in 2018 and missed in the previous sweep of indeffed bots. * Pppery * it has begun... 16:35, 4 February 2024 (UTC)

Notifications left, {{Inactive bot notification}} created for future notification purposes. Primefac (talk) 16:54, 4 February 2024 (UTC)
Is it time to deflag them now? * Pppery * it has begun... 16:57, 15 February 2024 (UTC)
 Done. Primefac (talk) 16:59, 15 February 2024 (UTC)

Missing bots from Toolforge's Grid Engine shutdown

I only learned that Yapperbot had been down since December yesterday - are there any other bots that are also down as a result of the Toolforge change? Legoktm (talk) 00:29, 22 February 2024 (UTC)

User:MajavahBot/Bot status report can be reviewed locally for recently-inactive bots. Izno (talk) 00:41, 22 February 2024 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Bots/Noticeboard/Archive_19&oldid=1215178276"