Misplaced Pages

talk:Bot policy: Difference between revisions - Misplaced Pages

Article snapshot taken from[REDACTED] with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 01:28, 12 May 2008 editAl tally (talk | contribs)Rollbackers2,553 edits Eliminate bot approval entirely: reply← Previous edit Latest revision as of 12:34, 19 January 2025 edit undoLowercase sigmabot III (talk | contribs)Bots, Template editors2,311,942 editsm Archiving 1 discussion(s) to Misplaced Pages talk:Bot policy/Archive 30) (bot 
Line 1: Line 1:
{{shortcut|WT:B}}
{{notice|'''This is not the place to request a bot, request approval to run a bot, or to complain about an individual bot''' {{notice|'''This is not the place to request a bot, request approval to run a bot, or to complain about an individual bot'''
* To request that a bot be created, see ''']'''. * To request that a bot be created, see ''']'''.
* To request approval to run a bot, see ''']'''. * To request approval to run a bot, see ''']'''.
* To report malfunctioning bots, follow the advice in ''']'''.
* Bot operators should be contacted at their user discussion page. If a bot appears to be malfunctioning and the operator does not respond, contact an administrator.
* To discuss something else bot-related, see ''']'''.
}} }}
{{Talk header|WT:BOTPOL|search=no}}
{| class="infobox" width="270px"
{{Policy-talk}}
|-
{{Press
!align="center" colspan="2"|]<br/>]
| subject = policy page
----
| author = Robert Gorwa
|-
| title = Twitter has a serious bot problem, and Misplaced Pages might have the solution
| ]
| org = ]
| ]
| url = https://qz.com/1108092/twitter-has-a-serious-bot-problem-and-wikipedia-might-have-the-solution/
|-
| date = 23 October 2017
| ]
| accessdate = 2017-10-23
| ]
}}
|-
| ] {{Misplaced Pages:Bots/ArchiveBox}}
| ]
|-
| ]
| ]
|-
| ]
| ]
|-
| ]
| ]
|-
| ]
| ]
|-
| ]
| ]
|-
| ]
| ]
|-
| ]
|-
|colspan="2"|
----
|-
|align="center" colspan="2"|]
----
|-
|align="center" colspan="2"|]
----
|-
|align="center" colspan="2"|] (also some approvals for interwiki bots)
|}<!--Template:Archivebox-->
{{User:MiszaBot/config {{User:MiszaBot/config
|maxarchivesize = 150K |maxarchivesize = 150K
|counter = 19 |counter = 30
|minthreadsleft = 4
|minthreadstoarchive = 1
|algo = old(21d) |algo = old(21d)
|archive = Misplaced Pages talk:Bot policy/Archive %(counter)d |archive = Misplaced Pages talk:Bot policy/Archive %(counter)d
}} }}


== Moving forward == == Open source bots ==

It is very noticeable how quickly this page lapses from frantic and heated debate back into quiet obscurity. It seems clear that the sweeping changes to the RfBAG process suggested by Coren have not thus far gained consensus as a complete package. But it would be a great shame to lose all the valuable talking points that the experiment has raised to the habitual apathy that surrounds ]. So while there's clearly currently no consensus to implement the RfA-style RfBAG in its entirety, I don't think it's fair to say that the proposal is completley dead, and I'd be interested to hear people's thoughts on indivdual issues like the ones below. <font color="forestgreen">]</font>‑<font color="darkorange">]</font> 15:26, 5 May 2008 (UTC)

===Is the current RfBAG process even broken?===

I for one think that it is: The four RfBAG nominations we have closed have more contributions than ''all'' the nominations that have occured at ], past and present, successful and not. I was genuinely shocked to see that Coren had been first appointed to BAG based on a discussion with only '''''two''''' comments in it. Levels of insularity like that (contributions from existing BAG members made up an average of almost 70% of comments at the WT:BAG nominations for Werdna, Soxred93, Cobi and Coren) are (IMO) the root cause of the community's legitimate accusations of cabalism and isolation. There are some more interesting statistics at ] if you're interested in that kind of thing. But I'm interested to hear what other bot operators think (it's unlikely we'll see anyone else at this page, but if you do happen to wander in I'd be particularly interested in non-bot-operator opinions). <font color="forestgreen">]</font>‑<font color="darkorange">]</font> 15:26, 5 May 2008 (UTC)
: I've noted on MZMcBride's RfBAG nomination that I feel the old method is simply not widely enough advertised. A single line on AN is easily missed. There is a certain amount of outright hostility from current members of the BAG to the listing on RFA, but I think that if you compare the nomination types, that the difference in consensus-building is clear. Perhaps a hybrid method, with a notification of the listing on the RFA page, and a listing on WT:BAG would be a compromise? ] (]) 15:52, 5 May 2008 (UTC)
:If by "current" you mean the long standing method of placing nominations at ] and closing them after a relatively short time, then yes, it's broken. BAG needs as much outside community input as possible to remain objective and to avoid issues of cabalism. While I'm no fan of RFA, in the absence of a better method, I think that's our best hope for getting the community involved. —] • ] • ] 07:32, 6 May 2008 (UTC)

===What went wrong with the RfA-style RfBAG?===

I have to say I wasn't very impressed with the process-protest votes on Coren's RfA-style RfBAG, but it didn't affect the result, so no harm done. I do think the RfA-based process has some legitimate concerns, which of course mirror the criticims of RfA itself. But in terms of increasing community involvement in the BAG and BRFA processes, I would personally consider it a success: an average of only 29% contributions from bot operators, and less than 10% from BAG (the four corresponding WT:BAG nominations, by contrast, didn't have a single non-bot-operator contribution between them). We've all heard the arguments and opinions for and against the RfA-based process, so no need to rehash them here; but what conclusions can be drawn ''from this experiment'' that are relevant to the question of how to appoint BAG members? <font color="forestgreen">]</font>‑<font color="darkorange">]</font> 15:26, 5 May 2008 (UTC)
:] is a perfect example of how screwed up RfA style elections are. the user in question has support but no experiance with the bot approval process. right now its about 66% approval, which is in the bcrat discression range. if Ilmari gets elected it will be a discrace. ] 16:09, 5 May 2008 (UTC)
::One of the continuing complaints (whether its true or not) about the BAG is that the members tend to be coding gurus, but distinctly subpar when it comes to communication, understanding community norms and consensus building. I think that there are quite a lot of people who would like to see some new members of the BAG who are stronger in the communication stakes, even if it means being weaker on the coding side. Understandably, this view has not met with great support within the current BAG. In the particular case you mention, it is a user who is a mediawiki developer, en-administrator and sometime bot operator. It is far from clear to me that the user is fundamentally unqualified, although I also initially opposed. I would not directly support Ilmari's application, but I think that the wider community has other minimum standards, particularly regarding communication, than does the traditional BAG member. ] (]) 16:27, 5 May 2008 (UTC)
:::I dont think programming skills are required, but being previously active in BRFAs are. you obviously have zero clue about bots or how they should be run. being active in BRFA is required to be a member of BAG. The community should have standards of experiance with bot related matters, if they dont that is a problem. ] 16:55, 5 May 2008 (UTC)
::::I would encourage you to re-read your comment and think about whether it reaches the community minimum standard for communication skills.] (]) 07:04, 6 May 2008 (UTC)
:::Some think BAG should only review the technical side of bots. I think BAG should not merely make a technical review, but should also determine if a task has consensus and complies with other non-bot policies. BAG doesn't deny spellchecker bots simply due to technical weaknesses of some script. As far as I'm concerned, someone with a wide knowledge of policy is welcome on BAG without any coding skills. However, there are precedents at bot approvals that BAG members ought to know about, and the way to learn those is to participate for a while before trying to join BAG. Anyone is welcome to comment on a BRFA. Someone who does that for a few months is likely to get support from the existing BAG should they desire to join it. ] 20:01, 5 May 2008 (UTC)
::::This presupposes that the support of the existing BAG is a desirable precondition in the case where there has been considerable community dissatisfaction with the current operating procedure. I think that the optimum would be more community input on bot approvals, but in the absence of that, community representatives on the BAG. ] (]) 07:04, 6 May 2008 (UTC)

===Closing RfBAGs===

It has been suggested that, wherever RfBAGs are held and whoever is involved, that the discussion should be closed by a bureaucrat as a point of principle. This strikes me as good common sense: evaluating consensus and being impartial arbitrators is what 'crats are ''for'', and it's the simplest and easiest way to increase the transparency of the process and mitigate claims of cabalism. Having the final decision whether to admit a member to a group, rest with the ''existing'' members of that group, is what happens in English ]s, not in a modern community like Misplaced Pages. Asking the 'crats to close half a dozen discussions a year (most of which are unanimous anyway and need little more than a passing glance) is no extra work for them in the greater scheme of things, and has a significant psychological benefit. Thoughts? <font color="forestgreen">]</font>‑<font color="darkorange">]</font> 15:26, 5 May 2008 (UTC)
:that is how it should have been on anything but 100% approval. Bcrats asked BAG not to bother them when it was that clear cut. ] 16:10, 5 May 2008 (UTC)
::I tried to get one to last time, and, the 2 or 3 I asked, declined to do so. ]] 17:26, 5 May 2008 (UTC)
:::Well that's (IMO) very irresponsible of them. It's not like they have so much on their plate that they can't close one discussion. <font color="forestgreen">]</font>‑<font color="darkorange">]</font> 17:30, 5 May 2008 (UTC)
::''(ec)''Do we have a diff for that? A lot of what goes on in and around BAG is based on precedent and on assumptions that in fact turn out to be baseless. As I said on ], I don't have a ''problem'' with that, per se, but it's that transparency issue again: let's be perfectly clear, in our own minds and in public, which parts of BAG and BRFA operations are actually rooted in policy/process/consensus, and which we just do because they seem to work and no one complains.
::I think another issue is the distinction between "unanimous" and "clear-cut": would a bureaucrat close as successful an RfBAG which was unanimous but had only two comments? ''Should'' such a nomination be closed as successful? In my opinion, based on the spirit of things like ] and ] as well as ], is that the agreement of two users does not constitute consensus in things like user rights polls; and so Coren's RfBAG should not have been closed as successful with only two contributors. <font color="forestgreen">]</font>‑<font color="darkorange">]</font> 17:28, 5 May 2008 (UTC)
:::I think, there were a few recently with 2-3 editors commenting, that passed. In my mind, that's probably a little weak of a response for a successful nom... Maybe we should have a minimum amount of editors commenting (as a condition for close), and leave the discussion open longer? ]] 18:19, 5 May 2008 (UTC)

===Should BAG be able to flag bots?===

It's been suggested before: should BAG members be made into a usergroup which can use ] to grant and revoke the bot flag? Personally, I would support such a move: it is already the case that BAG have complete authority over who gets the flag and when; having to have a 'crat rubber stamp it is a thoroughly ineffective check-and-balance when most of our bureaucrats don't know beans about bots - how are they supposed to know when a BAG member is making a mistake? I think that a compelling argument is that it will give BAG another tool with which to control wayward bots: currently having the bot flag withdrawn is an unnecessarily laborious process which is rarely used: bots are simply blocked instead, which is at best a blunt instrument. Of the over 100 bot-related rights changes this year, only ''one'' was a deflagging without the consent of the operator. What does everyone else think? A useful tool in the armoury of the people who are supposed to protect us against wayward bots? A natural extension of BAG's role? Or more trouble than it's worth? <font color="forestgreen">]</font>‑<font color="darkorange">]</font> 15:26, 5 May 2008 (UTC)
:My own opinion, is that BAG should be more of an 'advisory' role than it presently is. We should still close and evaluate the BRFA's as we do now, but, I do not believe that the Crats should blindly flag on our word. I firmly believe that the crats should be the last check/balance on the process. Just my $0.02 however. ]] 18:16, 5 May 2008 (UTC)
:: Bot approvals existed before bureaucrats had the ability to flag bots. Bot approvals is not something delegated by 'crats, and 'crats did not really oversee BAG, except that for a long time a 'crat was on BAG. ] 20:01, 5 May 2008 (UTC)

===General discussion===

I think this has certainly been an interesting experiment. If there's one thing that has been shown very clearly, it's the level of inertia and apathy that surrounds bot policies and processes on wikipedia. I don't think I've yet met anyone who is entirely happy with the way BRFA and BAG work on en.wiki (if you are, do speak up!), and I hope we can avoid getting into the same rut that has caught so many of our processes: where everyone agrees that it doesn't really work, but goes along with it anyway. There's no reason (other than apathy) why we can't change one little thing at a time and make gradual improvements; conversely, there's no reason not to try big changes as long as we're sensible with them. I'm very interested to hear other users' thoughts on the whole issue. <font color="forestgreen">]</font>‑<font color="darkorange">]</font> 15:26, 5 May 2008 (UTC)

== Page protection ==

This page has been protected for 5 days, community policy pages are not the place for reversion cycles, this discussion of the ] section should continue either here or at one of the other active venues (with a link to it from here). — ] <sup>]</sup> 02:11, 6 May 2008 (UTC)
:FWIW, I think this is already at the ]. — ] <sup>]</sup> 02:11, 6 May 2008 (UTC)
:: Obviously. The only right version is the one immediately after my rewrite back in January :) ] (]) 02:17, 6 May 2008 (UTC)

== "There is presently no method for joining the Bot Approvals Group which has consensus" ==

Ugh. It is '''not''' "My way or the highway". Please stop trying to confuse the issues, by now claiming that the previous version does not have consensus. I would suggest that it be reverted back, to the way it was before the "new (<s>experiment</s>) (<s>trial version</s>) (<s>policy</s>) proposal". Please address the old version seperately. ]] 03:13, 6 May 2008 (UTC)
:I haven't followed the debate, however. If the new method (which I dislike) hasn't got consensus (which I think is the case), then the old method is automatically in place. The fact that we have kindly asked some users not to submit their applications at the moment has nothing to do with the consensus. It was a polite request, not a policy statement. <i><b>] <sup><small>]</small></sup></b></i> 03:18, 6 May 2008 (UTC)
:You're right, '''it's not my way or the highway''', but the old method is broken and there's a reasonable amount of support for something '''besides''' that (though we can't seem to agree on what). Maintaining the status quo, which IMO is simply enhancing this self selecting cabal, is totally unacceptable. —] • ] • ] 04:35, 6 May 2008 (UTC)

== Let's settle this ==

Apparently since the propensity toward ] is irresistible for some, for the final time: let's settle this. Apparently people are disagreeing over whether or not consensus is or was not established, as well as whether it is still present or not. Thus, in order to help this along, I've made an outline of the key points and what people believe is or is not reflective of consensus. And, in this particular instance, a vote to determine just what, exactly, they think consensus is, I feel that it's entirely appropriate due to the points being relatively straightforward&mdash; it's a simple "yeah, there was consensus" or "no, there wasn't consensus." The details can be sorted out later.

I've added several points. Sign on '''any''' that you support, and feel free to add your own re-wordings in a new section at the end, but please do not modify the existing headers of others. This is not a policy vote&mdash; this is merely trying to establish points of reference to so that actual policy decisions as well as the ''current'' policy can be reflected accurately; for, if we can't agree on just what consensus is, then how, exactly, are we supposed to edit the policy page to state it? :P --]<small><sup>\&nbsp;]&nbsp;/</sup></small> 05:17, 6 May 2008 (UTC)
:It's telling that you'll go through the trouble to set up a "vote" but when it comes time to discuss the issue you folks all disappear. I'll never really understand that... —] • ] • ] 06:00, 6 May 2008 (UTC)
::'''Comment''' This section suffers from the problem that the BAG continues to define consensus differently to the rest of the wiki. If three members of the BAG discuss something on a subpage of the bot approvals page, which is archived after 12 hours, the rest of the wiki would perhaps not agree that consensus has been achieved. One thing which I see as a continuing problem is the general poor organisation of the BAG pages, with similar discussions occurring on several talk pages. Is there perhaps a way to help centralise such discussions? ] (]) 06:54, 6 May 2008 (UTC)
:::So, which sections or pages ''exactly'', are archived after 12 hours? ]] 07:14, 6 May 2008 (UTC)
:::It strikes me that the appropriate page for discussing WP:BOT is WT:BOT. ] 07:27, 6 May 2008 (UTC)
:::: (edit conflict) None, I was using hyperbole. Point is, most current BAG policy discussions suffer badly from low turnout. It reflects poorly on the BAG when policy is decided, without a single comment from outside the BAG. How can this be improved? I'm not sure, but I'm thinking maybe redirecting ], ], ], ], ] to a single point (like ]) would help, since an interested party would have to monitor all of those, plus AN and ANI to keep an eye on BAG policy discussions. (or perhaps to here, as Gimmetrow suggests) ] (]) 07:36, 6 May 2008 (UTC)

::I couldn't care less what approach is taken, because I know that in the end, it's not guaranteed to be harmful to the project to have either method or even no method at all. What I ''do'' know is that ] on ''any'' page&mdash; especially policy pages&mdash; '''is''' detrimental to the project. So, call it what you may, but this was by far the most neutral way I could think of to try to pull the vast sea of discussion seen above (now reaching 160 kb) into something from which people can move forth. As I said before, this serves as neither a policy vote nor final say on anything&mdash; it's merely a lens for facilitating productive edits and discussion. And, while I've been involved in the dicussion prior to this, I'm now more concerned that we stop edit warring over anything else.

::As a side note, I have a real life job and other real life commitments, and while I and other editors might "disappear" from discussion, especially during the ], it by no means should ever be taken to mean that an editor is apathetic in the affairs of the community and the encyclopedia as a whole. I truly wish we got paid to do this 24/7. Truly, I do. Sadly, however, we don't. Moreover, regular contributors to the encyclopedia aren't ], so if they do a drive-by on a talk page to state their opinions (instead of hovering over it), I'm of the opinion that it should '''not''' be construed to mean that they're not personally-invested enough in the encyclopedia and/or the topic that their opinions should be rendered any less valid. --]<small><sup>\&nbsp;]&nbsp;/</sup></small> 13:34, 6 May 2008 (UTC)

===Proposed points of consensus/non-consensus===

====1. The prior method of selecting the Bot Approvals Group (e.g., ) in the past...====

=====Had consensus=====
# I'll bite. ]] 05:25, 6 May 2008 (UTC)
# In the past, it had consensus, the kind of consensus that comes about when most people don't care. Now that we've seen how the BAG can grow out of control, though, there's a reason to care. This is why things have changed. ] / ] 07:55, 6 May 2008 (UTC)
# I Agree with Rspeer. No one really cared apart from bag members and the more active bot ops --] 12:49, 6 May 2008 (UTC)

=====Did not have consensus=====
# Unless a handful of people on an obscure page reflects community consensus... —] • ] • ] 05:59, 6 May 2008 (UTC)
# Based on ], closed as "Keep (reform)", I'm not aware of a particular consensus as opposed to inertia. ] (]) 06:33, 6 May 2008 (UTC)
# Too few persons, plus keep(reform) MfD. I've been trying to find a word for this, but maybe it would be best to describe the old system as being tolerated as long as no waves were made. By the time of the first betacommand RfAr, at the latest, this was no longer true. ] (]) 10:56, 6 May 2008 (UTC)
# The only consensus it could be described to have is that of obscurity and apathy. &mdash;&nbsp;]&nbsp;<sup>]</sup> 15:18, 6 May 2008 (UTC)
#<span class="plainlinks"></span> ''']''' ('']'') 00:11, 9 May 2008 (UTC)

====2. The prior method of selecting the Bot Approvals Group (e.g., ) currently...====

=====Continues to have consensus=====
#Obvious. ]] 05:25, 6 May 2008 (UTC)
=====Appears to have lost consensus=====
#Obvious. —] • ] • ] 05:59, 6 May 2008 (UTC)
#Depends, of course, on your definition of consensus and who is allowed to participate in determination thereof. ] (]) 06:34, 6 May 2008 (UTC)
#To say it hasn't lost consensus, you'd have to disregard basically everyone outside the BAG who has commented here. ] / ] 07:55, 6 May 2008 (UTC)
#Most definitely. <font color="forestgreen">]</font>‑<font color="darkorange">]</font> 09:40, 6 May 2008 (UTC)
#Except among the current BAG members. ] (]) 10:57, 6 May 2008 (UTC)
#I see more participation in the current requests, and I dont hear any outrage. reformation complete. --<span style="font-variant:small-caps">] <sup>'''(])'''</sup></span> 12:19, 6 May 2008 (UTC)
#There is to much disagreement for there to be consensus --] 12:52, 6 May 2008 (UTC)
#Pretty much by definition. &mdash;&nbsp;]&nbsp;<sup>]</sup> 15:18, 6 May 2008 (UTC)

====3. The changes, themselves, to the policy page regarding the Bot Approvals Group selection process (e.g., )...====

=====Currently have consensus=====

=====Currently do not have consensus=====
#My interpertation. I am an involved party and reserve the right to be wrong. ]] 05:25, 6 May 2008 (UTC)
#The only people seemingly actively fighting this are regulars of these pages. Which just demonstrates the disconnect between the community and the BAG IMHO. —] • ] • ] 05:59, 6 May 2008 (UTC)
#Apparently do not have consensus, though I'm mystified why a piece of text beginning with "a currently proposed method" would be so contentious, especially when the proposed method is in fact current and has gained wide participation. Of course, the best way to put out a fire is to stomp on it hard. ] (]) 06:44, 6 May 2008 (UTC)
#It would be unreasonable to expect a consensus already when changing a contentious policy. ] / ] 07:55, 6 May 2008 (UTC)
#As SQL. ] (]) 10:58, 6 May 2008 (UTC)
#No more changes until an agreement is reached --] 12:54, 6 May 2008 (UTC)

====4. The newly-proposed process for Bot Approvals Group selection (e.g., )...====

=====Currently has consensus=====
# Given the large amount of participation, for something "not having consensus", a lot of people sure seem to get involved (as opposed to the older method, which usually manages a handful of folks, mostly existing members of BAG (furthering the self selection/cabal aspect of it all). —] • ] • ] 05:59, 6 May 2008 (UTC)
#Actual community participation would indicate consensus. The turnout of editors opposed to the process, participating in the process, somewhat puts the boots to claims of no consensus. If you participate, it's a little difficult to claim that no-one wants to participate. ] (]) 06:48, 6 May 2008 (UTC)
#Lots of people participate in these nominations. Only SQL, apparently, participates in the old kind. ] / ] 07:55, 6 May 2008 (UTC)
#:I note, that not one of you so far has demonstrated that it has consensus, merely that a ''new process'', that's ''transcluded to a very high traffic'' page, ''was participated in'' *gasp*, really? Nice touch however, mentioning me specifically. Can't say accurate (heck, you yourself participated in one <s>prior to</s> directly after this?), but, amusing nonetheless. ]] 09:10, 6 May 2008 (UTC)
#::The intention appears to be that a consensus is demonstrated ''here'' by the number of people who profess support for it. <font color="forestgreen">]</font>‑<font color="darkorange">]</font> 09:43, 6 May 2008 (UTC)
#::Leaving aside any personal drahmaz, inspection of the seven current prefix-pages at RfBAG shows 191-28-13. The highwater mark is Cobi at 43-0-0, which could show Cobi's extreme sock-proficiency, or could show fairly conclusive evidence of relatively wide participation in the proposed process. Is there a demonstrated existing BAG member vote with 43 participants? This comes down to the definition of "demonstrated consensus", now I'm getting flashbacks to rollback. ] (]) 12:43, 6 May 2008 (UTC)
#Per Locke Cole: there was a suspiciously large amount of involvement for a process without consensus. I thought it was particularly ironic to see that those who opposed the process still got involved, just to make their opinions on the process known! <font color="forestgreen">]</font>‑<font color="darkorange">]</font> 09:43, 6 May 2008 (UTC)
#Perhaps "support" would be better. Certainly from persons outside the usual bot policy suspects, the RFA method has consensus. Has the BAG had a vote? If I could see that 10 or more BAG members could agree on one or the other, that would at least be a start. ] (]) 11:05, 6 May 2008 (UTC)
#Personally, I am glad to see BAG nominations being put on the main requests page, as BAG members act as buffer between the community and would-be operators whose bots could cause more harm than good (and hopefully they continue to be a guide to these operators so that the bots are improved).<br/>The community has demonstrated with higher participation in the current BAG requests that it is interested in who is selected for this role, and approves of the format; the community has a right to expect that this buffer is keenly aware of the community expectations of bot operators. <span style="font-variant:small-caps">] <sup>'''(])'''</sup></span> 12:15, 6 May 2008 (UTC)
#Insofar as we define "consensus" as "the community at large (as opposed to editors here) appears to find it acceptable", then yes it has consensus. &mdash;&nbsp;]&nbsp;<sup>]</sup> 15:21, 6 May 2008 (UTC)

=====Currently does not have consensus=====
# As per #3 ]] 05:25, 6 May 2008 (UTC)
# There have been objections since it was first proposed, which have never been resolved. &mdash;&nbsp;Carl <small>(]&nbsp;·&nbsp;])</small> 11:15, 6 May 2008 (UTC)
#:Because the objections are ridiculous in nature. We're getting much better community involvement in BAG member selection and ''some people'' seem to think this is something that needs "fixing". Lunacy! More community involvement should '''never, ever''' be discouraged or avoided. —] • ] • ] 00:22, 9 May 2008 (UTC)
# Hell no it does not have consensus, it was forced without discussion and is broken. ] 12:09, 6 May 2008 (UTC)
#: How is it broken? (links will be fine; I couldnt quickly see any problems when I scanned this talk page for the first time about 10 mins ago) <span style="font-variant:small-caps">] <sup>'''(])'''</sup></span> 12:21, 6 May 2008 (UTC)
#: Second the motion. Diffs please on the issue of being broken? ] (]) 13:26, 6 May 2008 (UTC)
#:you want to know how RfX is broken? ask Riana, Anticrist, or see ] a user who has zero prior bot related activity, save for a un-authorized bot that he ran for under 50 edits. Ilmari should have been a speedy closed because he shouldnt have even thought about running. Ive seen several users who have no prior experiance with bots and have an anti-bot attitude attempt to force their POV and dictate policy. BAG never has been and never should be a vote. all voting does is draw out the users who have no clue what they are talking about, who have hopes of being able to control things that they have no clue about. ] 14:22, 6 May 2008 (UTC)
#::Want to know why the BAG is seen as insular, cabalistic and out of touch with community standards? Look no further than this comment. Betacommand, if you could please refrain from the phrase "no clue what they are talking about" and AGF for a day, I'm sure we'll all be happy. The fact that the RFBM above didn't go in a fashion which you liked, is not proof that its broken. It is far from clear to me that an experienced user who is a mediawiki developer, en-administrator and sometime bot operator is fundamentally unqualified to be on the BAG. Further, if you say that the new method is no more broken than RFA/RFB (for which a community consensus exists) then where's your logic that it's broken? ] (]) 15:19, 6 May 2008 (UTC)
#:::Its a hell of a lot more broken, than RfA. someone should not be administoring something that have not been involved with. I will not refrain from saying the truth. 98% of people who vote at RfX have no clue about bots or bot policy. Ilmari's RfX is the same as giving a user with 0 edits +sysop. this RfBAG is a pure vote, if you think otherwise your lying to yourself. BAG and bots should NEVER be about votes. Bots are not a popularity contest, which this voting will turn it into. When first proposed Anti-vandal bots did not have what you would call "community consensus" in fact people did not like them, BAG made a tough call that was based on discussion, and guess what? when the AVB's go down people now complain. when voting is introduced people tend to become gutless and dont want to make the tough calls. What should be implimented is a transcluded discussion, (NOTE NOT A VOTE) on ], ], ], and ]. discussions are more productive than voting. ] 16:26, 6 May 2008 (UTC)
#::::The transcluded discussion is actually a pretty good idea. It would give the discussion the visibility which it's been lacking up to now. Is it workable? ] (]) 16:43, 6 May 2008 (UTC)
#:::::Its workable, and it actually will be productive and non-vote based. I am a very logical and reasonable person, Ive seen very very few votes that actually do anything productive. I dont have time at the moment to work out the logistics, but a WP:BAG/USERNAME page that is then transcluded as a discussion would should be workable. ] 17:16, 6 May 2008 (UTC)
#::::One need not be involved with something to understand it by being a lurker or reading up on prior discussions. His lack of involvement isn't a problem in mine (or seemingly the communities) opinion. It's regrettable you think your opinion on this matter transcends community consensus. —] • ] • ] 00:22, 9 May 2008 (UTC)
# As I have stated before there is to much disagreement for there to be consensus for any of the process --] 12:59, 6 May 2008 (UTC)
# Just because people used it does not mean it has consensus for us to continue using it. <font face="Broadway">]'']</font>'' 23:15, 6 May 2008 (UTC)
<span class="plainlinks"></span>. ''']''' ('']'') 00:12, 9 May 2008 (UTC)

=== Consensus schmonsensus ===
# ] (]) 16:46, 6 May 2008 (UTC)

=== T00 many opshunz 2 ch00z from ===
# ]] 23:06, 6 May 2008 (UTC)

==Recent nominations==
Why discuss an obvious issue with the BAG member selection method when you can just . Do you have no idea how bad it looks for members of BAG to be "nominating" people who share their views on BAG member selection (I'm specifically talking about krimpet's nomination: the person who called for a moratorium because of some unforeseen "chaos"). Is there any chance BAG will actually give a little here and stop the cabal activities, or are we heading back towards MFD since reform seems to be impossible? —] • ] • ] 07:10, 6 May 2008 (UTC)
:If we could, I'd prefer to keep the personal attacks, and bad faith to a minimum, please. ]] 07:19, 6 May 2008 (UTC)
::I think I've personally displayed exceptional patience (and good faith) considering BAG members continue to support a selection method that excludes the community (in the face of an option which has included more community input than all previous BAG member nominations '''combined'''). Maybe instead of acting like things are ''business as usual'' you could respect the fact that there '''is an ongoing unresolved dispute''' over the manner of BAG member selection. —] • ] • ] 07:23, 6 May 2008 (UTC)
:::Your edit summary conflicts with your statement, so, I'm ''supposed to'' put my head in the sand then? ]] 07:26, 6 May 2008 (UTC)
::::My edit summary reflects how you're behaving ''right now'', nominating people who agree with your preferred method (or disagree with the new RFA-style method) is just really bad during a dispute like this. Unless it's your intent to generate backlash and further accusations of cabalism, if so, good job. You're convincing me. —] • ] • ] 07:35, 6 May 2008 (UTC)
:::::Oh, I see. It's OK, for those that agree with the RFA method, to run there, but not OK, for other people to run at other perfectly acceptable locations. (I'm glad to see as well, that ], that I'd only do so for political betterment, and not that I felt that those users would be a net benefit to the project in that position. Thanks!) ]] 07:39, 6 May 2008 (UTC)
::::::(EC)Good faith is not some unlimited commodity that you can constantly use and call upon as needed. You've repeatedly made it clear that you're hostile towards any method other than what's in use now: further inflaming things '''is not helpful'''. As to your other comments, well, it's pretty obvious you're wrong since 1) a reasonable portion of those who submitted themselves to the RfBAG process didn't seem to voice an opinion one way or the other, and 2) at least one of the RfBAG participants (prior to the unnecessary "moratorium" because of all that incredible "chaos") was strictly opposed to RfBAG IIRC. So yeah.. let's try this again. Please suspend your cabal activities and help find something that involves the community (or maybe just relent and accept that RfBAG ''does involve more of the community, ergo it's a good thing''). Please? —] • ] • ] 08:09, 6 May 2008 (UTC)
::(indeterminate undent) I don't agree with LC's combative attitude, although it may be a result of frustration, but let's cool down here and keep the TLA's to a minimum please? I have to say I'm a little disquieted at seeing these nominations appearing on bot group pages, in particular nominating the admin who put the moratorium on the well-attended RFBAG applications. I would not be in opposition at all to either of Krimpet or MBisanz, but the perceptions here are not good. The effort to bring community input to BAG member approvals is soundly without consensus, but now there is another method to bring community input, the one favoured by the existing BAG? That doesn't look good. I have specifically ''not'' made any input on the membership requests on pages starting with "Bot" as my understanding is that BAG is self-selecting.
::We also have the problem that for either of Krimpet or MBisanz to be accepted, they must have previously demonstrated some months of participation in BRFA. Is this the case? If not, they are not eligible under the current process. A portion of the exact quote (far above) would be "being previously active in BRFAs are. you obviously have zero clue about bots or how they should be run". ] (]) 07:59, 6 May 2008 (UTC)
:::It's frustration. I'm going to step away for a couple of hours and come back, maybe things will have improved or someone slightly less frustrated with this could see about getting us somewhere (besides the seemingly neverending "no you're wrong" &rarr; (silence) &rarr; <revert> cycle). —] • ] • ] 08:09, 6 May 2008 (UTC)
:::(ec)Actually, as I mentioned, I was hoping to get... well, less-techinical, less entrenched editors involved in the process (There's probably a complaint about just that less than 3 sections away from here?). Both '''have''' commented on BRFA's, and, both '''do''' run bots. Also, I was hoping, that maybe, just maybe, if *I* nominated people, others would see that they could, too (although, my overriding motivation was that honestly I believed those two editors would make great additions to the team for the reasons I specified). It feels to me, like we are acting as though I have just '''appointed''' these folks, which, I absolutely have not, and cannot. If you have an opinion on these candidates (well, Krimpet at least, I have the feeling MBisanz won't accept....), there's a discussion header for each at ]. I'm sorry, that some choose to see it as cabalism, and, other such evil things, but, that was simply not the intent. Also, I would like to apologize, as I have obviously bought the bait brought upon in this section. I would like to ask that it be renamed to something less accusatory, if at all possible (with the consent of the other current contributors). ]] 08:15, 6 May 2008 (UTC)
::::I've renamed it, feel free to change it if you have a better title in mind. And I apologize for the poor title I chose. —] • ] • ] 08:19, 6 May 2008 (UTC)
:::::Greatly appreciate it, and, no harm done. ]] 09:23, 6 May 2008 (UTC)
::::One, it's always better, in preference to the AGF thing, to simply explain what your good faith edit was, in the face of a possible misunderstanding from the other party. That's mostly been explained and resolved now. There's still "evil" and "cabal" as touchstone words hanging out there, whatever, forget it, but remember that evil often proceeds from the best of intentions (ref's on request).
::::Two, I'm still unclear on why this nomination process couldn't be carried out under the aegis of the RfA page, which has attention from a wide portion of the community, albeit a still self-selecting portion. The only particular reason I can see is the moratorium declared by Krimpet, a current nominee for BAG. I can't really wrap my head around that one. Perhaps there is some distrust in the ability of the 'crats to judge consensus properly? Is there something in particular about bots that renders these stringently selected members of the community incompetent?
::::Three, from my own personal view, I'm not inclined to participate in !votes on bot pages where I have a concern that the official BAG members will summarily dismiss my views for lack of something-or-other, possibly with profanity included.
::::Last, I've already approached the ], who has declined my incredibly ] nomination but foolishly responded in a GFDL fashion so that I can repeat it here. It's not too late for a draft campaign. ] (]) 09:37, 6 May 2008 (UTC)
:::::Ignoring the bit of assumptions about my nom of Krimpet, if you don't mind, and cutting directly to the issue at hand, for me, personally, my ''personal preference'' is the "old old double-trial system" or whatever we'd call it, where folks could add and remove themselves. ] is about as far from that as one can get, no? I'd note, that there are still noms open at ] last I looked, that were 2+ days old (I think, I chose to close a couple at ] a while back that were not terribly older than that, after poking several people), so it appears as tho those aren't going to get closed anymore than they were when it was asked of the crats to close them here (which, I would greatly prefer to us having to close them ourselves.). Anyhow, hope some of this helps. ]] 09:49, 6 May 2008 (UTC)
::::::I'm not sure any assumptions have been made about Krimpet, though there are certainly concerns around ''perceptions''. Out of respect for Krimpet though, I'll certainly put that aside.
::::::I have only eight months here, so maybe a one/two-year backview of some archives. From early on though, it became apparent that there is a problem in the bot area (an interest of mine). I'm not familiar with "double-trial", can't comment there, certainly any system which combines opt-in membership with single-member approval is sub-optimal. Didn't that just happen? I advocate a dual-approval / single-veto system, tech and community members, forward and revocation. Two opinions are needed to proceed, one is a halt to operation. Membership in that system ''should'' be a trial-by-fire a la RfBAG, bot edits are almost by definition trusted edits, approving and restricting bots is important to the whole community. The whole community should have a chance to comment on it (or individually choose to ignore the process).
::::::I also have noticed that the RfBAG's have been dragging on and I'm not sure why they have. I choose to blame ] who could have helped, but for some strange reason is not able to. Another draft campaign, I guess. But that's another unclear process, let's get this one straightened out :) ] (]) 10:27, 6 May 2008 (UTC)

== BAG Candidacy ==

I have accepted a nomination to be considered for membership in the ]. Please express comments and views ]. ''']''' <sup>]</sup> 08:37, 6 May 2008 (UTC)

== Notice templates ==

Regardless of which way we go, the bot policy should include a section indicating that individuals standing for BAG membership may include a notice on their userpage indicating such. I have created {{tl|BAG-notice}} and {{tl|RBAG-nom}} to that end. ''']''' <sup>]</sup> 00:05, 7 May 2008 (UTC)

== Not the BAG nomination system ==

WT:BOT has been stuck discussing the BAG nomination system. There were quite a few ''other'' changes to ]. I'm listing the changes I noticed in of the live draft. Some rather significant new processes or policies are:
* In ]: In cases where the function of the bot is not one that already holds general widespread acceptance, or at the discretion of BAG members when greater community feedback is desired, the request may first move to an extended trial of approximately one month. During the extended trial the bot must have a link in edit summaries to the BRFA and a prominent notice on its user and user talk pages. Following this extended trial, consensus for the bot will be reconsidered, any issues should be resolved, and the bot can then be approved.
* ] (entirely new section)
* ] (entirely new section)
* ] now says that a bot must provide a way to opt-out of user talk messages.


I would like to do a temperature check (explicitly not an RfC) as a follow-up to the discussion at ], of how people feel about changing the source code requirements. Currently the language in the bot policy is:
I'm not even sure what the "extended trial" is supposed to mean or how it might apply. Is the multi-user idea acceptable to everyone? I think the user talk opt-out could go under configuration tips, but does it need to be a requirement?


{{Tq|Authors of bot processes are encouraged, but not required, to publish the source code of their bot.}} and for adminbots: {{Tq|It is recommended that the source code for adminbots be open, but should the operator elect to keep all or part of the code not publicly visible, they must present such code for review upon request from any BAG member or administrator.}}
Other possibly notable changes: a line saying "Bot operators may wish to create a separate bot account for each task" was removed. A statement was added about ], and there is a new ] section.


I would like to replace it with something like: "Authors of bot processes are expected to publish the source code of their bot in a public manner under an to facilitate collaboration and forking. Should an author wish to keep the source code private, they must request an exemption from BAG during the bot approval process. BAG members may decline requests solely on the basis of source code not being open source." And some kind of grandfathering clause for current closed source bots.
Do we agree with all of these? Do we no longer want to even mention that it can be OK to have different bot accounts for different tasks? The bot-flag section is mostly descriptive except that it implies BAG will no longer approve any bots to run without the bot-bit. Regarding "User scripts" in particular, if a javascript locks up a user's account for a long time making the user unresponsive to the queries on the operation of this javascript, should bot policy apply? Should WP:BOT say clearly yes or no, or should this be left ambiguous?


The rationale being 1) allowing people to suggest improvements for bots or point out possible bugs as a technical review step, and 2) when bots/maintainers inevitably disappear, mandate that there is a path for someone else to take over the bot without starting from scratch. I think the Wikimedia movement has moved in this direction, with requiring open source licenses for bots run on Toolforge (the vast majority of our bots) and there's an abundance of places to post your code. Or in other words, open source should be the norm, private should be an exception.
Also, I've been thinking about a model where BAG functions rather like a mentor. If an approved bot has technical issues later, then a BAG member (or more in exceptional cases) could take responsibility to watch over it until issues are resolved. ] 04:15, 7 May 2008 (UTC)


Some carve outs: I'm sure people can come up with edge cases where publishing code isn't desired; if those turn into actual BRFAs, I'm happy to defer the decision to BAG on whether the exception is justified or not. As a practical matter, I think it would be fine if people make changes, test their code, and then publish it shortly after. I don't think we need a hard requirement that code must be open source before you run it against Misplaced Pages.
== Eliminate BAG ==
The ] has been by far one of the most argued over formal groups on Misplaced Pages. It's existences seems to come out of the will of 4 users who thought more process was needed in Misplaced Pages (<span class="plainlinks">, )</span> In short, this process was never "ratified"/approved by the community.


So temperature check: how do people feel about this? Is this a reasonable proposal? Or if you would not support something like this being formalized, why not? ] (]) 03:54, 5 September 2024 (UTC)
While the idea of having some way to check the validity of a code is worthwhile, the community, not a group of users who approve new members themselves, should make the final decision in approving a bot. A formal group like BAG does NOT need to exist to check the validity of a code and the worth of a bot.


:Looks ok to me. I expect open source codes for bots as well. It helped with the takeover of the AdminStats task (although we ended up hunting for a copy of the codes in Toolforge itself). However, can the grandfather clause be extended into new task requests of current bots as the new tasks may still utilise the closed-source codes. ] (]) 04:03, 5 September 2024 (UTC)
The process for joining BAG is shady and switches whenever their control is threatened. Previously discussion took place on the ]. However, once a previously MfD was created about BAG and the community complained over the "cabal" of the process, BAG sought to fix this by allowing anyone to join. This was short lived, and BAG went back to the old way of adding users. Soon enough the community cried out again over the cabal nature, and BAG added itself to the ] main page. Again, when one of the current BAG members would of failed joining BAG, (see ]) the group switched back to the old way, which takes place on a unwatched talk page, of approving members.
::I don't see why we should bake 'they must be open, unless you ask for an exception, which we may deny' into policy, rather than the current 'we encourage, but don't mandate, open source bots'. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 10:00, 5 September 2024 (UTC)
:::@]: Could you expand on why you don't think it should be done? (I personally don't think we need an exception, I just expected people would oppose it without one) ] (]) 15:35, 5 September 2024 (UTC)
::::I'm also curious about this, but I do see that allowing for exceptions is a reasonable thing to do. Imagine if somebody came to us and said, "The company I work for has an abuse-detection system that's 10x better than what you're using now. We're willing to let you use it at no cost, but unfortunately I cannot make the code available". Having that exception carve-out gives us the ability to accept or refuse that offer as we see fit at the time. Not having that carve-out forces our hand. I think that's reasonable.
::::We already have agreements like that with some IP proxy detection vendors (I'm being cagey here about the vendor names only because I'm not sure of the status of these relationships). Because they are only (to the best of my knowledge) used as back-ends to some interactive tools, they don't fall under BAG's remit. But I could certainly imagine somebody wanting to build a BAGgy tool which uses one of those services as a back end. As much as I believe in ] everywhere, I also wouldn't want us to shoot ourselves in the foot to stand on principle. ] ] 16:04, 5 September 2024 (UTC)
:::::You might not want to put your code up because it's crude/inelegant. You could also be doing things that is "OK" with private code, that isn't OK with public code, like having "if ''password = sw0rdf!sh'' continue, else fail" instead of whatever you should be doing with passwords and logins. Or you might be using code from someone else that you got permission to use, but didn't get permission to distribute. Or you may be using closed source code that you purchased, but don't have rights to distribute.
:::::Like, I'll agree it's unequivocally better to have things open sourced. Hence why it should be encouraged. But volunteer coders are an extremely limited resource, so the fewer barriers to entry/participation we have, the better, IMO. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 19:12, 5 September 2024 (UTC)
*<s>'''Strong support'''</s> Requiring bots to be open source seems like a good idea to me for reasons ranging from cultural (<s>supporting the goals</s> promoting the ideals of the Wikimedia movement) to security (code review) to disaster recovery (being able to continue operation of critical services should the original developer disappear). ] ] 12:15, 5 September 2024 (UTC)
*I mainly pushed back against this in the above BRFA because I felt it violated current norms. But I am not opposed to it in general if we make a change to BOTPOL. There are major maintainability advantages to having bot code open sourced. Volunteers that write critical code lose interest or go inactive all the time. Honestly maybe a proposal to require Toolforge for non-AWB bots might also be worth considering. The combination of open sourced code plus Toolforge would be the ideal situation for rescuing abandoned bots. Finally, we also had a situation recently where an operator passed away and their bot was immediately blocked and globally locked. Avoiding blocking working bots ASAP, giving time for us to properly fork and replace them, might be worth adding to BOTPOL as well. –] <small>(])</small> 16:18, 5 September 2024 (UTC)
*:This is a good point; as anybody who has ever tried to port anything knows, just having the source code is only half the battle. Moving things to a new operating environment can be a pain too; requiring that everything runs in Toolforge (or Cloud VPS) would be a good thing IMHO. I'm not sure where you draw the line, however. Some people would insist that everything run in a Docker container. That would drive me nuts. Some people would insist that we only use phab, gitlab, and so on. That would also drive me nuts. ] ] 17:01, 5 September 2024 (UTC)
*:I think you're underestimating how successive additional requirements hinder attracting new volunteers. It's no big deal to experienced developers, but there is already a lot to navigate as a new developer. Of course, if the goal is to reduce the number of abandoned bots, discouraging new bots will definitely help. I think it would be better to encourage practices like source code availability, succession plans, etc. with a dashboard, recognition, and other approaches. ] (]) 20:14, 5 September 2024 (UTC)
*I'm strongly opposed to the proposed change. The current policy encourages open source without being overly restrictive or discouraging of people submitting requests. As an open source developer, I think that's a good thing. But requiring all bots to be open source could discourage some potential projects, especially if they use proprietary code or need to use non-free components. For some projects, there are also security-related reasons to not open source code for the same reasons we have private edit filters. Finally, if there are specific bots that are truly critical and not open source, we should identify those bots and solicit for replacement bots that would be open source, or ask the WMF to write, maintain, and operate replacement bots for those functions. The current policy is well-written. ] (]) 21:04, 5 September 2024 (UTC)
*:Part of my concern is that if it's necessary to grandfather existing bots, it strongly implies that there would be a chilling effect on future proposals, for both existing and new bots. I’d prefer to start with a review of existing bots to assess their criticality and succession plans, and then consider improvements based on the assessment. Policy changes might be one approach, but I believe that providing encouragements that won't discourage future projects, and can be applied to all bots, would be more effective. ] (]) 22:25, 5 September 2024 (UTC)
* I appreciate the feedback that people have given and will reply a bit later after digesting them, but please, can we avoid the bold votes? I would like to focus on the discussion and rationales not ... voting. ] (]) 21:39, 5 September 2024 (UTC)
*:Sorry if the bold came across as harsh, I was following the format of an earlier comment. I appreciate you following up on the discussion to discuss it out in the open which will reduce the odds this is rediscussed in random future BRFAs. ] (]) 22:10, 5 September 2024 (UTC)
*I think the circumstances have to be taken into account. If the bot is going to be a one-time simple task, it's probably less critical to have a succession plan in place. If it's a bot that's going to underpin key workflow processes, then having a plan for ensuring that the task can be handed off is more important. I agree that ideally all code would be open source (keeping any necessary private configuration closed) and with a relatively uniform development and runtime environment, but practically speaking, I don't think English Misplaced Pages can afford to limit its potential pool of developers to that degree. ] (]) 23:48, 5 September 2024 (UTC)
* I would unequivocally support something stronger for bots expected to be a continuing run as "we require open source" and would definitely encourage something like the OP even for shorter runs. I'm sorry, but we cannot continue to depend on closed source bots and private source. (I have said as much multiple times now.) And sorry, if your code is shitty, that's how open source works. Either you can get over your fear of publishing something that is hacked together (as if no one else has hacked together code into production, know how modern MediaWiki started?) or you can do something else with your time (which I'm sure will be productive for wiki goals as well). ] (]) 18:00, 29 September 2024 (UTC)
*:While having code available is a good start, if we're going to introduce some requirements for succession planning, I don't think it should stop there. Too many people think if the source is available, all is good. But if it's Haskell code, for instance, the pool of potential contributors is significantly smaller. So if we start on this route, I think we need to also include things like the bot has to run on the toolforge servers, the language is highly recommended to be from a list of supported languages, and there is at least one other maintainer actively involved. ] (]) 21:34, 29 September 2024 (UTC)
*::Before we consider a stricter policy for some cases, we need to be specific about which bots are actually ''critical''. Requiring people to code in specific languages, or get up to speed on Toolforge on top of learning MediaWiki APIs for a bot that quietly does its own thing, isn't mission critical, etc. is going to be counterproductive. We need more people, ''especially newcomers'' to Misplaced Pages coding, writing more helpful bots, and we should endeavor to keep the cost of entry as low as reasonably possible. The ideal case is always going to be easily portable and well maintained code, but no requirements are going to keep us from avoiding some inevitable realities of the software lifecycle and the ]. ] (]) 00:13, 30 September 2024 (UTC)
*::Let's tackle one thing at a time. I happen to agree that it makes sense to state an increased expectation for these other qualities, but I think we have to start from "someone could even theoretically pick this up and run with it". ] (]) 00:52, 30 September 2024 (UTC)
*:::I think a little bit more is needed to lay the base to enable someone else to theoretically operate a given bot. It could be one of the following: tool runs on toolforge, there are multiple active maintainers, or there is sufficient up-to-date written documentation that describes the software stack and execution environment. And, unfortunately for aficionados of more obscure languages, I think there should be a list of highly recommended languages. ] (]) 01:28, 30 September 2024 (UTC)
*::::On the one hand, I endorse all of these as obvious good things. And to that I'd add that the source has to be publicly available in a standard source control system (which these days basically means git). It's one thing to say the code is under an FOSS license, but if the distribution mechanism is to download a ROT-13'd ] file from a gopher server, it might as well not exist. And it should have a comprehensive test suite. And an issue tracking system. And code reviews. Well, you see where this is going. All of these things are essential good software engineering practices, but each one is also a barrier to entry for a lot of people, and at some point we need to make an intelligent decision about where we want to draw the line. If we chased away every potential code contributor with onerous requirements, we'd certainly solve the problem of tool migration because we wouldn't have any tools. ] ] 01:58, 30 September 2024 (UTC)
*:::::Yes, I already stated I don't think English Misplaced Pages can afford to limit its potential developer pool for all its tools. I think when a tool or bot is planned for deployment, we need to decide how important it is to have some form of succession plan in place. In many cases, we may just live with the risk. For some key processes, we may want to plan for future transition to different maintainers. ] (]) 02:33, 30 September 2024 (UTC)
* I have nothing against publishing my code. I acknowledge that the code quality is far from ideal, since I don't get a lot of time to work on it, and my decision to use C# may not have been the best. The bots have worked their way into some of our processes, so it might be good if someone could at least see what they do in case something happens to me. I would have to go through the files and add the appropriate copyright notices. I am unsure what counts as an open licence; my intent was always to use GPLv3. Once a licence is applied though, it will be hard to change, so a grandfather clause would be necessary. And yes, moving things to a new operating environment is a real pain; Toolforge now insists that everything run in a Docker container. Getting that to work has been taxing, and would have been impossible without a lot of help from the Toolforge admins. ] ] 20:25, 29 September 2024 (UTC)
*:Toolforge currently requires an . That seems like the right expectation to me. ] might be useful for your own review of what you might license your code as. ] (]) 00:54, 30 September 2024 (UTC)
*::I found the policy at ]. I haven't actually implemented it yet. ] ] 04:56, 2 October 2024 (UTC)
*:I think the docker container part is just picking an image on toolforge. You don't need to install docker on your local computer, nor do you need to know much about docker except for the one CLI command to run and which image you are going to pick from the list of images. My bots are written in PHP and I use xampp locally to run them when I am doing coding and manual tests. –] <small>(])</small> 15:59, 30 September 2024 (UTC)
*::Not an image, but a . The build pack creates the container image. I had to get them to install a dotnet build pack for me. Running docker locally was no problem; getting the application to work properly in that operating environment took more effort. ] ] 21:30, 30 September 2024 (UTC)
*:::I previously looked at getting a .NET app to run on Toolforge but they didn't have any "official" support so I couldn't be bothered to figure it out and I concluded I would need to get in touch with them to add this support. This is in addition to all the hoops one has to jump through to figure out how to do things there. None of it is user-friendly, that's for sure, speaking of barrier to entry and all that. Anyway, this did not exist at the time. I might ping you at some point to ask you how exactly you did it if I can't figure out stuff from the documentation. I don't suppose you recorded the steps you took to get it working? —&nbsp;<small>&nbsp;]&nbsp;<b>∣</b>&nbsp;]</small> 22:27, 30 September 2024 (UTC)
*::::Yes, I recorded the steps I took. ] ] 04:53, 2 October 2024 (UTC)


===Bots with available source code===
This unwarranted and unapproved process needs to be stopped. No more reforms, no more process wonk. The community should decide the fate and usefulness of a bot, not a selective group of users. If, indeed, later down the road the community would like to have a group oversee the validity of a code, then a whole new community approved process can start.
====List====
<!-- Format:
* {{Botlinks|<bot name>}}
** ]: code available
-->
See: ]


====Discussion====
Eliminate BAG, but continue to add bots to be approved on the ] page. The community can then go there and, with consensus of the community as a whole, decide the usefulness of a bot. Those who are in BAG can simply comment on the validity of the code/script. If you want to complain this doesn't get enough traffic, then add it to the RfA main page. ''']''' ('']'') 00:07, 9 May 2008 (UTC)
Based on the above, there appears to be a reasonable consensus that most (if not all) bots that do "core functions" (my phrasing) should have their code posted so that if the operator disappears (intentionally or not) the functionality can be quickly/easily/efficiently ported onto a new bot/operator who can take over the task. I have started a (currently empty) list above, and would invite editors to add and discuss the list so that we can start asking operators to provide the code if deemed necessary. Personally speaking I think this list should focus on open-approval tasks (i.e. not one time runs) to start, but if someone wants the code for OTRs feel free to ask. ] (]) 19:30, 29 September 2024 (UTC)
:As they seem unwilling to accept any new method of nomination (thus putting an end to the cabal concerns), I would agree with eliminating the BAG entirely and instead moving to an RFA style system for bot approvals (not to be held on the RFA page, but still to be decided by a bureaucrat (who would also of course set the bot flag upon community approval)). —] • ] • ] 00:13, 9 May 2008 (UTC)
:I think there's a tendency for the general editing population to think if the code is available, it should be easy for anyone to step into the void and quickly get a bot running, but that's a fallacy. I think if we're going to introduce requirements for succession planning, they should cover a bit more (as I discussed in an earlier comment). ] (]) 21:37, 29 September 2024 (UTC)
::I proposed a cross transcluded discussion that will work. I just havent had time to work the details out. ] 00:48, 9 May 2008 (UTC)
:I don't see that consensus. We all agree it's preferable. But mandatory is different. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 00:51, 30 September 2024 (UTC)
:::Translusion won't work though; a discussion posted at ] garnered zero responses, and AFAIK that's the only other place you could transclude them besides ]. (I suppose you could try ], but I doubt it'll come close to the kind of feedback we were seeing with RfBAG, and that's the mark you need to overcome to convince me that what you're proposing is better). —] • ] • ] 05:13, 9 May 2008 (UTC)
::I think the consensus is for a stronger policy than saying it's "preferable" (which we already do). We could make some exceptions for long-standing bots, such as AAlertBot, which is I think what you are primarily concerned about. – ] (]) 12:04, 30 September 2024 (UTC)
:If you can get the community involved, more power to you. So far, community consensus on the bot approvals process has been an overwhelming "I don't care". --] (]) 00:14, 9 May 2008 (UTC)
:::I don't see such consensus at all. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 15:21, 30 September 2024 (UTC)
:The arguments presented here don't seem to be very strong ones. The BAG membership process is shady? It's discussed at ] and ], exactly where you'd expect to find it. Also, as others have said elsewhere, decisions are made by those who show up. In 2006, users discussed and then implemented the bot approvals group. If only a few people participated, oh well. Further issues can (and have) been brought up on the talk page and the policy is always changing (this is a wiki after all). There's no formal ratification or approval process (though Jimbo has suggested using ArbCom in the past (/me shudders)). Also, I think Carnildo's point is dead-on &ndash; ]. --] (]) 01:21, 9 May 2008 (UTC)
:A ''mandatory'' policy is a recipe for "consensus" to shut bots down or worse remove bot privs fpr being a rouge operator. What else could "mandatory" mean? Which is like that Vietnam War saying, "We had to destroy a village to save it" (variations of this quote). Isaacl is exactly right that dumping a bunch of source to GitHub is meaningless for anyone trying to install and operate it. And some bots the operation requires a lot of training that is not easy to document. -- ]] 23:47, 30 September 2024 (UTC)
:: ] is running 34-5 against having RfBAG on RfA. Although perhaps not the best announced (On signpost and 'crat noticeboard, I think, but didn't quite make the site notice), it's so highly lopsided that it suggests, just maybe, the community simply doesn't want to select BAG that way. ] 01:34, 9 May 2008 (UTC)
:::If nobody cares, then I fully intend to run my bots without the approval of some poorly constructed group of users. ''']''' ('']'') 03:08, 9 May 2008 (UTC) ::{{tq|shut bots down}}. I imagine any new requirements would have an exception for bots approved before the new requirement. ] <small>(])</small> 00:44, 1 October 2024 (UTC)
:::Where in my post did I say mandatory? I did not, so to disagree with something I didn't say is a little odd. This sub-thread is about taking the first steps - right now we don't even know which bots ''have'' open-source or freely-available code bases, or where they're hosted, etc. ] (]) 12:38, 5 October 2024 (UTC)
::::Then you '''will''' be blocked and further action will be taken against you. you have a history of poorly designed and coded bots that have had numerious complaints spreading the four main accounts that you have used. ] 03:16, 9 May 2008 (UTC)
:I get where everyone is coming from with the desire to make sure bots keep running smoothly, but it's not clear to me that there's consensus making open source mandatory. I'm concerned that:
:::::Monobi, running your bots unapproved doesn't have the community consensus you've been pleading for in posts such as the one above. '']'' <small>(])</small> 03:31, 9 May 2008 (UTC)
:*The focus is open source and adding extra requirements instead of having succession plans.
:::: Monobi, WP did not originally have a bot policy. It developed because having completely unregulated bots created some problems. Of course nobody complains when a bot does good things and doesn't screw up, but it was the other cases that led the community to say that *someone* must approve bots. Anyone can comment on a bot request, but if nobody is responsible for the approval and has to answer for screwups, it's a form of ]. Thus BAG. BAG is pretty low in importance on WP, but it does serve a purpose. ] 03:34, 9 May 2008 (UTC)
:*There aren't clear definitions for terms like "critical" or "core" and we don't have a list of the bots that would be impacted.
::::: It's worth noting that ''most'' ways of determining community approval on Misplaced Pages don't involve closure by a person from a specific authorized group. Usually, if you want community approval for something, you either:
:*Grandfathering some bots might mean we end up with all of the downsides that will discourage future development without significantly improving continuity.
:::::* a) just do it, and see if anyone reverts you or tells you to stop, or
:I've only written one bot so far, one that's trivial to set up and also open source, but it likely wouldn't exist if I had to produce open-source code before getting project approval or had been required to use Toolforge for my first project. The problem that {{u|Protection Helper Bot}} solves has been a Phabricator ticket since 2012 and proposed multiple times before and since then (such as ]). We should be encouraging new developers to help solve long-standing problems rather than throwing up roadblocks, even if they seem like low bars to most experienced Misplaced Pages developers. ] (]) 01:03, 1 October 2024 (UTC)
:::::* b) propose it somewhere, let people discuss it for a while and then, if looks like consensus has emerged in favor of it, do it.
::I never said anything about anything being mandatory. ] (]) 12:38, 5 October 2024 (UTC)
::::: Most such discussions will either continue until a consensus is reached naturally (or isn't, and the discussion just dies out), or they have a time limit but no particular designated group of closers. The exceptions, like ] and ], tend to involve a simple yes/no poll to approve a single action (deletion, sysoping) that can only be carried out by a member of a particular group (admins, bureaucrats) and are thus naturally closed by the person actually performing (or declining to perform) said action when it is carried out (or not). BRfA is something of an anomaly here: even though it has a formal group of closers, it usually takes the form of a threaded discussion rather than a simple poll, it has no set time limit, and the people authorized to close it are not the ones with the actual authority to implement the decisions. In many ways, it would be much more natural if it was carried out more like, say, ]. —] <small>(])</small> 05:46, 9 May 2008 (UTC)
:::You're right, "mandatory" was used by another commenter. However, I do actually believe setting the expectation that core functions {{tpq|should}} make their code available would likely turn that expectation into a requirement in practice. The policy already recommends it and that seems to be interpreted aggressively at times in BRFA discussions. I would also like to understand the current situation before changing the policy. ] (]) 01:21, 6 October 2024 (UTC)
:::::: BRFA is an RfC. Anyone can comment. It probably wouldn't make a difference if we said "BAG closers = admins + select approved non-admins", because probably only technically interested admins would get involved. ] 00:02, 10 May 2008 (UTC)
::::Your bot was the exception as it's an adminbot that touches protection of articles. Most BRFAs have no requirement or request to release their source, and don't in practice. ] (]) 21:13, 14 October 2024 (UTC)
:::::I agree with the bot policy that source code for adminbots should be open or the developer {{tpq|must present such code for review upon request from any BAG member or administrator}}. My previous comments should not be interpreted as contradicting that. I designed my bot to be easy for anyone to run by releasing the code as open source and ensuring it's easy to set up. However, I believe it's fair to say that some of the additional requirements that have been discussed would have likely deterred me from submitting a BRFA. ] (]) 23:11, 14 October 2024 (UTC)
:Mandatory or whatever aside, I think there is merit to us having a list of what we think are "essential" bots, along some idea of what the succession strategy for these bots is. (any of: is source available? are they hosted on Toolforge with multiple maintainers?) ] (]) 21:12, 14 October 2024 (UTC)
::I added a couple bots to the list started above. I also included how esoteric their tech stack would be considered these days (ie: how easily could someone take over maintaining it with updates/fixes). Bots using pywikibot or mwbot-rs for example I think are quite accessible. Custom C++ code or even Perl code I'd say is not particularly easy to take over. Realistically there's nothing we can do about these, but it's worth remaining aware of our ].{{pb}}I'm loosely defining "core" as the bot disappearing causing noticeable disruption to the encyclopaedia, some significant process, or otherwise meaningfully impacting the quality of articles. ] (]) 21:46, 14 October 2024 (UTC)
:::I suggest creating a parent list of key English Misplaced Pages processes/ongoing work items, and under them listing the essential automated tasks for those processes/work items. (I understand that some bots may be grouped under multiple processes/work items.) At the very least, it would be helpful to those not familar with all the bots if the list could include a brief summary of their essential tasks. ] (]) 21:54, 14 October 2024 (UTC)
::::Do you mean something like this? ] ] (]) 22:04, 14 October 2024 (UTC)
:::::Yes. Basically a breakdown by workflow: here's an important process (which might be doing a set of ongoing work items), and here're the key elements that are automated in order to make this sustainable. I was thinking that depending on the size of the lists, or the number of bots that support multiple workflows, it might be worthwhile to keep the bot list with its details separate, and just have the workflow list point to the bots in the bot list. I feel this makes it easier to think about what workflows are absolutely necessary to keep running (and think of ones that are missing from the list), and to know what they rely on. ] (]) 22:23, 14 October 2024 (UTC)
::::::Thanks {{u|isaacl}}, I think this is a good idea. I'd like to suggest a single list for now, unless it transpires that it's common for single bot accounts to do multiple core tasks? I think it's easier than correlating entries across two lists, if we can avoid it.
::::::I am thinking there's a few things we should understand about each bot, rather than just asking "is the source available". I've tried to summarise these in the lead of ]. I give the example of ClueBot NG there - I think the fact that it's an ANN model using C++ and means someone outside the core development team is unlikely to be able to pickup that bot as-is and realistically maintain it, as opposed to just running it.
::::::With that in mind, I'm wondering if it might be good to develop a ''simple'' criteria to assess a bot against, to serve as a decent ] compared to raw-text comments. e.g. categories like: "source available and executable?" / "multiple maintainers?" / "maintainable tech stack?", on which a bot can get a binary score (good/bad). These categories are mainly just to illustrate the idea. I'm not fixed on what kind of framework we should assess bots against for a realistic 'operational resiliency' strategy. ] (]) 11:06, 16 October 2024 (UTC)
:::::::Could also do a scale of 1-5. Being hosted on Toolforge could add a point, source code published could add a point, active maintainers could add a point, etc. –] <small>(])</small> 13:25, 16 October 2024 (UTC)
::::::::Point systems are pointless (pun unintended). Let's not have a metric that serves no actionable purpose for sake of having one.
::::::::That said, what's the RFC bot? It should go on the core list. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 14:26, 16 October 2024 (UTC)
:::::::::{{replyto|Headbomb}} There are two RFC bots:
:::::::::*{{user|Legobot}} once an hour (i) detects {{tlx|rfc}} transclusions that lack a {{para|rfcid}} parameter, and adds one; (ii) ensures that the next valid timestamp after every existing {{tlx|rfc}} tag is less than thirty days in the past, and if not, removes the {{tlx|rfc}} tag and also removes the RfC statement from all of the listings (such as ]); (iii) checks the ] for each {{tlx|rfc}} transclusion, such as {{para||bio}}, and ensures that the RfC is listed on corresponding pages such as ]
:::::::::*{{user|Yapperbot}} (also once an hour, but half an hour after Legobot) sends messages to user talk pages concerning RfCs where Legobot has recently added a {{para|rfcid}} parameter, see ]
:::::::::HTH. --] &#x1f339; (]) 15:27, 16 October 2024 (UTC)
::::::::::Was thinking of Legobot. Not sure the other is core, but Legobot is IMO. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 15:30, 16 October 2024 (UTC)
:::::::I don't see a lot of utility in a single summary score. I think the number of core bots should remain below the threshold where a group of people could go through them and determine relative priorities for attention. Plus, in a volunteer environment, who works on helping with what bot is going to be highly influenced by personal interest in the associated workflow, in any case. For an individual characteristic like "maintainable tech stack", there could be some usefulness in having a score, to help those not familiar with the details of the related technology to make relative comparisons. I would consider it to be more descriptive than analytic, though, to avoid getting bogged down in its precision. ] (]) 15:55, 16 October 2024 (UTC)


:::That poll is nearly worthless. Besides, it's outweighed by the nearly fifty (or more?) contributors to '''a single RfBAG nomination'''. —] • ] • ] 05:13, 9 May 2008 (UTC)
::::Just because I supported a RfBAG doesn't mean I support the process --] 09:09, 9 May 2008 (UTC)
:::::Heck, just because I ] doesn't mean I necessarily support the process. (FWIW, I'm rather ambivalent on the subject, and not particularly convinced by the turnout of my own RfBAG: 24 !votes including several ]s, as there would've been had it been closed on time, do not a very convincing consensus make.) I'm not sure what would be better, though; the best suggestion I've seen so far might be the one made by Betacommand above, involving multi-transcluded discussions (but please keep it out of ], thank you!), but I'm not really convinced even that would work all that much better. —] <small>(])</small> 09:53, 9 May 2008 (UTC)
::::::I commented as well when it appeared the system was going to be pushed through despite the opposiiton, even though I am strongly against the system. As the only criteria for success was "people use it" it was set up so that after implementation it couldn't possibly fail unless people completely ignored it (obviously not going to happen on one of the highest watched pages) or the bureaucrats forced it to stop. The attitude of "other peoples' opinions are worthless because people used the process" was what caused me to abandon this discussion before. <font face="Broadway">]'']</font>'' 17:57, 10 May 2008 (UTC)
::: I bet if put RfBAG nominations in the site notice, we would get lots of contributors. Should we put them in the site notice? ] 06:00, 9 May 2008 (UTC)
:::: Sure that sounds great, or .... {{trout}}— ] <sup>]</sup> 11:57, 9 May 2008 (UTC) {{clear}}
:::::You're really, ''really'' not helping the conversation '''at all'''. —] • ] • ] 15:24, 9 May 2008 (UTC)
::::::actually that was a very effective message. ] 15:25, 9 May 2008 (UTC)
:::::::'''You''' would think so. —] • ] • ] 15:27, 9 May 2008 (UTC)
::::::::Pot, meet kettle. --]]]<small>(st47)</small> 18:12, 9 May 2008 (UTC)


===Reuse for bots and tools===
* I wish people would not move comments around. My reply above about the "site notice" was to LCs comment about "fifty contributors", which comes across as: "we got more comments this way, therefore it's better". I was not actually suggesting putting it in the site notice; I was illustrating the problem with the argument by placing it in a different context. ] 21:08, 9 May 2008 (UTC)
Somewhat orthogonal to <s>all this</s> the above thread, in an ideal world, I'd love to see greater standardization across bots and tools. I've written a few of my own tools, but I spent a lot of time reinventing a lot of wheels to make them work. I know there's been some progress in this area (pywikibot is certainly a step in the right direction) but there is still a lot of effort expending by people running in different directions. Which in turn makes it harder to have people pick up other people's projects. ] ] 16:35, 16 October 2024 (UTC)
:{{ping|RoySmith}} as I imagine you've already heard, frameworks are wonderful: everyone should have one :-). It's a big challenge to create one that is usable by others, with sufficient documentation. There's {{section link|Help:Creating a bot|Programming languages and libraries}}, but it's mostly just a big list, without much guidance to help someone decide on what to use. I feel there should be a location for programmers to share experiences, but I'm not sure where that is. ] redirects to ], whose header makes it sound more like a co-ordination spot than somewhere to collaborate on development. ] (]) 21:31, 16 October 2024 (UTC)
::Some statistics would go a long way. ] lists a lot of options that nobody would recommend nowadays. While I don’t believe we should mandate any language or toolkit, it would help to inform new developers which languages and toolkits are used in bots in active use, especially more recent bots. At least half of the current BRFAs are Python with Pywikibot. ] (]) 22:18, 16 October 2024 (UTC)
:::I agree that knowing some basic usage info would be helpful. Whenever I look at a third-party library/framework/tool, I want to know how popular it is and how actively it is maintained, in order to get a sense of how likely it is to continue to maintained in future, how easy will it be able to find answers to questions, and how useful have others found it. But circling back to the problem of overhead scaring away developers, this also applies to those creating code and tools for reuse. Tracking this info and keeping it up to date is extra work, and it might be less interesting for a one-person team than working on their project. ] (]) 22:55, 16 October 2024 (UTC)


=== Not Eliminate reviewing bots === == Update the global bots section ==
Even if the community feels that having a special group of bot approvers is not the best method, I'm not getting the feeling that the community thinks that bots should just roam free either. If it is decided to abandon BAG, the approvals process will need to be replaced by something...perhaps xfd style where any admin can close out the discussion? — ] <sup>]</sup> 04:17, 9 May 2008 (UTC)
:Why not just a noticeboard format, where people can comment as they please? The crats can decide if they think there are outstanding objections. I don't think the "support/oppose" format matches well with bot requests; it's usually more like: "Here's an issue" / "OK, fixed" / "Here's a question" / "Yes, that's fixed"/ etc. &mdash;&nbsp;Carl <small>(]&nbsp;·&nbsp;])</small> 15:30, 9 May 2008 (UTC)
::We tried something like that before the invention of BAG. The silence was deafening. --] (]) 19:31, 9 May 2008 (UTC)
:::Right, pre March 2006. This was before local bureaucrats even made bots... I think times have changed somewhat. ''']''' ('']'') 19:46, 9 May 2008 (UTC)
::::Have you seen how highly active ] is, even after I added it to the noticeboard header? ''']''' <sup>]</sup> 19:48, 9 May 2008 (UTC)
:::::What does that have to do with anything? ''']''' ('']'') 19:51, 9 May 2008 (UTC)
::::::That is in theory a noticeboard where people can comment as they please about bots. ''']''' <sup>]</sup> 19:53, 9 May 2008 (UTC)
:::::::"This is not the place for requests for bot approvals". We are talking about the place where bots are approved. ''']''' ('']'') 19:56, 9 May 2008 (UTC)
::::::::So you'd like ] discussion sitting on a noticeboard page for a month? Along with the 30 or so other open Bot reqs? Do we now hate people without gigabit ethernet connections? ''']''' <sup>]</sup> 20:04, 9 May 2008 (UTC)
:::::::::I don't want a noticeboard. I want a "request for bot status" page, similar to XfD. ''I'' never mentioned a noticeboard. Oh and people comment on RFAs all the time, which are a lot bigger than that. ''']''' ('']'') 20:57, 9 May 2008 (UTC)
:Yes, set up an XfA system for bots. It works for the other processes where it is implemented, and it will work for bots as well. Every other project I have encountered uses an XfA system for bots, why does Misplaced Pages have to be different? ''']''' ('']'') 22:01, 9 May 2008 (UTC)
:: BRFA is an XfDiscussion system. ] 22:28, 9 May 2008 (UTC)
:::But the bots are approved by a little Cabal. The community should be doing that, not a club. ''']''' ('']'') 22:49, 9 May 2008 (UTC)
:::: The community left the job of approving bots with BAG, and the community expresses its opinion on BAG members whenever anyone wants to join BAG. ] 23:55, 9 May 2008 (UTC)
:::: Then ] ], if its deleted, then the community shows it doesn't want BAG, if its kept, then its shown the community wants BAG. ''']''' <sup>]</sup> 01:09, 10 May 2008 (UTC)
:::::], ]. The result was "speedy keep", and we have to discuss it here. Apparently BAG is exempt from being deleted. ''']''' ('']'') 06:29, 10 May 2008 (UTC)
:(outdent) If left to 'crats to close, is the suggestion that crats approve all bots, or just the 'bot flag', if just the flagging, having any bot do anything (without a flag) is still likely to be excessive. — ] <sup>]</sup> 03:33, 10 May 2008 (UTC)
::There are really two issues here — flagging of bot accounts and community review of bot tasks in general — and it might be best if they were actually kept separate, so that we'd have "Requests for bot status", which would be an ]-style poll closed by those authorized to grant the bot flag (currently 'crats, though I'd personally support giving this ability to a broader group), and a separate "Bot review", in the style of ] or even ], for discussing proposed and ongoing bot tasks to see if they enjoy community support. Of course, the processes would still be connected to some extent, since nobody's likely to support flagging a bot account unless there's consensus for it to perform at least one task, but it might still simplify things (or not; the idea is to actually make the new processes simpler and less formal, not just take the existing bureaucracy and double it). —] <small>(])</small> 14:03, 10 May 2008 (UTC)
:::The solution is simple, really. Tag ] with {{tl|historical}}, then add the ] page to show up on the ] page. The intended task will be listed on the page, at which point, if consensus exists for the function, the operator will run the bot. After everything has been figured out and the majority of those who have expressed their opinions are please, a 'crat will the then flag the bot if need be, or approve it if it is to run without a flag. The guiding principle for the 'crats will be ], instead of the arbitrary rulings of BAG. ''']''' ('']'') 03:59, 11 May 2008 (UTC)
::::Is such a complex procedure really needed for yet another interwiki or newsletter-delivery bot? --] (]) 17:50, 11 May 2008 (UTC)
:::::It's no less complex than BAG approving it; except this way, the community will be instead. ''']''' ('']'') 17:54, 11 May 2008 (UTC)
::::::If there is not a stable consistant group that over sees bots, we will run into some major problems. there are bots that come up, often and are denied as often, (IE WelcomeBot). you might have consensus for the bot from a group of editors, but the bot should still be denied. given the nature of bots you need a stable group to manage them. bot approvals SHOULD NEVER be a vote. bot approvals function as a discussion and safety check. removing the bot oversight is asking for trouble. ] 19:38, 11 May 2008 (UTC)
:::::::Why should it be denied? Because you don't like it? That is precisely what is wrong with all this. The bots that get approved are ones that ''you'' like, and not necessarily the community. Other wikis manage without an arbitary little group, and so can we. I have never even mentioned having a vote, instead I said a discussion. In other words, it would be just like it is now, ''but without BAG''. I understand you and Carnildo would hate the idea of your little club being disbanded, and the community rightly deciding on these issues, but BAG is simply not needed anymore. And if we don't get consensus here, we'll have to MfD it, and you'll have to provide some sort of an argument to keep it, instead of shouting "Speedy keep!" ''']''' ('']'') 19:44, 11 May 2008 (UTC)
::::::::''My'' little club? Perhaps you should look at how active (or rather, inactive) I've been at approving bots, and then cease with the personal attacks. --] (]) 00:09, 12 May 2008 (UTC)
:::::::::I haven't made any personal attacks. It strikes me as odd you'd show up here to defend this group if you say you aren't even active here. You've still not said how having a little group approve instead of the community is better. ''']''' ('']'') 00:18, 12 May 2008 (UTC)


Hi, currently the global bots policy says that (]) global bots can only run on this wiki for the purpose of fixing double-redirects. I believe that is outdated, because it links to a discussion from 2008 and Meta policies have changed global bots in 2021 to allow running any task that is approved. I think this requires a change on this wiki as well, as otherwise it can be rather confusing. I propose allowing global bots to run here for any approved task, especially since en.wikipedia will be notified when anyone submits a global bot request. After all, this wiki can still instruct any bot not to run here, if required. If not, I recommend adding this wiki to the opt-out set so that global bots are completely disabled (rather than enabled for just one purpose). ] (]) 06:49, 12 September 2024 (UTC)
I don't think that BAG "rulings" can be described as arbitrary by any measure. We're faster than a one-week RfA. We've rarely approved any bot that didn't have community consensus. We've rarely denied any bot that wouldn't have community consensus &mdash; very few bots are declined at all. &mdash; ''']''' '']'' 07:29, 11 May 2008 (UTC)


:Applying for local bot approval here should still be required for bots here, our community and project are huge and expect our bot operators to be engaged here. As far should we kick out all global bots that are doing the task they are already approved for, that doesn't seem to be necessary. — ] <sup>]</sup> 09:32, 12 September 2024 (UTC)
===Eliminate bot approval entirely===
: Any change to the policy would need consensus for that change, here on the English Misplaced Pages. That discussion could be held here, but would need to be an actual RFC or other widely-advertised and widely-participated in discussion. Personally, I'd want to see more reason to change the policy than given so far. ]] 12:07, 12 September 2024 (UTC)
Given issues with BAG lately (notably their inability to comply with the will of the community) I support eliminating the BAG entirely. But further, I think we should stop approving bot tasks for the simple reason that we don't require editors to get approval for their edits before they make them, so we shouldn't be requiring bot operators to get approval for tasks prior to initiating them. All edits can be undone/reverted, so any potential damage is temporary at worst. I think that really just leaves the matter of how one applies for and receives a bot flag. I believe this is something we can do a number of ways, but the two most obvious ones to me are:
::Agreed. ] (]) 13:16, 12 September 2024 (UTC)
# Implement an RFA-style system for obtaining the bot flag (as with RfBAG, this would give us the widest exposure to the community, providing more input than obscure talk page discussions)
:Why is this change needed, and which specific global bots would help improve the English Misplaced Pages under a more permissive policy? ] (]) 00:18, 30 September 2024 (UTC)
# Implement a system where the candidate contacts a bureaucrat directly (or via the noticeboard for 'crats), is given a trial run/grace period of a week (during which edits will be performed sans bot flag, and observed for potential issues), and assuming no problems are found, is given the bot flag directly
::@] This is more for consistency, because I would normally not request local bot rights on a wiki that's not on the global bots opt-out set unless I know that it does not accept all kinds of global bots. I do not have any specific global bots in mind for this reason. Other wikis in this group include the Russian Misplaced Pages, where global bots are allowed but appear to reference old policies. ] (]) 14:02, 2 October 2024 (UTC)
The first option provides more input from the community, and could actually include portions of the second option (for example; during the RfBotFlag, a trial run may be performed to demonstrate that the bot is working correctly). The latter option is less formal and would still allow community input (nothing stops concerned editors from watchlisting 'crat talk pages and the noticeboard).
:::{{tq|I would normally not request local bot rights on a wiki that's not on the global bots opt-out}}. Good point. Maybe we should add our wiki to ] as "not allowed" so that global bot operators don't accidentally run global bots here. –] <small>(])</small> 00:23, 3 October 2024 (UTC)
:The only relevant change I see from 2021 is , which does not say what you say it says. Is there another change somewhere else? ] (]) 19:52, 30 September 2024 (UTC)
::@] That's the one actually - why do you think that it "does not say what you say it says"? ] (]) 14:03, 2 October 2024 (UTC)
:::The change on meta changed the requirements for meta. It did not change the requirements here, so when you say {{tq|I think this requires a change on this wiki as well}}, it reads as if you think we must be consistent with global policy. "Confusing" it is not: we simply have different requirements. ] (]) 17:21, 2 October 2024 (UTC)
::::@] Actually, that is what I was hinting at - "fixing double redirects" is just a single task that I am not convinced is needed as a specific exemption. And I was also saying that en-wiki is not the only wiki in this group, where it appears that the rules were created when the global bot policy was more restrictive. Also the policy change in Meta ''did'' change the rules for every wiki allowing global bots that did not explicitly have a restriction. ] (]) 06:03, 3 October 2024 (UTC)
:::::If I'm understanding correctly, meta has a policy allowing global bots, but that policy doesn't mandate that the bots can be run on the individual wikis without their consent. Each wiki can make its own decisions on what bots it wants to accept. ] (]) 06:56, 3 October 2024 (UTC)
::::::@] Yes and no. The global policies are global and individual wikis cannot "opt-out" of it. However, individual wikis can set preferences in terms of how they want global bots to use their bot flag, but I've seen a few wikis (eg this one) that references ''old'' Meta policies in doing so (which is what I want to correct) - I've not seen a single wiki that explicitly sets such restrictions ''while'' referencing the updated 2021 rules - nor have I seen any wiki yet have restrictions other than allowing fixing double-redirects/interwiki language links.
::::::And also, regarding "policy doesn't mandate that the bots can be run on the individual wikis without their consent", yes it isn't a "mandate", but the whole point of global bots is to avoid having operators request bot flags on every wiki, and hence if I were a global bot operator, I wouldn't go around asking for permission on global bot-approved wikis, unless I already know that the said wiki does not allow global bots for any approved purpose. And I cannot do this for all of the 800+ wikis that allow global bots either.
::::::TLDR; yes "wiki can make its own decisions on what bots it wants to accept", but to do so would kind of defeat the purpose of global bots. ] (]) 07:31, 3 October 2024 (UTC)
::::::: You're making a false distinction in {{tq|q=y|I wouldn't go around asking for permission on global bot-approved wikis, unless I already know that the said wiki does not allow global bots for any approved purpose}}, which IMO makes your argument unconvincing. If you (as a global-bot operator) know enwiki only allows interwiki-fixing global bots without separate approval, why would you ''not'' ask for permission if you want your double-redirect-fixing bot to run here? If your only complaint is that ] isn't clear enough, an easier solution might be to improve that page. {{tq|q=y|The global policies are global and individual wikis cannot "opt-out" of it.}} Except this one they can. Even if the global bot policy didn't explicitly say so, I think you'd find that we don't necessarily accept here any random "policy" that someone on Meta declares is "global". {{tq|q=y|I've not seen a single wiki that explicitly sets such restrictions ''while'' referencing the updated 2021 rules}} You have, this one. ]] 12:12, 3 October 2024 (UTC)
::::::::@] The bot page links to a discussion from 2008, not 2021. Put it this way: I ''know'' I have to apply for local bot rights. Would someone else not familiar with en.wiki? ] (]) 21:15, 3 October 2024 (UTC)
::::::::: They should if they read ]. ]] 11:27, 4 October 2024 (UTC)
:::::::The global policy says {{tq|The operator should make sure to adhere to the wiki's preference as related to the use of the bot flag.}} It explicitly allows each wiki to make its own decisions on what bots it wants to accept. ] (]) 15:58, 3 October 2024 (UTC)
::::::::@] I don't dispute that, and I don't also dispute that en.wiki is ''not'' doing anything wrong per se. However, I do believe that en.wiki created this exemption in 2008 when Meta rules were different, and believed that it needs at least a relook in 2024. How and what I'm not too bothered with - the other contributors have a lot more experience than I. Put it this way: I would rather have en.wiki put itself in the global bot opt-out set so that it's clear to everyone that you ''must'' apply for a local bot flag, rather than this weird one-task exception which isn't obvious unless you actually go to the bot policy (and it's not like it's any more difficult for bot operators fixing double-redirects to file a local bot flag request than a global bot operator for any other task). ] (]) 21:21, 3 October 2024 (UTC)
::::::::: As I mentioned back at the beginning of this, if you want a reexamination then creating an RFC is the way to go. If you want to start drafting one (I recommend a draft to reduce the chance of confusing wording issues), feel free. ]] 11:27, 4 October 2024 (UTC)
::::::::::I'm not motivated enough to do it - you all have more experience than I. I just posted here as a suggestion for improvement - it appears to me that the community does not feel this to be worth it. ] (]) 19:37, 4 October 2024 (UTC)
== "]" listed at ] ==
]
The redirect <span class="plainlinks"></span> has been listed at ] to determine whether its use and function meets the ]. Readers of this page are welcome to comment on this redirect at '''{{slink|Misplaced Pages:Redirects for discussion/Log/2024 October 12#Bot policy}}''' until a consensus is reached. <!-- Template:RFDNote --> <span style=white-space:nowrap;>] <span style="background-color:#e6e6fa;padding:2px 5px;border-radius:5px;font-family:Arial black">]</span></span> 20:40, 12 October 2024 (UTC)


== BAG nomination ==
As for bots who perform disputed operations, we should handle this like we handle any editor making disputed edits: discuss directly with the operator, get comments from the community via RFC, go to AN/I and, if the matter isn't solvable with the bot operator, then the matter can be taken back to the 'crats to discuss removing the bot flag (and thus that editors privilege to perform unattended automated edits). Thoughts? —] • ] • ] 00:20, 12 May 2008 (UTC)
:you need a reality check. stop attempting to push your POV. its getting disruptive. I would suggest that you avoid bot related topics because you seem to fail to understand what bots are, why we have a bot policy and why we have an approval system. RfX is broken like a square wheel. Im done attempting to talk with people who are attempting to re-write bot policy when they know absolutely jack shit about bots. if you ever figure out what the term "bot" means please come back, but until then stop spewing ideas that my dog even knows wont work. ] 00:49, 12 May 2008 (UTC)


::Betacommand, please read ] carefully before you reply again. The only thing that is "shit" around here is BAG and the members viciously defending it. ''']''' ('']'') 01:28, 12 May 2008 (UTC) Hi! I have nominated myself for ] membership. Your comments would be appreciated on the ]. Thanks! – ] <small>(])</small> 14:04, 18 January 2025 (UTC)

Latest revision as of 12:34, 19 January 2025

This is not the place to request a bot, request approval to run a bot, or to complain about an individual bot
This is the talk page for discussing improvements to the Bot policy page.
Shortcut
The project page associated with this talk page is an official policy on Misplaced Pages. Policies have wide acceptance among editors and are considered a standard for all users to follow. Please review policy editing recommendations before making any substantive change to this page. Always remember to keep cool when editing, and don't panic.
Media mentionThis policy page has been mentioned by a media organization:
Bot-related archives
Noticeboard1, 2, 3, 4, 5, 6, 7, 8, 9, 10
11, 12, 13, 14, 15, 16, 17, 18, 19
Bots (talk)1, 2, 3, 4, 5, 6, 7, 8, 9, 10
11, 12, 13, 14, 15, 16, 17, 18, 19, 20
21, 22
Newer discussions at WP:BOTN since April 2021
Bot policy (talk)19, 20, 21, 22, 23, 24, 25, 26, 27, 28
29, 30
Pre-2007 archived under Bots (talk)
Bot requests1, 2, 3, 4, 5, 6, 7, 8, 9, 10
11, 12, 13, 14, 15, 16, 17, 18, 19, 20
21, 22, 23, 24, 25, 26, 27, 28, 29, 30
31, 32, 33, 34, 35, 36, 37, 38, 39, 40
41, 42, 43, 44, 45, 46, 47, 48, 49, 50
51, 52, 53, 54, 55, 56, 57, 58, 59, 60
61, 62, 63, 64, 65, 66, 67, 68, 69, 70
71, 72, 73, 74, 75, 76, 77, 78, 79, 80
81, 82, 83, 84, 85, 86, 87
Bot requests (talk)1, 2
Newer discussions at WP:BOTN since April 2021
BRFAOld format: 1, 2, 3, 4
New format: Categorized Archive (All subpages)
BRFA (talk)1, 2, 3, 4, 5, 6, 7, 8, 9, 10
11, 12, 13, 14, 15
Newer discussions at WP:BOTN since April 2021
Bot Approvals Group (talk)1, 2, 3, 4, 5, 6, 7, 8, 9
BAG Nominations


Open source bots

I would like to do a temperature check (explicitly not an RfC) as a follow-up to the discussion at this BRFA, of how people feel about changing the source code requirements. Currently the language in the bot policy is:

Authors of bot processes are encouraged, but not required, to publish the source code of their bot. and for adminbots: It is recommended that the source code for adminbots be open, but should the operator elect to keep all or part of the code not publicly visible, they must present such code for review upon request from any BAG member or administrator.

I would like to replace it with something like: "Authors of bot processes are expected to publish the source code of their bot in a public manner under an open source license to facilitate collaboration and forking. Should an author wish to keep the source code private, they must request an exemption from BAG during the bot approval process. BAG members may decline requests solely on the basis of source code not being open source." And some kind of grandfathering clause for current closed source bots.

The rationale being 1) allowing people to suggest improvements for bots or point out possible bugs as a technical review step, and 2) when bots/maintainers inevitably disappear, mandate that there is a path for someone else to take over the bot without starting from scratch. I think the Wikimedia movement has moved in this direction, with requiring open source licenses for bots run on Toolforge (the vast majority of our bots) and there's an abundance of places to post your code. Or in other words, open source should be the norm, private should be an exception.

Some carve outs: I'm sure people can come up with edge cases where publishing code isn't desired; if those turn into actual BRFAs, I'm happy to defer the decision to BAG on whether the exception is justified or not. As a practical matter, I think it would be fine if people make changes, test their code, and then publish it shortly after. I don't think we need a hard requirement that code must be open source before you run it against Misplaced Pages.

So temperature check: how do people feel about this? Is this a reasonable proposal? Or if you would not support something like this being formalized, why not? Legoktm (talk) 03:54, 5 September 2024 (UTC)

Looks ok to me. I expect open source codes for bots as well. It helped with the takeover of the AdminStats task (although we ended up hunting for a copy of the codes in Toolforge itself). However, can the grandfather clause be extended into new task requests of current bots as the new tasks may still utilise the closed-source codes. – robertsky (talk) 04:03, 5 September 2024 (UTC)
I don't see why we should bake 'they must be open, unless you ask for an exception, which we may deny' into policy, rather than the current 'we encourage, but don't mandate, open source bots'. Headbomb {t · c · p · b} 10:00, 5 September 2024 (UTC)
@Headbomb: Could you expand on why you don't think it should be done? (I personally don't think we need an exception, I just expected people would oppose it without one) Legoktm (talk) 15:35, 5 September 2024 (UTC)
I'm also curious about this, but I do see that allowing for exceptions is a reasonable thing to do. Imagine if somebody came to us and said, "The company I work for has an abuse-detection system that's 10x better than what you're using now. We're willing to let you use it at no cost, but unfortunately I cannot make the code available". Having that exception carve-out gives us the ability to accept or refuse that offer as we see fit at the time. Not having that carve-out forces our hand. I think that's reasonable.
We already have agreements like that with some IP proxy detection vendors (I'm being cagey here about the vendor names only because I'm not sure of the status of these relationships). Because they are only (to the best of my knowledge) used as back-ends to some interactive tools, they don't fall under BAG's remit. But I could certainly imagine somebody wanting to build a BAGgy tool which uses one of those services as a back end. As much as I believe in FOSS everywhere, I also wouldn't want us to shoot ourselves in the foot to stand on principle. RoySmith (talk) 16:04, 5 September 2024 (UTC)
You might not want to put your code up because it's crude/inelegant. You could also be doing things that is "OK" with private code, that isn't OK with public code, like having "if password = sw0rdf!sh continue, else fail" instead of whatever you should be doing with passwords and logins. Or you might be using code from someone else that you got permission to use, but didn't get permission to distribute. Or you may be using closed source code that you purchased, but don't have rights to distribute.
Like, I'll agree it's unequivocally better to have things open sourced. Hence why it should be encouraged. But volunteer coders are an extremely limited resource, so the fewer barriers to entry/participation we have, the better, IMO. Headbomb {t · c · p · b} 19:12, 5 September 2024 (UTC)
  • Strong support Requiring bots to be open source seems like a good idea to me for reasons ranging from cultural (supporting the goals promoting the ideals of the Wikimedia movement) to security (code review) to disaster recovery (being able to continue operation of critical services should the original developer disappear). RoySmith (talk) 12:15, 5 September 2024 (UTC)
  • I mainly pushed back against this in the above BRFA because I felt it violated current norms. But I am not opposed to it in general if we make a change to BOTPOL. There are major maintainability advantages to having bot code open sourced. Volunteers that write critical code lose interest or go inactive all the time. Honestly maybe a proposal to require Toolforge for non-AWB bots might also be worth considering. The combination of open sourced code plus Toolforge would be the ideal situation for rescuing abandoned bots. Finally, we also had a situation recently where an operator passed away and their bot was immediately blocked and globally locked. Avoiding blocking working bots ASAP, giving time for us to properly fork and replace them, might be worth adding to BOTPOL as well. –Novem Linguae (talk) 16:18, 5 September 2024 (UTC)
    This is a good point; as anybody who has ever tried to port anything knows, just having the source code is only half the battle. Moving things to a new operating environment can be a pain too; requiring that everything runs in Toolforge (or Cloud VPS) would be a good thing IMHO. I'm not sure where you draw the line, however. Some people would insist that everything run in a Docker container. That would drive me nuts. Some people would insist that we only use phab, gitlab, and so on. That would also drive me nuts. RoySmith (talk) 17:01, 5 September 2024 (UTC)
    I think you're underestimating how successive additional requirements hinder attracting new volunteers. It's no big deal to experienced developers, but there is already a lot to navigate as a new developer. Of course, if the goal is to reduce the number of abandoned bots, discouraging new bots will definitely help. I think it would be better to encourage practices like source code availability, succession plans, etc. with a dashboard, recognition, and other approaches. Daniel Quinlan (talk) 20:14, 5 September 2024 (UTC)
  • I'm strongly opposed to the proposed change. The current policy encourages open source without being overly restrictive or discouraging of people submitting requests. As an open source developer, I think that's a good thing. But requiring all bots to be open source could discourage some potential projects, especially if they use proprietary code or need to use non-free components. For some projects, there are also security-related reasons to not open source code for the same reasons we have private edit filters. Finally, if there are specific bots that are truly critical and not open source, we should identify those bots and solicit for replacement bots that would be open source, or ask the WMF to write, maintain, and operate replacement bots for those functions. The current policy is well-written. Daniel Quinlan (talk) 21:04, 5 September 2024 (UTC)
    Part of my concern is that if it's necessary to grandfather existing bots, it strongly implies that there would be a chilling effect on future proposals, for both existing and new bots. I’d prefer to start with a review of existing bots to assess their criticality and succession plans, and then consider improvements based on the assessment. Policy changes might be one approach, but I believe that providing encouragements that won't discourage future projects, and can be applied to all bots, would be more effective. Daniel Quinlan (talk) 22:25, 5 September 2024 (UTC)
  • I appreciate the feedback that people have given and will reply a bit later after digesting them, but please, can we avoid the bold votes? I would like to focus on the discussion and rationales not ... voting. Legoktm (talk) 21:39, 5 September 2024 (UTC)
    Sorry if the bold came across as harsh, I was following the format of an earlier comment. I appreciate you following up on the discussion to discuss it out in the open which will reduce the odds this is rediscussed in random future BRFAs. Daniel Quinlan (talk) 22:10, 5 September 2024 (UTC)
  • I think the circumstances have to be taken into account. If the bot is going to be a one-time simple task, it's probably less critical to have a succession plan in place. If it's a bot that's going to underpin key workflow processes, then having a plan for ensuring that the task can be handed off is more important. I agree that ideally all code would be open source (keeping any necessary private configuration closed) and with a relatively uniform development and runtime environment, but practically speaking, I don't think English Misplaced Pages can afford to limit its potential pool of developers to that degree. isaacl (talk) 23:48, 5 September 2024 (UTC)
  • I would unequivocally support something stronger for bots expected to be a continuing run as "we require open source" and would definitely encourage something like the OP even for shorter runs. I'm sorry, but we cannot continue to depend on closed source bots and private source. (I have said as much multiple times now.) And sorry, if your code is shitty, that's how open source works. Either you can get over your fear of publishing something that is hacked together (as if no one else has hacked together code into production, know how modern MediaWiki started?) or you can do something else with your time (which I'm sure will be productive for wiki goals as well). Izno (talk) 18:00, 29 September 2024 (UTC)
    While having code available is a good start, if we're going to introduce some requirements for succession planning, I don't think it should stop there. Too many people think if the source is available, all is good. But if it's Haskell code, for instance, the pool of potential contributors is significantly smaller. So if we start on this route, I think we need to also include things like the bot has to run on the toolforge servers, the language is highly recommended to be from a list of supported languages, and there is at least one other maintainer actively involved. isaacl (talk) 21:34, 29 September 2024 (UTC)
    Before we consider a stricter policy for some cases, we need to be specific about which bots are actually critical. Requiring people to code in specific languages, or get up to speed on Toolforge on top of learning MediaWiki APIs for a bot that quietly does its own thing, isn't mission critical, etc. is going to be counterproductive. We need more people, especially newcomers to Misplaced Pages coding, writing more helpful bots, and we should endeavor to keep the cost of entry as low as reasonably possible. The ideal case is always going to be easily portable and well maintained code, but no requirements are going to keep us from avoiding some inevitable realities of the software lifecycle and the perfect is the enemy of good. Daniel Quinlan (talk) 00:13, 30 September 2024 (UTC)
    Let's tackle one thing at a time. I happen to agree that it makes sense to state an increased expectation for these other qualities, but I think we have to start from "someone could even theoretically pick this up and run with it". Izno (talk) 00:52, 30 September 2024 (UTC)
    I think a little bit more is needed to lay the base to enable someone else to theoretically operate a given bot. It could be one of the following: tool runs on toolforge, there are multiple active maintainers, or there is sufficient up-to-date written documentation that describes the software stack and execution environment. And, unfortunately for aficionados of more obscure languages, I think there should be a list of highly recommended languages. isaacl (talk) 01:28, 30 September 2024 (UTC)
    On the one hand, I endorse all of these as obvious good things. And to that I'd add that the source has to be publicly available in a standard source control system (which these days basically means git). It's one thing to say the code is under an FOSS license, but if the distribution mechanism is to download a ROT-13'd shar file from a gopher server, it might as well not exist. And it should have a comprehensive test suite. And an issue tracking system. And code reviews. Well, you see where this is going. All of these things are essential good software engineering practices, but each one is also a barrier to entry for a lot of people, and at some point we need to make an intelligent decision about where we want to draw the line. If we chased away every potential code contributor with onerous requirements, we'd certainly solve the problem of tool migration because we wouldn't have any tools. RoySmith (talk) 01:58, 30 September 2024 (UTC)
    Yes, I already stated I don't think English Misplaced Pages can afford to limit its potential developer pool for all its tools. I think when a tool or bot is planned for deployment, we need to decide how important it is to have some form of succession plan in place. In many cases, we may just live with the risk. For some key processes, we may want to plan for future transition to different maintainers. isaacl (talk) 02:33, 30 September 2024 (UTC)
  • I have nothing against publishing my code. I acknowledge that the code quality is far from ideal, since I don't get a lot of time to work on it, and my decision to use C# may not have been the best. The bots have worked their way into some of our processes, so it might be good if someone could at least see what they do in case something happens to me. I would have to go through the files and add the appropriate copyright notices. I am unsure what counts as an open licence; my intent was always to use GPLv3. Once a licence is applied though, it will be hard to change, so a grandfather clause would be necessary. And yes, moving things to a new operating environment is a real pain; Toolforge now insists that everything run in a Docker container. Getting that to work has been taxing, and would have been impossible without a lot of help from the Toolforge admins. Hawkeye7 (discuss) 20:25, 29 September 2024 (UTC)
    Toolforge currently requires an OSI-approved license. That seems like the right expectation to me. Comparison of free and open-source software licenses might be useful for your own review of what you might license your code as. Izno (talk) 00:54, 30 September 2024 (UTC)
    I found the policy at Help:Toolforge/Right to fork policy. I haven't actually implemented it yet. Hawkeye7 (discuss) 04:56, 2 October 2024 (UTC)
    I think the docker container part is just picking an image on toolforge. You don't need to install docker on your local computer, nor do you need to know much about docker except for the one CLI command to run and which image you are going to pick from the list of images. My bots are written in PHP and I use xampp locally to run them when I am doing coding and manual tests. –Novem Linguae (talk) 15:59, 30 September 2024 (UTC)
    Not an image, but a cloud native build pack. The build pack creates the container image. I had to get them to install a dotnet build pack for me. Running docker locally was no problem; getting the application to work properly in that operating environment took more effort. Hawkeye7 (discuss) 21:30, 30 September 2024 (UTC)
    I previously looked at getting a .NET app to run on Toolforge but they didn't have any "official" support so I couldn't be bothered to figure it out and I concluded I would need to get in touch with them to add this support. This is in addition to all the hoops one has to jump through to figure out how to do things there. None of it is user-friendly, that's for sure, speaking of barrier to entry and all that. Anyway, this did not exist at the time. I might ping you at some point to ask you how exactly you did it if I can't figure out stuff from the documentation. I don't suppose you recorded the steps you took to get it working? —  HELLKNOWZ  TALK 22:27, 30 September 2024 (UTC)
    Yes, I recorded the steps I took. Hawkeye7 (discuss) 04:53, 2 October 2024 (UTC)

Bots with available source code

List

See: Misplaced Pages:Core bots

Discussion

Based on the above, there appears to be a reasonable consensus that most (if not all) bots that do "core functions" (my phrasing) should have their code posted so that if the operator disappears (intentionally or not) the functionality can be quickly/easily/efficiently ported onto a new bot/operator who can take over the task. I have started a (currently empty) list above, and would invite editors to add and discuss the list so that we can start asking operators to provide the code if deemed necessary. Personally speaking I think this list should focus on open-approval tasks (i.e. not one time runs) to start, but if someone wants the code for OTRs feel free to ask. Primefac (talk) 19:30, 29 September 2024 (UTC)

I think there's a tendency for the general editing population to think if the code is available, it should be easy for anyone to step into the void and quickly get a bot running, but that's a fallacy. I think if we're going to introduce requirements for succession planning, they should cover a bit more (as I discussed in an earlier comment). isaacl (talk) 21:37, 29 September 2024 (UTC)
I don't see that consensus. We all agree it's preferable. But mandatory is different. Headbomb {t · c · p · b} 00:51, 30 September 2024 (UTC)
I think the consensus is for a stronger policy than saying it's "preferable" (which we already do). We could make some exceptions for long-standing bots, such as AAlertBot, which is I think what you are primarily concerned about. – SD0001 (talk) 12:04, 30 September 2024 (UTC)
I don't see such consensus at all. Headbomb {t · c · p · b} 15:21, 30 September 2024 (UTC)
A mandatory policy is a recipe for "consensus" to shut bots down or worse remove bot privs fpr being a rouge operator. What else could "mandatory" mean? Which is like that Vietnam War saying, "We had to destroy a village to save it" (variations of this quote). Isaacl is exactly right that dumping a bunch of source to GitHub is meaningless for anyone trying to install and operate it. And some bots the operation requires a lot of training that is not easy to document. -- GreenC 23:47, 30 September 2024 (UTC)
shut bots down. I imagine any new requirements would have an exception for bots approved before the new requirement. –Novem Linguae (talk) 00:44, 1 October 2024 (UTC)
Where in my post did I say mandatory? I did not, so to disagree with something I didn't say is a little odd. This sub-thread is about taking the first steps - right now we don't even know which bots have open-source or freely-available code bases, or where they're hosted, etc. Primefac (talk) 12:38, 5 October 2024 (UTC)
I get where everyone is coming from with the desire to make sure bots keep running smoothly, but it's not clear to me that there's consensus making open source mandatory. I'm concerned that:
  • The focus is open source and adding extra requirements instead of having succession plans.
  • There aren't clear definitions for terms like "critical" or "core" and we don't have a list of the bots that would be impacted.
  • Grandfathering some bots might mean we end up with all of the downsides that will discourage future development without significantly improving continuity.
I've only written one bot so far, one that's trivial to set up and also open source, but it likely wouldn't exist if I had to produce open-source code before getting project approval or had been required to use Toolforge for my first project. The problem that Protection Helper Bot solves has been a Phabricator ticket since 2012 and proposed multiple times before and since then (such as this discussion in 2017). We should be encouraging new developers to help solve long-standing problems rather than throwing up roadblocks, even if they seem like low bars to most experienced Misplaced Pages developers. Daniel Quinlan (talk) 01:03, 1 October 2024 (UTC)
I never said anything about anything being mandatory. Primefac (talk) 12:38, 5 October 2024 (UTC)
You're right, "mandatory" was used by another commenter. However, I do actually believe setting the expectation that core functions should make their code available would likely turn that expectation into a requirement in practice. The policy already recommends it and that seems to be interpreted aggressively at times in BRFA discussions. I would also like to understand the current situation before changing the policy. Daniel Quinlan (talk) 01:21, 6 October 2024 (UTC)
Your bot was the exception as it's an adminbot that touches protection of articles. Most BRFAs have no requirement or request to release their source, and don't in practice. ProcrastinatingReader (talk) 21:13, 14 October 2024 (UTC)
I agree with the bot policy that source code for adminbots should be open or the developer must present such code for review upon request from any BAG member or administrator. My previous comments should not be interpreted as contradicting that. I designed my bot to be easy for anyone to run by releasing the code as open source and ensuring it's easy to set up. However, I believe it's fair to say that some of the additional requirements that have been discussed would have likely deterred me from submitting a BRFA. Daniel Quinlan (talk) 23:11, 14 October 2024 (UTC)
Mandatory or whatever aside, I think there is merit to us having a list of what we think are "essential" bots, along some idea of what the succession strategy for these bots is. (any of: is source available? are they hosted on Toolforge with multiple maintainers?) ProcrastinatingReader (talk) 21:12, 14 October 2024 (UTC)
I added a couple bots to the list started above. I also included how esoteric their tech stack would be considered these days (ie: how easily could someone take over maintaining it with updates/fixes). Bots using pywikibot or mwbot-rs for example I think are quite accessible. Custom C++ code or even Perl code I'd say is not particularly easy to take over. Realistically there's nothing we can do about these, but it's worth remaining aware of our bus factor.I'm loosely defining "core" as the bot disappearing causing noticeable disruption to the encyclopaedia, some significant process, or otherwise meaningfully impacting the quality of articles. ProcrastinatingReader (talk) 21:46, 14 October 2024 (UTC)
I suggest creating a parent list of key English Misplaced Pages processes/ongoing work items, and under them listing the essential automated tasks for those processes/work items. (I understand that some bots may be grouped under multiple processes/work items.) At the very least, it would be helpful to those not familar with all the bots if the list could include a brief summary of their essential tasks. isaacl (talk) 21:54, 14 October 2024 (UTC)
Do you mean something like this? User:ProcrastinatingReader/Core bots ProcrastinatingReader (talk) 22:04, 14 October 2024 (UTC)
Yes. Basically a breakdown by workflow: here's an important process (which might be doing a set of ongoing work items), and here're the key elements that are automated in order to make this sustainable. I was thinking that depending on the size of the lists, or the number of bots that support multiple workflows, it might be worthwhile to keep the bot list with its details separate, and just have the workflow list point to the bots in the bot list. I feel this makes it easier to think about what workflows are absolutely necessary to keep running (and think of ones that are missing from the list), and to know what they rely on. isaacl (talk) 22:23, 14 October 2024 (UTC)
Thanks isaacl, I think this is a good idea. I'd like to suggest a single list for now, unless it transpires that it's common for single bot accounts to do multiple core tasks? I think it's easier than correlating entries across two lists, if we can avoid it.
I am thinking there's a few things we should understand about each bot, rather than just asking "is the source available". I've tried to summarise these in the lead of Misplaced Pages:Core bots. I give the example of ClueBot NG there - I think the fact that it's an ANN model using C++ and an uncommon C++ framework means someone outside the core development team is unlikely to be able to pickup that bot as-is and realistically maintain it, as opposed to just running it.
With that in mind, I'm wondering if it might be good to develop a simple criteria to assess a bot against, to serve as a decent summary statistic compared to raw-text comments. e.g. categories like: "source available and executable?" / "multiple maintainers?" / "maintainable tech stack?", on which a bot can get a binary score (good/bad). These categories are mainly just to illustrate the idea. I'm not fixed on what kind of framework we should assess bots against for a realistic 'operational resiliency' strategy. ProcrastinatingReader (talk) 11:06, 16 October 2024 (UTC)
Could also do a scale of 1-5. Being hosted on Toolforge could add a point, source code published could add a point, active maintainers could add a point, etc. –Novem Linguae (talk) 13:25, 16 October 2024 (UTC)
Point systems are pointless (pun unintended). Let's not have a metric that serves no actionable purpose for sake of having one.
That said, what's the RFC bot? It should go on the core list. Headbomb {t · c · p · b} 14:26, 16 October 2024 (UTC)
@Headbomb: There are two RFC bots:
  • Legobot (talk · contribs) once an hour (i) detects {{rfc}} transclusions that lack a |rfcid= parameter, and adds one; (ii) ensures that the next valid timestamp after every existing {{rfc}} tag is less than thirty days in the past, and if not, removes the {{rfc}} tag and also removes the RfC statement from all of the listings (such as WP:RFC/BIO); (iii) checks the RfC category parameters for each {{rfc}} transclusion, such as |bio, and ensures that the RfC is listed on corresponding pages such as WP:RFC/BIO
  • Yapperbot (talk · contribs) (also once an hour, but half an hour after Legobot) sends messages to user talk pages concerning RfCs where Legobot has recently added a |rfcid= parameter, see WP:FRS
HTH. --Redrose64 🌹 (talk) 15:27, 16 October 2024 (UTC)
Was thinking of Legobot. Not sure the other is core, but Legobot is IMO. Headbomb {t · c · p · b} 15:30, 16 October 2024 (UTC)
I don't see a lot of utility in a single summary score. I think the number of core bots should remain below the threshold where a group of people could go through them and determine relative priorities for attention. Plus, in a volunteer environment, who works on helping with what bot is going to be highly influenced by personal interest in the associated workflow, in any case. For an individual characteristic like "maintainable tech stack", there could be some usefulness in having a score, to help those not familiar with the details of the related technology to make relative comparisons. I would consider it to be more descriptive than analytic, though, to avoid getting bogged down in its precision. isaacl (talk) 15:55, 16 October 2024 (UTC)


Reuse for bots and tools

Somewhat orthogonal to all this the above thread, in an ideal world, I'd love to see greater standardization across bots and tools. I've written a few of my own tools, but I spent a lot of time reinventing a lot of wheels to make them work. I know there's been some progress in this area (pywikibot is certainly a step in the right direction) but there is still a lot of effort expending by people running in different directions. Which in turn makes it harder to have people pick up other people's projects. RoySmith (talk) 16:35, 16 October 2024 (UTC)

@RoySmith: as I imagine you've already heard, frameworks are wonderful: everyone should have one :-). It's a big challenge to create one that is usable by others, with sufficient documentation. There's Help:Creating a bot § Programming languages and libraries, but it's mostly just a big list, without much guidance to help someone decide on what to use. I feel there should be a location for programmers to share experiences, but I'm not sure where that is. Wikipedia_talk:Bots redirects to Misplaced Pages:Bots/Noticeboard, whose header makes it sound more like a co-ordination spot than somewhere to collaborate on development. isaacl (talk) 21:31, 16 October 2024 (UTC)
Some statistics would go a long way. Help:Creating a bot lists a lot of options that nobody would recommend nowadays. While I don’t believe we should mandate any language or toolkit, it would help to inform new developers which languages and toolkits are used in bots in active use, especially more recent bots. At least half of the current BRFAs are Python with Pywikibot. Daniel Quinlan (talk) 22:18, 16 October 2024 (UTC)
I agree that knowing some basic usage info would be helpful. Whenever I look at a third-party library/framework/tool, I want to know how popular it is and how actively it is maintained, in order to get a sense of how likely it is to continue to maintained in future, how easy will it be able to find answers to questions, and how useful have others found it. But circling back to the problem of overhead scaring away developers, this also applies to those creating code and tools for reuse. Tracking this info and keeping it up to date is extra work, and it might be less interesting for a one-person team than working on their project. isaacl (talk) 22:55, 16 October 2024 (UTC)

Update the global bots section

Hi, currently the global bots policy says that (Misplaced Pages:Global_rights_policy#Global_bots) global bots can only run on this wiki for the purpose of fixing double-redirects. I believe that is outdated, because it links to a discussion from 2008 and Meta policies have changed global bots in 2021 to allow running any task that is approved. I think this requires a change on this wiki as well, as otherwise it can be rather confusing. I propose allowing global bots to run here for any approved task, especially since en.wikipedia will be notified when anyone submits a global bot request. After all, this wiki can still instruct any bot not to run here, if required. If not, I recommend adding this wiki to the opt-out set so that global bots are completely disabled (rather than enabled for just one purpose). Leaderboard (talk) 06:49, 12 September 2024 (UTC)

Applying for local bot approval here should still be required for bots here, our community and project are huge and expect our bot operators to be engaged here. As far should we kick out all global bots that are doing the task they are already approved for, that doesn't seem to be necessary. — xaosflux 09:32, 12 September 2024 (UTC)
Any change to the policy would need consensus for that change, here on the English Misplaced Pages. That discussion could be held here, but would need to be an actual RFC or other widely-advertised and widely-participated in discussion. Personally, I'd want to see more reason to change the policy than given so far. Anomie 12:07, 12 September 2024 (UTC)
Agreed. Primefac (talk) 13:16, 12 September 2024 (UTC)
Why is this change needed, and which specific global bots would help improve the English Misplaced Pages under a more permissive policy? Daniel Quinlan (talk) 00:18, 30 September 2024 (UTC)
@Daniel Quinlan This is more for consistency, because I would normally not request local bot rights on a wiki that's not on the global bots opt-out set unless I know that it does not accept all kinds of global bots. I do not have any specific global bots in mind for this reason. Other wikis in this group include the Russian Misplaced Pages, where global bots are allowed but appear to reference old policies. Leaderboard (talk) 14:02, 2 October 2024 (UTC)
I would normally not request local bot rights on a wiki that's not on the global bots opt-out. Good point. Maybe we should add our wiki to meta:Bot policy/Implementation#Where it is policy as "not allowed" so that global bot operators don't accidentally run global bots here. –Novem Linguae (talk) 00:23, 3 October 2024 (UTC)
The only relevant change I see from 2021 is this one, which does not say what you say it says. Is there another change somewhere else? Izno (talk) 19:52, 30 September 2024 (UTC)
@Izno That's the one actually - why do you think that it "does not say what you say it says"? Leaderboard (talk) 14:03, 2 October 2024 (UTC)
The change on meta changed the requirements for meta. It did not change the requirements here, so when you say I think this requires a change on this wiki as well, it reads as if you think we must be consistent with global policy. "Confusing" it is not: we simply have different requirements. Izno (talk) 17:21, 2 October 2024 (UTC)
@Izno Actually, that is what I was hinting at - "fixing double redirects" is just a single task that I am not convinced is needed as a specific exemption. And I was also saying that en-wiki is not the only wiki in this group, where it appears that the rules were created when the global bot policy was more restrictive. Also the policy change in Meta did change the rules for every wiki allowing global bots that did not explicitly have a restriction. Leaderboard (talk) 06:03, 3 October 2024 (UTC)
If I'm understanding correctly, meta has a policy allowing global bots, but that policy doesn't mandate that the bots can be run on the individual wikis without their consent. Each wiki can make its own decisions on what bots it wants to accept. isaacl (talk) 06:56, 3 October 2024 (UTC)
@Isaacl Yes and no. The global policies are global and individual wikis cannot "opt-out" of it. However, individual wikis can set preferences in terms of how they want global bots to use their bot flag, but I've seen a few wikis (eg this one) that references old Meta policies in doing so (which is what I want to correct) - I've not seen a single wiki that explicitly sets such restrictions while referencing the updated 2021 rules - nor have I seen any wiki yet have restrictions other than allowing fixing double-redirects/interwiki language links.
And also, regarding "policy doesn't mandate that the bots can be run on the individual wikis without their consent", yes it isn't a "mandate", but the whole point of global bots is to avoid having operators request bot flags on every wiki, and hence if I were a global bot operator, I wouldn't go around asking for permission on global bot-approved wikis, unless I already know that the said wiki does not allow global bots for any approved purpose. And I cannot do this for all of the 800+ wikis that allow global bots either.
TLDR; yes "wiki can make its own decisions on what bots it wants to accept", but to do so would kind of defeat the purpose of global bots. Leaderboard (talk) 07:31, 3 October 2024 (UTC)
You're making a false distinction in I wouldn't go around asking for permission on global bot-approved wikis, unless I already know that the said wiki does not allow global bots for any approved purpose, which IMO makes your argument unconvincing. If you (as a global-bot operator) know enwiki only allows interwiki-fixing global bots without separate approval, why would you not ask for permission if you want your double-redirect-fixing bot to run here? If your only complaint is that meta:Bot policy/Implementation#Where it is policy isn't clear enough, an easier solution might be to improve that page. The global policies are global and individual wikis cannot "opt-out" of it. Except this one they can. Even if the global bot policy didn't explicitly say so, I think you'd find that we don't necessarily accept here any random "policy" that someone on Meta declares is "global". I've not seen a single wiki that explicitly sets such restrictions while referencing the updated 2021 rules You have, this one. Anomie 12:12, 3 October 2024 (UTC)
@Anomie The bot page links to a discussion from 2008, not 2021. Put it this way: I know I have to apply for local bot rights. Would someone else not familiar with en.wiki? Leaderboard (talk) 21:15, 3 October 2024 (UTC)
They should if they read Misplaced Pages:Global rights policy#Global bots. Anomie 11:27, 4 October 2024 (UTC)
The global policy says The operator should make sure to adhere to the wiki's preference as related to the use of the bot flag. It explicitly allows each wiki to make its own decisions on what bots it wants to accept. isaacl (talk) 15:58, 3 October 2024 (UTC)
@Isaacl I don't dispute that, and I don't also dispute that en.wiki is not doing anything wrong per se. However, I do believe that en.wiki created this exemption in 2008 when Meta rules were different, and believed that it needs at least a relook in 2024. How and what I'm not too bothered with - the other contributors have a lot more experience than I. Put it this way: I would rather have en.wiki put itself in the global bot opt-out set so that it's clear to everyone that you must apply for a local bot flag, rather than this weird one-task exception which isn't obvious unless you actually go to the bot policy (and it's not like it's any more difficult for bot operators fixing double-redirects to file a local bot flag request than a global bot operator for any other task). Leaderboard (talk) 21:21, 3 October 2024 (UTC)
As I mentioned back at the beginning of this, if you want a reexamination then creating an RFC is the way to go. If you want to start drafting one (I recommend a draft to reduce the chance of confusing wording issues), feel free. Anomie 11:27, 4 October 2024 (UTC)
I'm not motivated enough to do it - you all have more experience than I. I just posted here as a suggestion for improvement - it appears to me that the community does not feel this to be worth it. Leaderboard (talk) 19:37, 4 October 2024 (UTC)

"Bot policy" listed at Redirects for discussion

The redirect Bot policy has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Misplaced Pages:Redirects for discussion/Log/2024 October 12 § Bot policy until a consensus is reached. C F A 💬 20:40, 12 October 2024 (UTC)

BAG nomination

Hi! I have nominated myself for BAG membership. Your comments would be appreciated on the nomination page. Thanks! – DreamRimmer (talk) 14:04, 18 January 2025 (UTC)

Category:
Misplaced Pages talk:Bot policy: Difference between revisions Add topic