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)

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)