Wikipedia talk:Bots/Requests for approval/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Archive 6

Archive 7

→

Archive 10

Review of a Betacommand task

Per my comments at Wikipedia:Administrators' noticeboard/Betacommand#How_can_a_BCbot_task_be_rescinded.3F, I want to ask BAG what their procedure is for reviewing a bots' approval for a particular task.

I am interested in two aspects of the approval, which may be considered together or separately:

1. a technical review by BAG itself of a task's authorisation (as is done when an application is made for authorisation of a task),
2. a review of the community consensus for a task.

In the interests of clarity, I want to make clear that I have raised the operation of BAG as one of the issues to be considered in my statement on the RFAR on Betacommand. Arbcom members have expressed the hope that community can resolve these issues without the need for an arbcom case, so I want to see whether and how BAG can consider the issues which I want to raise.

So, please can BAG tell me what procedure I should follow for each of these points ... or alternatively, whether BAG has no process for re-examining a bot's authorisation.

I believe that the answer will be relevant to the question of whether arbcom accepts a case on these matters. However, I am asking not as hypothetical test, but out of genuine concern for a review of a particular task. --BrownHairedGirl (talk) • (contribs) 02:03, 15 March 2008 (UTC)

Like I have said before, yet you seem not to listen to. Post a request here and there will be a discussion. β^_command 03:51, 15 March 2008 (UTC)

BC, I would have hoped that you would have recused yourself from a matter relating to your own bot. I want to know whether BAG members other than the bot-owner are prepared to review one the bot's tasks. --BrownHairedGirl (talk) • (contribs) 05:23, 15 March 2008 (UTC)

I already offered a suggestion on the page you specified (which, was apparently ignored). I'm not sure, why Betacommand's not allowed to suggest, basically the same thing? He may well be involved, and, I would expect him not to decide the outcome of the discussion. However, he was just trying to help you here, to point you towards the right place to start the discussion you seek.

So, yeah, I'd say calmly and rationally, start a discussion here. I'd suggest using facts, a good amount of links, and, generally make it easy to follow, for us (Most of us don't follow all 39,194 places this discussion is going on at). As I said at the other place, I wouldn't have a problem with a 'reverse BRFA', either, however, I haven't heard from any of my colleagues on that idea. One thing, however -- please be patient with us. Not everyone notices right away, that discussion is going on here. However, if something serious like you are suggesting comes up, I can leave messages with the various members, to alert them to it. Thanks, SQL^{Query me!} 05:43, 15 March 2008 (UTC)

There is no written out procedure. We really don't do this kind of thing very often. If you've got a problem, and can get a BAG member or two to endorse your complaints, I would not be adverse to an ORGANIZED review of the issues. However, this page is backlogged, and none of us is interested in wading though megabytes worth of mostly useless content, and I don't believe that a simple poll would be sufficient to gauge the actual merits and technical issues. --uǝʌǝsʎʇɹnoɟʇs(st47) 23:21, 17 March 2008 (UTC)

A proposal - more community input

A perennial problem facing the BRFA process as a whole is a lack of input from the community during a BRFA. Such participation is often impossible to solicit in the course of the BRFA, and we only see complaints after the bot has been approved. These complaints often go straight to ANI and do result in bots being blocked and cement the view held by many that the whole BRFA process is totally ineffective. To make things worse, after a bot has been approved there is no set process to re-examine that approval or to change it.

The only real way to resolve these issues is to get more community input in the course of a BRFA. Links cross-posted to community noticeboards often serve no purpose other than to annoy, and we still see no real increase in participation in a BRFA. Indeed, the only time that members of the community care about a bot's approval status is when it does something they don't like and, invariably, this time falls after the bot is fully approved (and thus the flamewars start). We do assign short trials as a matter of course in BRFAs, however my feeling is that a 50 edit, or even a 2 day trial, only offers us a gauge of the technical merits of a bot (ie that it doesn't cause the wiki to die whenever it runs), and doesn't "touch" enough members of the community at large to give them the opportunity to complain.

My proposed solution to this is an extension of the BRFA process. Following a short trial to assess the technical merits of a bot, the bot is placed into a probationary period of around 1 month in length. During this time, the bot's edit summary for every edit should contain notice that it is in an "extended trial" and a link directly to the BRFA. The BRFA will remain linked from the main request listing page for the duration of this trial, and will remain open to community participation for the full period of the trial. If, at the end of the extended trial, any issues raised by the community have been addressed, the bot is approved. The same "probation" requirement would apply for new task BRFAs.

My feeling is that although approval wouldn't be granted, bots could be given (temporary) flags for the duration of the extended trial if their edits are likely to clog up recent changes too much. Exemptions to the rule are something that should be discussed - my feeling is that there should be none, just to ensure that any potential issues are spotted and addressed (because, believe it or not, even interwiki bots can go wrong!).

The second issue I raised above is that of re-examination of approvals. The proposal is that any BAG member who feels that there is a valid reason to request it can place a bot back into a probationary period, and have the obligatory notice put into its edit summary. This should only be done on discussion here and, if BAG can't come to a consensus, the crats can, as is the established method, make the decision for us. A bot put into probation would, as earlier, have its BRFA request linked from the main BRFA page, and would be unarchived so not to hinder participation.

I hope that we can discuss and agree upon the above. I must credit WJBscribe for helping to formulate these suggestions, and apologies for my use of the first person making the whole idea look like my own -- I think I perhaps got carried away ;). No doubt others will have ideas for how to improve things, and these should be welcomed. Thanks, Martinp23 18:52, 16 March 2008 (UTC)

I strongly support Martin's suggestions- that may not be especially surprising as I helped him develop them. There is in my opinion, a perceived gulf between BAG and the wider Wikipedia community at present - and frustration caused by unclear processes as to the review of disputed bot functions. That has I think been one of the factors that has lead to ArbCom deciding to accept the BetacommandBot case - ideally many of those matters could have been investigated and resolved by the Bot Approvals Group. These proposals seem like a good way to channel community input into the BRFA process and to have a clear mechanism - through probation - to make it clear that BAG's oversight of bot operations goes beyond simply giving them the technical nod. WjBscribe 18:58, 16 March 2008 (UTC)

I definitely support idea of a bot approval being re-examined via a 'probationary period'. I don't think it is necessary for the approval of every bot though. How would non-BAGers request a bot approval to be re examined? -- maelgwn - talk 22:17, 16 March 2008 (UTC)

I'd think along the lines of it being requested here and actioned if not a frivolous request. Martinp23 23:27, 16 March 2008 (UTC)

On the matter of "every bot?" - I think my feeling is that we should err on the side of requiring it unless absolutely unnecessary. Speedy approvals should only be issued very rarely, and I think they're the only case that the extended trial should be dropped. Can you think of any other examples? Martinp23 18:42, 17 March 2008 (UTC)

The idea of re-examination of bots sounds good to me. One alternative is to approve bots only temporary, say for six months, after which a re-approval may be given. In the case of no serious issues with the bot, and no objections, re-approval can be given straight away. Problem bots can then be thoroughly re-evaluated and discussed. This would also mandate a proper overview of which bots/bot tasks that are approved and running at a given period of time. Oceanh (talk) 02:00, 17 March 2008 (UTC).

My only fear with that is a rather large administration overhead - we'd need people checking which bot needs reapproving today, and still need the community input, which is sadly lacking. The proposal above is basically giving users (via a BAG member) the opportunity to get a bot discussion reopened if they feel consensus has changed -- so it's close to your idea on an "as-needed" basis. Martinp23 18:39, 17 March 2008 (UTC)

Good idea, Martin :) Sounds workable to me, and addresses re-evaluating bots when required.... SQL^{Query me!} 02:30, 17 March 2008 (UTC)

And that "when required" caveat mustn't hinge on technical reasons, but should instead hinge on whether valid non-technical concerns have been addressed. We will know what this means when it happens. Carcharoth (talk) 14:16, 17 March 2008 (UTC)

One of the points to note is that it only takes one BAG member to agree there is a problem that needs to be looked into further for a bot to be on probation - and being on probation doesn't affect the bot's daily running. This short prevent frivolous complaints disrupting things, but the one BAG member is a reasonably low threshold. At the moment it seems BAG needs to form a consensus that a task should cease, the proposal is intended to have a structured review process with a lesser hurdle to kick it off. WjBscribe 16:22, 17 March 2008 (UTC)

Yes - if indeed the bot is working fine and the probationary period's outcome is that it should continue as normal, then nothing has been lost. The only time that the bot-op must take is to add the link to the BRFA to the edit summary of the bot. As WJBscribe says, this would kick start the process... I can say from experience that trying to get BAG members together to form a consensus is like herding cats. Martinp23 18:35, 17 March 2008 (UTC)

I'm not going to bother with all the threaded discussion just yet, but here are my comments:

Both proposals seem reasonable, though I question the drama-causing potential of a retrial on demand. Perhaps the retrial could require some sort of discussion or (dare I say it) vote before occuring? Also, I'd prefer to see a means by which experienced operators can just be given the green light after a cursory review and minimal hassle. --uǝʌǝsʎʇɹnoɟʇs(st47) 23:18, 17 March 2008 (UTC)

I wholeheartedly approve of this proposal. It increases the authority of BAG, increases community awareness of which bots are new, and doesn't really add much bureaucracy. How hard is it to check that a link appears in an edit summary? Just go the bot's contributions, set it to 500 and scroll down looking for a "(in trial)" note. If the small additional overhead is too much for BAG, there are plenty of bot operators willing to join. I think this proposal should be supported by a review of the approval process for BAG membership, but that's another story.

I think that under this system, "speedy approval" should be a shortcut only to the "in trial" status. If a task is similar enough to another to warrant speedy approval, the only issues are likely to be technical, which an "in trial" status run should catch easily. If a task is controversial but has been previously approved, then that approval should be linked from the current approval discussion. Remembering that consensus can change, there's no reason to exclude discussion on a topic just because it's been discussed before.

I do not approve of automatically-required reconfirmation; if a bot is operating consistently effectively and uncontroversially, why do we need to keep checking that? Six-monthly reconfirmations for Sinebot or MiszaBot would be pointless bureaucracy. However, I think that a reconfirmation-on-demand process would be very effective. It again upholds the authority of BAG, reminding bot operators that they are answerable to BAG and the community not only during the approval process, but whenever they are running their bot. I think that reconfirmations should be ordered by BAG at the request of the community, and that (unlike the messy WP:AOR process) the policy and procedure for bot reconfirmations should be centrally ordained. Happy‑melon 10:07, 18 March 2008 (UTC)

Moar creep?

Okay, you may have addressed the issue called "not enough community input" but at the same time you walk further down the slope called "bureaucracy". I'm very interested how you'd address this issue. Your proposal is adding an extra process overhead to (possibly) each BRfA (not to mention the extra work with making edit summaries compliant). This may ease the BAG-community front, but possibly unleash more of said frustration but between BAG and the bot operators? It's been to date said that there is more process than it's worth - now there's potentially even more of it (please fill out form 33499XJ-alpha in three copies, along with attachments DD7-Q4X/34b and 7FG-3R/174v, plus one copy of evaluation form V5H44SF-56673/AAAQ-3e for each edit done by the bot, unless someone with trust level QS-54/4Z or higher files a protest BQ56L-55e in which case we invoke discussion protocol TY11-WP/3a). Faced with that I don't think I'm willing to change my status quo (read: develop and run bots on my own and pretend the BAG doesn't exist) on this matter. Mind you, I'm not pointing out a better way (not sure yet how exactly I'd envision it) but rather pointing out that your solution is far from perfect as well, so don't get overexcited over it. Миша13 21:38, 17 March 2008 (UTC)

Valid point. My thoughts run that these extended BRFAs would just be linked from the main page - not transcluded, and wouldn't necessarily need any form filing or input unless a problem was noticed and the point raised... in which case it's surely worth it. Martinp23 21:46, 17 March 2008 (UTC)

Okay, Martin, your idea certainly has merit but it definitely does not completely solve the problem. The question to be resolved should be framed as "How do we avoid bot complaints made at AN/I?" not as "How do we avoid bots being blocked?" The core of the issue is the former, not the latter, from what I am reading. It should be Administrators who collectively decide that the AN/I is not the place to complain about bot behavior. It was a few years ago that the Wikipedia:Bot page was the place to complain about a bot's behavior, and not AN/I. Certainly, a user should have the right to list that a bot's behavior is gone awry on AN/I, but the result for an Administrator should not be to block the bot right away. As the Wikipedia is built on a community of discussion and active consensus, in the same spirit, those Administrators who wish to be involved should move the discussion from AN/I to a subpage of Wikipedia:Bots for a review discussion on an approved bot. Adding the "additional" trial period is meaningless, in my opinion, because you will always have someone complaining about some thing or another -- you aren't going to make everyone happy unfortunately. The purpose of the technical review is to assert that the bot is harmless and is useful. Primarily the former than the latter. The reason why the period was given a "if no one objected" kind of setup is because, admittedly, the lack of involvement of monitoring bots on the Wikipedia by editors. Administrators do not have all the time in the world to monitor every aspect of the Wikipedia, unfortunately. Not giving bots the bot flag after the technical review will affect those on RC patrol. It is my feeling that the current bot policy should remain standing as is.

It is my feeling that the solution should be:

Person Alice complains about Bot Bob on AN/I. Administrator Carol sees the complaint about Bot Bot, summarizes the complaint, and moves the complaint off the AN/I board to a subpage here. Active members of the technical bot review committee along with the bot owner should be notified that the bot's actions have been disagreed by Alice. Whether the bot's actions should be halted or blocked should be subject to consideration and review by Carol if Carol understands whether the complaint holds any merit and whether Carol can immediately answer 'yes' to the question: "Is the bot harmful?" If Carol views Alice's complaint to be of a highly technical nature, or of one Carol is unable to immediately answer the question of whether the bot is being harmful or not, then the bot should be subjected to an immediate re-review process. Should a member of the technical bot review committee deem that the bot is being harmful, then the bot should be blocked until a decision is made of the re-review process. Should the bot owner believe that his/her bot was blocked in error, they should also have the right to call for a re-review process involving the member who had a complaint in the first place.

The review & re-review process primarily needs to answer the two core questions that have been essentially part of the bot policy:

Is the bot harmless? Is the bot useful?

It is likely that a complaint is made to either one of those questions.

In any case, the section that has Dealing with issues should be reorganized. It should stress that issues should be discussed with the bot owner and only when the bot owner is unwilling to cooperate is when the complaint should be made at AN/I. On the same level, a bot owner needs to reasonably understand that a complaint about their bot should be taken seriously, and should make all attempts to involve someone from the approvals group.

The matter, ultimately, should be resolved not by more policy, but through the standards of practice that has been the core principles of the Wikipedia. The dispute regarding a bot should be between the person making the complaint and the bot owner first. Both parties need to recognize when the matter is beyond their scope to include a member of the approvals group, then Administrator(s). --AllyUnion (talk) 05:57, 18 March 2008 (UTC)

The problems arise when a bot operator either carries on operating the bot in the face of valid complaints, or fails to respond to valid complaints. At that point, a block may be needed to stop the bot. The ideal result short of blocking is that the bot operator stops the bot and discusses the issues. Admins are perfectly capable of judging whether a non-technical issue is a good reason to stop a bot, just as BAG members are best place to judge on technical grounds. What is not acceptable is to keep the bot running while discussion is still taking place. That may just result in the bot operator having to revert all the edits anyway, so is pointless, and, given the impact thousands of bot edits can have, can be very disruptive. The recent case of BetacommandBot and the redlinked categories is a case in point. Betacommand was told by several people that these actions were not helpful - he disagreed and carried on anyway. It was this that got the bot blocked (I'm referring to Ryan's block). In general, I support any changes that prompt bot operators to be more responsive to concerns from editors, not less. Even after approval and trial, bugs or unforeseen problems may be raised. Bot operators should always be patient and prepared to wait a little bit longer, and improve the bot run a little bit more before going ahead. Also, edit summaries can be very poor. I've been looking at some files of BetacommandBot's edit summaries, and there are some that are not informative enough. I will be comparing BCBot and BHGBot at some point to demonstrate how widely bot operating practices differ. Carcharoth (talk) 09:32, 18 March 2008 (UTC)

That, unfortunately, and I can't say to be certain, Betacommand perhaps dismissed those people's comments on the grounds he didn't believe them or that they weren't his intellectual equals. I think he dismissed those people's comments because he believed they weren't valid. The problem that I wish to avoid is that I don't want Betacommand's actions to be the edge case defining bot policy. Nor do I wish to ignore that the problems arising from Betacommand's actions. It should be noted that the bot policy has been revised several times since the last time I saw it... and I thought that the main goal and concept was when there was a problem, bot operators should take upon themselves as outstanding Wikipedia members to stop their bot, and listen to other Wikipedia's valid concerns. --AllyUnion (talk) 03:18, 21 March 2008 (UTC)

A really good idea, but but but ...

I warmly welcome Martin's proposal, as a genuinely helpful attempt to find a better way to resolve some of the problems which have arisen with bots, and hopefully to identify potential problems before they cause actual difficulties. However, while I know that Martin really is sincere in trying to defuse the conflict which has lately surrounded some bots, and I think this is a really good start, I'm not sure that it goes quite far enough … so I want to offer some suggestions to build on Martin's proposal.

The first point is that while notices to community noticeboards may not elicit a response, they should still be required as part of a BRFA request. They should not be verbose, and could probably be kept to one or two template-generated lines, something like

"Approval is being sought for a bot to perform a task which may be related to this page/project. For more details, see Wikipedia:Bots/Requests for approval/FixSomeThingsBot, where your comments are welcome."

Yes, some people may find them irritating, but as long as they are not splattered everywhere, then I hope that the irritated people will be outnumbered by those who welcome the opportunity to comment, even if they choose not to use that opportunity. When I sought approval for BHGbot, I posted a notice at WT:IE, and was pleased to find a number of useful points being raised.

Sometimes the points raised will just be misunderstandings, but having the discussion to clarify things in advance is helpful to everyone, and may help to identify ways in which a useful task may be misunderstood. But even if nobody responds, I think that a "your comments are welcome" notice would have a really important confidence-building effect. It would be a clear signal that both BAG and the bot owner understand that a bot is not just a tool owned by one editor, but a device whose use may have a wide impact on the work of many editors.

Martin's suggestion of initial approval being followed by a probationary period seems to me to be a great idea, because it recognises that many editors may not appreciate the significance of a bit until they encounter it in action. If they then find that the file is still open and that comments are still welcome, we have a very good chance of resolving issues without the heat-and-fury which is generated when people feel that they have no way of making their voice heard.

I have a small technical concern here: the "extended trial" link in the edit summary is a great idea, but space is often at a premium in edit summaries, and this may grab too much of that space, squeezing out other info on the nature of the edits. (One example of this is CFD work: "moving Category:X to Category:Y per CFD link" can require a lot of characters if the category names are long). So it might be better in practice to leave it out of the edit summary, but to require a prominent "bot-on-extended-trial, please discuss at this link" notice at the top of the bot's user page and talk page.

As to what happens when there are complaints about a bot, I'm not quite so sure about that process. I don't have a better idea upfront, but I am very unhappy about relying on a BAG member to put a bot on probation, because, sadly, at the moment I have little confidence in BAG :(

My conclusion from the BRFA for the NFCC bot is that BAG is simply broken. The BRFA was shut down while discussion was underway and the concerns I raised have been cited at arbcom as evidence that I was of "engaged in disruption". Hmmm. If politely raising a concern in a discussion is "disruption", then I'm a banana.

I can understand and accept that we all make mistakes and that people can learn from episodes of conflict. If the BAG members involved in that BRFA were able to say that they can see that shutting down discussion was counterproductive because it simply shifted the debate elsewhere and raised the temperature, then we coukd all move on and concentrate on the solutions. However, sadly, so far as I am aware only Martin has done so. If BAG members not only reject community input but subsequently label objectors as disruptive, then I simply cannot trust BAG to have a decision-making role in a bot-review process.

I think the crucial underlying principle here is that a bot should not be WP:BOLD, and that bot-owners need to remember that a) they do need consensus for their bots tasks, and b) that consensus can change. I know that Martin genuinely does want to open up the bot-approval process, and to find more effective ways of building and sustaining that consensus, but the sticking point here is BAG itself. If BAG continues to include both the most controversial and uncivil bot operator and someone who not only curtails discussion but labels community input as "disruption", then why should the community have any confidence that BAG can successfully operate an improved process?

I'm sorry folks, but while improved procedures are a necessary step, they are not a sufficient step; we also need to know that the people who operate those improved procedures really do want to work with the community. So far so far I see one BAG member (Martinp23) proactively working hard to do just that, another (Cobi) who commendably reopened a closed discussion, two who seem to reject all discussion, and apparent silence from the rest.

That split in approach broke the community's confidence in the existing approval procedure, and so long as it persists I cannot have confidence that it will be any more effective in maintaining community confidence in any improved procedure. --BrownHairedGirl (talk) • (contribs) 12:08, 18 March 2008 (UTC)

Thanks for the points. For posting to noticeboards - this is something I require a lot of the time when looking at BRFAs for non-routine (interwiki) tasks. It would perhaps be handy to put that as a requirement into the boilerplate instructions. For the technical issue of using the edit summary - I think it can be worked around. If absolutely impossible, that the userpage should be used, but that increased visibility offered by having a link in the edit summary is very attractive, and so perhaps the CfD summary you cited could be changed to ([[brfa link|BRFA in progress]]) moving categories ([[Cat:adfgh|A]] -> [[Cat:asfghe|B]]) per [[WP:CFD link|CfD]], for the duration of the trial at least.

For the re-examination/probation idea - I think we should look at it like the issue of assigning rollback permissions (in a strange way, using a terrible simile). Any member of BAG can throw the bot into BRFA again, with or without discussion among BAG members here. If they think that discussion should take place before reopening it, then discussion can take place here - we'll trust members' judgement for this. If they so repeated errors of judgement, then the solution is obvious. Martinp23 13:08, 18 March 2008 (UTC)

I fully support BHG's well-worded comments above. She has covered practically everything I wanted to say, and more, raising some good points and offering some solutions. The issue of whether some bot operators only want a BAG on their terms is still worrying. It speaks to the underlying inability to work with others, and more importantly, an inability to work with those they disagree with. Carcharoth (talk) 14:45, 18 March 2008 (UTC)

To BHG, one of the planks of this proposal was that only a single BAG member would be needed to agree that a complaint warranted probation for it to happen. The idea being that this would rule out frivolous complaints. If you do not have confidence in any members of BAG (it would surprise me if you have had dealings with all them), then there is no proposal for more intensive review of bots by BAG that you are likely to agree to. Are you saying that your concerns could only be addressed if BAG were removed from the process? WjBscribe 15:46, 18 March 2008 (UTC)

You're right, I have had dealings with only a few BAG members, at least in a BAG context (e.g. I have dealt with Reedy Boy (talk · contribs) on other issues and he was very helpful).

However, I didn't say (and didn't mean) that I have no confidence in any members of BAG, but rather that I don't have confidence in BAG as presently composed to handle this process in a way which will maintain the community's confidence.

I think that we do need a BAG, and I don't object to the principle of a BAG member being the one to press the "go" button on a review, but when we still have BC and ST47 defending the previous curtailment of discussion, I don't have any confidence that that requests for review will get a fair hearing or that they reviews will not be summarily closed if they offend those users. (After ST47 closed the NFCCbot BRFA, the only BAG member who I have seen to object was Martinp23, in his arbcom evidence. Other discussions may have taken place elsewhere, but if so, they didn't change the situation).

The solution is not to remove BAG from the process, but to remove from BAG the members who are actively hostile to community input. --BrownHairedGirl (talk) • (contribs) 20:38, 18 March 2008 (UTC)

I think that it would also be fair to summarise for the members of the BAG who are reading that there is more than a little confusion within the community that the issues with Betacommandbot do not actually appear to have even been addressed by the BAG. There are references to off-wiki communication, but this is counterproductive to the appearance of impartiality by the BAG. In particular, there does not appear to be a precise list of rules and procedures for bot approval and operation. The role of the BAG during the operation of approved bots needs to be better defined, since at the moment complaints are bounced between ANI and Arbcom without ever approaching a BAG page. Wikipedia:Bots#Dealing_with_issues does not deal with systematic problems of a bot or operator. The following are points which I think are particularly important to address:

1. Splitting of bots into multiple user accounts
2. Adding additional tasks to an approved bot which are not related to previous tasks
3. Taking into account the community's weighting of advantage vs damage for bot tasks which must necessarily be imperfect (spellbots, category correction)
4. What does the BAG do if the community objects to a particular bot?
5. What does the BAG do when an operator uses his bot for an unapproved task?
6. What is the BAG's view of non-interactive, unsupervised scripts without a bot flag?

As I have made clear to betacommand, I think that the problems which have arisen with his bot are primarily due to a failure to the BAG to address the points above. In particular, I think that the BAG needs to move away from the idea that all approved bots are operating under community consensus. To this end, I would encourage members of the BAG to consider the idea which is floated elsewhere to have a Request for Bot Approval, on the RFA page, but only for bots which already have the bot flag, and which have been shown to be troublesome. I can't imagine sinebot needing to go there, but I think it would help a lot if there was a clear standard for community approval for such bots. If, as the BAG claims, a bot such as the Fair Use Bot is essential for the survival of wikipedia, but couldn't pass such an approval process, then the operator should have no problem getting the Wikimedia foundation to approve the bot (and even give the bot an admin flag), much as the foundation does for its employees. AKAF (talk) 13:38, 19 March 2008 (UTC)

Comment by CBM

I'm treating this as an RFC and leaving a comment without directly replying to the comments above.

My main concern with the proposals is that they don't appear to distinguish between the majority of bot requests that have a chance of getting approved, which are uncontroversial in every way, and the small minority of viable requests that might warrant broader discussion. Requests for interwiki bots, talk page archiving bots, AWB bot flags, etc. don't need a lot of community discussion. They just need an experienced person to review the technical details, and that's the point of the BAG process.

Most of the requests that would be unacceptable more broadly (such as spelling bots) are routinely denied without need for long discussion. That only leaves a small handful of tasks that might actually be approved but would also be controversial. The easiest thing to do for these is to start an RFC about the task.

So I don't see a need to revise the bot approval system. Everyone should remember that the goal is to have a system that bot operators will voluntarily follow before adding new tasks to their bots. The more complex the BAG system becomes, the more operators will simply ignore it. — Carl (CBM · talk) 12:36, 18 March 2008 (UTC)

Point taken, but I suggest that CFD is a useful comparison. The procedure is there for extended debate, but people don't have to use it, and very often don't. I suspect that many (perhaps most) bot probationary periods would pass without comment, and that's fine: what matters is that if there are concerns about a bot, that there is a lightweight way of raising those concerns withiut the necessity to open an RFC. --BrownHairedGirl (talk) • (contribs) 13:00, 18 March 2008 (UTC)

Mmm yes - it's worth me noting again that the probationary period can pass by without a hitch at all, and not be any hiccup at all to the operator or the BAG. If however an issue is raised that shows community upset about the proposal, then we've saved a lot of the bureaucracy of an RfC and the system has worked well. The only times that there could be a hint of intervention required in a probation periods is at the end, and if a problem comes up. And, it must be said, if a problem does come up then it is all worth it. Martinp23 13:11, 18 March 2008 (UTC)

I remember that the last time there was talk of making the bot approval process stronger, it seemed quite possible it would simply result in the dissolving of the BAG altogether. The process is on shaky ground as it is; we have essentially voluntary compliance by established operators, and additional restrictions are unlikely to help the situation. I don't see why we can't simply ask the BAG to be more firm in their discretion to seek outside comment for the few requests that warrant it. — Carl (CBM · talk) 14:09, 18 March 2008 (UTC)

Those who ignore the approvals process are going against the word of WP:BOT: "Bots must be approved before they may operate." Rather than taking this stance, perhaps they could serve the community better by helping to refine BAG/BRFA operating procedures. Martinp23 14:16, 18 March 2008 (UTC)

I'm thinking of comments like this one by Cyde [1] who as he points out was running an "approved" bot. There was also the discussion at the MFD last year. A common thread I have seen throughout these discussions is that BAG continues to exist only by being sufficiently convenient that not too many bot operators choose to ignore it. Personally, I only continue to file new "task requests" because the hoop is sufficiently low for my taste. — Carl (CBM · talk) 15:48, 18 March 2008 (UTC)

Cydebot is one of the better bots, doing a clearly important job and doing it with a very low error rate, and Cyde (talk · contribs) is both civil and helpful when it questions arise about the bot; I have sometimes dropped in to lend support when Cyde faces a why-did-your-evil-bot-delete-my-category-you-swine rant. But I'm disappointed that in the linked comment Cyde took such a casual attitude to BRFA, because the process isn't that tedious and getting approval is a policy with a very useful purpose in maintaining community support for bots.

So I'm wondering if there could be some synthesis here of the concerns of bot owners and the concerns of the community. The lengthy threads at ANI indicate a need for greater community input on bots, but some bot-owners (who perform a valuable service) find the BRFA process cumbersome. Could we perhaps review the process to see how it could be simpler to use, while still allowing more community input?

I'm thinking of something along the lines of the reforms made about a year to the AFD process, where smarter templates made the task of opening a nomination very much easier. Before then, I used to dread making an AFD nom, because it involved reading a complicated instruction page and tabbing back-and firth between difft pages. Now, I just put {{subst:AFD}} in the article and all the links and instructions appear in the article ... and Twinkle automates the while thing so smoothly that I will probably AFD myself one of these days.

Without going for something as elaborate as Twinkle, could we consider a template redesign to make a BRFA request easier?

One of my suggestions above was for a template pointer on noticeboards, and that wouldn't have to be done by bot-owners — it could be done by BAG members (if they have the energy), or by others taking on a helping role much as the clerks do formally at arbcom.

However it's done, some synthesis is needed. It is important not to create unnecessary hassles for bot owners, but I hope that responsible bot-owners such as CBM and Cyde can also that we do need to find a better way of pre-empting off the sort of conflicts that have arisen over less responsible bot-owners, as well as a better way of resolving conflicts when they do arise. I do hope that those two objectives can be shared objectives. --BrownHairedGirl (talk) • (contribs) 16:16, 18 March 2008 (UTC)

My piece to add is that it does not seem that the existing BRFA process is broken (maybe backlogged), so much is the process to un-approve bots nonexistent and that post-approval monitoring of Bots is rather hit or miss. Maybe if we could define the procedures for a reverse BFRA to the same extent we've done with the Admin RFC (essentially a reverse RFA), then when these threads pop up on ANI, we can just say "Go write up at page X and see if anyone else feels its a concern."

As far as post-approval monitoring, short of making Bot ops link their edit summary to each task approval, I'm not sure how this can be monitored. I've been working with WJBscribe to deflag inactive bots, which should make the Bot flag list shorter, but without some sort of Bot logging function, I don't have an answer.

And I know I don't operate a bot or have programming knowledge, but I'd be willing to volunteer my time helping with the backlog at BRFA is anyone thinks it would be helpful. MBisanz ^talk 18:23, 18 March 2008 (UTC)

Minimizing bureaucracy

In general, I think we should move incrementally to strengthen controls over new bots, while being careful about the amount of extra work those controls can cause. Extra work for BAG means less time contributing in other ways to the project. If we put in some new controls, and then don't prove adequate, then (and only then) should be add yet more.

In that light, I suggest something like this:

• Distinguishing between bots that are flagged (because they're doing non-controversial edits) and bots that are not. The system for flagged bots could stay as is.
• For bots that would not be flagged, posting not to community noticeboards but rather to the talk page of the most relevant policy or guideline, with a brief description of what the bot is doing and a link to the BRFA page. It would be up to the bot owner to indicate what talk page he/she proposes to post at, and what the text would say.
  • Doing the posting at the point where the bot has been approved for a trial run.
  • Waiting for five days after the trial run is completed to see if any objections are raised.
• For bots that would not be flagged, having a probationary period, as mentioned above. (I suggest 2 weeks rather than a month.)
  • Bots in the probationary period would have a link to BFRA in all edit summaries
  • At the end of the probationary period, formal approval is needed; until that is given, the bot should not continue to operate.

I think reconfirmation is just too much work/bureaucracy - if there problem is with less than (say) five percent of bots, why do reconfirmation for 100%. (Even for non-flagged bots, I think reconfirmation is excessive. At the minimum, we should wait to see how other changes work out before taking such a drastic step.) -- John Broughton (♫♫) 22:46, 19 March 2008 (UTC)

No one is suggesting a full reconfirmation - just reconfirmation on a case by case basis where issues are raised. Flagged bots need to go through the same approvals process as unflagged bots - after all both types should have community approval. The flag is just something used to hide the bot in rc. Martinp23 00:12, 20 March 2008 (UTC)

Existing practice and what to do about it

As far as I can tell, current practice is to direct potentially controversial bots to a suitable forum to discuss what it proposes to do (as opposed to how it proposes to do it, which is unarguably the mandate of the BAG). Perhaps codifying this would be a good idea, but adding an extra layer of approval process will not be of any significant help.

I know that I've sent more than one request to the VP (and, indeed, one to RFA) when there was doubt that the task itself might have been problematic— which is not that often when you look at the archives. Almost invariably, those forwarded discussions either generate absolutely no comment, or a very tiny handful of comments— certainly not enough to make more than a blind guess at what consensus really is.

Which leaves us at the BAG in an odd position— we either rule on "likely to be uncontroversial" or let bot proposal for potentially valuable and useful bots rot because of lack of interest either way by the community at large which is, and always will be, generally unconcerned about bots.

I know this isn't going to be liked much more that the proposal above, but at least the scope of added bureaucracy and drama will be reduced: Have an RFA-like process for BAG membership but otherwise give BAG members wide latitude in approving bots. There is no way we can get the community to pay attention to bot approval— especially since the vast majority of bot requests are trivial, boring and uncontroversial— because, frankly, it is boring crap for the most part.

Let the community pick a number of editors that are trusted for their technical acumen and judgment, and actually trust them. But open that process of selection to the wide public and give it enough exposure that a more significant fraction of the community gets to chime in; the current process admitedly does give too much weight to in-group thinking regardless of how much good faith goes behind it.

It's bureaucracy, but BAG membership "election" would be infrequent (unlike actual bot approval which is high-volume comparatively). And I would expect that, in practice, a dozen or so BAG members is all that's needed at any one time to take care of business. — Coren ^(talk) 23:32, 20 March 2008 (UTC)

I like this idea since its a medium between anyone can join BAG and only BAGers select future BAGers. Sorta like crats and admins. Once they've proven their trustworthiness and ability to the wider community through RfX, their given wider latitude in things like CSD and renames. MBisanz ^talk 23:35, 20 March 2008 (UTC)

Rambot

It's always been my stated intention to run the rambot again after the next U.S. census, but that's still a couple years away. I also had some other approved tasks that I wanted to eventually perform. I don't see the need to de-flag it and I may want to run it again sometime, since it isn't hurting anything, but it's also not the end of the world if it is deflagged. I'll request it again as needed if I have to, so long as the process to get the flag isn't endless and mundane, otherwise I'll just do something else. In any case, bot policy was essentially formed as a result of my bot anyway. I have a very long history of useful results, so there is no reason to remove the bot flag simply because you think it could be abused in the future. That's just totally ridiculous. Also, there is always work to be done. The fact that I rarely have time now to do any such work does not mean that I won't in the future. -- RM 21:16, 20 March 2008 (UTC)

Automated and semi-automated

Since we're discussing bot policy revisions, I would like to bring up again the distintion between automated and semi-automated bots. According to WP:BOT, semi-automated ("assisted") bots do not need approval. I've seen editors making repetitive questionable edits defended from a block citing this part of policy. Without an operational definition of semi-automated and automated editing, there is a loophole. The distinction seems to me related to the response time of the operator. I propose an operational definition of an automated bot is any repetitive edits where the operator does not respond within some reasonable time, and I think a reasonable response time is 15 minutes or less. Therefore, if an "urgent" query doesn't get a response in 15 minutes, we would presume the operator is offline and the policy for an "automated" process applies. Comments? Gimmetrow 22:37, 18 March 2008 (UTC)

I'd wonder if this wouldn't be easier to police on an edits per minute basis. As in, if an editor is making 10 edits per minute using AWB for 40 minutes straight, I'd say he's approaching Bot speed. MBisanz ^talk 03:19, 19 March 2008 (UTC)

That's another consideration, but I think the essence of an automated script is that it runs without the operator (to check and approve each edit). I have in mind a situation where a user's account was tied up for an hour while javascript in his monobook made edits. The user was unable to respond to comments. Even if the script only performed 2 edits per minute, because the operator could not respond, I would think the script ought to be reviewed for technical problems first.

I also think fast scripts should be reviewed for the technical issues, but for slightly different reasons. Fast edits are difficult to review by hand. Until the maxlag feature was added, unapproved (unflagged) scripts were limited to something like 2 edits per minute by policy. One aspect of the first BRFA is to review whether the operator can be trusted to run bots; bot approval partly means the operator is trusted to make good use of fast automated editing. Subsequent tasks tend to be reviewed quickly if there are no technical concerns. Gimmetrow 04:11, 19 March 2008 (UTC)

I don't know the technical end of it, but maxlag has always scared me to some extent, as it permits almost unlimited editing speeds at certain times of the day. And we've seen problems before with scripts that aren't fast, but are long and unmonitored, such as Maxim's deletion script that until recently wouldn't detect changes made after the script started. I'm beginning to wonder if all edits over a certain speed and all unmonitored editing should be included in the definition of a Bot. MBisanz ^talk 05:20, 19 March 2008 (UTC)

That's basically what I'm saying. I think either unmonitored or fast editing scripts should be reviewed and "approved by someone". Gimmetrow 06:04, 19 March 2008 (UTC)

Maybe the 2 epm restriction should be re added to the policy? I know it is perfectly possible to edit the normal way at a greater rate but is not very common. People wanting to use a semi automated script/bot at greater than 2epm need to get it approved? (But probably not flagged) -- maelgwn - talk 06:14, 19 March 2008 (UTC)

There's no such thing as bot speed. Bot-like editing means automated (usually repetitive) tasks, not a particular speed. Semi-automated editing can at least reach a dozen edits per minute (especially anti-vandalism work), and a bot could perform repetitive tasks at one edit per day: "bot-like speed" really is a misnomer. I'm not sure what the point of limiting semi-automated editing is, since by definition, every edit is approved and the responsibility of the editor. If he/she makes a mistake, it is entirely his/her fault. (Disclaimer: I do a fair amount of semi-automated editing, and am not exactly neutral on this issue.) Do you have any examples of editors using the semi-automated editing card to fend off blocks? Gracenotes^T § 15:41, 19 March 2008 (UTC)

The main reason I have heard to slow down semi-automated editing is that it can overwhelm the recentchanges queue, making it hard for vandalism patrollers. Flagged bots are easier for them to ignore, apparently, as are admins. It would be possible to make a multithreaded version of AWB that edits at enormously high rates, but there isn't any reason to do that. My rule of thumb is that if so many edits need to be made that an average rate of 5/min is too slow, then a bot account is warranted. — Carl (CBM · talk) 15:50, 19 March 2008 (UTC)

Yes, Grace, an editor making arbitrary style changes on hundreds of articles has been defending from a block on the grounds the edits were "assisted editing". I'm assuming an automatic bot making non-consensus style changes would never be approved. Gimmetrow 21:39, 19 March 2008 (UTC)

The editor in question should have the same responsibility for the edits as if they were committed manually. Because, they were in fact (if truly semi-automated) committed with manual approval. Do you mean style changes like this, or something more controversial? Gracenotes^T § 01:53, 20 March 2008 (UTC)

It was something else. But I ought to point out that moving refs can be controversial, and the regexes commonly used by AWB users have flaws. I'll discuss your regexes on my talk page, if you like. I can't find them in your .js files. Gimmetrow 02:11, 20 March 2008 (UTC)

I should point out that, in my mind, at least, there is no ambiguity. A semi-automated task is one where every edit (or, at the very least, every series of directly linked edit) requires positive input from the operator. AWB comes to mind in its usual operation mode (see change, click to save). I doubt there are any members of BAG that operates with a significantly different definition. — Coren ^(talk) 01:46, 20 March 2008 (UTC)

Would an assisted script include one where an editor "approves" every edit and then lets the script run for an hour? Gimmetrow 02:11, 20 March 2008 (UTC)

"Approving" an edit means that each edit is approved (normally by visual inspection, either of the resulting new version, or diffs, or both) shortly before it is saved. Your case "... then lets the script run for an hour" seems more like a bot mass-storing preprocessed edits, which is something else. The quality of an approval process is of course never guaranteed, some are better proofreaders than others. If the inspection is done by a program, then the process is no longer semi-automated but fully automated. Oceanh (talk) 04:22, 20 March 2008 (UTC).

Of course people make mistakes, and that's understandable. The concern is when people use AWB or some semi-auto tool to do large numbers of potentially controversial but undiscussed edits, to the point that it becomes a de facto "standard". Do we deal with such tasks as a bot task needing approval? Or some other way? Gimmetrow 05:01, 20 March 2008 (UTC)

I see your point. Programs/bots/scripts are great tools when applied "correctly" (and with care), but can do much harm if they perform a "wrong" (unwanted) task, or if they operate in a buggy way that mess up articles. I think an important question is, how easy is it to revert unwanted edits/results. An editor should always be prepared to (and able to) revert unwanted edits herself, if "asked by the community". I would say that for a task that is not approved, one single objection is enough to stop the process, and discuss how to proceed further. Oceanh (talk) 05:30, 20 March 2008 (UTC).

I think thats actually a rule (Martin?) - Or at least, a community accepted rule, that someone should at least offer to either revert bad edits, or assist in reverting them. Sometimes more experienced users can do it easier, and this happens. —Reedy Boy 08:10, 20 March 2008 (UTC)

If the problem is that the recent changes log is getting overwhelmed, then the answer is to make the recent changes log bigger, not to put bureaucratic obstacles in the way of people trying to make Wikipedia better. I've certainly approached "manual" 15 epm when WikiProject tagging with AWB - restricted to 2epm it would have taken all day to tag a couple of hundred articles. There's already an "approval" mechanism for "fast manual editing" built in to Wikipedia in the form of AWB approval, so I'd suggest that if people have that, then they have licence to edit as fast as they want (and AWB approval is revoked if there's a problem). Then you're just left with people rolling their own edit bots; but given how fast people can edit without AWB or anything I'd suggest the default definition of "too fast" should be nothing less than 6epm, possibly more. FlagSteward (talk) 11:04, 21 March 2008 (UTC)

Trial periods...

So, it seems to me, that sometimes, trial approved bots kinda... get lost... Feel free to revert me, but, I made a new section for bots that have completed the approved trial, that re-transcludes them on this page, to allow for further community discussion. [2] SQL^{Query me!} 02:58, 20 March 2008 (UTC)

For right now, I've changed the status of those bots to Open. Someone more knowledgable than I should probably implement a |TrialComplete parameter (and, fix whatever generates the report, to reflect it too) SQL^{Query me!} 03:01, 20 March 2008 (UTC)

Um im not sure how it is any different from 'Open', except where it is located. And who is going to move it? It is rare that much discussion occurs after the trial, so it would make little sense for a BAG member to move it before approving it and it would complicate it too much for an operator have to do it because they wouldn't know they have to. Unless a bot is going to do it? (Maybe a trial completed template would work, this would then show up on the listing on the page also.) -- maelgwn - talk 08:25, 20 March 2008 (UTC)

Having just taken 12 days from trial completion to approval, I'm quite aware of this. :-)) Just as a general comment, it would be good to make it a bit more explicit (in section III - or IV?? - of the instructions) what happens after a potential bot owner has run his trial. I kinda assumed that the person who approved FlagBot's trial would be watching the page for changes, but after nothing happened for a week, I first left him a message, and then a day or two later slapped a "needs attention" flag on it. It didn't help that my "BAG contact" was Betacommand I guess, I imagine he's got other things on his plate at the moment. ;-/ But in the first instance, some more explicit instructions would help (once you've finished the trial, mark it "needs attention" presumably? And in the longer term, a "trial complete" tag would make a lot of sense, to distinguish them from bot approval processes that need attention in some other way. FlagSteward (talk) 11:26, 21 March 2008 (UTC)

Current Bot Policy

Okay, this is a summary of what we have so far, from what I gather on this page. There is a consensus that something needs to be done about current bot policy without necessary adding more bureaucracy to the whole issue. This is not new before, but the policy discussion regarding the bot policy has never been highly involved, honestly. I have separated the issues raised into sections that can be discussed in further in-depth.

It seems like the bot flag, from historical reasons, stems from importing census data into the Wikipedia. Since then, the bot policy page has been defined and refined many times over in order to clarify what it meant to get a bot flag. With such projects as pywikipedia, the perl wikipedia framework, and AWB, the definition changed and had to allow for the development of newer bots and tools. --AllyUnion (talk) 02:43, 21 March 2008 (UTC)

Avoiding more bureaucracy

Several users, and myself including, wish to avoid further complications to the bot approval process. We don't wish to make it long and more complex than it is. --AllyUnion (talk) 02:53, 21 March 2008 (UTC)

Proposal: Add an additional trial period

Martinp23 has suggested to add another trial period.

Proposal: Leave the policy as is

I have suggested this, and that the policy should be left alone based on technical grounds, which this policy page is ultimately for the approval of the bot flag and the technical aspects thereof. --AllyUnion (talk) 02:53, 21 March 2008 (UTC)

Proposal: Monitor Talk page

I'm all in favour of minimising bureaucracy, having just gone through the process myself. ;-/ I was wondering, would one way to flag up bots with "issues" be to monitor the Talk page of the bot? More than "x" Talk edits per month and there could be a problem. An even neater way to "involve" the "ordinary", less technically aware Wikipedians would be to roll some kind of form which had to be transcluded at the top of every bot Talk page where registered users could vote: Do you think this bot is doing a good or bad job? Once there's more than "y" complaints per month, someone looks into it. That way you'd get fewer false positives and hopefully more ordinary punters contributing to the process, they might vote in a poll even if they were reluctant to write a formal complaint. FlagSteward (talk) 11:16, 21 March 2008 (UTC)

Believe it or no, not all bot talk page edits are complaints, so I don't think this is itself automatable. I think there should perhaps be a clearer "escalation route", for when someone fails to get satisfactory resolution of their issue, or if someone happens to note a large number of complaints about the same bot. (It's not like there's an actual lack of venues to discuss such matters, but I couldn't definitely say which should be the 'first port of call.) Alai (talk) 05:05, 22 March 2008 (UTC)

I suppose it should be clarified the steps needed to flag attention to shut down a bot. At the current moment, it's rather vague and people tend to read it as... "report it to AN/I anyway" --AllyUnion (talk) 11:36, 22 March 2008 (UTC)

Sure Alai, that's why I said an active Talk page could indicate a bot that the community had problems with. But it would be easy to come up with something that filtered bot Talk pages with >x edits in the last 3 days say, where x was set differently per bot, low (10?) for bots in their first month, rising to say 100 for WP 1.0 Bot or something. Most problems should show up in the first month - but we want to at least have a chance of catching an established bot that "goes rogue". It would then take somebody just a few seconds to check the half-dozen bots with "unusual" levels of Talk activity, to see if they're being showered with barnstars or going down in a hail of flame. That human then gets to decide whether to forward the bot to a complaints procedure or not, or otherwise perhaps increase x for that bot. Don't forget, we're looking to minimise bureaucracy, minimise the work involved, and involve ordinary Wikipedians as much as possible. The ordinary Joe doesn't know about BAG, they expect to interact with other "users" via their Talk page. FlagSteward (talk) 12:51, 22 March 2008 (UTC)

Well we want input before a bot is approved. We don't want the drama of having to remove bot flags later - hence my proposal above Martinp23 17:19, 24 March 2008 (UTC)

Proposal: BAG election

Coren has suggested that elections be held by the community to deal with violations of bots and bot owners, much like the ArbCom deals for normal people. --AllyUnion (talk) 02:49, 21 March 2008 (UTC)

Bot owners have ceased to be normal people? Oh. :) I feel that this might be going a little too far, but I think that something has to be done to increase the interaction between the community at large, and the bot approvals process. Firstly, the whole "technocrat" thing has to go. Having leet programming skilz is all well and good, but it has only a relatively small bearing on the approval process -- or at any rate, on what the approval process should be. Given the that bureaucrats have made it explicit that they're essentially just going to be rubber-stamping what the BAG decides, it's all the more crucial that the approval process is, and is seen to be, determining the consensus for a given bot task, whether in the form of established policies and guidelines, or explicitly on a case by case basis. Perhaps we should take this to its logical conclusion, and ask that flag-setting be split out from the BC role, and assigned as a separate permission (or if we end up talking to the dev hand on that one, at least make the distinction in on-wiki process). That might induce the community to pay a bit more attention to "approving the approvers". Alai (talk) 04:44, 22 March 2008 (UTC)

Well, specifically, I think what Coren meant was, and he'll need to correct me if I'm wrong here, the BAG is essentially an ArbCom for bots. Any problems with the bot owners should still be handled by the ArbCom, should normal dispute resolution processes fail. In regards to the technical aspect, well... if you really want to boil down control, bots are permitted because the developers allow it. The way I see it, BAG should consist of some people of technical knowledge to lessen the burden of the developers. --AllyUnion (talk) 11:42, 22 March 2008 (UTC)

I would strongly agree with cutting out the middle-man by allowing members of the bot approval group to set/unset bot flags. Any delegation of power (but with reasonable community input into the decisions) is ultimately a good thing, provided those who we delegate power to know what they're talking about, and are trustworthy. — Werdna talk 12:53, 22 March 2008 (UTC)

I don't know if it's needed to have BAG members be able to give or take back the flag themselves anymore than it is needed for AC members to be able to desysop directly; but yes, I did mean that the BAG should be elected at large then given real authority over bots— this would give a clear place to bring grievances, and would increase general confidence that someone is keeping an eye on bots. The 'crats are responsive to bot-related requests from the BAG so I don't think we need to worry about the extra step. — Coren ^(talk) 14:20, 23 March 2008 (UTC)

On the contrary, Arbcom doesn't need the ability to desysop directly because it's done so rarely. We get a few desysoppings per year, and that's about it. Note that they do have the right to do things that they do do more regularly, for instance oversight and checkusers. In comparison, BAG hands out a bot flag every day or two, sometimes more often, and it produces a real workload for bureaucrats to keep up with. It is certainly desirable that we let the bureaucrats get on with something more useful than plain rubber-stamping of BAG decisions.

I do agree with you in that the approvals group should be given a real community mandate to be an authority on bots — bots are a sensitive area that requires particular expertise, and I don't think it's necessary or desirable to get the full community involved in decisions about whether a task can be done by a bot. As we've seen in requests for adminship for bots, many users have incorrect ideas about bots, or just plain don't like them. It is for that reason that I would agree with the community determining who they trust to understand technical issues (the Bot Approvals Group should never have the power to determine whether it is desirable to do a task at all — only whether it is desirable to have that task done by a bot. A bot absolutely must be doing something that would be OK to be done by a human). — Werdna talk 23:17, 23 March 2008 (UTC)

Actually, what I've heard from the 'crats I've talked to basically amounts to "we can handle the workload" (re both the bot flagging and putative RFx for BAG membership). Doesn't mean I'm opposed to the idea, but I think that's a distinct and strictly orthogonal question that we don't need to ask ourselves just yet. — Coren ^(talk) 03:45, 24 March 2008 (UTC)

Coren, I was referring to this statement by WJBscribe. This tells us two things: firstly, we have an (actual) arbcom case about bot use, which I think puts the "BAG as arbcom for bots" model somewhat into perspective (as does the fact that a BAG member is the key involved party), and secondly that the 'crats don't really consider that they have a workload where bots are concerned, aside from pushing the occasional button. (It is not the premise of my suggestion that the actual flagging is somehow overly-onerous for the traditionally massive-overmanned 'crat-corps.) I also think the "lessening the burden of the developers" is not necessarily a helpful comparison, since it seems to encourage the understanding that the devs have "delegated" this function to the BAG, which is problematic in a number of respects (such as not being the case, and come to that, the amount of uncertainty that exists in the first place about the devs' role in the first place). I think to put it in those terms also exaggerates the "technocratic" aspect of the bot-approval process.

What motivates my idea is that there's a discernible disjunct between community input and the BAG. I believe this stems from a) community apathy in the normal run of things, other than when there's an episode of bot-related drama, but also b) the current BAG seems in part to rather like it that way. I'm not sure that simply having the BAG function as at present, but declaring "free and fair elections!" would significantly change the first part of this, though it might be a reasonable step to addressing the second. If a "bot approver" section were to appear on WP:RFA, I'm guessing the community would take a more active interest. I'd further justify the "mini-bureaucrat" model on the basis that bot-approval has been "advertised" as part of the BC role for some time, but it's obviously not what's uppermost in most people's minds when they're considering candidacies at RFB (for the full, "combined" role). And fundamentally, bot-approval is indeed similar to the bureaucrat role, in that primarily it's about judging community consensus for a given task (granted, with the additional matter of the technical aspects of the feasibility and advisability of automation, the importance of which I believe tends to be systematically overstated in these discussion). Alai (talk) 09:13, 26 March 2008 (UTC)

I think that this perception that the importance of the technical aspects is overstated exists only because, by and large, the community haven't had technically problematic bots to deal with— because that aspect of bot operation is already very well covered by the BAG as things currently are (as far as I can tell this is pretty much the only thing people don't complain about regarding the BAG).

I think we both agree that formalizing the BAG and requiring community "election" is a good thing, even if we don't agree why it's a good thing in part.  :-) — Coren ^(talk) 14:27, 26 March 2008 (UTC)

Dealing with "semi-automated" definition

The history behind this is stemming from the development of AWB. The reason why it definition was added was for the purpose that editors, although doing the task manually, were still assisted to the point that a bot flag was necessary for some users. --AllyUnion (talk) 02:43, 21 March 2008 (UTC)

Proposal: Bot operators must prove the same definitions as their bots

Before, I recall that there was a discussion that we had to prove that bot operators had to prove that they were useful and harmless. In light of recent events, it seems like this discussion may have some merit. --AllyUnion (talk) 02:46, 21 March 2008 (UTC)

• Requests for approval by very new or problematic users are already being denied, what else could be done? MaxSem^{(Han shot first!)} 06:31, 21 March 2008 (UTC)

• • This is true, but it's not explicitly outlined in the policy. --AllyUnion (talk) 07:01, 21 March 2008 (UTC)

Proposal: Problematic bots should use the RFC process

"The easiest thing to do for these is to start an RFC about the task." — Carl (CBM · talk) 12:36, 18 March 2008 (UTC)

Issue: Deflagging bots

RM has raised the issue about deflagging inactive bots. Personally, I don't see what the harm is leaving an inactive flagged bot, especially if the bot hasn't had any problems, and we have already gained trust with the bot operator. --AllyUnion (talk) 02:58, 21 March 2008 (UTC)

You can blame this one on me. Last month there was a discussion of Bots with official sounding names possibly being a bad idea, since Bot policy says a bot name should specify its a bot and relate it to the owner's name, like Z-Bot being related to Z-man. So I went and compiled a list at User:MBisanz/Botlist of all the bots that seemed to have official names. In doing so, I realized a bunch of these bots (8/74 actually) hadn't edited ina really long time. So I had the idea to contact the bot ops and see if they didn't mind deflagging dead bots (bots that will never operate) just to keep the house of accounts that have the Bot flag current/in order. Once I was done with those 8, I realized it would be an easy task to check all ~400 bot flagged, accounts, which led to the 80 accounts I notified. Working with crat WJBscribe, we agreed to only deflag bots where the operate explicitly said they could be deflagged. It wouldn't be overturning their BRFA or revoking their status as a bot op, just a housekeeping sweep. Sorry for any confusion. MBisanz ^talk 06:20, 21 March 2008 (UTC)

So basically they could just ask for the flag back at WP:BN if they wanted to become active again. —Random832 (contribs) 14:40, 26 March 2008 (UTC)

Correct. MBisanz ^talk 05:39, 27 March 2008 (UTC)

As I see it the arguments for deflagging inactive bots are:

1. Making it easier to keep track of bots using Special:Listusers. If bag is to have a credible role in overseeing bot operations on Wikipedia, it needs to have some idea of what bots are actually still operating.
2. Security - this is probably only a slight issue but a hacked account that can made edits unseen from recent changes may be able to do damage before stopped. Its a mere technicality to remove a flag from a bot that isn't going to be used.
3. Should approval be for ever? Circumstances on Wikipedia may change that make tasks problematic. Ones that haven't been run for some time may not be appropriate to simply start again (or another bot may now be doing the task better, or more in keeping with the community's expectations).

Where a bot merely runs infrequently - e.g. Ram-Man's bot there may be no reason to keep the bot. However, where the bot will never perform its function again, withdrawing the flag makes sense in my opinion. WjBscribe 23:15, 27 March 2008 (UTC)

One thing I'm thinking of doing which is marginally related, is actively monitoring high-speed botlike editing (technical details TBA) and alerting the approvals group of any that seem to be unapproved. — Werdna talk 22:18, 30 March 2008 (UTC)

Issue: Dealing with bot edit summaries

The issue has been raised that some kind of standardization should be imposed on bots. There are, of course, technical limitations to this, however the point is valid. --AllyUnion (talk) 03:03, 21 March 2008 (UTC)

A good Idea would be having the summary begin with Bot-- CWii_{(Talk|Contribs)} 19:58, 5 April 2008 (UTC)

Issue: Splitting bots into multiple user accounts

I think this isn't something we should insist on in every case, otherwise we'd get a profusion of bot accounts, and get into all sorts of semantic games about what a "new task" is (which already comes up, given the approval process, but isn't exactly hard and fast). But for tasks that have are anticipated, or in the course of events prove to be controversial, or indeed where the operator has attracted such concerns, the BAG (or its hiers and successors) should definitely look at making approval of a task, and come to that, continued approval of a task, contingent on separation of functions into multiple accounts. Otherwise, there's a clear risk of running into "take it or leave it"/"my bot is effectively unblockable" issues. Which of course, we potentially have to address anyway, since some ops might refuse to comply with such a regime, but... Alai (talk) 04:27, 22 March 2008 (UTC)

No bot is unreplaceable. Most of them are only a few hundred lines of code, and we have plenty of operators willing to play by the rules. — Werdna talk 12:50, 22 March 2008 (UTC)

I entirely agree with you as regards actual replacability and complexity. (Possibly with the exception of the anti-vandal bots: I have no idea how those are actually operating, and they could be made as elaborate as one wished.) But in practice, there seems to be a great reluctance for a bot performing a "controversial" task -- or indeed, a manifestly unapproved, counter-consensus, and technically wonky one -- to get blocked, and moreso to remain blocked, if it's also performing some other "useful", or allegedly "essential" task, or set of tasks. It'd do no harm to try to grease the wheels of bot policy enforcement, which currently seems to be extremely patchy. Often, there seems be a large "bureaucratic" delay in the approval of fairly straightforward tasks, while other tasks that never go near the approval process, or whose subsequent issues transpire not to have been anticipated in same, sail on merrily, . Alai (talk) 18:14, 22 March 2008 (UTC)

I will personally re-code any bot that is considered to be "irreplaceable". We have no time for people who think themselves above the bot policy because nobody is game to block their supposedly essential bot. — Werdna talk 23:49, 22 March 2008 (UTC)

OK, this is a good thing. But are you suggesting this in this context, by way of a counter-argument to splitting, or do you agree that it can be appropriate to ask for this? (With my rationale, or otherwise.) Alai (talk) 00:46, 23 March 2008 (UTC)

Personally, different bots split out the tasks it does, and whatever breaks, can break on a separate bot account. I created separate bot accounts because they helped tracked down cleaning and such. Sandbot was specifically separate for that reason. --AllyUnion (talk) 09:05, 23 March 2008 (UTC)

I agree that this should be a requirement. A different bot account should be created for every distinct function; if only because then it's easy to undo accidental damage with a mass revert. — Coren ^(talk) 14:32, 23 March 2008 (UTC)

Issue: Adding additional tasks to an approved bot which are not related to previous tasks

I think, for the purpose of scope and narrowing down problems, separate user accounts should be created. --AllyUnion (talk) 09:02, 23 March 2008 (UTC)

Issue: What does the BAG do if the community objects to a particular bot?

In my opinion, the bot should be blocked until further notice until BAG reviews the reasons for the objection, which has been my opinion of the standing policy. --AllyUnion (talk) 03:11, 21 March 2008 (UTC)

There are two classes of objections:

Objections to the task

Should result in the bot's approval being temporarily revoked while the issues are sorted out. Bots should absolutely only ever run approved tasks (i.e. tasks that would not attract issues if they were done by a human). This is particularly important because bot edits need to be mass-reverted.

Technical objections

Should result in an immediate revocation of approval if critical (i.e. security). Otherwise, discussion should occur first (as the BAG's approval is prima facie evidence that the bot is technically sound).

— Werdna talk 12:50, 22 March 2008 (UTC)

Issue: What does the BAG do when an operator uses his bot for an unapproved task?

Per the bot policy, the bot should be blocked. Specific unapproved tasks require approval by the BAG. The approval process to me has been a technical oversight in the ability whether a task can be reasonably completely automated. Essentially, the process was put in place to prevent spell bots and the like from appearing. The primary idea was to prevent a bot from doing tasks that had a high rate that would require manual intervention and undoing. --AllyUnion (talk) 03:11, 21 March 2008 (UTC)

This is something I think could be improved. The first BRFA checks, among other things, the operators qualifications. Other tasks within the range of that expertise ought to be considered OK technically. That doesn't really address consensus, so some time ago I proposed that subsequent tasks be posted somewhere and given adequate time for comment; if a few days go by without objection, the task would be considered approved. The benefit is that only tasks which significantly expand the range of operations of the bot would need an "additional task" BRFA, reducing paperwork and encouraging better documentation of bot operations. "Adequate time" would also mean tasks shouldn't be done minutes after a BOTREQ. Gimmetrow 19:50, 22 March 2008 (UTC)

Ideally, no BRFA should go by for several days without some sort of comment; during that time, some sort of link to a reasonably-appropriately-scoped local consensus, or a relevant guideline or policy should be produced. If it's not, someone should prompt for something along those lines. If it is, and it isn't otherwise fishy, it starts to become reasonable to wonder why it's not been approved yet. However, I'm not sure we should be moving towards "approval by default", so much as being more speedy and proactive in getting to that point. If necessary, having some more BAG members might be helpful (especially if they're focused on determining said consensus, as opposed to seeing the role as some sort of mini-dev position...). Alai (talk) 21:27, 22 March 2008 (UTC)

In point of fact, I have come to BOTREQ to find some task proposed and already complete, often without technical problems, that I object to on consensus grounds. Gimmetrow 22:18, 22 March 2008 (UTC)

Approval by default was actually the status quo two years ago. --AllyUnion (talk) 09:01, 23 March 2008 (UTC)

Again, most bot tasks are uncontroversial even if they do not have a discussion leading to consensus— the trick is to make sure that BAG member have an explicit mandate (and trust of the community) to make that judgment call in the simple cases. — Coren ^(talk) 14:28, 23 March 2008 (UTC)

Generally speaking the tasks that BAG are asked to approve are tasks that have been approved a million times before — interwiki bots, newsletter bots, et cetera. There is no value in waiting for extra input on those. Where a task is novel or we're not sure about the consensus, we wait (case in point: BOTREQ Invalid Parameter: BLPWatchBot.), and where there is no consensus that the task should be done, the task is denied. All of this is, of course, what should be done, and what I've seen done since I joined 3 or so weeks ago. I am open to be shown that it is not what is actually done. — Werdna talk 02:44, 28 March 2008 (UTC)

Perhaps, then, the guideline should be established for certain established and verifiable code that has been thoroughly vetted. I don't think this should be the case for interwiki bots, particularly, as the operator involved should understand the languages he or she is changing the pages for. --AllyUnion (talk) 09:33, 5 April 2008 (UTC)

Issue: What is the BAG's view of non-interactive, unsupervised scripts without a bot flag?

Personally, it should be brought to the attention of BAG, and reviewed a case by case basis. Particularly, members of the RC patrol should weigh in on this particular point of the discussion --AllyUnion (talk) 03:11, 21 March 2008 (UTC)

I may be missing something, but why wouldn't this be "block on sight"? Or at least, block if speedy resolution is required, and discuss with the op in the first instance if not. If someone insists on running such a script, and not requesting approval, or a flag... Do you have any particular instances in mind? Come to that, I'd suggest much the same thing for unapproved tasks being run on flagged accounts, but I suppose that's a different issue. Alai (talk) 04:20, 22 March 2008 (UTC)

There are instances where such bots are permitted to do their thing, but in no way they should be left unchecked -- and therefore should be patrolled by RC group. The speed, however, of the edits should be kept to a reasonable limit so as not to flood the RC feed. --AllyUnion (talk) 11:44, 22 March 2008 (UTC)

I'm still not quite sure what sorts of cases you're getting at here: are you speaking of bots that have been "grandfathered in", and you're suggesting they should be explicitly re-examined? All of those that I can think of do have bot flags, though, so are better covered in your later question. Alai (talk) 18:21, 22 March 2008 (UTC)

I'm saying that, according to the bot policy, there are some bots that are running without bot flags with the full intention that they should be reviewed by the RC patrol --AllyUnion (talk) 08:57, 23 March 2008 (UTC)

If unapproved, they should be blocked on sight. We have a bot policy for a reason. — Werdna talk 12:46, 22 March 2008 (UTC)

Some bots have been approved to run without a bot flag. I can't remember the exact cases. Gimmetrow 19:39, 22 March 2008 (UTC)

If the question here is actually "should the BAG be approving bots to run without a flag?", then yes, it already is, and I don't see any problem with this, assuming that there are no other "issues" with the task, and the edit rate is low. Alai (talk) 19:53, 22 March 2008 (UTC)

I don't think the issue is "bots without flags" so much as "unapproved bots". There are a number of cases where it is desirable for an approved bot to not get a bot flag (anti vandal bots come to mind, as their edits showing in recent changes are a requirement). Unapproved automated bots should normally result in an immediate block— the amount of cleanup a misbehaving bot can cause in a few minutes of operation can take hours to clean up. — Coren ^(talk) 14:25, 23 March 2008 (UTC)

Issue: Bot names

Just as a comment from an ordinary user, it would be helpful if there was a rule that all bot user names ended in -bot. It's not immediately apparent that eg User:RoboMaxCyberSem is any different to a human editor - you shouldn't need to go to its user page to find out that it's a bot when it could so easily be made clear from the name. And conversely humans were banned from user names with -bot on the end. FlagSteward (talk) 12:22, 21 March 2008 (UTC)

I think that's reasonable... but only to a point. Given if the edit summaries are standardized, this might be a moot point. --AllyUnion (talk) 08:56, 23 March 2008 (UTC)

Come one... There is already a rule that they should include it, not all does, but come on! Snowolf ^{How can I help?} 10:19, 23 March 2008 (UTC)

Issue: Approved bots that unintentionally mess up articles

With reference to this illustration case, two questions arise: 1. Who is responsible for repairing destructive bot edits, when the bot operator is no longer around? 2. Is there any procedure for disapproving (deflagging) a task/bot when every bot edit messed up the articles it worked on, and not all the involved articles are repaired within a reasonable time? Oceanh (talk) 17:42, 26 March 2008 (UTC).

Switch from AWB to Perlwikipedia

May I have some guidance please about what to do when a bot which was approved to use AWB starts to use code written by the bot-owner?

I'm asking partly because it seems like a policy issue not covered in WP:BOT, but more importantly because it affects to my BHGbot.

BHGbot was approved late last year to use AWB to apply the {{WikiProject Ireland}} tag to articles and categories for WikiProject Ireland. I don't at this stage want to change the task list, but I do want to change from using AWB to using Perlwikipedia — partly because my Windoze PC is ill, but also because after a little bit of initial coding, it'll make the ongoing tasks much easier and facilitate more thorough logging. (I'm not a professional programmer, but I have ten years experience of using Perl for a number of web-related tasks, including lots of trivial data-munging and some bigger jobs writing a successful and feature-rich search-engine for a large website before there any decent free alternatives).

At the moment, I'm still in a development phase, and I have a lot of steps to go through before I will let the bot do any edits, but I would like some guidance on how to proceed. Should I seek fresh approval? Or is it assumed that an authorised bot operators will take responsibility for the effect of any code changes?

If there is a consensus that I should seek fresh approval for BHGbot, then I'm happy to do so ... but I'm not so sure about how a general rule can be made in this respect. The change from AWB to user-coding may seem like an easy point to require fresh approval, and it's probably a good one, because it marks a shift to from reliance on a thoroughly-tested package to reliance on the bot-owner's own programming skills. However, I see nothing in the current guidance about how coding changes should be approached, many bot owners are diligent in developing and enhancing their bots, so the code deployed at time of approval will in many (or maybe most) cases not be the code running a few months later, and even quite trivial changes to code can have a severe impact.

Any thoughts? --BrownHairedGirl (talk) • (contribs) 17:14, 26 March 2008 (UTC)

As long as the bot keeps doing the tasks properly, I don't see any problem with changing the programming. --Carnildo (talk) 18:54, 26 March 2008 (UTC)

There isn't a set procedure because that's a fairly rare event (complete switchover as opposed to incremental changes). Given that you'd be switching from one tool to the other (requiring a new technical evaluation), I would recommend you get a BRFA.

As for the changes over time, you are correct. Indeed, such incremental changes are expected given that the bot operator needs to be responsive to bug reports, changes in conditions, or other sources of "tweak". The presumption is that if you knew how to make it work properly in the first place, you are likely to be able to cope with problems if they develop during incremental tweaking (and will be expected to clean up after your bot). — Coren ^(talk) 18:55, 26 March 2008 (UTC)

BRFAs do not do "technical evaluations", in any meaningful sense, and unless and until they start demanding open disclosure of all bot code, they can't really start anytime soon. Unless either consensus for the task had changed, or a fresh "trial run" demonstrated a fresh set of bugs, a BRFA would logically be a complete duplicate of the first one. I strongly urge that the BAG do not start insisting on such "re-filings", since for a responsible bot owner, it's simply jumping through hoops for the sake of it -- and an irresponsible bot owner will just ignore it anyway, and the BAG will be none the wiser, before any rash of complaints about a distinct set of errors. Alai (talk) 19:29, 26 March 2008 (UTC)

as someone who does wikiproject tagging, AWB's kingboy plugin which BHG has been using does a lot that you may not notice. a complete re-write from someone who has no prior experience with writing custom scripts (AWB is a dummy proof cookie cutter program), going such a re-write does make the prior BRFA void. there are a lot of things that need to be taken into consideration that were not previously a factor. Please File a BRFA for the new bot task. β^_command 19:37, 26 March 2008 (UTC)

I will indeed file a BRFA ... but it's silly to claim that AWB is "dummy proof". Setting up AWB for unattended tagging requires a lot more simply pressing "go", and I have not used the kingboyk plugin for anything others than a few tests runs before I discarded it as too clunky for my purposes ... and without a lot of care taken in setting it up, it's quite possible to wreak havoc with AWB.

Anyway, I'm very pleased to see that we finally agree on the importance of seeking approval for a task which could be regarded as new. It's taken a while, but it's good to have you on board :) --BrownHairedGirl (talk) • (contribs) 23:34, 26 March 2008 (UTC)

This appears to assume (or assert) that BRFA exists to evaluate a person's "experience", or indeed their actual code. That's simply not the case. I would go so far as to say the above statement is itself "void". Let's assume that a responsible bot operator is going to make an adequate array of tests themselves before deploying a fresh coding of an existing bot, which is, as I've just pointed out, all that a second trial period would establish. (In fact, it's likely to do more than that.) Alai (talk) 19:54, 26 March 2008 (UTC)

Alai, if you have a beef with the current process, please refer to and participate in the extensive sections above which are exactly on that topic; there is little use in disrupting a conversation in order to make your point. — Coren ^(talk) 23:18, 26 March 2008 (UTC)

I strongly dispute and deeply object to such an evaluation of my comments on this matter, which are entirely independent of my observations on BRFA/BAG reform (except, perhaps, insofar as both happen to relate to certain apparently entrenched attitudes in the current BAG). As I said, under the present system, a refiled BRFA would either be a foregone conclusion, or would deviate from normally expected approval in an entirely inconsistent or whimsical way. This is not, therefore, an objection to "the current process", but with this proposed approval-revocation. I would accordingly request and urge you to reconsider, and withdraw, said characterisation.

I find it especially inappropriate that a single BAG member (and to be quiet candid, this one BAG member in particular) would purport to act unilaterally to declare a existing bot-approval "void" when discussion on the matter is on-going, and when another BAG member (never mind input from mere civilians) had earlier expressed a directly contrary view. Alai (talk) 06:31, 27 March 2008 (UTC)

For what it's worth, I don't think that a new BRFA is in any sense obligatory, but I do think it would be a good idea to check with some experienced bot operators to double-check that the basic idea of the new code is sound. One way to do that is to start a new BRFA. If the language is Perl, I may also be able to help. — Carl (CBM · talk) 00:27, 27 March 2008 (UTC)

I think a BRFA would be a good idea, so that we can trial the new bot, and make sure it performs as designed. New code can have minor hiccups, and, during a trial, there are actually eyes on the contribs, which is immensely helpful. SQL^{Query me!} 06:51, 27 March 2008 (UTC)

Hi folks

I hadn't intended to poke a stick into a hornet's nest, but I guess that after recent controversies I should have expected that might be effect :( Anyway, I just want to say again since there are several contributors commending a new BRFA, I'm very happy to do that, and actually welcome it. A few extra eyes on the design logic and on the actual code will be helpful, and I don't think that it need be a bureaucratic process — I assume that BAG will consider it in good faith.

My preliminary very rough checks suggest that this job may involve tagging about 5,000 articles, which is too high a figure for easy manual checking of the effect, so it seems much better to have a review before starting work than to try undoing problems which may not be detected until some time after the bot has been run, by which time rollback may not be a viable option for repairing any damage.

As to bureaucracy, I don't see a businesslike discussion of the bot's design and coding amounting to more than a small overhead on the time required to do the design, coding and testing ... and since several experienced bot operators have offered to share their insights, it may well save time.

May I ask that those who have concerns about this process give it a chnace, and see how it goes? Thanks! --BrownHairedGirl (talk) • (contribs) 15:22, 27 March 2008 (UTC)

The easiest thing to do would be to run it for 50 edits or so and have one of us look it over (another trial run, but not another BRFA). The only real difference would be if you introduced some bugs. — Werdna talk 02:41, 28 March 2008 (UTC)

Newsletter Bots (opting out)

My understanding of the current policy on newsletter bots is the following:

1. Newsletter bots are allowed for groups that people have reasonably opted into (i.e. Wikiprojects).
2. Newsletter bots must have a working opt-out mechanism, which is prominently displayed in the newsletters it delivers.

Why don't we come up with a standard opt-out mechanism for all bots to support, rather than having users remove themselves from 101 lists? — Werdna talk 02:49, 28 March 2008 (UTC)

newsletter bots should be opt-in. end of story. I run one and the groups who want newsletters normally have a subpage of the wikiproject with a /Recipients page or similar which I use, Also I dont really see enough activity/requests for this bot to see the need for more of them. β^_command 02:55, 28 March 2008 (UTC)

I agree. Either that, or people specify in the list of wikiproject participants whether they wish to recieve the newsletter or not. The second option is easier for the member because they only have one page to edit when they join.-- maelgwn - talk 04:15, 28 March 2008 (UTC)

What's the difference with using {{bots}}? Can't you simply use that to opt-out? --Erwin85 (talk) 09:22, 28 March 2008 (UTC)

Does that support opting out of some newsletters but not others? On the face of it, opting in to the ones you want seems simplest and best. -M^ask? 08:56, 6 April 2008 (UTC)

Is there a general newsletter policy? I received a newsletter from a project I've never edited or joined. and when asked why, was told to add myself to their opt-out list. Is this a loophole in policy? MBisanz ^talk 09:13, 6 April 2008 (UTC)

Which bot, and where is that discussion? I don't remember any bot to receive approval for unsolicited newsletter delivery. MaxSem^{(Han shot first!)} 09:16, 6 April 2008 (UTC)

It was hand-delivered by Nothing444 (talk · contribs) for this issue, but from various talk conversation, I believe Wikipedia:Bots/Requests_for_approval#RyRyBot will be taking over once approved. MBisanz ^talk 09:25, 6 April 2008 (UTC)

NotifyBot

Could a BAG member request for User:NotifyBot be flagged so I can switch the BJBot task 4 over to that account? BJ^Talk 02:19, 8 April 2008 (UTC)

done. Have fun. - Taxman ^Talk 13:49, 8 April 2008 (UTC)

What NFCC bots are running, and what messages do they leave?

In the aftermath of BetacommandBot, I'd like to make sure that future bots that work on image copyrights leave messages that are written in plain English, are comprehensible to all users, and do not require understanding of Wikipedia jargon. I think many of the problems surrounding the bot could have been avoided if the bot had given mere mortals an idea of what to do next.

This is particularly an issue around NFCC 10c, which (as it is currently enforced) is a highly nitpicky requirement that does not make sense to most users. I am not proposing to change the way we enforce the requirement now, but for the users affected by it, a clear explanation of what to do is essential.

Are there any bots currently running that enforce 10c? What about other criteria? I would like to see what kind of messages they leave, and suggest improvements if necessary.

(Important note: I am not saying this to attack Betacommand. I am offering to improve Wikipedia and avert future conflicts. I see that Carnildo got quickly shown the door when he offered to fix BCB's jargon, so I want to make absolutely sure this is not seen a personal issue. Regardless of what you think of Betacommand, this is something that needs to be done.)

rspeer / ɹəədsɹ 03:43, 31 March 2008 (UTC)

FairuseBot will be using the message User:OrphanBot/nfcc10c when it starts enforcing 10c. It's not easy writing a message that is short enough that people will read it, specific enough that it mentions the exact problem, and generic enough that following the bot's instructions doesn't lead to silly results. --Carnildo (talk) 07:34, 31 March 2008 (UTC)

That's fairly straightforward. I'd propose adding a paragraph for what seems to be, by far, the most common problem:

If you have already added a rationale, please make sure that it includes the exact title of the article where the image is used; if you typed a slightly different title, this bot will not be able to find the rationale.

Wording is up for discussion, of course. rspeer / ɹəədsɹ 02:22, 1 April 2008 (UTC)

The title doesn't need to be exact. FairuseBot is capable of following redirects or disambiguation pages to get to the article, and will update links as needed. --Carnildo (talk) 04:20, 1 April 2008 (UTC)

Finally, a bot that handles disambigs! MBisanz ^talk 04:33, 1 April 2008 (UTC)

That's great to hear. Following disambiguation pages will help a lot. But the bot will still flag non-exact matches that people wouldn't -- such as if the user typoes the article name, or if they refer to it under a similar name that has no redirect or disambiguation page -- so I still think this is going to be a common case that the bot message should acknowledge. As an example, BCB just tagged a radio program logo used on WYND-FM that only mentioned that it was used on "WYND", and the person who came along and fixed it was as pissed off at BCB as is usual in these cases. rspeer / ɹəədsɹ 19:32, 3 April 2008 (UTC)

Rspeer, please note that that edit in question was made from a indef blocked sockpuppeting user that harassed several users. β^_command 18:33, 5 April 2008 (UTC)

I'm trying to see why that would be relevant to this conversation. What do you want me to conclude based on that? That a trolling sockpuppeteer understands image licensing better than your bot? That nobody should be upset when bots leave messages that suggest they are infallible, in cases that reveal that they're not, unless they are a troll? This is an implementation issue with image bots in general, and I don't see how another user's personal behavior diminishes the issue in any way. rspeer / ɹəədsɹ 04:44, 7 April 2008 (UTC)

I'm trying to get a reasonably comprehensive list at Wikipedia talk:BAG#Image bots (I know, wrong location...). Not just NFCC bots, but any bots or people using scripts, or people doing high-volumes of image work, or indeed anyone leaving templates that are, ahem, raising hackles. User:MECU is an example. See the large warning signs at the top of the talk page (a trait common to all people doing high volumes of image work, it seems) and our (productive) exchange at User talk:MECU#Why not gather people together to add sources? I'm also currently trying to get better co-ordination of all the people doing image work, or at least those doing high-impact image work (large volumes of uploading or large volumes of tagging or large volumes of deletion or large volumes of fixing). I've left a note for Carnildo so far, but no-one else yet (I'm not really organised yet), but would appreciate any ideas for a name for a central co-ordinating page. Should it be centred around a Wikipedia: page or a Wikipedia:WikiProject... page? Are there any image WikiProjects around? Carcharoth (talk) 10:29, 3 April 2008 (UTC)

Are you sure your really Wolfie? The real Carcharoth would certainly know about Wikipedia:WikiProject Fair use. MBisanz ^talk 15:38, 3 April 2008 (UTC)

Would you like to see my very sharp teeth to prove my identity? :-) Anyway, that's one image WikiProject. I vaguely remember it. I only recently found Wikipedia:WikiProject Image Monitoring Group. Are there others? Note that I'm not just talking about fair use/non free images, but any image projects at all. I also found Wikipedia:WikiProject Moving free images to Wikimedia Commons. I suppose what I did at WP:NFCC-C is an attempt at something similar, but more focused on compliance methods. Anything else? I suppose Wikipedia:Graphic Lab can be considered a WikiProject of sorts, or more a "service". Any others? Carcharoth (talk) 15:59, 3 April 2008 (UTC)

I notice that BetaCommandBot is still tagging images, and leaving the same old red-boxes-o-jargon that it always has. Now that other bots are doing a better job, with more comprehensible messages, do we really want this? rspeer / ɹəədsɹ 18:31, 5 April 2008 (UTC)

Apparently this is being discussed somewhere else, but I can't find it. BAG people, where are these pages where you're making big sweeping changes to bot policy? rspeer / ɹəədsɹ 16:38, 16 April 2008 (UTC)

Changing BCBot was done at WT:BAG, changing bot policy at WP:BOT. --uǝʌǝsʎʇɹoɟʇs(st47) 18:11, 16 April 2008 (UTC)

Betacommandbot tasks

I've just been looking at the contributions of betacommandbot, after seeing an edit on another page. After looking at the last 500 contributions, I couldn't see a single edit which was a task approved by the bot approval group. Is this whole thing just a joke? 207.47.37.6 (talk) 15:46, 26 April 2008 (UTC)

Please explain, I have approval for what BCBot does. β^_command 15:47, 26 April 2008 (UTC)

Dead bots

For bots that are inactive for very long periods of time (year+) should they be de-flagged? Not as much of an issue as with admin accounts left laying around, but it would seem to be simple housekeeping. MBisanz ^talk 08:57, 7 March 2008 (UTC)

Sounds like a good idea. We fire stewards for inactivity, why not bots.

Geoff Plourde (talk) 16:06, 7 March 2008 (UTC)

Sounds reasonable. I'd go with shorter... maybe 6 months? SQL^{Query me!} 16:12, 7 March 2008 (UTC)

we just cleared some of them out not too long ago. β^_command 17:21, 7 March 2008 (UTC)

Bot list

(ec)Ok these are the ones I ID' to start with as not having been active since at least 01/01/2007

1. AFD Bot (talk · contribs)-notified March 6, 2008-deflagged
2. LinkBot (talk · contribs)-notified March 6, 2008-deflagged
3. NotificationBot (talk · contribs)-notified March 6, 2008-deflagged
4. Pending deletion script (talk · contribs) (Dev bot, requires Tim Starling's approval)-notified March 6, 2008-deflagged
5. Portal namespace initialisation script (talk · contribs) (Dev bot, requires Tim Starling's approval)-notified March 6, 2008-deflagged
6. StubListBot (talk · contribs)-notified March 6, 2008-Flag removed De-flagged by user request. SQL^{Query me!} 07:06, 8 March 2008 (UTC)
7. VandalCountBot (talk · contribs)-notified March 6, 2008
8. Wikipedia Signpost (talk · contribs) (userpage notes it is still a bot)
9. ZsinjBot (talk · contribs)-notified March 11, 2008 - deflagged
10. Zbot370 (talk · contribs)-notified March 11, 2008 - deflagged
11. YurikBot (talk · contribs)-notified March 11, 2008
12. XyBot (talk · contribs)-notified March 11, 2008
13. Whobot (talk · contribs)-notified March 11, 2008
14. ABot (talk · contribs)-notified March 11, 2008 - I plan to start up again once I can find the time – ABCD✉ 01:36, 13 March 2008 (UTC)
15. Beastie Bot (talk · contribs)-notified March 11, 2008 - I plan to start this one up again when I have time —Pengo 07:02, 11 March 2008 (UTC)
16. BenjBot (talk · contribs)-notified March 11, 2008
17. Bgbot (talk · contribs)-notified March 11, 2008 - deflagged
18. Chris G Bot 2 (talk · contribs)-notified March 11, 2008 - still active, just some obscure problem with staying logged in --Chris 08:06, 11 March 2008 (UTC)
19. CrazynasBot (talk · contribs)-notified March 11, 2008
20. CricketBot (talk · contribs)-notified March 11, 2008-User intends to keep active
21. Danumber1bot (talk · contribs)-notified March 11, 2008
22. Dark Shikari Bot (talk · contribs)-notified March 11, 2008
23. DarknessBot (talk · contribs)-notified March 11, 2008
24. DinoBot (talk · contribs)-notified March 11, 2008 - don't de-flag
25. DisambigBot (talk · contribs)-notified March 11, 2008
26. Elissonbot (talk · contribs)-notified March 11, 2008-staying active
27. Eybot (talk · contribs)-notified March 11, 2008-deflagged
28. Fetofsbot (talk · contribs)-notified March 11, 2008-deflagged
29. Fetofsbot2 (talk · contribs)-notified March 11, 2008-deflagged
30. Fritzbot (talk · contribs)-notified March 13, 2008-deflagged
31. Gdrbot (talk · contribs)-notified March 13, 2008 — I may use it again some time. Gdr 10:18, 13 March 2008 (UTC)
32. Geimas5Bot (talk · contribs)-notified March 13, 2008
33. Grammarbot (talk · contribs)-notified March 13, 2008
34. GrinBot (talk · contribs)-notified March 13, 2008 – The code sits there, and I may use it someday, but waits for its new server. I'd keep the flag for now. -grin ✎ 10:00, 28 March 2008 (UTC)
35. Halibott (talk · contribs)-notified March 13, 2008
36. Heikobot (talk · contribs)-notified March 13, 2008 - I still have the plan to use it. Heiko Evermann. 85.177.140.123 (talk) 17:39, 14 March 2008 (UTC)
37. IW-Bot-as (talk · contribs)-notified March 13, 2008
38. Janna (talk · contribs)-notified March 13, 2008-please keep the flag so I get the higher limits on the API
39. JdforresterBot (talk · contribs)-notified March 13, 2008-keep active
40. JoeBot (talk · contribs)-notified March 13, 2008 - Should be deflagged. It was a semi-automated spellcheck bot made to distract myself from finals through procrastination. 25k edits later, I still somehow managed a good grade. Funny to look back on it now. Anyways, I'll probably never run it again, there are better projects out there right now doing that job more efficiently. JoeSmack ^Talk 12:05, 13 March 2008 (UTC)-deflagged
41. KevinBot (talk · contribs)-notified March 13, 2008-deflagged
42. Kurando-san (talk · contribs)-notified March 13, 2008-keeping active
43. KyluBot (talk · contribs)-notified March 13, 2008 - Currently used to read pages, MedCab bot functions have yet to be needed as the current bot for the function is stable. ~Kylu (u|t) 13:11, 13 March 2008 (UTC)
44. M7bot (talk · contribs)-notified March 13, 2008 - Should be deflagged. I'll probably never run it again. --M/ (talk) 12:17, 13 March 2008 (UTC)-deflagged
45. Mairibot (talk · contribs)-notified March 13, 2008
46. MarshBot (talk · contribs)-notified March 13, 2008-deflagged
47. MBot (talk · contribs)-notified March 13, 2008
48. MichaelBillingtonBot (talk · contribs)-notified March 13, 2008-staying active
49. MoriBot (talk · contribs)-notified March 13, 2008 - may be deflagged, no plans for bot-activity.. Moribunt (talk) 09:03, 1 May 2008 (UTC)
50. N-Bot (talk · contribs)-notified March 14, 2008
51. NekoDaemon (talk · contribs)-notified March 14, 2008-keeping active
52. Nobot (talk · contribs)-notified March 14, 2008
53. NohatBot (talk · contribs)-notified March 14, 2008-keeping active
54. NTBot (talk · contribs)-notified March 14, 2008
55. Pearle (talk · contribs) - Keeping active
56. Peelbot (talk · contribs)-notified March 14, 2008-deflagged
57. Pfft Bot (talk · contribs)-notified March 14, 2008
58. PlangeBot (talk · contribs)-notified March 14, 2008
59. Planktonbot (talk · contribs)-notified March 14, 2008
60. PoccilScript (talk · contribs)-notified March 14, 2008
61. Rambot (talk · contribs)-notified March 14, 2008 (I plan to use this for an approved task in a couple years. See my post below. -- RM 21:23, 20 March 2008 (UTC))
62. RBSpamAnalyzerBot (talk · contribs)-notified March 14, 2008-deflagged
63. RoboDick (talk · contribs)-notified March 14, 2008
64. RobotE (talk · contribs)-notified March 14, 2008 - deflagged
65. RobotJcb (talk · contribs)-notified March 14, 2008 - I'm planning to reactivate it within a few weeks, so please keep it flagged - Jcbos (talk) 14:07, 17 March 2008 (UTC)
66. RoryBot (talk · contribs)-notified March 14, 2008-deflagged
67. Selmobot (talk · contribs)-notified March 14, 2008
68. Sethbot (talk · contribs)-notified March 14, 2008
69. Sgeo-BOT (talk · contribs)-notified March 14, 2008
70. Werdnabot (talk · contribs)-notified March 14, 2008-Keeping active
71. Werdnabot (irc) (talk · contribs)-notified March 14, 2008-deflagged
72. Snobot (talk · contribs)-notified March 14, 2008
73. StatsBot (talk · contribs)-notified March 14, 2008
74. StefanBot (talk · contribs)-notified March 14, 2008-deflagged
75. Syrcatbot (talk · contribs)-notified March 14, 2008-deflagged
76. The Anomebot (talk · contribs)-notified March 14, 2008-deflagged
77. TheJoshBot (talk · contribs)-notified March 14, 2008-deflagged
78. Topjabot (talk · contribs)-notified March 14, 2008 Can be deflagged. --Gerrit ^CUTEDH 10:48, 14 March 2008 (UTC)
79. TPO-bot (talk · contribs)-notified March 14, 2008-deflagged
80. Vina-iwbot (talk · contribs)-notified March 14, 2008-keeping active

Comments

Do I grab a crat or SQL, will you grab them as a BAGer? MBisanz ^talk 17:22, 7 March 2008 (UTC)

I'm actually not a BAG'er, sorry... We'll need BAG to ok de-flags, before a crat does it... I'd suggest a note at WP:BOWN and/or WT:BAG, to try to grab some attn... SQL^{Query me!} 18:39, 7 March 2008 (UTC)

Might I suggest that before flags are withdrawn, operators are contacted if still active. It might be worth asking them if they still need a bot account, and when they are likely to use it again. People may be offended by flags being withdrawn without it being discussed with them first, and there's no great rush to do this. WjBscribe 19:05, 7 March 2008 (UTC)

Asked around, will wait a week or so for infrequent editors. And I'll start processing the entire list of flagged bots. Not a critical task, but still something I know I have the skills to do and needs to be done by someone. MBisanz ^talk 20:23, 7 March 2008 (UTC)

Need any help? Geoff Plourde (talk) 20:56, 7 March 2008 (UTC)

Thanks, I think I've got it set. Just checking through contrib pages, already 1/4 done. MBisanz ^talk 06:08, 8 March 2008 (UTC)

If anyone responds that they no longer need a flag, feel free to drop me a note on my talkpage and I'll remove it. WjBscribe 20:24, 7 March 2008 (UTC)

I don't intend to use Stublistbot, so go ahead. (For all I care, the whole concept of using stub templates can be abandoned, but that's a different story) Han-Kwang (t) 21:46, 7 March 2008 (UTC)

Thanks, I have removed the flag. WjBscribe 00:04, 8 March 2008 (UTC)

Ok I've processed all Bot flagged bots. There are 72 listed at User:MBisanz/Botlist#Inactive_bots_for_notification. I'll begin notifying them, but some have been dead since 2005, so I wouldn't hold my breath. MBisanz ^talk 07:13, 8 March 2008 (UTC)

Deflag Zbot370; it's blocked anyways. I blocked it since I lost the password and didn't want anyone to hijack that. User:Zscout370 ^{(Return Fire)} 06:46, 11 March 2008 (UTC)

Bgbot (talk · contribs) will stay inactive. You can freely take away its bot flag. — Borislav 08:11, 11 March 2008 (UTC)

ZsinjBot (talk · contribs) has been made obsolete, hence it's inactivity. I have no problem with its flag being removed. Zsinj^Talk 17:04, 11 March 2008 (UTC)

Thanks. Flags removed from Zbot370, Bgbot & ZsinjBot. WjBscribe 18:06, 11 March 2008 (UTC)

Thanks for the notification. CricketBot (talk · contribs) has been inactive for a while but might be revived when I have more time. I'll go with whatever the consensus is in that situation. Stephen Turner (Talk) 10:43, 12 March 2008 (UTC)

Thank you for the notification. While ABot (talk · contribs) has been inactive, I do mean to revive it once I have some more time. – ABCD✉ 01:36, 13 March 2008 (UTC)

Thank you MBisanz and co for chasing this up, and yes, LinkBot (talk · contribs) is inactive, and can be deflagged. If I do find I ever need to reactivate it again, I'll request that via the normal processes. -- All the best, Nickj (t) 04:47, 13 March 2008 (UTC)

Hey, thanks for the message. MichaelBillingtonBot (talk · contribs) is inactive because of an OS change, but will be operating again once I eventually get around to porting it. Cheers. --Michael Billington (talk) 09:11, 13 March 2008 (UTC)

Fritzbot (talk · contribs) can be deflagged. --Fritz S. (Talk) 09:22, 13 March 2008 (UTC)

Elissonbot (talk · contribs) has been inactive since I've been quite inactive (sadly), I would probably find chances to use it in the future again but I guess I could just reactivate it then. Go with whatever you find suitable. – Elisson • T • C • 12:43, 13 March 2008 (UTC)

Hey there! RBSpamAnalyzerBot (talk · contribs) is not flagged as far as I know. Ugh, it appears it was given a bot flag (I thought it wasn't). It can be deflagged, I don't have the resources to run him anymore. -- ReyBrujo (talk) 01:45, 14 March 2008 (UTC)

Thanks for responding, I have removed the flag. WjBscribe 01:51, 14 March 2008 (UTC)

You can deflag TheJoshBot (talk · contribs), as long as its status as being previously flagged is recognised, and it can get re-flagged easily when its needed for active service in the future. --TheJosh (talk) 03:36, 14 March 2008 (UTC)

I would prefer that NohatBot (talk · contribs) keep its bot status. If I leave the project with no intention of using the bot again, then I will request for its flag to removed at that time. Nohat (talk) 03:45, 14 March 2008 (UTC)

Please de-flag User:The Anomebot: I stopped operating it when I lost its password some time ago, and am currently operating through another more recent bot account. -- The Anome (talk) 07:09, 14 March 2008 (UTC)

Peelbot (talk · contribs) can be deflagged; if I decide to start it up again (which is a big if) it will probably be on a different task, hence can be reflagged during the request for approval process. Thanks. Mike Peel (talk) 09:04, 14 March 2008 (UTC)

I'm fine with TPO-bot (talk · contribs) being deflagged. Could you please add a note on the talk page when this is done. Thanks. --TheParanoidOne (talk) 13:50, 14 March 2008 (UTC)

StefanBot (talk · contribs) can be deflagged, will apply again if I ever make some a new bot code. --Stefan ^talk 14:22, 14 March 2008 (UTC)

Syrcatbot (talk · contribs) can be deflagged. I'm unlikely to do work with it again. Thx. Syrthiss (talk) 16:54, 14 March 2008 (UTC)

Thanks to those who have responded above. TheJoshBot, Anomebot, Peelbot, TPO-bot, StefanBot and Syrcatbot all deflagged. WjBscribe 18:58, 14 March 2008 (UTC)

JdforresterBot (talk · contribs) isn't unused, merely temporarily inactive. Given that it's job is to do editing on my behalf which isn't appropriate to claim as human editing (disambiguation, etc.), it would be best to keep its status. James F. (talk) 19:18, 14 March 2008 (UTC)

RoryBot (talk · contribs) can be deflagged, since to my knowledge its task is more or less complete, so if I decide to use it again I'd be going back to BRFA anyway. --Rory096 20:04, 14 March 2008 (UTC)

NotificationBot (talk · contribs) can be deflagged, as well as AFD Bot (talk · contribs). Please do not deflag Kurando-san (talk · contribs) and NekoDaemon (talk · contribs) as I will be revising the scripts over the next two weeks to get the two bots operable. --AllyUnion (talk) 21:29, 14 March 2008 (UTC)

Thanks. RoryBot, NotificationBot and AFD Bot now deflagged. WjBscribe 21:49, 14 March 2008 (UTC)

RobotE can be deflagged. It worked on interwiki, but I stopped it, because there are so many people working on that. Ellywa (talk) 12:39, 17 March 2008 (UTC)

Ok, done. Thanks for letting us know. If you'd like to use it again, you know where to request it of course. There are a lot, but they are still useful. - Taxman ^Talk 06:48, 22 March 2008 (UTC)

Werdnabot is now active again. Werdnabot (irc) can be deflagged. — Werdna talk 11:43, 22 March 2008 (UTC)

I wouldn't mind if both User:Fetofsbot and User:Fetofsbot2 were deflagged, as I don't intend in continuing their work anytime soon. If I ever continue, I'll request a flag again... fetofs ^Hello! 20:14, 29 March 2008 (UTC)

EyBot (talk · contribs) can be deflagged, I don't use it anymore for now :) EyOne (talk) 22:39, 1 April 2008 (UTC)

Vina-iwbot (talk · contribs) is now active again. -Vina (talk) 05:37, 7 April 2008 (UTC)

BoxCrawler

BoxCrawler (talk · contribs) has just malfunctioned for the second time in a few days, so I have blocked it: see User talk:BoxCrawler#Bot_is_broken.2C_so_it_is_blocked.

In each case, the errors seem fairly basic, so I suggest that a review of the bot might be appropriate (the operator may need some assistance). --BrownHairedGirl (talk) • (contribs) 00:32, 27 April 2008 (UTC)

For what is a pretty minor technical problem, a review is not necessary. There are no problems with the job the bot is doing, just a minor technical glitch. I am sure the operator will deal with this. -- maelgwn - talk 04:02, 27 April 2008 (UTC)

Thanks for stopping the bot but I think it was an overreaction. Just because the bot wasn't set up to pick out one specific shortcut does not mean the bot is malfunctioning, it works exactly as approved, and the only real changes have been in direct response to comments left for me. The block was unnecessary, a simple note on my talk page would have fixed the "problem." It's not a big deal and has been fixed. I'll also note that neither of these were "malfunctions," in both cases the bot worked flawlessly (The fault was mine the previous time), detecting this specific shortcut is an enhancement. Adam McCormick (talk) 05:42, 27 April 2008 (UTC)

I'll also note that the redirect in question ({{tl:WPSCHOOLS}}) was created in February 2008 by the blocking admin. It was the only redirect the bot did not detect and it has been adjusted. Adam McCormick (talk) 06:06, 27 April 2008 (UTC)

I recommend you put in a check for new redirects at bot start. That would avoid this problem permanently. -- JLaTondre (talk) 12:27, 27 April 2008 (UTC)

BrownHairedGirl, blocking for a single such edit is unnecessary. The better approach would have been to leave the operator a note first and request they fix the problem. Blocking is only needed when a bot is repeatably making the same mistake (making clean up difficult), the bot is damaging content (inappropriate removal, etc.), or the bot operator is non-responsive. While I'm sure you meant this post to help, I also don't think you needed to call into question the operator's competence in a public forum without first waiting for his response to your notice on his talk page.

As the operator has fixed the problem, I've unblocked. -- JLaTondre (talk) 12:27, 27 April 2008 (UTC)

The bot was making the mistake repeatably. Per the discussion on the bot's talk page, the bot-owner has confirmed that bot was being run on the false assumption that the list of redirects to {{WPSchools}} would remain static. Anyone can create a redirect to a template at any time, and it only takes a minute or so check the current list of redirects, even if the check is done manually As I do with User:BHGbot). The reason I posted here was because I was alarmed that such a basic check was not being done. --BrownHairedGirl (talk) • (contribs) 13:38, 27 April 2008 (UTC)

It only made one mistaken edit as can be seen by it's contribs. While it's possible the run would have resulted in more, it's also possible it wouldn't have depending upon what it was processing. A note to the operator on a single minor mistake is a better approach, in my opinion. If they are unresponsive, then block. You posted here prior to posting to the user's talk page. We all have our "oh, duh!" moments. That's hardly a cause for alarm unless the person is unwilling to recognize them when pointed out. A better approach than manually checking would be to use the API and generate the list at run time. -- JLaTondre (talk) 14:10, 27 April 2008 (UTC)

Yes it was possible it wouldn't have picked up any more false positives, but that depended on the scope of the bot run, and there was no indication on the bot's talk or user pages or in its edit summaries of the scope of the run, and every no reason to doubt to that this error early in the bot run would be repeated if the same issue was encountered again. As above, the block was preventive rather than punitive, and if the bot operator has taken on board the need to check for redirects, then the problem has been resolved. --BrownHairedGirl (talk) • (contribs) 14:43, 27 April 2008 (UTC)

I have already thanked you for blocking the bot as a preventative measure. My issue was that you blocked it indefinitely, which was not necessary to prevent anything, and thus does seem punative. Adam McCormick (talk) 19:21, 27 April 2008 (UTC)

If bots are malfunctioning, blocking is OK, though usually reserved for bots making significant errors. That being said, it is important to note that "indefinite" does NOT mean "infinite", temporary blocks are almost never used for malfunctioning bots--they are to be blocked until the error is resolved, then unblocked--as the blocked won't know when it will be resolved "indefinite" is the appropriate block length. — xaosflux ^Talk 11:19, 7 May 2008 (UTC)

I know what indefinite means. I have absolutely no issues with the fact that the bot was blocked. My only issue is that the only thing accomplished by blocking "indefinitely" as opposed to for an hour or even a day is that it wastes time. As I note on the bot's page even a short block will stop the bot, there is no need for the bot to be blocked longer than that. Either way the bot stops, either way I fix the problem, and either way the bot gets unblocked, but with an indefinite block I have to rely on an admin to unblock the bot which has, in the past, taken more than a day. It's a considerable inconvenience, and doesn't show any kind of good faith in me as a bot op. Adam McCormick (talk) 20:38, 7 May 2008 (UTC)

I'm sorry it took so long in the past, but there is no way for a blocked to know if your bot has seen the block and stopped, or just is no longer running (I suppose you could have it leave it's own {{unblock}} requests stating that it has ceased automated operations). Having your bot blocked shouldn't be taken as you being a bad operator, the process was blocked--not you as an editor. There are multiple channels to request unblocking, WP:AN, IRC, and a dedicated mailing list. From the notes above the unblock got turned around in 8 hours, and WT:BRFA is a fairly low volume page. FWIW, I wouldn't have blocked unless this error continued for multiple days without getting a talk page reply first, but that's my opinion only. — xaosflux ^Talk 02:51, 8 May 2008 (UTC)

A new bot

Hi, I was just wondering, is there a bot that automatically migrates images that have the "move to commons" tag on them (once checking for valid licensing etc) and would such a bot be rejected if put against the BAG? Because if the answer to both questions is no, then AtyndallBot is going to take that pathway as a bot (if no one has any objections).  Atyndall93 | talk  10:33, 23 May 2008 (UTC)

I think this task would require a fair bit of human judgement. Categorisation on Commons is fairly backlogged and a mass bot transfer wouldn't help. Not to mention the album covers tagged as {{PD-self}} that the bot would accidentally transfer. dihydrogen monoxide (H₂O) 10:35, 23 May 2008 (UTC)

Hmmm, do you have any suggestions for a niche that my bot could fill?  Atyndall93 | talk  10:38, 23 May 2008 (UTC)

There's plenty out there (not necessarily on Commons stuff though)... keeping WP:BOTREQ watchlisted always helps. dihydrogen monoxide (H₂O) 10:41, 23 May 2008 (UTC)

See WP:MTC β^{_{command 2}} 18:16, 23 May 2008 (UTC)

The redirection of a Wikipedia page to a user page seems intentionally misleading to readers and a the worst possible violation of wp:own I've ever seen. ("I am the State Wikipedia Guideline") --Lemmey talk 18:24, 23 May 2008 (UTC)

its fairly common practice. β^{_{command 2}} 18:31, 23 May 2008 (UTC)

Suggestions to improve communication with the non-bot community

Effective communication is important to running a bot. I've just experienced a bad bot episode where a series of communication failures summed to greater than the parts. The bot owner was surly and introverted - understanding things in his mind but unable to effectively communicate them. The complainer (me) wasn't looking at the same playing field as the bot owner, it took several hours to catch up. The bot's edit summaries were misleading or wrong. The tags the bot placed on image pages were sub-optimal or just plain wrong. The notes the bot placed on user talk pages were so misleading or wrong that they did more harm than good. It took a very long time for the non-bot person (me) to locate the bot's approvals and figure out exactly what this bot was supposed to be doing. I've done some automated tasks myself in the past and am sympathetic to bot owners, particularly to the regular abuse they reap. So please accept these suggestions in the positive light they are offered:

1. All bot userpages should link to all approvals, so non-bot people can quickly figure out exactly what the bot is supposed to be doing.
2. The Bot Requests for approval should include a review of the bot/editor interface.

   • Are the bot's edit summaries correct, do they communicate effectively? Or are they misleading or just plain wrong?
   • Is the bot placing the correct tags, or is it using tags that are kinda close, difficult to understand and classic tldr's?
   • Is the bot communicating effectively on the users talk pages, or is it placing a generic template that doesn't explain exactly what the problem is, for example; your image lacks a fair use rationale when it should read your fair use rationale needs an article link specifying the image usage.

3. Counseling - I didn't know this until a few minutes ago, but you have some very young bot owners. While these people might be technically proficient, it's perhaps unfair to expect them to be emotionally mature enough to run a project wide bot that makes controversial edits. The BAG group should aid these editors to communicate and resolve conflicts.

--Duk 17:46, 23 May 2008 (UTC)

Sigh, Good behavior is the remedy for bad behavior, not more policies, suggestions, approval boards, rules, and mediation groups. Furthermore I'm not immature, you're immature :). --Lemmey talk 18:12, 23 May 2008 (UTC)

I hear you - and good communication is the remedy for bad communication. Can you agree that bots should have accurate edit summaries and use accurate tags? Can you agree that a bot that taggs a user's page with; your image lacks a fair use rationale, when it should read your fair use rationale needs an article link specifying the image usage will cause trouble, is vague and misleading; and a bot owner who refuses to fix it is lazy? --Duk 18:33, 23 May 2008 (UTC)

Without seeing the image I can't say what the tag should have said. What I can say is that messages sent to users are generally preformatted catch all messages but still should be as appropriate as possible. Perhaps Bots that are intended to interact (tag user pages) with high volumes of users should have their message formats specifically posted in task approvals so others can review. These bots should probally also have their edit summaries formats reviewed for accuracy. --Lemmey talk 18:40, 23 May 2008 (UTC)

Edit count bot

Is it against the rules to create a bot that, kind of like what StatusBot did, reads a category of users (lets say for this example Category:Autoeditcount), creates subpages on its userpage for all its users, and instead of editing those pages with an Online/Offline thing, put an edit count on the page, updated every 3 hours or so? It would work by querying api.php or query.php at 3 hour intervals per user at about 30 second intervals.  Atyndall93 | talk  08:58, 25 May 2008 (UTC)

I doubt you can really justify it. StatusBot had a use (just) in helping people to write/collaborate on wikipedia. I'm not sure how this helps writing an encyclopedia. -- maelgwn - talk 09:58, 25 May 2008 (UTC)

Since when do bots have to be justified? --Lemmey talk 10:00, 25 May 2008 (UTC)

WP:BOT#Bot requirements: "In order for a bot to be approved, its operator should demonstrate that it: [...] is useful". MaxSem^{(Han shot first!)} 10:20, 25 May 2008 (UTC)

Useful is in the eye of the beholder. How useful is yet another archive bot? How does the Signpost help writing an encyclopedia? I contend that it and the bots that distribute it are largely useless. Why useful as opposed to just not harmful, were not worried about WP:Perf here. --Lemmey talk 10:34, 25 May 2008 (UTC)

You could probably write something up in javascript to do this. --Chris 10:25, 25 May 2008 (UTC)

(outdent) So whats the final verdict? Should I try to make such a bot and but it before the BAG? And Chris G, how could this be implemented in javascript?  Atyndall93 | talk  10:56, 25 May 2008 (UTC)

You may want to consider all the flack Betacommand has gotten recently over the edit count list he has generated. Dbiel ^(Talk) 12:41, 25 May 2008 (UTC)

I hadn't head about that. Were did this happen? sounds like an interesting read. In all truth, I want to make a bot. I don't care what it does (as long as it is within the realms of PHP, possibility and my ability), I just want to have the satisfaction of thinking "I made this, and it is helping Wikipedia". But everything a have thought of so far is either impossible, not allowed or already done, its very annoying.  Atyndall93 | talk  13:08, 25 May 2008 (UTC)

STBotI

Copied from User talk:Werdna

Hi Werdna, it seems my breath is no longer being wasted and the conversation is moving forward. Let me repeat that the reason I'm bothering you is that I saw your name at the approval checkmark for STBotl, and the bot's owner was uncooperative. I don't know the hierarchy or workings of the Bot Approval Group, so if I'm barking up the wrong tree, let me know, please.

First, here are some quotes from WP:B;

• In order for a bot to be approved, its operator should demonstrate that it: ... uses informative messages, appropriately worded, in any edit summaries or messages left for users.
• Good communication: Users who read messages or edit summaries from bots, will generally expect a high standard of cordiality and information, backed up by prompt and civil help from the bot's operator if queries arise. Bot operators should take care in the design of communications, and ensure that they will be able to meet any inquiries resulting from the bot's operation cordially, promptly, and appropriately. This is a condition of operation of bots in general.

So here are just a few small things (to start) that STBotl could do better:

1. STBotI failed to identify a fair use rationale here. That is a mistake. Compare it with this image, also a written rationale instead of the template rationale, where the bot succeeded. The bot should have left the same set of templates on both examples, but it didn't. Please note clearly, I'm not saying that the rationale in the first example is sufficient, it isn't, it lacks an article link, even though the copyright tag has a rationale and article link. I'm merely saying that the bot missed the rationale all together and that is a mistake. Also, regarding the prior section on your user page, please note that this bot does seem able to identify non-templated rationales (usually).
2. STBotI at this image

   a) bloated tags: Between the edit summaries and the image page and user talk tags, the editor has to read over 3,000 characters - that's 500 words - to uncover a single small WP:NFCC#10c link. That's more that twice the size allowed for Wikimedia board candidate statements! [3] Even experienced users will have trouble deciphering that they merely need to add an article link to the rationale. Fewer words, more clarity, let the actual problem, WP:NFCC#10c, stand out and be visible.

   b) misleading edit summaries.Instead of "This image has no valid rationale", which will trip up and slow down most users, the edit summary could read something like "This fair use rational needs an article link to be valid".

   c) poorly written tags: the template on the user page in particular should have a section heading that clearly identifies the problem instead of mindlessly shouting "Disputed". How about something like "An image you uploaded needs its rationale updated"

Please note that in addition to cooperative bot owner behavior, the Bot Policy places a high emphasis on accurate edit summaries and good communication. STBotl currently fails all three of these requirements. --Duk 16:02, 26 May 2008 (UTC)

Copied from my discussion page for wider input. Without having done extensive investigation, it seems to be that Duk is right on all but the first point. — Werdna talk 07:33, 27 May 2008 (UTC)

What's wrong with the first point? rspeer / ɹəədsɹ 08:37, 27 May 2008 (UTC)

Without expressing an opinion as to how this relates to actual NFCC policy, I would say that the lack-of-article-link here would be what Werdna refers to. dihydrogen monoxide (H₂O) 08:42, 27 May 2008 (UTC)

DinoBot2

Could one of you BAG admin types please block this bot? The user is failing to observe approval procedure ... -- maelgwn - talk 00:01, 5 June 2008 (UTC)

Section blanking bot

Please, please, please can we have a bot that detects, flags, and ideally reverts sectional blanking of an article. It is highly disruptive and flies under the radar until someone familiar with the article happens along and/or checks their watchlist. - RoyBoy 12:46, 8 June 2008 (UTC)

If its not already picked up by the anti-vandal bots, there's probably too many issues with false positives. Mr.Z-man 16:28, 8 June 2008 (UTC)

While that may be true, it shouldn't be difficult to at least flag an anon who deletes multiple sections in a row. - RoyBoy 03:38, 10 June 2008 (UTC)

Source Code

Are there any bots about that I can view their coding? Just out of curiosity, to see if I can decifer (sp?) it and see how it works? ← κεηηε∂γ ^(talk) 15:46, 2 June 2008 (UTC)

The source code for pywikipediabot and the DotNetWikiBot are both available, and form that basis for most of the bots used here. There is other bot source code out there as well--T-rex 16:07, 2 June 2008 (UTC)

Thanks for that. I assume your first link is meant to be: pywikipediabot instead of this: [4] ← κεηηε∂γ ^(talk) 09:45, 3 June 2008 (UTC)

Also: User:ClueBot/Source, User:ClueBot II/Source, User:ClueBot III/Source, User:ClueBot IV/Source, and User:ClueBot VI/Source -- Cobi^(t|c|b) 14:32, 3 June 2008 (UTC)

If you're interested in Perl, the code for my bots is available variously at User:OrphanBot/libPearle2.pl, User:OrphanBot/libBot.pl, User:OrphanBot/orphanbot.pl, User:OrphanBot/tagbot.pl, User:FairuseBot/Pearle.pm, User:FairuseBot/libBot.pm, User:FairuseBot/10c-removal.pl, and User:FairuseBot/10c-removal.pl. The code's mostly out-of-date and sometimes non-functional, but it's a good starting point for figuring things out. --Carnildo (talk) 20:20, 3 June 2008 (UTC)

Thanks for that too. ← κεηηε∂γ ^(talk) 09:10, 16 June 2008 (UTC)

And the AWB source is freely available too - https://autowikibrowser.svn.sourceforge.net/svnroot/autowikibrowser —Reedy 13:40, 16 June 2008 (UTC)

Bulk page downloading

I need to bulk download pages from Wikipedia for statistical purposes (in particular, getting a case-sensitive letter frequency count that includes digits). Do I have request approval if I automate downloading many pages at once? --74.210.110.25 (talk) 20:58, 25 June 2008 (UTC)

Don't crawl, download a complete dump instead. MaxSem^{(Han shot first!)} 21:02, 25 June 2008 (UTC)

Ah, that method is much better. Although it seems the current dump is truncated. I'll try to find an older version then. --74.210.110.25 (talk) 22:45, 25 June 2008 (UTC)

this might be useful. β^_command 22:51, 25 June 2008 (UTC)

Re-examination of approval and flagging of Alexbot

Following continued running of unapproved tasks despite the given warnings and mentions to only run Approved tasks, I'd like to open an reexamination of the approval and flagging of Alexbot. Q ^{T C} 04:10, 1 July 2008 (UTC)

Alexbot is currently blocked, and has requested an unblock. Is there a pending request to approve the double redirect fixing that I am unaware of, or are there only the two existing requests? UltraExactZZ ^Claims ~ Evidence 13:14, 1 July 2008 (UTC)

I only request two times. interwiki is approved, but DR is not because I make too much edits. The double redirect fix....I think I forget let my batch file without enwiki (I use a batch file to clean DR in some flagged wikis).--Alexbot operator Alex S.H. Lin 13:23, 1 July 2008 (UTC)

Seems like a simple mistake. Overlord, I'm not seeing any warnings on this user's talk page, would they have been posted elsewhere? Maybe his talk page at zh? UltraExactZZ ^Claims ~ Evidence 13:37, 1 July 2008 (UTC)

It had been explicitly stated in both BRFA's to only run approved tasks. In addition this is the second block to occur from running un-approved tasks. I'd think doing it twice moves it out of the realm of accidents. Q ^{T C} 00:36, 2 July 2008 (UTC)

Agreed, per my subsequent comments, below. UltraExactZZ ^Claims ~ Evidence 12:48, 2 July 2008 (UTC)

The linked to edit doesn't actually fix a double redirect --T-rex 14:29, 1 July 2008 (UTC) explained below --T-rex 19:52, 1 July 2008 (UTC)

I've also noticed that there have been some edits fixing wiki syntax, such as this and this. A minor change, to be sure - but not an approved bot task for this bot, either. UltraExactZZ ^Claims ~ Evidence 16:34, 1 July 2008 (UTC)

Yes, it did. If you look at the history of the target, U.S. Route 27 Alternate (Florida), it was redirected to Bannered routes of U.S. Route 27 at the time the bot made the change. However, the redirect was subsequently reverted. -- JLaTondre (talk) 17:02, 1 July 2008 (UTC)

I blocked the bot for tagging dead redirects for deletion (a task never requested or approved) and only later saw the double redirect edits. Admins you can check the deleted contribs to see what I'm talking about. BJ^Talk 19:28, 1 July 2008 (UTC)

And, there they are. I'm Sorry, Alex, but I'm counting three unapproved tasks, including one (Tagging for deletion) that uses an english-specific template (The Chinese Wikipedia, for example, uses a template:d with an argument for the Speedy Criteria). It sounds like more than accidentally leaving en.wiki on the list of wikis on which to run certain tasks. So, though I'm not as up-to-speed on bots as I should be, I'm a little concerned. UltraExactZZ ^Claims ~ Evidence 12:47, 2 July 2008 (UTC)

Can I have a chance? I'm preparing to make some works' RBA.No matter these works approved or not, if community unblock my account, I will just do approval works If I need to test some codes, I will make RBA.--Alex S.H. Lin 18:58, 6 July 2008 (UTC)

I would want your iron-clad committment not to run the bot AT ALL for any purpose other than those purposes that are approved by the appropriate Bot Requests for Approval, and to limit - for now - your edits even to approved tasks. Show us that you can operate the bot properly, and I do not believe anyone will object. I think you are sincere in your intent to run the bot properly, and that these were good-faith screw-ups, and the language barrier does not help, so I'm inclined to give you another chance, if the BAG is as well. But, as I cautioned you earlier, if your bot is unblocked, any further unapproved tasks would be grounds for an indefinite block. Comments? UltraExactZZ ^Claims ~ Evidence 14:31, 7 July 2008 (UTC)

I agree that this is the best course of action. If the bot is unblocked it is imperative that the operator demonstrate willingness to stick to approved actions and edits. Adam McCormick (talk) 02:35, 9 July 2008 (UTC)

Flagged bots to edit protected

• Wikipedia:Village pump (proposals)#Flagged bots to edit protected

This was a notification, please respond at the VP. Have a nice day. -- Cat ^chi? 17:42, 10 July 2008 (UTC)

Template:OperatorAssistanceNeeded

According to Template:BAG Tools, {{OperatorAssistanceNeeded}} is supposed to cause a bot to send a notification to the operator. However, User:BAGBot hasn't touched a user talk page in several months and User:SoxBot IX only made 2 notifications earlier this month. Given the current pileup in approved-for-trial bots, we really need to investigate what's happening to notifications and perhaps increase the amount of notifications made by a bot. Mr.Z-man 21:32, 19 July 2008 (UTC)

<sarcasm>/me votes to block the malfunctioning bot</sarcasm> —Reedy 21:40, 19 July 2008 (UTC)

Wikipedia:Bots/Requests for approval/SharkDBot closed too early

I feel that Wikipedia:Bots/Requests for approval/SharkDBot was closed way too early. I was given a whole 8 minutes to respond to a comment that was clearly filled with overblown statements. I would feel better if the topic were left open for a while longer to solicit further comments. Anyway, a response to the comments is warrented, as I feel they were filled with inaccuracies. SharkD (talk) 17:51, 23 July 2008 (UTC)

The bot quite clearly fails the "does not consume resources unnecessarily" requirement. Leaving the request open longer won't change that. --Carnildo (talk) 19:53, 23 July 2008 (UTC)

Would you care to explain why that is? It's no more wasteful than {{flag}}, a related template with similar scope. SharkD (talk) 20:28, 23 July 2008 (UTC)

Upon closer inspection, I think I can get {{flag}} to do what I want. The bot may no longer be needed. SharkD (talk) 21:05, 23 July 2008 (UTC)

User:Andrwsc seems to have anticipated me. The bot edits, as well as the template, will no longer be needed. SharkD (talk) 23:20, 23 July 2008 (UTC)

AWB and fixes

My bot is currently approved for the tasks listed here. I use AWB to run my bots. Since my first task got approved, I've turned off all of the "General" options listed here. While I'm doing approved tasks #1, #4, and #5 am I allowed to have the Apply general fixes option in AWB checked? Or would that require a new task request? If it would require a new task request, I may hold off, because it isn't that big of a deal. But, if I can turn it on without a new request, it would help clean up the articles a bit while doing the main task.--Rockfang (talk) 03:47, 31 July 2008 (UTC)

No, you can not run with general fixes on. Any requests would be speedy denied. BJ^Talk 03:57, 31 July 2008 (UTC)

Thanks for the info. I figured that was the case, just wanted to make sure.--Rockfang (talk) 04:22, 31 July 2008 (UTC)