Requests for comment/Refine global bot policy

The following request for comments is closed. There is a clear consensus that a change is needed, however, it's not clear what is its correct form. Considering all the comments here, I'm closing this proposal as approved with the following notes:
1) The discussion will run for 2 weeks.
2) The bot operator must demonstrate the bot task is welcomed on multiple Wikimedia projects. A good way to show it is to be flagged on 5 or more wikis for a single task.
3) The operator should make sure to adhere to the wiki's preference as related to the use of the bot flag.
4) The discussion will be publicized via MassMessage (to be created), where interested community members and wikis can be subscribed. —Thanks for the fish! ^{talk•contribs} 17:11, 6 April 2021 (UTC)

---

Proposal

The current global bot policy currently allows only bots that either maintain interlanguage links or fix double redirects. Given the fact that Wikidata was established in 2013, the only task that's approved for a global bot is de-facto only double redirect fixes. For that reason, virtually no global bot was approved in the past years, even though there are globally active bots that are approved by a dozen wikis, and would benefit from a globally active bot flag, see InternetArchiveBot or Special:CentralAuth/ListeriaBot as two examples.

For that reason, I would like to propose to amend the global bot policy to authorize the Wikimedia Stewards to approve uncontroversial bot tasks globally (at all wikis with global bots active). If my proposal is implemented, the Wikimedia Stewards would allow a week for the global community to weigh in (similar to how global sysops are appointed right now) and would close the discussion after the one week. Only bots with a task that's already approved at multiple wikis would be eligible to ask for that new flag. Given Wikimedia Stewards are already trusted with appointing similar global roles, such as global sysops or global renamers, I believe there is no issue with trusting them to evaluate global bots in a way that does not evade local consensus, and only for cases where other solutions wouldn't be practical.

What do you think?

Proposed by --Martin Urbanec (talk) 11:26, 24 November 2020 (UTC)

Another good example of a bot that could use global bot flag is CommonsDelinker --Martin Urbanec (talk) 14:26, 24 November 2020 (UTC)

Voting

1.  Support as proposer --Martin Urbanec (talk) 11:26, 24 November 2020 (UTC)
2.  Support per proposal Mardetanha ^talk 11:27, 24 November 2020 (UTC)
3.  Support --Saroj Uprety (talk) 11:44, 24 November 2020 (UTC)
4.  Oppose. In my opinion the success and acceptance of the global bot policy, even on heavily staffed wikis such as the English Wikipedia (where global bots are allowed) and other larger wikis was its narrow, clear, specific and well known purpose, as well as its known lists of tasks. While I agree that the current global bot policy as it stands serves no purpose, IMHO the solution is not to give us stewards a blank cheque to approve global bots for tasks we think are uncontroversial. My advice would be to amend the global bot policy adding specific lists of tasks, which can (e.g. doing a global brainstorming RfC), and then organise a global vote for the proposals that had most support. Otherwise we risk not only not expanding the global bot wikiset, but loosing few wikis in the process. Thanks. —MarcoAurelio (talk) 11:51, 24 November 2020 (UTC)

   while I also agree with some of your points here, I don't consider this as a blank cheque at all, as community does have say in this, if community doesn't feel it should approve there stewards would consider their objections Mardetanha ^talk 11:54, 24 November 2020 (UTC)

   I agree with Mardetanha here. As I wrote in the proposal, community would have a week to comment, similar to other roles that are already appointed by the stewards. By listing the tasks within the policy again, we won't fix the issue, but postpone the breakage to the later date, when the tasks approved by us would no longer be of any use, while there will be another in-practice global bots that can never be flagged. --Martin Urbanec (talk) 11:56, 24 November 2020 (UTC)

   I do not think the solution is to open a hole in the policy to approve whatever we, with the participation of few contributors for a week, think it's acceptable or not without the policy determining a clearly defined scope. The comparison with the global sysops or global renamers is not very accurate as both groups do have a limited and specific scope . I don't want the global bot policy and group to be a dynamic hodgepodge of bots doing random tasks. If we want to keep as many wikis as possible opted-in, the solution is to clearly state which tasks are allowed, as we do for the other global groups; specially when bots get their edits hidden from recent changes and most other places. Thanks. —MarcoAurelio (talk) 12:14, 24 November 2020 (UTC)

   You have a valid point here but again it is up to the Bot owner to ask the flag for a very specific purpose, if it is not the case, it is going to be rejected Mardetanha ^talk 12:28, 24 November 2020 (UTC)

5.  Oppose The discussion following MarcoAurelio's vote, seems to me to develop into a discussion like do you prefer a direct democracy or a representative democracy. What is uncontroversial? I rather decide myself what is (un)controversial than appointing stewards to decide on my behalf. So I rather see individual tasks to be put up for a vote.
--Sb008 (talk) 13:15, 24 November 2020 (UTC)
6.  Oppose Wikis that allow globals bot know which tasks will be done, and it doesn't matter for the wiki which bot fix the double redirects or other allowed task, so delegation the approval to the trusted stewards is no problem. It is another thing to decide which type of bot jobs are wanted in each wiki. The examples InternetArchiveBot and ListeriaBot are not good because they are both unique, and you can easily allow the bot and the task at the same time. I ask for examples where several bots do the same task and where the wikis could just approve that the task is wanted and don't have to care about which bot does it. --Dipsacus fullonum (talk) 13:21, 24 November 2020 (UTC)

   Usually, there is one main bot that does a task, like CommonsDelinker for removing deleted images, ListeriaBot for WIkidata lists or InternetArchiveBot for rotlink fixes. The experience to run a bot without mistakes is not transferrable, and for an approval to make sense, it needs to be tied to an individual bot anyway. Martin Urbanec (talk) 14:27, 24 November 2020 (UTC)

   I agree that each individual bot must be approved. I have no problem with stewards doing that for any wiki which have approved the bot's task. For new tasks there must be a way for wikis to approve the task before global bots are allowed to do them. Is it possible to make system where each global bot task is approved separate by the wikis, and a global bot must check if it is allowed to do a specific task on a specific wiki? --Dipsacus fullonum (talk) 15:25, 24 November 2020 (UTC)

   The wikis must explicitly opt into the global bot policy. I don't think it's possible to get explicit approval of each of the 400+ wikis before granting the flag for a specific task. We can send notifications to the wikis, that's doable. Martin Urbanec (talk) 15:27, 24 November 2020 (UTC)

7.  Support Given that it is possible to opt-out from the global bot policy, and the risk from bad local sysops (see 17'000'000 other RFC:s) is much worse than from global bots. The permission to "maintain explicit interwiki links" is obsolete. Maybe "User:CommonsDelinker" should be a global bot. Taylor 49 (talk) 13:56, 24 November 2020 (UTC)

   CommonsDelinker runs at dawiki without botflag in order to make its contributions more visible, so the community can try to replace deleted files. It may be the same in other wikis too. So giving it global bot status would not be good. --Dipsacus fullonum (talk) 14:16, 24 November 2020 (UTC)

8.  Oppose I do support the use of global bots for specific, well known tasks which do require global access (like the maintenance of interwiki links in old days). I also think ListeriaBot is doing a good job in updating lists whilst using specific commands given by a user for a specific list/page. This proposal does give a Stewart the possibility to allow any bot to start doing whatever on any Wiki-project. I think Wiki-communities could surely be resistant in opening this door to a black box. The proposal is too wide, too open, to support. RonnieV (talk) 14:17, 24 November 2020 (UTC)

   What do you think that should be done instead? Martin Urbanec (talk) 14:21, 24 November 2020 (UTC)

   Each wiki can block bot tasks at any time for any reason. "Starting doing whatever on any Wiki-project" is a fear that lacks trust in the people who are working in good faith to do the right thing, and ignores the existing safeguards. -- GreenC (talk) 17:15, 24 November 2020 (UTC)

9.  Support --Victor Trevor (talk) 14:23, 24 November 2020 (UTC)
10.  Support Certain bot tasks are better opt-out then opt-in -- GreenC (talk) 17:09, 24 November 2020 (UTC)
11.  Support Gamaliel (talk) 17:13, 24 November 2020 (UTC)
12.  Support ♥Ainali ^talk_{contributions} 17:22, 24 November 2020 (UTC)
13.  Support Quiddity (talk) 19:20, 24 November 2020 (UTC)
14.  Support per proposal. Juan90264 (talk) 19:36, 24 November 2020 (UTC)
15.  Support We should at least give this a try. If significant problrms arise, it's not irreversible. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:44, 24 November 2020 (UTC)
16.  Support What a good idea. We talked a few years ago about expanding the bot policy to cover more common/modern needs, and it makes more sense to me to trust the Stewards to sort out the actual needs. As Andy Mabbett says, if it doesn't work out, then we can un-change the policy, and perhaps eventually add in specific use cases. In the meantime, imagine a world in which cross-wiki spammers could be "legally" reverted by bot. At the moment, the global bot policy does not permit that. WhatamIdoing (talk) 20:33, 24 November 2020 (UTC)
17.  Support per proposal. --Jan Myšák (talk) 21:03, 24 November 2020 (UTC)
18.  Support as proposed. It can be rescinded later, if necessary, and bots can be blocked locally if things go awry - Alison ^❤ 22:12, 24 November 2020 (UTC) (ga.wiki 'crat)
19.  Support per proposal. There is no excuse for broken Web links (404s) in Wikipedia articles. They weaken the value of Wikipedia and give users the impression the service is not well maintained. The good news is that, for the most part, we can replace them with archived versions of those pages from the Wayback Machine and other Web archives. Over the years the Internet Archive has invested significant time and money to help address that problem. We have "fixed" more than 12 million URLs on nearly 50 Wikipedia language editions, seeking and getting approval to run InternetArchiveBot on each of those sites. We want to help fix broken links on the remaining 250 Wikipedia sites. This proposal could help accelerate that effort and save us considerable effort in the process. Please help us advance our efforts to fix more broken links by approving this proposal. Markjgraham hmb (talk) 22:33, 24 November 2020 (UTC)
20.  Support with changes. This is highly influential and it needs clarity immediately. If this gets passed then someone has to draft documentation before implementation and also call over discussion to a talk page to discuss details. I support this proposal, but this is a significantly higher impact and potentially more disruptive proposal than what is typical here. Specific changes that I want now are explicit statements of how many and what kind of wiki approval is a prerequsite for global approval. I will make a proposal - "two big wikis and two small wikis are the reprequisite, in a minimum of 3 languages". Also it is proposed that one week is the time for deliberation. This is the norm for single language discussions about typical activity, but this amount of time is not enough for multilingual mass automation. I propose 3 weeks, including with local language notices to all wikis listed among the prerequisites. I do not wish to confine typical ideas with bureaucracy, but I do want to maintain a healthy respect and fear for automated editing at scale across cultural communities without representation in the discussion. Blue Rasberry (talk) 23:10, 24 November 2020 (UTC)
21.  Support I trust stewards to act responsibly here, the current policy is unnecessarily limiting. – Ammarpad (talk) 02:22, 25 November 2020 (UTC)
22.  Support Prefer to extend the timeline to two weeks instead of one as per discussion below, but would support both, if the Stewards are happy (or at least willing) to take up this task. --denny (talk) 03:44, 25 November 2020 (UTC)
23.  Support per proposal. Ed ^{[talk] [en]} 04:14, 25 November 2020 (UTC)
24.  Support per proposal. --Holder (talk) 04:54, 25 November 2020 (UTC)
25.  Oppose basically per MarcoAurelio - while I agree the policy needs fixing I don't think this is (at least politically) the way to go about it. --Rschen7754 06:59, 25 November 2020 (UTC)
26.  Oppose In arwiki InternetArchiveBot task needed follow up to fix some issues, we were able to follow up because we knew that InternetArchiveBot is active on our project. If the bot had global approval and we didn't know about the bot activity it could cost us a bigger problem. I don't think it's a good idea to let the stewards decide what tasks approval without community and most of our community doesn't speak English and in best the English isn't his first language or even second and one week isn't enough. our community isn't too active on our project how will be active here or follow up the new tasks in English. this gonna be a problem for most of non English projects.--جار الله (talk) 10:20, 25 November 2020 (UTC)
27. Neutral I agree with the motivation, that is, the current global bot policy has become obsolete because it was accepted when interwiki bots were needed, and I do completely trust stewards. However, I think it would be more appropriate if all opted-in wikis were required to run a new discussion about whether they still want to allow global bots (then I would  Weak support this). Still, I can't get rid of the feeling that there will hardly be any non-problematic or uncontroversial task that will be accepted or that will cause no controversy on any wiki. --Matěj Suchánek (talk) 12:34, 25 November 2020 (UTC)
28.  Oppose The current global bot policy serves no purpose and should be deprecated. However I do not see much scope for global bots now. It is actually very difficult identify tasks that will be genially uncontroversial across hundreds of projects. It is certainly cannot be done by single steward. Ruslik (talk) 20:30, 25 November 2020 (UTC)

    Well, that's why there is community consultation phrase (I propose one week, some others think it should be two weeks, see below), similary to how we grant global sysop flag. I don't fully understand how those two are different. Martin Urbanec (talk) 21:56, 25 November 2020 (UTC)

29.  Oppose The fact that all of the bots you proposed granting global bot flags to are blocked on at least one wiki does not create a positive impression. * Pppery * _{it has begun} 23:21, 25 November 2020 (UTC)
30.  Strong support GeometryDashFan12 (talk) 22:07, 26 November 2020 (UTC)
31.  Oppose, none of Martin’s examples are uncontroversial (Lint fixes probably are, and I can support adding those to the double redirect fixes and interwiki maintenance, but not this blank cheque). InternetArchiveBot is buggy (I’m tired of fixing every single false positive it finds on my watchlist, and every now and then it actually breaks things), and it needs much of per-wiki configuration anyways (dead link template, cite template parameters etc.). ListeriaBot sometimes floods, and its lists are practically not editable by hand, which several people don’t like (yes, they can be edited on Wikidata, but 1) those edits have no immediate affect, and 2) a newbie will probably never find out how to do that). CommonsDelinker’s edits are often worth keeping track of, as removing images can lead to visually unbalanced articles, broken references (like “the graph on the right shows…”, and there’s no graph on the right), or blank gallery sections. —Tacsipacsi (talk) 22:26, 27 November 2020 (UTC)
32. Neutral. I am very keen in such a global bot policy idea being extended to more scope rather than just fixing interwiki links, as mentioned lint errors, CS1 issues, depreciated scripts might be some (and in uncontroversial cases), however, there is way too many concerns above. We need to fine tune the details to make it less of a blanket approval and I will support a clearly scoped global bot expansion of usage, that might be needing a separate RFC then. Thank you Martin for raising this up, this is clearly worth considering.Camouflaged Mirage (talk) 12:42, 28 November 2020 (UTC)
33.  Support —DerHexer (Talk) 22:31, 28 November 2020 (UTC)
34.  Support The current global bot policy is untenable, and its scope needs expansion. I agree with the overarching theme in this proposal, but I would stress in a way that does not evade local consensus: this should generally not do any content modifications and stick with 'uncontroversial fixes'. Some way of making clearer what an 'uncontroversial fix' is may be a good idea, perhaps with some examples. a week for the global community to weigh in (similar to global sysop I think local communities should be notified, like they are for ban proposals, to encourage participation. Particularly, I think relevant groups should be notified, eg for the English Wikipedia en:Wikipedia talk:Bot Approvals Group. A mix of these will ensure the proper checks, to ensure global bots are actually uncontroversial. And, of course, local projects should be able to opt-out of the global bot policy and some list of opted-out wikis would be helpful. ProcrastinatingReader (talk) 22:50, 28 November 2020 (UTC)
35.  Support, I see no reason to oppose the proposal.--听风吹过的声音 (talk) 08:35, 29 November 2020 (UTC)
36.  Support Expanding the range of useful bots throughout wikis that might not have enough volunteers to use bots on their own can only be good for everyone. Zoozaz1 (talk) 00:08, 30 November 2020 (UTC)
37.  Oppose in its present form. The list of actions considered uncontroversial should be extendend by clearly worded proposals. All projects that have opted in should be notified of the proposal and it should be open for discussion for 4 weeks, there is no need to hurry. I have no problem with the Stewards deciding which bots satisfy the requirements of the expanded list, and welcome the initiative to change the present situation. --MarcoSwart (talk) 21:23, 30 November 2020 (UTC)

    Note that a MassMessage was already sent about this proposal, to all wikis that opted-in (~420 wikis), and it was directed to the Village pump (ie. the most visible page at a wiki for internal matters). Martin Urbanec (talk) 23:02, 30 November 2020 (UTC)

38.  Support for the reasons presented by the nominators. Best, KevinL (aka L235 · t) 06:36, 1 December 2020 (UTC)
39. Weak oppose, per MarcoAurelio. Rather stronger oppose if discussions last only a week as proposed. --Yair rand (talk) 04:21, 2 December 2020 (UTC)
40.  Support per ProcrastinatingReader above (with included suggestions + caveats) and Vito Genovese below. –SJ talk  06:52, 2 December 2020 (UTC)
41.  Support as this lowers the bureaucratic bar and allows for bots to do their highly productive work. I think folks opposing do not appreciate how much time bot save the community, even with the relatively rare false positives. Also, there are remedies if the "uncontroversial" approvals are challenged, as bots can be blocked and the community can re-evaluate it. We should not make perfect the enemy of good. -- Fuzheado (talk) 03:23, 3 December 2020 (UTC)
42.  Support. I started work on the InternetArchiveBot when I was running the Wikipedia Library; I currently work with the Internet Archive making sure there are no dead links on Wikimedia projects. The bot does incredible work at immense scale. But every new wiki we try to expand service to requires clunky and time-consuming attempts--emblematic of the lack of an efficient and sensible global bot policy. The above proposal entrusts stewards to ratify community consensus on a per bot opt-in basis. This just makes sense and could deliver functionality to wikis that severely lack people or technical capacity. There's no reason smaller wikis from lesser-spoken languages should have dead links. It doesn't have to be this way. The same is true for other uncontroversial global bot functions that offer basic infrastructure and tooling. This is a very low-risk proposal, since Stewards are generally wise and conservative, and it involves a per-bot discussion. Wikis that don't want a particular global bot running can always opt out, which is far more lightweight than trying to expand a bot 1-by-1 400 times. Ocaasi (talk) 18:16, 4 December 2020 (UTC)
43.  Support edward (talk) 20:35, 4 December 2020 (UTC)
44. per SJ --MF-W 05:01, 8 December 2020 (UTC)
45.  Support having specifically InternetArchiveBot in mind (WMF should promote and support archive.org, btw). Stewards should, at least, initiate discussions on other wikis, and if they agree, help implement and run global bots, appropriately adjusted for their needs. Ponor (talk) 16:35, 14 December 2020 (UTC)
46.  Support --Novak Watchmen (talk) 21:08, 18 December 2020 (UTC)
47.  Support as the operator of IABot this would help tremendously in deploying this highly asked for bot to new wikis. More objectively, the old policy is antiquated. I see no reason why clearly uncontroversial and globally popular bots should not just be able to get global approval for wikis that follow the global bot policy. I would imagine, that a bot like ClueBot NG, assuming it can handle different languages, would be an excellent candidate for such a global bot approval.—CYBERPOWER (Chat) 17:13, 22 December 2020 (UTC)

    @Cyberpower678: As the operator of IABot, how do you plan to automagically support all wikis? The bot needs to “know” local templates, so manual configuration is needed anyway. When you ask the community for information about how to configure the bot, it’s not a big deal to ask for bot right at the same time. (Or if they proactively ask you to enable your bot on their wiki, they can offer the bit as well.) And, no, it’s too buggy to be uncontroversial. When it searches for dead links, probably there are more false positives than true positives; I’m just too tired of reporting each and every working link your bot marked as dead. (And when I do report something on the IABot Management Interface, it always realizes that the link is alive indeed… Something is seriously wrong with your code.) There are even some people on huwiki who’re questioning whether IABot makes more useful stuff than harm and propose to disable it entirely. I don’t think we should disable it on huwiki, but I do think that it’s far from being a good candidate for a globally-enabled bot. —Tacsipacsi (talk) 13:48, 23 December 2020 (UTC)

    A technician's note: IABot either can use or already uses Citoid configuration, which is what MediaWiki uses to properly fill out citation templates when you use the citation interface in the visual editor. Not all wikis have it configured, but there is no barrier on IABot's side. Martin Urbanec (talk) 16:21, 23 December 2020 (UTC)

    (Edit conflict.)@Tacsipacsi: I had a nice response written out to you addressing everything you mentioned, but MediaWiki decided to toss it out when I edit-conflicted with Martin. So I will be a little more succinct in this version. As Martin points, IABot reads Citoid, but is also now reads the CS1 modules and automatically adjusts. It can configure itself for the most part now, and many wikis run on automatic configuration for the citation templates now. Down the road, IABot will become even more intelligent and be able to map everything without human interaction, but we are still a few months out for that at the very least. As for the false positives, this has been a known, and highest priority problem. We even turned off dead link checking on all wikis a few months ago. We were finally able to figure out what the problem was a few days ago. Turns out, it wasn't a problem with the code or the libraries it was using, but the environment it was running on. After tweaking the environment variables, the false positive rate dropped back to tolerable levels, and my spot checking has revealed any false positives in the last 3 days. Enwiki was turned back on, and spot checking its edits, they all looked good as well. I plan to resume operation on all approved wikis later tonight and want to observe it's contributions globally. I'm expecting you will see much more reliable operation on huwiki going forward.—CYBERPOWER (Chat) 16:36, 23 December 2020 (UTC)

    @Cyberpower678: Thanks for your answer. Once it’s clear that IABot works reliably, I can support allowing it globally, but I still don’t think the blanket permission asked by this RfC is a good idea. —Tacsipacsi (talk) 18:13, 23 December 2020 (UTC)

    @Tacsipacsi: To be fair, this RfC isn't asking to give my bot global approval, it's to give the stewards the ability to make such approvals possible. I would still need to apply for global bot status, and I would still be subject to a community discussion before being given global bot status. My bot was simply listed as an example of a such a possible case.—CYBERPOWER (Chat) 02:17, 24 December 2020 (UTC)

    @Cyberpower678: I understand the scope of this RfC, and this is exactly why I oppose it. I could probably support allowing dead link archival globally (if we have evidence that your bot works correctly, which, of course, needs some time), but not this one, which gives much less visibility to the requests that fall within a not well defined scope. Your bot (in its earlier version) was just an example for what should not be allowed globally. (P.S. I just realized that I got no notification about your pings. This is probably because all links in your signature point to enwiki. Please change your signature to include at least one link to your Meta user page and/or talk page and/or contributions page. Thanks in advance!) —Tacsipacsi (talk) 14:59, 24 December 2020 (UTC)

48.  Support per proposal. Meiræ 12:29, 28 December 2020 (UTC)
49.  Oppose Blatant global bot abuse is tolerated by stewards even now. Acceptance of this proposal would just make it worse. Global bot flags would be handed out based on a nicely written request for permissions and never ever removed. — Robert Važan (talk) 01:48, 31 December 2020 (UTC)

    Hmm. This does concern me a little, however on enwiki we have a BAG and we have the same issue. As I understand it, BAG will not usually revoke bot approvals unless community consensus for. task has changed. Bots acting outside of scope, or malfunctioning, are blocked usually rather than having their tasks or bot flag revoked. It looks like the global bots take the same approach. Presumably local communities are meant to block themselves, and if enough block then maybe meta will discuss? This seems concerning, and in hindsight I agree a clear procedure for revocation of bot tasks should be set in place. On enwiki, I feel editors are often confused as to what the most effective approach is to stop a bot's operation. For global bots, especially on communities with less effective ability to deal with this stuff, that should be made very clear. ProcrastinatingReader (talk) 01:19, 2 January 2021 (UTC)

50.  Support The current list of "allowed" activities is, in my opinion, excessively restrictive and there are bots that would do well globally that do not need repetitive permissions. Local communities would also retain the option to block that global bot should they feel that local discussion is needed. Leaderboard (talk) 14:54, 29 January 2021 (UTC)
51.  Oppose Given the vast diversity between wikiprojects, the risk of unforseen consequences cannot be ignored. Each community should have autonomy to decide whether they want a new bot approved.
    For example, even CommonsDelinker is not completely uncontroversial. On Wikinews projects having a redlinked image on an archived article is arguably more appropriate than the image being removed altogether, as the archive is supposed to represent a moment in history, preserved intact as much as possible. Edits made months or years after-the-fact contravene the goal of maintaining a historical newspaper archive.
    For reasons such as this one, individual community buy-in is important, and I do not think it is fair to force smaller wikis to perpetually monitor Meta just in case a problematic bot is put up for global flags. Aŭdrea (talk) 15:11, 18 February 2021 (UTC)
52.  Oppose I want the local community to have more, and more direct, control on disallowing unwanted bot behavior that may happen both due bugs and pushing some idea that is not locally accepted. Both of the two may happen at any time. As admin, I want to be able to show the door for any bot in the project I am responsible for, at any time. Audriusa (talk) 18:46, 20 February 2021 (UTC)

    Local projects could still block bots they don't like, and also opt out of the global bot policy altogether. ProcrastinatingReader (talk) 00:58, 12 March 2021 (UTC)

Discussion

Arbitrary section #1

Why 1 week? I know SRB requires a 1 week discussion, but if we are per Global renamers / sysops, shouldn't we use the period of 2 weeks. Just my 2 cents. Camouflaged Mirage (talk) 12:14, 24 November 2020 (UTC)

Two weeks is also fine with me Mardetanha ^talk 12:29, 24 November 2020 (UTC)

Totally fine with two weeks. Martin Urbanec (talk) 14:22, 24 November 2020 (UTC)

InternetArchiveBot is indefinitely blocked in 2 wikis, and ListeriaBot in 4. This is quite sufficient a proof that they are not uncontroversial enough to be granted a global bot flag. Since this proposal is virtually changing the definition of "uncontroversial bot tasks" from "maintain interlanguage links or fix double redirects" to "per discussion case by case", we need better examples of what can be deemed uncontroversial and what cannot. Otherwise, it is difficult to determine the impact of the change, and we will be definitely opening a can of worms. ネイ (talk) 12:49, 24 November 2020 (UTC)

ListeriaBot's block on trwiki is not because of controversial edits. The reason for block is high volume editing without having a bot flag, e.g. flood. The block is temporary and the community await news from the operator for a bot flag request. [evolutionoftheuniverse] ^@meta 13:12, 24 November 2020 (UTC)

So, having a global bot flag for such bots might substitute a local bot flag. [evolutionoftheuniverse] ^@meta 13:15, 24 November 2020 (UTC)

Most of those blocks are for operating without a bot flag. Magnus wrote somewhere (don't recall where) that they do not have the energy to ask for local bot flag everywhere. This would be a solution. Martin Urbanec (talk) 14:24, 24 November 2020 (UTC)

I think bots that perform content-less updates are generally "uncontroversial" - for example Linter fixes. I was doing these for a while, but grew weary of having to track down bot authorization on every single project. — xaosflux ^Talk 15:21, 24 November 2020 (UTC)

^ This. Small wikis do not have technical expertise. We should not make volunteers such as Xaosflux jump through bureaucratic hoops on dozens or hundreds of wikis to fix obviously broken page formatting. WhatamIdoing (talk) 02:30, 25 November 2020 (UTC)

I propose a system where each task that a global bot may do, is described in a list. Then each wiki can select which tasks in the list they allow global bots to do. The wikis can either decide for each task individually, or if they prefer they can approve all tasks en bloc including any new tasks which may come later. --Dipsacus fullonum (talk) 15:38, 24 November 2020 (UTC)

I don't think that's a good idea. The flag would be active at all wikis, while the bot wouldn't be able to pick wikis where it wants to edit unflagged and where does it want to edit flagged. Martin Urbanec (talk) 15:42, 24 November 2020 (UTC)

The list should be available in a format that is easy to read automatically by the bot, so it can know where it is allowed to edit. --Dipsacus fullonum (talk) 15:49, 24 November 2020 (UTC)

This is a good idea in theory only. For bot operators it is a nightmare, as well as for anybody who is involved in handling such requests. --Krd 16:48, 24 November 2020 (UTC)

@Martin Urbanec: why not? This would only give that account access to the bot permission, it is still up to the account to assert or not assert the bot revision flag on each edit. — xaosflux ^Talk 17:26, 24 November 2020 (UTC)

I don't think a on/off matrix of tasks per project is a great idea, just that it should be technically possible. — xaosflux ^Talk 17:27, 24 November 2020 (UTC)

Not always, for instance, an user using an AWB has no available tooling to work with that, he's just considered bot everywhere. It's probably technically doable, on the other hand, most things are technically doable, it just depends on how much money/time/other resources you have. Martin Urbanec (talk) 20:07, 24 November 2020 (UTC)

Dipsacus fullonum, IMO the main problem with your proposal is that getting your wiki fixed requires someone from that community to find Meta, find the matrix, figure out what it means (in English, which is almost certainly not that person's native language), and say "Oh, that would solve this problem we're having and be so much easier than doing it by hand myself..." – which is not going to happen.

We should have a system that lets people report that a task is controversial and to stop it, but we should not require hundreds of communities to opt-in to each task. WhatamIdoing (talk) 02:34, 25 November 2020 (UTC)

I like this idea. Perhaps the wiki's individual settings could be set by local bureaucrats (/admins?) on a Special page or Mediawiki page, linked to from global bot userpages. --Yair rand (talk) 04:21, 2 December 2020 (UTC)

Polls are evil, so I will not be casting a vote to the section above out of principle. That being said, I fully support the proposal. I've been dealing with Linter issues extensively in the last few days, and it is clear that we need automated accounts to deal with such issues. I was the one who issued ListeriaBot's block at trwiki, which had nothing to do with the quality of the edits as mentioned above. If we can grant global rights to such accounts, then local blocks would not be needed to begin with.--Vito Genovese 22:16, 24 November 2020 (UTC)

• I absolutely understand Martin's motives and know that his goal is to have the communities served in the best possible way. But I also understand—too well, perhaps—the concerns that other colleagues, especially stewards, have expressed, and I know that they have the same best intentions for the communities as well. In the end, I think it's largely the trivial “the devil may be in the details” and “it depends”. Two things come to mind that may somewhat help eliminate controversy:
  • Require that the local communities are explicitly notified of any new global bot proposals, also communicating clearly why the bot is needed and what exactly it will do.
  • State it clearly that if a local community has problems with a bot, they are free to restrict it however they please, i.e. a “global” bot isn't privileged in any way.

While “Small wikis do not have technical expertise, [so we may as well decide for them]”—which was mentioned in the discussion earlier—is by all means a well-intentioned remark, it is, IMO, also a slippery slope. As a more tech-oriented person myself, I've seen how sometimes the trust in the community towards those pushing the tech solutions—be it simple bots or more substantial software changes—gets seriously strained. It's never going to be—and needs not be—completely smooth, but good communication and eliminating situations where the people might feel “force-fed“ usually help to avoid the dangers of an irreversible split. Speaking of these things, I still remember how once on Phabricator I asked a question, adding “sorry if it was a stupid one”, and Martin replied “There are no stupid questions” and then took the time to explain how the things were working. My question was stupid—I had understood it wrong before his explanation—and I kept this as an example how I should deal with similar situations when people ask about things they don't understand, while I do. So, while I'm sure everyone here has the same well-meaning and constructive attitude in mind, I think being a bit more explicit how nobody is going to be surreptitiously forced to accept things (or bots, in this case) won't hurt. :)

Cheers,
— Luchesar • T/C 17:59, 27 November 2020 (UTC)

Р.S. Why notify the communities if there are going to be global discussions anyway? Well, few people follow what's going on on Meta. Blame the rest if you like, but these are the facts, and let's not forget that we're all volunteers. Sometimes even looking after your local project alone takes too much time and effort. The notifications would be at least an honest attempt to make sure the people know what's going on. And they should, of course, be sent via the global message delivery or another automated system, with the usual “please translate” (i.e. I don't expect them to be translated in advance for each community).
— Luchesar • T/C 17:59, 27 November 2020 (UTC)

• How will this work in relation to "tasks"? eg on enwiki a single flagged bot account can do many tasks. Presumably, in this update, a flag is being linked with an approval for its task, in the sense that a flagged global bot can operate globally without needing to do anything else, except when required by local policies. So what if a bot has multiple 'tasks' on that flagged account, some uncontroversial and others not? ProcrastinatingReader (talk) 23:00, 28 November 2020 (UTC)

• JAnDbot is a former global interwiki bot that is now being blatantly abused while stewards do nothing to stop it despite clear breach of current global bot rules. Why are there any rules at all if they aren't being enforced even in cases of blatant abuse? I get it that InternetArchiveBot is trusted and useful, but this proposal opens the door to a lot of abusive bot operators while making it harder to remove existing abusers. — Robert Važan (talk) 01:39, 31 December 2020 (UTC)

What is uncontroversial?

Given the above there are many opposes due to controversial nature, and to try save this RFC without the need to have another, let's decide here on what can be deemed in scope for global bot (I.e. the use cases). This is like GR is granted to people with a strong Xwiki anti-vandalism track record (which is the scope), it will be good for GB to be given to XXX (where XXX is to be determined). I think this will be a way forward, the discussion period on meta I propose should be discussing whether the proposed task is in scope of XXX or out of scope of XXX, with the usual exceptions of course, if it's out of scope it should be declined, in scope approved. Ideas about XXX are welcomed below. Camouflaged Mirage (talk) 13:20, 3 December 2020 (UTC)

Highly trusted xwiki bot operator? Ie. has flags at multiple wikis, has a strong usecase (ie. if a wiki requires manual configuration, it doesn't make much sense to have a global flag), etc. Martin Urbanec (talk) 20:26, 6 December 2020 (UTC)

Thinking about what MAY be controversial, some of the reverses may be uncontroversial. In general any "content" editing may be controversial, grammar and spelling edits may likewise be controversial. Edits that only change the source but not the output (e.g. whitespace arrangement, cosmetic piping updates) may be controversial. So perhaps there can be some brightlines that are never allowed. — xaosflux ^Talk 19:44, 7 December 2020 (UTC)

Fairly uncontroversial edits could include purely technical updates (fixes to source formatting that are necessitated by software changes such as the aforementioned Linter changes), editing of dedicated project/userspace pages such as publications of bot-generated reports, updating x-wiki links following renames (bypassing of an external redirect) for example article links to commonswiki galleries. — xaosflux ^Talk 19:44, 7 December 2020 (UTC)

On notifying interested users

If this proposal passes, and in order to assess whether tasks are indeed uncontroversial or not, we need community input. This could be done by two means:

1. Create a MassMessage list, where interested users could (un)subscribe at their own will, to receive in their talk pages a message informing them that a new discussion is opened, and when it is expected to end.
2. Activate mw:Extension:Newsletter on Meta, where interested users could (un)subscribe at their own will. This will send Notifications instead of talk page messages.
3. Or both if desired.

—MarcoAurelio (talk) 11:45, 5 January 2021 (UTC)