Wikidata

Wikidata:Requests for comment/2018 administrator policy update

< Wikidata:Requests for comment


THIS RFC IS CLOSED. Please do NOT vote nor add comments.

This is an update of several policies related to the use of administrator tools, as well as areas of user conduct. Most of these policies remain unchanged since 2013 and the first days of Wikidata. There have been several incidents of confusion over the last several months where greater clarity would have been helpful. A separate RFC on civility and personal attacks will follow at a later date. (Proposed: 23 September 2018‎)

Wikidata:Administrators

edit

Accountability

edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Clear consensus to accept--Ymblanter (talk) 21:06, 9 November 2018 (UTC)[reply]

Administrators are expected to reply promptly and civilly to concerns about their administrator actions. Repeated failure to do so may result in removal of the right, subject to the usual procedures.

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Involved administrators

edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Clear consensus to adopt. We have one objection against treating an action against an item as an action against the user, but the majority clearly thinks otherwise, and this is a yes/no question, so I do not see how a middle ground would be possible--Ymblanter (talk) 08:14, 24 December 2018 (UTC)[reply]

Administrators should avoid using their tools to perform actions where there are credible concerns about their impartiality. Those situations include using the tools in disputes in which they are involved parties. If the administrator is in doubt, the administrator is encouraged to ask for opinions, or to ask another administrator to review the case at Wikidata:Administrators' noticeboard.

Exception

edit

An administrator who has interacted with an editor or topic area purely in an administrative role, or whose prior involvements are minor or obvious edits which do not show bias, is not involved and is not prevented from acting in an administrative capacity in relation to that editor or topic area.

Users with an item

edit

For the purposes of this policy, actions related to the item representing a Wikidata user are considered actions relating to that Wikidata user.

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Wikidata:Blocking policy

edit

Users and bots

edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
No consensus for this change: there are too many opposes, and their argument have not been rebutted.--Ymblanter (talk) 16:17, 24 December 2018 (UTC)[reply]

Unless otherwise specified, any block placed on a user account should be extended to all accounts that a user operates, including authorized bot accounts.

  •   Support This is already inferred by Wikidata:Alternate accounts. However, some users apparently need this spelled out. Without this provision, blocks against users running bots for issues like civility are useless. --Rschen7754 23:28, 23 September 2018 (UTC)[reply]
  •   Support This avoids evasions. Esteban16 (talk) 01:13, 24 September 2018 (UTC)[reply]
  •   Support Jc86035 (talk) 02:36, 24 September 2018 (UTC)[reply]
  •   Support--Liuxinyu970226 (talk) 05:07, 24 September 2018 (UTC)[reply]
  •   Support Agreed. However, I am not sure how to know these alternate accounts at the time of a block. Pamputt (talk) 05:24, 24 September 2018 (UTC)[reply]
  •   Support though it would greatly help to clarify how the situation of the second community global ban should be handled here in the context of this proposed policy. Mahir256 (talk) 05:38, 24 September 2018 (UTC)[reply]
  •   Conditional support Basically, I agree with this policy. But I think we also need an exception below. --Okkn (talk) 10:09, 24 September 2018 (UTC)[reply]
  •   Conditional support Per Okkn Bovlb (talk) 22:01, 25 September 2018 (UTC)[reply]
  •   Comment I'm a little confused by this - shouldn't every user just have one account, unless they also happen to have a bot account (which is relatively rare - a few percent of active editors)? If a user is found to have multiple (unauthorized) accounts otherwise they should be handled under a socking policy I would have thought. And regarding users with a regular + a bot account, I think blocks should be handled differently for the two different cases. That is, I'd like a malfunctioning bot to be blocked immediately by admins, but I don't think that requires the associated user account to be blocked. Conversely, as Okkn suggests below, I don't think a user account that is blocked for one reason necessarily implies a bot account doing unrelated things should be blocked. So on its face I don't really understand this policy and I think I would oppose it as it stands. ArthurPSmith (talk) 12:42, 24 September 2018 (UTC)[reply]
  •   Oppose, as long as authorized bot account blocks are involved here regardless of the blocking reason. Bots are essential infrastructure for this project and important in many regards to keep it running, so this proposal would create a lot of damage to the project. I would support bot account block only if the main account was blocked infinitely, or the bot account was abused to evade a temporary main account block, or if the bot is malfunctioning and the bot operator cannot address the concern due to their temporary block. I also note that there are a couple of bots operated by more than one operator, which makes it difficult to decide how to deal with them if this proposed policy became an actual policy. —MisterSynergy (talk) 13:28, 24 September 2018 (UTC)[reply]
  •   Oppose Per MisterSynergy. --Sannita - not just another it.wiki sysop 12:05, 25 September 2018 (UTC)[reply]
  •   Oppose User:SuccuBot was blocked on vague grounds that way. --Succu (talk) 18:56, 25 September 2018 (UTC)[reply]
  •   Oppose, I hate to be "that guy" but I'll have to bring up the local block of User:Daphne Lantier which was related to his vandalistic mass-deletion of "highly visible" pages on Wikimedia Commons and that "leaked" here through the fact that Wikidata edits are automatic, a user can edit Wikidata without their knowing, blocks should be to stop continued disruption, as much as I dislike the aforementioned user personally I have to give kudos to the handling administrators who didn't punitively block the User:INeverCry account here over edits that weren't in their own control. -- 徵國單  (討論 🀄) (方孔錢 💴) 19:01, 25 September 2018 (UTC)[reply]
  •   Oppose - Mostly per ArthurPSmith. This sounds too strict, especially in view of the arbitrariness of some blocks that have been made over the past year. Some bots do non-controversial routine work. If a bot is used to circumvent a block, then it can be blocked. - Brya (talk) 05:15, 2 October 2018 (UTC)[reply]
  •   Oppose - Too general, too automatic, especially for bot accounts. We shouldn't automaticly block the main account of a user for the technical problems that may cause a bot to malfunction so that it has to be blocked. We shouldn't block a well functioning bot either for an unrelated incorrect behaviour by the user at their main account. An account may be hacked or unintendedly but also unautherizedly used by a third person - that does not mean that secondary accounts like bot accounts have to be blocked. Lymantria (talk) 15:39, 3 October 2018 (UTC)[reply]
  •   Weak oppose - This is to wide-sweeping. I would rather not write this into policy as a command ("should extend"). Deryck Chan (talk) 10:26, 1 November 2018 (UTC)[reply]
  •   Oppose I think it's enough to leave that decision in the hands of the admin who makes the decision to ban. For some bots it would be inconvenient to stop them for shorter amounts of time. ChristianKl ❪✉❫ 12:56, 10 December 2018 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Users and bots (alternate)

edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
No consensus for this change either and unfortunately given too little attention--Ymblanter (talk) 16:18, 24 December 2018 (UTC)[reply]

Any block placed on a user account may be extended to all accounts that a user operates, including authorized bot accounts, at the blocking administrator's discretion.

  • Second choice   Support. Proposing as a potential compromise to some of the issues raised. --Rschen7754 18:56, 14 October 2018 (UTC)[reply]
  • First choice   Support to give both guidance and discretion to admins. Deryck Chan (talk) 10:23, 1 November 2018 (UTC)[reply]
  •   Oppose It will be very difficult and will require much wasteful effort to reverse the other admin's vague discretion, if the decision is controversial. Block to an authorized bot should be conducted after there comes a particular reason including the violation of our bot policy. --Okkn (talk) 11:16, 1 November 2018 (UTC)[reply]
    • @Okkn: The proposal below about discussions of controversial blocks should take care of this concern. Deryck Chan (talk) 13:27, 2 November 2018 (UTC)[reply]
      • Rules for blocking should be stipulated as much as possible. If a main account has been vandalizing Wikidata intentionally, I can agree to block all accounts including authorized bots, because the bot account may have also destroyed the contents too. However, if a user violates "alternate account policy" or "edit warring policy" by mistake, there is no merit in punitively blocking bots. I feel almost all cases of blocking an authorized bot for the reason that main account is blocked are controversial, and each blocking should be conducted after obtaining community consensus. In general, unblocking by discussion is much harder than blocking by one admin's discretion, and If the discussion is protracted, participated admins will become exhausted. --Okkn (talk) 23:21, 2 November 2018 (UTC)[reply]
  •   Support  – The preceding unsigned comment was added by ChristianKl (talk • contribs).
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Exceptions for bots

edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
consensus to accept --Pasleim (talk) 13:04, 28 February 2019 (UTC)[reply]

The block should not be extended to the authorized bot account if and only if the blocked account meets all of the criteria below:

  1. The main user account is not indefinitely blocked.
  2. The bot account is only conducting authorized tasks.
  3. The reasons for the block are not related to the bot tasks.
  •   Support Without this exception, we would hesitate to block a user operating an important bot. @MisterSynergy: You may be interested in this. --Okkn (talk) 10:09, 24 September 2018 (UTC)[reply]
  •   Support well, better than nothing, but I’d rather see bot accounts explicitly being exempted from the alternate account rule (in the context of user blocks). —MisterSynergy (talk) 13:28, 24 September 2018 (UTC)[reply]
  •   Support --Sannita - not just another it.wiki sysop 12:06, 25 September 2018 (UTC)[reply]
  •   Oppose What about sockpuppetry or something that affects the level of trust? "are not related to the bot tasks" is too subjective, besides my overall disagreement with this concept. --Rschen7754 18:16, 25 September 2018 (UTC)[reply]
    • Also, there are some bot accounts that are solely used for edits like QuickStatements. Are we really saying that if they make the edits off their main account it's not okay, but if they do it with their bot account it's okay? And that these bots are "so important" that we really cannot do without their services (which are basically semi-automated edits?) --Rschen7754 00:22, 26 September 2018 (UTC)[reply]
      • Of course, when the behavior of the bot itself is doubtful, we can block the bot even if this exception exists, because it does not meet point 2 or 3. This exception allow us to decide not to block a bot. Conversely, without this exception, we cannot decide not to block the bot at our admins' discretion.
        Obviously, we should not block QuickStatementsBot on the grounds that one of the user (not a bot operator) of it is blocked. --Okkn (talk) 04:27, 26 September 2018 (UTC)[reply]
        • I might support making the block optional, but this proposal goes too far and prevents an administrator from doing so. --Rschen7754 06:04, 26 September 2018 (UTC)[reply]
          • I think this exception just make the block of bot optional. Could you please explain with concrete descriptions in what case this proposed exception is going to be a problem? --Okkn (talk) 06:42, 26 September 2018 (UTC)[reply]
            • Sockpuppetry, where the decision is not to block the master indefinitely but for a limited period of time (because it's a first offense). --Rschen7754 18:13, 27 September 2018 (UTC)[reply]
              • In that case, point 2 is not fulfilled. Also we should block an authorized bot only after it is actually used for an inappropriate purpose. Blocking an authorized bot in advance is an excess response, because the bot has already been associated with its operator, and the authorized bots are limited in number. --Okkn (talk) 06:09, 28 September 2018 (UTC)[reply]
    • (outdent) This would not fall under an exception. If we block someone for abusing multiple accounts (for example, they used an undisclosed sock to vote twice in a RFA) and they are blocked only 1 week, under this proposal we could not block the bot account. --Rschen7754 00:41, 29 September 2018 (UTC)[reply]
      • There is no merit to block the authorized bot account at the time of the main account is blocked, if the bot has not been used inappropriately and the operator is not indefinitely blocked. --Okkn (talk) 01:41, 29 September 2018 (UTC)[reply]
        • Absolutely no merit? Besides the dishonesty? Because if faced with this situation again, I would either press for an immediate revocation of the bot flag by a bureaucrat, or indefinitely block, if this proposal passes. --Rschen7754 02:18, 29 September 2018 (UTC)[reply]
          • What is your purpose of the block of the bot account? As a punishment for the dishonesty? We should not choice an indefinite block in order to avoid this exception. Don't confound the means with the end. Without resorting to such forcible means, we can block the bot from the moment the bot does something wrong, or after the approval of a bot task or a bot flag has been rescinded. --Okkn (talk) 05:05, 29 September 2018 (UTC)[reply]
  •   Support User:SuccuBot was blocked on vague grounds that way. --Succu (talk) 18:56, 25 September 2018 (UTC)[reply]
  •   Support points 2 and 3, point 1 makes no sense if the bot makes uncontroversial maintenance edits and is not used for actual evasion. -- 徵國單  (討論 🀄) (方孔錢 💴) 18:57, 25 September 2018 (UTC)[reply]
  •   Support Per Okkn, but we should also have another exception that a block of a bot may be "technical" and does not necessarily apply to the user. Bovlb (talk) 22:01, 25 September 2018 (UTC)[reply]
  •   Support Per MisterSynergy. Not sure if this is right, but better than nothing. - Brya (talk) 05:15, 2 October 2018 (UTC)[reply]
  •   Comment I see issues here. There may be blocks of the main account like block longer than 6 months that would be reasonably accompanied by a block of the bot. So the first point IMHO is too weak. Second, I think that especially issues of a flood account leading to a block, should be stretched to the bot account as well. This is one of the point the third point is not clear enough about. Edits may not be related to the bot, but flood and bot behaviour may be related. Lymantria (talk) 15:39, 3 October 2018 (UTC)[reply]
  •   Oppose 1. Per Rschen, 2. For areas which have to visit this site via VPN or Shadowsocks is this really fair for them? This can also make private info leaks during your sessions. --Liuxinyu970226 (talk) 11:35, 12 October 2018 (UTC)[reply]
  •   Weak support This is a useful exception to have, if we ratify any proposal of blocking all accounts owned by the same person by default. However, the alternate proposal of giving the blocking admin discretion should suffice on its own. Deryck Chan (talk) 10:28, 1 November 2018 (UTC)[reply]
  •   Oppose We would not typically block a user indefinitely for socking, but a temporary block for sockpuppetry should still disqualify the user from being able to operate a bot (at the admin's discretion, depending on the severity of the socking).--Jasper Deng (talk) 09:51, 22 February 2019 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Unblocking policy

edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
consensus to accept --Pasleim (talk) 13:05, 28 February 2019 (UTC)[reply]

For comparison, this is the text of the current policy: "If any block or unblock is controversial, the status-quo should be restored and discussion should commence via administrators' noticeboard on which course of action to take."

If any block or unblock is controversial, a short discussion should commence via the administrators' noticeboard on which course of action to take. Administrators should be mindful of both any past consensus that has been established in regards to blocking the user, as well as any relevant policies related to the block.

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Advice on blocking IP addresses

edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
stale --Pasleim (talk) 13:06, 28 February 2019 (UTC)[reply]

IP address blocks can affect many users, and IP addresses can change. When administrators intend to block an IP address, or to turn on autoblocking of IP addresses when blocking a user, they should at a minimum check for usage of that address and consider duration carefully. IP addresses should rarely, if ever, be blocked indefinitely.

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Wikidata:Edit warring (new policy)

edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
consensus to accept all paragraphs --Pasleim (talk) 13:12, 28 February 2019 (UTC)[reply]

Basics

edit

Edit warring is the repeated reverting of the same edits by multiple users. Continued edit warring can be addressed by protecting the page. Persistent edit warring or edit warring over multiple pages can be addressed by blocks. Administrators should not favor one side over the other, but can factor in the severity of the edit warring and previous blocks for similar behavior.

Vandalism

edit

Reverting vandalism is not edit warring.

Socks

edit

Reverting edits by a locally blocked or globally locked/banned editor is not edit warring, but is also not mandatory.

Living people

edit

Reverting clear-cut violations of Wikidata:Living people is not edit warring.

Userspace

edit

Users reverting in their own userspace is not edit warring.

edit

Removing copyright violations or other illegal (in the U.S. where the servers are hosted) content is not edit warring.

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Wikidata:Page protection policy

edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
consensus to accept proposal 2 Pasleim (talk) 13:14, 28 February 2019 (UTC)[reply]

Edit warring: Proposal 1

edit

Pages may be protected at administrator discretion in the event of edit warring. Administrators must not use their privileges to continue the edit war; doing so may lead to blocks, or in repeated instances, a discussion about their continued administrator privileges.

Edit warring: Proposal 2

edit

Pages may be protected at administrator discretion in the event of edit warring. Administrators must not use their privileges to make any edits to the page (unless the administrator's changes are clearly uncontroversial or supported by consensus); doing so may lead to blocks, or in repeated instances, a discussion about their continued administrator privileges.

Lymantria: Yes, that wouldn't mean abuse of rights as autoconfirmed users could edit the item, but this proposal is for full protection (being the administratros the only ones capable of editing the item). Esteban16 (talk) 22:53, 7 October 2018 (UTC)[reply]
Yes, that is how I read it as well, but I felt unsure.   Support Lymantria (talk) 05:25, 8 October 2018 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Wikidata:Interface administrators

edit

Ratification as a policy

edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
consensus to accept --Pasleim (talk) 13:18, 28 February 2019 (UTC)[reply]

This page is ratified as a policy. (Any further proposals stand on their own unless otherwise specified.)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Accountability

edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
consensus to accept --Pasleim (talk) 13:18, 28 February 2019 (UTC)[reply]

Interface administrators are expected to reply promptly and civilly to concerns about their interface administrator actions. Repeated failure to do so may result in removal of the right, subject to the usual procedures.

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_comment/2018_administrator_policy_update&oldid=870120173"