I'm writing a userscript that assists in closing XfD's: User:Evad37/XFDcloser. One of the feature requests is to have an option to unlink backlinks after a deletion result – similar to Twinkle's Unlink module (discussion). This could potentially result in a large number of pages being edited by the script (after showing the user a list of pages to be edited and asking for confirmation). Would I need to file a BRFA once the code is written? - Evad37 [talk] 04:29, 23 February 2017 (UTC)

BRFA are for accounts that are making the edits (normally bot flagged accounts) - do you plan on being the only person that will run this? Do you plan on using it for retroactive closures? — xaosflux ^Talk 00:46, 24 February 2017 (UTC)

do you plan on being the only person that will run this? No. This isn't for myself (except for testing in sandboxes/uspersapce), I'm just the coder trying to make it easier for other editors (mostly admins) to close XfD discussions – like how many editors use User:Mr.Z-man/closeAFD, but with more features and working in more XfD venues. Do you plan on using it for retroactive closures? No, the actions would occur just after the script makes the close. - Evad37 [talk] 01:50, 24 February 2017 (UTC)

@Evad37: programmers don't need to file BRFA's. If the users of the software will be using it in a high-speed, high-volume manner covered by Wikipedia:Bot_policy#Assisted_editing_guidelines they may need the BRFA's. If appropriate to the edit, you may want your script to make use of the minor edit flag. — xaosflux ^Talk 02:50, 24 February 2017 (UTC)

Okay, thanks for the advice - Evad37 [talk] 02:54, 24 February 2017 (UTC)

I've noticed that Xaosflux and Headbomb seem to think that AnomieBOT isn't archiving the approved, expired/withdrawn, and denied BRFAs fast enough. The current parameters the bot uses (per AnomieBOT 54) are:

• When moving a request to the "denied" or "expired/withdrawn" sections, it will adjust that list to contain the greater of 15 BRFAs or all BRFAs denied or expired/withdrawn in the past 7 days.
• When moving a request to WP:BRFAA, it will adjust the position of the <noinclude> such that transclusion will display the greater of 30 BRFAs or all BRFAs approved in the past 7 days. It will also archive any BRFAs after the <noinclude> older than 1 year.
• It will also update WP:BRFAAA when new archive subpages are found to exist. But I see Headbomb recently changed the format of that page, which the bot will eventually (2018-01-01 at the earliest) screw up if I don't update the code first.

Should these parameters be changed? Anomie⚔ 15:22, 25 February 2017 (UTC)

Can't speak for Xaosflux, but for me it wasn't really a matter of AnomieBot being "too slow", I just thought it was weird to have the archives listed as 1 Jan - 31 December, and have items from those dates unarchived. Personally, I'd be fine with 30 days on WP:BRFAA, then archived to WP:BRFAAA. Headbomb {talk / contribs / physics / books} 15:28, 25 February 2017 (UTC)

Hmm, have to think over this - I don' think we really need very old ones hanging out indefinitely just to meet the "greater of" rules. — xaosflux ^Talk 18:28, 25 February 2017 (UTC)

It's labeled "1 January – 31 December" simply because it's using a page per year, just without the pages being named by year. AnomieBOT literally chooses the archive for each approved BRFA as $y-2004. Anomie⚔ 14:37, 26 February 2017 (UTC)

I propose to add a Namespace(s): field to the BRFA form. This will help BAG and other reviewers to determine the scope of the bot, especially when ambiguous. This should also avoid potential issues of the kind "I thought I can run this in userspace". The namespaces are often implied by the task details, but I think it is best to avoid assumptions. In few BRFAs I have seen, BAG actually ask for the affected namespaces, even when relevant – this should help clarify this detail. As with other fields, this would be task-dependent and may have any number of values, like "talk pages", "portal", "all", "all except articles", "n/a", etc. —  HELLKNOWZ  ▎TALK 15:48, 18 February 2017 (UTC)

Sounds good, I ask sometimes. And also am more likely to start a trial quicker for non-articles impacting changes. — xaosflux ^Talk 18:04, 18 February 2017 (UTC)

I support this addition. Some bots that are just fine to operate in article space should not operate in Template space, for example, and it would be good to make this clear in the BRFA. – Jonesey95 (talk) 18:14, 18 February 2017 (UTC)

Support on the condition that existing bots be interpreted as all namespaces unless explicitly clarified otherwise. I don't want to see existing bots need to seek new approval for a task they've run for years, etc. ~ Rob₁₃^Talk 21:14, 18 February 2017 (UTC)

Completely agree with Rob on this one. Definitely needed in the BRFA process to understand the task - it will save the inevitable question. TheMagikCow (talk) 08:24, 20 February 2017 (UTC)

Personally, I have to wonder if making the form longer with this field is worth it, since it should already be in the function details. Anomie⚔ 02:08, 19 February 2017 (UTC)

It almost never is in practice and that just causes needless ambiguity. I would rather have a longer form than potentially a much longer process (who knows when and how an issue might appear). —  HELLKNOWZ  ▎TALK 15:50, 27 February 2017 (UTC)

Template	Old	New
{{BotTrial}}
{{BotExtendedTrial}}
{{BotTrialComplete}}
{{BotSpeedy}}
{{BotApproved}}
{{BotExpired}}
{{BotWithdrawn}}
{{BotDenied}}
{{BotRevoked}}
{{OperatorAssistanceNeeded}}
{{BAGAssistanceNeeded}}

The old templates pissed me off as making little sense and having bad design, so I took it upon myself to implement a better-looking scheme that makes more sense. The general idea is

1. Trial = Blue
2. Approved = Green
3. Withdrawn/Expired = Grey
4. Denied/Revoked = Red
5. Attention = Yellow

In the trials, a check mark is to indicate it's been approved for trial, and the + for an extended trial. The eye is to indicate that the trial edits now need review. Approved/Speedy Approved should be self-explanatory, as should the others.

Should we make {{BotTrialComplete}} blackframe/yellow background instead (like {{BAGAssistanceNeeded}}) so it catches the attention more? Headbomb {talk / contribs / physics / books} 23:46, 26 February 2017 (UTC)

Headbomb {talk / contribs / physics / books} 23:39, 26 February 2017 (UTC)

Also, a thanks to CheChe (talk · contribs) for doing some work on these icons. Headbomb {talk / contribs / physics / books} 23:44, 26 February 2017 (UTC)

They all look good to me. — xaosflux ^Talk 01:20, 27 February 2017 (UTC)

Can we change the trial to like yellow or orange or something (caution color)? The swapping of blue and green is going to be a bit confusing for me since I'm used to blue meaning approved. ~ Rob₁₃^Talk 01:42, 27 February 2017 (UTC)

I like these. I much prefer green to be approval and blue being "in process". I like that attention needed ones have better contrast now. Withdrawn isn't as critical and denied isn't as orange. Honestly, I like them all color-wise. I don't think trial complete really needs extra changes -- it's not like any of them were ever that confusing to begin with. My only issue is with the extended trial one. It extends (har har) the line height and I've always disliked that. But it's a minor bike shed concern. —  HELLKNOWZ  ▎TALK 13:23, 27 February 2017 (UTC)

Yeah I don't really like that either. Could be made horizontal I suppose. Headbomb {talk / contribs / physics / books} 15:55, 27 February 2017 (UTC)

What we'll need now is a bot/AWB run to cleanup "hardcoded" like this. Headbomb {talk / contribs / physics / books} 16:00, 27 February 2017 (UTC)

Really? The text should be clear as to what the archived decision is, I don't see why they need changing. — xaosflux ^Talk 16:39, 27 February 2017 (UTC)

I would say the only reason is if we wanted some sort of BRFA bot that can go through all of them gathering info and stats and whatnot for some some sort statistic or overview report, and the bot was getting confused by these. Otherwise, it seems more or less WP:NOTBROKEN as far as that applies to WP space. Even the category is already there. —  HELLKNOWZ  ▎TALK 16:42, 27 February 2017 (UTC)

It's not to switch the text to the template, it's to put the new images instead of the old ones and have one uniform system that is easily maintainable. Otherwise you have discrepancies, even in the same BRFA (the bottom instance was templated, thus used the new icon, but the one in the closing rationale whas hardcoded, and used the old icon). Headbomb {talk / contribs / physics / books} 17:41, 27 February 2017 (UTC)

I agree with Hellknowz here, there seems little reason to edit years of BRFAs just to change images. Anomie⚔ 01:39, 28 February 2017 (UTC)

Take a look at BRFA/WarddrBOT 2, or BRFA/TheJoshBot. Would you not find those a bit weird/confusing to use different icons for the same thing, or out of sync with the current icons (and in many case, fairly unclear/have really weird scheme)?

Sure it's "years of BRFAs" but it'd be a trivial thing to improve/fix with bots, and it would be a one time run to ensure the scheme is easily maintainable and retroactive. Headbomb {talk / contribs / physics / books} 02:04, 28 February 2017 (UTC)

And we should update {{Bot Top}} to not subst the templates. Headbomb {talk / contribs / physics / books} 02:07, 28 February 2017 (UTC)

Hi, everyone. After seeing the above discussion I've decided to be bold and rotate the extended trial icon. I'm hope I'm not stepping on any toes! I've got to go change the templates now. —♫CheChe♫ talk 15:34, 28 February 2017 (UTC)

Ok, I'm not the most confident with templates, but I think I've done it right. —♫CheChe♫ talk 15:44, 28 February 2017 (UTC)

Please add this {{BRFA|TrustMeImAIRobot||Open}} to the page TrustMeImAIRobot (talk) 15:19, 1 March 2017 (UTC)

Added. —  HELLKNOWZ  ▎TALK 15:29, 1 March 2017 (UTC)

Per User_talk:BU_Rob13#Bot_autoassess_error the bot causes errors and the bot owner is aware of them. Instead of topping his bot and fix the error. The allow to bot to run and then fix manually. (It reminds me of Yobot in some cases). I think the bot should stop and resume only when the error is fixed otherwise search for a different approach for this minor task. -- Magioladitis (talk) 11:37, 17 April 2017 (UTC)

This has been discussed in the past with BAG members. The "errors" are caused by things like "| class = sub" (a misspelling of stub). The duplicate parameters are a good thing, as they allow me (or other editors) to correct unambiguous errors that exist on the talk page. The final result is both a correct class and the removal of an incorrect class. Thank you for (a) not notifying me, and (b) not even linking to the bot approval that you're talking about. ~ Rob₁₃^Talk 14:58, 17 April 2017 (UTC)

Anytime. I know that you follow this page very closely. AWB provides a feature to update parameters instead of creating all this mess. -- Magioladitis (talk) 15:28, 17 April 2017 (UTC)

You are incorrect. It doesn't provide a feature to update parameters with suitable regex allowed to determine when to make the change when multiple templates on the same page have the same name for a parameter. Each "error" represents an edge case caused by an erroneous value of a template parameter which must be removed by a human editor; it draws attention to an existing mess so I can clean it up. ~ Rob₁₃^Talk 15:45, 17 April 2017 (UTC)

It provides if you use a custom module. We have a section called Helper functions. Yobot has similar scripts and doing it in a better way than your bot. -- Magioladitis (talk) 16:05, 17 April 2017 (UTC)

Anyway. My argument is since this is a low priority task we should discuss and find way to minimise the edge cases instead of creating more mess and require two and three runs per pages. Take note also that removing a duplicate parameters that in fac does not affect the visual output is "cosmetic". The same holds if the bot visits a page and adds a parameter that does not affect the page because there is anoher paramtere there. Please read WP:COSMETICBOT. -- Magioladitis (talk) 16:11, 17 April 2017 (UTC)

If you'd like to write a module to handle that, do be my guest. Saying "we have a feature for that" and then "go write a custom module in a coding language you do not know" are rather different things, though! You'll also need to explain exactly how such a module would handle a theoretically infinite number of invalid "class" parameters, some of which are intended to be importance parameters, some of which are intended to be actual class parameters and are the same as what the bot would apply, and some of which are intended to be actual class parameters and are not the same as what the bot would apply. I'm always open for better implementations, but it makes little sense to spend 10 hours coding when it would take 10 minutes manually fixing, especially when the manual fixing is going to achieve a better end result. Human attention on the few talk pages with invalid parameters is desirable, which is why this hasn't been changed in the past.

(edit conflict) Article assessment is not a low priority task. It has been requested by the WikiProjects being tagged with knowledge of how the implementation works. There are consensus discussions to back up each project's opt-in. My bot doesn't run more than once per page in any given run (of course, if new project templates are added that need assessment between runs, a second edit is possible). That is simply false, as-is the claim that my bot removes duplicate parameters (it does not). I do welcome discussion of any bot task on my talk page, and I'm always happy to improve if one can suggest a better implementation. ~ Rob₁₃^Talk 16:14, 17 April 2017 (UTC)

OK let's see if BAG is informed that the bot creates a percentage of errors and that in some cases it violated COSMETICBOT. Then we and we will handle it. No problem. -- Magioladitis (talk) 16:20, 17 April 2017 (UTC)

Provide a single edit which violated COSMETICBOT and I will be happy to fix it. These do not exist. As for BAG being aware, I know you were aware of this in the past because we discussed it on my talk page. You were a BAG member at the time. So yes, BAG was aware. ~ Rob₁₃^Talk 16:23, 17 April 2017 (UTC)

Magioladitis (talk · contribs), stop WP:REICHSTAGing in apparent retaliation for BU Rob's request concerning DexBot, and drop the WP:BATTLEGROUND mentality. If you have an issue with User:BU RoBOT, then I suggest you follow the directions outlined in WP:BOTISSUE, which I will quote here for both of you's convenience

"If you have noticed a problem with a bot, or have a complaint or suggestion to make, you should contact the bot operator directly via their user talk page (or via the bot account's talk page). Bot operators are expected to be responsive to the community's concerns and suggestions, but please assume good faith and don't panic. Bugs and mistakes happen, and we're all here to build an encyclopedia."

It should be fairly obvious which bold passage applies to whom. Headbomb {t · c · p · b} 16:32, 17 April 2017 (UTC)

Also, consider doing articles likely to have duplicated parameters because of the bot semi-automatically, rather than automatically, if possible. Headbomb {t · c · p · b} 16:35, 17 April 2017 (UTC)

In my next run, which will not be for several months, I will (a) fix the duplicate auto parameter issue, which I believe has become more prevalent over time due to the amount of people copying my bot's assessment templates when creating new article talk pages, and (b) see what I can do about duplicate class parameters without compromising quality of the final result. ~ Rob₁₃^Talk 16:38, 17 April 2017 (UTC)

Fair enough. I think it's obvious that Rob has two criteria though. The one that apply to other bots and the one that apply to his bot. I know that the problem with Rob's bot is not that big but it's good to handle at some point because the replies in his talk page were most of the direction that he is actually aware of the problem but his way to fix the problem is manually fixing the edges cases. It reminds me of something. -- Magioladitis (talk) 16:45, 17 April 2017 (UTC)

I did not make cosmetic-only edits. I did not make edits against consensus. I did not introduce errors into any pages that didn't already, themselves, contain errors. I did not know of a way to prevent an erroneous error my bot was causing and refuse to apply it. For the third time or so, if you have a proposed solution that I can implement and that actually works, I'm all ears. ~ Rob₁₃^Talk 16:56, 17 April 2017 (UTC)

Were was User:Ladsgroup pinged in the above discussion User talk:BU Rob13? Doc James (talk · contribs · email) 19:21, 17 April 2017 (UTC)

@Doc James: Here, after I attempted to discuss the issue with him multiple times in that same thread and gave him several months to respond to my concerns. ~ Rob₁₃^Talk 19:38, 17 April 2017 (UTC)

Excellent thanks Doc James (talk · contribs · email) 19:47, 17 April 2017 (UTC)

The point here is that BU RoBOT's minor edit required another editor to make a cosmetic edit to fix the issue that BU RoBOT introduced. Seems to me that M. has a valid point here. I don't see any misspelling, nor any unambiguous error; just a parameter that wasn't assigned a value. Don't edits of this nature to talk pages clog up the article-space watchlists, thus making it possibly harder to detect article-space vandalism? I'm not sure one can watch an article without simultaneously watching its talk as well. wbm1058 (talk) 20:18, 17 April 2017 (UTC)

Yes that is a major problem with bot edits. Many of us hide them on our watchlists. But than that hides everything that occurred before that bot edit which can then hide vandalism from a human editor. We seriously need the WMF to fix this. Doc James (talk · contribs · email) 22:30, 17 April 2017 (UTC)

@Doc James: I believe T11790/[1] is being reviewed for deployment in the next MediaWiki update. Headbomb {t · c · p · b} 22:40, 17 April 2017 (UTC)

@Wbm1058: Typically, I follow very shortly behind my bot and fix such double parameters. These affect a very small percentage of articles, so it takes me maybe 5 minutes after a run on ~10,000 pages. I made the simple mistake of forgetting to do that this time because I had travel scheduled the next day and got distracted with that. In any event, I've already stated above that I would work something out with that bug before the next run of the bot task (or I will not run it, and explain to the WikiProjects why I'm unable to implement their consensus). The term "cosmetic edit" is meaningless when it comes to non-automated edits. It is purely a construction of the bot policy (and the AWB rules of use). ~ Rob₁₃^Talk 22:36, 17 April 2017 (UTC)

@Headbomb, JJMC89, Legoktm, Jonesey95, Magioladitis, and Anomie: I think we're going around in circles with three-and-a-half BRFAs going on right now about exactly the same topics. All three (as near as I can tell) are using pretty much identical regex, and now it just seems like we're holding one discussion in three locations. So, I'm bringing us all together. I realize I'm not BAG, but here's what it looks like we need to get this ball rolling:

1. Full regex for converting ISBN and PMID from magic link to regex (including edge cases) and (if consensus allows) regex for converting doi.
2. Test runs on said regex
3. Splitting the massive "magic links" categories into groups so that PrimeBOT, Magic links bot, and Yobot can get the go-ahead.

Feel free to add points to this list if necessary, and feel free to ping anyone I missed. Primefac (talk) 03:01, 18 April 2017 (UTC)

Agreed. I modified the third bullet to clarify the scope of action. I strongly recommend that the regex that is used be the regex that the Mediawiki software uses to recognize and create magic links. That code is not foolproof, but it is what puts pages in the "magic links" categories in the first place, and it should be conservative enough to avoid false positives. Once we have done all of the pages in the magic links categories, we can troll around and look for other patterns that should/could be converted.

I think we should leave DOI and other identifiers out of this round of fixes. Keep it simple. – Jonesey95 (talk) 04:33, 18 April 2017 (UTC)

DOI and PMC should be definitely be included, and other identifier fixes should be incorporated as they are tested and developed. It is highly undesirable to have the same article be edited multiple times for the same type of thing. These bots should covering the most highly used identifiers from the get go.

Mediawiki regex should not be used for ISBNs, we want to catch bad ISBNs and other ISBN errors. The template will put those in categories, flagging issues that were silently ignored before. Headbomb {t · c · p · b} 11:02, 18 April 2017 (UTC)

Isn't there a CHECKWIKI for malformed ISBNs? Also, I think it would be easier to find malformed ISBNs after we do this fix, because we could search for any ISBN that isn't immediately preceded by {{. Primefac (talk) 11:37, 18 April 2017 (UTC)

There is a checkwiki for that yes. Checking for malformed ISBNs after is always a possibility I suppose, but I don't really such much benefit. After the run, people will keep adding bare ISBNs, and those will need conversions too. The absence of a {{ won't be a guarantee the ISBN is malformed, and it will only take a few days before valid untemplated isbns take over bad untemplated ones. The advantage templating bad ISBNs is that the ISBN error will be visible to everyone, and can be fixed much more quickly rather than only listed at WP:CHECKWIKI. Headbomb {t · c · p · b} 12:14, 18 April 2017 (UTC)

I think we're at a "6 and two 3s" point with regard to how best to fix the extant broken ISBNs. Either way it will mean going through a second pass to fix broken links. I guess from a regex perspective we know the MediaWiki code works. So maybe we should use that plus an "everything else" regex for the bad stuff? Primefac (talk) 12:23, 18 April 2017 (UTC)

There is little point in trying to catch "bad ISBNs" with a bot. There are only about 800 ISBNs in the Checkwiki report, and the vast majority of them are inside URL links. The links need to be processed manually. The remaining population should be processed manually or as a supervised run, because they are broken in many different ways. – Jonesey95 (talk) 13:04, 18 April 2017 (UTC)

I agree with what Jonesey95 said. DOI is entirely unrelated here. It's not a magic link. Legoktm (talk) 17:53, 18 April 2017 (UTC)

Whether DOIs is a magic link or not is besides the point. The point is that DOIs should be linked, and this is a good fix to bundle in these bots. Headbomb {t · c · p · b} 17:56, 18 April 2017 (UTC)

It's entirely relevant. The RfC explicitly says those kinds of things that should be linked but are not currently are not included. Legoktm (talk) 19:47, 18 April 2017 (UTC)

No one objected to do those (save Rich, who also opposed doing ISBNs which are being done) to doing DOIs and other identifiers this way, neither in that RFC, or the follow up specifically on this question, or at the ongoing Wikipedia:Bots/Requests_for_approval/CitationCleanerBot_2. There is no argument from anyone that doi:10.1234/whatever is somehow desired over doi:10.1234/whatever. Headbomb {t · c · p · b} 19:51, 18 April 2017 (UTC)

Headbomb: You're making the perfect the enemy of the good here. Adding DOIs to this bot task adds an additional level of complexity and the opportunity for false positive edits. Do you have a regex in mind? (See step 1 above.) If you want to move forward with DOIs, bring us some ideas for step 1 instead of only arguing (hint: Module:Citation/CS1/Identifiers has a regex that works well in citations). – Jonesey95 (talk) 20:49, 18 April 2017 (UTC)

It's by far not perfect, we're talking adding 1 thing (DOIs), not all identifiers (at least not while developement is going on for the other ones). Perfect would be preventing this from going on while barely used identifiers like {{OSTI}} are covered. CS1 has no regex to catch DOIs, but the general regex would be something like

(\[\[digital object identifier\|doi\]\]|doi)(:|\s*)(10.<foobar>|\[http(s)?:\/\/(dx\.)?doi\.org\/<foobar> <foobar>\]). The tricky bit is what <foobar> should be exactly. Likely something like ([^(\]|\s*|,)]+?) since that would indicate the end of the doi match, but the finale "\.\s" is also allowed, and I'm not sure how to regex that. Also not sure on if +? is the right one for this match. However, that wouldn't take very long to develop and save several thousand edits from being made. The benefits are worth it.

Headbomb {t · c · p · b} 21:33, 18 April 2017 (UTC)

Has this discussion stalled yet? Can we just approve the bots already for PMID and ISBN? (cc: Legoktm) --MZMcBride (talk) 19:01, 23 April 2017 (UTC)

That's the thing, doing DOIs with those will save several several thousand edits. Headbomb {t · c · p · b} 19:09, 23 April 2017 (UTC)

Lack of consensus around DOIs (and lack of a proposed regex for DOIs) is preventing us from moving forward with ISBNs and PMIDs. Let's do the thing that has consensus. – Jonesey95 (talk) 23:25, 23 April 2017 (UTC)

Fully agree with Jonesey. From what I've read, we've got one camp that things we shouldn't do DOIs but should do ISBNs and PMIDs and another camp that wants them all done together. We need to avoid the situation where "do nothing" wins out even though no-one likes it. ~ Rob₁₃^Talk 06:00, 24 April 2017 (UTC)

From what I can tell, all objections are purely procedural in nature. "This wasn't in the RFC". No, it wasn't. But that doesn't mean it shouldn't be done. Headbomb {t · c · p · b} 10:35, 24 April 2017 (UTC)

Given that a bot owner was taken to ArbCom for going outside of standard procedure, I can understand the importance to some editors to strictly follow the rules. However, I also know that situation was rather exceptional, and maybe in this instance it's better to ask forgiveness than permission? In case you can't tell, I'm neutral as far as actually doing it.

Maybe a quick yes/no !vote among those gathered here would settle the issue. Primefac (talk) 12:07, 24 April 2017 (UTC)

The arbcom case wasn't about because some things were done "out-of-process", but rather because of WP:IDIDNTHEARTHAT. There was a follow up to the RFC with no objections, and people expressed support at Wikipedia:Bots/Requests_for_approval/CitationCleanerBot_2, and there's yet to be any objection to the idea that doi and other identifiers should be linked.

So the question is should "magic link" bots clean up other identifiers when they have the opportunity to do so, or not. Or do we want separate bots that will edit several pages multiple times.Headbomb {t · c · p · b} 13:10, 24 April 2017 (UTC)

The objections are not just procedural in nature. See step 1 at the very top of this discussion: we do not yet have a good regex for templating DOIs. Nobody has brought one forward and said "I have tested this in my main account" or "I followed the link that Jonesey95 provided and used that regex and found that it doesn't work" or anything like that.

Given that basic lack of ambition, and the fact that we have three editors ready to go with ISBNs and PMIDs (using the regex that WP uses to generate magic links), and a well-defined category of ISBN and PMID magic links, I think we should table the DOI idea and move forward with ISBNs and PMIDs. – Jonesey95 (talk) 13:33, 24 April 2017 (UTC)

Or simply develop that regex? \[?\[?(digital object identifier\|doi|doi)\]?\]?(:|\s)+10\.\d+\/<foobar> is a good starter. "Ends with \s, , or \.\s" should be the end. I just don't know how to regex that, because [^(\s|,|\.\s)]+ doesn't work. But that's a regex that shouldn't take long to develop and test. As for a "lack of ambition", I'm still waiting on Wikipedia:Bots/Requests_for_approval/CitationCleanerBot_2. Headbomb {t · c · p · b} 14:54, 24 April 2017 (UTC)

I agree with the others here and elsewhere that including DOI among these magic link fixes is out of scope. We can have a separate discussion about DOI, gain consensus for changing it, and then make the edits as part of other bot requests. In this case, we're focused on PMID and ISBN (RFC should be done manually). In my opinion, we should unblock/un-stall these magic link deprecations by approving the tested bots, such as Wikipedia:Bots/Requests for approval/PrimeBOT 13. Maxim, MaxSem, Addshore, JamesR, et al.: can one of you please take a look at these open bot requests and approve if everything looks okay? --MZMcBride (talk) 01:39, 27 April 2017 (UTC)

While it may be desirable to convert multiple links at once, it is not necessary to prevent an operator from making one improving edit (assuming task approval) unless they also make another non-dependant edit. — xaosflux ^Talk 12:12, 1 May 2017 (UTC)

At Wikipedia:Bots/Requests for approval/PrimeBOT 15 a request was made for the bot to "Change syntax usage of {{Episode list/sublist}} to allow for greater compatibility". This was approved and AlexTheWhovian has modified Module:Episode list with this edit. When asked Will the trial break pages if the module edit hasn't been made yet? If so, we should do a trial in userspace., AlexTheWhovian responded It will not break any pages, no. What will happen is that summaries from the transcluded tables will appear in the articles that the tables are being transcluded to (nothing serious, just out of the ordinary); implementing the module edits will then restore this to hiding the summaries. Test cases exist in the module's sandbox, the module's testcases and my sandbox.[3] This response understates the problem of "reversing" the way that transclusion happens (i.e. normally episode summaries appear in the season articles but not in the "List of episodes" pages. Alex modified the module after the test, but before the bot had run on all articles and, as a result, all episode summaries have disappeared from season articles and appeared in the "List of episodes" pages. This has created confusion,[4] and resulted in editors changing articles in the belief that doing so will fix the problem.[5] I have no idea how many articles were changed in the 18 hours between when Alex modified the module and when I reverted his change, but this disruption to the articles is unnaceptable. It could result in many articles containing errors even after the bot runs, especially if someone has deleted the code that the bot needs to change. If the bot can complete the changes almost instantly, it won't be a problem, but if the bot takes some time to change all 12,376 transclusions, we may be looking at significant article breakage. --AussieLegend (✉) 18:25, 10 May 2017 (UTC)

Not sure where the 12k is coming from (transclusion count shows just under 4k) but even if it is 12k, it should only take about six hours. Once I'm back at my home machine (in a little under an hour) I'll be running the bot. Primefac (talk) 18:37, 10 May 2017 (UTC) pinging AussieLegend, since that's a good way to get someone's attention. Primefac (talk) 18:38, 10 May 2017 (UTC)

See Wikipedia talk:WikiProject Television#Episode list sublist template. wbm1058 (talk) 18:50, 10 May 2017 (UTC)

(ec)Module:Episode list's transclusion count shows 12,376. I was looking at that. I think the issue was that Alex modified the module far too early. If the bot will take 6 hours, the module should be changed after the bot run, not before it although, even with that time there is a distinct possibility of article breakage. --AussieLegend (✉) 18:53, 10 May 2017 (UTC)

Unless I'm seriously misreading the module, only the /sublist entries are the ones being affected. Am I misreading that? Primefac (talk) 18:56, 10 May 2017 (UTC)

Aren't we guaranteed to have article breakage during this ~6 hour window? The article pages and the module need to be in sync. You change one without changing the other at the same time, and functionality is broken. If this is a tolerable solution, you should put some sort of "under construction" template on top of all the effected pages so that others are not confused and don't try experimenting with ad hoc fixes. – wbm1058 (talk) 19:05, 10 May 2017 (UTC)

Only the articles using /sublist need changing, but there is a carry-on effect to all articles to which they are being transcluded. Wbm1058 has identified a serious break. List of The Simpsons episodes (seasons 1–20) is now breaking the post-expand include size because season articles transcluded to it have been converted. As a result, the episode tables for seasons 14-20 and everything after that are not being displayed. --AussieLegend (✉) 19:09, 10 May 2017 (UTC)

By the way, is the GIANT display of the FL star in List of The Simpsons episodes (seasons 1–20) related to this change? Or is it just me?— TAnthony^Talk 19:31, 10 May 2017 (UTC)

Yep. The giant star is a side effect of this change. You see that whenever this page enters Category:Pages where template include size is exceeded. Been there, seen that. It's been a bear to keep that page out of that category. wbm1058 (talk) 19:41, 10 May 2017 (UTC)

Right, then, it's only 3500 articles, which will be done in less than two hours. I'll be starting shortly. Primefac (talk) 19:35, 10 May 2017 (UTC)

1750 edits per hour, or 29 edits per minute, or 2 seconds per edit... if operations doesn't slow you down. That's faster than the "normal" AWB editing rate. wbm1058 (talk) 19:53, 10 May 2017 (UTC)

Your math is backwards, it's 1 edit every 2 seconds. But yes, about 30epm. Given the relative disruption caused by this change, I don't think anyone is going to care much if I'm a little over the recommended 20epm. Primefac (talk) 19:55, 10 May 2017 (UTC) too fast... Primefac (talk) 19:57, 10 May 2017 (UTC)

Module has been updated, and all of the pages I've checked (including the various Simpsons pages) seem to be working. Still have a few hundred pages to edit but they'll get done faster than the backend would purge the pages anyway. I do honestly apologize for the disruption caused, but I'm glad it could be resolved in relatively short order. Primefac (talk) 20:50, 10 May 2017 (UTC)

After-action report: for what it's worth, I checked through all of the bot's edits: 3511 changes, none reverted. Assuming that the articles transcluding said 3511 pages haven't been broken by confused editors, everything should be working fine. Primefac (talk) 21:28, 10 May 2017 (UTC)

Brilliant work, thank you! That's another job to tick off the list. This entirely post was clearly unnecessary through the impatience of editors. As was stated: Aren't we guaranteed to have article breakage during this ~6 hour window? You change one without changing the other at the same time, and functionality is broken. -- Alex^TW 22:41, 10 May 2017 (UTC)

On a side note, the editor wanting to make the bot edits then update the module, this would have had a greater effect, as more pages would have been affected straight away without the required edits being made to the module, requiring all of those articles to be purged first... Rather than edit the module, which wouldn't implement in every page instantly due to the cache, then the bot running through with its edits, and that would produce instantly working articles. Really, though. Think it through. -- Alex^TW 22:46, 10 May 2017 (UTC)

@AlexTheWhovian: Please don't overlook the obvious solution to this, which I explained at Wikipedia talk:WikiProject Television#Episode list sublist template: implement the new syntax in Template:Episode list/sub-list, run the bot to change everything to use that, then when done, deprecate the old template and just redirect Template:Episode list/sublist to Template:Episode list/sub-list. You prioritized your own convenience over that of others, and wasted several others' time by making them investigate this, which I had no prior knowledge of, to track down and understand what was going on. You misled the BAG member who approved this. Water under the bridge now, but please promise to do it the right way next time. Right, I admit I'm a little impatient. This BRFA was filed on April 8 and has now run to completion. Meanwhile, my BRFA completed its first trial on March 23 and has been waiting ever since then for a response from the BAG. Your task completely leapfrogged mine. So sorry, I may have taken out a little of my frustration with that on Primefac. wbm1058 (talk) 23:02, 10 May 2017 (UTC)

Indeed. All water under the bridge now. However, all editors know that we do not simply copy content from one page to another due to the attribution to editor's contributions in the history, and changing the template name for a simple edit is, I maintain, overkill. Your suggestion has, however, been noted for future refetence. I also rebuke your accusation that I mislead the bot owner; the details of the edit were clearly listed in the BRFA, module edits and all - I recommended that you read it and note my statement to be true. Now, I recommended that you take your personal issues with how this page (bot requests) to another location, and not take it out on other editors. Cheers. -- Alex^TW 23:17, 10 May 2017 (UTC)

What a lame excuse that is. You can simply give attribution in an edit summary and on a talk page, see WP:CWW. The edit history is retained for reference when you redirect the old name to the new name. This sort of thing is done all the time in article space, per WP:Merging. wbm1058 (talk) 23:25, 10 May 2017 (UTC)

I duly noted your suggestion for future use, if I need it, and you give me "what a lame excuse" in return. Cheers for the civility. As I stated: it would be unnecessary overkill. The issue is solved. Everything is working. This report was unnecessary, submitted by a user who opposes a great deal of my updates. Take your personal issues at your personal project not being completed elsewhere. Ta-ta. -- Alex^TW 02:10, 11 May 2017 (UTC)

This report was entirely necessary because it quite clearly confused editors, resulted in inappropriate edits and broke thousands of articles, one extremely severely. As I said at WT:TV, if you can't accept that, maybe you should hand in your TE permission. I oppose some of your updates (not a great deal - that's an overstatement) because I have programmed professionally and have seen you rush in and do things just because you can. You don't take a structured approach and miss things - this issue was an example. Thankfully, Primefac was able to dive in and get this fixed quickly, which may or may not have happened had this report not been made. (I don't know what he was planning) You really need to accept what has been said by more than one editor and not brush things off. --AussieLegend (✉) 03:43, 11 May 2017 (UTC)

• Noted and accepted somewhat. However, you still don't seem to get that doing it in the reverse order would have caused more disruption. Making the bot edits then updating the module, pages would have been affected straight away by the bot without the required edits being made to the module, requiring every modified article to be purged after the module edits were made to implement those edits. Instead, the module edits were done first, which did not implement in every page instantly due to the site's cache, then the bot ran through with its edits, and those particular edits instantly produced working articles. I do freely admit, I should have added a note to the template that would have been transcluded to every usage of it, stating that it was being modified and not to make such changes. There was always going to be a level of disruption. I went with the one that caused less. -- Alex^TW 03:50, 11 May 2017 (UTC)

Doing it in the reverse order would have only resulted in the 150 test articles being wrong. Doing it as wbm1058 suggested would have been a much better method. Your method resulted in disruption to nearly 3,400 articles for 18-20 hours. Your argument that the module changes were not implemented in every article instantly is misleading. At least one editor complained at WT:TV 6 hours after the module was changed and 13 hours before the article was updated. A short disruption after the bot run would have been preferable to the much longer disruption prior to the bot run. --AussieLegend (✉) 04:15, 11 May 2017 (UTC)

I'm not seeing how that'd work. Implement the bot edits to every article, means every article is affected. The make the module edits. No article is updated due to the cache. All articles therefore faulty and need to be purged. I noted the alternate suggestion for future reference, and I do note that the module should have been updated closer to the bot edits, but I was not aware that the bot would take as long as it did to start doing the replacements; it still would have produced less disruption. -- Alex^TW 04:22, 11 May 2017 (UTC)

The idea is to change the module just before the bot run, not 20 hours prior to it. If either of the methods proposed by wbm1058 or I (use a modified transition template and the unmodified original) then both the modified and unmodified articles would always be using the correct template ensuring no articles, including List of The Simpsons episodes (seasons 1–20) and List of Casualty episodes*, were severely broken. --AussieLegend (✉) 04:42, 11 May 2017 (UTC)

So, better time coordination between editors for next time. Noted. -- Alex^TW 04:56, 11 May 2017 (UTC)

• For what it's worth, I rescheduled my plans for the evening in order to sort this out quickly, so I appreciate the thread (and completely understand the tone used). Clearly the process could have happened more smoothly, but it could have gone much worse. I've got a new list of things to consider before future bot runs, and I'm sure everyone else has realized a thing or two. Just as a formatting note, I added a bullet point above to show where I split this reply off from the original thread. Primefac (talk) 12:29, 11 May 2017 (UTC)

I appreciate that, Primefac. Alex should buy you a . wbm1058 (talk) 15:54, 11 May 2017 (UTC)

Re Wikipedia:Bots/Requests for approval/JJMC89 bot 12; see this bot edit, which is understandable but leaves the FUR statement in a nonsensical state. Suggest leaving the link text unchanged and piping to the non-redirect link, rather than just changing the link. Mike Christie (talk - contribs - library) 12:00, 23 May 2017 (UTC)