Wikipedia talk:Bot policy

Active discussions

Problems with WP:BOTMULTIOPEdit

The section titled "Bots operated by multiple users" has multiple problems I think.

  1. It is using a different definition of "operator" to the one used a few sections above in WP:BOTACC. Really, it isn't talking about operators (à la User:ClueBot NG or User:ArbClerkBot - literally multiple operators). Rather, by my understanding, it's talking about bots that can be triggered to operate by other users (eg Citation Bot, possibly AnomieBOT TfDTemplateSubster, CFDW, etc). Which is a totally different thing. Indeed, WP:BOTACC "operators" cannot, and do not (see contribs of ClueBot or ArbClerkBot) fulfil the WP:BOTMULTIOP criteria. The confusion seems confirmed by the very low usage of the shortcut - multiple of those discussions indicating this same confusion in definition. It's not helpful to change definitions of "operator" half way through the BOTPOL. To that end, we should rename this section I think.
  2. What restrictions do apply to actual multiple operators (eg User:ClueBot NG or User:ArbClerkBot). Which of the operators is responsible for the bot's edits, as outlined in WP:BOTACC? I presume "multiple operators" here is people who have access to the account / server running the bot.
  3. In line with a discussion I've had with Xaosflux, I think we need to clarify/change the responsibility of a bot operator for edits triggered by other users. Whilst, yes, I agree there is some responsibility if they choose their own criteria, but if the community are the ones who have created, set and approved the criteria via RfC, and other admins are the ones enforcing the criteria (by, say, adding names to an allow-list) I don't think it's logical to hold the bot operator responsible for someone misoperating the bot, any more than it is holding a MediaWiki software patch writer for a sysop (granted tools by the community) going on a blocking spree. (context, also autoprotect bot: One thing to keep in mind is the principal that bots are just alt-accounts of their operator, so the admin running such a bot would need to be personally responsible for all the protections that they apply to ensure they are aligned with the protection policy.)

ProcrastinatingReader (talk) 11:41, 9 December 2020 (UTC)

@ProcrastinatingReader: for adminy-things, I think we'd need to start with the admin policy - if you want to be able to let admin delegate their authority to others by allowing them to trigger them without manual review (WP:ADMINACCT) currently holds them personally accountable for anything they do. — xaosflux Talk 12:26, 9 December 2020 (UTC)
Isn't this a slight catch-22? afaik it's only considered a delegation of authority because BOTPOL considers it as such (which is the change I'm asking for here)? Say in the abusefilter method you mentioned, who does the principles of ADMINACCT apply to? It can't be the filter, and probably not the person writing the filter, so presumably it's to the person who triggered the filter? I guess I'm asking for tasks, where approved by consensus, be similarly treat simply as technical implementations.
I was also thinking this is required by the 'task has consensus' part of BOTPOL. My understanding was that it's somewhat a given that anything which allows others to do admin-y tasks needs wide community approval (likely evidenced by a high-participation RfC), with the bot just being the technical implementation of that (with, in my eyes, little distinction to it being an MW interface feature instead). In practical terms, I guess the concern I have here is that given getting something done in MediaWiki can be a pain, I thought a BOTPOL change clearly allowing the community another route to do these things (if it wishes) may help. ProcrastinatingReader (talk) 13:25, 9 December 2020 (UTC)
The AbuseFilter doesn't have normal admin powers (at least not here on enwiki) we don't allow it to block users or ip's, and it can't make edits. Any admin that makes a bad filter would be responsible for its fall out - and if they were say to make a filter to gain advantage in a dispute it would be just as serious if they did it any other way. A general principal is that a person can't delegate their responsibility, responsibility always flows back to the source. Think of bot actions as just quickly doing something you would otherwise manually do. — xaosflux Talk 15:28, 9 December 2020 (UTC)
A blocking concept example, say I work WP:AIV a lot - and it is getting repetitive. So I make a script that lets me block reported users with one click. Then that gets repetitive because I still don't like having to go look in to the reports - maybe I see a lot of reports from User:ProcrastinatingReader on there so I update my script a bit more that says something like IF (REPORTER = ProcrastinatingReader) THEN BLOCK REPORTED USER FOR 1 DAY). Then that starts getting repetitive, so I just make a program to run the script constantly. So what has happened here, basically I've delegated that anything you report, I will blindly block. Does that absolve me of my admin responsibility to only apply appropriate blocks? Does saying "blocked per request by ProcrastinatingReader" fix that - I'd think not. Now, perhaps I'd say that if this was a tool I made that was only able to be used by people that could natively perform the action manually (e.g. other admins) it could be a proxy for them - such that the reported would maintain responsibility for the action. Without that, you run in to a situation where individual admins giving non-admins access without the community vetting normally required for admins. — xaosflux Talk 15:28, 9 December 2020 (UTC)
Another bot concept to keep in mind is that no bot should ever be relied upon to ever make another action or edit. So "important" processes shouldn't be built around someone's bot. — xaosflux Talk 15:28, 9 December 2020 (UTC)
On a tangent, I'm not opposed to creating non-admins that can apply more technical controls (e.g. block, delete, etc) - just that it should be done as a community authority granting process, not a single admin divesting their individual authority. — xaosflux Talk 15:28, 9 December 2020 (UTC)
@Xaosflux: I'm on the same page with you so far, I think. If you decided my reports are good enough and made a script or bot that automatically took my AIV reports and blocked for them, I agree with the idea that you're responsible for those blocks equally as much as if you were reviewing each one, even if the erroneous report was mine. Mainly, I fully agree with it should be done as a community authority granting process, not a single admin divesting their individual authority. I'm talking about cases where the community has agreed to do something. Say an RfC passes creating a 'group' which can block IPs with less than 100 edits, but finds that the full 'block' permission is too much to give to people (not my personal opinion, but still, hypothetically), so a function is required ensuring blocks are only executed if meeting this criteria. In this hypothetical RfC, the community also says that the permission must be granted by any administrator at WP:PERM, following a minimum period of discussion. So: both the concept, and the criteria, is set and approved by the community, with, say, 200 editors in favour and 0 opposing.
Well, to technically implement this consensus, it's either a MediaWiki patch (preferred, but harder) or a bot (which has to be operated by someone). Now, due to the principle you mention, that bot actions are an extension of their operator, if this is ran as a bot it's considered the same as an admin operator unilaterally allowing non-admins to block via their account (and it's possible no admin wants to take that responsibility since it's a fair burden). imo there should be no difference between whether the trigger is via bot, or via the MediaWiki software. As long as the person triggering can be verified onwiki, and both the task and the criteria to trigger is widely approved by community RfC, I'm not sure why this technical distinction is relevant? Why can't a bot be used to do it, without the person who coded the bot being responsible for ensuring every block is in compliance with WP:BP? If, alternatively, said bot operator made a MediaWiki patch for the technical functionality doing otherwise exactly the same thing they're absolved of all such responsibility. This part is confusing to me. The exact same newly-created policy, with the exact same consensus backing it, same process for granting rights, and same individual block by the same person, yet one is (possibly) problematic if technically executed by bot and the other is okay since it's done via the MediaWiki interface? Is there any reason these two things should be treat differently? ProcrastinatingReader (talk) 16:16, 9 December 2020 (UTC)
If you write an arbitrary script to do something, you're definitely responsible for what the script does. However, let's say if the community, hypothetically, decides that "all users who have > x% accuracy at reporting users to AIV may have their future reports automatically actioned", and a bot operator writes a script to implement the community's consensus, it should be really be the community at large (not the bot operator) that's responsible for the blocks, as the bot operator was merely implementing the community's decision. I have not read PR's comment due to its sheer length, I apologise if I'm just repeating arguments. – SD0001 (talk) 17:31, 9 December 2020 (UTC)
This is a good start to look at the approach, it is expanding the community policies (the block policy in that case) to specifically allow admins to delegate responsibility for their actions to others (who then I'm assuming would be held to the admin standards policy when triggering another admin to do their bidding?). — xaosflux Talk 17:37, 9 December 2020 (UTC)
Finally read PR's comment above, and wanted to note I agree with him fully. Bots are powerful tools; holding the operator responsible for all actions even if they were triggered by other reasonable users (who knew what they were doing) is simply bad policy that severely limits the potential usefulness of bots. No one would want to implement such bots as long as this policy is followed. – SD0001 (talk) 17:41, 9 December 2020 (UTC)
Yes, this is what I'm trying to get at! My comment is a bit long, but I was really trying to emphasise that the scenario I'm describing is one where there's a community consensus that needs implementing, but a MediaWiki patch is infeasible. I think it's important to separate the technical means of executing the action from the actual consensus-backed proposal.
Simpler example, and this would be ridiculous but it's a totally valid technical approach to demonstrate the point, consider the community-approved WP:TPE guideline. What if templateeditor existed exactly as it does now (RfC support, same grant process, revocation, etc, all community approved), but people can't edit the page directly (maybe MediaWiki couldn't support it) so they need to edit a sandbox, then a bot checks if the person is a templateeditor and (if so) copies their code into live template. Why would the botop now suddenly take responsibility if the TPE messed up & this edit is bad? ProcrastinatingReader (talk) 18:00, 9 December 2020 (UTC)
In that case, the BotOp would have approval for the function. AnomieBot triggers when someone adds an undated {{cn}} to an article. If a vandal adds 432 {{cn}} to the article, Anomie isn't in trouble because the bot expanded them all. The bot didn't malfunction, it did exactly what it was supposed to do. Headbomb {t · c · p · b} 18:25, 9 December 2020 (UTC)
Right, and I think this is where we circle back around to MULTIOP and the whole "admin/protect bot" thing that's at AN. If a bot has consensus to block/protect/whatever, based on established rules that the community has agreed on, the bot (or the bot operator) is not "at fault" if someone is intentionally breaking those rules in order to gain the upper hand etc. Primefac (talk) 20:36, 9 December 2020 (UTC)
To ignore the above and come back to the original point, I do think a little bit of clarification is needed; an operator is the one who "owns" and maintains the bot. However, there are bots that can be triggered by other users (as described above); it is those editors who are responsible for the edits made by the bot that they triggered (which, if I recall, is why there are restrictions on who can trigger Citation Bot or edit AnomieBOT's TFDSubster page). Primefac (talk) 20:36, 9 December 2020 (UTC)
In the case of CitationBot, the restrictions are mostly there to prevent blocked users from using it. Headbomb {t · c · p · b} 20:44, 9 December 2020 (UTC)
(edit conflict) IIRC (but I might not be R-ing C), WP:BOTMULTIOP was written for cases where a tool on Toolserver allowed people to manually queue up arbitrary edits that would then be applied by an associated bot account. Some people were making bad edits through this mechanism, but there was no way to tell who was at fault. Even if there were logs, they weren't accessible to general wiki editors. Now that we have things like OAuth, such tools probably don't exist anymore since they can now use OAuth to make the edit via the requesting user's account.
As for responsibility for things like AnomieBOT's TemplateSubster and TFDTemplateSubster, I think it comes down to a shared responsibility. The bot operator needs to include appropriate safeguards to limit abuse and respond to any major abuse incidents, while any abuser is responsible for their actions abusing it. Whether the bot should identify the triggering user or not probably depends on the specifics of the task, e.g. how easy it is to find the responsible user after the fact. Anomie 20:45, 9 December 2020 (UTC)
Right. I don't think TFDSubst needs that sort of attribution (since the history is trivial to determine), but it is potentially helpful for the folks triggering Citation bot. Primefac (talk) 21:39, 9 December 2020 (UTC)
The responsibility of the malfunction there still lies with the bot operator, since people who activate the bot don't ultimately control what the bot does. There, knowing who triggered the bot mostly helps to see who is interested in an article and (possibly) filter out newbie editors from triggering a mass run. There was one case of hounding that where it led to a block (of the hounding editor, not the bot op), and OAuth-based editor identification was implemented after that as a security measure. While it could be made part of BOTPOL, I feel this would be hard to codify since it's so dependent on the bot task. As far as I'm concerned, this is something that should be flagged during BRFA, rather than pre-empted at the BOTPOL level. Headbomb {t · c · p · b} 22:31, 9 December 2020 (UTC)

Removing restrictions in softwareEdit

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)
Return to the project page "Bot policy".