Jump to content

Wikipedia talk:Bot policy/Archive 28

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


Should BAG members have an activity requirement?

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
The result of the RFC was to add Version D to Wikipedia:Bot Approvals Group.
Looking at the arguments, the main concerns of the opposition (i.e. the "option C" folks) felt that this was instruction creep, could have some sort of chilling effect on volunteers, and in general was a DONTFIXIT situation. Those who wanted some form of "inactivity requirement" (A, B, and D) felt that bot operators (similar to admins and perm-holding editors) should have some sort of idea of recent developments in order to effectively evaluate bot requests.
Taken as a "first past the post" question, no one proposal has a clear "victory". However, options C and D were the front-runners by a reasonable amount. Those who supported A or B often preferred D over C, giving D a slight numerical edge.
The final thing I considered was the opinions of the bot operators themselves (while their opinions don't necessarily hold more weight, I was curious). However, again, opinions were mostly mixed, following mostly along the general opinions already mentioned, and didn't really sway the conversation significantly in either direction.
In summary, the majority of editors felt that there needs to be some sort of activity requirement for BAG members, and the clear front-runner when choosing "which option" was D. Primefac (talk) 22:45, 16 December 2018 (UTC)

Following a prior discussion, I propose we institute an activity requirement for BAG members, much like Admins have. Headbomb {t · c · p · b} 17:43, 14 November 2018 (UTC)

Proposed wording

Version A
BAG members are expected to be active on Wikipedia to have their finger on the pulse of the community. After two years without any activity on bot-related pages (e.g. WP:BOTN, WP:BOTREQ, WP:BRFA, ...), BAG members will be retired from BAG following a one-week notice. Retired members can re-apply for BAG membership as normal if they wish to rejoin the BAG.
Version B
BAG members are expected to be active on Wikipedia to have their finger on the pulse of the community. After two years without any activity on the English Wikipedia, BAG members will be retired from BAG following a one-week notice. Retired members can re-apply for BAG membership as normal if they wish to rejoin the BAG.
Version C
Status quo: No activity requirement.
Version D
BAG members are expected to be active on Wikipedia to have their finger on the pulse of the community. After two years without any bot-related activity (such as posting on bot-related pages, posting on a bot's talk page, or operating a bot), BAG members will be retired from BAG following a one-week notice. Retired members can re-apply for BAG membership as normal if they wish to rejoin the BAG.

!Vote

  • Version A Version D, I feel if you want to be a part of BAG, you have to do BAG stuff. Version B is a second choice though. I'll mention it was very common to remove BAG members for inactivity in the past, so there's precedent to do that.Headbomb {t · c · p · b} 17:43, 14 November 2018 (UTC)
  • Version A -(Version D close 2nd) - You shouldn't keep access to groups (much like userrights) that you aren't using and that access isn't being used if the editor isn't working on BAG pages. Nosebagbear (talk) 18:29, 14 November 2018 (UTC)
  • Version A - Sounds reasonable. If you want to be a part of BAG, you have to do BAG stuff. The MilHistBot removes MilHist members from the active list after one year. Looking at the BAG, it seems that it could use an extra bureaucrat or two. Hawkeye7 (discuss) 20:16, 14 November 2018 (UTC)
    @Hawkeye7: as one, I don't think its that important to be a 'crat at BAG - we don't flag our own approvals and there has been no significant flagging backlog in a long time. Being an administrator is a big plus here, but the most important that we need at BAG is qualified people that will be active in keeping the requests processed. — xaosflux Talk 23:18, 14 November 2018 (UTC)
    Version D is also fine with me. Hawkeye7 (discuss) 19:44, 16 November 2018 (UTC)
  • Version B. You can still follow bot stuff, just not actively participate. Besides, I don't think a post on some random BOTREQ page once every 2 years is any different. I mean, I agree you ought to do BAG stuff, but version A doesn't really provide any solid "participation" rules. —  HELLKNOWZ   ▎TALK 21:38, 14 November 2018 (UTC)
    • Version D sounds more agreeable, but really only because this is being brought up as an issue. In the end, it's the same result as "posting on some random bot page every two years". —  HELLKNOWZ   ▎TALK 19:54, 16 November 2018 (UTC)
  • Version A per User:Headbomb and User:Nosebagbear. SemiHypercube ✎ 21:41, 14 November 2018 (UTC)
    Version D is also fine by me. SemiHypercube ✎ 03:19, 18 November 2018 (UTC)
  • Version C Per Mz7 below. I don't see any particular risk in someone keeping their BAG credentials, and especially not to the same level as admin tools. I see it as a net positive if an inactive member can come back from a break and contribute without having to jump through bureaucratic hoops. I think someone in BAG would have enough clue to see what's changed before diving into the deep end. I'd compromise to B as a second choice, but am very against A per Hellknowz above. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 00:21, 15 November 2018 (UTC)
  • Weak Version B, and Version A as a second choice, basically per Hellknowz. I don't really see any harm to this proposal. Automated editing can occasionally be a contentious place here, and it's a good idea for BAG members to be relatively up-to-date on relevant community discussions. Enterprisey (talk!) 01:56, 15 November 2018 (UTC)
  • I'm a fan of version B here. I think there is some risk, contrary to Mz7 and Wugapodes, as an out-of-touch member would be more-likely to approve bots which are inappropriate and disapprove bots which are appropriate. The former can be problematic to amend if the bot edits many pages (as is their general intent). I have a weak preference to see a tighter timeframe (1 year--same as admins) with a larger warning period prior (1 month, same as admins). --Izno (talk) 05:06, 15 November 2018 (UTC)
  • Version C - For the life of me, I don't understand why we want to make it more and more difficult to do volunteer work on Wikipedia. Are we suffering from a spate of rouge (or clueless) bot approvers? No. This is just a solution in search of a problem, IMO. Kaldari (talk) 07:12, 15 November 2018 (UTC)
  • Version C – Per my comments in the discussion section below, I'm not convinced any change is necessary here. We're all volunteers here, so we should be free to take breaks at any time for whatever duration. By successfully requesting BAG membership in the past, these editors have already proved their competence in this area. Unless there has been a radical change in the way we do things here in the last few years, I see it as a net positive for old BAGs to be able to resume their contributions immediately, without having to jump through the hoops a second time. (Consider how administrators desysopped for inactivity are not necessarily required to do RfA a second time, unless they've been gone for more than five years.) I realize the list at WP:BAG#Member list is getting kind of long and bloated. Consider instead putting something like {{collapse top}} over the list of inactive members, and if one decides to come back, maybe give them a quick update on new policies, etc., and just move their name back up. Mz7 (talk) 10:22, 15 November 2018 (UTC)
  • First choice Version A, second choice Version B. Would have the added benefit of encouraging more BAG members to participate (badly needed IMO) -FASTILY 06:39, 16 November 2018 (UTC)
  • Oppose Version A [and D]. Activity on the English Wikipedia is enough; activity on "bot-related pages" is too vague and unreasonable to track. I'm also okay with no change. — Godsy (TALKCONT) 08:40, 16 November 2018 (UTC)
Actually that would be relatively easy to track with a bot. Did they edit a page in Category:Wikipedia bots or its subcategories in 2 years (or their talk pages)? And there's still a one week notice where they can say they're still interested in being part of the BAG. Headbomb {t · c · p · b} 13:45, 16 November 2018 (UTC)
  • Not C D>>A>B. I take the concerns over changes in policy, and would add that if someone wanted help with a bot, it wouldn't help to have large numbers of editors they may contact be inactive. Bots and bot policy can be fraught and it's helpful to have active users. Two years is quite generous, so this may not be a titanic change, but a very reasonable start. ~ Amory (u • t • c) 19:09, 16 November 2018 (UTC)
  • Weakish Version B - if enacted today this would change - 1 status, with possibly 2 next year. BAG members should be up to date on current practices. It is also not very hard to "join BAG" if you are qualified and interested so if someone was removed and came back and wanted to help it shouldn't be overly burdensome. — xaosflux Talk 15:23, 16 November 2018 (UTC)
    • And an even weaker Version D, opposed to version C, effectively we've "retired" some people after years and years and years of inactivity before, might as well just codify it. — xaosflux Talk 21:36, 17 November 2018 (UTC)
  • Not A. Somewhat prefer version C over version B but I see the merit to B. Maxim(talk) 16:40, 16 November 2018 (UTC)
  • Version C only, as per Kaldari. Does my opinion not matter because I've been inactive from Wikipedia for too long? That's the implication. Yet I'm still just as qualified as I was when I wrote the bot policy 16 years ago. The logistical issues can be easily resolved by the simple changes that Mz7 suggested. More process creep won't benefit the project. -- RM 18:57, 16 November 2018 (UTC)
    • @Ram-Man: The implication is not that your opinion does not matter, the implication is that a long term inactivity in the bot area could make you disconnected from the current norms and expectations... 2018 is a very different time than 2008. (And to a lesser extent, why remain part of the BAG if you aren't involved with it?) But just by virtue of having commented here (or any bot-policy proposals in the past two year), that is enough to be considered 'active' per version A and D (and B too). Headbomb {t · c · p · b} 19:05, 16 November 2018 (UTC)
      • This shows the flaw in A/B/D: activity doesn't make me more or less qualified. To ensure contributors know current norms and expectations, they should be clearly stated. Unlike A/B/D, this would directly address the issue and not add bureaucratic load. Linking contributors to those guidelines on their talk page is the more effective policy. -- RM 19:36, 16 November 2018 (UTC)
  • Version A. The bot policy changes over time, and if someone takes a prolonged absence from all bot-related work, they should face re-confirmation before returning to the area. ~ Rob13Talk 17:20, 16 November 2018 (UTC)
  • None of the above - Version A doesn't account for the fact the not actively posting in bot related areas doesn't put you out of touch as long as you actively maintain a bot. I want to see an option where BAGgers either actively maintain bots, or are active on bot pages.—CYBERPOWER (Chat) 18:09, 16 November 2018 (UTC)
    • Yeah I'd be fine with that. Maintaining a bot is being involved, but normally that would also usually mean using your bot's page to address issues and the like. I'll update the wording.Headbomb {t · c · p · b} 18:45, 16 November 2018 (UTC)
@Cyberpower678: - is there a minimal level of activity required to manage a bot, or do any of the simpler ones just run without any oversight action ever having to be made by its managers? Nosebagbear (talk) 19:44, 16 November 2018 (UTC)
There are some simple bots where we only find out they aren't being watched/maintained because they break and it turns out the operator hasn't been active for months if not years. There's no process to determine if operators are active. WP:BOTPOL does however say indirectly that that's not allowed. —  HELLKNOWZ   ▎TALK 19:57, 16 November 2018 (UTC)
  • Version D - As long as the user demonstrates knowledge of bots, then they can continue to serve as BAG, however, not going anywhere near bots only puts them out of touch with constantly changing community viewpoints on what they expect a bot should do. BAG must be the voice of community consensus, and not being familiar with it can cause issues.—CYBERPOWER (Chat) 15:43, 18 November 2018 (UTC)
  • Note A version D has been added. Pinging @Amorymeltzer, BU Rob13, Cyberpower678, Enterprisey, Godsy, Hawkeye7, Hellknowz, Izno, Kaldari, Mz7, Nosebagbear, Ram-Man, Wugapodes, Xaosflux, Fastily, Maxim, and SemiHypercube: who participated to give them an option to update their !vote. Headbomb {t · c · p · b} 18:55, 16 November 2018 (UTC)
  • Version D. --Tom (LT) (talk) 23:09, 16 November 2018 (UTC)
  • Version D. If a user continues to maintain her bot but is otherwise inactive (as per Cyberpower), she can demonstrate activity and meet the requirement by a simple comment on the bot talk page saying that the bot is actively maintained. feminist (talk) 02:26, 17 November 2018 (UTC)
  • Meh: the bar for Version D is low enough that it doesn't take much to meet it. (E.g., ignoring my other contributions, I've arguably met it just by operating EarwigBot, even though the bot is stable enough that it hasn't required any substantial changes or attention in years. Does "operating" need to refer to an active involvement rather than a passive one? How would this be determined uncontroversially?) I think Version A is a reasonable low bar for a BAG member, and two years is a long time, so if this encourages someone to edit a few BRFAs in a couple years who wouldn't otherwise, I suppose that's a net positive. That said, I don't disagree with Kaldari's argument either, so I'm fine with Version C as well. — Earwig talk 19:34, 17 November 2018 (UTC)
  • Version C anything that means I don't have to be aware of the problems that are happening in the bot related dramahs of Wikipedia. Don't really care about anything else, as this is quite literally the part of Wikipedia I care least about and every time I see it on some public board I get annoyed: sort it out amongst yourselves how you want to deal with this, don't bother the rest of the community. If you do, my vote will always be to stick with the status quo because nothing is ever actually broken with bot policy. TonyBallioni (talk) 20:50, 17 November 2018 (UTC)
  • Version A -> Version D IMO. Demonstrated knowledge of the bot policy is important. SQLQuery me! 09:44, 18 November 2018 (UTC)
  • Support D, A, or (weakly) C, in descending order of preference. D is more inclusive. I agree with the overall rationales for this, and we should apply something like this to all special "bits", like page-mover, file-mover, template-editor, etc., since the constraints on the use of these tools shift over time (not always in ways that are codified in detail in policy and guideline bureaucratese).  — SMcCandlish ☏ ¢ 😼  11:22, 19 November 2018 (UTC)
  • Version C. Because there's no clearly defined problem that the other versions are trying to solve. –Ammarpad (talk) 08:33, 20 November 2018 (UTC)
  • Version C per comments by Ram-Man, addshore, etc. All people who I would trust to review bots as BAG members despite their apparent inactivity. Also, it's very exciting to see relatively inactive bot folks come back for this discussion, so maybe we need to have it more often ;-) Legoktm (talk) 00:49, 21 November 2018 (UTC)
  • C >> A > D >> B Basically, a solution in search of a problem. There is no security risk associated with BAG membership, so being part of the BAG means having (1) a clue about how bots work and (2) a clue about the applicable policies. (1) does not really expire with time (methinks), so the only concern is (2). The risk of a former BAG member greenlighting a shaky BRFA based on a change in policies and luring a gullible bureaucrat into activating a rogue bot seems too low to me to justify the WP:CREEP. This being said, if we decide in favor of the creep, then it should focus on familiarity with bot guidelines, so standard editing does not cut it; merely operating a bot does not necessarily demonstrate familiarity with all bot guidelines, either. TigraanClick here to contact me 17:02, 21 November 2018 (UTC)
  • A > D > B (in that preference order, I do not support option C) BAG members need to show that they are abreast of current community expectations and simply running an uncontroversial bot does not demonstrate this very well, but that is better than any activity on wp which is significantly better than no activity requirements at all. Note that this is only for members of BAG, not for all bot operators. Thryduulf (talk) 18:25, 21 November 2018 (UTC)
  • C. This is a clear cut example of WP:AINTBROKE/WP:SLFP. No change needed. ProgrammingGeek talktome 13:37, 26 November 2018 (UTC)
  • Version C. Useless as there is no problem to solve. jni (delete)...just not interested 06:09, 3 December 2018 (UTC)
  • Not Version C if you're not involved, there's no reason to hold a position - it is NOT about how qualified you are, it's about how useful you are and anyone who is elected by the community is elected for particular reasons, the main being, getting the job done. --QEDK (後 ☕ 桜) 17:16, 15 December 2018 (UTC)

Discussion

  • Why 2 years? I always feel that these things (access, userrights etc) depreciate too slowly - particularly reasonably significant ones. Why not 1 year or 18 months? Nosebagbear (talk) 18:31, 14 November 2018 (UTC)
  • It's an irony there is not always enough staff to deprecate the staff on a timely basis. -- GreenC 20:26, 14 November 2018 (UTC)
    • This exactly. Ironically, the comment by Fastily is why former members, like myself, are not interested in participating, even though it is badly needed. Options A and B both increase the amount of process overhead. This is not an attractive proposition. Threatening to remove membership will not encourage more BAG members to participate. Losing adminship due to inactivity just made me give up on Wikipedia administration completely. -- RM 17:08, 16 November 2018 (UTC)
  • With sysop and other advanced permissions, there's a security risk involved with keeping them on dormant accounts (increases attack surface and all), and that's a big reason why we remove those permissions for inactivity. However, with BAG, there doesn't seem to be such a risk – if a BAG account is compromised, maybe it might approve a BRFA that isn't well-thought-out? If an old BAG member comes back from inactivity, it strikes me as a net benefit for them to be able to resume their contributions immediately, rather than requiring them to sign all the paperwork a second time. Maybe we could remove them from the list, but if they come back, we can just add them back without needing a second request to join BAG. Mz7 (talk) 21:18, 14 November 2018 (UTC)
    I think I would support a trivial re-application; maybe something like (from BAG member to applicant): "Have you reviewed the changes to the bot policy since your absence began? Do you understand those changes? If you do not, what do you not understand and why?" Or something similar. That would satisfy my standard for "has an understanding of the current bot feeling". --Izno (talk) 05:09, 15 November 2018 (UTC)
    Izno, the trivial re-application thing sounds like a good alternative to the proposals above. Mz7 (talk) 10:24, 15 November 2018 (UTC)
    Maybe some language like "BAG members who are inactive for X length are "censured", meaning they cannot approve BOT tasks. They may remove this censure by answering in public the <insert questions I posed above> on the bots noticeboard. The thread must be available for 48 hours for community comment.", rather than the above proposals. --Izno (talk) 14:52, 15 November 2018 (UTC)
    If this proposal is accepted, I suggest using something like "suspended" instead of "censured", which doesn't seem apt. Given that I don't think an inquisitorial process is envisioned to determine if someone is current with policies and guidelines, but a self-proclaimed assurance, I feel this approach is more suitable than removing membership and requesting re-application. isaacl (talk) 18:33, 16 November 2018 (UTC)
    Yeah, "censure" is what popped into my head. "Suspended" works as well. --Izno (talk) 03:21, 17 November 2018 (UTC)
    @Izno and Mz7: not sure how many you follow (and they are relatively rare), but RFBAG is a fairly simple process already, nothing like RFA. — xaosflux Talk 00:55, 18 November 2018 (UTC)
    @Xaosflux: I looked into the requirements after. It requires a good bit more than my suggested process, even if there isn't the drama of an RFA. I envision a process which is a lot closer to the re-admin after inactivity process. I don't think they need to go through the 7-day, advertise everywhere rigmarole. --Izno (talk) 01:23, 18 November 2018 (UTC)
    Given that everything that was covered in the first request would likely still hold true, the only thing new is the candidate saying, yes, I am up-to-date on latest policies and guidelines. It feels like overkill to remove membership and go through the whole request process again just to have this statement made. isaacl (talk) 23:00, 20 November 2018 (UTC)
  • As a purely editorial comment, if either proposal gains acceptance, I suggest the first sentence be reworded to avoid an idiomatic phrase, and have something like BAG members are expected to be active on Wikipedia to be aware of the latest policies and guidelines. isaacl (talk) 23:02, 14 November 2018 (UTC)
    I agree and/or would like to see the admin inactivity language here (I am not sure if that is contra your suggestion). --Izno (talk) 05:09, 15 November 2018 (UTC)
  • @Headbomb: Question: How many Wikipedia policies have actually changed substantially in the past 2 years? Kaldari (talk) 07:18, 15 November 2018 (UTC)

Let's PING all current BAG members on this. Don't know why I didn't do it from the start:

Current:@Anomie, BU Rob13, Cyberpower678, Headbomb, HighInBC, MBisanz, MusikAnimal, Slakr, SQL, The Earwig, Xaosflux, Addshore, Hellknowz, Jarry1250, Kingpin13, MaxSem, Maxim, Aaron Schulz, Brandon, Carnildo, Chris G, Cobi, Coren, Daniel, Gimmetrow, Jake Wartenberg, JamesR, Josh Parris, Madman, Mets501, Mr.Z-man, OverlordQ, Quadell, Reedy, Snowolf, ST47, Tawker, Tim1357, Tinucherian, and Werdna:
Former:@AllyUnion, Andrevan, Δ, Bluemoose, Dreamafter, EdoDodo, Essjay, Fran Rogers, Freakofnurture, Fritzpoll, Giggy, Harej, Hersfold, Joshbuddy, Kingboyk, Lightdarkness, Maelgwn, Magioladitis, Martinp23, Pgk, Ral315, Ram-Man, Richard0612, Robchurch, Talrias, TheFearow, X!, and Xeno:

Headbomb {t · c · p · b} 16:38, 16 November 2018 (UTC)

Thanks for pinging me but it's not clear I can participate in the discussion due to restrictions posed against me by Arbitration Committe. -- Magioladitis (talk) 18:08, 16 November 2018 (UTC)
For my part, I don't comment too much anymore but I still watch everything. Including giving all new BRFAs a look-over for obvious denials or "this needs WP:VPR". Anomie⚔ 18:43, 16 November 2018 (UTC)
  • I don't see a huge downside to allowing for indefinite BAG membership, as there isn't really a security concern. As long as you're including policy changes in the bots newsletter, no one should be left in the dark. If they do miss them, that is their problem. Being active every day doesn't mean you'll take in the policy changes, either. Policy changes happen frequently across the wiki, no one can keep up. Meanwhile WP:BAG indicates who's (semi-)inactive, so you know who to approach with inquiries if needed. That said I don't really oppose a BAG activity requirement, I just think it's a little silly =p After all, we don't require that admin actions be made when desysopping due to inactivity (though I think we should), and that actually has a security concern. Anyway, speaking for myself -- I've been mostly inactive as a BAG member, but I'm still around watching things, and I do hope to get back into actual reviewing soon :) — MusikAnimal talk 21:30, 16 November 2018 (UTC)
  • I echo MusikAnimal. I may not be active in much of the reviewing process any more, or even as active on enwiki as I used to be, but I am always watching and can be approached. ·addshore· talk to me! 10:50, 17 November 2018 (UTC)
  • I agree with MusikAnimal and User:Addshore above. -- Cobi(t|c|b) 00:16, 20 November 2018 (UTC)
  • FWIW, if I was going to cast a !vote above I would be swaying between C or D, based off the fact that I agree with what Hellknowz said and as well a Mz7/MusikAnimal's comments. - Kingpin13 (talk) 19:00, 20 November 2018 (UTC)
  • I probably haven't touched BAG stuff probably since earlier this year, but I've also been largely inactive in general due to work issues and a constant buzz of depression. If someone really wants to kick me off, stop me from being able to help when backlogs arise, and make me go through some process just to start helping again—despite my spurts of inactivity literally never being a problem in the past—I say that's silly and it actively discourages someone perfectly capable of helping from doing so. Maybe I'm just crazy. --slakr\ talk / 01:21, 1 December 2018 (UTC)
  • I am with MusikAnimal on that. Recall that any participation and involvment is purely in volunteer basis. PS I am allowed to participate in this discussion see Wikipedia:Arbitration/Requests/Clarification and Amendment. -- Magioladitis (talk) 08:39, 1 December 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Humans editing with bot accounts

I misunderstood the situation. Nyttend (talk) 21:47, 29 December 2018 (UTC)

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

Bot accounts should not be used for contributions that do not fall within the scope of the bot's designated tasks. In particular, bot operators should not use a bot account to respond to messages related to the bot.

Now that one must have the interface editor permission to edit .js, .css, etc. pages, an operator can't edit such a page in a bot's userspace without using the bot account. Would it be appropriate to add a footnote <ref>The bot account may always be used for appropriate purposes when technically necessary, e.g. editing script pages in its userspace when the operator does not have the "interface editor" permission.</ref> I don't know if this is something that would be deemed a problem; no point in causing rule creep if there's no problem currently (e.g. it's already appropriate to use the bot to edit its scripting), but if an acceptable thing is technically a rules violation, we ought to tweak the rules. Of course, this assumes that there's a reason for a bot account to have such scripts; I don't use any of them, except one or two that someone else wrote to affect the appearance of my account's skin. Nyttend (talk) 21:31, 29 December 2018 (UTC)

I don't think this is necessary, especially given the rather small number of bots (probably approaching zero) that would even need js or CSS tweaks. –xenotalk 21:39, 29 December 2018 (UTC)
Okay, thank you. Nyttend (talk) 21:47, 29 December 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Notification of BAG nomination

I am just writing this to inform WP:Bot policy that I have requested to join the Bot Approvals Group (BAG). I invite your thoughts on the nomination subpage, which is located here. Thank you for your time. --TheSandDoctor Talk 05:42, 14 January 2019 (UTC)

Minor update to WP:BOTISSUE

I've added 'Alternatively, a targeted edit filter rule may be requested if only part of the bot's edits are problematic.' to the major issue section, as an alternative to stop buttons or blocks. Headbomb {t · c · p · b} 20:44, 10 February 2019 (UTC)

@Headbomb: (BRD'd that) - Well sure anything could be "requested" but how is this a "policy" issue? Even from a "practice" issue - if someone is causing disruption and refuses to stop, block away. — xaosflux Talk 21:54, 10 February 2019 (UTC)
Agreed. The last thing we need is to have an extra edit filter just because a bot is half-helpful. If it should be blocked, it should be blocked. There's no shortage of folks at AN, ANI, etc. That being said, something similar could perhaps be relevant at WP:MEATBOT, as the edit filter may be helpful dealing with bot-like editing by multiple/changing IP addresses. See for example Wikipedia:Bots/Noticeboard/Archive_12#Possible_bot_editing_from_German_IP. ~ Amory (u • t • c) 22:04, 10 February 2019 (UTC)
Well that very much depends on the bot. Most bots have single tasks/purposes, so if it's malfunctioning, you're not throwing any baby away with the bathwater when you're blocking. But say you've got User:InternetArchiveBot that is fucking up archival on one specific domain. Then you could have a InternetArchiveBot + domain filter to selectively block the bot while the issue is being worked out. Likewise for say some WP:AWB-based bot where there's an issue with a specific subrule or specific section of the AWB codebase. Headbomb {t · c · p · b} 22:05, 10 February 2019 (UTC)
There can be a hazard filtering software bugs. The bug is masked so there is no urgency to fix the code. It also gives control over bot behavior to someone besides the bot writer, another form of hazard. The hazards have comparisons with geoengineering and network neutrality, respectively. It might have occasional and special application, policy though? -- GreenC 23:08, 10 February 2019 (UTC)
Well it would be in the 'how to' section, which is mostly about giving editors and admins options on how to deal with issues. Blocking is still an option, but it might not the most desirable of options. It's like an equivalent to kill switch for a specific task, when a kill switch for the task isn't provided. Headbomb {t · c · p · b} 23:37, 10 February 2019 (UTC)
This is strongly related to the discussion at User talk:Citation bot/Archive_15#'User-activated'. I don't think it's acceptable to subject the entire pedia to another edit filter to enable a single bot to continue functioning. That's not how this policy works. --Izno (talk) 00:53, 11 February 2019 (UTC)
It is, but it's a workable solution while the bug is being fixed. The goal is damage prevention, and that's one of the options available, which is much less drastic than a block, which doesn't block the 99% good to tackle the 1% bad. "to subject the entire pedia to another edit filter" is gross exaggeration, only the bot is subject to the filter. Headbomb {t · c · p · b} 00:58, 11 February 2019 (UTC)
@Headbomb: the 'workable solution' would be for the operator (who is responsible for every single edit) to make an adjustment. — xaosflux Talk 01:57, 11 February 2019 (UTC)
Well yes, but that adjustment can sometimes take a few days/weeks depending on real life work, server access, the deployer not being the same person as the person who coded the fix, or just development time in general. Let's take my own User:Bibcode bot. Let's say it works fine today, but down the road something happens (like a URL change somewhere) which makes the bot screw up the addition of DOIs in 20% of its edits, but never screws up the addition of arxiv and bibcode links. Everyone can agree a fix in the code is the long term solution, but why should the bot be blocked for 100% of its edit when we can specifically target the problematic 20%? Headbomb {t · c · p · b} 02:05, 11 February 2019 (UTC)
If you are screwing things up and can't stop - your bot is literally "out of control" and needs to be shut down - if you can't do that it should be done for you until you can find a better way to take responsibility for your edits. Any edits you want your bot to make can wait: There is no deadline. — xaosflux Talk 02:08, 11 February 2019 (UTC)
Or, you can put the edit filters in, and have the 20% of the edits that are problematic wait, while the 80% that's fine get done. There might be no deadline, but there's no reason to purposefully delay improvements when they can be made. It certainly would have been useful during the WP 1.0 bot issue a while back. Headbomb {t · c · p · b} 02:14, 11 February 2019 (UTC)
I think that was a text book example of an out of control bot. Not only was the operator completely unresponsive - but it wasn't even clear who the operator was! Nobody was taking responsibility for their edits, and personally I find that completely unacceptable. — xaosflux Talk 02:32, 11 February 2019 (UTC)
But again, using an edit filter would have let the good, non-problematic part of the bot serve the community while the other issues were worked out. Headbomb {t · c · p · b} 02:43, 11 February 2019 (UTC)

Semi-automated Portal creation

I attempted to clarify that semi-automated creation of pages requires approval, not just articles. Headbomb reverted me, which is fine. I'm looking to ensure Portals can't be mass produced without discussion. Can we find a change that solves the problem now being discussed at VP? [1] Legacypac (talk) 01:54, 27 February 2019 (UTC)

Don't get me wrong, I support that change in principle, but going to 'pages' is a substantial change from 'articles'. For instance redirects are routinely created by semi-automated/automated means. I could go for 'content pages', where content is basically anything that readers can land on from the mainspace. Under that, articles, books, categories, and portals would all fit the bill since you can all access those from the mainspace. Headbomb {t · c · p · b} 02:06, 27 February 2019 (UTC)
I like that. We don't want to ban use of Twinkle to create XfDs for example. Legacypac (talk) 02:07, 27 February 2019 (UTC)
A change to "content" pages sounds good. —  HELLKNOWZ   ▎TALK 14:08, 27 February 2019 (UTC)
Do we RFC this, or is this a uncontroversial enough change to do with this discussion alone? Headbomb {t · c · p · b} 18:18, 27 February 2019 (UTC)
I don't think there is any change to the intent of the policy proposed, just an update to reflect that the semiautomated creation of portals are a thing now but were not a thing in July 2018 when there were 1700 portals no one was watching. Legacypac (talk) 18:23, 27 February 2019 (UTC)
Legacypac (talk · contribs) made this change, I refined to this. If we're all OK with the end result, I'll post a VP notice for more feedback. Headbomb {t · c · p · b} 20:03, 1 March 2019 (UTC)
I like your further changes. Very clear now. Legacypac (talk) 20:08, 1 March 2019 (UTC)
Headbomb, I would change the link to this thread to be a permanent link. It will be gone when the thread is archived. — Ganeshk (talk) 22:47, 3 March 2019 (UTC)
Eventually. For now, it's a bit too recent to know if there won't be developments. Headbomb {t · c · p · b} 22:48, 3 March 2019 (UTC)
Headbomb, got you. That works. — Ganeshk (talk) 22:56, 3 March 2019 (UTC)
Rather than make "broadly means" a link, I suggest having a reference. Usually linked text will point to a definition, rather than a conversation about the definition. isaacl (talk) 05:56, 7 March 2019 (UTC)
  • Whatever the letter of the policy, User:The Transhumanist has crossed the spirit of WP:MEATBOT and Good sense by autocreating thousands of pages. What is the penalty? What is the consequence? What is to be learned, and what is going to be done better going forward?
It seems he really only created the pages as "draft" subpages of a WP:WikiProject. This is not a project-damaging offence. I think he should be slapped with a wet fish. And then, he should be educated on better methods of Bot development. Define the scope. Do some testing, small scale. Present a case, listen to feedback. Do this BEFORE letting loose a MEATBOT violating process. Basically, follow standard WP:Bot processes and procedures.
Can someone skill with bot use give User:The Transhumanist some practical advice? --SmokeyJoe (talk) 05:24, 7 March 2019 (UTC)
@SmokeyJoe: I'd be willing to work with TTH - I think outlines have potential, and have even written 1.5 myself (User:DannyS712/Constitution is very much a draft) - @The Transhumanist thoughts? --DannyS712 (talk) 05:59, 7 March 2019 (UTC)
Outlines predate my Wikipedia career but what I've learned is there was massive backlash against them. SmokeyJoe - this thread pertains to the automated and semi-automated (he used both methods according to his own guide on making them) creation of thousands of portals. He breached these guidelines and we fixed the wording to make it even more clear not to do what he did. Legacypac (talk) 06:07, 7 March 2019 (UTC)

This is a bull shit edit [2] to cover his butt after he violated both WP:MASSCREATE and WP:MEATBOT. I've seen enough disruption. Someone else can revert him. Legacypac (talk) 18:16, 7 March 2019 (UTC)

I didn't make that edit, and you just falsely accused me. You are letting your emotions get the better of you. All edits I've made here have been to make the policy more clear.    — The Transhumanist   18:59, 7 March 2019 (UTC)
Meant to link to this edit [3] not sure how I got the other link. Some of your edits are ok but editing a policy to justify a breach of the policy is backward. You called your own edits semi-automated and you said you have a script that goes beyond semi-automated. You also claimed you checked these policies first. If you checked them you know you breached them, and if you did not check them, you misrepresented that you did. Legacypac (talk) 19:10, 7 March 2019 (UTC)
How is this edit an attempt to justify a breach of policy? (Note that no breaches of policy have actually taken place, to my knowledge). The change I was concerned about was the reporting of the results of a past discussion, in which different results were reported. I've improved the wording, so it is more clear. So that readers of the policy in the future are accurately informed, and so that editors wouldn't be confused upon discovering that the guideline didn't match the discussion referred to. Headbomb interactively improved my correction further, adding a link to the discussion in which the expansion of the policy took place (this very section we are in right now). Thank you, Headbomb.    — The Transhumanist   19:50, 7 March 2019 (UTC)
  • User:The Transhumanist, I suggest that any productive way forward from here does not involve you editing Bot policy, or engaging with Legacypac. An apology for startling your colleagues would be nice, and an acceptance of User:DannyS712's offer would be better. --SmokeyJoe (talk) 23:51, 7 March 2019 (UTC)

Clarification on "Bots operated by multiple users"

It's not clear what is intended here by "directing any given edit" or "at the direction of more than one person". Presumably the intention is to cover bots that are manually assisted, and require the user to specify some specific information (beyond the name of the page to be processed) rather than bots that run automatically?

Could the guidance be updated to express this clearly?

Martin (Smith609 – Talk) 09:47, 18 March 2019 (UTC)

@Smith609: this is intended to be about bots that are performing assisted tasks or automatic bots that execute on user initiated triggers even when the bot is automatic (e.g. OutreachDashboardBot's creations.) Do you have a proposed rewording? — xaosflux Talk 12:03, 18 March 2019 (UTC)
(edit conflict) I guess the wording is unnecessarily convoluted. How about:
Accounts used for approved bots that can make edits of a specific designated type, at the direction of more than one person, are not likely to be a problem, provided:
Bot account may perform tasks that can be run by multiple persons, provided:
There is no restriction on task automation -- manual, supervised, automatic. There aren't restrictions on number of edits. There isn't a restriction on how the bot's run is timed -- on demand, continuous, one-time, at the same time, etc. There isn't even a restriction on who runs it -- operator, sysop, anyone. Basically, as long as this is disclosed in BRFA. At least, that's the practice. —  HELLKNOWZ   ▎TALK 12:20, 18 March 2019 (UTC)
I'm trying to understand the motivation behind this requirement. In the case of bots that execute on user initiated triggers, users aren't performing the tasks, the bot is. I don't understand why it matters whether the bot was activated by a user or by a CRON job. What is the purpose of being able to identify which user added a page to a bot's queue? Under what situation would it be okay for one user to trigger a bot to act on a page, but not for another user to trigger the same bot to make the same changes to the same page? If there is a problem with the bot, then isn't it the bot's maintainer (not its triggerer) who needs to be made aware of the problem? What exactly is this requirement trying to accomplish? Martin (Smith609 – Talk) 13:37, 19 March 2019 (UTC)
This is a bit of an edge case. A central part of bot operations is that the operator is responsible for all actions made by the bot, this is really about unusual bots that have multiple operators and a situation where a specific action or batch of actions should be associated with one specific operator, so that accountability is maintained. Most bots working under an automation process (e.g. that cron job) are considered the responsibility of all of the operators. — xaosflux Talk 13:52, 19 March 2019 (UTC)
Here, we have a bot with a user page that says "Editors who activate this bot should carefully check the results to make sure that they are as expected." Since citation bot messes things occasionally, knowing who activates the bot can lead to WP:TROUTING those editors who activate it without reviewing the results and let them know if they want to activate the bot, they're responsible for checking that things are as expected after the bot is done. Headbomb {t · c · p · b} 13:57, 19 March 2019 (UTC)
@Headbomb: I'm strongly in support of operators that make their bots trigerable by other users to start a batch (such as your example) and the example I had for OutreachDashboardBot identify the triggering user with the action. I'd say it doesn't remove the responsibility of the operator to be ultimately responsible for the action, but having that accountability is otherwise a good thing. — xaosflux Talk 14:05, 19 March 2019 (UTC)

It seems we all agree that it is best practice to identify the editor who triggered the bot. But is a bot violating policy if it does not do this? That is the nub of the issue at User talk:Citation bot currently — Martin (MSGJ · talk) 11:43, 20 May 2019 (UTC)

Not as written, no. Whether or not the spirit of the policy is violated is a different question. Headbomb {t · c · p · b} 16:35, 20 May 2019 (UTC)

New BAG nomination: Enterprisey

Hi! This is a notice that I have nominated myself for the Bot Approvals Group. I would appreciate your input. Thanks! Enterprisey (talk!) 06:15, 31 July 2019 (UTC)

Bots triggered by multiple users

Hello! Following up on the situations that were resolved with Citation bot, I think it would be useful to record the expectations for bots that can get triggered by other users to make edits without the operator needing to manually review it. Looking for some succinct verbiage to add to the BOTPOL on this. Needs to be broad, but not overly strict. Some obvious examples of bots getting triggered by other users that don't really need anything changes are anti-vandalism bots, copyvio detection bots, sinebot, archive bots. The citation bot issue's discussion has led to what I see a need for certain classifications of bots to authenticate, authorize, and identify the triggering user. The authorization can be simple (such as "is not a blocked user") or it could be more complex - but that degree is probably best left to a BRFA not the policy. I'm looking to record the current standards here moreso then to create a new rule. All input is welcome! — xaosflux Talk 13:20, 7 August 2019 (UTC)

Something like Bots which can be triggered by users other than the operator are expected to display the username of the requesting user in edit summaries and log entries and to not perform actions if the user is blocked or lacks the necessary user rights to carry the action out themselves? Jo-Jo Eumerus (talk, contributions) 13:38, 7 August 2019 (UTC)
Getting there I think - single-page type editing bots probably don't need that far; think this issue was primarily for when you could trigger the bot to edit an arbitrary page? Or perhaps this is really just an issue if the trigger is out-of-band of onwiki edits? It was clear that something needed to be done, and we shouldn't end up in a repeat situation in the future. — xaosflux Talk 13:46, 7 August 2019 (UTC)
For example, Special:Diff/909683673 isn't really a problem - as the source of the triggers is onwiki, logged, authenticated, and restricted - and that edit could include multiple updates from collaborative edits on the request page. — xaosflux Talk 13:48, 7 August 2019 (UTC)
Bots which can be triggered by users other than the operator are expected to publicly display the username of the requesting user in some way and to respect user rights- and block-imposed limitations. to make it a bit open-ended; "in some way" to leave room for bots that are triggered by edits to a page. Jo-Jo Eumerus (talk, contributions) 13:53, 7 August 2019 (UTC)
Jo-Jo Eumerus, That might be an issue for some bots like IABot. IABot can edit through certain levels of protections that new users can't, but new users can invoke the bot to any page they like. Of course they can't configure how it should run as it will use community defined defaults, which I believe is acceptable under the conditions I stated. I think this verbiage would better cover it:

Bots and/or tools that allow users to invoke the bot on a list of pages are required to observe if the user is blocked and to link the username of the invoking user in the edit summary. Bots that allow configuration options for said list must also check that the invoking user can edit through protection if any are applied to pages.

—CYBERPOWER (Chat) 15:26, 7 August 2019 (UTC)
I would prefer to see, for one-off edit kinds of bots triggered by others, OAuth strongly recommended if not required for implementation in these kinds of bots and for the edit subsequently to be performed under the user's name (and/or to ship the editor straight to preview rather than to make the edit itself). The issue with citation bot was the 'category run', which IMO is reasonably a bot edit and which where that sits now should list the implementing user (again, strong preference to OAuth here). (Just getting my objectives on the page; I'll be back later to read other commentary.) --Izno (talk) 16:42, 7 August 2019 (UTC)
I think we would need to define "can be triggered" better. A lot of AnomieBOT's tasks are arguably "triggered" by others, e.g. by someone orphaning a reference, or adding a maintenance tag, or putting a template into Category:Wikipedia templates to be automatically substituted, or doing something on various project pages that are bot-clerked, or making various other edits that manipulate pages' categories, templates, and so on. On the other hand, there's no way for others to get AnomieBOT to do something by visiting any page off-wiki. And I could imagine a bot where edits are "triggered" by submitting a list of pages to a form off-wiki, but the user doing the submission has no control over what the bot does to each page. Where's the line, exactly? Anomie⚔ 16:49, 7 August 2019 (UTC)
I think the key thing for me would be an active choice in what page to trigger the bot on. If the bot always edits the same page, then being triggered to edit that page is not much different than a WP:PURGE. Signbots, vandalbots and dating bots, are not actively triggered, they are reactively triggered. Headbomb {t · c · p · b} 17:16, 7 August 2019 (UTC)
One of the identified problems with citationbot was that unauthenticated users were able to use it to hound another editor by having it follow them around - each atomic edit appeared appropriate, but the result was found to be unacceptable. — xaosflux Talk 17:33, 7 August 2019 (UTC)
Maybe it's better to state a general principle, currently embodied by the points "operator disclosure" and "operator verification". Something like "All decisions about the operation of the bot need to be accountable". (In practice, people want to know which talk page to yell at.) Nemo 18:03, 7 August 2019 (UTC)
As a policy, the more general the better - just want to be careful that we don't make it so broad that it is useless. The primary recipients of the policy are BAG and 'crats who end up approving bots. From a high-level technical perspective, I want to make sure we don't intermix an "operator" (someone who basically has total control and accountability for actions under the account) with a "user"/"triggering editor" of the bot though. — xaosflux Talk 18:07, 7 August 2019 (UTC)
That still leaves something of a grey area, depending on how you define "reactively triggered". The Citation bot queue complained about just above could have been implemented (somewhat poorly) as a wikipage, would the bot reacting to a wiki page edit have been sufficient for that situation? If not, then what about AnomieBOT's TemplateSubster reacting to the template being in a particular category; should AnomieBOT have to somehow dig through page histories to find out who added the category (probably by putting {{subst only|auto=yes}} on the template's doc subpage, but maybe some other way)? And similarly for TagDater and listing a template on WP:AWB/DT? Anomie⚔ 18:48, 7 August 2019 (UTC)
Editing WP:AWB/DT isn't triggering a bot, it is changing the configuration/rules of a weird pseudo-bot, so I think that example is out of scope for this discussion (it's a problem, but it's a different problem). AnomieBOT's TemplateSubster and {{subst only|auto=yes}} may be a real edge case in terms of this discussion, but it is also possible it simply means that that signal ("This template should be substed") belongs inline in the template—and thus subject to the same protection level as the template code—rather than on the /doc page (I need to think about this a bit more). But I also don't think one or two pathological edge cases are dealbreakers for a policy. There is always IAR and BAG discretion (and mandate for discretion can always be codified if really needed).
Other than that, I think y'all are overcomplicating this.
There is a pretty obvious distinction between things like AnomieBOT's TemplateSubster, SineBot, and ClueBOT, on the one hand, and things like Citation Bot and IABot (interactive), on the other. The former are not really "triggered by a user", they are operating autonomously. The user in question isn't directing the bot, they are doing something completely different that happens to be something the relevant bot is looking for: to subst erroneously unsubst'ed templates, to add a missing signature, or revert vandalism. In the latters' case, a user has actively asked the bot to perform a task (regardless of how much or little control that user has over the specifics of the task). It's the distinction between a user triggering the bot and a bot being triggered by something the user does. You can't do anything to make SineBot add signatures to another user's talk page messages, and you can't make ClueBOT revert another user's edits. And in all those cases the operator is responsible for the edits, and presumably perfectly comfortable with that. But you can make IABot add |archive-url= to all citations on an article written by another user (or, to pick a completely random example, mess up the carefully maintained indentation in a citation *cough* *cough*), and you can make IABot do this to all articles another user edits. You can use Citation Bot to bulk change the citations on a range of articles where you disagree with other editors on citation style. For the former group I need to be able to yell at Anomie and Cyberpower678; for the latter I need to be able to yell at whatever editor is being a… is directing the bot.
The duck test is pretty simple: should Martin be blocked when Citation Bot is being used to harass someone? If not, we have a case where the user needs to be authenticated (so the bot knows who is directing it), authorized (so blocked users are denied), and identified (so admins can block someone other than the operator, or other editors know who to yell at). None of the examples given so far (except possibly TemplateSubster and unprotected template /doc pages) seem at all problematic to distinguish here; and absent actual examples of bots that would be inappropriately caught by such a clause we're just bikeshedding.
Also, given the requirements and the state of technological development, I see absolutely no reason why BOTPOL shouldn't require OAuth for these cases now for all new BRFAs. The same for existing bots but with some kind of limited grandfather clause for tasks that are low potential for abuse and negligible risk of controversy (insufficient consensus for the task). Citation Bot failed on both those counts, and was actively abused, so a change was needed there in any case. But for other maintenance-mode/no-longer-actively-developed bots, where retrofitting OAuth would be a big ask, there may not be any pressing need. We're well past the point where OAuth is just "the cost of doing business" (or "table stakes" if you prefer), and if it's too hard for someone otherwise capable of writing a bot that other users can use, then something is wrong with either the bot architecture or the WMF infrastructure. --Xover (talk) 19:09, 13 August 2019 (UTC)

The WP:BOTDEF link in the side box redirects back to this very page, though the "main article" link in the same section works as expected. 69.85.254.70 (talk) 14:24, 17 October 2019 (UTC)

@69.85.254.70:, that's normal, this is an informational shortcut box (see {{Shortcut}}). It tells you what the shortcut for the section is, so you can use it to quickly link to that section in various discussion. Headbomb {t · c · p · b} 18:57, 17 October 2019 (UTC)

Question re:Bot policy page

Bots that download substantial portions of Wikipedia's content by requesting many individual pages are not permitted. When such content is required, download database dumps instead. Bots that require access to run queries on Wikipedia databases may be run on Wikimedia Toolforge; such processes are outside the scope of this policy.

I need to write an algorithm to iteratively return the page content from every link in List of human protein-coding genes 1, 2, 3, and 4, use NLTK to word-tokenize the page, then test whether the page content contains any of the strings "gene", "genes", "protein", or "proteins", returning the page title if the page does not. My motivation for doing that is to fix the links to non-gene-related pages in these tables via recoding the script that generates them. Since this involves accessing ~20000 pages, what quantifies "substantial portions of Wikipedia's content"? Seppi333 (Insert 2¢) 22:51, 25 November 2019 (UTC)

@Seppi333: for such large scale page examinations, you should consider off-line use of a Wikipedia:Database download. — xaosflux Talk 23:08, 25 November 2019 (UTC)
I've never worked with a database dump before; does the pywikibot library support the creation of pagegenerators from links on a page in dump files? Seppi333 (Insert 2¢) 23:21, 25 November 2019 (UTC)
Nvm. Figured it out and already programmed it. Seppi333 (Insert 2¢) 01:46, 26 November 2019 (UTC)
@Seppi333: would you be able to link or describe how for documentation? Wug·a·po·des​ 03:03, 26 November 2019 (UTC)
Are you asking about the generator specifically or the script that does what I described?
@Wugapodes: Either way, after reading the documentation, it doesn't appear that the Pywikibot library supports pagegenerator creation from links on a page in a dump file (see doc.wikimedia.org/pywikibot/master/api_ref/pywikibot.html#generator-options and the pywikibot.pagegenerators.XMLDumpOldPageGenerator() generator further down in the documentation). If it actually does support it, the documentation needs to be rewritten because it's not at all apparent to me how to program that.
If you're interested in the script I used, it's here: User:Seppi333/GeneListNLP. I wrote it as a single-purpose script rather than a reusable module, but I'm sure you can figure out how to revise it to suit other purposes. Basically all you'd have to do to customize it for other pages and use cases is change the pages in listOfPages (these are pages that the script runs the linkedPages generator on) and then modify the tested strings in the relevant line within the genePageTest() function to suit your needs. In other words, just modify these two lines of code:
listOfPages=["List of human protein-coding genes 1", "List of human protein-coding genes 2","List of human protein-coding genes 3","List of human protein-coding genes 4"]

if ("protein" in wordList) or ("proteins" in wordList) or ("gene" in wordList) or ("genes" in wordList):
The script generates a lot of output because I had a secondary use in mind when I programmed it (i.e., assess how many gene pages were located at the gene symbol instead of the official UniProt name in accordance with MOS:MCB). The mistargeted links are saved to a text file called mistargetedLinks.txt (NB: it creates a second similar text file as well, which I'm using to generate a dictionary with piped links for the script that writes the 4 wikitables listed above). Seppi333 (Insert 2¢) 06:12, 26 November 2019 (UTC)
In the event anyone actually reuses this script for another list/article, I'd suggest notifying WT:WikiProject Disambiguation about the entries it finds since they've been quite helpful with adding disambiguation for ~200 pages that were identified when I ran it on the gene lists. Seppi333 (Insert 2¢) 00:26, 30 November 2019 (UTC)

My edit to WP:MEATBOT

Headbomb, I saw that you reverted the edit I made here to this page. I don't understand why you don't believe it do be an improvement, nor do I understand why you believe that I was modifying this section "for the sake of changin [sic] them", as you pointed out in your edit summary. I believe that the changes expand the explanations given and make sentences such as, "For the purpose of dispute resolution, it is irrelevant whether high-speed or large-scale edits that are a) contrary to consensus or b) cause errors an attentive human would not make are actually being performed by a bot, by a human assisted by a script, or even by a human without any programmatic assistance" much more understandable to newer viewers that would've otherwise been more likely to be confused with the status quo. Can you provide some information and thoughts regarding how you came to this conclusion and why? Thanks. ~Oshwah~(talk) (contribs) 03:16, 16 March 2020 (UTC)

An increase in verbiage does not translate in an increase in clarity. I could take any part of the edit and elaborate, but since my remarks will apply to pretty much every passage, I'll take one at random.
Current: However merely editing quickly, particularly for a short time, is not by itself disruptive.
Proposed: However, the sole act of editing quickly, particularly for a short time, is not by itself a disruptive behavior.
What do these add except more words for no reason? There is nothing unclear about the current wording.
Headbomb {t · c · p · b} 03:26, 16 March 2020 (UTC)
And concerning the bit about
If the block is being applied to a "bot" account, or an account that is clearly identified as being an alternative account to the bot operator's main account, the "autoblock any IP addresses used" option should be left unticked so that the block does not also block the bot operator. The autoblock option can always be re-enabled and the block updated later if suspicions arise that the user is continuing to operate the bot while logged out, or while using another user account.
I could be convinced this has merit, but I really don't see the point of this. What admin is autoblocking the IP addresses of malfunctioning but logged in bot's? Headbomb {t · c · p · b} 03:35, 16 March 2020 (UTC)
Headbomb, I understand your argument regarding verbiage vs clarity. To focus on the end of your response (the blockquote), I added these details in order to make sure that this is spelled out. An issue doesn't need to happen in order to give reason to make sure that something is spelled out that should be. In fact, it's better to spell this out and before it becomes a problem, not afterwards... ;-) ~Oshwah~(talk) (contribs) 03:42, 16 March 2020 (UTC)
Phrased differently, what admin is at risk of autoblocking a logged-in bot's IP? If this really needs to be spelled out, that's more WP:ADMINGUIDE material than WP:BOTPOL material, I feel. Others may disagree though. Headbomb {t · c · p · b} 03:45, 16 March 2020 (UTC)
Headbomb - What's the harm in defining this on both pages? :-) ~Oshwah~(talk) (contribs) 03:49, 16 March 2020 (UTC)
Wasting the time of the vast majority of people who read this page? Headbomb {t · c · p · b} 03:51, 16 March 2020 (UTC)
Headbomb - I don't see where adding this information is a waste of time... ~Oshwah~(talk) (contribs) 04:44, 16 March 2020 (UTC)
This page is mostly aimed to bot operators, people who deal with bots on a regular basis, and random passerby. We have a small bit about admin blocks there to let them know what action they should take, but also to let bot ops know that it is standard procedure to have bots indef blocked. Warning against incompetent admin action isn't the purpose of the bot policy. Headbomb {t · c · p · b} 04:57, 16 March 2020 (UTC)
@Oshwah: FWIW, I also found your additions unnecessarily verbose. Anomie⚔ 12:06, 16 March 2020 (UTC)
Anomie - Fair enough. If they're not necessary, then they don't belong. I appreciate your input and your thoughts. :-) ~Oshwah~(talk) (contribs) 12:10, 16 March 2020 (UTC)
I also agree that the language before Oshwah's edit was superior. Nemo 12:59, 16 March 2020 (UTC)

Bot expirations?

I recently ran into another example of a helpful bot, User:Acebot, that seems to have stopped working without explanation (at least that I can find on the bot page or the like). I've run into this sort of situation a bunch lately, so I was wondering (forgive my ignorance), is there some policy that's causing bots to expire once their owners become inactive? Or is there some easy way to report an inactive bot to get it working again? You all probably know better than I do how often expiring bots cause problems, but I do think it would be good if we at least added some documentation to the pages of bots that have expired to make their status clear. And of course, in an ideal situation, bots would get reviewed so that useful ones wouldn't expire. Sdkb (talk) 08:23, 10 March 2020 (UTC)

A bot that is no longer maintained can stop working for a number of reasons, but English Wikipedia policy is not one of them. Reasons for a bot to stop working generally come down to lack of time or interest on the part of the operator. Off the top of my head, direct causes can include
  • Something changes that causes the bot to fail unless its code or configuration is updated, but the operator doesn't have the time or interest to do so anymore.
  • A software update by the hosting provider breaks the bot's code, again requiring a code update.
  • The bot's process stops running or locks up, and the operator isn't paying attention to notice and restart it.
  • The hosting provider where it bot is being run closes the account (or closes entirely).
There's not too much we can do about these sorts of things. Operators who want to plan for this sort of thing happening can host on Toolforge, can add additional maintainers, and can make their source code available so others can fork it. HTH. Anomie⚔ 12:07, 10 March 2020 (UTC)
In the case of Acebot, you could also ask its owner Ace111 (talk · contribs). Headbomb {t · c · p · b} 17:40, 10 March 2020 (UTC)
@Headbomb: Regarding Acebot, it looks like Ace111 has only made one edit since January. Is there somewhere else I should go to request a fix? Without it functioning, a bunch of counts on high-profile pages like WP:About are going to start to go out of date. - Sdkb (talk) 03:43, 21 March 2020 (UTC)
@Sdkb:, yes. That page is User talk:Ace111. Headbomb {t · c · p · b} 04:34, 21 March 2020 (UTC)
@Headbomb: I'm going to assume from the unanswered pings and unanswered request from another editor already on that page that Ace111 isn't active enough to make the fix themselves. Is there nowhere else to turn? Sorry to keep harping on this, but there are hundreds of pages that use {{NUMBEROF}} and no other template that adequately replicates its functionality, so it seems like a task that needs to get done. Sdkb (talk) 04:52, 21 March 2020 (UTC)
@Sdkb: You can slice and dice it however you want, the only way to restart AceBot is for Ace111 to restart it. No one else has access to that account. Contact them, and see how it goes. Don't assume. There could be a million reason for a lack of reply, ranging from forgetting to give one, to taking a vacation, etc... If they don't reply on their/the bot's talk page, send them an email. Maybe you won't get a reply, but maybe you will. Headbomb {t · c · p · b} 09:39, 21 March 2020 (UTC)
@Headbomb: Okay, thanks for the advise; I'll continue reaching out. Since this is the policy page, have you all considered making it a requirement as part of the bot approval process that new bots have their code made publicly available on Toolforge as Anomie alluded to above? (Or, alternately, adding some mechanism for admins to take control of bot accounts operated by inactive users?) Given how open Wikipedia is, I'm not used to encountering anything hidden for reasons not related to privacy/security. Sdkb (talk) 19:19, 21 March 2020 (UTC)
That would be detrimental to several bots, which may re-use non-open code, or deter some bot coders to get involved because they aren't comfortable uploading code publicaly for a variety of reasons (like having a password hardcoded in the source code). Headbomb {t · c · p · b} 21:02, 21 March 2020 (UTC)
Who would do such a thing!! —  HELLKNOWZ   ▎TALK 21:05, 21 March 2020 (UTC)
While the code of the bots I operate is now available on Toolforge, it took several months to get them there. There was a bug that had to be fixed first that prevented me from being able to access it. Hawkeye7 (discuss) 21:22, 21 March 2020 (UTC)
@Headbomb: Ah, I could see that being an issue. As I said below, I'm just jumping in here without prior experience in this area, so I'd guess that you all will be much better at coming up with viable ideas than me. My main goal here is just to make sure we're thinking about the problem of expired bots (given how widespread it is in my anecdotal experience) and brainstorming ways to fight it proactively. I appreciate all the thoughts so far. Sdkb (talk) 21:31, 21 March 2020 (UTC)
"English Wikipedia policy is not one of them" -- but a bot being blocked because the landscape has changed in a way that makes its old code no longer beneficial can be. This happened to Cydebot a few months ago. * Pppery * it has begun... 00:25, 16 March 2020 (UTC)
@Anomie and Pppery: Thanks for the explanation. That seems unfortunate but at least partially inevitable. Still, perhaps some sort of patrol could be created to find and fix expired bots (or tag them as historical if they're no longer needed). Bots could be programmed so that they'd alert the patrol when they encounter an error that forces them to stop functioning. Does that sound feasible? Sdkb (talk) 03:43, 21 March 2020 (UTC)
This idea would have been much more viable if it had been thought up years ago. * Pppery * it has begun... 03:59, 21 March 2020 (UTC)
@Anomie and Pppery: I'll defer to your judgement as you all are the ones actually in the trenches here, but please keep this in mind. Even if this is just something implemented for bots created from now on and past bots are ignored, it'll still pay dividends in the future. It seems odd for bots that stop functioning not to send any alert to anywhere. Sdkb (talk) 05:00, 21 March 2020 (UTC)
It's up to the person who codes each bot to write that sort of code. Note too that several of the ways for a bot to stop functioning would also prevent it from sending an alert. Anomie⚔ 12:54, 21 March 2020 (UTC)
A couple of notes that come up over and over: (1) you should never assume that any bot, or any editor, will ever make another edit or action - anyone can stop at anytime without warning. (2) If a bot isn't working and you want to follow up on it, the right place is at it's operators talk page. — xaosflux Talk 21:18, 21 March 2020 (UTC)
@Xaosflux: I may be misinterpreting your point, but I think in de facto practice, regular editors need to make a lot of assumptions that bots they've seen working in the past will continue to do so, e.g. every time I upload a high-resolution fair use movie poster, I don't check to make sure RonBot is functioning, I just assume it'll be there to downsize appropriately. Waiting for a bot's absence to be noticed before repairing it doesn't seem like the best strategy. As for bot editors, I agree it's definitely important to respect the voluntary nature of the project, but given that some of the tasks bots perform are pretty essential (i.e. the opposite of voluntary), I think where that leaves us is that we need to do more to make sure bots are treated as communal resources that can be operated/maintained/repaired collaboratively the same way everything else on WP is, so that they're not as dependent on the continued presence of their "owner". Sdkb (talk) 21:50, 21 March 2020 (UTC)
In fact, RonBot is not functioning right now, nor was it ever responsible for downsizing images, only determining that they need to be downsized. (actually downsizing the image is done by DatBot, and RonBot's former task is done by JJMC89 bot). * Pppery * it has begun... 23:47, 21 March 2020 (UTC)
It's not functioning, mostly because Ronhjones has been silent for a few months. Headbomb {t · c · p · b} 00:49, 22 March 2020 (UTC)
That is a bot that tries to fix inappropriate uploads, and it is certainly useful - but making an appropriate upload would be even better. Our upload interface and policies don't say anything along the lines of go ahead and upload anything, someone else will probably fix it... But pack on point, I can't possibly see any part of the bot policy evolving to ever require a future edit - besides what would be the consequence of breaking such a policy - barring the editor who wants to make future constructive bot edits from doing so? — xaosflux Talk 00:52, 22 March 2020 (UTC)
I don't think anyone here is proposing that we require bot operators to stick around; neither of the ideas thrown out above (programming bots to issue alerts when they stop working, and requiring some form of communal ownership/transferring capability to keep bots working after their owners become inactive) involve that. I mean, is your view that none of the bots operating on WP are essential? It seems very clear to me that some of them are (and that's a testament to the importance of the work you all do). Sdkb (talk) 01:51, 22 March 2020 (UTC)
@Sdkb: let's phrase it differently then. Which current or future bot, hypothetical or real, would you rather not allow editing on the sole basis of not having publicly accessible source code? Headbomb {t · c · p · b} 02:07, 22 March 2020 (UTC)
I'd certainly always rather have a bot than not have it. It seems like there ought to be other methods of dealing with expiring bots (either through policy or just through common practice) that don't involve mandating publicly accessible source code, though. I hope we'll brainstorm a more viable solution at some point in the future. Cheers, Sdkb (talk) 02:37, 22 March 2020 (UTC)
@Sdkb, Pppery, and Headbomb: There's no nice way to put this, but it turns out that RonBot hadn't been functioning because Ronhjones had passed away with his wife in a house fire See his talk ppage for tributes. I found this conversation by searching for his username in the Wikipedia talk namespace. Graham87 12:25, 6 May 2020 (UTC)
@Graham87: I have to say, I had suspected a death, but I didn't expect a death from a fire. Sad news indeed. Thanks for letting us know. Headbomb {t · c · p · b} 13:08, 6 May 2020 (UTC)

Making BOTCOMM more explicit

WP:BOTCOMM currently implies, and it is strongly implied by culture and (I think) consensus, that operators of bots on the English Wikipedia must be both able and prepared to respond to issues with the bot that are raised on the English Wikipedia (as opposed to another wiki, phabricator, sourceforge, toolserver, or any other location). However this is not stated explicitly and I'm wondering if it would be beneficial to do so? To be clear, I'm not asking for communication about the bot in other venues to be prohibited, an operator can even indicate they prefer to receive communication in those venues. I'm talking only about there being at least one page on the English Wikipedia that is actively monitored by the operator where they can and do respond to English Wikipedia editors about issues with the bot or bots they operate. The operator would remain entirely free to choose which page or pages they wish to use for this purpose. Thryduulf (talk) 15:55, 14 April 2020 (UTC)

No objections to making it more explicit. Headbomb {t · c · p · b} 15:57, 14 April 2020 (UTC)
With SUL how is this a problem, so long as the contact page is actually a user_talk on a WMF project? I'm fine with excluding off-wiki things like email-only, phab, git, toolserver, etc, etc,etc. — xaosflux Talk 16:14, 14 April 2020 (UTC)
I hadn't considered that aspect. As long as the host project is fine with a page there being used for messages in English about en.wp bots then the only potential problems I can immediately think of are (a) its harder for an en.wp user to monitor for replies and (b) a user in good standing here who is blocked on the other wiki. Neither are necessarily show stoppers, but they need more than the minute's thought I've given them so far to determine if they are. Also a contact page doesn't have to be a user talk page, it could be a user page or Wikipedia (talk) page, the key thing is that it is monitored. Thryduulf (talk) 16:43, 14 April 2020 (UTC)
I think bot operators should be reachable in English on a SUL wiki. I don't care if they direct inquires to meta or some other wiki but if registering accounts on other websites or connecting a email to your Wikipedia account is required that would be inappropriate. ‑‑Trialpears (talk) 17:50, 14 April 2020 (UTC)
Support per what I assumed was obvious. Botop should be reachable within Wikipedia ecosystem, not an external website. This should mean bot's and botop's talk pages or at the very least a link to an appropriate (talk) page. I would further add that if botop rarely checks Wikipedia and reaching them externally basically becomes a necessity, then that fails the purpose BOTCOMM too. I keep seeing so many "botop not responding" comments over the years, that it's clearly not stated strongly enough and not enforced at all. —  HELLKNOWZ   ▎TALK 18:06, 14 April 2020 (UTC)
Most of the "bot op not responding" comments I've seen were for bots that have mostly been abandoned or with retired maintainers. Usually the associated bot functions well-enough that no damage is being done, but where new features don't get implemented. Or that some aspect of the bot gets broken to the point of failure, while the others keep functioning as intended. So it's not really a matter of enforcement, more than a slow decay into decrepitude. Headbomb {t · c · p · b} 19:08, 14 April 2020 (UTC)
I think that being able to communicate in English, within the public Wikimedia ecosystem is where I sit. E.g. being reachable only by Git, email, IRC, phone, snail mail, or the 2-meter band would not do. IMO a public Wikimedia phabricator contact solution would be fine (Or, I just don't see the issue with it, perhaps? Feel free to fill me in / inform me). SQLQuery me! 19:17, 14 April 2020 (UTC)
I think it stands to reason that bot operators should probably be accessible/available onwiki, or at least in places that are within SUL. I'd include Phabricator for that (ideally though a specific project within Phabricator, not just "Phabricator") and other projects ... but it should be somewhere. Jo-Jo Eumerus (talk) 19:26, 14 April 2020 (UTC)
Can you log in to phabricator without having an email address set? I know you need to agree to oauth stuff which is possibly daunting for new users. Thryduulf (talk) 20:08, 14 April 2020 (UTC)
I'm a no on phabricator. It has additional hurdles, an entirely new interface and syntax, no visual editor, is not newbie-friendly at all, and if you click on a link "go here to comment", you get prompted to OAuth log in, which then takes you to the main phabricator page instead of where you are meant to be. Headbomb {t · c · p · b} 20:43, 14 April 2020 (UTC)
Thryduulf, OAuth login is an option, as is LDAP/Wikitech. SQLQuery me! 20:48, 14 April 2020 (UTC)
Another point against phabricator is that ip users cannot comment there, but can on (most) wiki pages. Thryduulf (talk) 20:15, 15 April 2020 (UTC)
Bot ops should respond to queries on any of their SUL talk pages, but ideally for EnWiki that would be their EnWiki user talk. Phabricator should not be the only point of communication for bot ops since it's not intuitive for non-technical reporters and not a part of SUL. — Wug·a·po·des​ 20:49, 14 April 2020 (UTC)
Agree, but if they redirect their enwiki usertalk to another project, go there. Also for global bots that only update interwiki data - we don't expect them to maintain a local page (but they need some page and need to be responsive to queries if their bot is running). — xaosflux Talk 22:35, 14 April 2020 (UTC)
Redirects only work within en.wp, to other project they function as soft redirects (see user:Thryduulf/R to other wiki). However a clear and prominent direct link to some other wiki page serves the same purpose. Thryduulf (talk) 01:48, 15 April 2020 (UTC)

Based on the discussion so far I think we have consensus that the following are acceptable locations for the operator of a bot to receive messages about the operation of their bot on enwp:

  1. The bot's talk page
  2. Another page on the English Wikipedia that the bot's talk page redirects or clearly and prominently links to
  3. A page on another WMF wiki that is part of the same SUL group as the English Wikipedia and which is clearly and prominently linked to from either (a) the bot's talk page, or (b) another page on the English Wikipedia the bot's talk page redirects to. This does not include Phabricator.

Any objections to writing that into the policy? Thryduulf (talk) 13:48, 15 April 2020 (UTC)

By "acceptable locations," are we saying that we will require the operator to use at least one of those? Just because "acceptable" could also be read as "if you want feedback on the bot on-wiki, here are the places you're allowed to receive it" (i.e. specifying where feedback could be left). creffett (talk) 20:21, 15 April 2020 (UTC)
Bot operators will be required to use at least one of those locations and respond to comments/concerns/issues with their bot that are left at that location. There is and will be no restriction on using other venues as well, and they can even be marked as the operator's preferred location to receive the feedback, they just cannot be the only venue where they respond. Thryduulf (talk) 20:37, 15 April 2020 (UTC)
All right, then I'd suggest making sure that that's explicit in your update - maybe words to the effect of "Bot operators must designate at least one location meeting (that list of criteria) as their preferred on-wiki contact location for bot-related matters, and are expected to monitor that location" plus your wording above about them being allowed to have other locations. creffett (talk) 22:29, 15 April 2020 (UTC)
I think we're at the point where we give a specific example here of the updated text and tweak anything that needs it, rather than making a change and then discussing how to tweak it. Primefac (talk) 14:12, 16 April 2020 (UTC)

Something simple like

Bot operators should take care in the design of communications, and ensure that they will be able to meet any enquiries resulting from the bot's operation cordially, promptly, and appropriately. Issues and inquiries are typically expected to be handled on the English Wikipedia. Pages reachable via unified login, like a talk page at Commons or at Italian Wikipedia could also be acceptable, so long at it is clear on both the bot page and the bot's talk page that this is where comments should be directed, and that the landing page is not confusing to an English speaker. External sites like Phabricator or GitHub – which requires separate registration or do not allow for IP comments – can supplement on-wiki communication, but do not replace it. At a minimum, the operator should ensure that other users will be willing and able to address any messages left in this way if they cannot be sure to do so themselves. This is a condition of operation of bots in general.

Should be fine, IMO. Feel free to tweak. Headbomb {t · c · p · b} 16:34, 16 April 2020 (UTC)

I've made two very minor tweaks ("inquiries" → "enquiries", "the Commons" → "Commons") and added the clause "although these are acceptable when used in addition to on-wiki pages" making it explicit that phab, etc. are not prohibited they just can't be used alone (which I'm more than happy for others to tweak). Other than that this looks good to me. Thryduulf (talk) 16:49, 16 April 2020 (UTC)
Further tweaked. Headbomb {t · c · p · b} 17:09, 16 April 2020 (UTC)
That looks good to me. Thryduulf (talk) 17:31, 16 April 2020 (UTC)
Thumbs up here. creffett (talk) 17:38, 16 April 2020 (UTC)
Looks good to me. SQLQuery me! 15:08, 18 April 2020 (UTC)
 Done. Primefac (talk) 15:10, 18 April 2020 (UTC)

I'd also like to add that email via Special:EmailUser (or via personal account) as the only means of contact is also not acceptable for the same reasons that Github and Phab are not. Similar issues have occurred with at least one currently-functioning bot because the operator is generally unresponsive onwiki. Does anyone have issue with that? --Izno (talk) 18:19, 18 April 2020 (UTC)

Seems fine by me. Headbomb {t · c · p · b} 18:21, 18 April 2020 (UTC)
 Done Headbomb {t · c · p · b} 18:36, 18 April 2020 (UTC)

Bot code -- can remain proprietary???

Disclaimer: Although I have programmed nearly all my life, and have been on Wikipedia about 12 years, I have never looked into bots until now.

When issues arose over the feedback service for RfCs, I decided to look under the hood and try and help with recent problem with User:Yapperbot which was preceded by User:Legobot.

The new coder Naypta wrote: I can only suppose that the code that is available on GitHub is not the actual code that was running on Legobot, which is part of the reason I didn't waste too much time looking over the code and documenting every part of it. I replied:

This statement is deeply concerning to me. From what you are saying, it sounds to me that you are saying we don't have access to the actual code that is running Legobot and therefore we are not able to change it, and that only the author of the code can. If true, that to me is a big problem.
I don't think bots that can have huge impacts on the project and could make 1000s of edits in seconds should be private.
Also, what if the coder suddenly disappears? What if the code has biases built in that we are not aware of because we can't see and analyze the code?
I didn't reliaze the bots are basically like regular accounts that can be blocked, but are controlled by software.
The potential that the code or data the bot uses might be private and could be changed without our knowledge is very concerning.
It reminds me of all the problems with Black box voting and proprietary software. Richard_Stallman gives his two cents on that.
If the code for some bots really is proprietary I believe that would need to be discussed else, and probably already has. If anyone wants to point me to those discussion(s), I'm all ears.
But I do want to confirm: Is it true that we really don't know for sure what code Legobot is running on?
--David Tornheim (talk) 05:20, 18 June 2020 (UTC)
Authors of bot processes are encouraged, but not required, to publish the source code of their bot. WP:BOTCONFIG Wow. --David Tornheim (talk) 07:53, 18 June 2020 (UTC)

Any thoughts about my concerns here? Isn't there a way to require all bot code to be loaded from a protected page on Wikipedia, so we can be sure we know what exactly what code produced what problem, rather than trust a possibly anonymous coder will not suddenly disappear, and leave us hanging as happened in this case. We might never know what was in the proprietary code that was so important to the project. I was simply shocked to learn that the bot codes for something as important as Legobot can be proprietary. I'm even more amazed how long this part of the policy has been in place--2005.[4] --David Tornheim (talk) 08:26, 18 June 2020 (UTC)

For the sake of ease of reference, I'll copy over my response to this to here:
Well, technically speaking, nobody but myself and the admins of Wikimedia Toolforge knows for sure what code I'm running Yapperbot on I can tell you, and tell you truthfully, that the exact code you find on GitHub is what is running on Toolforge, but there's no independent guarantee of that of course, apart from going and asking a Toolforge admin. I've chosen to host Yapperbot on Toolforge, not only because it provides a free environment for hosting tools beneficial to the Movement, but also specifically because it means that if I'm not around for a long time and things break, someone else can go and request maintainer status on the tool to take over from me. Using Toolforge for a bot, however, is very much not required.
Bots on Wikipedia aren't running elections - they're sending messages, reverting vandalism and handling minor cleanup tasks. I like free software as much as the next person, and I strongly believe that bot operators should make their bot code public, but I don't think it should be that they must do so.
Naypta ☺ | ✉ talk page | 08:34, 18 June 2020 (UTC)
(edit conflict) All of the Legobot source code is public and appropriately licensed as free software. What exactly are you looking for? Legoktm (talk) 08:37, 18 June 2020 (UTC)
@Legoktm: Hi Lego, hope you're well! I dropped you a message on your talk page about taking over the Feedback Request Service a month ago, but hadn't seen any replies - looking at your contributions, I assumed you weren't around for a while, so welcome back. The specific discussion here is with regard to the Legobot FRS code - as had been raised on your talk page a few times, Legobot had stopped sending FRS messages at all for a number of months, so I wrote bot code to do it myself with User:Yapperbot. The Legobot code, which has been looked at for comparison - which I think is actually Harej's original code, just with modifications? - seems to mention "randomness" in its user selection, but then actually just looks like it selects the entire list of subscribers for a given header, no randomness involved. As the FRS pages on-wiki, as well as the source code itself, all mention randomness in the user selection, I posited that it must be that the complete FRS code is not available. Either that, or I'm missing something that picks up randomness (or there's been some miscommunication). Naypta ☺ | ✉ talk page | 08:44, 18 June 2020 (UTC)
Real Life has been crazy, I didn't see your message until now. Glad to hear you've taken over FRS. I just checked, what's in my Toolforge crontab is the exact same version that's on GitHub, no live hacks or anything.
Harej wrote the first version, at some point Chris G rewrote it, and I picked it up when he needed a new owner. I don't really remember how it works, it's all a giant mess anyways. That said, you should probably update User:Harej/Bots now :) Legoktm (talk) 09:16, 18 June 2020 (UTC)
@Legoktm: Cheers! I'm not sure what I'd be updating at User:Harej/Bots, though - I'm running a complete rewrite of the FRS code in Golang, rather than just Harej's code. I hope you're doing okay - things have been all sorts of crazy for all sorts of people recently, please don't let myself or anyone else pull you back into the wiki earlier than you're ready Naypta ☺ | ✉ talk page | 09:42, 18 June 2020 (UTC)
(edit conflict) Here's my perspective. None of AAlertBot code is public (although another editor has access in case of bus). I want to open-source it. But I am not doing so and all the reasons are my ability to maintain it. It's a gigantic legacy codebase of a dozen years and if more than one person starts changing things, I won't be able to keep up and effectively maintain it and thus unable to follow BOTPOL. I simply don't have the time to do so (for free, no less). If I had to keep it open source to begin with, the bot wouldn't exist. I think the same is true for many other bots. We're trading longevity for usefulness. —  HELLKNOWZ   ▎TALK 08:50, 18 June 2020 (UTC)
Publishing source code doesn't mean you have to accept others contributions. Even uploading a tarball of source code is a big step in ensuring that if something does go wrong, it can be sustained. You can also release it under a free license, but not actually distribute it to anyone but your one person - that will give them the ability to share the code later on if something goes wrong. Ultimately that was what killed the first AAB :( Legoktm (talk) 09:16, 18 June 2020 (UTC)

All code in the Tools project is published under an OSI approved open source license [5] Hawkeye7 (discuss) 11:24, 18 June 2020 (UTC)

@Hawkeye7: Bots aren't required to be on Toolforge, though, so the point is sort of moot. (I say this as someone very happy to use Toolforge, and to publish all my bot source code under GPL!) Naypta ☺ | ✉ talk page | 11:32, 18 June 2020 (UTC)
Too right! I used to run mine on my own servers, but one summer I had a failure while I was away, and decided to move to Toolforge. It took two years before they fixed the Github on Toolforge so I could use it. Hawkeye7 (discuss) 11:46, 18 June 2020 (UTC)
Bots don't have any requirement to have public code. All edits and actions made by a bot are the responsibility of its operator, this coupled with the tenet that no editor can ever be required to make a future edit or action means that no one should become dependent on a bot to ever be running. It is certainly welcome to have published code, so that someone can take over wanted tasks if the operator packs up shop one day. — xaosflux Talk 12:36, 18 June 2020 (UTC)

Kind of a derail but "1000s of edits in seconds" isn't really a thing though I understand your point being "a lot of edits" but according to Wikipedia:Statistics it is 1.9 edits per second, which is calculated by {{#expr:({{NUMBEROFEDITS:R}}-843241557)/({{#time:U}}-1530212463) round 1}} producing 2 -- GreenC 16:57, 18 June 2020 (UTC)

I'd honestly support the perhaps-radical idea that every bot or significantly-used tool should be open-source on en.wp, or else it doesn't get included for use or widely. There's a related conversation at VPT about another tool where the author isn't using the infrastructure available and we can't do anything about it. If those tools are needed, our project shouldn't be hostage to those authors. If they are unable or unwilling to provide open-source support, then we shouldn't provide our support for use. --Izno (talk) 16:40, 23 June 2020 (UTC)

Anyone is free to recode anything openly. Headbomb {t · c · p · b} 16:56, 23 June 2020 (UTC)
That's true. But irrelevant to my point. --Izno (talk) 17:16, 23 June 2020 (UTC)
Toolforge is good for everyone for a lot of reasons. BRFA masters might ask "Have you considered hosting on Toolforge and why not?" (a default question in the form) with a link to a short intro doc on creating an account, setting up a project, logging in, and how to run a 1-time script with jsub on the grid, and making a crontab entry. A nudge but not requirement. Also a question who their Toolforge backup person in case of bus. -- GreenC 17:22, 23 June 2020 (UTC)
Any open repository is great really. If toolforge is prefered, again, we could encourage, but not mandate. I like the idea of having at least one backup person. Again, optional. Headbomb {t · c · p · b} 17:53, 23 June 2020 (UTC)
@GreenC: does such a quick start guide exist in one place? — xaosflux Talk 17:55, 23 June 2020 (UTC)
wikitech:Portal:Toolforge/Quickstart? Anomie⚔ 20:49, 23 June 2020 (UTC)

BAG nomination

Hi! This is a procedural notification that I've requested to join the Bot Approvals Group. Your comments would be appreciated at the nomination page. Thanks, ProcrastinatingReader (talk) 01:56, 17 November 2020 (UTC)

Another BAG nomination

This is a procedural notification to note that I have requested to join the BAG. Your input is welcome at the the nomination page. – SD0001 (talk) 17:13, 17 November 2020 (UTC)

Problems with WP:BOTMULTIOP

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)

"Wikipedia talk:BOT" listed at Redirects for discussion

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)

I speedy closed this as being unnecessary. Primefac (talk) 17:21, 25 March 2021 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Bot_policy/Archive_28&oldid=1137404147"