Jump to content

Wikipedia:Bots/Noticeboard/Archive 19

Add links
From Wikipedia, the free encyclopedia
< Wikipedia:Bots | Noticeboard

This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 07:42, 13 June 2024 (Archiving 1 discussion(s) from Wikipedia:Bots/Noticeboard) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Archive 15←Archive 17Archive 18Archive 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)

Discussion at User talk:Kku § Overlinking/bot-like editing

 You are invited to join the discussion at User talk:Kku § Overlinking/bot-like editing. Sdkb talk 18:22, 28 March 2024 (UTC)

Please block Cewbot

Edit rate is far too fast. These aren't urgent edits, so rate should be 6 EPM or lower. Creator unresponsive to requests to slow it down; he replies promptly but only with advice about how to hide its edits.—S Marshall T/C 20:17, 16 February 2024 (UTC)

Well above the urgent rate of 12epm, too; median edit rate (averaged over one-hour periods) since the start of February is 107 per minute, with three hours exceeding 150. —Cryptic 21:15, 16 February 2024 (UTC)
The bot was already blocked over this back in January [5]. Could we get a longer block this time? By the way, Qwerfjkl (bot) (talk · contribs), the other bot dealing with this talk page WP banner thing, also seems to be editing above the rate. Could you check this, Cryptic? Super Ψ Dro 22:56, 16 February 2024 (UTC)
Now in the same query - better, but not by much. quarry:query/80461 has the rates grouped by individual minute; Qwerfjkl (bot) was at one point as high as 225/minute, currently between 60 and 70. —Cryptic 05:31, 17 February 2024 (UTC)
Thank you for your detailed investigation at User talk:Kanashimi/Archive 1#Slow it down. It looks like we need both cewbot, Qwerfjkl (bot) to slow down together? What fraction of the current speed would be better? Kanashimi (talk) 23:08, 16 February 2024 (UTC)
Whatever fraction equals 6 edits per minute? MrOllie (talk) 23:12, 16 February 2024 (UTC)
We ought not to forget this is a thing affecting over 5 million pages and I think all of us would like not to continue seeing these edits in 5 years from now. Super Ψ Dro 23:14, 16 February 2024 (UTC)
Kanashimi, with the current rate, when would all of this be over? I understand the point of this should not be to drag this thing for years, so I can be in favor of a rate over the apparent standard of 12 epm. Not of a rate ten times higher than that. The spam since the start of February has been massive. Super Ψ Dro 23:14, 16 February 2024 (UTC)
Well, I just checked, and at the current rate, the current category will be up for another 3 or 4 days, so overall it looks like about a week? Kanashimi (talk) 23:17, 16 February 2024 (UTC)
I suggest a generous 30 epm. Will be far easier to manage than what we have now and still end this within a month. With 6epm if the maths don't fail me this would last almost half a year which is a no. I also suggest longer term sanctions to be applied if the bots far exceed their supposed rates again. Super Ψ Dro 23:21, 16 February 2024 (UTC)
I'd like to point out that despite knowing that Qwerfjkl (bot) has a similar edit speed, and editing with similar bot tasks, at no point has S Marshall been asking for that bot to also slow down. Why the targeting of Cewbot only? Zinnober9 (talk) 01:07, 17 February 2024 (UTC)
  • Please will a sysop urgently block the bot. I'm amazed that, despite participating in this discussion, Kanashimi has still not stopped it.—S Marshall T/C 00:09, 17 February 2024 (UTC)
    The bot is making 71 and 58 edits per minute. – DreamRimmer (talk) 01:05, 17 February 2024 (UTC)
    I agree; it needs to be blocked or deactivated. If Kanashimi wants an exception for it to run faster than normally permitted they can open an RFC requesting the community grants such an exception. BilledMammal (talk) 01:11, 17 February 2024 (UTC)
    I have blocked User:Cewbot indefinitely per WP:BOTPERF with no objection to an unblock at any time by any admin should the edit rate be adjusted to an acceptable value or a consensus emerge to allow the bot to exceed the generally-accepted maximum edit rate of 6 EPM. ~2 edits per second is far above accepted norms. Reaper Eternal (talk) 01:13, 17 February 2024 (UTC)
    @Reaper Eternal 6epm here would mean that the bot would need to remain operational (on a conservative estimate) for 1 year for what is a one time run. (This is assuming no infrastructure downtime, taking a very conservative downtime of 1% of a year (i.e. 99% uptime, which Google claims to acheive), that number balloons to 1.5 years). Based on this, limiting the bot to 6epm is not very logical stance to take in this context (in my opinion). Sohom (talk) 02:00, 17 February 2024 (UTC)
    There are very good arguments for allowing this bot to run in excess of the usual maximum edit rate; however, there would need to be a consensus to allow this. (I could see 15-20 EPM being easily supported by the community.) The bot was editing in the range of 120 EPM, which is vastly in excess of generally-accepted norms. Reaper Eternal (talk) 02:08, 17 February 2024 (UTC)
    @Reaper Eternal I thought the progress discussed above was that cewbot and Qwerfjkl (bot) should be slowed down together, and we are discussing which speed is better. Instead of blocking cewbot at too fast a speed, but not Qwerfjkl (bot) running at the same speed, am I wrong? Kanashimi (talk) 02:29, 17 February 2024 (UTC)
    "Injuries, therefore, should be inflicted all at once, that their ill savor being less lasting may the less offend; whereas, benefits should be conferred little by little, that so they may be more fully relished." — Niccolò Machiavelli, The Prince Hawkeye7 (discuss) 05:09, 17 February 2024 (UTC)
    I'll try to slow down my bot. Unfortunately just not quite as simple as setting the epm, I have to modify the delay between edits, which doesn't always correspond to what the actual edit rate is (because I also have to take maxlag into account).
    What edit rate should I aim for? — Qwerfjkltalk 07:46, 17 February 2024 (UTC)
    It seems that 20-30epm would be acceptable based on the above discussion. Primefac (talk) 09:35, 17 February 2024 (UTC)
    @Reaper Eternal:I set the PIQA task to 5s/edit, please help me to unblock the robot, thank you. --Kanashimi (talk) 08:19, 17 February 2024 (UTC)
    I think 12EPM would be fine. – DreamRimmer (talk) 09:03, 17 February 2024 (UTC)
    ...and if you want to increase it in the future, it should be discussed before implementation. – DreamRimmer (talk) 09:07, 17 February 2024 (UTC)
    My biggest problem is that we should treat all bots equally. If speed is the reason, then every robot with the same speed should be handled together, not just one robot. Kanashimi (talk) 09:42, 17 February 2024 (UTC)
  • Thank you for blocking this bot. I didn't ask for Qwerfjkl's bot to be blocked because it didn't annoy me as much, but I do agree with Kanashimi that in the circumstances it's only fair to block that bot too.
    I understand that Kanashimi has, at long last, finally done something to reduce the edit rate and I regret that it took this much drama to achieve that. I suggest unblocking for a 50-edit trial so we can check that the edit rate is below 6 EPM now.—S Marshall T/C 09:47, 17 February 2024 (UTC)
    Thank you for your response. So the point is actually the harassment of the watchlist. But as you can see, there are users who have complained about Qwerfjkl's bot interfering, they just haven't asked for it to be blocked. That's why my discussion above focused on how much it would be better to reduce the speed. Kanashimi (talk) 10:15, 17 February 2024 (UTC)
Yes, it is about the watchlist, as it should be obvious after the complaints of over a dozen of editors since January. I think Qwerfjkl (bot) shoould receive whatever treatment Cewbot receives. It appears to me that it is running at around 60 epm right now. Either block it or apply immediately a 20-30 epm rate. Super Ψ Dro 10:32, 17 February 2024 (UTC)
@S Marshall Based on the discussion above, it seems that 20epm (3s/edit) is the speed that many people think we can try. I'll try this speed first, and you can report back on your situation, what do you think? Kanashimi (talk) 11:31, 17 February 2024 (UTC)
I think this is a non-urgent task, and the community has decided that non-urgent tasks must run at or below 6 EPM. Why do you want to exceed this?—S Marshall T/C 11:50, 17 February 2024 (UTC)
@@S Marshall Okay, I see what you mean. I can keep 6epm. So, in fairness, do you think it's necessary to limit cewbot only, or should it be fair to all bots in the same situation? You don't seem to have commented on this yet. Kanashimi (talk) 12:03, 17 February 2024 (UTC)
I just said Qwerfjkl's bot should also be blocked. I said it in this thread, this morning, a few posts above this one.—S Marshall T/C 12:21, 17 February 2024 (UTC)
Sorry, I missed your comment. Because only cewbot is banned now, and the title of this section is only cewbot. Kanashimi (talk) 12:24, 17 February 2024 (UTC)
@S Marshall So if I'm not mistaken, you're saying that both robots should run on 6epm. Am I right? Kanashimi (talk) 12:26, 17 February 2024 (UTC)
Yes.—S Marshall T/C 13:25, 17 February 2024 (UTC)
  • Surely a stupid question but I can't reason why. We only have 6 million articles. That's not a big number for computers. Why can't we do the one-time tasks like these as fast as possible and finish it up, I don't know, in an hour or less? Currently, slow or fast edit is just the same to me because they are going to show all my articles in the watchlist whether it be dozens a day for a year or hundreds a day for a few months. Usedtobecool ☎️ 10:29, 17 February 2024 (UTC)ec
The talk pages of both are full of notices of bugs. They've required human watching since the start and indeed many editors have done so. Also it is absolutely not the same having your entire watchlist being shown in 2-3 months or in 24 hours. The latter is absolutely unmanageable and defeats the purpose of having a watchlist. I don't see why should editors, as in the entire community, be bothered over this minimal change that doesn't matter. Super Ψ Dro 10:37, 17 February 2024 (UTC)
If it's because we can't trust the task to be done well, then ok. Even still, if they don't break something major when they go wrong, we can find the errors as we go and fix them, I would think. The watchlist thing misses the point. We could simply send out a notice first and set the time, and editors can simply hide bot edits for that one time window. I guess my point is, we tell everyone and run it once, and trust the task to be done reasonably well. Asking everyone to work around it, suck it up or whatever for one editing window which could even be done whenever most editors sleep, seems to me miles better than having these conflicts over months. Usedtobecool ☎️ 10:55, 17 February 2024 (UTC)
I don't want to suck it up. I want to see if mistakes are introduced in the articles I've written. Super Ψ Dro 11:00, 17 February 2024 (UTC)
Fair enough. Usedtobecool ☎️ 11:06, 17 February 2024 (UTC)
Hiding bot edits only works properly with a very few watchlist configurations, all of which are only practical for people who'd be least impacted by high rates of bot edits to begin with. —Cryptic 11:45, 17 February 2024 (UTC)
Might it be possible to make one editor's edits completely invisible to the watchlist program for a short time that they would need? Maybe not from here but technically, if we found consensus and asked the WMF? Usedtobecool ☎️ 11:53, 17 February 2024 (UTC)
This is the idea behind the bot permission. The bot permission makes it possible to filter out edits by bots. However some folks turn this off, probably the folks that are posting here right now. –Novem Linguae (talk) 12:03, 17 February 2024 (UTC)
No, what the bot permission does is make it possible to not show pages on your watchlist at all if the most recent edit was flagged bot. (Also to not show just the bot edit, if your watchlist is low enough volume that you use the show all edits option, but people who can do that aren't running up against the 1000-entry watchlist limit anyway.) —Cryptic 12:18, 17 February 2024 (UTC)
To deal with this, you can use the extended watchlist in your preferences: that shows all edits to a page, instead of only the last one, and showing no edit at all if the last edit is a bot edit, whether or not preceeded by a non-bot edit. Wikiwerner (talk) 13:11, 17 February 2024 (UTC)
(I wrote something in parens above about that.) —Cryptic 13:18, 17 February 2024 (UTC)
We've been asking the WMF since 2007, very nearly since removing bot-edited pages from the watchlist was introduced. Good luck with that. —Cryptic 12:18, 17 February 2024 (UTC)
You could also just configure your watchlist to ignore specifically talk page banner shell conversions. (By ignoring the specific tag that corresponds to this task). This is not a all or nothing problem, it a problem with specific editors just not wanting to hide the edits in the first place and then complaining when the edit rate gets high. Sohom (talk) 12:53, 17 February 2024 (UTC)
There is NO SUCH OPTION unless your watchlist is low-volume enough that you can enable show all changes. This is not a problem of specific editors not wanting to hide edits. This is a problem with specific editors who don't understand how any watchlist configuration except their own works. —Cryptic 13:14, 17 February 2024 (UTC)
Watchlist configuration dropdown
Hiding a specific tag in the watchlist
(There's no reason to shout here, please make sure to abide by the Technical Code of Conduct.) I'm pretty sure there is a way to remove only edits tagged with "Talk page banner shell conversion". If you are using the filters based watchlist you can scroll down the filtering menu (pictured), click on Tagged edits, which should show a new view (pictured) where you can select "Excluding selected" and then select the "Talk page banner conversion" tag. This should remove only Cewbot and Qwerjfkl bot from your watchlist. Sohom (talk) 13:28, 17 February 2024 (UTC)
Wonderful. Great. I'm glad it works for you. Please stop attempting to tell me it works without show-all-edits enabled without testing it. Because it. Does. Not. With utmost respect, you don't know what you're talking about. —Cryptic 13:33, 17 February 2024 (UTC)
And before you tell me to just enable show-all-edits, the thousand-edit maximum makes my watchlist go back just over four and a half hours. —Cryptic 13:44, 17 February 2024 (UTC)
I'm not going to tell you to do anything. I'm just going to leave this discussion, since to me it is clear that you are not here to ask for help like I initially assumed. Thanks and have fun driving well meaning people off the project. Sohom (talk) 14:09, 17 February 2024 (UTC)
There's something that maybe Cryptic failed to explain here. On this page, I made an edit, then my bot made an edit similar to the talk banner shell conversions. If I go to my watchlist and hide bot edits, or hide minor edits, or hide edits tagged like that, and don't have the "Not the latest revision" checkbox enabled (so it only displays the latest revision), it would hide the page from my watchlist entirely. This means that the bot's edits will cascade a previous edit, making it harder to see an actual human update to the page.
This is the issue Cryptic referred to, I believe. 0xDeadbeef→∞ (talk to me) 16:08, 17 February 2024 (UTC)
Editors have continously expressed they do not wish to hide the edits. Daily since this spike I've been fixing errors on talk pages of articles I have created. Fix the bot and don't tell editors to modify their ways over this irrelevant change. Super Ψ Dro 13:37, 17 February 2024 (UTC)
No, this is a problem with two bots going at a rate ten times higher than the one they should be running at, to apply a completely irrelevant change, bothering editors that just want to work on the project as usual through regular tools like the watchlist. Super Ψ Dro 13:34, 17 February 2024 (UTC)
This would result in excessive resource consumption and server load. Additionally, there is no urgency necessitating rapid completion. – DreamRimmer (talk) 10:39, 17 February 2024 (UTC)
Are you sure? I find it hard to believe that a website as big as this can not handle 6 million page downloads and uploads in a couple hours. Moreover we are talking about talk pages. in this case. Most of them are empty. Almost all of them have only text. The necessity is ripping the band-aid off in the interest of peace and harmony, which seems desirable given the amount of conflict this one simple thing has generated. Usedtobecool ☎️ 10:59, 17 February 2024 (UTC)
I don't see it anymore, but I'm pretty sure the page mw:API:Etiquette used to have this six edits per minute speed limit explicitly mentioned. Also keep in mind that edits are much more database intensive than views. Folks that have severely violated API etiquette in the past have brought down every Wikipedia website before. For example, wikitech:Incidents/2021-07-26 ruwikinews DynamicPageList. API etiquette exists for a reason. –Novem Linguae (talk) 12:08, 17 February 2024 (UTC)
@Novem Linguae I don't think 6 edits per minute is a server-side limitation (API etiquette limitation), it's something enwiki has dreamed up to make watching bot edits manageable. For mediawiki's POV, bot operators are expected to follow the max-lag (and not operate when the value is too high) and abide by server rate-limits.
That being said doing six-million edits in a hour is stupid, and would definitely bring down the servers. Please don't do that. A higher edit rate (approaching 20-30epm) should be okay, not 1666 edits per second. Sohom (talk) 12:22, 17 February 2024 (UTC)
Sohom Datta, I have in the past run my bot at around 1000 epm (for an unrelated problem, reverting some edits I made), so I can assure you there is no server-side limitation. — Qwerfjkltalk 14:06, 17 February 2024 (UTC)
1000 epm is probably not great sustained over long periods of time. > 20/30 edits per second is too much though :) Sohom (talk) 15:03, 17 February 2024 (UTC)
We only have 6 million articles. That's not a big number for computers. Why can't we do the one-time tasks like these as fast as possible and finish it up. Well a couple reasons. It it was a local database, and you were updating fields in the DB, of course this can be done very fast, 6 million records in seconds. But everything here is done over networking. And networking is by many orders of magnitude slower than any other operation done on computers (CPU, memory access, disk access). Furthermore, there can be rate limiting on the Wikimedia side. Finally there are limits to what the local computer can do. Each edit involves a long series of back and forth networking communications at different layers of the stack. It just takes time. The only way to speed it up is parallel processes, and again you run into rate limiting, CPU and networking bottlenecks that slow it down. IF you ran it on a Toolforge node (a LAN connection to the main database) AND you have a really hot parallel processing rig, it is possible to get very high rates of speed. But it's not like you can do that with AWB and other typical methods. My fastest edit rates were done with the (sadly retired) Grid engine which had an obscure feature for array processing designed for math processing which I hijacked to edit Wikipedia, and man that thing was so fast. -- GreenC 18:01, 17 February 2024 (UTC)
GreenC, just using async JavaScript requests is pretty fast (i.e. parallel processing like you said). — Qwerfjkltalk 19:51, 17 February 2024 (UTC)
I've modified the code to run at around half the rate, at 30-35 epm, just by changing how it handles editing. I'll try to add a delay between edits as well. — Qwerfjkltalk 13:49, 17 February 2024 (UTC)
Actually I note @Primefac said 20-30 epm above, would this be fine? The latest epm can be seen at quarry:query/80482. — Qwerfjkltalk 13:51, 17 February 2024 (UTC)
@S Marshall thinks we should all go to 6epm. 20epm is the speed that should be banned. Kanashimi (talk) 13:53, 17 February 2024 (UTC)
I'm referring to this comment. — Qwerfjkltalk 13:57, 17 February 2024 (UTC)
I've changed to 6epm. Anyway, cewbot was banned for @S Marshall comments and he thinks we should all be running on 6epm. I think what we're doing here is seeking a community consensus. As it stands now, more than 6epm needs to be banned, such as cewbot, so 6epm is a community consensus. Then we should abide by it. Kanashimi (talk) 14:02, 17 February 2024 (UTC)
I will await Primefac's reponse, I'd like a clearer position on this. Completing this task at 6epm is unreasonable. — Qwerfjkltalk 14:05, 17 February 2024 (UTC)
I also think 6epm is too slow. But I think you should respond to the above statement. He says it's not an emergency mission, and it looks like it could run for a year or two. Since my bot has been banned, I'm in no position to comment on this statement. Kanashimi (talk) 14:09, 17 February 2024 (UTC)
With respect, Primefac cannot speak for the community on this. I agree with Billedmammal's suggestion above: If you want to exceed the limits given in WP:BOTPERF we should hold an RFC on that. MrOllie (talk) 14:11, 17 February 2024 (UTC)
MrOllie, Primefac is a member of the BAG, so I try to follow their advice on bot-related matters. — Qwerfjkltalk 14:14, 17 February 2024 (UTC)
I'm aware of that, but given the repeated pushback it is unwise to proceed without support from the community at large, especially since limits that appear to be clearly stated in the bot policy are being exceeded. MrOllie (talk) 14:18, 17 February 2024 (UTC)
MrOllie, yes, I'm trying to reduce the edit rate right now. — Qwerfjkltalk 14:20, 17 February 2024 (UTC)
... if I can work out how to. It's suprisingly difficult to do in pywikibot. — Qwerfjkltalk 14:39, 17 February 2024 (UTC)
I find that quite surprising, since this is a feature all bots should be required to implement. Something like this does not suffice? MrOllie (talk) 14:47, 17 February 2024 (UTC)
I haven't used pywikibot before so maybe I'm missing the obvious, but pywikibot.config.minthrottle looks like what you're looking for? —Cryptic 14:55, 17 February 2024 (UTC)

Cryptic, currently I disable the throttle via 

site.throttle.setDelays(delay=0, writedelay=0, absolute=True)


For some reason modifying those parameters does not seem to actually slow down the bot. I'll need to play around with it a bit.
I'd rather do the edit throttling natively in python than via the time module. — Qwerfjkltalk 15:50, 17 February 2024 (UTC)

The time module is native python, it is part of the python standard library. MrOllie (talk) 16:12, 17 February 2024 (UTC)
MrOllie, oops, I meant pywikibot. — Qwerfjkltalk 16:23, 17 February 2024 (UTC)

Please block Qwerfjklbot

...until Qwerfjkl agrees to reduce it to 6 EPM or below.—S Marshall T/C 14:08, 17 February 2024 (UTC)

S Marshall, I have already said reducing this to 6 epm is unreasonable. The lack of clarity on what edit rate is acceptable doesn't help. — Qwerfjkltalk 14:10, 17 February 2024 (UTC)
Please do the sensible thing and just turn the task off voluntarily until consensus is reached. MrOllie (talk) 14:13, 17 February 2024 (UTC)
I endorse this. Super Ψ Dro 14:27, 17 February 2024 (UTC)
When will this end at 20 epm? Super Ψ Dro 15:21, 17 February 2024 (UTC)
I'm guessing that two bots running the current category should take about half a month if things go well :) After all, we've done a lot of running before. cewbot will probably run a little longer due to the addition of other features, such as fixing incorrect parameters. After this first run, I'll slow it down again, and then it'll become a regular run. The robot will then only process a small number of incremental pages. Kanashimi (talk) 15:35, 17 February 2024 (UTC)
  • Primefac, why are these bots exempt from the policy?—S Marshall T/C 15:18, 17 February 2024 (UTC)
    I know it's a pain to have a flooded watchlist. But since the task page is huge, maybe we can find some workarounds. And 20epm is about 1/5 the speed of the original. Based on the frequency of watchlist flooding you described above, this might be a more acceptable rate for you. This is a new speed, so maybe it's better to try it out first? Of course, you can always comment and we'll fix it. And I don't think you want to have to see them every day for quite some time, do you? Kanashimi (talk) 15:27, 17 February 2024 (UTC)
    There is no hard-coded policy about the speed at which bots may run. If a task is very large or very important, it makes sense to increase the edit rate, and as long as I have been a botop the acceptable "fast" rate has been 20epm. Primefac (talk) 15:44, 17 February 2024 (UTC)
    Kanashimi, when you say "You can always comment and we'll fix it", I'm afraid that's hasn't been my experience at all. I've been asking on your talk page since 18th January for you to slow it down and others asked earlier. You replied telling us how to use technical measures to hide your bot's edits, but you completely failed to slow it down until I posted here.
    Primefac, if the rule isn't 6 edits per minute, then why does the policy at WP:BOTPERF say the rule is 6 edits per minute?—S Marshall T/C 16:30, 17 February 2024 (UTC)
    I was struggling with a lack of community consensus on what seemed to be the norm for such a task. As far as I could tell, the biggest problem was the flood of watchlists. But everyone has a different watchlist, and most people hide bot edits, so more comments are needed. If possible, I do hope there will be a wider discussion to reach a consensus. After all, a few of us may not be talking enough. Kanashimi (talk) 16:42, 17 February 2024 (UTC)
    Shoulds and mays. BOTPERF also hasn't been changed appreciably since 2010, which indicates to me that no one has noticed or cared enough to update it to match what is actually done. If a policy is ignored for long enough, it should be changed. Primefac (talk) 16:49, 17 February 2024 (UTC)

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in Wikipedia's policies are to be interpreted as described in RFC 2119.

    0xDeadbeef→∞ (talk to me) 16:52, 17 February 2024 (UTC)
    Okay, then I've fixed the policy. If the rule's 20 EPM then the policy ought to say it's 20 EPM. Personally, I'd say that's too fast but I'm disinclined to fight about it.—S Marshall T/C 16:59, 17 February 2024 (UTC)
    I've updated it a bit more to remove the part about "urgent bots". 40 EPM is definitely far too fast. (I also don't think there really are "urgent" bot tasks anymore.) Cheers! Reaper Eternal (talk) 18:05, 17 February 2024 (UTC)
    For example, ClueBot NG's tasks are urgent.—S Marshall T/C 18:22, 17 February 2024 (UTC)
    Agreed, but Cluebot NG rarely exceeds 5 EPM. It also only edits in response to vandalism rather than going through massive page lists. Reaper Eternal (talk) 18:31, 17 February 2024 (UTC)

Reaper Eternal, theoretically though, if there was some massive spike in vandalism, it could go much higher. — Qwerfjkltalk 19:52, 17 February 2024 (UTC)

Was it worth it

This is water under the bridge now, but it's been repeatedly shown (i.e with this task and Monkbot 18) that very large bot tasks inevitably annoy the community, and that BAG never seems to realize this until its too late. We should have tried harder to avoid the situation where these edits are necessary at all - it seems to me that Module:WikiProject banner could have been coded to implement the bots' behavior itself (of automatically selecting the rating based on the children and so on) without the need for an edit. * Pppery * it has begun... 15:51, 17 February 2024 (UTC)

I say this genuinely without sarcasm, but if we want to pass a policy where any BRFA with more than X pages needing edited (my initial thought being 10k) has to go through community approval, I'd be all for it. We'll never get anything done, but at least it would mean that BAG would get less grief for approving tasks. Primefac (talk) 15:58, 17 February 2024 (UTC)
I think 10K isn't large enough, and would set it to 1 million, and limit it to one-time runs not tasks that will gradually reach 1 million edits by running for years. If that had been in place for the entire history of Wikipedia it would cover only MalnadachBot (which was belatedly community approved at Wikipedia:Village pump (policy)/Archive 179#RFC: Clarifications to WP:COSMETICBOT for fixing deprecated HTML tags, although to this day I consider the entire concept of lint errors an utter waste of everyone's time), the two bots discussed here, Monkbot 18, probably removal of interwikis for Wikidata (which was approved at Wikipedia:Wikidata interwiki RFC anyway), KasparBot's deletion of persondata (to which I would count the RfC that deprecated persondata a sufficient consensus), and that's about it. I genuinely think Wikipedia would have been better off if the few bots in that list were discussed in a broader venue before being applied. * Pppery * it has begun... 16:09, 17 February 2024 (UTC)
Ah, I see what you mean. I, personally, will be keeping things like this in mind going forward, for what it's worth. Primefac (talk) 16:11, 17 February 2024 (UTC)
The community only got cross because the bot operators disregarded requests to slow down. See for example User talk:Kanashimi/Archive 1#Slow it down or User talk:Kanashimi/Archive_1#Stop flooding watchlists, please. If the botops had had the courtesy to halve their editing speed when specifically asked, the BAG would never have even known it was a problem. I think the lesson here isn't to run a full RFC before every large BRFA, but just to make sure the botops know they can't ignore the community.—S Marshall T/C 16:40, 17 February 2024 (UTC)
I'm sorry to make you feel that I'm not sincere enough, this is something I need to improve on. As I mentioned above, since this is not a task performed by a single robot, I need a broader consensus. Changing my robot alone won't solve the problem. Also, even if the daily processing is halved, I'm sure you don't want to see the task take twice as long. So we need to discuss a solution that works for all robots. Kanashimi (talk) 16:46, 17 February 2024 (UTC)
Changing your bot alone may not have solved the whole problem, but it would have solved the part of the problem that is within your control. It is important that we do not create a situation where responsibility gets passed back and forth and nothing gets done. MrOllie (talk) 16:57, 17 February 2024 (UTC)
Yes, you have a point. Kanashimi (talk) 17:02, 17 February 2024 (UTC)
S Marshall, as a result of that discussion, I switched to doing pages in random order, to avoid editing a lot of similar pages and clogging up watchlists, which was suggested during the ensuing discussion resulting from that thread you linked. After that I received exactly one (this) request to slow it down, which seemed (to me at least) more about email alerts and less about the edit rate itself. — Qwerfjkltalk 16:50, 17 February 2024 (UTC)
No, look, if your bot's editing too fast and someone asks you to slow down, you need to slow it down. That is the only acceptable response. People who don't get that shouldn't be running bots.—S Marshall T/C 17:07, 17 February 2024 (UTC)
S Marshall, if you look at the thread, they were asking to stop the notifications rather than the edits themselves. — Qwerfjkltalk 19:49, 17 February 2024 (UTC)
WMF needs to solve this problem. For example, the ability to edit without triggering watchlists. Obviously such permissions could be granted carefully with consensus. There will be times when millions of pages need to be updated. This is one case. There is no reason to have all this disruption. -- GreenC 19:36, 17 February 2024 (UTC)
The thing with these bots is that often they were forgetting to remove things they were supposed to remove or duplicating parameters. This made watching their edits necessary. If they did every single edit flawlessly I would have had no problem in hiding their edits through the tools above. The thing isn't not triggering the watchlists, that is a bad idea. There will be times when millions of pages need to be updated. This is one case. this thing wasn't really necessary and I'm quite sure 99% of the community is indifferent towards this reform and that 99.9% of it is aware of it in the first place because of the huge spam in the watchlists over such a trivial matter. Super Ψ Dro 21:09, 17 February 2024 (UTC)
Super Dromaeosaurus, how often is "often"? Believe me, I don't get paid enough to write flawless code. — Qwerfjkltalk 21:21, 17 February 2024 (UTC)
Often enough to make me not want to hide the edits. To give an actual estimation, I might have edited 1 out of every 15 talk pages that I've seen pop up in my watchlist to remove class values that were not removed or duplicated |blp and |living parameters (apparently fixed now). Super Ψ Dro 21:27, 17 February 2024 (UTC)
Super Dromaeosaurus, can you give some examples? — Qwerfjkltalk 08:17, 18 February 2024 (UTC)
[6] [7]. Super Ψ Dro 11:56, 18 February 2024 (UTC)
These were intentionally left, as they conflicted with the majority. --Redrose64 🌹 (talk) 12:04, 18 February 2024 (UTC)
Yes, that's what Category:Articles with conflicting quality ratings is for. — Qwerfjkltalk 12:16, 18 February 2024 (UTC)
As far as I know Cewbot removes all class ratings and puts the majority one into WPBS. Super Ψ Dro 12:23, 18 February 2024 (UTC)
Super Dromaeosaurus, I'm fairly sure it doesn't. It does put the majority in the WPBS, but it should leave the differing ones. — Qwerfjkltalk 12:30, 18 February 2024 (UTC)
Another avenue possibly worth considering when there's millions of edits to be made is asking a sysadmin to do it. Snowmanonahoe (talk · contribs · typos) 02:38, 1 April 2024 (UTC)

Are we ever going to fix the actual problem or nah

STOP PUNCHING SO MANY HOLES IN THE CARDS!!!!! THEY ARE JAMMING THE WIKIPEDIA AND WE HAVE TO GET THEM OUT WITH A COAT HANGER

There is no other open-source project in the world I'm aware of where modifying the headers in twenty-year-old files causes hundreds of people to get their email inboxes blown up. Here on the English Wikipedia, we seem to (?) think it is fine (?) that it's impossible for anyone to carry out large-scale changes to files unless they do so at a rate -- six modifications per minute??? -- better suited to a PDP-11. Now, unlike some people here, I have never been employed writing production code for the PDP-11, but I suspect that even in 1970 this would have been pretty slow (correct me if I am wrong). Do we have any suggestion or plan or whatever for a way to modify files on a large scale that doesn't result in this same cavalcade of anger and misery happening every time a couple million quotation marks need to be made curly/straight/etc? jp×g🗯️ 18:06, 20 February 2024 (UTC)

Apparently the email issue is fixed; bot edits no longer trigger emails. — Qwerfjkltalk 18:10, 20 February 2024 (UTC)
The watchlist issue is hard to analogize to other systems; I'm struggling to come up with something that would be a direct equivalent; on Wikipedia the product and the source code are the same thing on the same website, something which is true virtually nowhere else. I guess it's like, if somebody made some commits to the GIMP repository changing the way that it did Gaussian blurring, and for some reason you got a notification about this the next time you tried to use the lasso tool. jp×g🗯️ 18:18, 20 February 2024 (UTC)
Fuck me, not receiving any emails is the exact opposite of what I want to happen. Primefac (talk) 18:30, 20 February 2024 (UTC)
An honest question: Are there seriously Wikipedia editors with thousands of Watchlist entries who have e-mail Watchlist notifications turned on and don't know how to configure e-mail filtering? Keeping track of my Watchlist has me busy enough; I really can't imagine getting Watchlist-related e-mail messages. Wow. – Jonesey95 (talk) 19:48, 20 February 2024 (UTC)
I find being able to sort and prioritise my emails to be much easier than doing so in the Watchlist directly, but then again my Wikipedia email address is only used for Wikipedia business. Primefac (talk) 19:56, 20 February 2024 (UTC)
I've added a counter-task to reverse or at least modify this change. Primefac (talk) 10:23, 21 February 2024 (UTC)

Perhaps a long term solution to this problem should be a wishlist item. —k6ka 🍁 (Talk · Contributions) 02:20, 1 March 2024 (UTC)

Probably. In the meantime I've asked for help with a toolforge task at VPT. Primefac (talk) 12:13, 4 March 2024 (UTC)

Speedily-approved page-moving bot??

What the heck User:Primefac? It's been annoying enough for me to see my patience tested by letting my BRFAs sit for months waiting for approval. And here I see Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 28 lightning-speedily approved in what, six days?

Since when it it acceptable to mass=page-move by the terrible kludge called the page-swap process?

This should be required to be an admin-bot which moves pages the technically-correct way. wbm1058 (talk) 10:53, 30 March 2024 (UTC)

Well, if you're willing to write some code for it... — Qwerfjkltalk 12:27, 30 March 2024 (UTC)
Sure, and hopefully you'll be willing to wait months for my code to be approved. – wbm1058 (talk) 12:31, 30 March 2024 (UTC)
There are four BRFAs that have finished a trial, all of which are mine. I'm not sure I see the issue. I will also note that the task in question was not speedy-approved, it went through the normal trial-review process (though I know you are referring to "speedy" as "within a week"). Primefac (talk) 12:44, 30 March 2024 (UTC)
Please list the four relevant BRFAs here, so I can get myself up to speed on the big picture. Thanks. This is a massive change which has been controversial. Previous bold moves of this nature have been reverted. That's been disruptive to my patrols. – wbm1058 (talk) 12:58, 30 March 2024 (UTC)
Tasks 44, 43b, 42, and 39, though admittedly the last one is on hold so I am not really concerned about that one.
As far as Qwerfjkl (bot) 28, it is supported by an RFC and thus does not fit the categorisation of "bold moves". Primefac (talk) 13:01, 30 March 2024 (UTC)
Re: 44, what does "Replacing invisible space characters in short description templates" have to do with changing the naming convention for TV series articles? wbm1058 (talk) 13:20, 30 March 2024 (UTC)
Re: 43b, I don't understand the relevance of "Remove {{linktext}} uses in Korean personal names" either. – wbm1058 (talk) 13:23, 30 March 2024 (UTC)
Re: 42, "add |10k=yes to the project banner {{WikiProject Africa}} on the talk page" is also irrelevant. – wbm1058 (talk) 13:27, 30 March 2024 (UTC)
Re: 39, {{Wikisource author}} is also irrelevant. – wbm1058 (talk) 13:32, 30 March 2024 (UTC)
Clearly there has been a miscommunication. You said initially that my BRFAs sit for months waiting for approval which I took to mean you were waiting on a BRFA to be approved. Primefac (talk) 14:02, 30 March 2024 (UTC)

Category:Articles with redirect hatnotes needing review is getting flooded by this process. One of these bots should be bypassing redirects. – wbm1058 (talk) 13:12, 30 March 2024 (UTC)

Looking at Follow-up RfC on TV season article titles, I see the concerns that I'd run into with the first disruptive attempts to boldly implement this before it was fully approved. I see the DISPLAYTITLE and navigation issues raised, and would like some reassurance that the bot is taking care of all this stuff. A while back my time was wasted when I manually did some of this cleanup, only to find everything reverted. – wbm1058 (talk) 13:48, 30 March 2024 (UTC)

Cleanup will happen, as it always does. Primefac (talk) 14:02, 30 March 2024 (UTC)

WikiData discussion

Hello, please also see

Thanks a lot! M2k~dewiki (talk) 12:13, 31 March 2024 (UTC)

For example, en:American Idol (season 1) is now a redirect to en:American Idol season 1. The redirect en:American Idol (season 1) is still connected to d:Q655900, while the actual article en:American Idol season 1 is now unconnected. M2k~dewiki (talk) 17:58, 31 March 2024 (UTC)
For the (currently 5000) unconncted tv season articles possibly soon duplicate items will be created by a bot, which might have to be merged later. M2k~dewiki (talk) 18:00, 31 March 2024 (UTC)
For unconncted tv season articles please see:
M2k~dewiki (talk) 18:03, 31 March 2024 (UTC)
I'm going to be honest, mate, WD issues are not enWiki issues. Primefac (talk) 18:08, 31 March 2024 (UTC)
@Primefac: enwiki doesn't stand alone. If you don't want to consider 'WD issues', consider that the consequence of this issue has broken all inter-language links for those articles to other language Wikipedias. Thanks. Mike Peel (talk) 18:18, 31 March 2024 (UTC)
My point was that if WD cannot handle a page being moved on enWiki, that is an issue with WD. I have been harangued for page moves before, and I still have no idea the "correct" way to move a page according to WD. And no, I'm not going to go to WD to "move" a page (if such a thing is even possible, I don't edit WD). Primefac (talk) 18:21, 31 March 2024 (UTC)
WD handles page moves just fine, something with this bot's setup was not correct and caused this issue. It's the bot operator's problem to clean it up now. Thanks. Mike Peel (talk) 18:22, 31 March 2024 (UTC)
(edit conflict) What should happen when you move a page is that an edit is made in your name on Wikidata that updates the sitelink. But if the user who performed the move does not have an account on Wikidata (and Qwerfjkl (bot) doesn't) then that doesn't happen. I thought d:User:Krdbot cleaned these cases up, but apparently not. And the view of the enwiki community is largely that enwiki does stand alone. * Pppery * it has begun... 18:24, 31 March 2024 (UTC)
I will be honest, I did not know this, and it explains why this task was such an issue for the WD side of things. If this sort of disconnect is such a problem, I feel like it should be better-publicised, especially for something like a bot that might never leave its home wiki. I am all for getting rid of the stereotype that enWiki plays by its own rules, but if we're not helping ourselves out other folks should probably at least tell us how to play nice(r). Primefac (talk) 18:34, 31 March 2024 (UTC)
Krdbot did clean up several thousand unconnected articles on Wikidata. I think it probably was just overwhelmed by the sheer quantity of moved, but only Krd can explain for sure. * Pppery * it has begun... 18:39, 31 March 2024 (UTC)
I operate User:Pi bot, which creates new Wikidata items for new enwiki articles, amongst other things. Since these move weren't done right, and I got no warning of this bulk change ahead of time, it looks like Pi bot has already created a bunch of new items for the affected articles already this morning, see [8]. Those now all need to be merged... Mike Peel (talk) 18:45, 31 March 2024 (UTC)
I've turned off that Pi bot script for now, until the issue is cleared up. Thanks. Mike Peel (talk) 19:10, 31 March 2024 (UTC)
I always assumed that Wikidata linked to the {{PAGEID}}, not to the {{FULLPAGENAME}}. That's the way I'd design it, so that the link wouldn't be broken by a page rename. --Redrose64 🌹 (talk) 21:07, 31 March 2024 (UTC)
Per d:Wikidata:Project_chat#(5000)_unconnected_television_season_articles_in_the_english_language_wikipedia_after_pages_have_been_moved it sounds like this has been cleaned up, Pi bot will restart creating new items from tomorrow onwards. There's ongoing discussion at phab:T143486 about potential technical ways to avoid this in the future, but it seems this wouldn't have happened if @Qwerfjkl: had made sure that the bot's account was also set up on Wikidata. Interwiki links have always worked through pagenames rather than pageids as far as I'm aware. Thanks. Mike Peel (talk) 19:07, 2 April 2024 (UTC)
Speaking with my BAG hat on, I will do my best to keep this issue in mind for future page-move bot task requests. Primefac (talk) 11:30, 3 April 2024 (UTC)
We should probably add a note somewhere in Bot policy (or some Bot subpage) to that effect. Headbomb {t · c · p · b} 10:04, 5 April 2024 (UTC)

Fully automated edits without BRFA - Request for assistance

I recently came across a large number of automated edits (10,000+) made in October by NmWTfs85lXusaybq without a BRFA (as far as I am aware and can see). I disagree with the edits, for reasons including the ones I posted on their talk page. I don't mean to inflame the situation by posting here, but I feel that I'm somewhat out of my depths regarding knowing what the best thing to do here is, and that input from editor(s) more experienced in this area and/or the Bot Approvals Group would be beneficial, including with regards to the best next steps.

Let me know if there are any queries. All the best, ‍—‍a smart kitten[meow] 13:11, 3 January 2024 (UTC)

Judging from Special:Contributions/NmWTfs85lXusaybq, these edits are ongoing. Seems like an easy case of WP:BOTBLOCK for running an unapproved bot. Headbomb {t · c · p · b} 20:40, 4 January 2024 (UTC)
Warning left on the initial thread. Primefac (talk) 20:45, 4 January 2024 (UTC)
Warning deleted, it looks like. –Novem Linguae (talk) 01:11, 5 January 2024 (UTC)
Per WP:OWNTALK. NmWTfs85lXusaybq (talk) 01:49, 5 January 2024 (UTC)
@NmWTfs85lXusaybq can you commit to not doing these edits without a BRFA? Galobtter (talk) 01:56, 5 January 2024 (UTC)
Sure. NmWTfs85lXusaybq (talk) 01:59, 5 January 2024 (UTC)
I'm cautious to suggest too much in this discussion, as there are other editors (who are much more experienced regarding bots than me) who may well have better ideas of what the next steps in this situation should be. However, I'd like to make an initial proposal that the edits I initially raised concerns about, defined as:

Edits (including pagemoves) made by NmWTfs85lXusaybq between 17 October 2023 and 24 October 2023 (inclusive) that are tagged with [paws 2.2] (OAuth CID: 4664)

be rolled back. This is due to the concerns I described on their talk page[a], and due to them being automated edits run without bot approval or consensus for the task. By my estimation, this is between 24,000-26,000 edits that would be reverted. (I would be happy to submit a BRFA to accomplish this on a bot account, using massRollback.js & a slightly modified massMoveRevert.js.)
I'd also ask if NmWTfs85lXusaybq would mind listing the automated tasks/bot runs that they have previously run on their account, so that they can be retrospectively assessed by the community & the Bot Approvals Group. If there are concerns raised with any of the other automated edits, further proposals (such as the above) can be made.
Everything I've just said, however, comes with the caveat that I am not as experienced in bot matters as other editors, so I will likely defer to members of the BAG if they have any other suggestions and/or take issue with any of what I've said.
All the best, ‍—‍a smart kitten[meow] 16:56, 6 January 2024 (UTC)
I support the idea to roll these edits back (not a vote obvi I just really don't like this), though I'm not a bot-experienced editor, there's really no reason to do this and it makes everything far more confusing. PARAKANYAA (talk) 23:38, 6 January 2024 (UTC)
Mass rolling back did come to mind when I saw what was being done. I would support it too. Headbomb {t · c · p · b} 01:31, 7 January 2024 (UTC)
I support this but I would limit it to the edits from October 20-24; the October 17-19 edits are useful and not worth reverting IMO. * Pppery * it has begun... 03:00, 8 January 2024 (UTC)
To expand on my view of why the Oct 17-19 edits are worth reverting; in my opinion, it’s unhelpful to mass-redirect talk pages of redirects to the talk pages of the target articles. Talk pages of redirects can be useful for discussing the redirects themselves, in addition to (for example) recording previous RfD discussion results. For this reason, I don’t support doing so generally as a blanket measure - without individual consideration as to whether the action is appropriate. (The exception to this is that I support redirecting talk pages in the case of an {{R from move}}, where someone that follows a link to the pre-move article talk page will rightly expect to end up at the current location of the article’s talk page). I also note that WP:TALKCENT says that an editor wishing to implement centralized talk pages should consider first gaining consensus for [the] proposal, which presumably would apply even more so to a mass-centralization such as this; especially when I can’t find a record that existing wider community consensus for such centralization exists. However - to be clear - if consensus is against me on the 17-19 Oct edits being reverted, it is not a problem, and I would still be happy to submit a BRFA to revert the others. All the best, ‍—‍a smart kitten[meow] 14:18, 9 January 2024 (UTC)
I was quite aware of WP:TALKCENT when I did this task. I will never argue that the talk pages of redirects are useless. However, my point is a talk page can't be useful if it's intentionally blanked, no matter if it's associated with a redirect or an article (that's why I moved or tagged the empty talk pages of articles as well). Any empty talk page of redirects doesn't deserve a {{tpr}} tag per Template:Talk_page_of_redirect/doc#Misuse. Moreover, the task of Oct 17-19 edits is the most thanked one without any objection before this thread. NmWTfs85lXusaybq (talk) 14:55, 9 January 2024 (UTC)
I disagree with you on the principle - I think a talk page of a redirect should point to the talk page of its target unless there's a good reason otherwise, but regardless the October 17-19 edits replaced blank pages with redirects - I'm completely failing to see how re-blanking them could possibly be an improvement. * Pppery * it has begun... 16:01, 9 January 2024 (UTC)
information Note: The abandoned talk pages are filtered by only one major edit and the messy talk pages are filtered by lack of section header from Category:Talk pages with comments before the first section. The ones created from anonymous user or inexperienced user (#edits <= 10) are generally against WP:TPG, like Talk:University of Hail. It's better to blank and redirect it to the talk page of its target, which is exactly what I have done, rather than tagging it with {{tpr}}. NmWTfs85lXusaybq (talk) 09:15, 8 January 2024 (UTC)

Notes

  1. ^ including concerns around removing comments from redirect talk pages, moving comments left on a redirect's talk page to a different article's talk page, and unnecessarily redirecting the talk pages of redirects

Other bot runs

I looked through NmWTfs85lXusaybq's other edits tagged as using PAWS. I found:

  1. Early tests from September 15-October 7, 2023 that aren't actual bot runs
  2. September 17: Mass tagging a bunch of talk pages (rightly) as U2 cases. They were later deleted.
  3. October 11: Creating a bunch of "foo, the" -> "the foo" redirects. These seem harmless to me, but anyone who disagrees is welcome to R3 them.
  4. October 12: Various changes to rcat templates on DAB pages. I'm not an expert in this area, but these seem correct to me.
  5. October 14: Tagging redirects for a RfD that was later closed as no consensus
  6. October 15: Adding {{R from unnecessary disambiguation}} to a bunch of redirects. Some of these (i.e United States Agricultural Information Network (USAIN) aren't really unnecessary disambiguation redirects) but this is overall harmless (and small enough it could have been done easily with AWB)
  7. October 17-19: Centralized empty talk page of redirect. This specific bot run replaced all talk pages of redirects that were blank with redirects to their targets, and seems useful to me despite being included in the request to revert (although I agree it deserved a BRFA)
  8. October 20: A bunch of page moves. A smart kitten and others make a reasonable case to revert these, although I'm not convinced it's necessary (there may be few enough to review manually)
  9. October 22 #1: Some more page moves basically identical to the October 20 moves
  10. October 22 #2: For some inexplicable reason Talk:2021 Polish census was created via PAWS
  11. October 22-23: ‎ Centralized abandoned talk page of redirect from anonymous user. This is the meat of the complaint and I concur these edits (which go beyond the above link) need to be mass reverted.
  12. October 24: ‎ Centralized messy talk page of redirect from inexperienced user. These are a (much smaller) extension of the previous run, and should also be reverted.
  13. October 26: Creation of a few redirects to clean up after a page move. Innocuous.
  14. October 27 #1: A re-run of the October 17-19 bot run except applying to pages outside of mainspace.
  15. October 27 #2: Replace blank talk pages of redirects with soft redirects to Commons. Seems useful.
  16. October 29-30: "‎unlink language label for transliteration template in disambiguation pages". Seems useful.
  17. November 5-9: Adding {{Talk page of redirect}} to talk pages of redirects. Seems useful. This run repeats sporadically through the coming months (as recently as January 4), only affecting a few pages each time
  18. November 11: A re-run of "‎unlink language label for transliteration template in disambiguation pages"
  19. November 13: Add reference lists to a bunch of templates. Seems useful
  20. November 24: Mass PRODing of disambiguation pages
  21. November 26: Mass addition of {{One other topic}} to disambiguation pages
  22. December 1: Mass redirection of disambiguation pages (and later set indices) with only one entry. Most of these are useful but this is the bot run that brought us oddities like Walker Elementary School (later deleted at RfD). I'm not sure what to do here, but this could use attention. Many of these edits have been deleted because they redirected a disambiguation page at X containing only X (Y) to X (Y) and then X (Y) was moved to X.
  23. December 3: Moving of template documentation subpages. Innocuous
  24. December 19-20: Mass changes to WikiProject banners. These seem to consist of removing {{WikiProject Disambiguation}} from talk pages of set indices, adding {{WikiProject Anthroponymy}} to talk pages of name pages, and adding {{WikiProject Lists}} to lists
  25. December 21-22: Reclassifying set-indices and lists as list-class rather than disambiguation class in WikiProject banners, and removing the class parameter entirely for articles
  26. January 3: Moving several dozen articles per a RM discussion

* Pppery * it has begun... 02:56, 8 January 2024 (UTC)

So in summary, most edits look good, but you're proposing 11 and 12 be mass reverted? –Novem Linguae (talk) 10:00, 10 January 2024 (UTC)
I'm proposing 8,9, 11, and 12 be reverted. * Pppery * it has begun... 14:32, 10 January 2024 (UTC)
The edits summarized by cleanup before move in 8 and 9 are actually different except that they are all intended to deal with the talk pages of redirect when that of the target doesn't exist. The case Special:Diff/1181304837 proposed by A smart kitten is in 9, not 8. The cases in 8 are generally uncontroversial, as the moved talk page is the only extant page among the talk pages of the target and all sources while most of them contain nothing but {{WPDAB}} and {{Tpr}}. Therefore, a similar argument may still apply: The revert of edits in 8 couldn't be an improvement unless there's a good reason to move the centralized talk page back without leaving a redirect. NmWTfs85lXusaybq (talk) 15:47, 10 January 2024 (UTC)
I was assessing a bunch of unassessed articles earlier and I found a bunch of cases where this editor automatically added WikiProject List to articles that weren't lists. It also was out of the template shell. Unsure how many of those there were but I noticed quite a few PARAKANYAA (talk) 16:49, 10 January 2024 (UTC)
The articles were only tagged with {{WikiProject List}} when they had been categorized as SIA while not tagged with any banner, or at least categorized in one list category, like "Lists of ...". NmWTfs85lXusaybq (talk) 23:50, 10 January 2024 (UTC)
Ah. Well that's someone's problem, but probably not yours then. PARAKANYAA (talk) 17:15, 11 January 2024 (UTC)

Unarchived, at WP:ANI

This was unarchived, but it is also being discussed at Wikipedia:Administrators' noticeboard/IncidentArchive1149#Disruptive editing of disambiguation pages. So as not to split the discussion, it is probably best to discuss it there for the time being. Rgrds. --BX (talk) 18:02, 15 February 2024 (UTC) Link updated post-archive. Primefac (talk) 17:23, 23 February 2024 (UTC)

These are not really that related. ANI is complaining about 22 in my list above. This discussion was originally complaining about 7-12. * Pppery * it has begun... 18:09, 15 February 2024 (UTC)
Noting that the ANI thread has now been archived. Best, ‍—‍a smart kitten[meow] 17:21, 23 February 2024 (UTC)

Proposal closure

I've thought about requesting formal closure of the proposal above, given that discussion seems to have died out. However, I'm conscious that there aren't that many comments in response to the proposal, which may make it difficult to infer a strong consensus (especially for >24,000 edits). I'd therefore appreciate it if more experienced editors than myself could comment on what might be the best next step here; including whether it's worth notifying any other venues (e.g. WP:AN) of this mass-rollback proposal, in order to hear more editors' opinions on the matter. All the best, ‍—‍a smart kitten[meow] 17:21, 23 February 2024 (UTC)

Noting here for reference my post at WP:BOTREQ#Bot to mass-undo edits & pagemoves. All the best, ‍—‍a smart kitten[meow] 18:45, 6 March 2024 (UTC)
I've asked for more input at VPP. Snowmanonahoe (talk · contribs · typos) 01:41, 2 April 2024 (UTC)
Well, that didn't work. Snowmanonahoe (talk · contribs · typos) 14:44, 15 April 2024 (UTC)

Well this may be pretty poor timing judging by the threads above on this page, but… :)

I'm about to run PWB's replace.py on my main account (from PAWS) over the ~267 articles in Category:Child Ballads to update a bunch of sisterlinks to Wikisource after a page reorganisation there. The changes will be variations on this edit; I'll be manually checking and approving each edit; and the rate will be as high as I can possibly make while still manually checking (i.e. not very, on average).

So far as I know this should require no particular approval (much less BRFA), but… 1) I haven't been paying attention to enWP for a couple of years (and I note WP:BOTPOL has been rather actively edited lately), so I could be out of touch. 2) It's likely I'll need to do similar cleanup on enWP, after wielding the mop over on enWS, in the future so I figure better safe than sorry.

So… thumbs up? No don't do it? RFC? BRFA? Xover (talk) 17:50, 18 April 2024 (UTC)

267 edits is a drop in the bucket, we wouldn't even blink if someone did that on AWB. Primefac (talk) 18:15, 18 April 2024 (UTC)
That's what I figured. Thanks. Xover (talk) 18:38, 18 April 2024 (UTC)
More specifically, the manual checking of each edit makes it fall under WP:SEMIAUTOMATED, and planning to be not very fast helps avoid trouble too. Use a good edit summary and it should be fine. Anomie⚔ 21:32, 18 April 2024 (UTC)

Blocked user-operated bots

I have an idea that may be unpopular, but I suggest that bots operated by blocked users should not just be blocked, but should instead be "adopted" to a new owner who will then refurbish it, rename it, and make it do new tasks. I see no reason to block innocent bots that have not done anything wrong because their owners have been blocked, instead it just slows down the project's productivity. 2003 LN6 19:30, 8 April 2024 (UTC)

We have plenty of bots, inactive or otherwise, who have had their tasks taken over by someone else. If the code is available there is no reason to take over the bot; just copy over the code. Primefac (talk) 19:40, 8 April 2024 (UTC)
It takes a lot of work to adopt (on Toolforge) or fork a bot. The idea of blocking first due to the bot operator losing trust, then other folks taking their time and adopting or forking the bot if the bot is important and if it is hosted in our ecosystem and/or has open source code, is already practiced. The idea of usurping an existing Wikipedia bot account of a blocked user seems unnecessary since a new account can be created to run the same program code as the original bot. –Novem Linguae (talk) 19:40, 8 April 2024 (UTC)
That is not a good idea because bots are just an extension of their operator, so the account should certainly not be just handed over. Of course the task can be replaced by anyone that wants to under a different bot account if it is still needed. — xaosflux Talk 10:29, 1 May 2024 (UTC)

Inactive bots (May 2024)

Bot account Operator(s) Last edit (UTC) Last operator activity (UTC)
Thehelpfulbot Thehelpfulone 26 Dec 2012 01 Mar 2022
TheMagikBOT TheMagikCow 21 Dec 2018 13 Apr 2022
PowerBOT 力 01 Aug 2019 30 Apr 2022

Per User:MajavahBot/Bot status report. * Pppery * it has begun... 02:00, 1 May 2024 (UTC)

Notifications have been left. Primefac (talk) 08:47, 1 May 2024 (UTC)
Is it time to process this now? * Pppery * it has begun... 15:21, 10 May 2024 (UTC)
It would appear so.  Done. Primefac (talk) 15:25, 10 May 2024 (UTC)
The unflagged bots list has been updated. --Redrose64 🌹 (talk) 17:36, 10 May 2024 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Bots/Noticeboard/Archive_19&oldid=1228799516"