This article is about bots to make edits to the RuneScape Wiki. For bots in RuneScape, see Macro.
- For a list of bots in RuneScape Wiki and their status and tasks, see RuneScape:Bots/List.
- For guidelines and rules regarding the AutoWikiBrowser tool, see RuneScape:AutoWikiBrowser.
A bot is a computer program that automates certain tasks, which in this case is editing this wiki. Unlike bots that perform tasks in RuneScape, bots here are allowed and encouraged. However, given that there is a potential for bots to malfunction or vandalise, the community must carefully regulate their operation to prevent them from damaging the wiki.
There are many tasks that bots can perform more efficiently and with less work than humans. Examples include correcting American spelling of words to British and tagging pages with maintenance templates (such as Template:Jpeg). However, human editors will always be needed, as bots aren't capable of adding content to the wiki. They are just a tool for performing repetitive tasks with less work involved.
Community members that are interested in creating a wiki bot should read creating a bot on Wikipedia, as it provides useful background information that applies here.
The process of creating a bot should usually begin with an idea for a bot being discussed by the community. These discussions are often held with another user privately, for feedback and suggestions. If the general consensus is that it would be useful for the bot to perform the discussed tasks, then the prospective bot operator should write a detailed specification that explains how the bot will run on the Yew Grove. The specification should include:
- A detailed description of what the bot will do and how the bot will do it. The latter is important because otherwise, the community may end up waiting and waiting for a bot that will never be able to carry out its intended tasks.
- How often the bot will run. All bots will run either continuously, periodically, or one time. If the bot is designed to run periodically, it should be specified how often it runs.
- Who will be able to access it. Most often, only the owner will be able to control the bot other than through blocking it, but sometimes it is possible to allow others to access the bot. Access to the bot will almost never be open to everyone, since again there is a potential for abuse of its features.
- Any other information the community would be interested in when evaluating the proposal.
It is important to write the specification before work on the bot is started, because it defines the bot's goals before it's annoying to change them. Additionally, the community can be sure that the operator is serious about running the bot.
After the bot is coded, it should go through testing of all its features in a variety of scenarios. This testing should occur on a separate bot account instead of the creator's account, and is oftentimes performed on a 'test wiki'. The testing should ensure that the bot performs as expected. Once testing is complete, it should be noted on the thread, if it is still open.
The bot flag only has the technical effect of allowing the bot's edits to be hidden from the recent changes page, but to the community it indicates that the bot has been tested and approved. Bureaucrats can flag bots; they will look for a community consensus to flag the bot before doing so.
All bots must run on separate accounts from their creators, as it is important to distinguish between automatic and manual edits. These accounts should not be created until the bot enters the testing phase, however, because until that point there might not ever be a working bot to use the account.
Most of the time, the bot account should have a bot flag so that its edits are hidden from recent changes. Additionally, the bot flag shows that the community has approved the bot, as bureaucrats look for a consensus when flagging bots (and no other users can flag them). The only exception is when the bot is still testing, in which case it may be relevant to have the edits on recent changes in case the bot functions incorrectly. Otherwise, the bot has demonstrated correct behaviour and its repeated edits need not be seen by everyone else unless they are overtly interested. Bot flags are reserved for bot accounts, and normal accounts may not have a bot flag, although this probably goes without saying.
Per the above section, community consensus behind the bot is required at nearly every stage of the process. There is always the potential for a bot to function incorrectly or do harm to the wiki, and it is important that the community knows bots are running and has some confidence that this operation is correct. If an unapproved bot is caught running, administrators are free to block it as they see fit until there is community approval for it.
It is requested, but not required, that bot creators publicly release the source code for the bot, or at least give a copy of said code to a trusted user. The code should be released under an open license such as the GPL. By providing some community member with the source code, the bot can continue operation after its operator has left the wiki, if and when this happens. If the operator has distributed the bot's source code, this should be noted on the bot's user page.
If a bot operator does in fact leave and another takes his or her place, a separate bot account should be created, controlled by the new operator. This is to ensure transparency and accountability for the bot's actions. The bot's source code will usually run unmodified by the new operator. If this is the case, the specification and testing phases may be skipped and the new operator need only ask the community for a new bot flag before running the bot, given that the functionality of the bot is already known to the community to be correct. However, if the code is significantly modified to the point where its behaviour is not the same, the testing phase of bot development should also be repeated by the new operator.