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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A discussion is taking place to address the redirect Wikipedia talk:BOT. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 March 25#Wikipedia talk:BOT until a consensus is reached, and readers of this page are welcome to contribute to the discussion. JJP...MASTER!_{[talk to] JJP... master?} 17:11, 25 March 2021 (UTC)[reply]

I speedy closed this as being unnecessary. Primefac (talk) 17:21, 25 March 2021 (UTC)[reply]

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

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

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

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

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

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

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

Moved to Wikipedia:Bots/Noticeboard

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

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