UDWiki:Administration/Guidelines
What are System Operators on this Wiki?
There are currently only two kinds of administrators on the wiki, system operators (commonly abbreviated 'sysops') and bureaucrats.
Sysops have several abilities beyond that of the average user. They can:
- Ban users and IP addresses from the wiki
- Delete and undelete pages
- Protect and unprotect pages
- Move pages to new titles
Bureaucrats can do everything that sysops can do, but can, in addition, promote and demote users to sysop status.
The current Sysop roster can be found here, and the Bureaucrat roster, here.
This page provides guidelines as to the conduct of system operators, and the use of administrative abilities. All system operators are expected to follow the guidelines listed below, and not following these is considered misconduct.
These guidelines are the effective will of the community at this point in time. Modification of these guidelines is expected as a part of the growth of this community. Those wishing to modify any part of this document should discuss the changes on this page's talk page. Consensus of the community is required in order to change these guidelines.
Owner Privilege
As owner of this wiki, Kevan is not required to follow any wiki guidelines, and he has full carte blanche of any activity within the wiki. Further, Kevan retains the ability to promote and demote system operators as he sees fit; assign or remove administrator status from anyone; overrule any promotion, no matter how much or how little support the prospective user may have; overrule any administrative decision or ruling; and generally exercise complete and total authority over any wiki activity.
General Conduct
Administrators are provided with abilities beyond that of normal users in the expectation that they will be used to fulfill duties on the wiki that normal users are not capable of fulfilling. System operators are not any "more worthy" than any other user, and system operators are not to use their status to create the impression that they are. System operators are merely especially trusted wiki users, and are beholden to the community just as any other user is. For most actions on the wiki, a system operators' word has no greater weight than any other user. As a wiki, for these actions, each user's voice has equal weight, regardless of his or her abilities.
In some instances, however, system operators are considered to have greater authority than normal users so that they can effectively fulfill their responsibilities.
- System operators are considered "more authoritative" than normal users in the sense that only sysops can make decisions regarding administrator-specific responsibilities, and only system operators can definitively enforce wiki policies.
- System operators, as trusted users of the wiki, are given the right to make judgment calls and use their best discretion on a case-by-case basis. Should the exact wording of the policies run contrary to a system operators' best good-faith judgment and/or the spirit of the policies, the exact wording may be ignored.
- System operators are also given the authority to make decisions regarding actions for which there is no governing policy in place. For example, should a particular action for which there is no policy be disputed, system operators may exercise their best judgment to allow or deny it.
- Past administrator actions that are not explicitly governed by a policy may be used as precedent, but if a system operator believes that the precedent should be ignored for some significant reason, he or she may do so.
- Despite having access to CheckUser, system operators are still bound by the terms of the privacy policy.
For any administrator-specific actions, if a system operator is found to have been in error, the processes of sysop misconduct may be used to resolve the issue.
In short, a system operator is to be treated as a normal user, with all the rights and responsibilities therein, with some additional responsibilities and associated rights so that they can fulfill those responsibilities.
Deletion and Undeletion of Pages
Deletion of pages is restricted to system operators due to its permanent nature — deletions can't be reverted by normal users, and deleted images can't be reverted by anyone. The following guidelines outline when system operators may delete pages.
System operators may only delete a page in one of four instances:
- A page has been listed on UDWiki:Administration/Speedy Deletions, and that page is eligible for Speedy Deletion according to the current guidelines for Speedy Deletions. Before serving the request, system operators are expected to review the page to ensure its suitability for Speedy Deletion.
- A page has been listed on UDWiki:Administration/Deletions, and that page has been deemed eligible for Deletion by the wiki community, in compliance with the rules of the Deletions page.
- A page has been created by a system operator in the User namespace as a subpage of the administrator's user page, no user other than the administrator has made substantial contributions to the page, and the page is not required for any significant reason. In this case, the system operator should make note of his or her deletion on UDWiki:Administration/Speedy Deletions either before or after he or she has deleted the page.
- When acting in accordance with approved policies.
Except in the third instance listed above, a system operator may not delete a page that he or she has requested be deleted. It is part of a system operators' responsibility to check the Speedy Deletions and Deletions pages often and serve any pending requests, subject to the guidelines above, and review the administrator Page Deletions page often to ensure that administrator user pages have been deleted properly.
The ability to undelete pages is restricted to system operators, and normal users are limited to recreating pages. As such, in the case that a deleted page is in need to be restored, regular users can request the restoration through the Undeletions page. System operators may only undelete pages that have been requested to be restored through this page, or that they themselves have deleted by mistake. The repeated recreation of deleted pages not going through the Undeletions page is to be treated as Vandalism.
In some circumstances, scheduled deletions may be required to avoid clogging the Deletions or Speedy Deletions pages. In this case, it is not expected that each deletion be requested through the Administration pages. Instead, the schedule should be approved by the community at the Scheduling subpage. Approved schedules are listed in the following subsection.
Scheduled Deletions
- Image revision removal
- Image revisions that are older than 7 days are to be removed.
- Approved 16 May 2006
- Monumental Screw Ups
- Pages in this form: with//////lots//////of//////slashes, and this one: http://wiki.urbandead.com/index.php/Example_monumental_screwup are unable to be moved or edited via normal means. Their content is to be manually moved to a sensible pagename without extraneous //s in its title and the original page is to be deleted on sight.
- Note to sysops: A method for deleting these pages can be found here.
- Approved 23 August 2006
- Unused redirects resulting from page moves
- redirects resulting from moves, that only show admin pages in their "what links here" list.
- Approved 3 Mar 2007
- Copyrighted images
- Images that are requested to be deleted by the copyright holder
- Approved 10 Nov 2007
- Broken redirects
- redirects that lead to nonexistent pages
- Approved 12 Dec 2007
- Personal Information
- If a user wants personal information about themselves deleted from the wiki, they should be able to get it speedy deleted. Things like your name, your phone number, your email or home address, your workplace, pictures of your family etc. Link
- Approved 11 July 2008
Porn is to be deleted on sight.- I like porn, you like porn, but this isnt the place for it.
- Approved 22 July 2008
- Revoked 2 August 2009
- User page redirects
- in the main space should be delete on sight as crit 3 or 9 (excluding those redirecting to Kevan).
- Approved 26 November 2008
- Swearing in page titles
- Pages that have swearing in the title that is directed at a user or group (or their actions).
- Approved 22 July 2008
- Crit 7 by Proxy
- If a user leaves a sysop a note on their (i.e the sysop's) talk page requesting deletion of a page that falls under Crit 7, the Sysop may delete the page on sight, making clear in the edit summary that the user requested it via talk page.
- Approved 26 March 2009
- As of January 2010, this scheduling now includes pages that the author has blanked or replaced with text indicating a desire to be deleted. However, pages used as inclusions (such as many templates) are excluded from this criterion.
- Approved 3 January 2010
- Crit 11
- Userpages/Journals that are in the User: namespace but are non-existent users, and are already duplicated in the appropriate User: or Journal: subspace may be deleted on sight.
- Approved 30 June 2009
- Adbot-created pages
- Pages created by Adbots and Spambots are to be deleted on sight.
- Approved 30 July 2009
- Unnecessary banned user pages
- The User: pages of permabanned spambots and vandal alts (that have no contributions showing) are to be deleted on sight.
- Approved 27 November 2009
- Grouped location pages
- Grouped location pages are to be deleted once each individual location has its own page and all incoming links (excluding those refrencing deletion) are diverted.
- Approved 1 December 2009
- Unused Image Removal
- Images on the Unused Image list that are two weeks old are to be deleted. Images that are linked by text only will appear on the unused image list also.
- Approved 10 December 2009
- Associated talk pages
- Talk pages associated with pages that are deleted under other policies, including talk pages missed in previous deletions.
- Approved 19th May 2010
- Amended 14th August 2011
- Crit 9
- Personal Page (Prefix Rule): The page is named after a user without the "User:" or "Journal:" prefixes and its content has been moved to the appropriate User or Journal page. Includes pages that should be User subpages, ie. in-game characters.
- Approved 29th August 2011
Protection of Pages
Protection of pages is restricted to system operators due to the inherent nature of the action — protections would not be useful if regular users could protect and unprotect pages at will. The following guidelines are the rules that govern system operators' actions in regards to page protection.
System operators may only protect pages that users have requested be protected on UDWiki:Administration/Protections, or (for a short period, and without the need for a protection request) high-visibility pages that are undergoing repeated vandalism. Before a page is protected, it is expected that the system operator will ensure that there is good reason for its protection — these include protracted edit wars, and constant vandalism by multiple users on a high-visibility page. Further, except in the instance of heavy vandalism mentioned above, system operators may not protect a page that they themselves have requested be protected. It is part of a system operator's responsibility to check these pages often and serve any pending requests, subject to the guidelines above.
In the event of protection, a system operator is expected to protect the page in whatever state the page was in at the time the request is reviewed, regardless of its original state.
In some circumstances, protections on a scheduled basis may be required as part of a system on the wiki. In this case, it is not expected that each protection be requested through the Administration pages. Instead, the schedule should be approved through UDWiki:Administration/Protections/Scheduling. Approved schedules are listed in the following Subsection.
Scheduled Protections
- Inactive Open Discussions - Open Discussions that have had had no discussion for 6 months will be protected. Approved 17 Sept 2018.
- Administrative Templates - Templates with administrative only purposes which have been categorized as such in the Administration Templates category. Approved 24 May 2011.
- Closed Polls - Polls which are held through UDWiki:Poll and have been concluded. Conclusion is defined as the point at which the author of the poll posts their conclusions. The talk page of the poll remains unprotected. Abandoned or withdrawn polls can be protected without the need for author conclusions. Approved 16 March 2011.
- Historical Events - Events which are voted Historical are to be protected on sight. Their talk pages should stay unprotected. Approved 12 August 2009.
- Administration archives - Archives of the administration pages will be protected upon creation. Approved 15 November 2007
- Spamminated and Removed Suggestion Pages - Individual suggestion pages that were spamminated or removed from voting. Approved 3 June 2007.
Suggestion Day Page Protection - Each Suggestion day vote page will be protected after its given voting period, and after the intro template has been replaced. Approved 11 Dec 2005.Suggestion Day Pages are no longer an active system.- Policy Discussion Protection - Polices on policy discussion for which voting has ended, and their talk pages, will be protected. Approved 23 Aug 2006.
- Historical Groups Protection - Groups that are listed in Category:Historical Groups. Their talk pages should stay unprotected. Approved 8 Sept 2006., Ammended 14 May 2019.
- Suggestions Archives Protection -
The suggestions archives of undecided, peer rejected (after voting for the days have closed) and the previous days archives. Approved 8 Sept 2006.Suggestions that have finished voting and been archived. Revised due to Suggestion system changes. - Banned Users Protection - Users who have been banned should have their user pages, user talk pages, and any subpages of their user pages or user talk pages protected for the duration of their bans. For example, a user banned for 24 hours would have his or her pages protected for 24 hours, and a user banned permanently would have his or her pages protected permanently. Approved 11 Sept 2006.
Editing of Protected Pages
As a subset of their administration powers, system operators also have the ability to edit protected pages. Given that sysops and bureaucrats are the only users who can edit protected pages, it is expected that system operators take care to edit protected pages only in good faith, and not without good reason. System operators are explicitly given the right to edit a page that has been protected due to constant vandalism, and changes are necessary to revert the vandalism. Requests for a system operator to edit a protected page should be placed under the Requested Edits heading on the protections page.
Unprotections
Any user may request on the protections page that a page be unprotected. If there is no longer a need for the page to protected, a system operator will then fulfill that request.
Moving of Pages
As a result of frequent page move vandalism, the 'move' permission on this wiki has been restricted to specific user groups (currently sysops and bureaucrats; this may change in the future). If a normal user wants to move a page, they will need to request that do so on the Move Requests page. All reasonable requests will be carried out by those who have the 'move' permission. Any user still able to move pages will not need to request another user move pages for them.
Warning and Banning of Users
Introduction
Warning and banning of users is restricted to system operators due to security reasons — a conflict between two users could easily escalate to a constant ban war if such power were available to all users. It is expected that a system operator will always try to look at a reported edit from the viewpoint that it is a good faith attempt to improve the wiki. Also, it is expected that a system operator be prepared to reverse a warning/ban should the community desire it. It is part of a system operator's responsibility to warn or ban any vandals they find on the wiki, subject to the guidelines below.
System operators may also choose to ban the IP of a user for the same duration that the user's account was banned, provided that the system operator believes that the user is circumventing their account ban, or is planning to do so.
When a system operator warns or bans an user, the action should be noted on the UDWiki:Administration/Vandal Data page.
What is Considered Vandalism
System operators may only warn or ban users who consistently vandalize the wiki. Vandalism is by definition an edit not made in a good-faith attempt to improve this wiki, and includes any actions which are defined to be vandalism by approved polices. Many examples of this can be found on UDWiki:Vandalism. Additionally, some pages may have specific rules as to their usage, and consistent and flagrant disregard for those rules may also be considered vandalism.
When a User May be Warned or Banned
System operators may only warn/ban a user when:
- The user is an alternate account of a vandal that is still under his/her ban period.
- The user is an adbot (a type of computer program used for automated edits such as the creation of pages/links with no legitimate purpose).
- The user has made at least 3 (three) edits, at least one of which is deemed vandalism, and none of which are deemed to be constructive or to the benefit of the majority of the wiki.
- A report has been filed through UDWiki:Administration/Vandal Banning, and the user doesn't match any of the previous instances shown above. In this instance, a system operator is specifically given the ability to warn/ban the user before a report is made on UDWiki:Administration/Vandal Banning, as long as the report is placed on that page shortly thereafter by the system operator or someone else. Furthermore, system operators are specifically given the ability to both report and warn/ban a user.
- Acting in accordance with approved policies.
- The user itself requested his own ban for personal reasons.
In the unlikely case that a system operator bans a user without merit or without following the guidelines above, and a Misconduct case is filed against him or her, said system operator may be banned for the same duration of time that the user was unfairly banned, should the ruling system operator on the misconduct case deem it necessary.
Additionally, some users may be under limitations imposed by an Arbitrator according to the UDWiki:Administration/Arbitration page. In that case, a violation of those limitations will be treated as vandalism subject to the same treatments as the fourth instance shown above, while ignoring warnings, as per the UDWiki:Administration/Arbitration page's rules.
Cycle of Warnings and Bannings
In all but the fourth of the above instances, and the fifth should the system operator believe that the case doesn't merit the permaban laid out by standing policy, he/she should impose an infinite ban without a warning. In the case of the fourth and fifth instances (the latter only if the system operator rules that a permaban is not applicable), the system operator is expected to warn/ban the user according to the following process:
The first action to be taken is to warn the user. A user must be warned at least twice (in response to at least two different reports) before a system operator may administer the first ban. Warnings are to be placed on the talk page of the user's account and recorded on the vandal data page. No ban shall be delivered if the user has less than two standing warnings on his or her record on the vandal data page, even if he or she has been banned before.
To encourage users to reform and become good contributors to this Wiki, a single vandal escalation can be struck out for every 250 good-faith edits the warned user makes, provided that one month has passed since the user's last infraction, with another month for every subsequent striking after the first in the series, restarting in the event of a vandal escalation. If a user has more than two vandal escalations, the first escalation struck shall be the second warning, followed by the bans in descending order of severity (if any), and finishing in the first warning.
If the user is still found vandalizing this Wiki and his or her two warnings still stand, the system operator then may ban the user. The bans shall be escalating in nature, the first being for 24 hours, the second being for 48 hours, the third being for one week, the fourth being for one month, and any subsequent ban being for one month with the possibility of a permanent ban as outlined in the Reducing Vandal Escalations policy.
