Wikiversity talk:Bots/Archive 2

Update
This page seriously needs an update, as most bots on the list need to be deflagged since they don't work anymore/inactive. ---Atcovi (Talk - Contribs) 20:40, 1 January 2016 (UTC)


 * I've updated a few of the ones that have changed username to remove the redlinks. I've also started tagging the userpages with undefined. The policy lacks guidance on removing the bot flag for inactivity. I would propose we modify it with a two year inactivity time, which is the same as used at Admin activity review --mikeu talk 21:16, 1 January 2016 (UTC)
 * You can unflag my bot Crochet.david (discuss • contribs) 21:32, 1 January 2016 (UTC)


 * The bot is not yet near the proposed 2 year inactivity period. I do hope it will become active as the bot has made many useful contributions. Thanks you! --mikeu talk 02:54, 2 January 2016 (UTC)


 * But... shouldn't we allow bots to be deflagged by operator request? Crochet might not have any plans in the future to operate the bot ---Atcovi (Talk - Contribs) 03:51, 2 January 2016 (UTC)


 * Of course. But, a minor semantic subtly is that he said we "could" rather than "should." The bot won't hit the two year inactivity threshold for a few months. I'm hoping he changes his mind as the bot has made many useful contributions in the past. There is no urgency to act on this. (Fwiw, he commented in response to me pinging him in irc. He asked if we needed it to do anything for us.) There is more to this than just just flipping a bit to flag the bot. I want to make sure that the operator knows that we value his past contributions and would welcome future activity. That is more important than book keeping.. --mikeu talk 04:22, 2 January 2016 (UTC)
 * Alright, that works. ---Atcovi (Talk - Contribs) 14:48, 2 January 2016 (UTC)

Temporary Custodian flag for automated actions
(please continue discussion started at ) --mikeu talk 20:31, 20 January 2016 (UTC)

(if you find the technical details in the following paragraphs too confusing skip down to Wikiversity_talk:Bots for the short explanation.) --mikeu talk 18:57, 23 January 2016 (UTC)

Are there any other pressing bot tasks that might require the custodian flag? Unlike curator, the custodian right it one that I can grant but not remove. The process would be to discuss locally and grant if there is support. When the task is complete we would go to meta and explain that the right was granted for a limited scope/duration and request removal of the right (without prejudice.) We should use this process sparingly and do any needed tasks during a single run. --mikeu talk 13:20, 19 January 2016 (UTC)


 * I had forgotten that you can add but not remove. I can't think of anything else that requires custodian rights, because the only practical difference in roles is user management.  There isn't anything in the MediaWiki namespace I would want to update by bot, and the rest can all be handled by curator rights as far as I can see right now.


 * There is one other option. We could grant a temporary allowance for a bot to log in with a custodian's account.  I'm not sure whether the separation of user and bot or the avoidance of bots being custodians is a greater priority.  Or, we keep doing them manually, which isn't horrible.  -- Dave Braunschweig (discuss • contribs) 15:09, 19 January 2016 (UTC)


 * TL;DR = performing automated admin actions and requesting Steward removal of these admin rights complicates things.


 * Yeah, I can't even "resign" by removing my own bits w/o a Steward request.


 * I'm fine with a trusted Custodian operating a bot having Curator flag (even indefinitely) as long as there is community consensus for the edits and a process for deciding what gets bulk deleted. If we trust the person to have Custodian rights and we also trust them to operate a bot, there's really nothing new going on. Except, granting a bot a user right which also includes the ability to block (human) editors raises an eyebrow and should probably be done sparingly, even if there is not intent to use the right.


 * I would support using a Custodian non-bot account with a temporary bot flag. We just let it run overnight and remove when done, repeat if needed. Any edits done manually while the bot flag is present will be hidden in recent changes unless someone hits the show bots button. (Recent changes is patrolled by the cross-wiki anti-vandalism team, most of whom are not local to our project.) I've never tried to turn off the flag for just some edits by an account that has the bot flag.


 * It may not be horrible to do this manually, but it is a waste of time that two contributors are pushing a button 14,000+ times when they could be adding expertise to astronomy or IT learning resources.


 * I don't see this as a "big deal" - I just want to make sure that we do it transparently and with both the support of the local community and within the norms of wikimedia project governance. The changes that I proposed to the BOT policy are just a paper trail showing local community support for any Stewards wondering why we might ask to quickly remove a flag that we just granted yesterday. It would be more efficient if we had a local policy solution that doesn't require actions from off project. (They prefer such solutions as it reduces their workload.) This limited task obviously supports our mission and is for the "good of the project." But, granting/revoking flags for this purpose also sets a wiki precedent for future activity by our successors and will be interpreted as such by the Stewards. They require a link to a local policy page or a community review for any requested actions like user rights removal.


 * I'm going to transclude this section in the BOTS talk page to make it more widely available for comment. --mikeu talk 20:27, 20 January 2016 (UTC)


 * I think from a simplicity standpoint, I'd rather approach it by having community permission (or acceptance) to run the bot with a custodian account. I'm not even sure changing bits on the custodian is necessary.  There's already no rate limit on custodians.  I also know that anything more than 500 quick updates requires letting the stewards know.  I've had my IP locked out temporarily for that before, and that was with the bot bit.  This approach would eliminate extra work for the stewards and for us.  -- Dave Braunschweig (discuss • contribs) 20:40, 20 January 2016 (UTC)
 * Agreed, it would be much simpler to keep this local. Performing 14k of any kind of action will flood recent changes making it difficult to see concurrent vandalism. Our recent changes is watched by a number of non-local human contributors, but it is also monitored by bots looking for cross-wiki patterns. There's about 8 of them watching our irc RC channel (and perhaps hundreds of others) as we speak. The bot flag reduces the load on these automated global scans by signaling that they can safely be ignored. For non urgent tasks like this, I would recommend that automated edits be run nice by following the rate limits and throttling based on the Manual:Maxlag parameter when load is high. I'm not sure what the topology of our servers looks like today. I very much doubt that we are on a dedicated server. We used to be some kind of "VM" on a cluster that had many projects hosted on the same iron. Just because we can run without rate limits, doesn't mean it is a good idea. It could impact performance on other projects. I've seen my bot slow down for 10 or 20 seconds a number of times recently due to maxlag. I assume it was due to high load elsewhere in the wikiverse as there was so little activity here. I'm not suggesting that one bot running full out is a problem, just that if everyone follows the guidelines it gives server resources priority to human editors. Personally, I reserve the no rate limit editing for tasks like reverting vandalism; not for mundane edits. --mikeu talk 21:29, 20 January 2016 (UTC)


 * Sorry, I wasn't suggesting bypassing Maxlag. I don't think the user rate limit and Maxlag are the same value.  User rate limits should be hard-coded based on mw:Manual:$wgRateLimits.  Maxlag varies, somewhat considerably, based on time of day and activity level.  My bot is currently using Pywikibot, which has Maxlag functionality built in.  -- Dave Braunschweig (discuss • contribs) 22:43, 20 January 2016 (UTC)

The theory of giving bots Curator rights was good. The actual result, however, wasn't as effective as desired. For a curator to delete pages as a bot, the bot must authenticate on each deletion. Even with that, access is throttled so that only a few pages may be deleted at a time. There do not appear to be corresponding limits on Custodian / sysop accounts. If we want bots to be able to process page deletions, we need to either allow custodians to log in as bots, or give bots run by custodians the Custodian bit.

There is a difference between the two. Accounts tagged as bots will have the edits and deletions flagged as bot edits. Edits from human custodian accounts don't have the bot tag. This impacts viewing of the recent changes log.

If we believe having a bot do this work is appropriate, we will need to grant the bot Custodian / sysop rights. -- Dave Braunschweig (discuss • contribs) 15:15, 23 January 2016 (UTC)


 * A couple of random thoughts and questions:


 * Just checking, I take it you added  to the user-config.py per mw:Manual:Pywikibot/delete.py? (assuming that is the script that you are using, though I suspect it might apply to other API actions)
 * I'm curious, approximately what is the rate limit of the bot compared to a regular account? (not including auth time)
 * There is also a flood flag that can be applied to a regular (non-bot) account. mw:Manual:Bots So, that is another possibility to keep massive activity out of RC. I don't know much about that.
 * I can't figure out what a CSRF token is, but it looks important. mw:API:Delete


 * In principal I see no big deal about the Custodian right for a bot to bypass the ability to complete these tasks. I just want to know what is going on. Is the bot triggering a user right ratelimit, or hitting some internal mediawiki throttle that is inherent to the bot flag. The documentation is not (to me) clear. I could temporarily flag your main account now as a bot to test. I'm assuming that you could manualy edit (w/o RC b) while also running the bot with the b in RC. I'm in #en.wikiversity IRC if you want to chat. --mikeu talk 16:22, 23 January 2016 (UTC)


 * Yes, I added MaintenanceBot to user-config.py using sysopnames. Pywikibot won't perform a delete without it.  I'm not using delete.py, but calling site.deletepage directly from my own script.  The issue wasn't the delete rate limit, but an authentication rate limit.  It logged in too many times and then timed out for 300 seconds.  It seems to be a non-sysop limit rather than a bot limit.  The code runs fine as me, but not as MaintenanceBot.  Tagging me as a bot account would allow me to hide the edits with the bot flag.  But that leads us back to the separation of user accounts and bot accounts.  Would it be better to have a user that can run as a bot, or have a bot that is a custodian / sysop, or neither of the above and just do it manually?  -- Dave Braunschweig (discuss • contribs) 17:20, 23 January 2016 (UTC)


 * After some IRC discussion and additional testing, there is a clear difference between giving a custodian a bot flag and giving a bot the custodian flag. Any updates performed by a user with the bot flag are tagged as bot edits in the log.  So, they need to be separate accounts, with the bot given additional rights if that's what we want the bot to be able to do.  This led to the following change being made, pending community discussion and comments.  -- Dave Braunschweig (discuss • contribs) 18:52, 23 January 2016 (UTC)

Discussion and comments
Dave Braunschweig and I have been testing the various methods for automating bulk Curator and/or Custodian actions for uncontroversial tasks like the Open Proxy IP unblock and associated IP talk page deletions, orphan redirect deletion, etc. We've probably also confused many non-programmers with the long discussion above about user rights, authentication rate limits, and other technical details. The bottom line is that we've learned that a bot with Curator can not easily perform the tasks due to limitations in the mediawiki software. In order to automate these tedious maintenance tasks we need to flag the bot as a Custodian.

Dave has a long track record of productive contributions to our project and has demonstrated use of the tools in a way that the community obviously supports. I don't see it as a big deal to flag a Custodians bot with the same rights that can be performed manually with another account. I've flagged his bot as a "probationary custodian" (w/o the need for a mentor, of course) for one month as a trial. I'd like the community to comment on which Custodian tasks you are comfortable with a bot automatically performing, and which tasks should be left to manual Custodian action. Please note, this is not a vote; it is a request for comments. Think of it as a sign on the back of a truck that asks: "How's my driving?" --mikeu talk 18:43, 23 January 2016 (UTC)

Important: maintenance operation on September 1st
Read this message in another language

The Wikimedia Foundation will be testing its secondary data centre. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster. To make sure everything is working, the Wikimedia Technology department needs to do a planned test. This test will show if they can reliably switch from one data centre to the other. It requires many teams to prepare for the test and to be available to fix any unexpected problems.

They will switch all traffic to the secondary data centre on Tuesday, September 1st 2020.

Unfortunately, because of some limitations in MediaWiki, all editing must stop while the switch is made. We apologize for this disruption, and we are working to minimize it in the future.

You will be able to read, but not edit, all wikis for a short period of time.


 * You will not be able to edit for up to an hour on Tuesday, September 1st. The test will start at 14:00 UTC (15:00 BST, 16:00 CEST, 10:00 EDT, 19:30 IST, 07:00 PDT, 23:00 JST, and in New Zealand at 02:00 NZST on Wednesday September 2).
 * If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it.  If you see the error message, then please wait until everything is back to normal.  Then you should be able to save your edit.  But, we recommend that you make a copy of your changes first, just in case.

Other effects:


 * Background jobs will be slower and some may be dropped. Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.
 * There will be code freezes for the week of September 1st, 2020. Non-essential code deployments will not happen.

This project may be postponed if necessary. You can read the schedule at wikitech.wikimedia.org. Any changes will be announced in the schedule. There will be more notifications about this. Please share this information with your community. User:Trizek (WMF) (talk) 10:30, 31 August 2020 (UTC)

Important: maintenance operation on October 27
This is a reminder of a message already sent to your wiki.

On Tuesday, October 27 2020, all wikis will be in read-only mode for a short period of time.

You will not be able to edit for up to an hour on Tuesday, October 27. The test will start at 14:00 UTC (14:00 WET, 15:00 CET, 10:00 EDT, 19:30 IST, 07:00 PDT, 23:00 JST, and in New Zealand at 03:00 NZDT on Wednesday October 28).

Background jobs will be slower and some may be dropped. This may have an impact on some bots work.

Know more about this operation.

-- User:Trizek (WMF) (talk) 09:25, 26 October 2020 (UTC)