विकिस्रोत:Restricted access policy

Restricted access policy

[[:|WS:AP]]

This page codifies restricted access on Wikisource. Restricted access refers to user groups that are not granted automatically by the software (particularly administrator, bureaucrat, and checkuser access). Checkuser access is also governed by the Foundation checkuser policy.

Obtaining access

Consensus

Restricted access may be given following a community election to determine consensus. The nomination should explain why the user needs the access; see the nomination archives for past nominations.

The vote will he held for at least one week. Although any user is welcome to discuss the nomination, only established editors may cast a vote with weight.

A bureaucrat will eventually archive the discussion and, assuming consensus, give access to the user.

Temporary (administrator only)

A user may request temporary administrator access for a specific reason (temporary bureaucrat or checkuser access is not permitted). This should proceed through the same vote described under Consensus above. If and only if it is urgent, a local bureaucrat may provide administrator access immediately on their judgment. The user may then proceed to what they were given access to do and only that.

Stewards

Stewards may freely grant themselves temporary restricted access. However, they should go through the consensus process if it is on a permanent basis.

Usage

Administrator access

Blocking policy.
Deletion policy.
Protection policy.
The rollback feature automatically reverts the latest changes from a user to a particular page with the standardised edit summary "$2 (चर्चा) यांनी केलेले बदल $1 यांच्या आवृत्तीकडे पूर्वपदास नेले.". This tool exists primarily to simplify the reversion of malicious edits. Although it can theoretically be used to revert any change, it may be aggravating to the affected user if it is used to rollback a legitimate change which the administrator disagrees with. Administrators should avoid rolling back legitimate edits if at all possible, and the rollback feature should never be used in a reversion war.

Checkuser access

Checkuser access must be used in comformity to the Foundation checkuser policy; deliberate or repeated violation of that policy may be grounds for immediate removal of access. A check may only be performed if there is evidence of abuse, or following a request by the user being checked. Stewards may use checkuser access on this wiki in the event of crosswiki abuse.

Checks must either:

be publicly requested (or noted) on the Administrators' noticeboard, or
be performed privately to ensure privacy, with a note and justification sent to the checkuser-l list for sanity-checking (this should only be done where the public message would link a legitimate contributor to their IP address or other non-public personal information).

Any block due to checkuser information must provide an accurate justification as much as possible without violating privacy (if no meaningful justification can be made public, justification should be sent to the checkuser-l list). Users in good standing should be informed of any public checkuser request with a note on their talk page.

Oversight access

Oversight usage is codified by the Oversight policy.

Loss

Active users will typically maintain restricted access without any further hurdle. However, there are a few cases where a user may lose access. In all cases below, only established users may vote. However, anyone is free to discuss.

Votes of confidence

Restricted access depends on the continued support of the community. This may be tested by a vote of confidence, in which a simple majority (50%+1) must support the user's continued access for it to be retained. (What access a discussion concerns should be explicitly noted in the discussion's introduction.) Any user may propose a vote of confidence, but at least three established users must support the need for one before it can be called. Such a proposal is made automatically one year after the last scheduled or called proposal (concerning all restricted access). The full schedule of proposal votes is available on the administrators page.

In the case of an unscheduled (called) proposal, the user may not use the restricted access for any non-trivial action at any time until the vote is closed. A bureaucrat will eventually archive the discussion and, if so decided, request removal of restricted access by a steward.

Inactivity

It is a common occurrence on wikis to create an account, be active for a certain period of time, then become inactive. While this is to be expected due to the nature of this site, accounts with restricted access should not be left unattended for a long period of time. Users who return after an extended break may no longer be in touch with community practices or policies, which is not desirable in an administrator. Inactive accounts are also more open to account hijacking, and this may be difficult to detect as compromised if the original user is not there to notice edits they didn't make. Furthermore, the list of users with restricted access should only contain those capable of responding to queries within a reasonable period of time.

An inactive user is one who has not edited during the past four months. Inactive users automatically lose their restricted access in their next scheduled confirmation vote unless at least half of the voting community supports continued access. Any user who has lost access due to inactivity may reapply through the regular processes.

Emergency

In extreme circumstances, a bureaucrat may immediately remove a user's restricted access through a steward. The steward may assume this to be temporary until community decision. This should only be done if the bureaucrat judges that the user is acting maliciously or is severely incapable of continued proper use. A vote for continued access by the user should be automatically begun to confirm or overturn the bureaucrat's decision.

The bureaucrat should not be penalised in any way for this action, unless they were demonstrably acting in bad faith.

Special cases

Request: Any user may request removal of their own access. Should they wish to regain access at a later time, they should go through the normal consensus process described under "Obtaining access" above.
Temporary adminship: A user granted temporary administrator access should have it removed when they complete the stated task. They may then request permanent access through the normal processes. However, they may not request permanent access while they still have temporary access.