From Wikipedia, the free encyclopedia
    Bots noticeboard

    Here we coordinate and discuss Wikipedia issues related to bots and other programs interacting with the MediaWiki software. Bot operators are the main users of this noticeboard, but even if you are not one, your comments will be welcome. Just make sure you are aware about our bot policy and know where to post your issue.

    Do not post here if you came to

    Fully automated edits without BRFA - Request for assistance[edit]

    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)[reply]

    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)[reply]
    Warning left on the initial thread. Primefac (talk) 20:45, 4 January 2024 (UTC)[reply]
    Warning deleted, it looks like. –Novem Linguae (talk) 01:11, 5 January 2024 (UTC)[reply]
    Per WP:OWNTALK. NmWTfs85lXusaybq (talk) 01:49, 5 January 2024 (UTC)[reply]
    @NmWTfs85lXusaybq can you commit to not doing these edits without a BRFA? Galobtter (talk) 01:56, 5 January 2024 (UTC)[reply]
    Sure. NmWTfs85lXusaybq (talk) 01:59, 5 January 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]


    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[edit]

    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)[reply]

    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)[reply]
    I'm proposing 8,9, 11, and 12 be reverted. * Pppery * it has begun... 14:32, 10 January 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    Ah. Well that's someone's problem, but probably not yours then. PARAKANYAA (talk) 17:15, 11 January 2024 (UTC)[reply]

    Unarchived, at WP:ANI[edit]

    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)[reply]

    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)[reply]
    Noting that the ANI thread has now been archived. Best, ‍—‍a smart kitten[meow] 17:21, 23 February 2024 (UTC)[reply]

    Proposal closure[edit]

    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)[reply]

    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)[reply]
    I've asked for more input at VPP. Snowmanonahoe (talk · contribs · typos) 01:41, 2 April 2024 (UTC)[reply]
    Well, that didn't work. Snowmanonahoe (talk · contribs · typos) 14:44, 15 April 2024 (UTC)[reply]

    Please block Cewbot[edit]

    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)[reply]

    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)[reply]
    The bot was already blocked over this back in January [1]. 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)[reply]
    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)[reply]
    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)[reply]
    Whatever fraction equals 6 edits per minute? MrOllie (talk) 23:12, 16 February 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    • 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)[reply]
      The bot is making 71 and 58 edits per minute. – DreamRimmer (talk) 01:05, 17 February 2024 (UTC)[reply]
      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)[reply]
      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)[reply]
      @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)[reply]
      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)[reply]
      @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)[reply]
      "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)[reply]
      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)[reply]
      It seems that 20-30epm would be acceptable based on the above discussion. Primefac (talk) 09:35, 17 February 2024 (UTC)[reply]
      @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)[reply]
      I think 12EPM would be fine. – DreamRimmer (talk) 09:03, 17 February 2024 (UTC)[reply]
      ...and if you want to increase it in the future, it should be discussed before implementation. – DreamRimmer (talk) 09:07, 17 February 2024 (UTC)[reply]
      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)[reply]
    • 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)[reply]
      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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    @@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)[reply]
    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)[reply]
    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)[reply]
    @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)[reply]
    Yes.—S Marshall T/C 13:25, 17 February 2024 (UTC)[reply]
    • 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[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    Fair enough. Usedtobecool ☎️ 11:06, 17 February 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    (I wrote something in parens above about that.) —Cryptic 13:18, 17 February 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    GreenC, just using async JavaScript requests is pretty fast (i.e. parallel processing like you said). — Qwerfjkltalk 19:51, 17 February 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    @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)[reply]
    I'm referring to this comment. — Qwerfjkltalk 13:57, 17 February 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    MrOllie, yes, I'm trying to reduce the edit rate right now. — Qwerfjkltalk 14:20, 17 February 2024 (UTC)[reply]
    ... if I can work out how to. It's suprisingly difficult to do in pywikibot. — Qwerfjkltalk 14:39, 17 February 2024 (UTC)[reply]
    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)[reply]
    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)[reply]

    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)[reply]

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

    Please block Qwerfjklbot[edit]

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

    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)[reply]
    Please do the sensible thing and just turn the task off voluntarily until consensus is reached. MrOllie (talk) 14:13, 17 February 2024 (UTC)[reply]
    I endorse this. Super Ψ Dro 14:27, 17 February 2024 (UTC)[reply]
    • 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)[reply]
      • 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)[reply]
    • 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)[reply]
    • 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)[reply]
      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)[reply]
      Oh sorry, I see 20 epm. Kanashimi (talk) 15:10, 17 February 2024 (UTC)[reply]
    When will this end at 20 epm? Super Ψ Dro 15:21, 17 February 2024 (UTC)[reply]
    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)[reply]
    • Primefac, why are these bots exempt from the policy?—S Marshall T/C 15:18, 17 February 2024 (UTC)[reply]
      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)[reply]
      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)[reply]
      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)[reply]
      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)[reply]
      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)[reply]

      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)[reply]
      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)[reply]
      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)[reply]
      For example, ClueBot NG's tasks are urgent.—S Marshall T/C 18:22, 17 February 2024 (UTC)[reply]
      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)[reply]

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

    Was it worth it[edit]

    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)[reply]

    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    Yes, you have a point. Kanashimi (talk) 17:02, 17 February 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    Super Dromaeosaurus, can you give some examples? — Qwerfjkltalk 08:17, 18 February 2024 (UTC)[reply]
    [2] [3]. Super Ψ Dro 11:56, 18 February 2024 (UTC)[reply]
    These were intentionally left, as they conflicted with the majority. --Redrose64 🌹 (talk) 12:04, 18 February 2024 (UTC)[reply]
    Yes, that's what Category:Articles with conflicting quality ratings is for. — Qwerfjkltalk 12:16, 18 February 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

    Are we ever going to fix the actual problem or nah[edit]


    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)[reply]

    Apparently the email issue is fixed; bot edits no longer trigger emails. — Qwerfjkltalk 18:10, 20 February 2024 (UTC)[reply]
    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)[reply]
    Fuck me, not receiving any emails is the exact opposite of what I want to happen. Primefac (talk) 18:30, 20 February 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    I've added a counter-task to reverse or at least modify this change. Primefac (talk) 10:23, 21 February 2024 (UTC)[reply]

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

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

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

    Speedily-approved page-moving bot??[edit]

    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)[reply]

    Well, if you're willing to write some code for it... — Qwerfjkltalk 12:27, 30 March 2024 (UTC)[reply]
    Sure, and hopefully you'll be willing to wait months for my code to be approved. – wbm1058 (talk) 12:31, 30 March 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    Re: 39, {{Wikisource author}} is also irrelevant. – wbm1058 (talk) 13:32, 30 March 2024 (UTC)[reply]
    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)[reply]

    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)[reply]

    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)[reply]

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

    WikiData discussion[edit]

    Hello, please also see

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

    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)[reply]
    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)[reply]
    For unconncted tv season articles please see:
    M2k~dewiki (talk) 18:03, 31 March 2024 (UTC)[reply]
    I'm going to be honest, mate, WD issues are not enWiki issues. Primefac (talk) 18:08, 31 March 2024 (UTC)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    (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)[reply]
    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)[reply]
    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)[reply]
    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 [4]. Those now all need to be merged... Mike Peel (talk) 18:45, 31 March 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

    Blocked user-operated bots[edit]

    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)[reply]

    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)[reply]
    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)[reply]

    Meatbot sisterlink updates[edit]

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

    I'm about to run PWB's 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)[reply]

    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)[reply]
    That's what I figured. Thanks. Xover (talk) 18:38, 18 April 2024 (UTC)[reply]
    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)[reply]