Wikipedia:Bots/Noticeboard/Archive 19

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

Flooding watchlists

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

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

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

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

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

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

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

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

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

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

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

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

Tag discussion

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

User script

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

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

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

A decentralized approach to solve the watchlist problem

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

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

Randomize

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

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

A semi-centralized approach to solve the watchlist problem

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

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

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

Cosmetic edits

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

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

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

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

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

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

Why is Qwerfjkl (bot) signing my post?

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

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

Request for global bot flag for CommonsDelinker

Hello!

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

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

Best regards --Superpes15 (talk)

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

Lifting the ban?

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

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

Inactive bots (February 2024)

It's that time again:

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

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

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

Missing bots from Toolforge's Grid Engine shutdown

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

User:MajavahBot/Bot status report can be reviewed locally for recently-inactive bots. Izno (talk) 00:41, 22 February 2024 (UTC)

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)
  • You might think it's unreasonable but these are the rules and they apply to everyone. It's grossly unfair to leave your bot running doing the same thing that got Cewbot blocked.—S Marshall T/C 14:31, 17 February 2024 (UTC)
    • S Marshall, I'm running the bot at about a third of the rate of what Cewbot was editing at. — Qwerfjkltalk 14:33, 17 February 2024 (UTC)
  • S Marshall, I think it is indeed undesirable to have this task at 6 epm. It would prolong it for a very long time, months to over a year as I've understood. I think 20-30 epm can be reasonable, it will be a third/fifth of what it was, and end this in a few months. I think seeing these edits still by late 2025 would be really annoying. Super Ψ Dro 14:32, 17 February 2024 (UTC)
  • Kanashimi, I have unblocked your bot, but both you and Qwerfjkl must make sure that the edit rate stays as close to 20epm as possible. This is a rate at which is quick enough to not drag the task on for years, but also slow enough that it will not flood watchlists. If the rates start rising again I do not think the task will be able to continue. Primefac (talk) 15:04, 17 February 2024 (UTC)
    Thank you. May I ask what speed I can run at? I'm running at 10s/edit now. Kanashimi (talk) 15:10, 17 February 2024 (UTC)
    Oh sorry, I see 20 epm. Kanashimi (talk) 15:10, 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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Bots/Noticeboard/Archive_19&oldid=1221720130"