Requests for comment/The block log lacks useful information - basic requirements for sysop/admin accountability
The following request for comments is closed. overwhelming opposition and repeated abuses of procedure and community standards by OP make this proposal as currently framed unlikely to pass. Dronebogus (talk) 22:03, 15 June 2024 (UTC)[reply]
Proposal:
When a sysop or admin blocks someone, they should cite both (a) specific policy and (b) substantive diff(s) or permalink(s), either on the recipient's talk page or (ideally) in the block log entry. It takes only a moment to include this information. Without it, an observer or uninvolved party cannot straightforwardly assess the fairness of a block or whether a block complies with policy. Likewise, the recipient of a block cannot make a convincing argument in their own defense, as the blocking admin/sysop hasn't made a concrete, falsifiable statement in the first place (apart from some variation on "you are blocked", usually followed by a glib comment). Its absence also precludes (or at least complicates) the public investigation of potential biases or other patterns in the aggregate, since one cannot easily associate each block with the contribution(s) it resulted from. Wikimedia projects promote the impression that they are open public participation. The UCoC uses ideographs like <inclusive>, <diverse> and <accessible>. The enforcement guidelines emphasize <transparency> and fairness. This seems quite at odds with how blocks are presently handled. What I am proposing here would make it plainly obvious whether or not a block was issued fairly.
Many RfCs tend to recive binary support/oppose replies. I shall interpret such answers as approval or disapproval of the above proposal, which could be implemented either in the UCoC or by individual projects. However I hope for more discussion than voting. Also understand that I intend this only as a policy proposal and a critique of current policy, not as a critique of any particular admin or sysop.
Some extra remarks:
Taking the extra moment to copy a few links would hardly be a nuisance in most cases, but for the sake of argument let's say a project is so short-handed that they cannot apply this rule for every user. From a cursory look at the wikipedia block log (as an example), it seems that roughly half of all blocks are issued to ip users. IPs do not seem to receive long blocks in the first place and so limiting this policy just to those blocks issued to registered users would be natural. Still too much work? Apply it only for confirmed/autoconfirmed, or in the worst case extendedconfirmed users, who naturally represent a minuscule fraction of the block log (and probably deserve at least that much courtesy for the effort they've put in).
Sometimes instead of (b) the blocking sysop/admin gives a nonspecific description of where the alleged violation occurred, even though it would take only an extra few seconds to paste a link. Additionally, sysops/admins often cite essays instead of official policy. These ad hoc conventions have no practical advantage but seem quite favorable to abuse. If a user has not plausibly broken any official rule or policy then they should not be blocked. If official policy is inadequate then it should be changed. It is deceptive to call one set of rules "official policy" while enforcing another set of rules categorized and labeled as "essays": "Essays are the opinion or advice of an editor or group of editors for which widespread consensus has not been established. They do not speak for the entire community and may be created and written without approval."[1].
Why would any project state that it "has no firm rules" yet actually have pages upon pages of rules? Rules can be broad and rules can be adjusted or changed, but when rules are 'soft', vague or needlessly overwrought, it is often a sign that they were written by people who do not intend to respect those rules themselves. The entirety of UCoC section two (along with a number of 'essays' and a sizable chunk of official wikipedia policy) could just as well be replaced with the sentence "observe common decency and show respect to other users". The exposition in w:WP:NOTBURO and w:WP:5P5 does not constitute a serious argument against having a fair, concise and consistently enforced set of rules, the value of which is self-evident. Consider this specious portion of w:WP:NOTBURO, "Although some rules may be enforced, the written rules themselves do not set accepted practice. Rather, they document already-existing community consensus regarding what should be accepted and what should be rejected." It seems to excuse any convenient departure from official policy on part of sysops/admins (e.g. an abusive block), suggesting that such an event should be interpreted as failure of the community to document accepted practice rather than a failure on part of specific members to observe the rules as they're presently written. This wouldn't per se be unfair if the official rules were actually changed to reflect how admins, sysops, and other "whitelisted users" behave. For example, if some essay represents de facto policy and is enforced as if it were official policy then let it be called official policy. "Whitelisted users" is a phrase I found in wiktionary's blocking policy [2]: "It is rare, but occasionally there will be a seasoned contributor, even an administrator, who is causing trouble; such cases must be handled with diplomacy. It is not acceptable to block a whitelisted user or an administrator unless they already know they will be blocked for their actions." A bit on-the-nose, no? How is any other user (aside from those on the "whitelist") supposed to know they'll be blocked for something that doesn't violate a reasonable interpretation of official policy? How should they divine which of the many contradictory essays or unwritten rules "reflects practice"?
Incidental comments: Wikipedia's appeal policy [3] gives one the superficial impression that when users are blocked unfairly, the mistake will be rectified immediately, "If there is agreement that you may have been blocked unfairly, you may be directly unblocked ". The sysop/admin who issued the block obviously isn't going to agree, otherwise they wouldn't have issued the block. The rest of the sentence further qualifies this already-weak assurance, "but this is very rare unless there genuinely were no prospective grounds for the block. Usually the blocking admin's judgement is respected if there is any question of doubt". Why wouldn't it simply read "If you've been blocked unfairly, you'll be unblocked"? Is that not reasonable? Again one gets the sense that these rules are written without any intent to enforce them fairly and consistently. If I could make just one change though, it would be what I have proposed here. Between (a) and (b) the latter is more important, but really both should be included in the log to have the intended effect. Thank you for reading.
AP295 (talk) 23:01, 24 May 2024 (UTC)[reply]
Addendum:
1) Please observe Paul Graham's Hierarchy of Disagreement (pictured on the right).
2) As of 6/3/24, all users who oppose are admins but none of the supporting users are. Obviously admins should have their say, yet I'd like for this RfC to remain open for a reasonable length of time to take a larger sample of "community input". Admins should not close this RfC on grounds of w:WP:SNOW (or some such thing), which isn't policy in the first place, but also because it presents a COI in this case.
- Blocks should be against disruption, not for unfairly pressuring an editor over something they disagree with. w:WP:IAR doesn't guarantee that you would ignore a single rule.
- Sysop accountability should be a must, especially new sets of wikis are appearing. I might share this idea to other wiki farms because some local wikis tend to fail to enforce rules. Ahri.boy (talk) 23:45, 26 May 2024 (UTC)[reply]
- Agreed though I don't quite understand your point about IAR, which at any rate should just be deleted. AP295 (talk) 04:26, 27 May 2024 (UTC)[reply]
- Strong support If a person is wrongly blocked, then the lack of an audit trail means that they have no route for appeal, nor can they exercise the en:Innocent prisoner's dilemma. Having an audit trail (diffs of their actions that are linked to the block notice) as to why they were blocked will give them a route to appeal against false blocks and will also cause "trigger-happy" admins/sysiops to think twice before applying a block aftr somebody "throws mud in the hope that it will stick". Martinvl (talk) 13:47, 27 May 2024 (UTC)[reply]
- Precisely, but it's also for the sake of the observer. Think about a researcher or journalist trying to compute some statistical features using block log data. This would be relatively straightforward if the block log included the essential information. How would anyone know if some sysop(s) were abusing their privileges to bias an article or topic, when they can block editors to create a false appearance of "consensus" but aren't required to ID the contributions in question or the relevant policy? Obviously this would be inappropriate but as far as I can see there's no means in place of ensuring otherwise. That would be just one value of having a basic record, but instead blocks are needlessly obfuscated. It is not normal. AP295 (talk) 21:34, 28 May 2024 (UTC)[reply]
- Strong support the current system of sysop governance is, to use an increasingly cliched and diluted term, Kafkaesque. Admins basically are allowed to be judge, jury, and executioner in these situations; if we’re going to trust a very hit-or-miss basket of users that kind of power it should at least be regulated and accountable. It’s bad enough even on Enwiki; on smaller wikis there have been cases of sysops acting like dictators. Dronebogus (talk) 00:07, 29 May 2024 (UTC)[reply]
- By luck, I came across a comment by a long-gone user named R_physicist (who I really know nothing else about) that describes the status quo in similar terms. "[...] a parody of the well known practices used in police states, where denunciation is sufficient to imply guilt, and intimidation is a stock in trade to contain potential "enemies of the state"." That might sound dramatic, but when you consider Wikipedia's position, are the stakes really much lower? Wooden language commonly uses metaphor, and I have started making a serious effort to excise such patterns from my writing. But yes, it has the scent of despotism. AP295 (talk) 19:23, 29 May 2024 (UTC)[reply]
- Oppose I actually agree that the English Wikipedia community where I'm most active tends to block people more than it should, but I don't see the specific thing proposed here as a solution. Both AP295 and Martinvl are blocked on the English Wikipedia, and it's clear to me, even with the current system and years later, why they were blocked. This on the contrary seems to be an excuse to give blocked people a chance to rant and hassle admins further. Counter Dronebogus I don't think this would deter people like Til Eunspiegel - in cases like that it would become dead letter because they wouldn't care. * Pppery * it has begun 00:28, 30 May 2024 (UTC)[reply]
- This is an ad hominem, not a counterargument. Refute my informally-drafted "appeal" if you like, unless denunciation is sufficient to imply guilt. Even if you could - and I think you'll be hard-put - it wouldn't amount to more than an ad hominem in the context of this RfC (though you're welcome to do so on my talk page there). I've added a thumbnail with an illustration by Paul Graham for the sake of all concerned, which should probably be included with all RfCs. You imply it won't deter anyone from issuing abusive blocks, but that's just baseless speculation. What it would do is make any given project accountable to its own actions. If it doesn't deter an abusive admin, they'd have to take away the admin's privileges in order to maintain the project's reputation - exactly as it should be. You write that my suggestion "seems to be an excuse to give blocked people a chance to rant and hassle admins further", yet you are the first person to make any comment about other people. AP295 (talk) 01:43, 30 May 2024 (UTC)[reply]
- I don’t support AP295’s behavior on Enwiki, but a person’s unrelated actions do not make their ideas automatically bad. As for Martinvl I can’t even find a concise explanation of why he was blocked, so that’s another reason to implement this— ease of record-keeping for the sake of future readers. Dronebogus (talk) 03:49, 30 May 2024 (UTC)[reply]
- It should go without saying that supporting a proposal does not imply one endorses or disagrees with anything but that proposal. It's a tautology. I'd also like to point out that my "behavior on enwiki" was to question the objectivity of a special interest group who have, among other things, gone on to falsely accuse people of beheading babies. (I know, how could I have ever doubted?) Likewise, this was not a comment on anything other than the appropriateness of using that source, whose objectivity was questionable at best even then. I feel silly having to state the obvious so many times. Some of Wikipedia contributions are imperfect but not for the reasons the blocking admin insinuates. Rather, in my naivete, I had assumed I was speaking with reasonable, objective people - exactly as I was told to do. One must recognize leading arguments and loaded questions for what they are and point them out, and I shall take care to do so here. On the whole I think my contributions were a net positive. Let's stay on topic, anyway. AP295 (talk) 05:58, 30 May 2024 (UTC)[reply]
- We aren’t arguing over why you were blocked or whether you consider yourself a net positive. If anyone needs to stay on topic it’s you. Considering I’m an editor in good standing hearing out someone basically gaming the system (see below) because the idea itself is actually good, you shouldn’t strain my good faith with bludgeoning (yes, that dirty word) and tangential textwalls. Dronebogus (talk) 10:27, 30 May 2024 (UTC)[reply]
- It should go without saying that supporting a proposal does not imply one endorses or disagrees with anything but that proposal. It's a tautology. I'd also like to point out that my "behavior on enwiki" was to question the objectivity of a special interest group who have, among other things, gone on to falsely accuse people of beheading babies. (I know, how could I have ever doubted?) Likewise, this was not a comment on anything other than the appropriateness of using that source, whose objectivity was questionable at best even then. I feel silly having to state the obvious so many times. Some of Wikipedia contributions are imperfect but not for the reasons the blocking admin insinuates. Rather, in my naivete, I had assumed I was speaking with reasonable, objective people - exactly as I was told to do. One must recognize leading arguments and loaded questions for what they are and point them out, and I shall take care to do so here. On the whole I think my contributions were a net positive. Let's stay on topic, anyway. AP295 (talk) 05:58, 30 May 2024 (UTC)[reply]
- @Pppery: Will you please clarify exactly what I did to be blocked citing any relevant postings that I might have made. Martinvl (talk) 13:44, 1 June 2024 (UTC)[reply]
- Sure. You were originally topic banned from measurements per w:Wikipedia:Administrators'_noticeboard/IncidentArchive816#User:Martinvl_and_long_term_disruption_of_WT:MOSNUM (a discussion that includes plenty of links to diffs). That was later converted into a full blocked for refusing to w:WP:DROPTHESTICK and repeatedly relitigating that topic ban by starting discussions like w:Wikipedia:Administrators'_noticeboard/Archive255#Topic_Appeal_Ban_(2)_by_Martinvl only a few days after w:Wikipedia:Administrators'_noticeboard/Archive255#Topic_ban_appeal_by_Martinvl was closed against you. You then had your talk page and email access revoked per w:Wikipedia:Administrators'_noticeboard/IncidentArchive867#Martinvl for misusing both to engage in discussions unrelated to be matter of being blocked (for example w:Special:Diff/638329419 and others linked in that discussion). And I made no use of my admin tools in composing that comment - all of the information it relied on is publicly available. * Pppery * it has begun 15:09, 1 June 2024 (UTC)[reply]
This is not the place to discuss enwiki blocks and has almost entirely derailed from the original purpose of this RfC. --SHB2000 (t • c) 10:04, 6 June 2024 (UTC)[reply] |
---|
┌─────────────────────────────────┘
|
- Strong oppose This seems like a proposal to change English Wikipedia rules, however every project is idependent and they should set their own block/block reason(s) rules as long as they are in line with UCOC and 5P. Moreover, since I personally do a lot of long term abuser blocks, per WP:DENY and alike policies, I would oppose the addition of links, which in turn just glorify vandals reasons. Sorry, but any sane admin would do the same and not paste links in the block reason. Same goes for even more clear cut cases, ie. racism/sexism/extremism/paedophilia etc. which we block & report to T&S. No need to glorify vandal's actions in an unchangeable block summary.--A09|(pogovor) 10:15, 30 May 2024 (UTC)[reply]
- I don’t see how recording exactly why someone was blocked is “glorifying” their actions. That’s another issue I’m seeing— W:WP:DENY being used as unpersoning. And while there’s definitely an implicit “I can’t propose this on Enwiki so I’m proposing here” vibe from the OP, I think it’s a reasonable standard for all projects to set. Dronebogus (talk) 10:22, 30 May 2024 (UTC)[reply]
- And what's the point in linking to a diff if it's going to be hidden/rev'deleted soon? There is a reason you do not see everything sysops/CUs/oversighters see and for privacy reasons we should keep it as is. A09|(pogovor) 10:30, 30 May 2024 (UTC)[reply]
- You're grasping at straws. "This seems like a proposal to change English Wikipedia rules, however every project is idependent and they should set their own block/block reason(s) rules as long as they are in line with UCOC and 5P". This is a circular argument. The requirement I propose could be included in the UCoC or implemented by individual projects, and I addressed this in the second paragraph. The rules currently do not require it. It is entirely my point that they should be changed to do so. "And what's the point in linking to a diff if it's going to be hidden/rev'deleted soon?" I take it this isn't the case for most blocks, and in these exceptional cases (b) may be omitted, though (a) should still be included. Presumably such abuse is even rarer if the recipient is an extendedconfirmed user who has already volunteered for a time. "Sorry, but any sane admin would do the same and not paste links in the block reason." I don't understand why the suggestion of accountability seems to come as such a shock. If I were an admin I'd have no problem with this, and in fact I'd probably already be doing it. "No need to glorify vandal's actions" See my reply to SHB2000 below. I'm sure most blocks are not issued abusively, but some are. Admins must be accountable to the rules just like others. AP295 (talk) 12:42, 30 May 2024 (UTC)[reply]
- You're proposing an addition to UCOC, but your introductionary sentence is not very nice. To be clear, I also oppose any such addition to UCOC that would require admins explicit diffs to violations that caused to blocks. Honestly, your proposal seems illogical to me, so adding a diff to violation would automatically make a sysop more accountable than just citing? If a project has abusing admins the only working long-term solution is desysoping those users and not creating additional burden on admin team. Those who want to abuse, will abuse regardless of a potential UCOC addendum, and projects have appropriate venues for such discussions. A09|(pogovor) 13:17, 30 May 2024 (UTC)[reply]
- It creates no more burden than requiring the highway police to fill out a citation. Less, actually. It could be made even easier with a few interface basic interface features, yet even now it's essentially trivial. I explained in the original proposal how this policy might be adjusted to minimize the already practically-infinitesimal effort it would require, namely reducing its scope to registered, confirmed or extendedconfirmed users. Even just excluding IP users cuts it down by roughly half. You could also constrain the policy to just long-term blocks (or just indefs), but the first approach would be the most natural, if need be. So it can be scaled down in a couple of ways if a project is short-handed. "If a project has abusing admins the only working long-term solution is desysoping those users" And I said so - in almost exactly those words. They seem to have no incentive to do this if the blocking sysop can cover their tracks and obscure their administrative actions from public scrutiny. Again, a point I've already made. You say these things as though I haven't covered them, but I've already addressed them thoroughly. If you're going to pursue that line of argument, at least acknowledge the points I've already made about it instead of pretending I haven't addressed it. AP295 (talk) 20:56, 30 May 2024 (UTC)[reply]
- Admins who are abusive, will abuse further no matter UCOC rules. Your proposal is pointless to me. As well is your comparison with Highway Patrol, they are paid when filling citation. We aren't and WM community shall not create additional burdens when handling blocks. Your argument about covering blocks is pointless and patently false, that's why block logs exist. I'm not spending any more time on this discussion because you're the one making it a timesink. A09|(pogovor) 10:18, 31 May 2024 (UTC)[reply]
- It creates no more burden than requiring the highway police to fill out a citation. Less, actually. It could be made even easier with a few interface basic interface features, yet even now it's essentially trivial. I explained in the original proposal how this policy might be adjusted to minimize the already practically-infinitesimal effort it would require, namely reducing its scope to registered, confirmed or extendedconfirmed users. Even just excluding IP users cuts it down by roughly half. You could also constrain the policy to just long-term blocks (or just indefs), but the first approach would be the most natural, if need be. So it can be scaled down in a couple of ways if a project is short-handed. "If a project has abusing admins the only working long-term solution is desysoping those users" And I said so - in almost exactly those words. They seem to have no incentive to do this if the blocking sysop can cover their tracks and obscure their administrative actions from public scrutiny. Again, a point I've already made. You say these things as though I haven't covered them, but I've already addressed them thoroughly. If you're going to pursue that line of argument, at least acknowledge the points I've already made about it instead of pretending I haven't addressed it. AP295 (talk) 20:56, 30 May 2024 (UTC)[reply]
- You're proposing an addition to UCOC, but your introductionary sentence is not very nice. To be clear, I also oppose any such addition to UCOC that would require admins explicit diffs to violations that caused to blocks. Honestly, your proposal seems illogical to me, so adding a diff to violation would automatically make a sysop more accountable than just citing? If a project has abusing admins the only working long-term solution is desysoping those users and not creating additional burden on admin team. Those who want to abuse, will abuse regardless of a potential UCOC addendum, and projects have appropriate venues for such discussions. A09|(pogovor) 13:17, 30 May 2024 (UTC)[reply]
- You're grasping at straws. "This seems like a proposal to change English Wikipedia rules, however every project is idependent and they should set their own block/block reason(s) rules as long as they are in line with UCOC and 5P". This is a circular argument. The requirement I propose could be included in the UCoC or implemented by individual projects, and I addressed this in the second paragraph. The rules currently do not require it. It is entirely my point that they should be changed to do so. "And what's the point in linking to a diff if it's going to be hidden/rev'deleted soon?" I take it this isn't the case for most blocks, and in these exceptional cases (b) may be omitted, though (a) should still be included. Presumably such abuse is even rarer if the recipient is an extendedconfirmed user who has already volunteered for a time. "Sorry, but any sane admin would do the same and not paste links in the block reason." I don't understand why the suggestion of accountability seems to come as such a shock. If I were an admin I'd have no problem with this, and in fact I'd probably already be doing it. "No need to glorify vandal's actions" See my reply to SHB2000 below. I'm sure most blocks are not issued abusively, but some are. Admins must be accountable to the rules just like others. AP295 (talk) 12:42, 30 May 2024 (UTC)[reply]
- @Dronebogus unpersoning means " an individual who usually for political or ideological reasons is removed completely from recognition or consideration". Are you accusing Admins of doing that? Doug Weller (talk) 08:17, 7 June 2024 (UTC)[reply]
- Yes and no; I’m not accusing admins of “disappearing” “enemies of the state”, but I do think that the current system (such as it is) is sometimes, albeit rarely, used to not only prevent the user from contributing but almost pretend like they didn’t exist— by scrubbing talk pages, user pages, rationales for blocking, occasionally even censoring mentions of them, etc. I understand there’s supposedly good reasons for this but if they were super-ultra-permabanned I think it should be obvious why. Dronebogus (talk) 09:07, 7 June 2024 (UTC)[reply]
- And what's the point in linking to a diff if it's going to be hidden/rev'deleted soon? There is a reason you do not see everything sysops/CUs/oversighters see and for privacy reasons we should keep it as is. A09|(pogovor) 10:30, 30 May 2024 (UTC)[reply]
- I don’t see how recording exactly why someone was blocked is “glorifying” their actions. That’s another issue I’m seeing— W:WP:DENY being used as unpersoning. And while there’s definitely an implicit “I can’t propose this on Enwiki so I’m proposing here” vibe from the OP, I think it’s a reasonable standard for all projects to set. Dronebogus (talk) 10:22, 30 May 2024 (UTC)[reply]
- Strong oppose for very similar reasons to A09. In most cases, block reasons are obvious – whether it be vandalism, block evasion, spam, and the like. Forcibly requiring admins to provide diffs will only put more burden with less time put for more productive things. Others, like the blocks of LTAs, go against the spirit of DENY (this is not exclusive to enwiki, FTR) and give them the attention they seek (making it entirely antithetical). For more complex cases, this is almost entirely the case already and does not need to be enshrined in policy. --SHB2000 (t • c) 10:48, 30 May 2024 (UTC)[reply]
- It would take a few seconds of extra time (if any). I wrote the first paragraph below "some extra remarks" in anticipation of this response. The flimsy our-critics-are-all-socially-insecure-losers line of rhetoric is exampled here in true form; "and give them the attention they seek". This isn't an honest or sound argument. AP295 (talk) 11:22, 30 May 2024 (UTC)[reply]
- Uhm, it does? Most LTAs here are purely attention-seeking; that's why DENY exists. --SHB2000 (t • c) 13:22, 30 May 2024 (UTC)[reply]
- Yet some people are blocked unfairly. Do you agree that sometimes admins have ulterior motives and block people unfairly? Even just the potential justifies this proposal. LTA, I presume, means "long term abuse", but you lump "others" in with this category "Others, like the blocks of LTAs" AP295 (talk) 20:37, 30 May 2024 (UTC)[reply]
- I'm not denying that some people are blocked unfairly, but this number is rather small and should instead be dealt on a case-by-case basis instead of blanketing it in the UCoC. Otherwise, I've said what I said and don't think it needs to be repeated for the umpteenth time in a wall of text. --SHB2000 (t • c) 09:33, 31 May 2024 (UTC)[reply]
- " but this number is rather small" Hard for the public to know without a public record. Pilot this requirement for a few months or a year and then maybe you can make that claim. "Small" relative to blocks issued? Probably. A small number per year? I doubt it. AP295 (talk) 09:47, 31 May 2024 (UTC)[reply]
- I'm not denying that some people are blocked unfairly, but this number is rather small and should instead be dealt on a case-by-case basis instead of blanketing it in the UCoC. Otherwise, I've said what I said and don't think it needs to be repeated for the umpteenth time in a wall of text. --SHB2000 (t • c) 09:33, 31 May 2024 (UTC)[reply]
- Yet some people are blocked unfairly. Do you agree that sometimes admins have ulterior motives and block people unfairly? Even just the potential justifies this proposal. LTA, I presume, means "long term abuse", but you lump "others" in with this category "Others, like the blocks of LTAs" AP295 (talk) 20:37, 30 May 2024 (UTC)[reply]
- Uhm, it does? Most LTAs here are purely attention-seeking; that's why DENY exists. --SHB2000 (t • c) 13:22, 30 May 2024 (UTC)[reply]
- It would take a few seconds of extra time (if any). I wrote the first paragraph below "some extra remarks" in anticipation of this response. The flimsy our-critics-are-all-socially-insecure-losers line of rhetoric is exampled here in true form; "and give them the attention they seek". This isn't an honest or sound argument. AP295 (talk) 11:22, 30 May 2024 (UTC)[reply]
- Strong oppose An administrator can theoretically also block without giving reasons (I personally do this myself) In clear cases, long reasons are unnecessary work. The assertion that the block cannot be checked is also wrong. An administrator must always justify his use of the rights in case of reasonable grounds for suspicion. --𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 19:18, 10 June 2024 (UTC)[reply]
- Oppose I like where the proposal is going, but it is arguably too undifferentiated. Surely an admin blocking a long-term abuse account or an obvious one-off cross-wiki vandal should not need to collect diff IDs and state policy. Yes, too many wikis have great administrator accountability problems. These are made better in the Czech Wikipedia and Czech Wiktionary by admins being removable by mere superminority (33.3% + 1), and it leads to a state of affairs in these projects where I cannot identify anything like an abuse of power (and Czech Wikipedia has an impressive arbitration commitee); by contrast, the administration in the English Wikipedia and the English Wiktionary leaves too much to wish, and none of these projects make desysop by superminority possible. --Dan Polansky (talk) 09:24, 12 June 2024 (UTC)[reply]
- I like the idea of being able to de-mop by superminority. As it stands sysops on enwiki are basically impossible to remove unless they want to be. I worry, however, that attempting it on enwiki would lead to the initiator getting abused and/or banned if it failed, sort of like RfAs but in reverse. Dronebogus (talk) 16:08, 12 June 2024 (UTC)[reply]
- Strong oppose per WikiBayer, SHB2000 and A09|. User:AP295 can you please explain your comment at the beginning "I shall interpret such answers as approval or disapproval of the above proposal, which could be implemented either in the UCoC or by individual projects."? How is your interpretation relevant to this RfC? — The preceding unsigned comment was added by Doug Weller (talk) 10:24, June 12, 2024 (UTC)
- The above proposal as opposed to the rest of my observations. Others may disagree with some of them yet still support the proposal itself. While it's not my prerogative to tell others how to interpret votes, I can certainly let them know how I shall interpret them, which is not otherwise clear. Making an effort to prevent misunderstanding is important, no? AP295 (talk) 12:55, 12 June 2024 (UTC)[reply]
- @AP295 That's fine, but your interpretation doesn't matter for the result, right? Doug Weller (talk) 15:58, 12 June 2024 (UTC)[reply]
- I just explained why I think it does, at least to some small degree. AP295 (talk) 16:39, 12 June 2024 (UTC)[reply]
- @AP295 I don’t see how that could affect the close, nor do I see how this RfC even if it passes can have an effect. Doug Weller (talk) 17:41, 13 June 2024 (UTC)[reply]
- @AP295 I’m not sure if you’ve seen this post. Your interpretations can’t affect the result and I don’t see how this RfC can affect anything. Doug Weller (talk) 21:10, 14 June 2024 (UTC)[reply]
- @Doug Weller Ap295 was indef banned from Meta, so expect no further responses from this account. A09|(pogovor) 22:00, 14 June 2024 (UTC)[reply]
- TPA also revoked so their chances of getting unblocked are slim. --SHB2000 (t • c) 04:18, 15 June 2024 (UTC)[reply]
- @SHB2000 Thanks for letting me know. It was clearly inevitable. Someone uninvolved needs to close this now. Doug Weller (talk) 10:40, 15 June 2024 (UTC)[reply]
- Thanks for telling me. Doug Weller (talk) 10:40, 15 June 2024 (UTC)[reply]
- TPA also revoked so their chances of getting unblocked are slim. --SHB2000 (t • c) 04:18, 15 June 2024 (UTC)[reply]
- @Doug Weller Ap295 was indef banned from Meta, so expect no further responses from this account. A09|(pogovor) 22:00, 14 June 2024 (UTC)[reply]
- @AP295 I’m not sure if you’ve seen this post. Your interpretations can’t affect the result and I don’t see how this RfC can affect anything. Doug Weller (talk) 21:10, 14 June 2024 (UTC)[reply]
- @AP295 I don’t see how that could affect the close, nor do I see how this RfC even if it passes can have an effect. Doug Weller (talk) 17:41, 13 June 2024 (UTC)[reply]
- I just explained why I think it does, at least to some small degree. AP295 (talk) 16:39, 12 June 2024 (UTC)[reply]
- Strong oppose Disclosing that I am not an admin, I am also essentially retired from editing wikipedia largely because I find myself facing the en:Innocent prisoner's dilemma and I am tired of the bullying environment endemic to en.wikipedia. This proposal fails on two points. An admin shouldn't have to log the details with diffs. Why you may ask? Because I remember the old days of wikipedia when an issue was raised requiring admin intervention, it had to be extensively supported with the use of diffs. If it wasn't it would be tossed out with no action. Sadly this is no longer the case, merely enough editors making a noise is sufficient to get an editor sanctioned. We need to return to a state where the onus is put upon the complainant to provide the evidence not a post hoc justification by an admin. My second reason for opposing this, is that it would become a further excuse for inveterate wikilawyers to nitpick over the details and having been the focus of one such editor for well over a decade I am well aware this would become a charter for disruption. My colleague @Kahastok: can well attest to this. The onus needs to put upon complainants to provide evidence that there is an urgent incidents or chronic, intractable behavioural problems rather than the admin conducting action. Wee Curry Monster (talk) 11:54, 12 June 2024 (UTC)[reply]
- "We need to return to a state where the onus is put upon the complainant to provide the evidence not a post hoc justification by an admin." That's perfectly fine, but not all blocks involve a "complainant". Your argument seems to presume that complainants are fallible and must provide information but that admins are not and should not. Also, when the complainant does provide the info, the admin can simply put it in the block log or in the talk page notice so that others can easily find it. I don't see how your point contradicts my own. Lastly, accusing someone of "wikilawyering" is both dismissive and unwarranted if the admin hasn't furnished any substantive evidence to support the block in the first place. The admin is responsible for issuing the block and should make a positive statement that can be falsified if it's untrue. AP295 (talk) 13:06, 12 June 2024 (UTC)[reply]