User:NoSeptember/adminbots

Initial ideas

Ideas on the procedures we should use with respect to the sysopping of adminbots:

1. Approve the sysopping of the underlying code, not the specific bot or the specific admin that is to run it.
   • First the functionality is approved by the bot approval procedure, then an RfA would be conducted for sysopping bots with the approved code, not limited to the one bot of the user that created the code or on which computer that code would be located.

   • Example: AdminA writes and gets approval for the code for AdminABot. Other admins agree to support bots with the same code. Once the RfA for the specific code is approved, AdminABot, AdminBBot and AdminCBot are all sysopped as bots for that specific function. If AdminABot has hardware issues, AdminB can promptly take over the job with AdminBBot.
   • Should the code become obsolete or the community decides that the bots should stop running this task, all bots sysopped for the purpose of running that code would be desysopped (done with a simple request to a Steward by a bureaucrat).

   • Adminbots would be restricted to a single purpose and would not run any unrelated jobs.
   • If the community feels it is necessary, it can define which admins will be (or not be) permitted to have adminbots for each approved adminbot code.
2. Adminbot code would have to be resubmitted to RfA for routine reapproval, creating a standard that unlike for admins, RfA approval for bots is for a fixed term (6 months or a year perhaps).
3. Additional unique RfA standards or procedures that would make the approval of needed adminbot code run more smoothly and pass more easily should be adopted.

(proposed by NoSeptember)

Prior to RFA

1. The bot to be operated from a dedicated account only for a trial period of 1 month with full admin abilities.
2. The trial period to be publicly announced at WP:AN, bots user page to indicate the trial period with full instructions on what the bot is doing and contacts if problems are occuring.
3. The trial to be supervised by a bureaucrat who can terminate the trail at any time.
4. No change in functionality during trial period, ie if bot is designed to delete orphaned fair use images, then it can't be modified to delete unlicensed images as well.
5. The bot is to stop operating during the RFA
6. The bureaucrat to give an overview of the trial at the commencement of the RFA.

(proposed by Gnangarra)

Restrictions

1. to be operated only by an admin or bureaucrat.
2. access to the code to be restricted, we have passwords on our accounts to prevent others using them and this isn't any different.
3. single function bots.

(proposed by Gnangarra)

---

Others are invited to add more ideas, and comment on these.

Discussion

Why these ideas? (On the Initial ideas section above):

1. In the last several adminbot RfAs there was a lot of discussion about the admin behind the bot or the author of the code. This seems unproductive. If the code is good, why limit its use to the author of the code or to a single admin? Why allow a hardware issue or an admin leaving the project end the functionality of an adminbot code? It seems reasonable to base the RfA approval on the code itself, not the admin, and to allow that code to be run from multiple locations (although only one may be active at any one time). The RfA should not be about the author of the code, or which admin is to run the bot.
2. A mandatory reconfirmation on a scheduled timetable seems reasonable. We are always having significant coding improvements making older bots obsolete, so why not build in a time limit? And this may make it easier for approval, as it may allay some fears that once an adminbot is approved, we may never be able to get rid of it should its performance be controversial. Adminbots are not people, do not have feelings, so desysopping should not be a big deal, especially if the code is being shared by multiple bot operators anyway.

   NoSeptember 14:42, 31 January 2007 (UTC)