Wikipedia:Bots/Requests for approval/MusikBot


 * 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 Symbol keep vote.svg Approved

MusikBot
Operator:

Time filed: 06:23, Wednesday, April 22, 2015 (UTC)

Automatic, Supervised, or Manual: Automatic

Programming language(s): Ruby

Source code available: GitHub

Function overview: Bot clerking at WP:PERM pages.

Links to relevant discussions (where appropriate): Special:PermaLink/655854110

Edit period(s): Continuous

Estimated number of pages affected: Up to six during one run (one for each PERM page, except Confirmed and AWB requests)

Exclusion compliant (Yes/No): No

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

Function details: This bot works very much like does at WP:RPP. It monitors all the Request for Permissions pages for new requests, and checks if there were previously declined requests for that user and permission. If matches are found, an automated comment is left linking to those declined requests. Eventually it may also ping the declining admin, but I've side stepped that for now. There are two exceptions: The AWB checkpage which does not have the same structure as the other request for permissions pages, though I might implement special case handling for this at some point. The other is requests for confirmed, where it's very unlikely we'll see multiple requests by the same user, so the bot clerking is not that helpful there. A few notes: Thank you! &mdash; MusikAnimal  talk  06:23, 22 April 2015 (UTC)
 * It works by using regex to parse out all the necessary info, and constructs the automated comment(s) to be saved. As long as Template:Request for permission generates a level 4 heading and Template:Rfplinks is used than it shouldn't flake out.
 * Thoroughly tested on test-wiki, see testwiki:Wikipedia:Requests for permissions/Rollback (and here).
 * Operates on wmflabs, with a crontab running the script every 10 minutes or so, or whatever we decide on.
 * The perm clerking task can be turned off by changing User:MusikBot/PermClerk/Run to anything other than true.
 * For all six permission pages, it should take less than a minute to complete, with a 2 second pause between processing each page, and it will edit no more than 6 times total. However given the nature of the task you probably won't see but a few edits every day at most.
 * Checks for edit conflicts. If one is detected it will re-attempt to process that permission page for a total of three times, waiting progressively longer each time. So after attempt #1 it will wait 1 second before trying again, after attempt #2 two seconds, etc.
 * Caching is in place where appropriate, such as fetching the declined pages and any declined permalinks for a user.
 * There is verbose logging that I can make publicly accessible.
 * Full exception error handling. If a critical error is encountered (e.g. more than 3 failed attempts to edit a page), the script will proceed to process the next permission page rather than abort the task altogether. Fatal errors such as when the API is down will result in a full abort of the task until it is ran again by the cron job.
 * To be clear, the "cron" jobs are actually submitted to the grid, which helps allocate resources so the bot doesn't get in the way of other jobs on tool labs.

Discussion
BAG assistance needed


 * Looks sane; has support from the target audience; reasonable logic; trusted user. The thing I was actually going to ask about (i.e., pointless edits on already-handled entries) looks like it's already covered: if section.match(//i) -- slakr \ talk / 07:27, 29 April 2015 (UTC)
 * Thank you! It is now running, processing the PERM pages once every 10 minutes. 50 edits could take a while, but I'm no hurry. In the meantime allow me to note that I am implementing another clerking feature, where it will remove extraneous headers (e.g. see bottom request at testwiki:Wikipedia:Requests for permissions/Rollback). This happens a fair amount from new users, who do not read the instructions stating not put anything in the heading field. This development is happening completely on my local environment and will not interfere with the currently running bot, which is running off of code on tool labs. &mdash; MusikAnimal  talk  16:14, 29 April 2015 (UTC)
 * Just letting you know I've updated the bot to remove extraneous headers when present. This requires no additional edits should there also be previously declined requests for a user – the bot will simply make all changes to the page at once. Thanks &mdash; MusikAnimal  talk  15:35, 30 April 2015 (UTC)
 * This message is however totally misplaced, see this edit. It's also incorrectly indented. Armbrust The Homunculus 05:34, 1 May 2015 (UTC)
 * The bot acted exactly as programmed, only removing the level 2 header. The rest of the text was left as is. Here the user also ignored the  parameter of rfp and instead wrote the request body on the line below it. I am working on a more intelligent regex solution that can fix this common scenario in full. The incorrectly added level 2 heading is more common, however, so the bot is at least addressing that. Anyway, there's clearly discussion needed so I've disabled that feature for now. Let's talk more at WT:PERM so others can chime in. &mdash;  MusikAnimal  talk  06:03, 1 May 2015 (UTC)

With the updated regex please. Thanks, Magioladitis (talk) 11:42, 8 May 2015 (UTC)
 * Thank you for the endorsement. Just to be sure, has MusikBot been approved for a total 100 edits? The new regex is now in place and working nicely. An important note: I will be on holiday starting this Friday though the rest of the month. I am programming the bot to automatically shut off when it reaches 50 edits, or 100, as advised. I will still be able to occasionally check its activity for accuracy and act accordingly. Thanks &mdash; MusikAnimal  talk  16:41, 11 May 2015 (UTC)
 * please make 50 additional edits. -- Magioladitis (talk) 21:01, 13 May 2015 (UTC)
 * Thank you, will do &mdash; MusikAnimal  talk  21:03, 13 May 2015 (UTC)

Is the bot trial done? -- Magioladitis (talk) 23:17, 27 May 2015 (UTC)
 * No, and far from it, actually. I was going to bring a few ideas to your attention... There is now consensus (multiple supports, no opposition) for MusikBot to take on a new task for which it is already capable of doing. That is, comment on requests for permissions where the candidate does not meet some configured requirements. Please see User:MusikBot/PermClerk/Prerequisites for more information. If this task is approved for trial, it could be coupled in with the current allotted 100 edits and we'd be able to meet that threshold quicker. Together those 100 edits should provide ample data to evaluate the bot's overall performance for all of its tasks. What do you think?Finally, I believe MusikBot may be destined to take over 's task of archiving requests. This is both because of the operators inactivity and that MusikBot is already parsing the same pages. This has not been developed yet, however, and whether it should be a separate BRFA altogether is up to you. At the rate we're going, I'll have the archiving functionality ready for trial before the bot has made 100 edits. &mdash; MusikAnimal  talk  20:56, 28 May 2015 (UTC)
 * Assuming there will continue to be frequent malformed requests made at requests for confirmed, I believe a mere 50 edits will be able to show the bot is capable and proficient at it's current tasks. The one task, "FetchDeclined" as I call it, has been on point since the first edit. The other currently enabled task, "Autoformat" has undergone a few transformations. That is simply because one cannot predict how users will construct their requests, but I believe the logic is at a point where it can handle most scenarios and do so correctly. This edit on testwiki demonstrates the bot's ability to handle a wide range of scenarios. That being said, my proposal is to terminate the trial at 50 edits, and if all is well, start a new 50-edit trial for MusikBot's archiving functionality. If allowed, I'd like to also include the aforementioned "Prerequisites" task, which is ready to go. Let me know what you think! &mdash; MusikAnimal  talk  15:17, 5 June 2015 (UTC)
 * This seems fine. I dunno about auto-rejecting (something someone mentioned in the discussion), as that tends to put bots in the express lane for accidental warring, frustration, and general WP:BITE complaints, but simple, informational notices that don't explicitly reject the user should be fine, and I think it's probably fine to roll them into this one without having to worry about an additional task. Not sure as far as the archiving portion goes; I dunno about the status of KingpinBot or if it's actually truly necessary to replace it (or if that functionality would even be ready to test), so I'd probably recommend submitting a separate task once those details are clearer. -- slakr \ talk / 03:37, 10 June 2015 (UTC)
 * Thank you! Prerequisites just comments with relevant data, Autorespond only marks requests already done when the user already has the permission, never declines. The archiving task is rather low-priority, for now anyway. The issue is the operator is becoming less active and sometimes we end up having to manually archive. Since MusikBot is already parsing and looping through the same pages, it shouldn't be terribly difficult to have it takeover archiving as well, which is why I've proposed it. The operator is in support and we are working together on this. It's still in development, though, and I'll start up a new BFRA when it comes time.Also thank you for showing me how to deactivate the template :) Cheers &mdash; MusikAnimal  talk  16:18, 10 June 2015 (UTC)

Alright! The bot has finally completed the 100-edit trail. I will go through each task and provide relevant diffs so that you can judge the bot's efficacy.


 * FetchDeclined
 * This is the task that inspired the bot. When a request is made, the bot checks the archives and comments if the user has had a request declined in the past 90 days. This is fairly straightforward and has been spot-on accurate since day one:


 * Autoformat
 * Adding requests using the preloaded template isn't exactly user-friendly, so the bot attempts to fix common mistakes. Since it was impossible to predict what mistakes users would make, I had to continually refine the logic to handle the scenarios I observed. It is somewhat complex so I'm just going to provide a few diffs exemplifying how the bot handled various scenarios:  To be transparent, the bot didn't always do the right thing, but rest assured I quickly deployed bug fixes. Since around mid-June the autoformat task has been in a stable state and is able to repair most malformed requests, and ignores them when it can't figure out what to do. See on testwiki how the bot correctly handled a wealth scenarios in a single edit:


 * Prerequisites
 * This tasks checks predefined qualifications for a given permission, and comments with relevant data if the user does not meet them. Sometimes the edit counters go down, but the bot uses it's own API calls so it will continue to work. It also updates the prerequisite data every 90 minutes, as necessary, until the request has been responded to. Examples: (rollback) (AWB, 2 requests) (updating prereq data)

You'll also notice the improvement of the edit summaries over time. The bot now leaves a detailed summary of what tasks where performed, and how many requests were effected. Some examples of multiples tasks performed in the same edit: ,

Let me know if you need a more thorough explanation of any of the tasks and the logic behind them. Thank you! &mdash; MusikAnimal  talk  05:27, 6 July 2015 (UTC)
 * BAGAssistanceNeeded &mdash; MusikAnimal  talk  03:16, 13 July 2015 (UTC)

I read over the discussion, reviewed the edits, and everything looks good. —  Earwig   talk 05:37, 13 July 2015 (UTC)
 * 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.