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)

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)