Wikipedia talk:Bot policy

Does a bot require an authorized account if it doesn't make edits

I'm just curious, do you need permission to use an algorithm to comb through information on Wikipedia (like to find out how many times a word appears on Wikipedia, finding the pages that get edited the least, ect.) Assuming that it's code isn't on Wikipedia. I currently don't have the knowledge or skills to program something like that, but I'm still curious, and I might eventually have the ability to program that. Not a kitsune (talk) 15:26, 7 January 2024 (UTC)

@Not a kitsune in general you don't even need an account to just read pages. However, if you generate some sort of exceptionally high number of requests that cause disruption to the systems the system administrators may block your connection. If you want to do some very heavy mining you are likely going to be better of using a WP:DUMP that you can download and mine off-line - especially as your use case seems to be for looking at the "current version" of pages and not being particular if the page is slightly out of date. — xaosflux ^Talk 16:12, 7 January 2024 (UTC)

See also WP:EXEMPTBOT Headbomb {t · c · p · b} 23:37, 7 January 2024 (UTC)

thanks for answering my question. Not a kitsune (talk) 21:14, 17 January 2024 (UTC)

Require tracking maxlag

The policy currently does not mandate tracking the maxlag parameter. Wouldn't it make sense to have this tracking be a explicit requirement considering that most bots will already have to follow it to be compliant with the API Etiquette ? Sohom (talk) 22:24, 3 March 2024 (UTC)

Courtesty ping Novem Linguae :) Sohom (talk) 22:28, 3 March 2024 (UTC)

Ah, I didn't know this was in API etiquette. Interesting. I'm still mildly opposed, but let's let others weigh in. –Novem Linguae (talk) 22:33, 3 March 2024 (UTC)

I will preface by saying that I don't know exactly how the backend of AWB works, but if it doesn't track maxlag then we should not mandate its tracking because any AWB bot would automatically be violating it. Primefac (talk) 12:23, 4 March 2024 (UTC)

My understanding is that Pywikibot and AWB both already track maxlag (I might be wrong though). WP:JWB appears to not track the parameter though, maybe we can the ask the maintainer to add support for it. Sohom (talk) 12:46, 4 March 2024 (UTC)

I note the reverted edit to this policy had changed "may" to "should", not "must" as implied by the paragraph here. The API Etiquette page also says "should". That stops short of a requirement, particularly if we're using plain English meanings rather than RFC 2119. Since we seldom directly review the code, and have no way to verify that the code posted is actually the code running or to check the parameters on API queries made, any actual requirement would be nearly unenforceable by us anyway.

As for "may" versus "should", again particularly since we're using plain English meanings rather than RFC 2119, I find myself without a strong opinion on the matter. "Should" seems fine to me, as long as people aren't going to try to misinterpret it as a requirement and start "attacking" bots they don't like over it. Anomie⚔ 06:44, 5 March 2024 (UTC)

It is my view that if you put "should" in a Wikipedia policy, that folks will interpret it as a requirement. –Novem Linguae (talk) 14:48, 5 March 2024 (UTC)

Bot policy questions

Have two, separate, questions about the bot policy that I've come across in the last 10 days that I can't find the answers to so far.

1. If a bot (and operator) have been inactive for 10+ years, and the bot has been deflagged, is that all that needs to occur, or does the bot also need to be preventatively blocked without prejudice?

2. Can bots (approved by another language wikipedia) operate here too as is, or do they additionally need en wiki approval? If it is not a one for all situation, how would one determine if they have en wiki approval?

The reasons I'm asking are: For the first case, I've seen a few bots that were blocked so they couldn't be hacked into and become destructive, but I think those were in slightly different situations than this one. And in this case, the operator (in good standing) just never returned. And for the second (unrelated) case, bot #2 has not done anything problematic, I just haven't encountered any other cases like this and being cautious.

I'm not naming case 1 or case 2's bot at this time, but can if there's no issue in doing so, and/or is needed to better answer either case. Thanks, Zinnober9 (talk) 16:21, 4 June 2024 (UTC)

1) I don't think we have a policy/guideline/norm that inactive bots need to be blocked. 2) I don't think global BRFAs are honored by enwiki, with an exception for updating interwiki links. We have some kind of opt out, so bot operators from other wikis need to go through the enwiki WP:BRFA process. I think there's more info at WP:INTERWIKIBOT and WP:GLOBALBOTS. –Novem Linguae (talk) 16:45, 4 June 2024 (UTC)

Blocks are only needed for bots editing without authorization. Approvals on other projects don't count here - however you can point to examples of a successful task on another project when applying here. Keep in mind we require each task a bot is going to be approved, not just the account. — xaosflux ^Talk 17:02, 4 June 2024 (UTC)

1, That is what I figured, thank you both.

2. Xaosflux, Thank you. I wasn't asking from the operator point of view, as I have no bot and not planning on operating any. I had come across a bot account that had made a few edits here and was from another wiki. Their edits (here on en) have been primarily related to some articles in regard to images that were globally renamed (7 en wiki edits 2014-22), and more recently, has only been editing on two user's subpages (114 since Feb). One is the operator's, the other user I don't know their connection to the operator/bot. Those recent edits in userspace have been to create a list of various user's .js pages (one edit), and to keep and update a report list of recent en wiki draft to mainspace moves by any user (113 edits). Zinnober9 (talk) 20:43, 4 June 2024 (UTC)

Regarding userspace edits, Wikipedia:Bot policy#Valid operations without approval allows for bots to edit their own or their operator's userspace without approval (as long as the edit isn't otherwise disruptive). Editing other users' userspaces isn't allowed without approval under that exception though. Anomie⚔ 21:48, 4 June 2024 (UTC)

Approval by BRFA, or approval by the other user to edit in that user's userspace? It seems that the other user asked for the bot to generate the report. My feeling is that it would better for the bot to create the report in its own userspace, keep things neat and tidy within the userspace boundaries and then have on the other user's page a transclusion of the new page "{{BotFooReport}}" from the bot's userspace, but since I'm not sure I can satisfy their questions at this point, the discussion is here. Zinnober9 (talk) 22:01, 5 June 2024 (UTC)

Approval by BRFA. Anomie⚔ 12:00, 6 June 2024 (UTC)

I think this rule is sometimes bent. See the bottom of Wikipedia:Bots/Requests for approval/NovemBot 7, for example. –Novem Linguae (talk) 04:34, 6 June 2024 (UTC)

I don't see the linked BRFA itself as bending the rule, it's exactly the kind of thing that should happen if someone wants a bot to edit outside of their own or the bot's userspace. The speedy approval is also fine if the BAGger is confident that a trial isn't needed to expose problems with the task. OTOH, I think @Primefac erred in that case by implying that that BRFA was unnecessary. Anomie⚔ 12:00, 6 June 2024 (UTC)

Eh... genuinely don't remember what prompted me to type that, but you're correct. I have amended the close. Primefac (talk) 14:06, 6 June 2024 (UTC)

Move+ Link Correction

I've created a script, Move+, that assists with closing requested moves and moving pages. One of its functionalities is to help cleanup after moves by fixing mistargeted Wikilinks, which I believe falls under WP:ASSISTED.

However, I've recently discovered that the number of links to be fixed can sometimes be very high, and following discussion with Ahecht and SilverLocust I now believe that it is too high for WP:ASSISTED. My plan is to only allow normal users to resolve these links when the number is sufficiently small, and otherwise require that a user be a bot, but I'm not sure where to draw the line. My initial thoughts are 1000 links?

Once I've implemented the limit I intend to create User:Platybot and go through WP:BRFA. BilledMammal (talk) 01:33, 4 July 2024 (UTC)

Could you give an example of what's intended to be fixed here? Maybe one with only a few links to fix, and one with a multicrapton of links? And how would this not go against WP:NOTBROKEN? Headbomb {t · c · p · b} 01:59, 4 July 2024 (UTC)

For example, if we decided that China was no longer the primary topic, and instead moved China (disambiguation) to that title, we would need to retarget every link currently to China to China (country), because otherwise they would take readers to the dab page, rather than the intended page.

I can't give real examples because those are fixed quickly, typically by approaches requiring more editor time than Move+ requires, but a hypothetical with a multicrapton would be the China example, while a hypothetical with only a few would be if we decided George Peabody Library should be a disambiguation page. BilledMammal (talk) 02:05, 4 July 2024 (UTC)

See Wikipedia:Cleaning up after a move#Fix mistargeted wikilinks. This is for moves where the old title becomes a disambiguation page, so the links have to be updated. That info page suggests WP:AWB or another semi-automated script. The other one I can think of – and the one I use – is DisamAssist. For either of those, you have to confirm each edit you make. Cf. WP:AWBRULES.

I'd suggest two reasons this feature of Move+ is automated editing rather than semi-automated: (1) the ratio between the number of buttons the user presses to the number of resulting edits is very high, and (2) the a script can keep editing for more than a couple seconds without your input.

In other words, I think 1000 would be way too high. I don't really even like rmCloser's ability to move several pages in a mass move. SilverLocust 💬 02:09, 4 July 2024 (UTC)

rmCloser doesn't really support moving several pages in a mass move, as it starts to fail when moving more than a few pages; its part of the reason I created Move+.

However, there are some scripts that do genuinely support mass moves, such as User:Ahecht/Scripts/massmove.js, but I am willing to add limits to Move+ for this as well? BilledMammal (talk) 02:16, 4 July 2024 (UTC)

I was thinking about the mass move scripts after my reply and seeing Headbomb's. I think Headbomb's point about giving a higher limit based on user rights is a good one. Like how mass mover is limited to page movers and admins. Though I very much don't think pagemovers should have an unlimited amount. Perhaps admins > page movers > extended confirmed > autoconfirmed (along with giving a warning about how many links it will need to change). (I had never tried moving a bunch of pages with rmCloser, given my reluctance to automate things too much [edit: without a bot, that is]. I had looked at rmCloser and didn't see any numerical limit. So I assume that's just from the time limits that it has.) SilverLocust 💬 02:37, 4 July 2024 (UTC)

Currently, it only lists the number of links to update after starting. I'll put that on the todo list.

I'll definitely add limits to the number of pages permitted to be moved in one action by editors who don't have relevant advanced permissions; I'll watch the discussion to see if I should also add them, at a higher level, for page movers.

(Yep; rmCloser doesn't consider server side rate limits, and its actions start to be rejected because of that. Move+ doesn't consider it for one part of the process that has remained unchanged from rmCloser; it causes some issues, but I haven't got around to fixing it yet.) BilledMammal (talk) 03:09, 4 July 2024 (UTC)

Ah I see. Could the script check for pagemover/editconfirmed rights, or something similar (e.g. a whitelist of users, similar to AWB) and have the threshold depend on those rights? Headbomb {t · c · p · b} 02:10, 4 July 2024 (UTC)

It already checks for rights in deciding which page move options to offer, so it could easily check when considering the limit. A whitelist would be a little more work, but still simple enough to implement. BilledMammal (talk) 02:16, 4 July 2024 (UTC)

Just ideas. For users with a regular trust, I wouldn't go over 250. Maybe 100. For admins, or those with advanced trust, I'd say no limits. Headbomb {t · c · p · b} 02:33, 4 July 2024 (UTC)

That sounds reasonable for regular users. For admins and extended movers (I assume that is who you mean by advanced trust), I don't object to no limit, but I'll see what other editors think, or if they believe there is a point where it should be done on a bot account. BilledMammal (talk) 03:01, 4 July 2024 (UTC)

I agree it would be preferable by bot account, if only because you can suppress bot from the watchlist. Headbomb {t · c · p · b} 03:23, 4 July 2024 (UTC)

I've actually tried setting it as a bot edit for all users, but either I'm not calling the morebits function correctly, or accounts need to be flagged as a bot for that to work. I'm assuming the second?

Do you think a hard limit is a good idea then, or would you prefer a soft limit that recommends the use of a bot account? BilledMammal (talk) 03:34, 4 July 2024 (UTC)

Yeah, only bots have the bot edit flag. SilverLocust 💬 03:48, 4 July 2024 (UTC)

A real example would be Talk:Australian#Requested_move_20_October_2022, in which there were 700-1000 links to process post move. It was cleaned up within 24 hours with the help of other editors who picked the newly dabbed title up at the disambiguation wikiproject (DYK they have a report for dab pages with massive numbers of links going there?) – robertsky (talk) 02:38, 4 July 2024 (UTC)

(DYK they have a report for dab pages with massive numbers of links going there?)

I did not! (Although, generally I think manual review of every link is a waste of editor time - it would be better to create a script that finds ones likely to be problematic and presents only those for manual review. It's currently on my todo list for Move+, but I'll prioritize it - I've almost got "Add support for actioning technical requests" done, and once finished I'll do it. One issue I found in the past with dabassist is that it didn't immediately present the next text to review, so I'll make sure that is addressed - if there are other useful features this function could have please let me know, either at User talk:BilledMammal/Move+ or here.) BilledMammal (talk) 03:01, 4 July 2024 (UTC)