Wikipedia:Bots/Requests for approval/MusikBot II 4

The following discussion is an archived debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA. The result of the discussion was

Approved.

MusikBot II 4 edit

New to bots on Wikipedia? Read these primers!

Approval process – How this discussion works
Overview/Policy – What bots are/What they can (or can't) do
Dictionary – Explains bot-related jargon

Operator: MusikAnimal (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 00:59, Thursday, June 11, 2020 (UTC)

Function overview: Adds protection templates to protected articles where they are missing.

Automatic, Supervised, or Manual: Automatic

Programming language(s): Ruby

Source code available: GitHub (new relevant code is not pushed yet)

Links to relevant discussions (where appropriate): Wikipedia:Bot requests#A bot to add missing instances of padlocks (permalink)

Edit period(s): Every 10 minutes

Estimated number of pages affected: 5-10 a day (estimate)

Namespace(s): Mainspace

Exclusion compliant (Yes/No): ~~Yes~~ No (see comments)

Adminbot (Yes/No): Yes

Function details: This is an extension to MusikBot 9 (removes protection templates from unprotected pages) and a replacement for TheMagikBOT 2 and Lowercase sigmabot 1 (both of which have long been retired).

The logic is to comb over the protection log, and look to see if the pages have transcluded a protection template. The list of templates to look for is defined in the "base_protection_templates" hash at User:MusikBot/FixPP/config (to be moved to User:MusikBot II/FixPP/config). It also looks for redirects of each of these templates. The existing task to remove protection templates uses this same configuration.

Summary:

It will only run in the mainspace, since padlocks are not necessarily desirable in other namespaces.
It will only add either {{pp|small=yes}}, {{pp-move|small=yes}}, or {{pp-pc|small=yes}} as applicable. The associated Lua module for each template will ensure the correct padlock is displayed based on the protection level.
For redirects, it won't add a template if {{Redirect category shell}} or any of it's redirects are present. These templates already automatically show the appropriate padlock.
It will run on fully-protected pages, hence why I am filing this one under MusikBot II. Consequently, the task to remove protection templates will run under MusikBot II as well since they are currently implemented in the same module. However I can keep them separate, if we feel that is better.
- WP:AN notice; according to WP:ADMINBOT a discussion should have happened there first, sorry about that.
Since the bot queries by the protection log by timestamp, it never iterates over the same article twice. This prevents the bot from edit wars, whereby it keeps reinstating the template after it was intentionally removed.

There was also talk about the bot fixing incorrect protection templates, such as changing {{pp-pc}} to {{pp}} if it's only normal edit protection. The bot already has a "normalize_pp_template" option at User:MusikBot/FixPP/config which was built to do this, but it has not been thoroughly tested nor approved in the previous BRFA. To keep things simple I'll save this for a separate BRFA.

Discussion edit

I'm unsure about adding padlocks when the article is only move-protected. Some may prefer it not to be there since most people aren't interested in moving the page, and the padlock can even be misleading if there's no edit protection. I brought this up in the discussion and no one voiced concerns, however. I could go either way.
I also wonder if it should use {{pp-semi-indef}} or {{pp-move-indef}} when applicable. I suppose there's no downside, and the benefit is the categorization you get. — MusikAnimal ^talk 00:59, 11 June 2020 (UTC)[reply]

Surprised we didn't already have this...mostly because I thought we already did. Whoops. Sounds like a good idea. I don't have problems with move protection padlocks, but would be fine with them not being added for the reasons you give. Using the more specific templates when possible is a good idea. Thanks for doing this. — Wug·a·po·des 03:00, 11 June 2020 (UTC)[reply]

Your memory serves you correct; There were two other bots in the past that did this, but they've since retired. I just realized, since MusikBot queries by the protection log by timestamp, you shouldn't ever be stuck in a scenario where you keep removing the template and the bot keeps adding it back. That makes me feel a little better about adding {{pp-move}}. — MusikAnimal ^talk 03:27, 11 June 2020 (UTC)[reply]

Like Wugapodes above, I'm surprised we don't already have this. Excellent task for a bot. -FASTILY 03:28, 11 June 2020 (UTC)[reply]

Comment. I'm going to "start the clock" on discussion, as I see there is an AN thread having been posted. If there's no significant opposition for the task I'll put it to a trial towards the end of next week. Primefac (talk) 13:11, 11 June 2020 (UTC)[reply]

Seems good to me. If there's any type of protection, I'd prefer it to be shown (even if just Move). However, if a page has both some edit protection and move protection, it should show add the edit protection template only (as only one padlock should be shown, and edit limitations are more relevant to know) Nosebagbear (talk) 14:38, 11 June 2020 (UTC)[reply]
(this will be easily answered once the code is up but) Is there a minimum time left before adding? Presumably checking the log is to only process new protections, but I vaguely recall that Magik wouldn't add a template if the page was only going to remain protected for a short period of time, is that right? I'm not sure I would set it anything higher than 3 hours, but just figured I'd check. ~ Amory (u • t • c) 13:07, 12 June 2020 (UTC)[reply]
Good idea. I can definitely have it skip pages that were protected for less than some configurable amount of time (3 hours sounds reasonable). The code is unfinished for this very reason; I usually wait for a trial to start before finishing and publishing the code, since the BRFA itself invites a lot of changes and I don't want to have to re-do any work :) But the core of it is there, and I'm confident I can satisfy all the requests made so far. Keep the ideas coming! — MusikAnimal ^talk 19:33, 12 June 2020 (UTC)[reply]
I've always wondered why these aren't part of the interface. —Cryptic 19:14, 12 June 2020 (UTC)[reply]
Approved for trial (50 edits or 7 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Whichever happens first. Primefac (talk) 17:04, 19 June 2020 (UTC)[reply]

Trial complete. [1] Amazingly, we ran into about every scenario I wanted to test during the trial:

Special:Diff/963654652 - adds {{pp-pc}}
Special:Diff/963655768 - adds {{pp-move}}, but this was for Today's Featured Article. I am safely assuming we don't want a padlock on TFAs, so I added a special exception to ignore protections added by TFA Protector Bot.
Special:Diff/963658776 - added {{pp}} to a redirect, but made the rookie mistake of putting the template above the #REDIRECT syntax, which breaks the redirect. I fixed the bug and re-ran on that page, see Special:Diff/963659494.
Special:Diff/963661065 - adds {{pp-move-indef}}
Special:Diff/963661640 - adds {{pp-semi-indef}} (in this case the page is a redirect)
The rest simply added {{pp}}, such as Special:Diff/964116846.
The bot did run into redirects that had {{redirect category shell}} (or equivalent template) and those pages were correctly skipped.
Regarding Amorymeltzer's point about skipping pages if there only protected for another 3 hours: I actually didn't implement this. I thought about it more and to me, at least, any amount of time would seemingly be worthy of showing the padlock for the benefit of the editor. I think TheMagikBOT was different because it didn't handle removal of templates, while this bot handles both. So the template would only linger there unnecessarily for no more than 10 minutes, and the Lua module actually hides the padlock if the page isn't protected, anyway. Let me know if you still think this will be a problem!
Finally, I did not make the bot exclusion compliant, yet... This is actually the first task I've written that has a remote use-case for being exclusion compliant, and it's not exactly simple to implement it. So before I spend the time ironing out the regex, I'd like to first ask how important we think exclusion compliance is. According to User:AnomieBOT/Nobots Hall of Shame/0, there are zero mainspace pages that deny all bots, which is what I would expect. I'm not sure why you would specifically deny this bot, either. As mentioned in the function details, you can always remove the protection template without worry of the bot adding it back. Even if you did want to preemptively deny the bot, you might forget you added the {{nobots}} (etc.) and indefinitely that page gets ignored. This would seemingly only be desirable for a test page, and those don't belong in the mainspace. What do you think? — MusikAnimal ^talk 19:22, 23 June 2020 (UTC)[reply]
FWIW, I mostly meant it to avoid unnecessary edits, it's not a huge concern (and, if I'm being honest, I kind of like the on-off edits since it's easier to tell when protection ended). ~ Amory (u • t • c) 00:08, 24 June 2020 (UTC)[reply]
Approved. Sorry for the delay, thought I had already approved this! Primefac (talk) 18:35, 30 June 2020 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA.