Using Wikibooks/Advanced Administration< Using Wikibooks
In this page we are going to discuss a variety of administrator-related topics. Some topics are for all admins, while others are only for bureaucrats or checkusers.
The Wikibooks site licenses (GFDL and Creative Commons) require that the history pages, and thus the trail of authorship and attribution, must be preserved. This is one of the reasons why we have the import tool, instead of simply using copy and paste moves from other wikis. The import tool preserves the page history, which helps us to stay in compliance with the license.
Copy and paste mergers between pages are technically a violation of the license. There are two ways to avoid this problem. The first is to provide a backlink to the history of the merged page. This can be done with a short note in the edit summary including a permanent link to the version copied. The better method is to merge the histories.
How to MergeEdit
Historically administrators used some loopholes in the deletion system to merge the histories:
- Open the edit view for the top revision of the target page in another window or tab;
- Move the source page to the target page;
- You will be warned that the target page already exists, and asked if you would like to delete it;
- Delete the target page;
- Go to the history view for the target page and undelete the deleted revisions with a reason like "history merge";
- Go to the edit view you opened at the beginning;
- Save this revision with an edit summary like "restoring current version"
If all has gone according to plan, you will have your chosen revision on top, with all previous history of both pages mixed together in the page history. More recently a Merge History tool has been developed and is available to Administrators.
User renaming is reserved for bureaucrats, and is very much ignored in policy or guideline documentation. Because of this, bureaucrats are given wide latitude in determining whether and when to rename users. This section will attempt to outline some of the common practices, but should not be misconstrued as a description of things that "always" happen, or that "must" happen.
The renaming process is typically facilitated through email, so people who are requesting a username change should have a valid email address registered, and should have their preferences set to accept emails from other users. In this way, if there is a problem with the rename, the bureaucrat can stay in touch with the user.
A doppleganger is when a person creates the same username on Wikibooks as a real user on another WMF project, such as Wikipedia. This often happens as a form of harassment or personal attack, and is generally not tolerated.
Another common occurrence is for people to create usernames that appear similar to another screenname, in order to impersonate or harass other users. A Mediawiki extension was created that prevents usernames from being created if they are too similar to an existing username. Unfortunately, this extension creates new problems, as legitimate users may be prevented from registering a desired username. Admins (not just bureaucrats) may follow this link to create a username and bypass the protection mechanism: CREATE NEW ACCOUNT.
When you create a new account for a user, make sure you get that user's email address. You can then email them the username and the password. Make sure the user does the following immediately:
- Change the password to something strong.
- Register an email address for contact, in case there is a problem.
Interwiki Rename RequestsEdit
Often times, when a user is renamed on Wikipedia or other wikiprojects, they will ask to be renamed here as well. Bureaucrats typically ask for some kind of confirmation that the user account here really does belong to the same person as the user account on the other project.
Usurpation is the act where one user assumes a username owned by another person. Wikipedia has a number of strict guidelines on this subject, but Wikibooks does not. However, a lack of rules on the subject does not mean that username usurpations are performed regularly or without proper consideration.
While all the details are left up to the judgment of the bureaucrats, a usurped username typically needs to be:
- Blocked indefinitely with little or no hope of ever being unblocked
- Have few if any legitimate edits, and few if any log entries (such as file uploads, page moves, etc)
- Have been created a long time ago, and not having been used for a long time.
If the username to be usurped has an associated email address, a request should typically be sent to ensure that the current owner of the username is amenable to the usurpation process.
Single User Login, (aka "SUL" or CentralAuth) is a MediaWiki extension that allows usernames to be shared among all WMF projects. Many users looked to usurp or obtain their username on other projects in order to protect them during the consolidation process.
When SUL was initiated, duplicate usernames were awarded to only one of the owners, typically the owner with the highest edit count or most privileges. To protect against losing their usernames, many users may ask to be renamed, or to have accounts protected.
Admin promotions, bureaucrat promotions, and granting the bot flag are performed by a bureaucrat in response to affirmative community support. Exactly what numerical value of support votes a bureaucrat must see before they will perform the promotion is variable.
About 10 support votes, or so, is a decent number of votes needed to promote an admin. Admins can be, and have been in the past, promoted with as few as 5 votes, but typically a bureaucrat should wait for a greater showing of support before any promotions. Promoting a new bureaucrat is a much more conservative process, and a bureaucrat should wait to see significantly more votes than they would expect for an average admin promotion before promoting a bureaucrat. All of these are just suggestions, of course, and depend on the activity level of the community, the reasoning behind support and opposition votes, and other factors.
Bots and the Bot FlagEdit
Granting a bot flag is an issue where bureaucrats on Wikibooks have historically been very conservative. The bot flag really exists to prevent an active bot from flooding the RC list and thereby preventing vandalism monitoring operations. It's the general opinion that an account should only be given a bot flag if they have demonstrated an ability to flood the RC list on a regular basis.
Many people use automated and semi-automated scripts from regular user accounts. However, this is strongly discouraged if the user does not have the Reviewer right. If the account does not have the Reviewer flag then every single automated change will have to be manually reviewed. Before contemplating making automated or semi-automated changes ensure that you have the Reviewer flag on the account you plan to use. The Bot flag includes the Reviewer right.