User:Davidwr/AdminiBot

Overview

AdminiBot is designed to let suitably-trusted/pre-approved users do certain "admin only" task in certain highly-controlled, safe conditions.

Safe conditions mean:

• Deletions that even a bot can recognize as uncontroversial.
• Un-deletions that even a bot can recognize as uncontroversial.
• Additional administrative tools that do not affect other editors' ability to edit and which are extremely unlikely to be controversial.

The purpose of the Adminibot is to reduce the backlog of administrative tasks and to free administrators to do non-administrative work should they wish to do so.

It is NOT to let people accumulate permissions. In fact, except for "self" permissions where the ability to do harm is all but nil, and "retired administrators" using the bot to accomplish tasks they could once do themselves, these permissions should only be handed out for good cause and for the specific period of time in which the administrators expect to be overloaded with, e.g. the duration of a backlog-elimination drive.

While I would like to say "it is not a prelude to RFA" in fact, it will be. People are people and any tool that gives editors a chance to demonstrate trustworthiness or lack thereof will be a factor in RFA. I would expect that, should this tool become available, people will expect that RFA candidates will be using it and any candidate who has chosen not to use it or who has only used it for a short period of time will have to find some other way to show trustworthiness.

Standard permisison levels

Most tools will have a "self" permissions that are very low risk and available to any editor in good standing and a parallel set of very low risk "not self" permissions that may be granted on request.

Retired administrators in good standing can get special extended permissions by just asking.

Other editors can get special "extended permissions" after making a case and demonstrating to either a specific person or to the community that it is in Wikipedia's best interest to grant them the requested permission without requiring them to seek adminiship.

Self

Potential for damage beyond one's own contributions

practically nil.

Judgment and experience level

That of an editor in good standing.

Criteria

Be an editor in good enough standing to get "rollbacker".

Issued by

Any administrator

Revoked by

Any administrator

Special conditions

None.

These permissions are to releive administrators of the duty of deleting pages created by the author and undeleting pages previously deleted at the request of the sole author.

The "self" permissions are harmless enough that they can be handed out to any editor in good standing (e.g. "rollbacker" criteria). The bot will only allow the requested action if all of the following criteria are met:

• The affected page only has edits by the requesting author and it only had deletion, undeletion, revision-deletion, and revision-undeletion, and similar entries which are made by this bot on behalf of the requesting author.
• All edits to be deleted or undeleted are "recent," where "recent" will vary by namespace or other criteria. As an example, in "main space" recent would be a few days for deletion, a few minutes for undeletion. In user space it may be "forever" for deletion and "a few days" for un-deletion. The "recency" criteria is to prevent users from using "deleted pages" as an "invisible holding bin."
• No deletion of any page that was once a redirect, unless the target of the redirect did not exist during the time the page in question was a redirect (this is to prevent move-and-delete-the-redirect games by people abusing the low level of trust needed for "self" permissions).
• If there is a deletion request with previously deleted revisions, it will be made but it will be flagged for urgent review by a live administrator.
• No undeletion of material the requesting author didn't himself delete.
• No undeletion of material deleted by any other editor or bot or by the bot on behalf of any other editor.
• The page in question must not have any form of protection on it.
• The page in question never had a {{db-copyvio}} or similar tag on it as far as the bot can tell. Should an administrator reviewing the deleted material discover copyright violations, he can make a null edit or equivalent, which will prevent the bot from un-deleting the material even if the user asks it to.
• Any deletion that cannot be undone by the bot will not be done until the editor has been warned and confirms the action.
• When in doubt, the bot should refuse to act and offer to post to the appropriate noticeboard requesting administrative assistance.

Not self

Potential for damage beyond one's own contributions

Low.

Judgment and experience level

1) Must be able to abide by rules even if they are not enforced in software. 2) Must be able to make judgement calls on things like "does the fact that a db-author- or db-user-eligible page is blanked really mean the editor wanted it deleted?"

Criteria

Editor has to make a case for having the tool and a time-frame in which he needs to use it. This will become his "charter." Have a person authorized to grand this permission do more than a cursory review of both the editor's history to determine if he is competent to use the technical tool he is being granted and the personality to stay within the confines of his charter, and whether there is a need for more people with authorization to accomplish the task described in the charter.

Issued by

Person authorized to hand out this credential, who is presumably also an administrator.

Revoked by

Any administrator. Recommended that it be revoked by the bot itself at the expiration of the charter.

Special conditions

No use outside the charter beyond the user's other permissions (e.g. "self" or permissions granted under another charter).

These allow trusted editors who have undergone some level of scrutiny to do the same "deletion" tasks they can do using "self" rights but do so

on behalf of editors who do not have "self" privileges with the bot. Again, this is to relieve administrators of the duty of deleting pages created by the author.

The "not self" permissions are only granted on a case-by-case basis and typically have the same criteria except:

• Each user who is granted permission will have to abide by a "charter," or detailed list of situations when the permission can be used and for how long. These criteria and the expiration date may or may not be enforced in software but the editor is expected and required to follow his charter. An example charter would be "Editor X is allowd to call the bot to delete pages that qualify for db-author or db-user any time the backlog as listed in category Y has entries older than 1 hour, with an expiration date of 1 year from now." Another example would be "Editor X is participating in the speedy-deletion backlog reduciton drive. He is allowed to call the bot to delete pages that qualify for db-author or db-user during the drive. The drive starts this Sunday at 00:00:00 GMT and lasts for 7 days."
• "the requesting author" is typically replaced by "a single author" or "a single author, not counting edits the bot can identify as made automatically by a bot, edits which were reverted for good cause, and "reverting" edits made for good cause (e.g. if editor #1 blanks the page, editor #2 unblanks the page, bot undoes the unblank, primary author restores the page, then a recognized maintenance bot updates categories on the page, then the primary author tags the page with db-author, Adminibot will detect this and will count as a page written by a single author).
• The page must be tagged in a way that the bot clearly knows that the single author is requesting deletion. In some cases blanking a page and leaving it blank for a specified period of time qualfies as a request for deletion.
• Deletions requiring "not self" permissions are not available for un-deletion. If "self" can't undelete, get an administrator to do it. The bot will warn the editor that is requesting deletion that his action cannot be undone.

Retired administrators

Potential for damage beyond one's own contributions

Same or less than that of resuming adminship.

Judgment and experience level

Same or less than that of resuming adminship.

Criteria

Be eligible to resume adminship by just asking.

Issued by

Person authorized to hand out this credential, who is presumably also an administrator AND who is presumably authorized by a bureaucrat.

Revoked by

Any administrator or bureaucrat.

Special conditions

Assume your edits using these permissions will be treated the same as if you had resumed adminiship.

This allows administrators who have resigned their tools and are eligible to resume adminiship by merely asking but who no longer want ALL of the tools or responsibilities of adminiship but who do want to use a specific tool for a specific purpose or set of similar purposes.

• "Retired administrators" would be able to ask for and easily get approval to use the bot for any administrative task it could do without any specific charter or time limit. However, if they ask for a lot of permissions, it is recommended they just pick up the whole mop and all that goes with it.
• Abuse of the bot would be treated as abuse of administrative power and they may find that they will no longer be allowed to resume adminiship without going through RFA again.

Extended permissions

Potential for damage beyond one's own contributions

Case-by-case, no greater than having full adminship.

Judgment and experience level

Case-by-case, no greater than having full adminship.

Criteria

Case-by-case depending on required judgment and experience level. Recommend that editors requesting anything with more than a small potential for abuse or more than a small potential for causing severe technical problems have a good edit history, demonstrate sufficient technical knowledge, and have and experience in the area in which they wish to use the bot.

Issued by

Person authorized to hand out this credential. In most cases this will be either a bureaucrat or a an administrator who has been recommended by the community and appointed by a bureaucrat. In low-risk cases, this will be any administrator.

Revoked by

Any administrator.

Special conditions

No use outside the charter beyond the user's other permissions (e.g. "self" or permissions granted under another charter).

The "extended permissions" allow those who are not administrators or former administrators in good standing to do specific administrative tasks not covered above when there is a need for additional manpower.

• If enough current and retired administrators are available to accomplish a given task, then there will be little or no need to give the specific permission to people who are not retired administrators.
• These are also granted under a case-by-case, charter-based basis, but with even more scrutiny than the "non self" requests.

Some examples of "extended permissions" that can be handed out to any editor in good standing:

• Deleting redirects left over after the user moves a page, where the redirect points, directly or indirectly, to a page that the editor doesn't already have permission to delete. This provides the equivalent right of "move without leaving a redirect."

Some examples of "extended permissions" that demand greater scrutiny due to the potential to cause damage or the need to be trusted not to abuse power, even unintentionally:

• "Move over redirect, where redirect is only item in edit history" when the user does not have this ability already.
• Making edits requested by "editprotect" to a certain, specified list of articles.
• Moving sandbox edits for protected templates into the template.
• The ability to do administrator-level tasks with respect to articles that are under probation or similar supervision.

Mis-use of the tool

• Typically accidental mis-use would lead to revoking of privileges, with leave to re-apply after it is clear that it won't happen again.
• Repeated accidental mis-use or deliberate abuse would typically not only result in revoking of the tool, but the editor would have to re-earn the trust over a long period of time before successfully re-applying to use the tool, and the any recent (last few months or yeas, or few hundred or few thousand edits, depending on the situation) mis-use would likely be raised at RfA should he run for adminiship.

Adminibot usage

For "self," the editor simply requests permission from any administrator. For "non-self" and "extended permissions," the editor requests a specific permission or "charter," e.g. db-author and db-user speedy deletions, for use in a specific context, e.g. speedy-deletion backlog patrol, for a specific period of time, e.g. for the duration of a backlog elimination drive or until the backlog is below a certain level for a certain period of time. Retired administrators would typically ask a bureaucrat.

Editor's history and if applicable, the charter, are reviewed and he is granted permission. For technical reasons his permissions may exceed what is requested, but he is "banned" from using the tool outside of the scope of his "charter."

Editor installs scripts to call the tool on his behalf or learns to use the bot without scripts.

Editor uses the scripts and bot, freeing up administrators for other tasks.

Administrators or others spot-check the use of the tool.

If the permissions have an expiration date, the permissions are revoked.

Indirect AdminiBot usage by editors not approved to use it for a given task

Some AdminiBot tasks can be requested by a template which human editors watch. For example, {{db-author}} is implicitly such a template, but {{db|reason=user requesting deletion of own page|AdminiBot=yes}} would explicitly add the page to a category that can be monitored by people authorized to use adminibot to run db-author.

AdminiBot technical requirements

• The bot is only run manually, not automatically. It may have automated tasks related to logging and maintaining itself, but when it comes to editing pages in the project, everything is done only after an individual request from a user or trusted script.
• All bot activity logged in a special place in addition to regular edit logs. This log will be spot-checked.
• All users must be granted specific permission to do a specific type of act (e.g. delete a leftover redirect) by a permission-granting authority, e.g. BAG, RFA, ArbCom, a bureaucrat, or an appointee of one of the above empowered to grant such things. It is expected that the "least harmful" bot activities will be delegatable by any administrator, and that the "most harmful" ones will require an RFA-like process. The "self" permissions are an example of the former - the Bot Approvals Group will delegate to administrators the right to grant and revoke "self" permissions without any further formal process.

• Right before (for deletions) or right after (for undeletions or edits) each bot edit, a null edit will be made in the name of the actual editor with a note that the next or previous edit, deletion, or undeletion is being made on behalf of the requesting editor, with a diff if possible. This is so editor's true edit histories are clear to everyone.

• Any editor in good standing can stop the bot entirely ("emergency off switch") and any administrator can suspend them for a given user on an emergency basis. Any administrator can ask the bot to undo or roll-back its recent edits, up to a point.