User talk:Atsme/Block log proposals

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Copyediting Proposal #1[edit]

  1. Blocks for sockpuppetry, vandalism and other major offenses that resulted in a site ban by the community or ArbCom will remain permanently on the block log.
  2. Administrators are required to first discuss a questionable action by a good-faith (GF) editor prior to implementing a block, and will first attempt to reach a mutual agreement without blocking. If discussion fails to resolve the issue, the admin will issue a formal warning, and if the warning fails, a block shall be implemented.
    • Wikilinks: Administrators are required to first discuss a questionable action by a good-faith (GF) editor prior to implementing a block, and will first attempt to reach a mutual agreement without blocking. If discussion fails to resolve the issue, the admin will issue a formal warning, and if the warning fails, a block shall be implemented.
    • Problems: Admins have no way of knowing if the edit is good-faith or just looks that way; what they actually operate on is the WP:DUCK/WP:SPADE principle of whether something clearly seems to be bad faith. WingsOfGodric, in !voting early on the draft, also highlighted this problem in the wording. It's actually worse, in that it's perfectly legit to block someone for disruption even if they are acting in good faith. It's also improper to say that a block shall be implemented, since there may be other remedies (such as a topic ban, if DS are in effect, or just hauling someone off to ANI, AE, or RfArb for a public reaming). Also, it's not possible to require an actual discussion first, since the user can refuse to respond. Some of the wording is also redundant.
    • Suggested revision:
      Administrators are required to first attempt to discuss a questionable action by an editor prior to implementing a block, unless the disruption or policy violation is severe and urgent enough to require an immediate block, or there is clear evidence of bad faith. Otherwise, if discussion fails to resolve the issue, the admin will issue a formal warning, and if the warning fails, a block may be implemented.
      ✅ -- My use of "GF" was to exclude vandals and trolls.
  3. Administrators shall show a high degree of sensitivity per WP:BLP policy when logging their reason for blocking a user. (Perhaps pre-scripted reasons should be introduced?)
    • Link: Administrators shall show a high degree of sensitivity per WP:Biography of living persons (BLP) policy when logging their reason for blocking a user. (Perhaps pre-scripted reasons should be introduced?)
    • Problems: I have no idea what any of that means. It's definitely not policy wording, since there's probably a dozen conflicting ways to interpret that. Please explain in a paragraph or so, and I can try to do the WP:Policy writing is hard heavy lifting.
      ✅ Use your discretion to keep, reword or remove. Re: clarity: editors should be treated the same as any WP:BLP per policy (my bold): Editors must take particular care when adding information about living persons to any Wikipedia page. Such material requires a high degree of sensitivity,... Some of the reasons I've read in several block logs seemed a bit harsh, such as "cannot edit own talk page" which could be reworded as "TP access restricted". Another is "personal attacks" which could be reworded as "questionable conduct" or "conduct issues" or "unbecoming behavior", etc.
  4. Administrators may redact their own block log errors from a user's log as soon as they recognize they made an error.
    • Links:
      Administrators may redact their own block log errors from a user's log as soon as they recognize they made an error.
    • Seems fine otherwise.
      ✅ - good.
  5. A challenged block that consensus determines was wrongful will be quickly redacted from the block log.
    • Problems: ArbCom isn't a consensus (it's a vote) but can also make this determination.
    • Suggested revision:
      A challenged block that consensus (e.g. at WP:Administrator's noticeboard) or that ArbCom determines was wrongful will be quickly redacted from the block log.
      ✅ - works for me.
  6. Aministrators may not override another administrator's decision to not block a user without first obtaining consensus; however, they may override a block if the purpose is to redact an error confirmed by consensus or to reduce it to more closely fit the offense.
    • General copyediting, clearly account for more circumstances, and use WP admin lingo like "proportionate":
      Administrators may not override another administrator's decision to not block a user without first obtaining consensus at an appropriate venue, including WP:Administrator's noticeboard, WP:Arbitration enforcement, or another site-wide noticeboard, unless the editor's transgressions have escalated. However, an admin may override a block if the purpose is to redact an error confirmed, as described above, or to reduce a block to a sanction more proportionate to the offense.
      ✅ - works.
  7. Up to 3 short blocks will be redacted from the log after one year has expired since the last block unless the blocks were made in error.
    • Problems. I have no idea what that means, yet it appears to be crucial. I can think of multiple sharply conflicting interpretations of each half. Please explain in a paragraph.
      ✅ Year is 2018 - editor is guilty of edit warring, gets two 3RR blocks (one 24 hrs in June, the other 36 hrs in July), then in December, they violate DS earning a 48 hr block at AE. Count starts as of last block - December 2018 to December 2019. If after a year has passed with no other block occurrences, the log is redacted. Blocks made in error are not counted toward the maximum 3 block annual limit because they should be redacted per #4 & #5. However, if 4 regular blocks occur in the same year, the log stays unless/until the editor qualifies as a tenured editor at which time #8 comes into play.  
  8. Blocks will be redacted from the block logs of GF editors who meet the following minimum requirements: 3 years tenure, 10,000 article edits, and no block activity for 2 years after the last recorded block.
    • Copyedit (all editors are GF editors, or they get sitebanned; don't contradict the first point):
      Blocks – other than those enumerated in no. 1 above – will be redacted from the block logs of editors who meet the following minimum requirements: 3 years tenure, 10,000 article edits, and no block activity for 2 years after the last recorded block.
      ✅ - works.
  9. Topic bans Blocks should not be imposed or included in a decision to block if a GF editor mistakenly violates an ambiguous admin-imposed restriction while editing controversial articles or if that editor adamently believes their actions were compliant with BLP policy.
    • Problems: Again, this cannot be in terms of whether the editor is "good faith"; that's a judgement of personal character/nature. We can only judge their actions, and we assume good faith unless given strong evidence to the contrary. Much of this is redundant, and it doesn't really work anyway. Admins are not empowered to issue topic bans unless a) ANI or a similar venue comes to a consensus to impose one, or b) discretionary sanctions are in play. Worse, we have no way at all to know what an editor adamantly believes. And there's nothing magically special about BLP among the 7 exemptions.
      ✅ I think it's unfair to block an editor who believed their edits were compliant with WP:BLP, a policy which requires that contentious material in a BLP that is unsourced or poorly sourced (my bold) whether it is negative, positive, neutral, or just questionable - should be removed immediately and without waiting for discussion. I believe it is wrong to block an editor who removed such material, regardless of how many times. The editors who restore the material are the ones who should be called to task - the onus is on them to substantiate BLP compliance - not the editor who removed it. POV warriors are good at gaming the system via tag-teams and pile-ons, and are not above pulling the wool over the eyes of admins (who are already overworked & under time constraints) in order to make their opposition appear to be disruptive and on the wrong side of "local consensus". I would support a remedy that allowed the admin to remove the challenged material, and warn the editors who previously restored the material. An RfC should then be called to resolve the dispute, and if any of the involved editors act against consensus, they may be blocked.
    • Remaing problems: TBANs have nothing to do with blocking policy, and are covered at a different policy. These should probably be separate proposals, because this is wandering into complicated territory.
    • Suggested revision, though this may not be enough to salvage it:
      A topic ban – where one is available, e.g. under WP:Discretionary sanctions – may not be included in a decision to block if A) the restriction an editor is said to have violated is one imposed by an individual admin rather than by ArbCom or a noticeboard consensus; or B) the editor's actions qualify under Wikipedia:Edit warring#Exemptions.
      ✅ - Use your discretion. Delete it if you think it handicaps the primary objective.
  10. An administrator shall not interfere in or threaten to block a GF editor simply for expressing an opposing view in a civil manner during a content debate on the TP of a controversial article and shall not use such a discussion as part of the reason to impose a topic ban.block.
    • Copyediting: "Shall" isn't a word we use (except by accident of copyediting failure). Same "GF" problem. You can't "interfere in someone". And this is very overbroad. Suggested revision
      An administrator may not interfere with the legitimate editing activity of, or threaten to block or otherwise sanction, an editor simply for expressing a topic-relevant opinion, within the bounds of WP:Civility, WP:Wikipedia is not a forum, and related policies, even at the talk page of a controversial article, and may not use such a opinion as part of the reason to impose a topic ban. block.
    • Remaining problems: Same comment as above, about TBANs being off-topic for a blocking policy revision proposal.
      ✅ - Suggestion - I changed it to block instead of topic ban. I will leave it to your discretion whether or not to keep, or delete if you think it handicaps the primary objective.

This is the best I can do in one go, without further input, especially about the two segments I flagged in boldface.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  15:22, 9 January 2018 (UTC)[reply]

Love what you did, SMCCandlish! Thank you! My responses will use the ✅ for approval followed by highlighted text to clarify. Feel free to make the changes directly to Proposal 1. I did not author Proposal 2 - it was proposed by Wbm1058, now pinged for input. Atsme📞📧 22:24, 9 January 2018 (UTC)[reply]
Glad it's helpful. I've about run out of steam for today. I think I understand points 3 and 7 now, and can see about "policyizing" them, though I think neither stand much chance of acceptance. On point 9, I understand what you mean, but there's no way it would get accepted when it's about what the user believes, because there is know way to know what the user believes, and what they believe might be insane. What can be agreed upon is whether what they actually did qualified under the BLP rule (or one of the other Exceptions); that's how administration actually works (you can even be entirely correct as to sources and policy, and clearly acting in good faith, yet still get blocked if you're being a disruptive asshat about it, and that's never going to change, because it's more valuable to protect the community from disruption than to have a few correct edits made at the cost of a controversy firestorm. Learned that the hard way, e.g. my 3-month move ban several years ago).  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  23:16, 9 January 2018 (UTC)[reply]

Copyediting Proposal #2[edit]

Any administrator, upon determining that they blocked a user in error, and reversed that block within 24 hours, may, at their discretion, RevisionDelete both the block and its removal from the block logs. Such revision deletions may be reviewed by other administrators who, at their discretion may restore visibility if they feel that the block was justifiable. Once restored once, a block should not be RevisionDeleted a second time. There is no time limit on the redaction; all blocks lifted within 24 hours are eligible for redaction at any time.

"Any administrator, upon ... reversed" isn't grammatical. "Once restored once" is hard to parse. Parenthetical commas come in pairs. That's all easy to fix, but I don't understand why this would be limited to 24 hours.

Any administrator, upon determining that they blocked a user in error, and having reversed that block within 24 hours, may, at their discretion, RevisionDelete both the block and its removal from the block logs. Such revision deletions may be reviewed by other administrators who, at their discretion, may restore visibility if they feel that the block was justifiable. After being restored once, a block should not be RevisionDeleted a second time. There is no time limit on the redaction; all blocks lifted within 24 hours are eligible for redaction at any time.

Also, mere mortals are not going to understand how "redaction" is different from RevDel. That will have be made clear somewhere, even if it's just intro material to the proposals.

To followup on the comments on the first proposal: I think there should be three, with the two points about T-bans (which are WP:Banning policy) separated out from the rest of proposal #1, which is otherwise all about WP:Blocking policy.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  16:08, 9 January 2018 (UTC)[reply]

SMcCandlish see my comment above - I pinged the author of Proposal 2. Atsme📞📧 22:25, 9 January 2018 (UTC)[reply]
Well, this has morphed into something much more complex than what it started out as. This sort of feedback isn't very timely at this point. For the purposes of this, "redaction" and "RevDel" are synonymous. An administrator redacts a block by revision-deleting it. As at this point my feeling is that my simple proposal has less than a 50–50 chance of success, I'm not interested in pursuing it further at this time. The fact that those who should be supporting it either seem indifferent or don't understand it doesn't help. wbm1058 (talk) 22:33, 9 January 2018 (UTC)[reply]
It doesn't help either that the point of the time limit isn't obvious. The point being, if it takes two d**n days to figure out that a block was an obvious mistake, well then maybe it wasn't really a mistake. Then it's controversial, and redacting controversial blocks is controversial. wbm1058 (talk) 22:46, 9 January 2018 (UTC)[reply]
Except see User talk:Tony1. It took way more than two days to get various admins to conclude the block was wrong, and for the blocker to admit that it was. PS: The copyedits I suggest to your proposal have no effect on the substance of it, they just make it easier to understand and thus less likely to be opposed.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  22:56, 9 January 2018 (UTC)[reply]

You determine how long it took the administrator to recognize they made a mistake by how long it took them to reverse their block. The block was reversed in 29 minutes; this is less than 24 hours. There is no time limit for redacting it. wbm1058 (talk) 23:15, 9 January 2018 (UTC)[reply]

  • 03:26, 28 December 2017 Oshwah unblocked Tony1 (talk | contribs) (User clarified their statement, and was not a legal threat. Unblocking.)
  • 02:57, 28 December 2017 Oshwah blocked Tony1 (talk | contribs) with an expiration time of indefinite (account creation blocked) (Making legal threats)
You're right; the actual unblock happened quickly; I got confused by the amount of "admin did no wrong" wikilawyering by that party (and several admin buddies) on Tony's talk page.  — SMcCandlish ☏ ¢ 😼  01:39, 26 June 2018 (UTC)[reply]

Oiyarbepsy's Proposal #3[edit]

Somewhere, I forget where, Atsme mentioned the difficulty in finding the reason the user was block in the first place (aside from the very short block log description). I'm gonna propose that entries to the block log must link to the relevant discussion, if it exits, such as WP:ANI, talk page discussions, etc. This allows an editor viewing the block log to quickly see what it's about and fairly judge the merits - without this link, doing so is often flat-out impossible. Of course, ideally we would fix our broken page archiving session so that the links don't break as soon as a bot archives it. One workaround is to create a redirect, link the redirect in the block log, and fix the redirect once archives, but this is a pain in the butt. Oiyarbepsy (talk) 06:09, 5 February 2018 (UTC)[reply]

You'll need to specify an exception for oversight blocks. --Tryptofish (talk) 19:39, 5 February 2018 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:Atsme/Block_log_proposals&oldid=847534531"