Star Trek Timelines:Administrators guide

From Star Trek Timelines Wiki
Revision as of 05:25, 6 May 2017 by Titan (talk | contribs) (Deleting)
Jump to navigation Jump to search

Public wikis successfully operate on a basically democratic level. This doesn't mean that every decision is voted on, but in general, decisions on a wiki should be made by reaching a consensus whenever this is reasonably possible. The following guidelines are provided to help administrators exercise good judgment:

Assume good faith
When there's doubt about whether an edit was intended to help the wiki, assume it was and treat the editor that way. If an edit is obviously abusive, feel free to take appropriate action, but where's there is doubt, give the editor the benefit of that doubt.
Administrate users, not content
When it comes to the content of the wiki, the voice of an administrator should be treated as the equal of any other user. Administrators should only impose their opinions when the community fails to come to a reasonable consensus. Otherwise, administrators should try to get disagreeing users to discuss the situation. Administrators may offer their opinion as well, but they need to take care not to sound as though they're enforcing it.
Be light-handed
Try to settle problems with the minimum use of administrative powers reasonably possible. For example, if two editors keep reverting each others' edits on a page (edit warring), warn them and try to get them discussing it first. If that doesn't work, temporarily protecting the page might be a better option than blocking either editor, especially if it's just a matter of getting their attention. Try to use blocks as a last resort and warn first where possible.
The above doesn't apply to spammers, but don't place indefinite blocks on anonymous users. IP addresses change over time and an indefinite block might eventually affect a legitimate editor. In most cases, blocking spammers is rarely very useful as they don't often spam more than once from the same IP, so it's usually best to just clean up the spam. If serious problems with spam crop up, bring it up with your wiki's Curse liaison.

Types of Administrators


See Star Trek Timelines:Ranks for more information

For this document all are referred to as administrator. This status is not intended to represent extra weight within community decisions or generally directing the wiki, nor is it a requirement for moderating or enforcing policy. Like all users, administrators are expected to respect policy and consensus.

Wiki design rules


stt.wiki encourages our admins and editing community to not only contribute wiki information, but to help improve the design of this wiki. This community-driven project relies on editors to succeed, and we appreciate your efforts! When altering the design of this wiki, if you're not sure if something is allowed, contact us via one of the methods below.

Feature requests


Have an awesome idea for a wiki? We're constantly adding new features and expanding the functionality of this wiki. Please contact us via the links below to suggest a feature.

Questions?


For questions or concerns about wiki design, please visit the Admin_noticeboard, the Community_portal, or my (Titan)'s talk page

Blocking


See: Star Trek Timelines:Block policy

Deleting


See: Star Trek Timelines:Deletion policy

Protecting


Protecting a page restricts it from being edited. This is primarily used for pages that have a high chance of being vandalized (Main Page) or as a temporary measure on a page that is the subject of an edit war or mass vandalism. There are three different kinds of protection:

  • Semi-protection: Only registered users are allowed to edit the page. Any anon (IP) contributors will still be able to see the source code, but are unable to make any changes.
    • This version makes a lot of sense on a page that is getting a lot of anon vandals, but it's not very useful in preventing an edit war.
  • Full-protection: Only administrators are allowed to edit the page.
    • This version should mainly be used on high-profile pages (the Main Page), pages that should never be changed by a non-administrator or as a very temporary measure to stopping an edit war. Please note that, when dealing with an edit war, no matter which revision you choose to protect, it will be the wrong one. Try to keep any pages protected for as short of a time as possible.
  • Cascading protection: The page and all images, pages, and templates included into the page are also protected.
    • Cascading protection should NEVER be used with semi-protection. Since Cascading protection automatically full-protects all included pages, any registered user can add an image or template to that semi-protected page to cause it to be full-protected (something that only administrators should be able to do).
    • This is an emergency measure, typically used to temporarily protect a very high-profile page (Main Page) if a change makes the images/templates used vulnerable. Try and avoid this option if at all possible, as it may protect templates that are used in other locations (create a duplicate copy of the template and protect that instead).

Move Protection


By checking the "unlock move permissions" box on the "Confirm protection" screen, the page move rights can be restricted independently of page editing. This is most often used on Project pages that anyone should be able to edit, but that should generally not be moved.

Create protection


If a page does not exist, it can be protected against creation in the same way that an existing page can be protected from moving and editing. This is generally only done for pages which are frequent vandalism targets with no reason to exist, such as "index.php".

Protecting images


To protect an already uploaded image from being replaced with a newer version (such as images used on the Main Page), you can simply use the Protect button like with any other article.

Once in a while you may come across some image filename that shouldn't be uploaded at all to the wiki, (e.g. "File:Example.jpg"). To achieve this, simply edit the page of that image, (for example to add a reason why that page was protected). After this page has been created, the Protect button for that article will be available, and users trying to upload the image after that will receive a warning message that the page has been protected and will be unable to proceed.

Notes on protection


When used to temporarily stop an edit war, protection may be viewed as an endorsement of that particular version. This is not the case. Be careful to remind other users of this and start a discussion on the talk page of the article to resolve the conflict.

Rollback


Any user can revert a page by going through the page history. Administrators gain access to an additional rollback link to expedite the process. To revert the edits of one user to the last version by the previous editor, click rollback on the page history, the user contribution list, or on the diff page. The reversion will be marked as a minor edit and given an automatic edit summary based on the contents of MediaWiki:Revertpage.

Impartiality


Most active administrators also actively edit the wiki. This occasionally causes conflict of interest. For example, if people start personally attacking you after an edit to an article, blocking them yourself makes it appear as if you're using your administrator tools to control wiki content.

Thus:

  • If you're editorially involved in a conflict, request another administrator's intervention.
  • If you're personally involved with a member of a conflict, request another administrator's intervention.
  • Only mention your administrator status when justifying or explaining an administrative action.

Cultural reverence of administrators


Administrators do not have any say in the editorial process beyond that of any other editor. At least, that's what we like to say. More accurately, administrators absolutely do have a bit more voice than non-administrators. This extra voice is completely unintentional and stems completely from the culture of the wiki -- people look up to administrators and are more reluctant to dispute them. Even though this reverence is not the administrator team's fault, nevertheless, every administrator should be careful to avoid abusing this additional editorial power. Specific suggestions on how to do this are, by nature, controversial -- thus, if you disagree with any suggestion below, please note flaws with said suggestion here instead of simply removing it. If you really feel it doesn't belong, take your case to the talk page.

Some possible ways to avoid abusing non-systemic administrator authority follow, roughly sorted from simple to complex.

  • Negate the importance of the administrator role if it gets brought up in an editorial discussion.
  • Be a little more explanatory than usual. Justify edits more completely. Post in talk more often if something might become controversial. This is good advice for everyone, but it's doubly important for administrators -- a lack of an edit summary for any non-minor edit can give the impression of unilateral action.
  • Remind people that usual cultural considerations apply to administrators, too. For example, occasionally add "if you disagree, please revert" to your edit summary or talk post. Even though people are always free to revert like this, explicitly stating so helps them get over the fear of reverting an administrator.
  • If you get administratively involved with an article, avoid being editorially involved with that article for some time.

Other useful notes


  • Watching (and watchlisting) the Admin noticeboard is useful for awareness of currently requested tasks. Remember though, that an issue being listed there does not necessarily mean that administrator action is required.
  • Administrators should also have their email accessible through the "Email this user" link located in the toolbox from their Userpage. To do this, go to Preferences and make sure that Enable Email from users is checked. This offers the community access to discuss issues (blocks, protections etc.) outside of the view of the general community. If an issue is brought to attention in this fashion that requires community input, the administrator should post it as is appropriate.