Wikipedia:Bots/Requests for approval/TFA Protector Bot
- 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.
Operator: Legoktm (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)
Time filed: 17:06, Thursday May 9, 2013 (UTC)
Automatic, Supervised, or Manual: Automatic
Programming language(s): Python
Source code available: here (incomplete)
Function overview: Move protects articles that are scheduled to appear on the main page as the TFA per current custom
Links to relevant discussions (where appropriate): Wikipedia:Bot_requests/Archive_54#Anyone_got_an_adminbot_looking_for_work.3F
Edit period(s): Daily, will run 5 minutes before midnight
Estimated number of pages affected: 1/day
Exclusion compliant (Yes/No): No
Already has a bot flag (Yes/No): No, will need bot+sysop
Function details:
- Gets the TFA for the next day with Template:TFA title.
- Checks the protection level:
- If move=autoconfirmed: protect w/ move=sysop expiry=when off main page
- If move=sysop: Check if expiry is long enough, if not: re-protect w/ move=sysop expiry=when off main page
- If not move protected: Protect w/ move=sysop expiry=when off main page
I decided it was pointless to re-instate any move=autoconfirmed protection since non-autoconfirmed users can't move pages.
Discussion
[edit]@Bencherlite: Legoktm (talk) 17:06, 9 May 2013 (UTC)[reply]
- As a TFA delegate, I think this is an excellent idea, not least because I suggested it! Move protection is generally put in place for the day of a featured article's appearance on the main page, because it prevents vandalism such as this taking place. However, it's quite easy for me to forget to do it at all, or set it to expire at the start of the day rather than at the end of the day. It would be very helpful to have an adminbot to do this limited task (and it would make my life, and that of current/future TFA delegates, slightly easier as a result). BencherliteTalk 18:40, 9 May 2013 (UTC)[reply]
- I am hopeless at botcode but I can spot typos in edit summaries: "Upcomping"? I have also mentioned this BRFA at WT:TFAR since that's where
all the kool kids hang outpeople with an interest in TFAs tend to hang out. BencherliteTalk 19:00, 9 May 2013 (UTC)[reply]- Oops, fixed. Thanks! Legoktm (talk) 19:10, 9 May 2013 (UTC)[reply]
- Agree that this is a great idea. It's logical and sensible and there's no real downside here so long as it operates properly. Thanks for the help, — Cirt (talk) 19:27, 9 May 2013 (UTC)[reply]
- If we're having a bot do this, is it also worth having the bot fully protect all templates used in TFA? It's been less of a problem recently, but we used to get quite a bit of that sort of vandalism (e.g. penis appears floating on TFA, but editing that page will not remove it and someone has to check all unprotected/semi-protected transcluded templates). WJBscribe (talk) 22:34, 9 May 2013 (UTC)[reply]
- Alternatively, WP:FAP could be revived, cascade protected and the bot could transclude all the templates from TFA onto that page, instead of protecting each template. WJBscribe (talk) 22:51, 9 May 2013 (UTC)[reply]
- That sounds like a better idea to me. I think that we should stick to just move protection for this task, and look into using WP:FAP in another BRFA. Legoktm (talk) 04:21, 13 May 2013 (UTC)[reply]
- Alternatively, WP:FAP could be revived, cascade protected and the bot could transclude all the templates from TFA onto that page, instead of protecting each template. WJBscribe (talk) 22:51, 9 May 2013 (UTC)[reply]
- I'm hopeless at python, and I still am not used to legoktm being highlighted blue now. but I don't see any issues with this bot.—cyberpower ChatOnline 03:17, 10 May 2013 (UTC)[reply]
I reviewed the code, and I have the following comments/questions:
- What will the bot do should the TFA title subtemplate not exist or contain the empty string for a particular day? I guess either pywikipedia will throw an exception at line 71 or you'll run into an undefined variable access at some point.
- I see the bot is supposed to run at 5 minutes before midnight. If this is somehow delayed, it looks like the bot will skip today and go protect tomorrow's FA instead.
- What happens if the listed FA title happens to be a redirect? Will it move-protect the page or the redirect? For that matter, what makes sense for it to do there? Off the top of my head, it seems that move-protecting the page and both move- and edit-protecting the redirect would make the most sense.
- I note the query you are performing will set the protections to just move protection, removing any other protection (e.g. edit protection). This is obviously not right. While T48911 exists, no one has worked on it yet.
- I wonder if the bot should try to restore the old move semi-protection after the page is off the main page.
Item #4 is a blocking problem. HTH. Anomie⚔ 12:32, 13 May 2013 (UTC)[reply]
- Good bot idea. Needs some tweeks before implementing. Can it run half an hour before, so editors can notice if it has not, can it have an automatic kill switch if it is delayed? If it protects next day due to failed run, probably an annoyance, easily fixed, not crisis. -166.137.209.143 (talk) 13:56, 15 May 2013 (UTC)[reply]
- I would rather, in fact, that it added move protection to articles at the next time it runs after the articles have been selected, rather than waiting until 5 minutes before the article hits the main page. This means there's plenty of time to see whether the bot has missed something and also stops any move wars taking place between selection and TFA day. (Admittedly I'm not aware of any naming issues in the 6 months that I've been selecting TFAs, but you never know...) BencherliteTalk 15:35, 15 May 2013 (UTC)[reply]
- Yes, it seems it would be useful to have time to catch an omission. I do not see any obvious harm in doing it early, moves at the last minute on a TFA seem unlikely. -166.137.209.148 (talk) 17:39, 15 May 2013 (UTC)[reply]
- I would rather, in fact, that it added move protection to articles at the next time it runs after the articles have been selected, rather than waiting until 5 minutes before the article hits the main page. This means there's plenty of time to see whether the bot has missed something and also stops any move wars taking place between selection and TFA day. (Admittedly I'm not aware of any naming issues in the 6 months that I've been selecting TFAs, but you never know...) BencherliteTalk 15:35, 15 May 2013 (UTC)[reply]
{{OperatorAssistanceNeeded|D}}
Any updates? MBisanz talk 05:51, 30 May 2013 (UTC)[reply]
Ok so I've changed the workflow so that the bot will try and protect all existing TFAs that have been scheduled until it hits a non-scheduled day. I was thinking have it run around noon, and then maybe have another script run around 18:00 and drop a note on WP:AN if the page isn't protected yet. Re Anomie:
- Now the bot will just stop if the subpage doesn't exist or an empty string.
- I suggested changing the run time to around noon (anytime really would work since it should protect a few days in advance)
- That sounds like a good idea, I'll code that in.
- Fixed.
- Since non-autoconfirmed users can't move pages anyways, it seems pointless imo.
Legoktm (talk) 06:22, 5 June 2013 (UTC)[reply]
- Replies:
- Maybe I just don't know Python or pywikipedia well enough, but now it looks like it will protect the Template:TFA title subpage itself?
- Ok
- Seems not done yet, can't review. ;)
- While it should be good for now, since the TFA is unlikely to have upload protection (or LQT "newthread" or "reply" protection) and create protection doesn't apply to pages that already exist which leaves only 'edit', I'd personally rather see it just blindly preserve all non-move protection types. Also, you should probably ignore any protection entries that have a "source" set just in case the article somehow gets transcluded onto a cascade-protected page, and preserve the cascading flag in case the article is itself cascade protected.
- Hrm. Ok.
- Anomie⚔ 10:47, 5 June 2013 (UTC)[reply]
- 1. Seems I had this fixed locally, just never pushed to github.
- 3. Implemented. Though, the bot should probably re-instate edit semiprotection if it existed on the redirect...
- 4. Done as well. It seems some pages (noticed it on the main page) have "aft" protection, so will be useful. Any protection entry with the 'source' key is just ignored, and anything with 'cascade' will cause &cascade=1 to be set.
- Legoktm (talk) 08:11, 26 June 2013 (UTC)[reply]
- Ok, new review (of this version):
- It looks like do_page() will reach the end of the function without returning any specific value if the page is not a redirect and should_we_protect() returns a falsey value. That would prematurely terminate the loop in main().
- You're using p_status rather than real_p_status when calling should_we_protect() on the redirect target.
- Err... You're passing the date instead of p_status when calling protect() in the non-redirect case?
- Your loop in prot_status should be where protections with 'source' set are ignored. As it is, a direct protection may be overwritten with a 'source' protection if the page is protected both directly and by cascading.
- Does the + operator instead of .append() on lines 70-71 do the right thing?
- As mentioned, it would be good to re-set an overridden edit semi-protection on the redirect after the TFA protection expires.
- Something good for preliminary testing would be to comment out lines 72-74 (the actual submission of the action=protect query) and instead just print params, to make sure the rest of the bot runs correctly (I do this sort of thing with pretty much every change I make to any of AnomieBOT's tasks). Good also would be to somehow feed in test pages to make sure all the code paths in do_page and its sub-functions are hit. Anomie⚔ 12:07, 26 June 2013 (UTC)[reply]
- Ok, new review (of this version):
A long time ago east used to run a bot under his main account to do this (as you can see he didn't even bother to hide it), it'll be nice to get an approved bot doing this.
@Legoktm any progress on #3 and 4? Apart from those I'm happy to approve the bot for a trial. --Chris 13:02, 24 June 2013 (UTC)[reply]
- Responded above. Legoktm (talk) 08:11, 26 June 2013 (UTC)[reply]
- Ooh, this new (to me me at least :P) notification feature is cool. I uploaded the source code for my old bot here, maybe you can crib some ideas like IRC notifications or move vandalism done shortly before the protection cronjob. I know for sure that questions #3 and #4 are accounted for in my bot, I learned those mistakes the hard way. Be aware that my code is uncommented, messy (and that's being charitable), and was built on top of a fork of a now five year old version of pywikipedia. Good luck with your bot. — east718 | talk | 15:29, 24 June 2013 (UTC)[reply]
- Thanks! If the bot protects as soon as the page is selected, it should reduce the chance of page-move vandalism, but a separate IRC bot notifying that it was recently moved is a good idea. I'll try and write a bot to do that soon. Legoktm (talk) 08:11, 26 June 2013 (UTC)[reply]
{{OperatorAssistanceNeeded|D}}
Is this still an active bot request or has this gone stale? Hasteur (talk) 18:58, 31 July 2013 (UTC)[reply]
- I haven't had time to work on it lately, but I'll try and get it done during Wikimania. Legoktm (talk) 03:42, 1 August 2013 (UTC)[reply]
{{OperatorAssistanceNeeded}} Poking again. Wikimania has come and gone. Active/Stale? Hasteur (talk) 23:41, 19 September 2013 (UTC)[reply]
The dropdown list of protection reasons now includes "Forthcoming TFA" which might help - what I've been doing recently is adding a wikilink to the TFA blurb for that date/article in the "other/additional reason" field, which might be a useful habit for the bot to copy. BencherliteTalk 10:30, 15 October 2013 (UTC)[reply]
{{OperatorAssistanceNeeded|D}}
So, here we are six months on. Done yet? Josh Parris 11:21, 5 November 2013 (UTC)[reply]- I did a dry run and everything worked fine. Could I get a trial to run on my main account? Legoktm (talk) 05:06, 10 November 2013 (UTC)[reply]
Trial
[edit] Approved for trial (5 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Naturally, report mishaps. Complain if trial parameters are unsuitable. Josh Parris 06:48, 10 November 2013 (UTC)[reply]
- Thanks. Bencherlite, when you queue up the next set of TFA's could you not protect them and ping me so I can run the script? Legoktm (talk) 18:36, 13 November 2013 (UTC)[reply]
- I note that according to Special:Log/TFA_Protector_Bot nothing has happened in the past week. What's the cause? Josh Parris 22:37, 20 November 2013 (UTC)[reply]
- The bot doesn't have admin powers (yet) so I'm not surprised that log is empty - I assume that Legoktm will be protecting the couple of TFAs I've scheduled in the last couple of days by running the script through his own account before he seeks +bot+sysop for the bot. BencherliteTalk 22:44, 20 November 2013 (UTC)[reply]
- I note that according to Special:Log/TFA_Protector_Bot nothing has happened in the past week. What's the cause? Josh Parris 22:37, 20 November 2013 (UTC)[reply]
Trial complete....or close enough. Operation Crossroads and Ambohimanga were protected. Some things I noticed and had to accommodate for:
- Template:TFA title/ subpages are created by AnomieBOT II and may not exist even if the TFA has been scheduled. The bot now falls back upon WP:TFA/ subpages and uses the same regexes as AnomieBOT to determine the page title.
- If a TFA is missing, the bot will look at least 35 days in the future from today before stopping.
Legoktm (talk) 17:58, 21 November 2013 (UTC)[reply]
A trusted operator, with a useful and uncontroversial task. Approved. Seriously. Josh Parris 20:56, 21 November 2013 (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.