Jump to content

Wikipedia:Bots/Requests for approval/Protection Helper Bot

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Daniel Quinlan (talk | contribs) at 22:06, 3 September 2024 (Discussion: Reply). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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

Time filed: 22:10, Tuesday, July 30, 2024 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available: The source code will be made open source on GitHub if the bot is approved and once it is operational.

Function overview: The bot will automatically restore long-term page protection levels after shorter-term higher protection levels expire to reduce administrator workload and to avoid unintentionally leaving at-risk pages unprotected.

Links to relevant discussions (where appropriate): Special:Permalink/1237644057#Bot_to_restore_long-term_protections_after_shorter-term_higher_protections_expire

Edit period(s): Continuous

Estimated number of pages affected: roughly 50 to 200 pages per year

Exclusion compliant (Yes/No): Yes

Already has a bot flag (Yes/No): No

Function details: The Protection Helper Bot will automatically restore the original long-term page protection level after a temporary higher-level protection expires. This bot will:

  • Monitor the protection log to track when temporary higher protection levels are scheduled to expire.
  • After scheduled expirations, check the page protection status and restore the previous long-term protection if needed.
  • Ensure that protection changes are logged with the appropriate reason and attribution to the original protecting administrator.
  • Notify the most recent protecting administrator about the restoration action to allow for any necessary adjustments.
  • Skip pages with the {{bots}} template indicating exclusion from bot actions.
  • Stop all actions if an emergency shutoff method is activated.
  • No action will be taken if the duration of the higher protection level extends beyond the prior protection's expiration date, or if the protection level is the same or lower.
  • The bot will initially rely on existing bots to update protection templates as needed, but that functionality may be added in the future.

Minor adjustments to the bot's operation may be made based on feedback.

Discussion

Approved for trial (25 edits or 30 days, whichever happens first). Please provide a link to the relevant contributions and/or diffs when the trial is complete. I am counting these 25 edits as page protections (since page protections show as "an edit" in the page history) but please make sure the edit log posted at the end of this trial also contains any user talk notifications as described above (in other words, if I'm reading the functionality correctly, there will be up to a total of 50 edits made). Primefac (talk) 23:44, 4 August 2024 (UTC)[reply]

I had a few comments but I've accidentally lost them. Roughly speaking:

  • I don't think it makes sense to exclude pages with {{bots}} - that would allow non-admins to control protection status of pages. Further, often the template is added to deal with minor content adjustment bots or buggy bots affecting singular pages, and not this particular bot.
  • It may be good for there to be a mechanism for an admin to prevent reprotection of a page by the bot. As it stands, my understanding is that the admin will only be notified after the reprotection is reinstated. If the temporary protection is that of ECP for 6 months, for example, the original admin may not even be active when the original protection is reinstated, which hurts effective review. One mechanism might be an ignore comment in the protection log prevents the bot from acting, and the bot informing the admin it will do a reprotection as soon as they change the protection level, rather than when the bot is due to change it back. There might be other ways too.
  • I would ask the source code be released as a condition of approval, prior to approval, especially as this is an adminbot and behaviour in edge cases is relevant. That would also allow for better scrutiny of the bot prior to approval.

ProcrastinatingReader (talk) 02:32, 15 August 2024 (UTC)[reply]

I have some thoughts on each of those points:
  • I agree that giving all editors the ability to override a protection reinstatement simply by slapping a {{bots}} tag into an article is a bad idea.
  • This bot doesn't need to have any additional mechanism to prevent reinstatement of protection (which I see as unlikely to be needed). The mechanism is already there. An administrator who wants to prevent reinstatement would merely perform two actions: first re-protect for a short duration (or just unprotect), and then apply the second temporary protection for a longer duration. When the temporary protection expires, the original protection would also be expired, and the bot does nothing.
  • A source code review would be good. I thought that was standard procedure, especially for admin bots, but I am unfamiliar with how bots get approved.
~Anachronist (talk) 17:48, 31 August 2024 (UTC)[reply]
I will also chime in and request that the source code be made available before approval. EggRoll97 (talk) 19:01, 1 September 2024 (UTC)[reply]
I also feel it is important that the source be released and a reasonable amount of time be allowed for review before approval for production use. RoySmith (talk) 19:06, 1 September 2024 (UTC)[reply]

@Daniel Quinlan: This bot was approved temporarily and the approval period is almost done. I have seen no activity from this bot. Were you planning to start it up?

Also, your source code availability conditions are backward. For something like this, it should be available for examination before approval, not after. ~Anachronist (talk) 19:12, 1 September 2024 (UTC)[reply]

I don't think releasing source code is a normal BRFA requirement. I think BRFA is normally based around consensus for the task plus performance in trials. –Novem Linguae (talk) 19:55, 1 September 2024 (UTC)[reply]
I'm pretty much a BRFA newbie, but I've been editing wikipedia for almost 20 years, been working on open source coding projects longer than that, and writing software in general a lot longer than that. I'm just not seeing any reason to make releasing the code conditional on approval to run it. RoySmith (talk) 20:08, 1 September 2024 (UTC)[reply]
Assuming good faith, Daniel probably meant something like "let me get the bot working, then after that I'll take the extra time and effort to spin up git and a GitHub repo". –Novem Linguae (talk) 20:52, 1 September 2024 (UTC)[reply]
I'm always happy to AGF. I guess I was mostly responding to the statement that BRFA doesn't normally require releasing the source code. If that's true, I think it's an unfortunate state of affairs. I was also thinking of a conversation I recently had in another setting regarding the fragility of the whole ecosystem of scripts, bots, and other bits of software on which the smooth running of enwiki depends, and how often some important tool gets abandoned with no practical way for another developer to take it over. But, I really shouldn't be trying to make this particular request a soapbox for all that. RoySmith (talk) 21:27, 1 September 2024 (UTC)[reply]
Thanks for sharing your views. I might be open to supporting a rule that complex bots need to have their source code in the BRFA, if proposed on the right talk page. I agree that it helps immensely with keeping old bots running once their owners go inactive. –Novem Linguae (talk) 21:54, 1 September 2024 (UTC)[reply]
For an admin bot like this, the bot policy recommends (but doesn't require) a source code review. The review doesn't have to be community-wide. ~Anachronist (talk) 22:48, 1 September 2024 (UTC)[reply]
@Novem Linguae: Per the bot policy, It is recommended that the source code for adminbots be open, but should the operator elect to keep all or part of the code not publicly visible, they must present such code for review upon request from any BAG member or administrator. I am not either (though I would fancy myself technically competent enough to have a look through it), but at least two administrators and a BAG member have now requested that the source code be made available. While providing the code privately to those individuals would technically satisfy the conditions of WP:ADMINBOT, I don't see any reason why the source code would need to be private. EggRoll97 (talk) 22:35, 1 September 2024 (UTC)[reply]
@Anachronist: I've been pulled away from working on this the last few weeks, but the bot is nearly ready for activation.
As mentioned in the BRFA, the source code will be released. In addition, Novem Linguae has kindly agreed to review the code prior to activation (and if Novem Linguae ends up being too busy, I'll ask someone else to review). While I understand the need for contingency plans on some critical bots, I'm concerned that requiring completed source code prior to approving projects would be a strong disincentive for future development.
Based on the above discussion and reviewing logs, exclusion using the {{bots}} template doesn't seem to be necessary or helpful, so that functionality has been left out. Also, if an administrator wishes to prevent restoration of a long-term protection, unprotecting the page before applying the new protection will be sufficient and is less hacky than some other approaches that I considered. Based on my experience handling requests on WP:RFPP, I expect that to be rare, though.
Finally, the bot is designed to handle both temporary and indefinite protections. Daniel Quinlan (talk) 09:08, 2 September 2024 (UTC)[reply]
Thank you. I look forward to seeing it in action. ~Anachronist (talk) 17:13, 2 September 2024 (UTC)[reply]
The source is located at protection-helper-bot . I'm still cleaning up the code, revising some of the method names, etc. so if anyone has feedback, I'd appreciate an email rather than pull requests or GitHub issues at this point. Thanks. Daniel Quinlan (talk) 21:40, 3 September 2024 (UTC)[reply]
I'm also on Discord if anyone has any questions that you would like to ask interactively. Daniel Quinlan (talk) 22:06, 3 September 2024 (UTC)[reply]
requiring completed source code prior to approving projects would be a strong disincentive for future development. The "completed" source code isn't being requested. You're free to change the source code any time, including after the approval – only major changes in functionality require a new supplementary BRFA. – SD0001 (talk) 17:25, 3 September 2024 (UTC)[reply]
I guess what's really bugging me about this is trying to understand why anybody would not want to release the code early. @Novem Linguae said a couple of days ago, let me get the bot working, then after that I'll take the extra time and effort to spin up git and a GitHub repo. To me, it's hard to imagine "git init" not being pretty close to the first thing I type when starting any new project. It's just good software engineering hygiene. And pushing it out to some storage that's more robust than my laptop's hard drive isn't far behind. RoySmith (talk) 18:26, 3 September 2024 (UTC)[reply]
The significant part is let me get the bot working, not setting up source control. It took me five minutes to create the repository and package the script. Requiring someone to invest a significant amount of time developing code prior to approving a project is the issue. This wasn't a ten line user script, it was a significant investment of my free time in the month since project was approved. Daniel Quinlan (talk) 21:19, 3 September 2024 (UTC)[reply]