There is a current thread at WP:VPPOL#Huggle & Rollback which I think deserves some consideration here. Ignoring the specific user (which can be discussed there) and specific thread (that WP:PERM is supposedly a problematic process), a user was sufficiently technical to modify Huggle to remove the permissions check for rollback. He subsequently used that software on wiki.

Another tool this impacts would be WP:AWB, which implements a check on the CheckPage for non-admins and bots, or that you're an administrator by default.

I see this choice as WP:GAMING. At least two other users have either said this is not GAMING or did not consider this might be GAMING.

Should this policy have anything to say about scripted tools being modified to circumvent social controls on the tool that happen to be implemented in the tool directly as being GAMING (rather than e.g. WP:AWB having the social controls external to that software in WP:AWBRULES), or is the fact it is GAMING actually a common sense conclusion and we just found two users who came to a different conclusion? --Izno (talk) 21:42, 18 December 2020 (UTC)

Copying my response over:

I think this is really problematic to add into BOTPOL. How much modification of AWB is acceptable until it's no longer considered AWB & I can use AWB without requesting access to AWB? What if I make my own script from scratch to do the same thing (a particular semi-automated edit)? What if I base this script off AWB's regexes? Similar to the Huggle situation. Lines can't be drawn here, which is why making a BOTPOL restriction for this is difficult. If the issue is with rollback, apply the restriction to that guideline, but honestly I think nothing should be done unless it can be shown that the edits themselves are disruptive, problematic anti-vandalism edits. This is also the only enforceable remedy. Also, if the edits aren't problematic I don't see what the big issue is. And it's quite rare that someone is actually capable of, and does, edit the source of a tool and recompile it, so it's not the kinda thing worth legislating over I think - more harm than good will come of it. ProcrastinatingReader (talk) 21:56, 18 December 2020 (UTC)

To add: By releasing a tool publicly under a permissible license, you accept that people can edit it. We also have no policy requiring people to get any particular right before they can use semi-automated tools in general. Thus, whether one uses a particular tool, a modified version of that tool, a derivative of that tool, or their own totally custom tool, these are all equivalent things. It's somewhat illogical (and hence unenforceable, or only arbitrarily enforceable) to try to restrict how much editing someone can do to a tool, until they've done too much and it's a separate tool. Heck, how do you even prove how much someone has edited a tool? What if they've recoded half of the tool and removed the permission requirement, deciding that they don't want their derivative to have that restriction. Is this now unacceptable, too? ProcrastinatingReader (talk) 22:01, 18 December 2020 (UTC)

• Two things, firstly the software is under an open license, they can do practically whatever they want with it. If they want to remove the check or rollbacker, they can. Secondly: All bot-like editing is covered under BOTPOL. If a user is using an editing tool to edit in a manner that does not rise to the threshold of being a bot/bot-like/automated per MEATBOT, there is not currently a policy that forbids it. If a user is using an editing tool to make the actions they make on-wiki easier, and doesnt require specific permissions to do so, there isnt a policy that forbids it. If we want to prevent people using editing tools that *mimic* an on-wiki action like rollback, we need to a)get consensus editors should not be performing tasks that normally require a user-right in order to perform and b)add that wording to a relevant policy. Botpol is probably the most likely culprit here, as its the one that most closely deals with automated tools. For what its worth, I personally do not think editors should be doing tasks that mimic rollback, without the relevant right. The point of being *granted permission* to do something is that its a check on if the person has the judgement to do a thing, not just the technical ability. Only in death does duty end (talk) 22:25, 18 December 2020 (UTC)
• Everyone is free to modify any open source software however they want, including the checking of permissions. We, however, are free to a) prohibit the use of such software b) indef-block those who do use it per WP:DE. In practice? A WP:DE block will be handed out to those who bypass the checks and edit disruptively with it. And if User:Example removes the permission from Huggle but doesn't edit disruptively with it, who cares. WP:BOTPOL isn't what governs this, this is WP:DE and WP:CLUE stuff. Headbomb {t · c · p · b} 22:55, 18 December 2020 (UTC)
• Was approval needed in the first place? In the case of "rollback with Huggle" the question has two parts:
  1. Can an un-approved editor use Huggle to effect rollbacks? and
  2. Can an un-approved editor use another tool or make his own from scratch to effect rollbacks?

The answer to the first question is clearly "no." The answer to the second appears to be "yes." If this is true, then "modifying Huggle to do rollbacks" should be allowed. If it is not true, then the language of the Bot policy needs to be clarified to prohibit using any tool to effect a rollback except that which is provided by Wikipedia itself if you do not have that user-right.

As a side-note, any editor, logged in or not, can effect a rollback by viewing the edit history, selecting the most recent edit by a different editor, opening it, and saving it. This can be done quite rapidly, without thought, and, as it says in WP:Bot policy, with all of the responsibility that would come with using an automated tool. I mention this only to say that if we ban automated and semi-automated tools from effecting a rollback, we haven't prevented people from rolling back edits without thinking about it. davidwr/(talk)/(contribs) 🎄 23:25, 18 December 2020 (UTC)

Rollback-specific considerations should be built into WP:ROLLBACK. WP:CLUE and WP:DE covers the rest. Headbomb {t · c · p · b} 23:32, 18 December 2020 (UTC)

@Davidwr: "rollback" is a specific technical operation that occurs server-side, no editor can initiate an rollback without rollback permissions. Note, this has nothing to do with "reverting" only "rollback"ing. — xaosflux ^Talk 00:11, 19 December 2020 (UTC)

The issue here is not WP:DE. See User talk:ChipWolf. The background to this section is that an editor was indef blocked for making 3 correct (as stated by an admin there) Huggle reverts, whilst not being a rollbacker. There is nothing disruptive about it - by definition, 3 good reverts did not disrupt progress toward improving an article or building the encyclopedia - although one may well be on a shorter leash if they mess up with it and hence it is inadvisable. Either way, I think this is a WP:ROLLBACK issue (as I said at VPP). afaik there is no PAG supporting that block, and a block on the basis of a possible 'implicit consensus' (especially without warning) is meh. ProcrastinatingReader (talk) 23:37, 18 December 2020 (UTC)

@Davidwr: as far as I gather, the line here seems to be with the frequency at which a tool can edit. Presumably a tool would be considered to require rollback if the frequency it can edit is over some acceptable threshold. I would imagine this should be achieved with API ratelimiting (for users without explicit permission) rather than a social policy. A blanket prohibiting of all tools except those on a whitelist would cause more problems imho ~ Chip🐺 01:10, 19 December 2020 (UTC)

The issue here is not frequency, and blocks for this haven't been limited to Huggle/rollback. See eg this. The issue seems to be that some people don't like other people editing source code to disable access limitations set by tool developers, and view this as "gaming". If you made your own high frequency editing tool and used it properly presumably nobody would care; you'd be limited solely by policy on WP:ASSISTED, and WP:MEATBOT if disruptive. ProcrastinatingReader (talk) 01:20, 19 December 2020 (UTC)

Hopefully we can establish where that line is; as I mentioned briefly below, if people truly do have an issue with modifying open-source tools with restrictions for their own use, how would this be effectively implemented in policy? There is of course the issue of how bastardized must the code become before it becomes acceptable to use, and how would this be enforced to ensure fairness? I'm of the opinion it would be almost impossible to enforce as the operations these tools have are essentially identical, they just enable the user in different ways which is completely transparent to other editors. ~ Chip🐺 01:39, 19 December 2020 (UTC)

• @Izno: Your initial summary doesn't seem to have anything to do with "bots" so I don't think the bot policy is at issue. If this software was being used by an actual bot it still wouldn't really matter - as long as the bot was operating within it's approved tasks. As far as the possible actual issue - if anyone is editing disruptively they should be dealt with as a disruptive editor regardless of if they are using scripts, the webui, the api, their own custom software, or someone else's software. If the person is doing bot-like-editing without being an approved bot - that is already unacceptable, we shouldn't need new special rules to control it. — xaosflux ^Talk 00:06, 19 December 2020 (UTC)

  I think Izno is talking about amending WP:ASSISTED to say something like "Tools where the developer has attempted to restrict access to certain editors must only be used by those editors. Attempts to circumvent these controls is a violation of this policy." (which I think is a bad idea for reasons above) ProcrastinatingReader (talk) 00:13, 19 December 2020 (UTC)

  Don't think we need a policy on that at all - if someone is being disruptive that is already enough reason to step in, and if they are not then why care?. — xaosflux ^Talk 01:03, 19 December 2020 (UTC)

  This was my initial thought and it circles back to the open-source discussion; at what point is the tool still considered to be the same tool, and indeed how would you possibly prove or enforce such a policy? Unless there's harm to the wiki or intention to harm, I don't think other editors should care ~ Chip🐺 01:27, 19 December 2020 (UTC)

  I agree with Xaosflux: if someone's usage of {huggle, AWB, a pywikibot script, their own completely custom tool} is disruptive, then handle it as any disruptive editing. If their edit rate is so high that they are flooding watchlists or recent changes, tell them to get a bot flag. We already have very clear policies to handle both of those cases, regardless of what tool is used. If they aren't being disruptive, then who cares? Using Huggle without permission is no more disruptive than using pywikibot without permission. The checkpage is good to weed out complete newbies, but anyone who is capable of recompiling Huggle or AWB is also capable of reading the Mediawiki API docs and writing their own tool. Users are allowed to modify free software. That's probably the main point of "free software", and it is expressly allowed according to the licensing information distributed as part of Huggle. We should not be indef blocking editors in good standing just because they used a piece of free software without "permission". ST47 (talk) 03:44, 19 December 2020 (UTC)

  @ST47: Apologies for my lateness, I've just found this discussion. I'm afraid I don't fully agree here. The problem with simply waiting for the unauthorized user to cause disruption is because with these kinds of tools, if the user does become disruptive, then they become very disruptive. Not only might we have to block, but we would potentially have to check hundreds upon hundreds of edits that were submitted in a short time in order to respond to the disruption. Yes, it is "free software", meaning the licensing allows editors to fork and modify the software just like CC BY-SA allows editors to copy the contents of one article and paste it overtop another article as long as they supply attribution—but that doesn't mean it's always a good idea. Just because a user is technically skilled enough to recompile a tool like Huggle does not necessarily mean they can be trusted to use it responsibly. If an editor was denied access to Huggle or AWB via traditional means, presumably there is a good reason for doing so (admin error does happen, but technical circumvention surely isn't the solution to that). Mz7 (talk) 06:01, 27 December 2020 (UTC)

  I should also clarify that I don't necessarily think blocking is the first resort in a case where an editor has done this kind of circumvention, but I am concerned that we seem to be legitimizing this kind of circumvention where it should be discouraged or prohibited. Mz7 (talk) 06:12, 27 December 2020 (UTC)

  AWB is used to do find+replace the same as pywikibot. I can write a few lines of code on top of pywikibot to do a semiauto find+replace, without using AWB/JWB, and it’s totally acceptable without any authorisations. Pywikibot has no checkpage. Or maybe I can write my own API requests, as ProcBot does. It’ll be at the same (or faster) speed, thus same/more “damage”. So the idea that one can write that code and it’s all ok, but cannot edit AWB code, is illogical imho. Besides, where do you draw the line if we’re now making developer source code policy? If pywikibot tomorrow says “users must be +sysop to use this tool” 95% of bots have to shut down their operations? This is why I say I don’t think anybody advocating for this position has really thought this through. ProcrastinatingReader (talk) 11:47, 27 December 2020 (UTC)

  @ProcrastinatingReader: I don't buy this slippery slope argument. If pywikibot tomorrow says that users must be +sysop to use this tool, that would of course be ridiculous, and we would have a discussion to overturn that (note: the proper response would be discussion). However, requiring preauthorization to use Huggle and AWB is a longstanding community expectation on this project, and it makes no sense that we are allowing editors to intentionally skirt around that expectation. (Indeed, in my view, even if we say here that developers can't unilaterally impose enforceable technical restrictions on their tools, the rollback and check page requirements in the narrow context of Huggle and AWB are no longer merely "developer source code", but full-fledged community expectations.)

  With respect to your find+replace pywikibot example, it seems to me that the reason why we don't have a check page currently for pywikibot is because pywikibot requires a nontrivial amount of technical skill to use properly, and historically only seasoned editors are interested enough to learn it, so we haven't bothered with any kind of pre-check. As soon as any tech-savvy LTA figures out how to use pywikibot on a regular basis to disrupt the project on a wide scale (which is certainly not beyond the realm of possibility, and me saying this might honestly be WP:BEANS), I suspect the community will look favorably on imposing some kind of restriction on pywikibot usage. In other words, pywikibot represents more the exception than the norm in this area, and I can't help but see this as a sort of WP:OTHERSTUFFEXISTS situation. Mz7 (talk) 19:23, 27 December 2020 (UTC)

  This is a policy discussion, not a deletion discussion, so OSE is quite valid imo. It’s bad policy making to not consider the broader effects of a policy. I don’t see what’s so legitimate about a RB restriction and illegitimate about a sysop one. And tbh, if one removes the tag on AWB and maybe disables genfixes it’s pretty hard / impossible to tell if AWB is used or pywikibot or raw API requests. And imo I don’t think it matters. But I’ve said my piece, I think. ProcrastinatingReader (talk) 00:01, 28 December 2020 (UTC)

  Anyone capable of writing a for loop can cause widespread disruption. Using pywikibot and most other tools requires more of programming familiarity rather little familiarity with Wikipedia, or in other words, they don't need to be "seasoned editors". It isn't possible to restrict pywikibot usage by policy because it isn't possible in the first place to make out who is using pywikibot. Similarly, for Huggle and other tools, if someone hacks the tool and makes it use different tags and edit summaries than what the tool normally uses, it's impossible for anyone to tell they're using that tool. Policy should always be enforceable, disallowing Huggle forks isn't an enforceable policy. It can at best be a "discouraged practice". – SD0001 (talk) 17:37, 28 December 2020 (UTC)

  Hmm, that is a good point. I suppose it is always possible for editors to obfuscate their tool activity to make it look like they're manually editing, and there is little we can do beyond restricting API editing in and of itself. On the other hand, it is possible for people who have been blocked indefinitely to simply return a few months later under a new username and try to obfuscate their activity so they remain undetected—that doesn't mean this behavior can't be prohibited by policy. At the very least, I would be satisfied if the outcome of this discussion is a clear understanding that this behavior isn't legitimate—i.e. if a user is caught to have hacked Huggle with the express intent of circumventing the rollback restriction, they should be asked to stop. Mz7 (talk) 23:04, 28 December 2020 (UTC)

• Hypothetical situation to think about as we decide this question: What if a non-Wikipedia editor creates a semi-automated tool the can do reverts very fast, as fast as or faster than Huggle. Let's say he does this because he needs it on a non-WMF project that uses Wikimedia software. Now let's say he publishes it in some form. Maybe he sells it, maybe he gives it away "free as in beer." Maybe he open-sources it. It doesn't matter. It's out there. If the solution we come up with doesn't at least acknowledge this possibility, then it is not well thought-out. "Acknowledging the possibility" may be as simple as "kicking the can down the road" saying "yeah, this could happen, if it does, we will address it at that time, in the meantime, we'll let the issue sit in our minds to percolate so we are ready to discuss it when the need actually arises." But the possibility should at least be acknowledged - that is, whether or not to "kick the decision down the road" when it comes to software that doesn't exist yet - should be intentional and not the result of overlooking something. davidwr/(talk)/(contribs) 🎄 19:39, 27 December 2020 (UTC)

  I edit-conflicted with you, so my response covers a fair amount of "response" to your situation, but as a TLDR, it doesn't matter what they're using - if it's disruptive, we sanction them. If it's not, then it's not. Primefac (talk) 19:43, 27 December 2020 (UTC)

  I see it as a case-by-case approach where we discuss new tools as they arise. If the new tool offers functionality identical to Huggle, I would probably support restricting the tool to rollbackers as a community decision. My understanding of this discussion, however, is more about users who deliberately evade some kind of longstanding restriction on an existing tool, which I claim is easy to tell apart from someone who in good faith creates a new tool from scratch. The key here is intention. Are they intending to get around a longstanding community expectation, or are they legitimately intending to build a new tool to contribute to the encyclopedia? If it's the former, then I think they should be asked to stop and request the relevant permission first, which usually shouldn't be a big deal if they are truly trustworthy enough to use the tool responsibly. Mz7 (talk) 22:21, 27 December 2020 (UTC)

• If a user is causing disruption, it doesn't matter if they are using AWB/Huggle/Twinkle or some "hacked" variant of it, they will be sanctioned. We've had editors that were using their own scripts to do high-speed editing; some were indeffed for disruption, others finally figured out that the community was serious and "slowed their roll" so to speak. In my mind, the specific tools don't matter, it's the implementation that is the problem. Saying something along the lines of "you can only use AWB and not a single other thing to do mass editing" is, in my mind, dumb, and likely the reason why WP:MEATBOT says nothing about specific tools. Primefac (talk) 19:43, 27 December 2020 (UTC)
  • MEATBOT's origin goes even further than that. Some people were mass-creating articles in a bot-like manner, but claiming they weren't using any automation at all as an attempt at defense. The main discussion leading up to the addition was Wikipedia talk:Bot policy/Archive 24#Clarification regarding high-speed human editing. Anomie⚔ 14:48, 28 December 2020 (UTC)

This is still happening and still a massive problem, especially where the editors concerned are autopatrolled. FOARP (talk) 10:04, 3 April 2021 (UTC)

As Primefac said above, disruptive editing (automated or not) can be adequately dealt with by existing policies, as can the use of unauthorised bots or bot-like editing. I'm not sure amending BOTPOL will help at all. ƒirefly ( t · c ) 10:46, 3 April 2021 (UTC)

I feel this is pretty obvious, but this discussion has highlighted that it is possible less than entirely obvious, that cutting/pasting a sentence and changing one word in it is "semi-automated content page creation". For this reason I'm going to do a small, bold edit to say as much. Please WP:BRD if you disagree. FOARP (talk) 09:48, 3 April 2021 (UTC)

That's rarely how mass creation happens, and that's not an example of "semi-automation". So I don't find the example very helpful, since this is meant to be very general section, and apply to all mass creations. WP:MEATBOT covers the rest, including mass copy-pasting. Headbomb {t · c · p · b} 11:08, 3 April 2021 (UTC)

The examples I've been looking at lately of mass-creation have all been of the cut-paste variety. It may be that there are many others that I haven't seen of course. E.g., the Iranian "village" case. In every case the creator denies completely that either MEATBOT or MASSCREATION apply to what was done, even in cases where the articles were being created at a rate more than 50 or even 100 per day and consisted of the same cut/pasted sentence with one word or two words changed. Were they right to say there was no requirement to seek consensus before doing that? FOARP (talk) 16:14, 3 April 2021 (UTC)

The purpose of MEATBOT, as I understand it, is to prevent wikilawyering in dispute resolution (eg ANI). Such that if the community thinks the activity appears bot-like it can be considered as such, regardless of whether a bot was actually used or not. So whether the creator denies they used a bot becomes somewhat moot. The specific means of automation (a bot changing the word or a person doing so by hand) also becomes moot. ProcrastinatingReader (talk) 16:51, 3 April 2021 (UTC)

"In every case the creator denies completely that either MEATBOT or MASSCREATION apply" and in every case, the creator is wrong about it. Headbomb {t · c · p · b} 17:00, 3 April 2021 (UTC)

I came here spurred by what I saw in the same two ANI threads. WP:MASSCREATE basically says don't use (semi)automated tools to create content pages without approval, and it appears that the emphasis is commonly perceived to fall on the automated part. In the Turkish villages ANI cases, for example, there was a sub-thread where people tried to figure out whether the creator had used automation, with the understanding that it's bad if he had, and kosher if he hadn't (Incidentally, I think that's upside down: it would have been infinitely better if he had used automation because that would have meant less room for human error). I believe that was barking up the wrong tree. What made this mass creation disruptive was not the presumed nature of the tools used, but the simple fact that it was an instance of mass creation. The problem with the resulting articles was that they were based on a rubbish source, and that – possibly – some might not be notable. None of that appears to have been helped by the fact that the mass creation proceeded at a slow pace over several weeks.

This obviously goes beyond the scope of the bot policy, but we should have something, somewhere, telling editors that if they want to create more than n articles of a single type, they should seek consensus first. – Uanfala (talk) 00:03, 6 April 2021 (UTC)

I've created an essay at Wikipedia:Substantive content about topics that don't include any actual content which could be discussed with regards to MASSCREATE. Crouch, Swale (talk) 17:09, 28 June 2021 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Moved to Wikipedia:Bots/Noticeboard

— xaosflux ^Talk 10:47, 1 July 2021 (UTC)

I was asked on my bot's talk whether I could not mark some of my bot's edits as bot edits. Is there any policy or guidance or convention on when not to mark a bot's edit as a "bot edit"? Just want to make sure I won't get in trouble for not doing so. – wbm1058 (talk) 04:03, 1 July 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

 You are invited to join the discussion at Wikipedia talk:Notability § Adding one new thing to the current SNG text. {{u|Sdkb}} ^talk 05:57, 16 July 2021 (UTC)

I don't see a good place to put this in that discussion, so I'll reply here. Feel free to link this if appropriate.

As far as WP:MASSCREATE and WP:MEATBOT, I don't think we need much if any change here. Further guidance on what sorts of sourcing is valid for a mass creation task would be better in other policies or guideleines, with a "see also" added to WP:MASSCREATE. I also don't think the proposal there is redundant to WP:MASSCREATE: it purports to establish a consensus on what sort of sourcing and/or level of content is sufficient for a mass creation task, which the bot policy does not (and IMO should not) touch on. Anomie⚔ 12:05, 16 July 2021 (UTC)

I have boldly changed the wording of the policy to read that human editors "should not" make large-scale cosmetic edits. Please feel free to revert. Enterprisey (talk!) 04:03, 7 January 2022 (UTC)

I've tightened the language, bringing the should together with the bot-like manner. Open to further tweaks. Headbomb {t · c · p · b} 05:34, 7 January 2022 (UTC)

Looks good, thanks. Enterprisey (talk!) 05:44, 7 January 2022 (UTC)

What's the proper forum for raising concerns about a user using semi-automated tools for an extended period of time at a high rate? ANI seems a bit harsh as they are not acting in a poor manner but multiple editors have expressed concern on their talk page to the point community consensus/guidance may be wise, even if it to approve their conduct and cut down on talk page inquiries.Slywriter (talk) 21:01, 12 January 2022 (UTC)

Village Pump proposal or policy would get the most exposure. Make a proposal "Should a bot do this.." link to the bot and diffs and what it does. -- GreenC 21:10, 12 January 2022 (UTC)

Depends on how disruptive it is; ANI is right, if a single user's behavior seems disruptive and direct discussion is failing, ANI is the normal next step. — xaosflux ^Talk 23:52, 12 January 2022 (UTC)

ANI/VP can also have other options than blocks, like the removal of WP:AWB access if that's the problematic tool use. Headbomb {t · c · p · b} 01:07, 13 January 2022 (UTC)

I have raised a question at User talk:Ser Amantio di Nicolao on this matter. The edits are not disruptive, but they should be performed on an alternate account with the bot flag, to avoid flooding watchlists and to ensure BAG approval. I will wait to see the response — Martin (MSGJ · talk) 03:57, 24 February 2022 (UTC)

Few comments about WP:BOTPERF. I understand that recently Wbm has ran a script purging a couple million pages on enwiki (per phab:T157670); a couple sysadmins seem to be in the discussion and did not seem to object to this. Reviewing BOTPERF, I notice it (correctly) says performance is an issue for the sysadmins not the community, and plus some notes (like the one on editing speed) is disregarded by many large bots, as well as the guidance on times of day.

I notice there's the sysadmins' policy at wikitech:Robot policy, and I would've suggested just linking to that and not imposing anything further locally (at least not for performance reasons), but then I notice that page has also been tagged as outdated with the note that some things there may no longer apply and it was written in 2009. Tbh I'd suspect that, given the scale of Wikipedia in 2022 and the fact that it also gets a lot of random requests from unaffiliated bots, that the infrastructure can handle high requests and imposing these requirements on our project's bots isn't awfully worth it. Basically wondering if its provisions are still relevant today? ProcrastinatingReader (talk) 23:16, 10 May 2022 (UTC)

I don't think it should be scrapped, and the first two bullet points for example are very relevant to non-system performance factors. Some of it can likely be updated. — xaosflux ^Talk 23:23, 10 May 2022 (UTC)

The first two seem like community restrictions/considerations rather than performance ones. The first should probably be mentioned in the paragraph about bot trials, and the second maybe in WP:BOTFLAG. ProcrastinatingReader (talk) 23:32, 10 May 2022 (UTC)

I don't think anyone does the whole "slowly during peak hours" thing (correct me if I'm wrong though), and don't think it's that relevant. Using maxlag is definitely the better way to do it if the bots edits really need to be slowed, so I think that part can be scrapped.

I think edit rate limits make sense, but I guess not for performance reasons. It gives people time to spot errors, see that a bot task is happening and object if needed, and avoid spamming watch-lists. Editing every 10 seconds is 8000 edits a day, which is a pretty decent rate. Not many tasks need to be faster than that. I think the current limits are pretty decent defaults - could be increased if current practice is more than that (I think many bots do 10 edits/minute?), but I don't think they should be removed - people shouldn't be doing 30-40 edits/minute unnecessarily.

Maybe rename the section to "Edit rate"/"Run rate", if that's the concern. Galobtter (pingó mió) 23:54, 10 May 2022 (UTC)

I agree that the section should be updated. The only time I have seen the website getting disrupted by a bot is wikitech:Incidents/2021-07-26 ruwikinews DynamicPageList. That was because of a bot importing ~100k pages per day and even then it was resolved in 30 minutes. If it needs such a high load to cause issues, I don't see how advising to slow down during peak hours is still relevant. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 04:35, 11 May 2022 (UTC)

Skimming that report, it seems it was primarily due to the DynamicPageList extension (since disabled on ruwikinews). Without that extension, which enwiki does not have per Special:Version, the servers could've handled even that load it seems, and sysadmins didn't seem to require the shutting down of the bot.

To Galobtter, those two primarily, but also the restriction on fetching pages (requesting many individual pages are not permitted) doesn't seem too relevant today. The others also seem to exist for non-performance reasons (namely, for community harmony), so should be described as that I think. It doesn't seem like sysadmins actually require anything performance-related from bots (and otherwise I think it's just the UserAgent stuff they ask for)? Would be best to get sysadmin clarification though, as I'm just guessing. ProcrastinatingReader (talk) 11:18, 12 May 2022 (UTC)

With my sysadmin hat on, the advice about running at different speeds for peak hours vs. quiet time is super outdated and can go. In general the requirements for bots are 1) follow the user-agent policy 2) run with maxlag=5, 3) Action API requests should be made in series, not in parallel. The exception for #2 is for bots that must continue to edit as long as humans are editing, like anti-vandalism bots or my TFA Protector Bot. If you're doing something weird or unusual (like the purging mentioned earlier), it's always nice to flag it for sysadmins ahead of time in case there are concerns. The problem that happened on ruwikinews was that after an action had been identified as problematic (mass creation of articles used in DPL queries), the operator had been asked to tell sysadmins again if they do it in future - they didn't, which unsurprisingly led to the same result of a sitewide outage.

Edit speeds are a bit harder to give advice on, my personal opinion (not backed by science or numbers) is that running at ~10 edits/minute (6 seconds between edits rather than the recommended 10) is usually good enough, and if a bulk task takes a week or a month, so be it. If some bots started editing faster like 15epm or 30epm, no one would notice. If every bot started editing faster, I don't know what would happen. Legoktm (talk) 22:12, 12 May 2022 (UTC)

I think it would be sensible to have some way to run a bot at significantly higher speeds than currently recommended. For example when I was doing my short description additions after thousands of checked edits it would be very convenient to ramp up the speed a few times so the 150-250k edits needed didn't take weeks. There is however significant benefits with starting out slowly and I think that should continue to be the norm even if it isn't for performance reasons but rather to help with finding and resolving potential issues. It is a lot easier to deal with 5 bad edits than 500. --Trialpears (talk) 12:04, 12 May 2022 (UTC)

For some context, some past incidents I remembered off the top of my head where sysadmins intervened: the infamous status bots, a single bot that was constantly null editing that it amounted to 30% of all edits across all Wikimedia projects, a bot that was sending harmless yet bogus requests that were interfering with dashboards that tracked 4xx and 5xx errors, a bot that null edited every page on Wikipedia, exposing a MediaWiki bug!, but combined with some new Parsoid stuff being deployed caused a huge buildup in the job queue. Bots can definitely cause trouble, but it's usually the exception because bot ops are decent about self-regulating. Legoktm (talk) 01:45, 19 May 2022 (UTC)

Proposal

Based on the above discussion as well as an informal discussion with some other sysadmins, I propose replacing the entire WP:BOTPERF section with the following:

While editors generally should not worry about performance, bot operators should recognize that a bot making many requests, editing at a high speed or creating many pages can have a much greater impact and cause genuine problems. Bots are exempted from MediaWiki's normal rate limits and given higher API limits to enable more opportunities at the cost of more responsibility. System administrators expect communities to self-regulate bots but will inform users if issues do arise, and in such situations, their directives must be followed.

• Bots must follow all applicable global policies, including the User-Agent policy and API etiquette guideline.
• Bots must use maxlag=5 (see documentation) unless they are e.g. an anti-vandalism bot that should keep editing as long as humans are.
• Bots should use a speed of about 10 actions/edits per minute. There may be other non-performance related reasons to run at slower speeds, such as clogging up watchlists or potential bugs that require mass-reversion of edits.

Bots should always strive to use the most efficient method to operate. When dealing with bulk data, see m:Research:Data and wikitech:Portal:Data Services for different options.

If you are doing something unusual or different and are unsure about the impact you might have, please feel free to ask system administrators for assistance or guidance.

Let me know what you think. Legoktm (talk) 01:45, 19 May 2022 (UTC)

I find that too big a deviation from the current guideline in subtle but significant ways (e.g. general considerations, trial bots, unflagged bots, etc...). I'd rather keep the current section and tweak the one or two bullets than need adjusting, rather than TNT the section. Headbomb {t · c · p · b} 02:40, 19 May 2022 (UTC)

@Headbomb: It was pointed out above that the parts about trial and unflagged bots aren't relevant to performance, they're for "community harmony" (as @ProcrastinatingReader put it). Probably the trial part can go into WP:BOTAPPROVAL and I don't know where unflagged bots should be discussed.

Which part are you referring to as "general considerations"? If you mean the intro paragraph, the substantive changes (as I intended them) are 1) calling out rapid page creation as a potentially problematic activity 2) explain what special permissions bots have that can lead to perf issues 3) state that sysadmins expect communities to self-regulate. I think all of those are justified changes. Legoktm (talk) 05:00, 19 May 2022 (UTC)

Why it's needed (greater effect/potential to be disruptive), urgency of the task is a factor, the downloading of pages, not making unnecessary requests, making use of dumps, etc...

I find little that needs to be tweaked outside of one or two bullets, which is basically that the guidance on when to make bot edits is superceded by the modern maxlag standards. Headbomb {t · c · p · b} 07:01, 19 May 2022 (UTC)

Do the first two sentences that contains "greater impact" and discuss specific permissions not cover the "why it's needed?" Based on yours and Anomie's feedback, I'll add a "community performance" section as well that covers stuff like urgency of tasks, flagged vs unflagged.

Re: "the downloading of pages, not making unnecessary requests, making use of dumps, etc.", I don't think it really makes sense to call these out anymore. It's probably more efficient to use insource/regex searches than to scan an entire dump. And we have APIs like Restbase that are intended to provide bulk content access. Are there usecases that I'm overlooking? But they're still indirectly mentioned anyways, both the Meta and Wikitech links prominently feature dumps as an option. And "use the most efficient method to operate" is the positive phrasing of not making unnecessary requests. Legoktm (talk) 05:31, 20 May 2022 (UTC)

I personally disagree with 10epm; AWB basically caps bot edits at 20epm these days and that's what I've been using since day 1 (when the general guidance was "max 30epm"). I don't see why we're cutting that by a third. Primefac (talk) 07:20, 19 May 2022 (UTC)

@Primefac: sorry, where does it say 30epm? For urgent stuff, it currently has "once every five seconds" aka 12epm. Legoktm (talk) 05:24, 20 May 2022 (UTC)

PrimeBOT 7's task gave explicit approval, it was discussed briefly in this discussion (and no one contested my statement "recommended 20epm"), 15epm was approved here (though 20 was discussed), and there are a handful of others. I will admit that most of these are either for short-term edits or "we must fix this immediately" mass edits, and there are plenty of discussions where 30epm (or even 8epm) is listed as "too high", but we either need to start enforcing these speed limits (which we apparently, currently, don't) or have them match the standard usage; I can't be the only botop running in the 15-20epm range on a regular basis. Primefac (talk) 07:49, 20 May 2022 (UTC)

Seems ok to me as far as it goes, but finding a home for the community-related performance recommendations (versus systems performance, which this is now focused on) would be good. As it is that's only hinted at now. Anomie⚔ 12:23, 19 May 2022 (UTC)

Ack, I think it can just be a second series of bullet points under the current list. I'll probably get to updating the current proposal after the hackathon. Legoktm (talk) 05:32, 20 May 2022 (UTC)

Hey, @Headbomb. Any idea where the lack of opposition was? I saw the assertion, couldn't figure out if the surrounding links helped, decided to query. Valereee (talk) 23:12, 31 August 2022 (UTC)

See the link in 'This requirement initially applied to articles', as put in the edit summary of my revert. Headbomb {t · c · p · b} 23:16, 31 August 2022 (UTC)

As part of the Conduct in deletion-related editing case, the Arbitration Committee decided to request community comments on issues related to mass nominations at Articles for Deletion in a discussion to be moderated and closed by editors appointed by the committee.

Workshopping for the first of two discussions (which focuses on mass article creation) has begun and feedback can be given at Wikipedia talk:Arbitration Committee/Requests for comment/Article creation at scale. As previously announced, Valereee and Xeno will be co-moderating these discussions.

For the Arbitration Committee, –MJL ‐Talk‐^☖ 16:33, 2 September 2022 (UTC)

Discuss this at: Wikipedia talk:Arbitration Committee/Noticeboard § pre-RfC mass-article creation discussion has begun

Wikipedia:Arbitration Committee/Requests for comment/Article creation at scale Valereee (talk) 13:58, 4 October 2022 (UTC)

@Headbomb: I don't understand why you are overriding consensus and imposing your preferred language over the RFC language here and here. Please self-revert. Levivich (talk) 21:21, 27 November 2022 (UTC)

Personally I still think that since the RFC has made mass creation not specific to bots/meatbots then the relevant text should be moved to some other policy page and WP:MASSCREATE retargeted there. We could still keep a reference and any bot-specific guidance here. Anomie⚔ 12:29, 28 November 2022 (UTC)

"overriding consensus" I'm doing no such thing. The RFC's wording is poor and I improved it. That's it. Headbomb {t · c · p · b} 12:43, 28 November 2022 (UTC)

I have to agree that Headbomb's suggested wording is an improvement in readability, without changing any of the meaning or context of the RfC consensus statement. Let's not get to the stage of violent agreement here. Loopy30 (talk) 13:17, 28 November 2022 (UTC)

Of course it changes the meaning of the text. "Have" is not the same thing as "be cited to", and, though this is pedantic, being required to follow GNG isn't the same thing as being exempt from GNG. The community spent months looking at several alternative versions, and this is the one that won. The RfC wording wasn't poor, these changes were not an improvement (and didn't accurately document consensus) and everyone had months to participate in the multiple RFCs. Anyway, HB's bold edits were reverted so he can start a new RfC to gain consensus if he wants to. Until then I've put it back. Levivich (talk) 13:41, 28 November 2022 (UTC)

These two version have exactly the same meaning, and yes

• All mass-created articles (except those not required to meet WP:GNG) must be cited to at least one source which would plausibly contribute to WP:GNG

is much poorer than

• All mass-created articles that are required to meet WP:GNG must have at least one source which would plausibly contribute to WP:GNG.

"cited to" is completely ungrammatical, and the parenthetical is awkward for no reason. Headbomb {t · c · p · b} 15:42, 28 November 2022 (UTC)

"Cited" means WP:CITEd and is more specific and thus clearer than "have", which could be misinterpreted to mean "a GNG source exists". The point of the line is that the article should contain a citation to a GNG source, it's not enough that a source just exist, so we should keep that part clear. As to the rest, I disagree with you that the consensus text is poor or awkward, and I think it's better than your revision. We talked about this sentence for like six months, it was voted on twice, it's the result of a lot of compromise, and it doesn't seem like the dozens of editors supporting it thought it was poorly phrased. But hey, WP:CCC and all that, I'm not saying you can't propose changes, just that it should follow the usual procedure. Levivich (talk) 16:39, 28 November 2022 (UTC)

"The point of the line is that the article should contain a citation to a GNG source"

And that point is unchanged. Headbomb {t · c · p · b} 02:43, 29 November 2022 (UTC)

Changing "cited" to "have" made that point less clear. Levivich (talk) 03:13, 29 November 2022 (UTC)

I agree with Levivich; using "have" will result in some editors interpreting it as a requirement that the source must exist, rather than that the source must be provided in the article. BilledMammal (talk) 04:12, 2 December 2022 (UTC)

An article that doesn't have a source is one where no source is given. No one is talking theoretical sources here. (And you also still don't cite to a source. You cite sources.) Headbomb {t · c · p · b} 04:37, 2 December 2022 (UTC)

Regarding WP:Bot policy § Bots directed to edit by other users -- WP:BOTACC says edits are the responsibility of the operator, and that's true, but some consideration needs to be given to the fact that: a) community consensus supports the operation of a task, as certified by BAG in the BRFA; b) that edits directed by another editor depend on the judgement of that other editor, this principle is outlined in 3. Competence: All users directing a bot must have the required skill and knowledge to ensure their actions are within community consensus.

So I'd like to propose a line be added in this section stating that, if a bot allows some kind of arbitrary actions and this behaviour has been deemed appropriate by community consensus/BRFA, then responsibility for the particular action taken passes to the editor directing the action, and not to the operator (barring technical bugs and so long as the action taken is the expected action). The context of this proposal for me is WP:RESPONDER-RFC but this isn't limited to that; it just feels strange to me for the operator to take responsibility for actions taken by authorised users, if the entire task has been authorised by the community and community consensus is deciding who is authorised to operate the task. So I think this clarification would be worthwhile: botops shouldn't be (and AFAIK currently are not) held responsible for actions by authorised users. ProcSock (talk) 02:50, 30 November 2022 (UTC)

Makes sense to me. GeneralNotability (talk) 03:43, 30 November 2022 (UTC)

I'm a bit wary of this proposal. We don't want to make it so that the operator of such a bot that's frequently misused can claim they don't have to take measures to stop people from misusing it because the responsibility is all on the misusers. We also don't want them to claim they have no responsibility to help in cleaning up after it. Anomie⚔ 13:00, 30 November 2022 (UTC)

Sounds a bit like Section 230... but I agree with Anomie; point 3 quoted above should be enough that if a user is not competent enough to be running (or otherwise using) the bot in question, then the bot operator should be making sure that editor is not using the bot. Primefac (talk) 13:04, 30 November 2022 (UTC)

What if the bot's access whitelist isn't decided by the bot operator? Aside from the hypothetical WP:RESPONDER-RFC, there are concrete examples of this like User:DannyS712 bot III's autopatrol tasks, where the list is at Wikipedia:New pages patrol/Redirect autopatrol list and it's a fully protected page managed by admins which the botop can't even edit. To a lesser extent there's also User:ProcBot/PurgeList which I let most people edit and don't really want to micromanage the addition of pages to that list, or play around with the purging frequency set by whoever added it, so long as it's not absurd or disruptive to resources.

I guess in the case of the redirect autopatrol list, if some bad redirects get autopatrolled, I wouldn't imagine Danny is responsible for cleaning that up. The access should be revoked by an admin and any cleanup decided by the community as appropriate. I guess I see these directed bots as a service, and (barring bugs or operation outside BRFA-approved parameters) the botop's responsibility for particular actions as no more than a Wikipedia's sysadmin's responsibility for the content of our articles. Mainly I think it limits the possibilities of bots if the edits of these bots are considered to be the same as if the bot operator made them on their own account, if that's what we mean by being responsible for the edit. I don't think we really want botops deciding which arbitrary actions are appropriate or not. ProcSock (talk) 14:52, 30 November 2022 (UTC)

In your hypotheticals, you have exactly described how the bot operator does take responsibility, so I do not think your last statement that's what we mean by being responsible for the edit is accurate; a botop can be "responsible" for an edit by undoing the type of edit that caused the issue in the first place; Danny might not be responsible for cleaning up bad redirects, but he can remove names from the AP list; you can remove inappropriate null edit runs if necessary (though as you say, this can be done if there is a problem found, and you do not need to micromanage). Primefac (talk) 09:03, 2 December 2022 (UTC)

In the case of Danny I don't think he can remove names from the AP list, since it's fully protected. He could add overrides in the codebase, of course, but I think the point of the fully protected page is that responsibility for that has been delegated to admins, and I imagine that in practice admins deal with problematic editors on that list and not Danny.

But in substance I'm largely happy with what you say, if we assume 'responsibility' means dealing with issues (as reported) by removing access to the tool? But here the botop isn't responsible for every edit on the bot's account as if it were their own, right? This interpretation is the one I don't like as much or think reflects the status quo too well. ProcSock (talk) 14:29, 2 December 2022 (UTC)

I mean, Smith609 doesn't have to fix issues brought on by Citation bot editing in the wrong places - the user that triggered the edit is given in the edit summary and they likely would be responsible for the cleanup. Smith609 would be responsible if the bot started going haywire and/or editing outside of its remit, though. Primefac (talk) 14:37, 2 December 2022 (UTC)

Citation bot may be a useful example. I recall several discussions at WP:BON and elsewhere over the years where people were being able to use it to make edits that some found problematic. IIRC some of those involved operator non-responsiveness to fixing problems, while others went in the other direction. Anomie⚔ 14:50, 3 December 2022 (UTC)

Citation bot cannot make arbitrary edits/actions though, right? It makes operator-defined actions on user-specified pages. It could just as easily run on the entire encuclopaedia, in which case it would make operator-defined actions on all pages.

I was referring specifically to the case where a bot makes an action which has some degree of variability depending on the parameters a user feeds into it. ProcrastinatingReader (talk) 09:35, 3 January 2023 (UTC)

Citation bot is a weird case at this point (and I was one of the ones saying the operator was inattentive). At this point he may be the listed operator but the clear maintainer today is AManWithNoPlan, who has push rights on the bot's repository. I don't know who has access to the toolforge configuration and whether the process is running these days though, I assume it's him. Izno (talk) 09:13, 20 January 2023 (UTC)

I do have access. AManWithNoPlan (talk) 15:33, 20 January 2023 (UTC)

Right now our bot policy is fairly lenient on bot inactivity, requiring 2 years inactivity for both the bot and the operator. We have a few bots on the relevant list that aren't running and may never run again because they are blocked, or their operator is blocked, or both.

I think that a longterm block placed against either the bot account or its operator should result in removal of the bot permission. I think being blocked for a minimum of 1 year is a reasonable bound, but we can paint a bikeshed if we want. Izno (talk) 09:20, 20 January 2023 (UTC)

Why not just remove the operator activity requirement for simplicity? Two years of inactivity is more straightforward and sensible than carving out an exception for blocked bots with a different time duration. For what it's worth, this was brought up previously by BU Rob13 here: Wikipedia talk:Bot policy/Archive 25#Activity requirements. --MZMcBride (talk) 09:35, 20 January 2023 (UTC)

Agreed that operator activity should not factor into bot flag status. Additionally, I think if a bot has no active tasks, there is no reason for it to have the bot flag. For example, FlagBot 2 is a one-time run that has completed, and thus does not need the flag. This will also allow us to better track bots that are acting outwith their remit. Primefac (talk) 09:40, 20 January 2023 (UTC)

See my response on BOTN on why I don't think "bot inactive for two years" alone isn't reasonable: IznoBot didn't edit in either 2019 or 2020, and so I would have needed to request a new flag with BRFA 2 in 2021. Maybe if the timeframe on "only bot activity considered" were much longer, say 5-10ish years, or as BU Rob suggested there, allow operators to opt in to keeping the flag after notification.

Those rules with those caveats would also sweep up a whole bunch, but not get the currently blocked ones. I would not however support a short timeframe without the caveat. Small improvements please. :) Izno (talk) 09:48, 20 January 2023 (UTC)

It looks like @Xaosflux has previously done a 5 year a thon without explicit policy backing, also allowing operators to opt to retain the tools. I don't know if I would have done that allowance at 5 years, but that feels reasonable. Izno (talk) 09:50, 20 January 2023 (UTC)

@Izno the rough policy support for that was that bots can be reviewed and revoked if they no longer have consensus to run - it went smoothly last time (especially since any operator that wanted to remain was allowed). — xaosflux ^Talk 10:31, 20 January 2023 (UTC)

I think that's a real stretch of the relevant policy, but I was more interested in pointing to prior art that 5 years seems to have been a number used. Izno (talk) 00:28, 21 January 2023 (UTC)

I would have needed to request a new flag with BRFA 2 in 2021 - so? I know both xaosflux and I have Wikipedia:Bots/Requests for approval/Approved watchlisted, and if anything AWB bots take longer to activate than bot-flags (mainly because AnomieBOT gives us big bold warning notices if a bot doesn't have a flag). This is also something that should ideally be handled by BAG if/when a bot is approved (i.e. we/BAG should be cross-posting to BN, not the botop). Primefac (talk) 13:10, 20 January 2023 (UTC)

For 'crats adding the flags, my understanding has been that they watch the Approved page instead of anyone having to ping at BN. Anomie⚔ 15:26, 20 January 2023 (UTC)

Yup, there is rarely a delay there. But if it gets missed after a reasonable time the botop is welcome to ask at BN. Note: a count of these is listed in the stat box at BN as well. — xaosflux ^Talk 16:36, 20 January 2023 (UTC)

if anything AWB bots take longer to activate than bot-flags My bot is an AWB bot. So, y'know, you hit the biggest reason why. Then you're managing two places.

But besides that, it's just time consuming for everyone involved - op and crat - where I suspect that the improvement you think would come out of it (This will also allow us to better track bots that are acting outwith their remit.) isn't ultimately much of an improvement. Bots operating with no or questionable consensus are easy to identify from their operators' talk pages or BOTN if that escalates or AN(I) if there is not even an approval on file for the edits, whether or not they have a bot flag. Ultimately the biggest reason for having an inactivity policy at all is that the bot right comes with sboverride and rateunlimiter (or whatever the name is), which Anomie alludes to below.

I proposed the low hanging fruit I did because an indefinite block is an obvious consensus that the op, bot, or both, aren't welcome which is de facto indication of lack of consensus. But I'm happy, as I said above, to having a 5 year inactivity removal or a shorter removal of the operator requirement but "please be gracious to the op" removal. Maybe, for bots that are one-offs, they could instead get the flag with expiry at 5 years, so no-one even has to care a whole lot. I can go for that as well. Izno (talk) 00:26, 21 January 2023 (UTC)

Small FYI: I don't think bots come with sboverride (per Special:ListGroupRights), but I remember it has been proposed before. –Novem Linguae (talk) 00:34, 21 January 2023 (UTC)

• I'm in support of a 5-year inactivity general rule, but don't want to get too picky on this; if an operator is around and their bot is inactive and wants to keep it in reserve, I'm not worried about it at all. Also, we enforce these sporadically - which seems to work rather well - I don't want to get in to a situation where we need to handle this like inactive admins, with monthly reviews or anything like that. — xaosflux ^Talk 13:34, 20 January 2023 (UTC)

  Agreed on all points. It looks like the last sweep was 2016, it's time for another. --MZMcBride (talk) 16:10, 20 January 2023 (UTC)

• Meh. There's something to be said for removing unused rights to reduce the opportunity for a compromised account to cause problems. OTOH, I wouldn't see a problem with a bot op in good standing being able to get their bot's flag restored on request at BN without having to go through a new BRFA (but with a standard caution that they should make sure any still-approved tasks are still wanted, and should feel free to go the re-BRFA route if they want to be sure). Anomie⚔ 15:33, 20 January 2023 (UTC)

  @Anomie process-wise I think I'd rather them go to BRFA instead of BN on that -- but there is no need that BRFA needs to be onerous. — xaosflux ^Talk 15:35, 20 January 2023 (UTC)

Please see RFC: Clarifications to WP:COSMETICBOT for fixing deprecated HTML tags. Legoktm (talk) 08:00, 8 February 2023 (UTC)

I've been talking with @Theleekycauldron about adding a task to DYK-Tools-Bot which would require admin rights (move-protecting pages that are currently on the main page DYK section). I'm a firm believer in running with the minimum privileges required in case something goes haywire. So I'm thinking I should spin up a new DYK-Tools-Admin-Bot account and use that to run just the tasks that require admin rights.

Before I go down that path, is that a reasonable approach to take? Yeah, I know, lots of other steps in the approval process, but for now I'm just looking for a sanity check on the two accounts approach. -- RoySmith (talk) 01:21, 16 February 2023 (UTC)

Yep, TFA Protector Bot is a separate account for that reason. AnomieBOT has multiple accounts with different permission levels as well. Legoktm (talk) 03:16, 16 February 2023 (UTC)

Yes, that option is fine, you could put 2FA on it as well and use a limited access grant (which you won't use on the API, but just to lock it down more). — xaosflux ^Talk 12:11, 16 February 2023 (UTC)

Sigh. I tried to create DYKToolsAdminBot and got an error that the account name was blacklisted! ACC #330190 pending. It'll be interesting to see what the process looks like from the other side :-) -- RoySmith (talk) 17:58, 27 February 2023 (UTC)

OK, got that sorted... -- RoySmith (talk) 20:15, 27 February 2023 (UTC)

See Wikipedia:Village pump (policy)#Alternative proposal: Move MASSCREATE out of BOTPOL. Anomie⚔ 12:19, 23 April 2023 (UTC)