UDWiki talk:Administration/Policy Discussion/Off-Site Requests for Admin Actions

From The Urban Dead Wiki
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

In case that any of you have missed the drama that has created the need for such a policy: Izzy's sig SD discussion and related Misconduct case against Cheese for overturning an off-site request.
As should be obvious, I am not a fan of off-site requests - they are easy to falsify and hard to be made accountable without massively hurting privacy.
However, I recognize a few cases where off-site requests might be valid:

  • Actions requested on behalf of a banned user (especially for, but not necessarily limited to Permaban appeals).
    Banned users have technically no other way to get anything done but to use non-banned users as proxies.
  • Deletions of copyrighted material requested by the copyright holder.
    When The Man threatens us with his lawyers over copyright, we would be terminally stupid to not act on it just because The Man can't be bothered to use the petty bureaucracy of our petty fiefdom.
  • Actions that would have been considered to be scheduled anyway (particularly, but not limited to Scheduled Deletions and Scheduled Protections).
    No-Brainer that hopefully doesn't need further explanation.
  • Sys-Ops may temporarily tolerate other off-site requests. As such a requested is merely tolerated, it may be overturned at any time by any sys-op, unless the user himself shows up on-site to confirm it.
    This is the carte blanche for extreme cases - like, when an user's home connection breaks down and he can't access the wiki at work. As it is merely tolerated until the user shows up, there is a strong built-in incentive to show up ASAP and thus create the necessary accountability. Obviously, this would require to put some trust into sys-ops to not do instant overturnings on sight - but likewise, users would need to put trust into them anyway to recognize their off-site request.

Discuss. --Oh, and vote on Project Funny, by the way. -- Spiderzed 20:06, 17 May 2011 (BST)

Works for me… mostly.

Remove the whole “tolerate” section and require any other sysop to show cause for anything to be overturned. I remind you that these are sysop-only actions and thus subject to Misconduct proceedings if any impropriety is found to have taken place. ᚱᛁᚹᛖᚾ 02:27, 18 May 2011 (BST)

Regarding the "show cause" idea, I would disagree to the greatest degree possible. The onus should always be on the sysop who is accepting an offsite request, rather than on the rest of the team, to provide evidence supporting their side. After all, by virtue of being an offsite request, we can only guarantee that the sysop accepting the request would have access to any form of evidence at all. Putting the burden of proof on the team would mean that any sysop could claim to have had an IRC chat or received an e-mail but not kept it, allowing them to do virtually anything in anyone's name. Unless the person showed up later to contest whatever happened, the team would have no way of showing cause. Aichon 06:27, 18 May 2011 (BST)
^ to every possible degree, seriously. Keeping in mind the catalyst for this, iscariot, is someone notorious for forging off-site logs in order to prove things in issues on-wiki -- ϑanceϑanceevolution 10:49, 18 May 2011 (BST)
As these two. -- Cheese 10:53, 18 May 2011 (BST)
I'm with Aichon on this one. An off-site request has to leave a trail (request) that could be reproduced, while there is no way to get proof for the negative if the user in question doesn't actively provide it. By putting the onus on the sys-ops doubting the validity, inactive users would become unprotected game for whatever claims of off-site requests someone puts up for them. In general, off-site requests should stay the excemption, and they should be as soon as possible confirmed. --Oh, and vote on Project Funny, by the way. -- Spiderzed 17:19, 18 May 2011 (BST)

I very much agree with basic policy but I'm not entirely happy with the ability of Sysops to entirely unilaterally overturn the decisions of other Sysops with any discussion or cause. I believe there should be at least some sort of discussion before doing so (I.e something put-on A/SD].--The General T Sys U! P! F! 09:11, 18 May 2011 (BST)

The general principle should IMHO remain to keep on-site requests the default case, and to have an incentive for the usee in question to confirm on-site ASAP. I see how this could lead to edit warring between sys-ops, though. Any ideas on lessening that risk while staying true to the principle and keeping an incentive to confirm on-site? A grace period maybe? Or the need for two sys-ops to agree on overturning the action to cut down on the risk of lone rogue ops willy-nilly overturning actually necessary off-site requests on sight? --Oh, and vote on Project Funny, by the way. -- Spiderzed 17:19, 18 May 2011 (BST)
Perhaps the requester must show just cause for the off-site request (they'd have to explain in their request why they could not make the request themselves). Also, possibly a rule that whichever op received the off-site request may only post the request on the wiki, but the action must be carried out by another sysop. This would give an opportunity for review by a peer. ~Vsig.png 17:35, 18 May 2011 (UTC)
Yes, I do agree that off-site requests should be discouraged when not necessary. I think the best way to implement it would be to require the agreement of two or more sysops in order to overturn a deletion. Effectively, one could post it to A/U and another could undelete it.--The General T Sys U! P! F! 17:43, 18 May 2011 (BST)
IMHO I don't think we should be implementing a policy which encourages decisions to be overturned. There should be more strict rules for someone requesting an off-site action and a way for sysops to be held accountable for taking action on it (i.e. the op which received the request may only relay the info to the wiki). ~Vsig.png 17:59, 18 May 2011 (UTC)
Hence why I think that sysops should post on A/U and wait for another sysop to overturn it: That's makes it no easier than the current system for overturning deletions. I think there should definitely be strict rules for accountability on deletions, but there are still problems with the basic principle in that is no way to absolutely prove that the user requested it.--The General T Sys U! P! F! 18:05, 18 May 2011 (BST)
Yes, there is that. Try as I may I can't think of any good way of obtaining proof. In my opinion, I think it's just best if they aren't allowed unless by a banned user. ~Vsig.png 18:40, 18 May 2011 (UTC)
There are ways, like screenshots of e-mails or forums PMs. However, the former can be a massive violation of privacy (and useless if the e-mail adress can't be verified as that of the user), while the latter requires to be strongly established in the meta. And when someone really wants to, screenies are falsified within a couple of minutes. Just more reason to limit it to a temporary last-ditch effort. --Oh, and vote on Project Funny, by the way. -- Spiderzed 17:41, 19 May 2011 (BST)
Temporary tolerance of illegal acts is actually a quite wide-spread practice in public administration. Rather than to directly deal punishments or outright deny bad requests, the recipient is given a time window to remedy the law violation and turn the situation legal. That's where I've lend the idea from, since it is my field of work. It doesn't compromise accountability at all, but still provides something for those in favour of off-site requests and gives us grounds on which to temporarily enact such requests. --Oh, and vote on Project Funny, by the way. -- Spiderzed 17:41, 19 May 2011 (BST)

Restricted Actions

Requests should probably be limited to only deletion and protections requests. Wouldn't it be a nice little loophole if a user was able to request a self-ban off-site which would then allow them to request whatever action they wanted under this policy, then request an unbanning after they've gotten what they want. ~Vsig.png 18:40, 18 May 2011 (UTC)

Oh, off-site self-bans. Yes, that would be malicious if abused. I'll add them to "Thou shalst never" along with votes. --Oh, and vote on Project Funny, by the way. -- Spiderzed 19:03, 18 May 2011 (BST)
After a long and hard look on the admin pages, I also added self-requested demotions. That could also be massively abused. --Oh, and vote on Project Funny, by the way. -- Spiderzed 14:27, 20 May 2011 (BST)

Urgh

President Obama has prepared a statement, which he's passed to me for this wiki:

"while the idea is a good one, Iscariot has been a dick about the whole thing. I'd like to see items that aren't immediately necessary but reasonably important be initiated only by a wiki presence. Actions like taking the entire sysop team to misconduct, for example. Thanks for your hard work, citizens!

I agree with the Commander-In-Chief. --Karloth Vois ¯\(°_o)/¯ 09:36, 19 May 2011 (BST)

To the bat-mobile!

Tomorrow, this policy will become eligible for being put up for vote. I have some interest into seeing that put through ASAP, so if anyone still has something to add, I'd like to hear it pretty soon. --Oh, and vote on Project Funny, by the way. -- Spiderzed 14:27, 20 May 2011 (BST)

Read below and maybe ignore the people telling you there's a glaring issue less just because Cheese and DDR want to re-enforce their argument in a A/M case with policy? --Karekmaps 2.0?! 21:33, 20 May 2011 (BST)
I've got something to add, but am still thinking about how best to word it. I'll see if I can get it written up coherently tonight (AEST). ᚱᛁᚹᛖᚾ 07:27, 21 May 2011 (BST)

About this policy

Sys-Ops may temporarily tolerate other off-site requests. As such a request is merely tolerated, a sys-op may anytime ask for another sys-op to overturn it, unless the user himself shows up on-site to confirm it.

—Spiderzed/Mainpage

Uhm, yeah, no. We don't need sysops harassing users who don't or can't visit for the sake of it. It's petty and exists solely for vindictive use. It negates the whole rest of the policy. It's a bad idea and I seriously question the motivations of anyone foolish enough to support it. Don't make policies with built in "I can refuse to allow this if I feel like it/don't like the requester" riders, common sense.

Also, remove the copyright thing too. Any requests for it have to go through Kevan to be legal. Any other actions should be documented in the standard way considering they're already auto-override when it can be shown to clearly be in violation of copyright law. --Karekmaps 2.0?! 21:32, 20 May 2011 (BST)

It's not for vindictive use, and neither willy-nilly used as thou wilst - you can render that clause _completely_ void just by heading over personally and leaving your four tildes.
A similar principle is used by public administrations all around the world to make temporary allowances, while ensureing that the recipient cooperates in the procedure and actively works legalizing it. (A common and comparable example in German law are illegal constructions built without permit if a permit would be likely obtainable. Rather than to immediately enforce the law and force the constructer to waste large wads of dough through potentially unnecessary demolition, or to fully permit the construction based on insufficient documentation, administration practice is to temporarily tolerate the illegal action and give the builder a chance to obtain the permit and thus legalize the construction after the fact.)
As for copyright, I think it is better to keep our backs safe in case we receive a legal threat and have to act swiftly. I don't want to see an op punished on A/M for keeping the wiki from getting plugged by lawyers. --Oh, and vote on Project Funny, by the way. -- Spiderzed 22:38, 20 May 2011 (BST)
1) We are not a legal/governmental organization so 2) pettiness is easier to justify and defend through bullshit arguments like "He can request it there he can request it here". If you want to show that the goal isn't for actually making this an unenforceable policy remove that line. Don't claim real world precedent. Fon't deny that this will lead to the ability to easily abuse this system to allow sysops to deny requests based on the requester. Just remove it. A/M is our review process, don't try to sidestep it through a special exception.

No one has ever punished said op for doing the right thing. All this would really do is make it easier for sysops like Conndraka(former) to delete things like the Marty Banks pictures on site without having to defend their own reason. It basically gives them the argument of "Well so and so requested it in email to me but, also revealed his personal information so I don't have to site it.". It would open up a bigger potential can of worms. --Karekmaps 2.0?! 03:52, 21 May 2011 (BST)
One of the first, if not the first, request for copyright removal came from an off-site request (it was to remove a picture on a page controlled by the survivor group named "Chanel 4 News Team"). I think off-site requests must continue to exist, because most copyright violations are likely going to be done against entities that likely have no interest or care about this Wiki and would be unlikely to make an account, preferring instead to bother Kevan.--ShadowScope'the true enemy' 23:27, 23 May 2011 (BST)
I more meant that copyright requests have to be documented by the sysops taking action before taking it. This policy is more just for semi-scheduled requests that you do and document. Copyrights are something that should be brought up to the image uploaders prior to immdediate deletion, the claim gets vetted, we shbouldn't just be deleting things because someone claims copyright. Plus including it here makes it subject to the other ridiculous part of this policy and thus pointlessly unenforceable. --Karekmaps 2.0?! 00:32, 24 May 2011 (BST)
We are indeed not the guvernmint. However, there are strong similarities in the way administration is handled (we get requests, check them for validity and then carry them out or not, depending on results), and those guys have maybe, maybe a bit more experience with such matters than our little fiefdom or wikipedia.
As for "easy abuse", you can still _completely_ side-step this policy by simply submitting your request in person, just as you should do, and laugh in the face of every wannabe Conndraka. If personal submission is too much effort for you to make your request waterproof, you can't care that much about the wiki anyway. -- Spiderzed 17:15, 24 May 2011 (BST)
Or, you could not intentionally hamstring a policy to make it easier to serve user requests, that's a good idea too. --Karekmaps 2.0?! 21:40, 24 May 2011 (BST)

"Deletions of copyrighted material requested by the copyright holder."

Is already a part of Scheduled Deletions. Do we need to have it in this policy? I assume it is enacted when Kevan states: "Hey, I got a request to get this deleted, remove it." --Akule Maker of fine, hand-crafted UDWiki sass since 2006 -- Akule School's back in session™ 21:52, 24 May 2011 (BST)

You are correct. Will remove that bit to avoid redundancy and potential policy clash, should the status of copyrighted stuff ever change. -- Spiderzed 16:53, 25 May 2011 (BST)

Discussion on Aichon's vote

The part about being able to overturn the request is absolutely necessary, since we would otherwise be giving these off-site requests the same weight as on-site requests, but without the requirement that any sort of paper trail be provided. Aichon 16:52, 30 May 2011 (BST)

That's not exactly true. In cases where it is questionable we can require proof through A/M.--Karekmaps 2.0?! 17:43, 30 May 2011 (BST)
The default of A/M is to uphold the action in question (e.g. tied votes are treated as Not Misconduct), but we need for the default to be to support the overturn, else it puts the responsibility on the wrong party. Also, A/M should always be treated as an exception, and not part of the normal process for handling disputes that are likely to arise. Towards that end, this policy provides non-A/M mechanics for how an overturn can itself be overturned, which is by the requestor showing up to make it official. Clear, simple, and without room for drama and interpretation. Aichon 21:21, 30 May 2011 (BST)
The only valid reason is reasonable suspision the request is fake. That's exactly the kind of thing A/M should be used for. --Karekmaps 2.0?! 22:39, 30 May 2011 (BST)
"The only valid reason is reasonable suspicion the request is fake." - Says who? I know you think that an action must be Misconduct to be overturned (at least with regards to A/U), but we're talking about this policy here and it doesn't say that. Overturning an action does not necessitate that the action be considered Misconduct (else we'd have to rule Misconduct before we could undo any administrative mistake), nor are fake requests the only valid reason to overturn a ruling (and even if they were, what if it wasn't the sysop's fault, such as if one user impersonated another off-site?). Plus, in cases where the sysop is at fault, the status quo shouldn't be upset for however many days it takes for the A/M ruling to be reached. Aichon 05:30, 31 May 2011 (BST)
You realize you're contradicting yourself right? If it's an administrative mistake in this case it would ha ve to be a fake request. Anything else would be a valid request. --Karekmaps 2.0?! 07:49, 31 May 2011 (BST)
I don't think you're being imaginative enough if you think that all administrative mistakes have to be fake requests. What if a user made an ambiguous request which was reasonably acted on other than how it was intended? Or what if a user made two contradictory requests to different sysops? And how about if one user impersonated another to make a request? Aside from the last one, none of those are fake requests, and that last one isn't being perpetuated by a sysop, yet all of them are likely to need overturning. It shouldn't require reaching a Misconduct ruling to do so, since the sysop(s) aren't necessarily to blame. Aichon 08:24, 31 May 2011 (BST)
1. We don't ambiguously serve requests, if you're unsure you get clarification. 2. No such thing and if there were it's grounds to legitimately serve neither. 3. Fraud will out but, generally, off site request come through means that we know who the requestor is well enough to catch that. None of that justifies your stance though, it's just things that can already happen without requestinhg them offsite.--Karekmaps 2.0?! 17:39, 31 May 2011 (BST)
For all of these, my point is that things happen sometimes which require undoing administrative actions without taking people to Misconduct, which I think may have gotten lost in all of the words. To quickly clarify each one and respond to your points:
  1. Ideally, yes, but what if you don't realize it's ambiguous? That's why I said "reasonably acted on" in the description. It's happened before, and it's a simple mistake that can be easily corrected without assigning blame. We shouldn't have to rule Misconduct to fix the mistake.
  2. I think you misunderstood it, since it can happen, such as if a user wants to create drama by intentionally saying contradictory things to different sysops without either of them being aware of the request made to the other (something that can't happen on the wiki). I do agree that it's grounds to not serve either, but that wouldn't be immediately apparent, since this would have all been done off-site. Overturning the initial action while it's sorted out makes sense, and while that situation likely should go to A/M, since it would appear that at least one sysop must be lying, a Misconduct ruling should not be the basis for determining what happens, since neither of them should have that ruling made against them.
  3. It's easy to fake that on IRC, especially for people that haven't registered their account, and I doubt most sysops know everyone well enough to check the IRC profile and ensure that it matches with the actual person. It's even easier with e-mail, since few people here use it frequently enough to recognize the legitimate account associated with a user.
Also, only #1 can happen currently. #2 and #3 can't happen on the wiki, since #2 would be spotted immediately, and #3 is impossible without compromising an account. Aichon 22:14, 31 May 2011 (BST)
Yes but, there's one big mistake in the reasoning here: namely the assumption that sysops are incapable of discussing and fixing issues when they arise. The first point assumes that anyone would be required to misconduct it when the sysop is asked about the action, you don't need to misconduct to get a sysop to fix a mistake(look at the DHPD edit conflict right now). The second assumes that when given conflicting reports the sysops won't ask each other what the hell is going on and figure it out. And the third, it's easy enough to double check if you're not sure before serving the request.--Karekmaps 2.0?! 03:28, 1 June 2011 (BST)
I'm fine with that. My concern was based on some of your earlier statements, which I (mistakenly?) interpreted as saying that A/M is how every overturn would need to be handled. Given your previous stance on A/U, I assumed that then meant that for an overturn to occur, a Misconduct ruling would have to be handed down. That's what I disagree with and why I tried to provide examples of situations where sysops wouldn't be at fault but would still need to have their actions overturned. Aichon 04:56, 1 June 2011 (BST)
Meh, that case undeletion had/has specific rules for requests that are made. In that case without being able to show the request to be otherwise fake, or served in a manner incongruous with the request, it had to be treated like an otherwise valid request performed as a judgement call. The question then was specifically one of did Misanthropy fake the request or serve it incorrectly, and the misconduct case originally reflected that and ok'd the action where as cheese decided to make the misconduct case and act with the assumption that it was misconduct before the case had a chance to conclude. --Karekmaps 2.0?! 06:04, 1 June 2011 (BST)

Too lax?

Funny. I'm myself firmly set in the "no off-site requests" camp, and had actually made it more liberal in order to appeal to and compromise with those who are in favour of allowing off-site requests. Do I see it right that Karek is the only one who thinks this is too harsh on off-site requests, while at least 4 users would rather see no off-site requests at all? If so, I might withdraw this one and submit a new version without the Sys-Ops may temporarily tolerate other off-site requests. As such a request is merely tolerated, a sys-op may anytime ask for another sys-op to overturn it, unless the user himself shows up on-site to confirm it. That way, only banned users and scheduled actions would be eligible. -- Spiderzed 17:45, 1 June 2011 (BST)

No, I'm with Karek, but not enough to merit an against vote either.--Yonnua Koponen T G P ^^^ 17:51, 1 June 2011 (BST)
Personally, I'd remove that part. It leaves the door open for disputes and hasn't this issue been disputed enough? We either nip it in the bud; strict policy on off-site requests, or we go with the current status quo; arguing the validty of these types of requests with nope hope for consensus. ~Vsig.png 18:03, 1 June 2011 (UTC)

Looking on the way the vote goes and at the discussion on the talk page, I'll withdraw this one in favour of something harsher. -- Spiderzed 14:17, 3 June 2011 (BST)