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

See previous policy discussion, especially the discussion in the last section. The community has made it clear that it prefers to have as little off-site requests as possible, so I've revised the proposal.

In the new proposal, off-site requests are generally shunned and sternly limited to actions on behalf of banned users and to scheduled actions. In addition, several administrative actions are defined that are too sensitive to ever be allowed for off-site requests.

As the old proposal was up for nearly 2 weeks before going to vote, and since the revision discussion has been running for three days, this one will already go up for voting tonight before the server clock ticks over, in order to lose as little time as possible. -- Spiderzed█ 14:24, 3 June 2011 (BST)

If you're planning to do anything with this, it probably needs to be soon. —Aichon— 19:48, 18 June 2011 (BST)

Sadly, I don't have the time currently to give everything proper thought :( Especially not on such a hotly contested topic as this. -- Spiderzed█ 20:10, 18 June 2011 (BST)

Crit 7

But the only time a user would be making an offsite deletion request would be a crit 7, which already is a scheduled deletion, so I don't really see this curbing off-site requests at all, which seems to be what you're going for.--Yonnua Koponen ^{T G P} ^^^ 14:26, 3 June 2011 (BST)

It's not. What is scheduled is Crit 7 by proxy, which is defined as If a user leaves a sysop a note on their (i.e the sysop's) talk page requesting deletion of a page that falls under Crit 7 - which is still on-site and thus confirmable, just on the wrong page. -- Spiderzed█ 14:34, 3 June 2011 (BST)

That's not actually the full crit 7 by proxy, but w/e. If this doesn't include crit 7, then it goes against UDwiki's copyright policy, precedent for off-site deletion requests, etc. It's also really, really stupid.--Yonnua Koponen ^{T G P} ^^^ 14:38, 3 June 2011 (BST)

Eurgh

I do not agree with this in the slightest. Sysops are (meant to be) trusted users, and when they claim responsibility for doing something they were asked elsewhere, it should be given that leeway. Curbing the ability for a sysop to do what's asked of them without it going through the increasing levels of red tape is a bad idea. Ops who act on off-site requests should be responsible for ensuring that they can verify the validity of said requests, but should be permitted to act on them. 15:26, 3 June 2011 (BST)

He's making determinations that justify his opinion instead of reading the actual votes or letting the discussion/vote go long enough to have really had community input that is qualitative. Can't be suprised really, he was trying to do it throughout the last discussion too but there he was claiming it was a compromise to the status quo. --Karek^{maps 2.0?!} 19:35, 3 June 2011 (BST)

Funnily enough, two of the last people I ever thought I'd be agreeing with.--Yonnua Koponen ^{T G P} ^^^ 20:12, 3 June 2011 (BST)

Last PD was open for nearly 14 days. You had over 2 weeks to propose a counter-policy or something similarly substantial, and have come up with nothing. If it weren't for me charging forward and actually doing something, we'd be stuck with drama as in the Iscariot deletion discussion again and again, something the community seems to widely disapprove of. If you guys really think that there is a majority in favour of off-site requests, all you need to do is to go ahead and do something, rather than to expect me to carry out your will.
As for "reading the actual votes", within a couple of days of going to vote, Sexualharisson and Vapor have jumped ship and deemed it not harsh enough. Karloth refuse to sign something so liberal, as did Fjorne. That are four votes clearly lost by being too permissive towards off-site requests.
On the opposite side, we have Karek, Mis, Gardenator and now Yon explicitely deeming the old policy too harsh. Obviously, your stance wouldn't be changed at all when a harsher policy is being proposed. OTOH, a policy that is fully permissive wouldn't get anyone but you four behind it and would be bound to fail.
The way I read the community input, a strictly non-permissive policy is the only thing with a chance to pass. Personally, the most important thing is that we come to a clear-cut solution about off-site requests, and I'd prefer a clear-cut permissive stance that passes and thus releases us of that drama over a clear-cut restrictive stance that fails and leaves us with drama. If I could see a clear majority in favour of it, I'd rather propose a liberal policy and see it passing, rather than to submit a failed policy more to my liking. However, community doesn't look to fly that way. -- Spiderzed█ 14:44, 4 June 2011 (BST)

Please stop bullshitting, as Karek's comment that he removed. You also say that we "haven't proposed an alternative". How about the precedent that's already in place that was set out by the sysop rulings in the Iscariot case? How about the reason I didn't blindly force my ideas on the community and tell them that's what they want is because I think the situation's already been resolved.--Yonnua Koponen ^{T G P} ^^^ 16:17, 4 June 2011 (BST)

Looks good to me

Let 'er rip. ~ _{20:45, 3 June 2011 (UTC)}

Why?

Now that you've removed the ability to do actions other than dealing with banned users and handling scheduled actions, this policy very nearly does nothing at all.

For instance:

1. Permaban appeals are not an admin action, since any user can initiate an appeal, and the banned user doesn't need to contact a sysop. Why are they mentioned in this policy at all?
2. The only admin action a banned user may request is to be unbanned after a self-requested ban, and that doesn't require a formal request, since those bans can be undone at will.
3. None of the scheduled protections involve a request, so it doesn't matter whether or not off-site requests are allowed. Why are they mentioned in this policy?
4. Only three of the scheduled deletions involve a request, while the other twelve have nothing to do with them.

If this policy only impacts three scheduled deletions, why not use the correct way to change them, rather than opening new loopholes by mentioning all sorts of other stuff that has nothing to do with off-site requests? And after that, to close any loopholes, make a policy forbidding all off-site requests for admin action unless explicitly permitted elsewhere. Simpler, less controversial, easier to understand, and easier to maintain going forward since it doesn't use confusing language or lists that might be outdated in the future. —Aichon— 20:50, 3 June 2011 (BST)

1. Permaban appeals are performed over an admin site, and need sysop action to be carried out when successful. While this should be no-brainer, I'm better on the safe side rather than to see this policy invoked to overturn a legitimate permaban appeal. With everything invoked because of Iscariot, I am very wary of wikilawyering.
2. Not so sure on that one. What if a banned user wants to get rid of a userspace subpage (C7)? What if he has copyrighted material on this wiki, such as self-created images, and wants to see them deleted (Scheduled _and_ potentially wiki-threatening if not carried out)? Or what if he has left personal data on his userpage and wants to see it thoroughly removed (see above)? While the privileges of a banned user are heavily diminished, there are some rights that are being retained even after being banned.
3. While no scheduled action necessates a request, scheduled actions are often only carried out when a request is given, such as in the case of missed administrative pages. (See The General's suggestion clean-up in the A/PT archives.) In other cases, something only becomes a scheduled action by being triggered by request, as in the case of copyrighted material, or in the case of dox originally put up by the user in question.

As for what this policy would do, it would clear-cut seal off-site requests for anything but actions on behalf of banned users and for scheduled actions. Looking at the case that has created the need for this policy, the deletion wouldn't have to be carried out unless Iscariot shows up himself, and we would have saved the unproductive quarrel over what to do. Which is good enough for me. -- Spiderzed█ 15:00, 4 June 2011 (BST)

Let me cut to the chase: I think that the solution I mentioned in my last paragraph was a better one than this policy and achieves the same goals. I'd like a response, since it seems like a more elegant solution which is less prone to issues.

As for issues, which takes precedent when a contradiction occurs: this general policy, or the more specific ones governing each scheduled action? It seems like lose-lose to me:

1. Assuming the policy overrules the wording of scheduled actions, then we'll need to amend the policy anytime that we want to add a scheduled action which doesn't permit off-site requests, which is bad (it shouldn't require a vote and a policy change).
2. Assuming the wording of the specific rules prevails, then this policy does nothing at all since the scheduled actions can ignore it as they choose.
3. Assuming no decision is made, anytime a sysop acts on a scheduled action which contradicts this policy (such as C7 by proxy), they could face A/M for acting contrary to the rules of the scheduled action.

As for the ban stuff, mentioning permaban appeals makes as much sense as mentioning A/D requests (both are initiated by anyone, go through a vote, and are processed by sysops at the end), banned users can't use C7 since they can't post on the wiki (all of the current methods for requesting C7 require the wiki), actual copyright requests go through Kevan and circumvent the usual channels, and I overlooked personal info, but even non-users can get it deleted, so it doesn't matter. —Aichon— 08:55, 5 June 2011 (BST)

Meh, it's not like any of it matters. The whole of the second section is already the status quo and common sense without policy. The fact that it's even proposed as part of one is actually kinda stupid.

Actually this whole policy could be shortened down to the following phrase: "Off-site requests are not allowed" but that would be clearly a foolish thing to write a policy around. Especially when the current status quo is that sysops are not required to serve off-site request but occasionally do when the circumstances surrounding that request make it reasonable. If you don't like serving off-site requests don't serve them or, if you have reason to suspect one of being faked, take it up with the sysop that did serve it and show your reasoning. --Karek^{maps 2.0?!} 09:15, 5 June 2011 (BST)

Yeah, I'm fine with common sense prevailing, and the current precedent seems fine, since it appears that everyone agrees it shouldn't be done without good reason. That said, there have been a few times where "good reason" has been a bit stretched, so I'm also in support of defining what is or isn't acceptable practice. Either way works for me, so long as we don't make it worse by adding unresolved contradictions, confusion, and drama (which probably goes against what I said on the prior revision of this policy that went to vote, but meh, I can change my mind). —Aichon— 21:59, 5 June 2011 (BST)

Absolutely. Anime's proposal below for example is a much better solution than this and having that in policy would be a clear thing that users can see to know the discussion will be shared before making the request. I'm thinking the real disconnect here is his interpretation of the problem that caused the Iscariot drama, namely that there was dispute over whether a self-imposed time away from the wiki is a good enough reason. It wasn't so much about off-site requests as a whole but the fact that Iscariot was making one when he could have otherwise made it on the wiki. --Karek^{maps 2.0?!} 02:50, 6 June 2011 (BST)

Ah. I see your point now. Proposal has been amended. -- Spiderzed█ 14:08, 5 June 2011 (BST)

How about this wording instead: "For any administrative action, except where they are explicitly permitted to do otherwise, System Operators must not accept an off-site request from a user, nor an on-site request on behalf of a user, in place of an on-site request from that user." I was trying to cut off two (frivolous and dumb) arguments/loopholes with the rewording:

1. IRC User: "Please protect that admin archive." Sysop: "I would, but you requested it off-site, and policy says I can't 'carry out' any actions that are requested off-site."
2. Wiki User: "I'm posting this on-site on behalf of a user who asked off-site that this be done for them, which instantly makes it okay since the request is on-site."

Not sure if it handles everything without introducing new loopholes, but I'm tossing it out there for examination and scrutiny. And if you want to include AS' idea from below, you could easily tack on, "without first providing <whatever you want to require> on the appropriate administration page." The wording could easily go either way, depending on what everyone wants. —Aichon— 21:54, 5 June 2011 (BST)

Admin archives are scheduled before anyone else needlessly points that out. --Karek^{maps 2.0?!} 02:50, 6 June 2011 (BST)

To be clear, I was aware of that fact, which is why I chose it for the example. —Aichon— 03:08, 6 June 2011 (BST)

Requiring copy/paste of request

How about requiring the verbatim chatlogs or email copypasta's of the requests to atleast show the conversation surrounding the offsite request?--THE Godfather of Яesensitized, Anime Sucks ^{Yalk | W! U! WMM| CC CPFOAS LOE ZHU | Яezzens} 18:03, 5 June 2011 (BST)

I like the idea, but I can't think of how to make the logistics not suck. How much of the conversation is required? Do we c/p it to the admin pages and clutter them, do we make new admin archive pages to store transcripts and then link to them, or do we link to off-site copies of the transcripts stored at <INTERNET_COMPANY_X>, such as PasteBin? If we do the third one, which <INTERNET_COMPANY_X> do we choose to host the transcripts, and what do we do when <INTERNET_COMPANY_X> inevitably goes belly up, taking our transcripts with them, in a few years? Do we require taking note of the IP address of the requestor if they make the request via IRC, in order to verify their identity? If so, how do we record it in a way that preserves privacy while still being accessible only to the sysops? Same question, but with e-mail headers and the data contained therein. Basically, lots of details that might need working out, but if it can be made to work, I like it. —Aichon— 03:29, 6 June 2011 (BST)

ddr header

The reason I didn't vote on the other one was because I was still mulling over in my head what changes the policy would have actually made and the wording was a pain and all I could gather was that it wouldn't really change anything of the status quo of the situation in the parts I found important. it was withdrawn before I could eventually vote no on it.

Personally, ATM I don't see how this policy is going to fix anything. Right now, the sysops as a group have decided (in the one "serious vote" we made over this) that an off-site request can be made and followed through. It was also somewhat established that reversing it isn't misconduct even if the final result sees the items in question deleted eventually anyway. This is okay I guess, but if a policy is going to go through it's going to have to deal with many of the potential liability issues, proof issues, who's responsible, etc.

In fact this policy is the exact opposite thing we need TBH. I think what we should be having is a policy that explicitly states what is on and not. Preferably one that says sysops can/cannot make off-site requests. Depending on whether we still think they should be able to do it or not. Right now the consensus is a shakey but alright one, right now we don't have to follow through with such requests but someone can if they want to. I'd like some sort of burden of proof on the acting op to be made though in future, if a policy does go through. -- ϑ^anceϑ^anceℜ^evolution 12:27, 6 June 2011 (BST)

I'd rather…

Document and explore the ramifications of the status quo before making a hasty obvious rule patch. Have been mulling it over, and I think the idea of using a mailing list for sysop discussion and archiving of sensitive requests (like they do at Wikimedia) is probably the best way to go. Obviously, the best practice would be to post the request directly here, and in most cases that is going to be the best way to go, but let's not throw out the baby with the bathwater by ignoring that there can be legitimate reasons somebody cannot go via the regular process and seek to accommodate that as best we can without causing additional problems. ᚱᛁᚹᛖᚾᚨᚾᛏ 01:33, 8 June 2011 (BST)

Or install that wiki forum thing Jorm was working on. --Karek^{maps 2.0?!} 01:53, 8 June 2011 (BST)

Threaded mode discussion would be incredibly helpful, but addresses an unrelated issue. ᚱᛁᚹᛖᚾᚨᚾᛏ 01:49, 9 June 2011 (BST)

I'm thinking something like the following:

Sysops are not required to accept off-site requests for administrative actions. The preferred method for requesting administrative actions is always the respective administrative pages. However, some sysops may choose to make themselves available via more contact methods – in particular, most sysops can be reached via the “email this user” link on their user pages.

A request is in most cases analogous to a request made on administrative pages and is subject to all the same rules and strictures, including logging of actions taken, where possible. In addition, any action taken which requires special authorisation (such as author privileges) must have the requester's identity positively confirmed before action is taken. Failure to do so may constitute Misconduct.

Due to the public nature of the wiki, if a request is sensitive in nature, email is the preferred contact method. Be advised that emails may be forwarded to other members of the Administration team as required. At all times, the privacy policy should be adhered to.

As far as I'm aware, this documents and codifies existing practice and consensus, as a proper policy should. ᚱᛁᚹᛖᚾᚨᚾᛏ 01:49, 9 June 2011 (BST) I'd support Revenant's policy.--ShadowScope^{'the true enemy'} 00:19, 11 June 2011 (BST)

Sorry for not commenting earlier, but this week has been incredibly busy. As the main issue is accountability, and in connection with that privacy (such as e-mail adresses being out in the open), a closed mailing list only open to ops would effectively deal with both of those problems.
There would still be a slight privacy issue, since all the ops would learn the data associated with the off-site request (e-mail adresses, forums accounts etc.), but that is the problem of the lazy requester, not the problem of the wiki community. After all, if you really care about your privacy and really mistrust the op team, you can always just come on-site and file your request regularly, as you should anyway. -- Spiderzed█ 21:23, 11 June 2011 (BST)

Pretty much. We can always divulge email data publicly and keep the address/forum accounts hidden anyway without much issue, this'd be my preferred method tbh. If someone has a major issue with that though, again, they can always just come here and make a proper request. If this becomes allowed, it's going to have to be accepted eventually that those who CBF making it onto the wiki to make requests, are going to have to come to terms with people speaking on their behalf and sometimes perhaps quoting their requests or using other methods to validate the requests to the ops if requested, that may end up with their email address or forum account being circulated between the ops. If they don't like it? 10 seconds to ask for it on wiki. -- ϑ^anceϑ^anceℜ^evolution 08:52, 12 June 2011 (BST)

Perfect

... just the way it is.

• this conforms to the spirit of our current policies,
• anyone who wants pages, that they created, deleted can just ask here... just like everyone else,
• knowing a sysop shouldn't get you special treatment,
• allowing off site requests reduces transparency for no real benefit.

-- boxy 12:29, 12 June 2011 (BST)

It actually doesn't conform with what we already have, it goes directly against what we already have, but whatever.--Yonnua Koponen ^{T G P} ^^^ 21:33, 18 June 2011 (BST)

He said it conforms to the spirit of the current policies, not with what we already have, and he's right. The current policies dictate that all requests are to be processed through the admin pages (C7 by proxy being an exception, since it can start elsewhere on the wiki). What we have now doesn't conform with the spirit of the policies, since we've chosen to take a lenient stance on breaking those policies when it's in the best interest of the wiki. —Aichon— 21:43, 18 June 2011 (BST)

Actually, case precedent is, and always will be the rule of law where there isn't legislation, or where there is contradictory legislation which the precedent over-rules, unless the legislature over-rules it. The precedent is the law, and the spirit of the precedent is the spirit of the law.--Yonnua Koponen ^{T G P} ^^^ 22:25, 18 June 2011 (BST)

He said nothing about law or the way things are ruled (which would include precedent). He said "policies". I'm merely pointing out that his statement is correct, not that it accurately reflects the way that rulings are handed down (he never suggested it did). I'm arguing semantics, not the way things are (since I agree with you about how things are), and I'm not interested in arguing semantics any further since they're pointless. I just wanted to point out where I think that you misunderstood him. —Aichon— 02:44, 19 June 2011 (BST)

Yonnua is correct. The policies have always existed as a means to explain how a request can be made, not to actually limit them. Aside from that they, historically, serve solely as a guideline for how best to record actions taken. --Karek^{maps 2.0?!} 23:20, 18 June 2011 (BST)