|This page documents a Wikidata policy. It is a widely accepted standard that all editors should normally follow. Changes made to it should reflect consensus. When in doubt, discuss your idea on the project chat.|
CheckUser is an interface that permits authorized users to examine the IP address information of users on Wikidata. The term CheckUser also refers to a user with such access.
The CheckUser tool is to be used to combat vandalism, to check for sockpuppet abuse, and to limit disruption of Wikidata. It must be used only to prevent damage to any Wikimedia project.
The tool should not be used for political control; to apply pressure on editors; or as a threat against another editor in a dispute. There must be a valid reason to check a user. Alternative accounts are not forbidden, so long as they are not used in violation of the policy.
- Note: The following section only applies once Wikidata has two active CheckUsers. Until then, stewards are to continue current CheckUser duties without regard to this section.
Stewards may perform checks on users at Wikidata if the outcome of the checks will result in global actions (global blocks or locks) being performed. This mainly includes cross-wiki abuse. Stewards must have tried to contact at least one local CheckUser or have a valid reason for performing this check themselves instead of local users. For the purposes of this section, IRC, on-wiki message, or any CheckUser-related mailing list (checkuser-l in particular) may be acceptable, but if questioned, a local CheckUser (preferably the one(s) the steward attempted to contact) should be able to verify that contact was made if it was done in any means other than an on-wiki message.
Stewards are required to notify local CheckUsers after they perform checks.
CheckUser may be used to verify a need for IP block exemption and to identify the target of the block if need be.
The tool may be used to investigate credible and legitimate cases of sock puppetry or abuse of multiple accounts in accordance with the alternate accounts policy. A credible and legitimate case of sock puppetry is one for which sufficient evidence, especially in the form of diff links, has been provided indicating likely abuse of multiple accounts.
The tool may be used to evaluate the collateral damage before blocking a range that has been used by long-term abusers.
The tool may be used to hardblock IP addresses or ranges of users when blocks of accounts combined with autoblocks will not suffice to prevent disruption. However, appropriate care must be taken when conducting these blocks to protect the privacy of registered users.
A CheckUser block is a block where CheckUser-confidential evidence has been used to come to the conclusion and matters regarding the block (unblock, IPBE etc.) are required to be dealt with by CheckUsers only, for privacy reasons.
Only administrators who have permission to unblock from a CheckUser may remove a CheckUser block. Administrators who remove CheckUser blocks against policy may be subject to the removal of the administrator rights in accordance with the standard process of removal.
A successful request for the CheckUser right will have the following: a minimum of 25 support votes, a minimum of 80% support, and two weeks of discussion on the candidate. In accordance with the global policy, all successful candidates must be at least 18 years of age, of the age of majority in their jurisdiction, and identified to the foundation.
Bureaucrats will close requests for the granting or removal of CheckUser access, and will post at m:SRP accordingly.
A CheckUser will have access to Special:CheckUser, which is the main interface for running checks, and Special:CheckUserLog, which allows viewing of a log of all recent checks made through the interface. At this time, Wikidata has no local CheckUsers, so stewards will serve as local CheckUsers. m:Steward requests/Checkuser can be used for requesting CheckUser information from stewards.
The CheckUser flag can be removed by a removal request with 1/3 support in favor of removal.
CheckUsers will follow the inactivity policy discussed in the inactivity definition RFC. However, if the rights are not used for an extended period, the removal request process can be followed.