User:Atvelonis/Admin

This is a collection of my thoughts on how an administrator  (sysop) should ideally act and what duties they should perform. While the first half of the guide is based in theory, the second half discusses practical uses of administrative tools and how to actually uphold the duties that the position entails. Neither section should be overlooked.

I would highly recommend that both users who seek to become an administrator as well as newly-promoted sysops read through this guide at least once to get an idea of how they should carry themselves. Certain sections apply more to bureaucrats  than administrators, but I believe the entire guide contains information relevant to anyone using the wiki.

Deleting/undeleting pages
One of the primary jobs of administrators is deleting pages that break the rules or are otherwise inappropriate for the wiki. This includes spam articles, irrelevant material, or anything overly risqué, with some exceptions. Likewise, if a page was deleted mistakenly or unfairly, it is the duty of an administrator to restore the page to how it was previously.

Deletion candidates
The wiki uses the Delete template on articles which need to be deleted: pages tagged with this template are included in the Deletion Candidates category, which should be periodically cleared by the administration. In the past, this task has been ignored until the category contained several hundred items, making the job of clearing it out even less appealing. To prevent it from becoming overfilled, administrators should be careful to delete pages in that category that do not belong on the wiki, or remove the deletion tag from articles that can remain.

Content ideologies
Editors often have opposing trains of thought about how to approach deletions on the wiki. One line of thinking, which has been dubbed "Eventualism," argues that incomplete articles should remain on the site to be updated in the future. Supporters of this practice claim that the future usefulness of Stub articles outweighs their current lack of usefulness. Alternatively, proponents of "Immediatism" believe that all pages should be required to meet a relatively high standard upon or soon after creation, or else be deleted. Neither approach is necessarily more correct than the other, and many editors are more comfortable with a mix of the two.

Protecting pages
An argument among editors will occasionally become heated enough over a page that an administrator is forced to intervene and protect (lock) the article. A good time to protect a page would be during an edit war, if it is undergoing excessive vandalism, or if it happens to be about something extremely noteworthy, controversial, or of functional necessity, and therefore must be protected from any possible harm.

By default, pages are open to all contributors, even those without an account. However, administrators can "semi-protect" the page so that only logged-in users whose accounts are over a certain age can edit it. The option for this is "Block new and unregistered users." The most stringent option, "Administrators and Content Moderators only," should be used sparingly, as it prevents anyone who is not an administrator, content moderator, or a member of Wikia Staff from editing the article. Particularly important templates, project pages, and user pages can be fully-protected, as well as articles undergoing significant edit conflicts between logged-in users.

Generally, though, a page is only protected temporarily. The option for indefinite protection should not be used too frequently, as it is very easy to forget to unlock a page in the future. For the most part, only things like rule pages and important templates are protected indefinitely. A list of all protected pages on the wiki can be found on Special:ProtectedPages. Some of these cannot even by edited by administrators.

Blocking users
Administrators are required to block troublesome users for differing amounts of time, depending on the offense they have committed. A table with commonly-followed block length guidelines can be found here. These guidelines can be ignored if the situation permits it, but they are good to follow in most scenarios.

When to block a user
Of course, administrators may take context into account when deciding how to enforce a rule. It is better to judge by the spirit of the law rather than the letter of the law. For example, admins should not block a user based purely on a technicality. Alternatively, if a user breaks a rule in order to fix a critical issue or otherwise prevent further harm from befalling the wiki, it is not a good idea to block them for it.

Rather, blocks should only be handed out if a user or group of users has repeatedly proven themselves to be detrimental to the further development of the wiki and/or community. This does not mean that administrators have the right to block whomever they disagree with. There is a fine line between blocking someone for sharing a dissenting opinion (even a harshly-worded one), and blocking someone for actively causing damage to the wiki or its users.

That said, no one on the wiki is entitled to freedom of speech. At least, their freedom to express opinions is not protected by the Constitution of the United States of America, even though Wikia is headquartered in the United States. This is because the oft-quoted First Amendment only applies to the government; as Wikia is a private company, its employees (and, by extension, its volunteer staff members) are not required to abide by legal restrictions regarding censorship that do apply to the government.

Note that this argument should not be flouted in order to justify blocking a large number of people without a good reason. It is a defense against those who claim that they have the right to spout whatever nonsense they please on the wiki, not a justification for censorship.

Community input on blocks
When dealing with troublesome users, it is important to remember that just because a user may have a large amount of community support, their statements or actions do not necessarily represent the best path forward for the wiki.

Although several democratic elements exist within the wiki, The Elder Scrolls Wiki is not a democracy. A major flaw with democratic systems of government is the tyranny of the majority; under-informed or ill-intentioned individuals may vote in ways that actually harm the underlying goal of the wiki. This is why a consensus is never ultimately decided by a vote, rather by discussion, even if a vote takes place; more important is the reasoning behind the decision being made.

Rather than a pure democracy, the wiki is commonly described as a meritocracy, in which only the most deserving members hold staff roles. It is also sometimes thought of as more of a bureaucracy, in which decisions are made with little community intervention, and the process for policy-making is primarily in the hands of the staff. In truth, the wiki is a mix of these three systems of government.

Thus, community support for a block (or a page deletion, protection, etc.) is not required. It is easy to misinterpret this line of thought as, "Administrators have the final say in all matters," but that is not really the case. While an "executive decision" (so to speak) is necessary in many situations for efficient policy-making, an administrator should generally abide by whatever the community thinks is the right thing to do.

For example, if an administrator thinks that the wiki background should be a picture of the Giant Flying Spaghetti Monster, and the vast majority of the community believes that it should be a picture of the ESO Ouroboros, the latter image should be adopted. However, if a user has caused a significant amount of damage to the community, policies, or wiki itself, they should be blocked, even if they have a high degree of community support.

The difficulty here is deciding what is considered "damage." Obviously, someone who is outright vandalizing articles should be blocked. However, it can get a lot more nuanced than that. If someone makes a huge amount of bad policy proposals that distract from the addition of content on articles, should they be blocked? Are they genuinely trying their best to help out, or is it actually a convoluted way to make the wiki an overly difficult, hostile, or otherwise unappealing place to contribute to? These are the questions that have to be considered when blocking someone for anything less clear-cut than blatant vandalism.

Most of the time, the wider community is not informed enough to make a decision on whether or not someone should be blocked, as they do not track user contributions to as great a degree as administrators tend to. Thus, the opinion of an informed administrator is weighted more heavily than that of a passionate, yet uninformed member of the community. That said, their opinions should not be outright ignored. It is important to balance executive decisions with community input. Failing to do this may be grounds for the demotion of the administrator at fault (see below).

Evidence for blocks
While screenshots have been used in the past to prove that a user broke a rule on the wiki, particularly in the Chat, this practice has declined in use in the past few years. It has become increasingly clear that screenshots can be doctored without much effort. For example, the text of a Chat message can be altered via Photoshop or other image editing programs, and the "Inspect Element" feature can be used in Google Chrome to change the text of a Chat message for the duration of a user's session on Chrome. These techniques effectively render screenshots of text useless.

The bot KINMUNE logs everything that is said in the Chat when she is operational. Since her records are posted to the User namespace, they have an edit history: any later revisions on the log itself can be observed and undone. As such, evidence for arguments made on the Chat which require any level of investigation should generally only come from the chat logs provided by KINMUNE. A list of Chat logs can be found here, for reference.

Range blocks
On rare occasions, namely when a large amount of vandalism has originated from a number of similar IP addresses, it may be necessary to block the applicable IP range in order to prevent further issues. This can be done by inserting the offending IP address into Special:Block and adding a CIDR suffix at the end (explained in more detail here). A table of sample IPv4 ranges can be found here, and a table of sample IPv6 ranges can be found here. For example, blocking  would block every IP address from   to , or a total of 2562 (65,536) IP addresses. For obvious reasons, this method should not be adopted except as an absolute last resort. Additionally, as with regular IP blocks, administrators are strongly recommended against setting infinite IP range blocks because of the number of innocent IPs that can be permanently affected this way.

MediaWiki
MediaWiki articles are lines of CSS (Cascading Style Sheets) and JS (JavaScript) that makes up the back-end structure of the wiki. It is the job of the administration to keep these pages updated and with as little clutter as possible. MediaWiki is one of those things that should not be changed significantly without consensus from the rest of the staff and/or community (if necessary). Note that even if something appears to be useless at a glance, it is probably still there for a reason. As such, it is advised not to edit any part of any MediaWiki page without an understanding of what is being done and how it works, at least in a basic sense.

Generally, it is also a bad idea to add innumerable quirky scripts to the wiki unless they are genuinely useful. Things like pretty animations, popups, or a million widgets are probably not necessary to the wiki, and only serve to increase loading times by a small degree. Over time, these scripts can really add up, eventually reaching the point where simply reviewing them becomes a project in and of itself. Administrators should strive to find a balance between useful scripts and unneeded ones whenever possible.

If assistance with a MediaWiki page is ever required, Flightmare is probably the best person to get help from on this wiki. If he is inaccessible for whatever reason, consider asking on Community Central or sending a ticket to Wikia (although it is not their job to help clean up messy MediaWiki pages).

Project pages
It is also the job of administrators to create and maintain the wiki's official project pages (anything in the "Project" namespace). This includes policies, archives, poweruser groups such as the Circle, events such as the Member of the Month award, and more. Many of these pages are semi-protected or fully protected to avoid vandalism or misinformation being placed on them.

Administrators technically have direct control over the contents of policy pages, but they are not permitted to create or remove whichever rules they please without community consensus. While a full consensus is not always necessary, administrators should seek to at least present their ideas at the moot every month in order to gauge community support or opposition.

Policy creation should never be a secretive matter. Some things are left to the administration, but if the community presents legitimate objections to a policy (even one that they may not be knowledgeable in), the administration should amend the policy to address these issues to the best of their ability.

Promotions
The next few sections apply more to bureaucrats than administrators, but are still relevant to all sysops. There are a number of general ideas to keep in mind at all times when voting on staff applications, or thinking about requesting an application from a user.
 * Necessity of additional staff of this category. Will promoting this user have a meaningful positive effect on the efficiency of that area of the staff and the wiki at large?
 * Ability of the candidate to adequately carry out staff duties. Are they technically qualified enough to receive the position, and more importantly are they likely to adapt well to it mentally? This is broken down further in the rubric below.

Other things to consider are:
 * Likelihood of long-term retention. In years past, the wiki has had an unfortunately high turnover rate for staff members, especially moderators on the Chat and Forums. It is generally preferable to support the promotions of users who are likely to remain on the wiki for several years, as this provides experienced role models in each staff position to inspire and guide new staff members in running things properly.
 * Activity trends. Highly sporadic activity can be an indication that a significant amount of an applicant's time is taken up by other things. All users have some level of real-world obligations to deal with, but if an applicant has consistently shown themselves to be unreliable in terms of activity, they should probably not hold a staff position.
 * Reasons for interest in position. Obviously, simply being interested in a staff position does not immediately disqualify someone from gaining those tools. However, if a user shows an unusual amount of interest in becoming a staff member, there is a good chance that they truly just want a shiny staff badge, but are not genuinely interested in properly carrying out the many responsibilities that come with a promotion. Editors who hold such beliefs should not be promoted under any circumstances.

Some red flags to watch out for in staff applications are indications of an objectively counter-productive agenda, grudges against current or former staff members or members of the community, unusually favorable behavior towards particular users or groups, and other generally unbecoming behaviors, such as excessive vulgarity.

Inactivity
As the leaders of the wiki, administrators should encourage all staff members to remain active whenever possible. Not doing so sets a bad example for the future: after all, if one staff member can get away with doing nothing and retain their position, what about everyone else? The logical train of thought for many users is that they would also deserve to keep their positions, even when they are not pulling their weight, so to speak, in any serious way. To avoid such fallacies, it is generally best not to allow staff members to become perpetually inactive.

Difficulties in staff management arise when staff members have legitimate reasons for not spending enough time on the wiki. For example, obligations with school or work, illness, financial difficulties, or familial conflicts are all explanations that staff members will give for their inactivity. These are legitimate excuses for not attending to their wiki duties. Although staff members are not entitled to indefinite absences, it is completely unnecessary to take away someone's tools simply because they took a break to handle these issues.

The best ultimate course of action in these situations differs depending on the context, but it is always a good idea to communicate with the staff member in question about their inactivity before doing anything else. It may be appropriate to set a rough deadline for when the staff member should return to full or semi-activity (this guide cannot provide universal times in a fair way: that is dependent on too many situational factors). If the staff member is not available for a meeting in any capacity, the decision should be left immediately to consensus.

Demotions
Although relatively infrequent, revoking tools from staff members is an important part of being a bureaucrat on the wiki. This is not something to take lightly. Most of the time, the only way to remove a staff member from their position is to gain a supermajority of supporting votes in a consensus against that particular user. Although anyone can start such a consensus, they must be mediated by an administrator or bureaucrat. In addition to understanding the information presented in the consensus, there are a couple further points to bear in mind when voting on this type of Consensus Track thread.
 * Overall usefulness of the staff member in question. Would it truly be a net positive to remove the tools of this staff member? Even if it is believed that they were acting in bad faith, it is essential to balance a user's acts of misconduct with their contributions, administrative skills, and general usefulness to the wiki. What may appear to some as harsh leadership may come across as pragmatism to others, for example.
 * Broader effects of the demotion. Is this demotion going to set an unwanted precedent, or otherwise lead to negative outcomes in the long run? It is critical to view these things impartially, and to consider the broader effects of the demotion, if it is to succeed.

No one, even an administrator, is above the rules: sysops have been demoted by community consensus on more than one occasion. A demotion usually only happens if an administrator is unquestionably abusing their power to a significant degree. However, if they are simply making a controversial (but much-needed) decision, but not actually overstepping their boundaries, then they have no reason to be demoted.

Of course, extreme care must be taken when demoting staff members. If a consensus against a staff member succeeds, but it is later revealed that some evidence used against them was doctored (edited screenshots, for example), this can reflect poorly upon the mediating sysops. Likewise, administrators must remain aware of any possible foul play on Consensus Track threads, including sockpuppetry, blackmail, or generally unproductive agendas.

If a user has unquestionably broken Wikia's Terms of Use, they may be demoted by the administration without community consensus. The exception to this is, of course, a bureaucrat: unless they choose to resign, their tools can only be removed by Wikia Staff. Thus, a consensus must be held and another administrator must contact Wikia to demote the offending bureaucrat if it succeeds.

It is often difficult to judge the exact significance of abuse of tools among staff members. For example, how does a passive-aggressive set of edit summaries compare to incompetence in administrative duties? Do either of those things qualify a staff member for demotion? Provided below is a rough guide on how immediately concerning various abusive behaviors are considered, from most concerning (top) to least concerning (bottom). This is not set in stone, nor is it a comprehensive list of possible abuses, but can be used as a quick reference when necessary.

Note that multiple lower-level offenses may be considered equivalent to one higher-level offense. Consensus Track threads are occasionally created to demote staff members who have not necessarily caused active harm to the wiki, but are still unworthy of their tools, often related to temperamental conflicts. These generally require substantial evidence presented against the offending staff member in order to pass successfully (2/3 supermajority).

Application veto
Per consensus, bureaucrats have the ability to veto a user's staff application if they believe the candidate to be unsuitable for the role. This veto power outweighs any level of community support that said user may have received, but is used extremely rarely, and only with the applications of users who could cause significant harm to the wiki if they are promoted. More frequently, if a bureaucrat disagrees with the promotion of a user, they will simply vote against them in the application, and will usually still promote the user if they have received wide community support. Therefore, the bureaucratic veto should only be used as an absolute last resort.

Other staff duties
In addition to the aforementioned duties, administrators are encouraged to keep an eye on all parts of the wiki, including Recent Changes, the Chat, and the Forums. Generally, each administrator will have slightly different areas of expertise, but they should all make an effort not to completely ignore one or more sections of the wiki.

Patrolling
In essence, patrolling comes down to continually opening everything on Special:RecentChanges and checking if each of the edits are good or not. If an edit is deemed to be vandalism, inaccurate, unnecessary, or otherwise undesirable, it should be reverted, and the user who made the edit should be informed of how they can improve their future edits. It is also important to patrol new articles to make sure that they are up to snuff, and block users who commit vandalism or repeatedly cause disruption on articles.

Forum moderation
Similar to patrolling, forum moderation requires every post to be reviewed by a moderator or administrator, who will determine if it breaks any rules. The Forum guidelines should be used on the Forums, and the Discussions guidelines should be used on Discussions.

It is perfectly fine to make exceptions to the rules here and there, depending on the situation. Posts that blatantly violate the rules should be deleted, whereas legitimate threads that have gotten derailed in some way should usually be locked. If the users are still capable of continuing the conversation in a mature fashion, then only the specific comments that have been derailing the thread should be removed.

Blocks should only be handed out if a user has broken the rules multiple times after being warned (see above); in other words, a first offense is usually not something to block over, unless it is plain spam or vandalism.

Chat moderation
Moderating the Chat requires a great deal of attention, so it is not always possible to keep a close eye on it while simultaneously editing or moderating a different part of the wiki. If one or more Chat moderators are online, it is perfectly acceptable to go AFK in the Chat. If not, it is recommended to keep a closer eye on the Chat.

It is best to enable chathacks (Options → Enable chathacks) and set your pings to various corruptions of your name, as well as the terms, "Admin" and "Moderator." If you want to be especially vigilant, "Help," "Question," and related terms can also be useful.

News
Alongside the news team, administrators are responsible for keeping the news on the front page up-to-date. Add the category "News" to blogs add have them display on the front page's first news tab. Likewise, add "Community News" to blogs to the second news tab on the front page.

Administrators must also either delegate the writing of the Weekly Updates to a member of the staff, or write the updates themselves. They must also continually update all related materials, such as social media accounts and other aspects of the front page.

Good traits to have
While editing skills are an extremely important part of being administrator, admins also have to be active within the community, and as such require a good number of social and leadership skills. I have listed a few here that I believe are important for the position:


 * Accessibility – Users should be able to contact admins in at least one way (talk pages), and ideally in several, such as through the Chat or from off-site. Additionally, admins should make themselves as approachable as possible and avoid coming off as cold or unfriendly.
 * Assertiveness – Although an admin should obviously take into account multiple different opinions before making a big decision, they should not meekly step aside every time someone challenges their ideas. They should be firm in their beliefs, but not overly stubborn.
 * Calmness – An administrator should not be freaking out over calamitous events. Additionally, they should know how to deal with criticism and policy, editing, moderation, etc. issues in a level-headed manner.
 * Caution – Although it can be beneficial to try out new features, admins should be careful not to go too far. Totally changing the content of all of the wiki's rules to something different, for example, could potentially have devastating effects.
 * Dedication – An admin should constantly be dedicated to protecting and improving the wiki. They should not abandon or neglect the wiki for another wiki or website, although of course real life does take priority over administrative duties at times.
 * Friendliness – Tying into being approachable, an admin should have friendly or at least professional interactions with all users. They should not be hostile or otherwise unpleasant, and should instead strive to create functional relations with as many users as possible.
 * Helpfulness – Admins should always attempt to be as helpful as possible to new and old users alike. Explaining things to others and fixing issues in a friendly but still informative fashion is a very good way for an administrator to improve the wiki.
 * Humility – Being responsible for so many essential aspects of the wiki can have a negative effect on the perception of one's own importance. An admin should be aware that they are just a glorified internet janitor, and that they are not irremovable from their position should they stop acting properly. They should accept the fact that they are not above the rules, and should not consider themselves any more important than they actually are.
 * Integrity – In addition to being honest to other members of the community, an administrator should not be tempted to break the rules just because they think they can; they should always remain devoted to improving and maintaining the wiki.
 * Intuition – Administrators should be able to process a situation easily and figure out a course of action fairly quickly. No one is perfect in this regard, but the position often requires quick thinking. Although many scenarios require a much deeper level of thought, some must be handled almost instantaneously.
 * Judgment – Similar to the previous point, admins should be able to reach sensible conclusions more often than not. They should be able to suggest compromises and solutions, and should also be able to make sense of drawn-out debates.
 * Knowledge – Obviously, an admin should know what they are doing most of the time. This means being familiar with policy and style guidelines, as well as having knowledge of the game series itself and of course how to perform their administrative duties.
 * Leadership – While they are not dictators, admins are the faces of the wiki and as such should demonstrate good leadership skills. They do not necessarily give orders, but they should make an effort to be forthright with their ideas.
 * Patience – An administrator should be patient with everyone they speak to. Most people are not knowledgeable about many things on the wiki, so teaching them about such things should not result in an admin getting frustrated and leaving.
 * Positivity – Although they certainly do not have to be bounding with energy, an administrator should be at least somewhat inspirational among members of the community. It is difficult to follow a leader who constantly brings everyone down emotionally.
 * Restraint – Admins should be capable of exercising restraint when it comes to blocks, protections, consensuses, and other matters. This means that they should only make use of their tools if there is a proper reason to do so, such as dealing with vandalism.
 * Trustworthiness – Users should be able to come to admins for help and expect a decent reply, and admins should always be there to handle blocking users and de-escalating heated arguments. An unreliable admin should probably not have the position.

Wikilawyering
Although they should be followed whenever practical, the wiki guidelines are not law. Treating them as such to further an agenda is called wikilawyering, and should be avoided at all times. If someone is using a technicality in a rule to get their way, but simultaneously undermining the general spirit of said rule, they are wikilawyering. This is certainly not something that a staff member and especially an administrator should do. Instead of purely getting bogged down with semantics, always take into account the "spirit of the law" when crafting and enforcing policy.

Policy cliques
To some extent, the formation of social cliques on the wiki is unavoidable, because users are naturally attracted to those with similar interests. This is generally harmless when it comes to most casual topics. However, an administrator should do everything in their power to ensure that users do not adopt a single, immutable approach to wiki policy. In this regard, a clique of users on the wiki is akin to a political party in an election. This is a terrible approach to wikis. Not only does it bias users towards supporting or opposing users based solely on their associations with such cliques, but it actively harms the further coordinated development of the wiki.

Wikis are built, fundamentally, on working together: on compromise. Forming echo chambers of users determined to support a particular type of policy never yields positive results. Oftentimes, this makes the climate of the wiki intensely hostile to those with a different point of view, and discourages users with alternate schools of thought from contributing in the long run. Without additional perspectives on policy and formatting, it becomes difficult to see the errors in existing policy. As a result, poorly-designed templates, confusing article layouts, and needlessly complicated rules become the status quo, making the experience of using and editing the wiki noticeably more irritating.

Taking on too many roles
No administrator has a comprehensive understanding of every topic of every game, and they are not required to: spreading oneself too thinly is bad for productivity in the long run. There are a limited number of subjects in which an administrator can be highly knowledgeable, so attempting to master every area of the wiki is not a practical endeavor. Instead, most administrators choose to specialize in doing certain tasks. With a diverse group of administrators, this practice can spread out the workload fairly evenly between all sysops. A few common archetypes are listed below, although many administrators fall partially into multiple categories.
 * Content – A focus primarily in patrolling, adding information, and doing various community-related tasks.
 * Maintenance – A focus primarily in formatting, organization, and standardization.
 * Technical – A focus primarily in portability, templates, MediaWiki, and bots.

Disappearing
Taking breaks is fine, and is certainly encouraged from time to time, especially when real life is proving troublesome. When taking time off for an extended period of time (several weeks or more), though, admins should make an effort to remain accessible in one or more ways to anyone who requires their assistance. Remaining active or semi-active on Discord, Reddit, Slack, Steam, and/or other platforms while on a break will prevent a massive flood of messages upon returning to the wiki.

It can sometimes be eye-opening to completely ignore all wiki-related messages, at least temporarily, but disappearing without warning is not conducive to the further development of the wiki, its staff, or its community.

Ultimatums
As Wikipedia's "Don't be high maintenance" essay so excellently puts it, "Threats to 'leave and never come back' inevitably invite the response: don't let the door hit you on the backside on the way out." Troublesome, attention-seeking users are better off gone than continuously pretending that they are going to quit. The only time an editor should make a big deal out of possibly retiring from the wiki is when they are genuinely considering it, not because they want to receive validation from their colleagues. In a similar vein, confronting someone else with a set of demands... "or else!" is equally unwarranted. Administrators, especially, have no business participating in such childish stunts.

Passive-aggressiveness
If there is something to say, it should be said. There is no reason for anyone (and especially not an administrator) to be passive-aggressive to anyone else on the wiki. Over time, this breeds resentment among editors and causes drama. Instead of quietly insinuating a wrongdoing, say it directly (privately or otherwise). Speaking in riddles actively deteriorates the professional relationships between editors that have been built up over the years, and often results in the formation of hostile cliques of like-minded users, which is not good for productivity.

The only way to effectively collaborate on the wiki is to communicate well. Being cryptic on repeated occasions serves no purpose other than to confuse the message's recipient, which is unarguably a bad thing in almost all situations. It can sometimes be advantageous to remain vague in public statements, perhaps to allow for interpretation or to appease multiple sides in a compromise. However, being persistently difficult to understand has no positive effect. It is virtually always better to be straightforward when talking to other users on the wiki.

Not asking for help
Contrary to popular belief, becoming an administrator does not grant one access to the entirety of human knowledge. Even though administrators tend to be very qualified individuals, knowing everything about every topic is an unrealistic expectation or goal. It is not in any way demeaning to ask for help from another staff member. If a question comes to mind, regardless of how stupid it may seem, it is always better to request assistance than to never know the answer.

Tone
Since writing lacks the human aspect of communication (tone of voice, body language, etc.) that exists in face-to-face speech, it can take a great amount of attention to detail when typing up messages to guarantee that the more subtle implications of the message remain true to its intended purpose. Below are three common ways to leave messages, although they are much closer to general observations than rules to be followed:

Relaxed
Communication between friends, especially on the Chat, is often quite informal. Proper spelling, grammar, punctuation, capitalization, and other normally important aspects of writing are not taken as seriously in friendly social contexts as they would be in most other areas of the wiki. This is generally not a tone that should be used on project pages, in Consensus Track threads, or in other more formal activities. Rather, this sort of approach to communication is often adopted for use on talk pages and elsewhere, although many users choose to remain a little more professional.

Guiding hand
Many staff members choose (often subconsciously) to adopt a "guiding hand" tone when speaking with new users. The idea here is to be fairly laid back and amicable (in order to remain approachable), while still maintaining the air of professionalism that is expected from staff members. Using this tone of writing usually entails proper usage of spelling, grammar, punctuation, capitalization, etc., but should not come off as overly dry and certainly not intimidating. Contractions can be used to soften constructive criticism, and many staff members choose to finish messages written in this style with a genuine note along the lines of, "I would be happy to answer any questions you have."

Formal
A formal tone is frequently used on project pages, in CT threads, and when intentionally leaving particularly direct and/or imposing talk page messages, especially to users who have been blocked for breaking a rule. Formal messages often employ a more commanding vocabulary and generally avoid the use of contractions. Staff members occasionally elect to speak in third person in such messages ("the administration" or "the staff" rather than "we" or "us"), but it is quite possible to remain formal and still speak from a personal standpoint.

It is important to note that speaking highly formally all the time is a terrible idea. Doing so is not only incredibly tacky, but it often gives the speaker a permanent notion of self-importance. Many editors, especially younger ones, go through a "formal" phase for several months or even years, in which they refuse to talk like a normal person in order to sound more intelligent. A thesaurus is often used to replace mundane words with lengthier and more obscure (but not always fitting) ones. It is very easy for an experienced staff member to pick up on when someone is doing this, so such behavior is really not necessary.

Criticism
It is impossible to be an administrator and completely avoid criticism. In fact, even if such behavior were possible, it would be explicitly discouraged: the only way that the wiki improves is when its users share their ideas to make a positive change to it. Criticism is not inherently bad, nor is it something to dread in any form.

Giving constructive criticism
A wiki of this size has an unavoidably high barrier of entry for editing many subjects. In particular, most users do not bother to read through the style guidelines provided to them upon joining the wiki, and therefore have a limited understanding of how to format a significant number of articles. This is not a ban-worthy offense for new users. Most proficient editors probably ignored those policies when they first joined, only reading them when it became clear that they must be followed (not that this is something most people would admit publicly). Many folks tend to think that they already understand the gist of the rules without actually having read them; as unfortunate as this may be, it is impossible to totally remove such a mindset among very new users. Given a decent level of encouragement, though, they can definitely be convinced to read through these pages. All it takes is time and a couple of messages.

Instead of blocking new users for not having a perfect understanding of all of the wiki's policies, a much better course of action is to explain to them precisely what they are doing wrong, and especially how to fix it. Such messages should be written in a friendly tone that presents the administration as the people to go to for help, not a bunch of cold, heartless dictators. Perhaps unsurprisingly, those with no prior community management experience tend to go for the kill in these situations, ripping apart the user's edits and even their presence on the wiki. This is not an effective method of giving constructive criticism. There is a fine line between explaining an editing mistake in an objective fashion and making the user feel like they are not welcome on the wiki: an administrator's message should never imply the latter. When leaving this sort of message, I generally follow the following pattern:
 * Amicable greeting, ideally no more than a sentence long. This tells the reader from the start that they are not being reprimanded for their mistake, instantly relieving some pressure.
 * Brief link to the user's error. Without this basic context, the user may be confused as to what is even being discussed. This is a critical part of the message, but usually does not have to be very long.
 * Clear explanation of why they were mistaken, and how to improve in the future. This part often uses multiple sentences in the case of larger issues, but should always be the highlight of the message, regardless of its size.
 * Closing line encouraging them to ask for help in the future if need be. This may seem unimportant, but that could not be further from the truth: it gives the user a friendly figure in the staff to turn to in the future.

Other things to remember are:
 * Keep the message as brief as possible. Although no specific word counts or number of paragraphs can be provided in this guide, it should be obvious that needlessly long-winded messages are deeply off-putting to new editors and discourage them from contributing in the future.
 * Try not to sound robotic. Oftentimes, newly-promoted sysops feel the need to speak much more professionally than they would in any normal situation: this is generally unnecessary. If a more cordial tone is adopted, the user in question will have something else to relate to and will react more positively to whatever is being said.
 * Let other people answer sometimes. Users typically gravitate towards the administrator whose name is recorded on the automatic greeting message on their talk page. There is nothing wrong with this, considering how lifeless the staff project pages can feel in comparison. However, it is beneficial to occasionally allow other staff members to answer questions from this user. If the user interacts solely with one admin, and said admin later becomes unavailable, the user may feel like they have no one to talk to anymore. Introducing more than one authority on editing matters gives them options down the line.
 * Ask them questions too. All edits are made with a purpose in mind. If a user is doing something questionable, it is generally better to ask them why they are revising articles this way instead of more bluntly confronting them about it. This promotes a more cooperative atmosphere because it shows that the administration genuinely cares about why people are making edits on the wiki.

Responding to criticism
It can be extremely difficult for many administrators to reply to a hard-hitting message, especially from a respected user. However, if an editor has an issue with the way the administration is handling something in particular, or even the fundamental approach they take to running the wiki, their criticism should be taken into account by all sysops. Chances are, the author of this criticism has a legitimate reason for stating their opinion in such a way, so their point of view should not be ignored. Honestly acknowledging the concerns presented in their message indicates that the administration welcomes feedback, which is always relieving for users to hear: it means that their thoughts are not being ignored.

Even if a user is quietly insinuating wrongdoings indirectly, the best course of action is to speak to them about it, privately or otherwise. Some users are reluctant to contact the administration directly out of fear that they will be blocked or insulted. Rather than playing into these fears, administrators should seek to be as open to criticism as possible. Administrators should absolutely never respond to criticism with any form of ad hominem or lash out in any other way: such behavior is deeply unprofessional. Instead, it is strongly recommended to remain calm, respectful, and objective when dealing with criticism. This promotes genuine discussion free of any sort of resentment.

Staff members
Communication between staff members is key to the success of the wiki as a whole. In the past, the staff had divided itself into two large groups which correlated roughly to users who mainly edited the wiki itself (patrollers and administrators) and users who focused on social areas of the wiki (Chat and Forum moderators). This was particularly troubling because the two groups began consistently opposing the other in staff nominations and CTs, almost like political parties. To avoid any sort of partisanship in the future, it is always best to approach issues in a way that does not single out a particular user or group, if possible. In other words, explain things in a way that promotes the thinking of "The wiki versus the problem" rather than "This group versus that group."

Presently, staff members are required to have accounts on a private Slack channel in order to stay connected. Although concrete policy decisions are left to CTs and moots, the existence of this platform allows for quicker discussion about smaller or particularly sensitive issues. Slack was chosen mainly because it has good mobile and desktop support, as well as bot functionality. Staff members may also choose to remain in contact with one another on other platforms, such as Discord, Steam, Facebook, or Reddit, but they are not strictly obligated to do so.

Wikia
It is important for administrators to maintain a positive relationship with Wikia. This means sending feedback to the company through the Special:Contact form, and participating in groups such Community Council and events such as Community Connect, if possible. By doing these things, sysops are able to get a bigger say in how Wikia interacts with the wiki and the members of the community. It is possible to be critical of Wikia's plans yet still maintain good relations with them. Without being vulgar, give a genuine opinion about their products in regards to the wiki. Such things will go much smoother if ideas are stated clearly and the administration makes an effort not to sound disingenuous.

As with all software, though, Wikia's products experience delays in production due to unforeseen technical conflicts. If Wikia announces that a feature is coming tomorrow, it is actually coming in two weeks. Since they do not work on weekends, emails sent to them may not be answered on Saturdays or Sundays. Likewise, it is important to recognize that they may not even respond instantly on a weekday because they have more issues to deal with than ones emanating from The Elder Scrolls Wiki. Be patient.

Other wikis
It can also be helpful for administrators to foster relationships with staff members on other wikis, for example on Nukapedia (Fallout Wiki). Although sysops here have no official say in their policy, and vice versa, checking in on other wikis once in a while can be an effective way to discover better ways to get things done. Observing the structure of policy, article layout, and other things on alternate wikis can inspire administrators on here to update these things in a positive way. Typically, users credit the source of an idea if they lift it from another wiki, but given suitable transformation this step may be skipped.

Personal activity
Administrators are highly encouraged to remain active on the wiki when they have the position. Since there are a limited number of sysops on the wiki, and a large number of vandals, deletion candidates, edit wars, etc., the workload can seriously pile up when multiple administrators become inactive for a long period of time. However, breaks are unavoidable. Sysops can always take breaks to handle personal matters, but are expected to make a good faith attempt to maintain a presence on the wiki whenever possible.

The wiki officially recognizes three types of activity for administrators which are reflected in the transcluded template on the project page (see below). They are as follows:
 * Fully active – Regularly checks in on the wiki and completes their administrative duties. This may extend to activity on the mainspace, Forums, Discussions, Chat, or elsewhere. It is possible for an administrator to be considered fully active yet not make hundreds of edits per week.
 * Semi-active – Focuses a comparatively small amount of attention toward the wiki. While relatively active, they do not make use of their tools nor appear on the wiki particularly often.
 * Inactive – Retains their tools but rarely logs into the wiki. This can be acceptable when significant real-life factors temporarily decrease a staff member's ability to carry out their duties.

Note that falling into a lower group does not necessarily mean a sysop must be demoted instantly. Activity is required, but rushing demotions has a very poor effect on the wiki in the long run (see above).

Burnout
A high level of activity is always a good thing, but can lead to burnout over a long period of time. When burnout occurs, a user becomes deeply unmotivated to continue making edits or uploads at a rapid pace or at all or otherwise becomes uninterested in editing due to exhaustion. This can often be prevented by spreading out particularly demanding projects over several days, rather than doing everything at once. Making an excessive number of edits can be very tiring, so taking on smaller workloads over a somewhat longer time greatly alleviates stress.

Loss of interest
Users occasionally find themselves losing interest in editing as a whole; not necessarily because they lack the time to do so, but often because they no longer find it enjoyable. Virtually everyone loses interest in the wiki temporarily, so it can be useful to confide in other staff members who have experienced this issue in the past. Exact solutions to this issue vary greatly from person to person, but interest can frequently be renewed by trying another game in the series for the first time or by experimenting with alternative tasks on the wiki.

Candidate rubric
This rubric serves as a basic way for you to determine how well-suited a patroller would be for the position of administrator in a relatively objective sense. This rubric is not all-encompassing; the qualities listed above should still be taken into deep consideration when voting on sysop applications. Bear in mind that a candidate does not necessarily require a perfect score on this rubric in order to be considered qualified for the position.

Here is some analysis to take into consideration after calculating a user's score on this rubric.
 * A user whose personal skills are more refined than their editorial skills may be a strong candidate for social moderation, where they would only be responsible for guiding discussions and giving new users basic editing guidance.
 * A user with strong editorial and personal skills may fit well into the role of an administrator, as sysops are responsible for making article formatting decisions, carrying out page deletions, and mediating disagreements between users.
 * A user who ranks especially highly in all areas of the rubric, especially the logic and reasoning and temperament categories, may be a strong candidate for the position of bureaucrat.

Select essays
It is fairly easy for new administrators to get caught up in their own "importance" as leaders and forget that the position is not particularly glamorous or desirable. Remember that being sysop entails nothing beyond the duties of an internet janitor. Here are a couple of essays on Wikipedia that would be good for new or aspiring sysops to read.
 * Don't be high maintenance
 * Encourage the newcomers
 * Free speech
 * Imagine others complexly
 * You don't own Wikipedia

How to run the back-end of the wiki if all the admins disappear
New administrators may find the next few sections particularly useful because they give more practical explanations of how to make use of the tools granted by the sysop usergroup. Of course, this would also be a good reference in the event that the administration becomes inactive, leaving only a couple of confused and inexperienced patrollers to run the site in their absence (cough).

Delete
A page can be deleted by clicking the arrow next to the "Edit" button, pressing "Delete," and then hitting "Delete page." A reason from the drop-down tab, or a more descriptive one written out manually, should always be included. A deleted page can be restored by visiting a deleted article, clicking "view/restore," and then "Restore." It is a good idea to include reasoning for why the page in question is being undeleted, especially if it is a contentious topic.

Block
Users can be blocked via the Special:Block form. This can be accessed directly (via URL), or through a button on the "Contributions" tab of a user's profile. If the latter option is used, the name of the user is already filled out, which prevents typos.

Protect
An article should be protected (locked) during edit wars or when leaving it open for anyone to edit would otherwise be bad for the quality of the page. The option to do this can be found on the drop-down tab to the right of the edit button. There are currently three levels of protection:
 * Allow all users – Anyone is permitted to edit the page, including users without registered accounts.
 * Block new and unregistered users – Only accounts which are of a certain age and have a certain number of edits are allowed to make a revision to the page.
 * Administrators and Content Moderators only – The page cannot be edited by anyone who is not a sysop, content mod, or a member of Wikia Staff.

If, for example, an edit war calls for the page to be protected from renames, but not from editing, move-specific protections can be enabled by selecting the "Unlock further protect options" checkbox underneath the initial protection field. Below that is a checkbox to "Protect pages included in this page (cascading protection)," which protects any sub-pages below the specified page. For example, selecting this option on Console Commands (Skyrim) would also lock Console Commands (Skyrim)/Armor, Console Commands (Skyrim)/Characters, Console Commands (Skyrim)/Keys, and so on.

Editing MediaWiki pages
A list of what are in my opinion the most useful MediaWiki pages can be found here, while a full list can be found by sorting Special:AllPages. Note that the links provided on this page must be clicked twice to see the exact MediaWiki pages.

General scripts
A number of the scripts on the wiki are currently located on MediaWiki:Common.js. It's probably a good idea not to mess with these unless you happen to know what they all do, because you could inadvertently remove a commonly-used feature or something. You can import a script by adding the name under the "importArticles" section, or depending on the script you might want to keep the full code below. If any existing scripts need to be loaded before or after others for whatever reason, make sure to respect this. Once you make a revision, you have to submit it for approval by Wikia.

You can also bypass the whole verification thing by just importing directly to MediaWiki:ImportJS. This should work for most scripts.

Game colors
The color of each infobox is controlled from MediaWiki:Common.css/infobox.css. You can find a list of infobox colors here. Qtables, the tables that are used for journals (example), are controlled via MediaWiki:Wikia.css (Special:CSS). If you want to add a new infobox or table color, copy+paste all of the existing code for one of the infoboxes or tables, and then change the name. Don't forget the commas.

Community
To edit the to-do list on the Special:Community page, you have to go to MediaWiki:Community-to-do-list. Note that making this list too long results in a scrollbar, rather than actually extending the length of the page.

Edit Tools
In Source Editor, users can see a small button on the top that says "More," referring to additional symbols that are not included on standard English keyboards. To make a change to this page, you have to visit MediaWiki:Edittools.

Promoting/demoting staff
This is pretty easy. Go to Special:UserRights (only accessible if you are an admin or Staff), type in the username of the person you want to promote (or demote) and click "Edit user groups," then select/deselect the necessary checkboxes. Write a brief note if you want, and then hit "Save user groups." That's it.

Staff MediaWiki/templates
This is what can sometimes take a little longer if you don't know what you're doing: the MediaWiki and templates. You can probably figure out what to do for these yourself, just copy+paste the previous entry for some other admin and replace their name with the name of the person you're promoting. Might have to mess around with a couple other stats, but it's not difficult. Don't forget commas. Here's where you've gotta go:
 * MediaWiki:Common.css/highlights.css – Where you go to apply username highlights.
 * MediaWiki:ProfileTags (formerly MediaWiki:Common.js/masthead.js) – To update the little note at the top of the user's profile that says their position. Also used for MOTM.
 * Template:StaffList – Transcluded on staff pages. Edit the position-specific ones.
 * Template:StaffList/admin – List transcluded on the project page for administrators.
 * Template:StaffList/patrol – List transcluded on the project page for patrollers.
 * Template:StaffList/mod – List transcluded on the project page for Forum moderators.
 * Template:StaffList/chatmod – List transcluded on the project page for Chat moderators.
 * Template:StaffList/news – List transcluded on the project page for news team members.
 * Template:StaffList/bot – List transcluded on the project page for bots.
 * Template:StaffNav – A navbox representation of all staff.
 * Template:StaffTimeline (2011) – A visual representation of all staff. You have to update both this one and the individual ones to do it fully; it's not automatic as they're different templates.
 * Template:AdminTimeline – Timeline transcluded on the project page for administrators.
 * Template:PatrollerTimeline – Timeline transcluded on the project page for patrollers.
 * Template:ForumModTimeline – Timeline transcluded on the project page for Forum moderators.
 * Template:ChatModTimeline – Timeline transcluded on the project page for Chat moderators.

Don't forget to add one of the following templates to their profile if you're promoting someone, depending on the position:
 * Administrator
 * Patroller
 * ForumMod
 * ChatMod
 * News Team
 * Bot

Admin Dashboard
Accessible from Special:AdminDashboard. Lots of great stuff here. You start out on the "General" tab, but there are quite a few additional links on the "Advanced" tab.

Theme designer
Don't touch this unless you know what you're doing. Elchzard happens to have a backup of many of the wiki's files just in case you totally ruin everything, but honestly there's no reason 99% of the time to mess around with this.

Wiki navigation
The local navbar is controlled via MediaWiki:Wiki-navigation. One bullet is the first level of category tabs; two bullets are the drop-down tabs; three bullets are the contents of the drop-down tabs. That's as far as it goes, though. Keep in mind that there are size limitations on this, so you can't add an unlimited number of links here. You can write in plaintext here, but you need to use a pipe link for anything that has a prefix.

Wiki features
Administrators have the ability to enable/disable various Wiki Features. Polls, blogs, article comments, message walls, barring anons from editing, and various "Labs" features such as Chat and Achievements. I would advise not to enable or disable any of these features without prior discussion with the rest of the staff and approval from the community.

Community corner
Distinct from Special:Community is the right rail that appears on Special:WikiActivity from MediaWiki:Community-corner. Edit this sparingly, as it notifies every logged-in user on the wiki of the change, similar to a talk page notification.

Protect site
The "Advanced" tab of the Admin Dashboard features a number of Special pages, one of which is Special:Protectsite. If the wiki is in a state of emergency and you need to temporarily shut down anon/user access to user account creation, article creation, editing, page moves, and/or file uploads, this is where you would go. Be extremely cautious about using this sort of thing, because it could potentially affect thousands of users. You can only limit access to these tools for a maximum of 12 hours, for obvious reasons.

Weekly updates
They don't write themselves. They're posted on Saturdays after the moot, and discuss everything from new rules to new games. I personally date them for Saturday even if I write it on Tuesday, just so I don't confuse myself (and everyone else). Proper record-keeping is important; be sure to talk about everything that's happening on the wiki itself, and also be very sure to remain updated on the progression of the series in general. Here are some links which you will certainly want to make use of if you happen to be writing these updates:


 * Wikia
 * Wikia Staff Blog – General informational blog posts from Wikia Staff.
 * Wikia Technical Updates – Brief lists of small or technical changes to Wikia's code.


 * TES
 * Bethesda News – For general TES-related news.
 * Legends News – For Legends-related news.
 * ESO News – For ESO-related news.


 * Other
 * PC Gamer – My go-to for a basic overview of general TES or PC news that isn't on any of the official sites.
 * Gamers Nexus – If you're gathering technical data on a game, such as performance benchmarks and/or analysis, these guys have their testing methodology down.
 * Anand Tech – If you need info on a new GPU or something, this site has great articles on PC hardware.

I also just tend to search "The Elder Scrolls" in Google under the "News" tab and see what pops up, in case it happens to be an unofficial (but still noteworthy) piece of information. Usually this stuff is just click-baity garbage, but if it happens to be any good then it's often worth mentioning.

The update also requires a unique quote from The Elder Scrolls universe as well as a screenshot taken by a user on the wiki, preferably having been uploaded in the past week. Past quotes are stored on the the project page, which can be used to prevent duplicates. Also remember to add the newest update to the list when you're done writing it. Depending on how distracted I am, writing an update can take anywhere from 30–45 minutes, often near the higher end of that range if I have to do a moot summary. It's not a problem if it takes you longer, though: there's really no need to rush it.

Achievements
You can edit the names, icons, and groupings of achievements from Special:AchievementsCustomize, which is linked on the right rail of Special:Leaderboard. We have a backup of the achievement images here, in case you accidentally replace an icon with something unfitting.

Since Wikia doesn't give sysops access to Special:Platinum, you need to get a Wikia Helper or Staff to update the page to include new Members of the Month, which will grant them a Platinum-level achievement for MOTM.

Discussions
While the guidelines are stored on TES:Discussions, a permanent link to them can be found here for optimal accessibility on the app. Note that not all formatting works properly in the latter page, as Discussions does not presently support wikitext.

Main page
A lot of stuff on the front page is displayed via templates, so it can't all be edited in one place. Fortunately, it's not that complicated. If you go to the page's source code, you'll first notice the code for the Slider, which is probably the most visible part of the main page. This is simply a type of gallery, and you can use the existing formatting as a baseline on how to change the images and text on it. The Portal section below doesn't have to be updated until a major new game comes out.

Next is the News section, which lists recent blog posts in a given category under a group of tabs. To make a blog post appear here, you have to add it to the category specified on this page. For example, if you want a news blog to show up under the News tab, you have to add the category News to the blog itself. You'll see a few other templates underneath that which you can leave alone. After those come the widgets on the right rail.

The advertisement for the wiki's mobile app doesn't require any maintenance unless the URL to the app changes for some reason (unlikely). The "Helping Out" box contains a few links to get readers started on editing; you can change this if you feel it is necessary, but be careful not to make it too long. The Twitter and Facebook widgets update automatically and require no input from you.

The MOTM (Member of the Month) section needs to be revised every time there is a new winner of the award. The recipient's name should be updated from here, and you should write a short blurb detailing how their edits have helped the wiki here. Be careful to write your description inside the  tags, and leave the text within the   tags alone.

Try to update the main page's Poll every so often, just so that visitors have something to do on the page. It uses the standard poll tags, so text on the first line after the tag is the question, and text on every new line after that is an answer choice. The code below that is necessary to prevent the main page from functioning like a normal article, so there's no reason to touch it.

The final thing you have to do is to update the list of languages every time a TESWiki in a foreign language is created. Each language that the wiki is written in (excluding English) is listed by its ISO 639-1 code, a two-letter abbreviation of its name in English. You can find a list of these codes here. These links will appear the way they are written in their respective languages so that foreign readers can access their proper wikis with relative ease.

Bots
Wikia Staff are the only ones capable of giving an account the bot flag (done through Special:Contact/general), which prevents it from flooding activity feeds such as Recent Changes and Wiki Activity. After sending a request for that, you should promote the account to Content Moderator (rather than admin) so that it can't wreak total havoc if it becomes sentient. It's also accepted practice to have a link pointing to the operator(s) on the bot's profile.

AutoWikiBrowser
AutoWikiBrowser (AWB) is a pretty easy way to have a bot do simple find & replace tasks such as link, template, and file corrections and some general maintenance. While it requires no programming knowledge, its functionality doesn't extend very far beyond simple maintenance tasks. For a brief explanation on how to use AWB, see here.

When running automatic scripts, it's a very good idea to personally oversee the first few edits to see if any unexpected issues arise. Most of the time, something comes up: if you don't catch it early on, you'll be spending a long time fixing every mistake the bot made on your watch.

If the type of maintenance you do frequently requires you to load every content article on the wiki, I would recommend basing the list off of the recursive category tool with the wiki's main hub category, Browse. This will load all namespaces included in that category, which covers several hundred thousand pages in total. Filter that list to just include the mainspace, and then save those settings as your default. It will load much more quickly upon startup. Just be sure to clear that list (List → Clear current list) before loading a different saved list.

PyWikiBot
PyWikiBot (PWB), which runs on Python, is an alternative. It's a little more difficult to use since it requires a certain amount of programming knowledge, but has many more uses.