Guild Wars Wiki talk:Arbitration policy

Maybe "injunction" should be explained further. Probably in more layman terms... I mentioned to Xeeron that I don't really understand the meaning of it, so I think others also may not. The Free Dictionary says:

1. The act or an instance of enjoining; a command, directive, or order.
2. Law A court order prohibiting a party from a specific course of action.

So, it's kinda like giving ArbComm (or individual bureaucrats?) the power to declare that certain users absolutely cannot do something and banning if they go ahead and do it anyway? And this only while an arbitration is being considered or discussed? -- ab.er.rant 09:56, 28 September 2007 (UTC)

Pretty much. The way this draft is currently worded, any individual bureaucrat could technically use it for whatever (even outright banning/de-sysop-ing) with no hard limitations. It is still part of "arbitration process" though and soft-limited by the Guiding Principles and the note that they should be limited to what is practically necessary. I've tried rewording it to make this clearer. They are also to be limited to while arbitration is being considered or discussed, but this is really only another soft safeguard that makes them easier to scrutinize (note that nothing strictly prevents bureaucrats from requesting arbitration themselves). --Rezyk 19:52, 28 September 2007 (UTC)

So...not much discussion going on here. Are you all still absorbing and thinking it over? --Rezyk 06:31, 2 October 2007 (UTC)

Well, a lot that is written there makes sense ... but why should it be policy? It shoves a big lot of procedure onto arbitration cases which might be useful, but at times might be not. Apart from that, I have my usual complaint that the first part is not enforcable at all ("General fairness") and thus should not be policy. --Xeeron 11:20, 2 October 2007 (UTC)

It should be made policy (assuming, of course, that it is fixed up to satisfaction) so that we have a more stable agreed-upon description of what we decide arbitration's role/powers/process should be. This would help all users better understand what to expect.

Do you think it would be more helpful/useful to users with less procedure? Why should something be enforceable to be policy? How is this fundamentally different there from behavioral restrictions like NPA? --Rezyk 06:31, 3 October 2007 (UTC)

I think it should be split into a policy proposal and a draft guideline. -- Gordon Ecker 06:52, 3 October 2007 (UTC)

Which part(s) do you feel don't fit as policy? --Rezyk 07:27, 3 October 2007 (UTC)

The more subjective or unenforcable portions of the guiding principles section. I also dislike the "very strongly warrented" line, as it gives trolls a great deal of leeway outside of both sysop and arbitration comitte jurisdiction, although it wouldn't be an issue if something about trolling or disruptive behaviour makes it into the blocking policy. -- Gordon Ecker 07:53, 3 October 2007 (UTC)

What's wrong with having those portions as policy? --Rezyk 22:17, 3 October 2007 (UTC)

For the "very strongly warranted" line, does anyone have a suggestion on how else to try capturing the sense of "arbcomm as a last resort only"? --Rezyk 22:48, 3 October 2007 (UTC)

What about "strongly warrented" or "clearly warrented"? -- Gordon Ecker 02:19, 4 October 2007 (UTC)

I changed it to "strongly warranted" and added a bit about "last resort". --Rezyk 18:33, 4 October 2007 (UTC)

Sounds good. -- Gordon Ecker 06:59, 5 October 2007 (UTC)

The Arbitration Committee, shepherds of the flock

"I would much rather get a clear statement from ArbComm as to whether such behavior is something that is acceptable on the wiki now, than to wait until it becomes unbearably disruptive later. --Aiiane 21:59, 20 September 2007 (UTC) "

I'll make this short, since I've recently been starving for sleep: I disagree with anyone having such expectations from the ArbComm. I think the goal of this group should be to simply decide if they believe there is a problem in each individual case, and to recommend solutions that can help alleviate those problems. I don't think it should be up to the ArbComm to be the community's mariner's compass or friendly neighborhood preacher or anything of the kind.

By the way, I'm not even sure if you really meant it that way or if it was just the wording, Aiiane, so don't read this as being a response to your comment specifically. I just think it's an important point that deserves to be made clearly if the community agrees with it, or to be discussed further if there's disagreement. --Dirigible 06:46, 6 October 2007 (UTC)

I agree. The ArbComm is supposed to deal with individual disputes, incidents and users. Hard rules are the domain of policy, and soft rules are the domain af guidelines. -- Gordon Ecker 07:19, 6 October 2007 (UTC)

Generally like the proposal as it stands, but the NPA examples are a problem; they give the impression that ArbComm can rewite policy as they see fit. I'd think policy is above ArbComm. Else they'd have no mandate. Backsword 13:48, 14 October 2007 (UTC)

Which piece of policy do they appear to rewrite? --Rezyk 09:01, 15 October 2007 (UTC)

They're governed by policy like everyone else, but the adminship policy gives arbitration comittees the authority to deal with user conduct. -- Gordon Ecker 09:38, 15 October 2007 (UTC)

Which piece of policy do they appear to rewrite? Can you explain more specifically about what it means for policy to be above ArbComm or ArbComm to be above policy? I might agree or disagree with some of the implications, but so far it is a bit too abstract for me to grasp/address properly. --Rezyk 08:17, 27 October 2007 (UTC)

Do you feel the NPA examples read as usurping GWW:NPA policy as a whole? I put in one as an example of ArbComm possibly interpreting some of the ambiguous regions of NPA. The other is ArbComm executing part of the "consequences" section of NPA. I'd read both as falling within policy, not contradicting/extending/ignoring it. --Rezyk 08:17, 27 October 2007 (UTC)

With the "above" comment I mean that in a stuation where a considered and documented consensus obtains, as with a polcy, ArbComm should follow it. Eg. if a policy explicitly states that X is allowed, but Y is disalloed, then no one should be punished for doing X, or allowed Y by ArbComm decision.

"interpreting" is just the sort of thing I'm worried about, as in US juridical discourse it means legislate. Something I don't feel is the intention with ArbComm. Backsword 07:08, 2 November 2007 (UTC)

The "Respecting community consensus and established practices" could be expanded to "Respecting community consensus, existing policy and established practices". If that's insufficient, something along the lines of "rulings shall not contravene existing policy, any ruling which contravenes existing policy shall be considered invalid". -- Gordon Ecker 10:07, 2 November 2007 (UTC)

Stare decisis

(regarding Backsword's concerns)
I suggest that the root issue may be better understood in terms of the different roles of "interpretation" between common law systems and civil law systems. Under a common law system, interpretations create case law (minor nitpick: really not "legislating" as it is non-statutory law) and we want to avoid the equivalent of case law usurping the role of legislation. On this axis, our model should tend towards following the theory of civil law systems instead, where interpretations do not create case law.

I think that the principle of "the wiki being generally managed by the community" already pushes somewhat against the creation of case law equivalents and against ArbComm disregarding policy, but we can be more explicit. To this end, I applied Gordon's first suggestion and also spelled out that rulings are not to be taken as binding precedent. I thought about how to change the NPA example, but I tend to already see it as well-oriented towards a non-case-law-like ruling. Compare:

1. Behavior XYZ (which User:Example has been doing) is to be considered a violation of NPA.
2. User:Example has been found to have repeatedly violated NPA.

The first one exemplifies a ruling creating case law and possibly expanding its scope (namely, that XYZ is now "illegal"). The second one is much more limited in scope, generally only pinpointing the specific case in question.

Does this address/alleviate your concerns enough? If you think we need to go further, I have at least 2 concerns:

• Statutory interpretation seems like one of the important functions for ArbComm in their role in settling things. What if we had a case where half of users think that a user's conduct should be considered personal attacks, half of users think that it should not, AND everyone generally agrees it is important to decide/resolve expediently?
• I balk at anything that might imply that ArbComm should adhere to policy strictly, because they should be able to cut through loopholes and such. So I prefer softer wording like "respect policy". This isn't perfect of course (and I worry that we may have issues with users too quickly taking their own interpretation as the spirit of a policy), but still.
  

Disclaimer: I am not saying that we should create or rigidly follow any legal system here.
--Rezyk 22:56, 6 November 2007 (UTC)

You make some interesting points. Let me first explain that I find applying the distinction common/civil law to modern systems to be artifical nonsense, so that's not how I think about things.

In cases of ambiguous policy, it is preferable if this is brought to the community's attention and fixed before it becomes an issue. That will not always be posible, so it will be one of the functions of ArbComm to decide how to rule here. I actually think precedence would suit us here; it seems in line with our janitorial system to reduce the range of discretion for SysOps first. I suspect that they will be used as such whatver we put in policy; it's an effect you find in most continental juridial systems. Remains to define principle for how ArbComm should decide here. I took literalism for granted and sought to make that binding, but you seem to prefer a "mischief" stance. I find that problematic in the context of a consensus operated body. Being a non oppose rather than support system there simply exist no single intention or even a guarantee for a majority view. ArbComm would have to settle for the type view. (Which also brings up the topic of what standing talk pages have in general.)

The other side is that ArbComm is both more and less than a court. Primary among it's duties are handeling disruption and user conflicts that fall outside policy. Stare decisis would obvious be the same as legislating here but I don't see that as an issue; Admin policy makes clear SysOps may only uphold policy. A thing about the changed text here: There won't be policy to follow by definition, so does including "consensus" in the policy text give guidelines equivallent status here?

That said, I wouldn't mind seeing the policy implemented as it now reads. My primary concern of issues arissing in using it has been adequately covered.

Backsword

The problem I have with stare decisis is that it would allow the rulings of former bureaucrats to restrict the options of current bureaucrats, as well as scattering GuildWiki's rules over dozens of arbitration pages. -- Gordon Ecker 03:47, 9 November 2007 (UTC)

Seems like I addressed the wrong issue; sorry about that.

• Regarding which method of interpretation to use: I'd rather not bind us into literalism (textualism?), or the Mischief rule, or any particular school of thought.
• Yeah -- it isn't that there would/should not be any precedence effect at all, just not to the level of stare decisis.
• The guidelines aren't supposed to be taken as consensus. (But if consensus at that time is to follow the guideline for that case, that should still be respected as a matter of respecting consensus.)

--Rezyk 00:28, 11 November 2007 (UTC)

I don't actually think any other school is viable, so it's not an issue for me. But it would be interesting to hear from the current ArbComm what they'd actually do.

As for guidelines, they do represent a sort of concensus, but are intended to be general ones that you can override in any specific case if so needed. That's why I wanted it to be clear, since it would seem specific cases is exactly when ArbComm will run into such issues. That is, ArbComm is not deciding on the general case. Backsword 11:33, 11 November 2007 (UTC)

Thoughts

Some food for thought...note this line: The committee can also take other cases in general when the community wishes them to (with an explicit consensus). So if we had, say, some content decision where we could not make a unified choice, but we generally agree that a decision should be made, and ArbComm accepts the case, ArbComm may end up doing a content decision. It might not be related to user conduct at all. This might even happen against the wishes of a bureaucrat, since neither consensus nor case acceptance need be unanimous.

For ArbComm, the principles should still be involved in this decision, but they may push in different directions. "Wiki stability", for example, would probably tend toward accepting the case (depending on how important it was to have a decision) while "the wiki being generally managed by the community" may push against it.

Is this acceptable? Or too much power? Consider that a content decision might be stuff like comment removal, fixing a policy wording, or a builds wipe. I expect that the requirement of an explicit consensus from the community should make this benign enough, but who knows... --Rezyk 02:32, 26 October 2007 (UTC)

I think it's fine as long as those content decisions can be overturned with concensus and requests for arbitration on content issues can limit options (for example: "Reversion policy proposal A and reversion policy proposal B both have strong support, but are mutually exclusive, choose one."). -- Gordon Ecker 04:54, 26 October 2007 (UTC)

That would be no different from a consensus that any random group of three users should decide. Would be fine, but I don't see it happening. There would only be such a consensu if people think they can predict the oucome, and it is acceptable to them. But if so, the consensus can just settle on that outcome. Backsword 21:54, 26 October 2007 (UTC)

Or a concensus that all of the possible outcomes are acceptable, and are preferable to further delays. Of course, this only applies if the arbitration comittee's choices can be restricted in content-based arbitration requests. Bureaucrats seem like the most appropriate people to serve as the official tie-breakers. -- Gordon Ecker 23:58, 26 October 2007 (UTC)

Support? Oppose?

I'd like to get an overview of general opinion of this. Please respond, everyone, with a note about whether you support or oppose this proposal as policy -- preferably with a short explanation if you oppose (put any long explanations in another section, please). This is not meant as a vote, but as a measure of where we stand relative to consensus. --Rezyk 19:30, 26 October 2007 (UTC)

Support. --Rezyk 19:30, 26 October 2007 (UTC)

I vote no. To the poll that is. Don't see how it's helpful. What needs to be asked is 'Any remaining concerns?'. I'd still like ArbComm not being above policy made explicit, btw. Backsword 21:54, 26 October 2007 (UTC)

*grumble* That is not quite right, but whatever. --Rezyk 08:17, 27 October 2007 (UTC)

I dislike the word "recuse", but that is a minor point not taking away from my general support of this policy. --Xeeron 14:55, 13 November 2007 (UTC)

How about "abstain"? If not, how about more of a hint why. =) --Rezyk 00:08, 14 November 2007 (UTC)

Hmm..the main thing I don't like about "abstain" though, is that I think it has more of a connotation of just refraining from that vote, rather than also from participation within the case. --Rezyk 00:12, 14 November 2007 (UTC)

After some more thought, I agree with switching off "recuse" wording myself. I'll edit the draft; see what you think. --Rezyk 01:05, 14 November 2007 (UTC)

I am ok with the new wording. Just to point out why I disliked recuse: It has a connotation of the recusing member being somehow personnaly involved in the case at hand, but arbcom members might want to abstain for other reasons, despite no personnal involvement. --Xeeron 15:12, 14 November 2007 (UTC)

Too fearful to function

My concern is, If ArbComm has to follow policies , guidelines and "community consensus", what's the use for it? It's the last resort, so if an issue reaches the ArbComm, is because policy and such didn't covered it.reanor 15:15, 13 November 2007 (UTC)

We're not seeking to bind all their judgments to be within stuff covered by policy. This draft even states that arbitration is generally not limited to addressing policy violations. (Also, guidelines do not have that status of have-to-be-followed.) --Rezyk 00:08, 14 November 2007 (UTC)

Alright, it's ok then.reanor 00:13, 14 November 2007 (UTC)

Arbitration and unblocking

If arbitration is brought against someone, should they be unblocked to make their case? If so, should their edits be restricted to the arbitration talk page, and should they be re-blocked if they make edits elsewhere? Should the block be reinstated after the arbitration is resolved and does not overturn the block? -- Gordon Ecker 04:20, 18 November 2007 (UTC)

Currently this would be up to injunctions to deal with. Is there a need to standarize? It would seem just to allow all parties to have a say.Backsword 04:22, 18 November 2007 (UTC)

Would unblocking be within the scope of injunctions? Real-world injunctions take the form of obligations and restrictions, while temporary unblocking sounds more like bail. -- Gordon Ecker 04:34, 18 November 2007 (UTC)

Unblocking would have to be done by a SysOp, as only they have the right. Injunctions would limit his actions once unblocked. Backsword 17:42, 18 November 2007 (UTC)

I've also expanded the wording for injunctions in this proposal to include "appropriate in facilitating arbitration". --Rezyk 20:51, 19 November 2007 (UTC)

I suspect that blocked users can generally still edit their own talk page. If that is true, it may be simplest to have the blocked user post their input there (and others can move it to the arbitration page for them). --Rezyk 07:09, 18 November 2007 (UTC)

Can we test that theory? It'd make sense if it worked. -Auron 07:16, 18 November 2007 (UTC)

Sure, if we can get a volunteer. -- Gordon Ecker 08:06, 18 November 2007 (UTC)

--> -Auron 08:24, 18 November 2007 (UTC)

Done. -- Gordon Ecker 08:37, 18 November 2007 (UTC)

Auron says: "http://img522.imageshack.us/img522/6558/blocktestingzj3.jpg" -- scourge 08:44, 18 November 2007 (UTC)

He's unblocked now. Too bad it didn't work. -- Gordon Ecker 08:45, 18 November 2007 (UTC)

He says you have to unban his IP please -- scourge 08:50, 18 November 2007 (UTC)

Try using Special:IPBlocklist -- scourge 08:51, 18 November 2007 (UTC)

Ta. -Auron 08:55, 18 November 2007 (UTC)

(Reset indent)

Too bad that didn't work. Does anyone know which MediaWiki setting or extension is needed to enable users to edit their own talk pages while blocked? -- Gordon Ecker 08:58, 18 November 2007 (UTC)

As I posted on Raptor's arbitration article, I think unblocking in this instance makes sense, provided we limit that user to only post on their arbitration article. I really think this is more akin to letting someone out of jail to attend a court hearing, as opposed to just letting them out on bail. What do you think? LordBiro 11:52, 18 November 2007 (UTC)

Found it: $wgBlockAllowsUTEdit needs to be changed. In the meantime, I agree that we might as well temporarily unblock Raptors with that condition. --Rezyk 17:21, 18 November 2007 (UTC)

Active

If this is resolved and there are no further issues, I think we ought to move this into effect tomorrow. Backsword 06:38, 23 November 2007 (UTC)

Doing so now. Backsword 03:57, 25 November 2007 (UTC)

General Process - Steps 4 and 5

A bit of nitpicking, but anyway: step 4 is supposed to happen when the ArbComm request is accepted by the bureaucrats, and is a step in which the community is free to add arguments and its opinion. What about the next step? I thought step 5 was for the bureaucrats (and only the bureaucrats) to discuss among themselves in order to reach a conclusion. As things are currently happening in the Raptor's ArbComm, steps 4 and 5 have mostly been fused - we have users giving their opinion on what should be done both in what would be "step 4" (everything above and including the "Lack of arguments brought forth here" section) and in what would be "step 5" (the "Decision discussion" section).

I think that's a bit redundant, as the community theorically would already have had its say, and it feels like users are acting in the decision making stage as if they were bureaucrats themselves. I would like to propose one changes: that no one but bureaucrats would be allowed to act on step 5, so no edits would be made to the "Decision discussion" (or about that section) by anyone who's not a bureaucrat, until a decision between bureaucrats is reached. Then users would be allowed to comment on it (that's more or less what happened on the Skuld ArbComm, for example).

(One way to make this clear would be by having the "Decision discussion" to happen in the ArbComm page itself, and not in its talk page.)Erasculio 12:25, 27 November 2007 (UTC)

Well, I was previously in support of the bureaucrats discussing amongst themselves outside of this wiki and then provide either a transcript or summary of their discussion once they've reached a decision. They could try to move the talk in a not-so-obvious subpage but I'm thinking that as long as it's on the wiki, someone will find it and comment on it. Hmm... what if we protect the talk page that the bureaucrats discuss on? (and making sure no sysops intervene of course). -- ab.er.rant 12:31, 27 November 2007 (UTC)

We discussed the ways of comming up with the final decision on User talk:Dirigible#Arbitration case erasculio. I don't see the rationale behind discussing it on the wiki, but not allowing others to comment. There are some advantages to discussing it amoung the bureaucrats only, but those would be bigger if the discussion is done privately in emails. In any case, I feel that discussing on the wiki and thus allowing others to comment is the slightly better solution.

Or maybe let me put it like this: When I read that section, I take into account any comment made, however, the ones that matter in the end are those by bureaucrats. The bureaucrats can use the comments in their draft, but the solution is reached by a consensus among bureaucrats, not by a consensus amoung all participants in the discussion. --Xeeron 17:05, 27 November 2007 (UTC)

Revision

I plan on writing up a revision proposal for this policy. I believe that we should explicitly state that injunctions can immediately suspend sysop status in emergency situations (compromised account, rogue sysop on a banning / deletion spree etc.). I think the simplest option would be to add the following example to the rulings and enforcement section:

• User:Example's sysop status is suspended immediately pending reconfirmation.

I'd like this to be a quick, minor, non-controversial revision which can be passed before Guild Wars Wiki talk:Adminship/draft B, does anyone have any comments or suggestions? -- Gordon Ecker 00:05, 16 April 2008 (UTC)

Your suggested wording looks good to me. --Rezyk 00:49, 16 April 2008 (UTC)

Sure, it's no change of policy, just an additional example. Just go ahead and do it. Backsword 02:32, 16 April 2008 (UTC)

Support. --Xeeron 09:44, 16 April 2008 (UTC)

Sure, good idea. *Defiant Elements* +talk 13:46, 16 April 2008 (UTC)

A minor thing, just a clarification imo, so no problems. - anja 17:19, 16 April 2008 (UTC)

Implemented. --Rezyk 18:28, 24 April 2008 (UTC)

Block appeals: the final arbiter of user conduct on this wiki?

If the arbitration committee is "the final arbiter of user conduct on this wiki" and "can impose binding solutions for such issues when requested by anyone", aren't block appeals within their jurisdiction? If this conflicts with community consensus, shouldn't policy be revised to reflect the new consensus? -- Gordon Ecker (talk) 06:59, 6 January 2010 (UTC)

As I see it, Arbcom can overturn blocks. However, that does not imply that they are the only ones who can do so, not even that they are the usual way of doing so. Implicitly, right now the block appeal can go to any sysop and is likely determined by discussion with that sysop, the original blocking sysop, and possibly other sysops.

One of the advantages we have is that we are still small enough, that every sysop at least somewhat knows every other sysop. So usually such discussions can be handled informally. --Xeeron 13:45, 6 January 2010 (UTC)

Gordon, does this question result from the declination of (or provided reasoning for the declination of) Lena's ARBCOMM? -- FreedomBound 13:49, 6 January 2010 (UTC)

Block appeals are within the BC's remit and also within a sysops. It's due that review by a BC on a block is considered a higher review and ultimately above question. -- Salome 14:24, 6 January 2010 (UTC)

People are free to contest an arbcomm ruling... they are just difficult to overturn. ;) Vili 点 17:43, 6 January 2010 (UTC)

This isn't about Uchiha Lena, this is about clarifying the block appeal process. Out of the five bureaucrats who have served while a case against a permabanned account, I have been the only one who chose to accept the case. Everyone else has chosen to defer to the sysops. If the authority to handle block appeals is supposed to be shared between sysops and bureaucrats, I think that we should mention that shared authority in one of our policies or guidelines. -- Gordon Ecker (talk) 03:34, 7 January 2010 (UTC)

I think we can all agree that, generally speaking, arbitration is reserved for cases that cannot be handled except by arbitration. As such, I should think that while block appeals do fall under the purview of the arbitration committee--really, aside from content decisions, what doesn't fall within arbcomm's jurisdiction?--, if the review in question can be handled by the sysops (i.e. if there's consensus among the sysops and there's no evidence of some kind of misconduct), then I don't think arbcomm should be getting involved. With that said, I don't think we need to explicitly define the manner in which sysops and arbcomm share responsibility for block reviews, which are, in of themselves, discretionary. — Defiant Elements +talk 04:10, 7 January 2010 (UTC)

But right now, no policy or guideline even mentions the possibility that block reviews might be within sysops' jurisdiction. -- Gordon Ecker (talk) 07:47, 7 January 2010 (UTC)

And no policy or guideline mentions that it is not possible. Stop thinking that everything what is possible needs to be written down to be actually possible; that only makes the law more complicated than it actually is. poke | talk 09:58, 7 January 2010 (UTC)

I agree that policy creep can become a serious problem if left unchecked, however IMO an outline of who has jurisdiction over block appeals seems like one of those things which probably should be written down. -- Gordon Ecker (talk) 13:13, 7 January 2010 (UTC)

"no policy or guideline even mentions the possibility that block reviews might be within sysops' jurisdiction" - funny how that didn't stop you. Regardless, sysops have been given discretion of using the tools available to them (which include both blocking and unblocking) "whenever he or she believes it would be supported directly by community consensus". A sysop who notices that consensus after a block was to undo said block would be within his right to do so, as already made clear by the existing policy; a sysop who has discussed a block with its author and led the community to a consensus in which said block should be undone could do it himself/herself as already made clear by the existing policy. In other hand, a misguided sysop who's against removing disruptive users from the wiki and would like to ignore consensus in order to undo as many blocks as possible through as many wiki loops as possible cannot remove any block, as already made clear by the existing policy. Therefore, the current policy is fine, without any need for additional outlines. Erasculio 13:31, 7 January 2010 (UTC)

Eras may I just say "WUT?", honestly not sure what you are talking about. Policy on unblocking has nothing to do with community consensus, it is solely to do with sysop discretion. It is only manners and custom which makes us a group seek consensus with the other sysops before unblocking.(which is a good thing to do, I hasten to add) Further to that, just to make you aware that almost every post you make in relation to this is coming across as quite aggressive. If you do wish to be a sysop, maybe being a tad more objective and getting your point across without slinging about terms like "funny how that didn't stop you" and "misguided sysop". Terms like that don't add to the debate and ultimately can just lead to flaming. (I should know I've strayed into that territory myself in the past and nothing good ever comes from it) -- Salome 15:41, 7 January 2010 (UTC)

The opposite, Salome. Sysops' discretion is meant to follow consensus; the entire sentence I have quoted above, from the Adminship policy, states how sysops are allowed to use their tools "At their own discretion, whenever he or she believes it would be supported directly by community consensus (regarding the specific change/action)". Do you see what this means? Whenever a sysop blocks or unblocks an user, it's not because he/she thinks it's the right thing to do, rather because he/she thinks it's the right thing to do per the existing consensus. That's obvious if you consider what would happen if a new sysop decided to randomly block users, thinking it's the right thing for the wiki; would you expect such action, clearly against the consensus, to be held as part of sysops' discretion, or do you believe it would be challenged?

In other words, what you see as courtesy is just a sysop doing what he/she has the obligation of doing: all the sysops are here to serve consensus, and thus, if two sysops have different opinions, instead of undoing each other they have to figure out what is the consensus around that decision. This isn't etiquette; this isn't good manners; this isn't custom; this is the description of what the sysops have to do, based on our current sysop policy (and on what is logical, as well).

Gordon's misguided crusade against blocking users is effectively going against the role sysops have here, both by weakening them (as the sysop's decision of blocking someone could be undone at any time) and by twisting the role of sysops (as seen in the mess he's trying to make around the role of bureaucrats and sysops on this). All this is going to accomplish is to disrupt the wiki; if you think I'm being agressive by pointing this, so be it. It would pointless for me to become a sysop if to do so I had to stay silent instead of complain when someone does something disruptive. Erasculio 16:00, 7 January 2010 (UTC)

That is indeed the case Eras but that doesn't mean we are supposed to go and consult the community first before unblocking someone. It just means that the motivation behind our actions should be that we believe the community would agree with us if we did it. It doesn't mean we have to go "hey community I want to unblock someone, you all okay with that?" EDIT: this stands for blocking people too and we don't block by committee either. It's how the policy has been interpreted since it's inception, that we admin in the best interests of the wiki and in the belief that our actions would gain the consensus of the community if put up to the test, it does nt mean that the blocking sysop and the sysop wishing to retract the block, must come to a consensus beforehand, although it is advised. In regards to your final point I would also just like to say, that it is not your viewpoint which I have an issue with, it is how you are trying to get it across. One can disagree without being aggressive about it. However I see that the comments made on the oppose side of your RFA have not been heeded, I truly do hope you learn from them in the future as I think if your somewhat combative communication style could be more balanced, you would make a great sysop. :( -- Salome 16:02, 7 January 2010 (UTC)

Salome, I agree with you in that I don't think sysops have to ask the community before doing anything; they already have, which is what the RfAs are about. Sysops, by being chosen sysops, are already those who know what the consensus is; which is why they don't really have to ask for people's opinions. However, when a sysop disagrees with each other, that system hits a wall: we have two users who, following consensus, are reaching different goals. What the sysops have to do, then, isn't do what each of them think is right (in other words, undoing a block, or reapplying a lifted block), but rather to figure out what would consensus rule. They don't really have to ask anyone other than the two sysops involved, but they can't just ignore consensus and do whatever.

Which, incidentally, is one of the reasons why the appeal system proposed by Gordon doesn't work. When a sysop blocks an user, the sysop is backed by the community (who, after all, has chosen him as a sysop), and the user isn't. If the user complains, his complain should not have the same weight as the decision of the sysop; the sysops are chosen exactly as those who have a better grasp on the sysop roles (which includes blocking people) than common users. In other words, an user should not be able to trigger the entire appeal process just by requesting it; he should have first to convince a sysop that his ban was not proper, and only then, if he manages to do so, the entire process should happen. The problem here is how even that would not work - Gordon is clearly against blocks, so any user who complained to him would be able to trigger the entire appeal process, regardless of how proper the ban had been. Erasculio 16:28, 7 January 2010 (UTC)

I'm not against blocks, I'm against the unilateral permabans of non-throwaway accounts. I think that sysops should primarily be responsible for damage control and short-term solutions, while, in all but the most clear-cut cases (vandalbots, obvious sockpuppets, accounts used solely for abuse etc.), serious punishments and long-term solutions for serious misconduct should be handled by the arbitration committee. When the arbitration policy got passed, that's how I believed the system was going to work, and I was shocked when, late into my term, two other bureaucrats refused to carry out what I believed was one of the major duties were all elected to perform: formally evaluate and provide long-term solutions for serious user minconduct. As for my block reviews, three of the five unblockings had explicit consensus support, and one of the other two had implicit consensus support due to its' similarity to one of the other three, one was a mistake and all five are proof that sysops aren't infallible. -- Gordon Ecker (talk) 03:49, 8 January 2010 (UTC)

...Which makes it clear how you are going against consensus, Gordon. If the other bureaucrats have a different opinion, if the sysops who have been blocking users have a different opinion, and if people are telling you here they have a different opinion (as seen a few paragraphs above and a few paragraphs below), it's clear your view of how blocking should work is not shared by consensus as a whole.

It also brings an interesting question: if you think sysops should not permanently block users, and if the admin policy is changed to explicitly say sysops can unblock users, would you just unblock everyone who has been permanently blocked? Erasculio 10:33, 8 January 2010 (UTC)

What do you mean by explicitly saying sysops can unblock users? As for a policy change which would explicitly permit sysops to lift blocks, if it was just a generic "sysops can lift blocks as they see fit, regardless of consensus, with no obligation to discuss the decision in advance" (I interpret the current policy as authorizing sysops to lift blocks as long as they realistically expect future consensus support, I stopped setting blocks to expire when I stopped expecting future consensus support), I'd set some of the permabans to expire, while leaving the permabans on obvious throwaway accounts and any permaban supported by an arbitration committee ruling in place, and would push to get the reversion policy extended to cover blocking and unblocking. If someone else decided to restore their previous durations, I would not shorten the same blocks a second time. If it became clear that no one was going to reinstate the blocks, I would leave messages on the accounts' talk pages to inform the account holders that their blocks are about to expire, and warn them. If an unblocked account was used for miscounduct and I got to it first, I would reblock it myself, probably from a month to a year depending on the severity of the misconduct. Once a block got lifted and stayed lifted, I'd stop being proactive, since the lifted block would prove the existance of a viable block appeal path. I would also stop being proactive if I was satisfied with the wiki's blocking guideline or block appeal process. In any case, I would not violate policy, and, when practical, I would try to work within the system. -- Gordon Ecker (talk) 12:18, 8 January 2010 (UTC)

So you would allow all (the few, actually) disruptive users (who were so disruptive to the point of being banned) who have been permanently blocked to come back, regardless of how most of them have not asked to come back or given any sign of having changed or given any sign of being willing to actually contribute to the wiki?

Gordon, do you really believe doing that would improve the wiki in any way? Would that allow us to better document Guild Wars in any way at all? Erasculio 12:28, 8 January 2010 (UTC)

Other sysops have allowed users far more disruptive than some of the currently permabanned users to return by only blocking them temporarily instead of permanently, do you object to that practice? I'd like to point out that the community probably wouldn't support a policy explicitly permitting sysops to lift eachother's blocks without prior discussion unless they actually wanted sysops to lift eachother's blocks without prior discussion. I'd also like to point out that, in such a scenario, the delayed block expiration would give other sysops an opportunity to lengthen the blocks to whatever duration they feel is reasonable before they expire, so the expiration of such a block would indicate that none of the active sysops disagreed with the block expiration strongly enough to prevent it. -- Gordon Ecker (talk) 03:45, 9 January 2010 (UTC)

"do you object to that practice?", of course. Those other users you described should have been permanently banned, too.

"I'd like to point out that the community probably wouldn't support a policy explicitly permitting sysops to lift eachother's blocks without prior discussion unless they actually wanted sysops to lift eachother's blocks without prior discussion", and given how the community is currently not supporting such a policy (as seen here and in some other pages), the likely conclusion is that the community does not want sysops to behave in such way. Which only makes sense: your proposed system, in which a sysop would undo blocks and wait to see if his revert of the block would be reverted by anyone who didn't agree with, is basically like breaching GWW:1RR. Users, be them sysops or anyone else, are not expected to keep reverting things and hoping no one disagrees with it; we are expected to discuss things we don't agree with in order to reach a consensus, and then act through that consensus. That's how the current appeal system works, since that's how the wiki as a whole works. Erasculio 11:01, 9 January 2010 (UTC)

I'm not advocating such a system. You asked me what I would do if "if the admin policy is changed to explicitly say sysops can unblock users", I made a guess about what you meant by "explicitly say sysops can unblock users", then extrapolated a hypothetical scenarios based on your premise. Such a scenario is unlikely to come about unless the community supports BRD-style admin interaction. -- Gordon Ecker (talk) 05:10, 10 January 2010 (UTC)

You are not advocating it, but isn't that the system you would like to have, in which you would be free to unblock users without any interference of the blocking sysop? Likewise, don't you support a BRD-style admin interaction yourself? Erasculio 10:42, 10 January 2010 (UTC)

Actually, Gordon, I would argue that, implicitly at least, GWW:ADMIN as written confers on sysops the responsibility of reviewing blocks in so far as unblocking is one of the "restricted features" that they're granted. I think there's an understanding that if we're giving them the power to block, then we're also giving them the power to unblock as per the clause pertaining to sysop discretion. With that said, if all you're advocating is that we add a sentence to ADMIN that explicitly states that sysops are allowed to review blocks, I wouldn't have any problem with it seeing as how it would merely be a codification of our existing policy. — Defiant Elements +talk 20:10, 7 January 2010 (UTC)

Or a sentence that says they're not allowed to review blocks, or are only allowed to review their own blocks, or can review the blocks of any sysop who dosn't object. Pretty much anything that clearly answers the question. The way I interpret it, the current adminship policy implicitly authorizes sysops to review blocks, however the "final arbiter of user content" line in the arbitration policy gives arbitration committees a far stronger block review mandate. -- Gordon Ecker (talk) 03:49, 8 January 2010 (UTC)

I think it is totally obvious that sysops are able to unblock. Not only because it's part of the "restricted features" as mentioned in the adminship policy, but also because everybody who gets blocked is told to contact the blocking sysop or another administrator per MediaWiki:Blockedtext. The only one who is questioning that is you Gordon, and I really don't get why.. poke | talk 06:34, 8 January 2010 (UTC)

I'm with poke here. Are you looking to add an explicit mention of block review? For example "including deleting pages, blocking users, and reviewing blocks"? -- ab.er.rant 07:56, 8 January 2010 (UTC)

There seems to be general consensus that requests for block reviews should be directed to the blocking sysop first (it's not clear if this is the original blocking sysop or the sysop who last modified the block). After that, things are less clear. Should sysops review eachothers' blocks? Should they be permitted to unilaterally overturn blocks? If not, how many should be needed to form a quorum and adjust or overturn blocks? When is it appropriate for the arbitration committee to make a decision about whether to, endorse, modify or lift a block? Should they be willing to overrule sysop consensus? Should they only take cases the sysops don't want to handle or can't resolve? I don't think that any of those questions has an obvious, intuitive answer. -- Gordon Ecker (talk) 11:12, 8 January 2010 (UTC)

IMO,

1. "Should sysops review eachothers' blocks?": of course. That's not new, either; whenever a sysop disagrees with another about a decision, they have always been free to discuss it between each other and try to reach a consensus. This applies to anything, no reason it should not apply to blocking or unblocking people.
2. "Should they be permitted to unilaterally overturn blocks?": no, at least not without discussing it before. A sysop doesn't do what he/she thinks is right; he does what he/she believes consensus would support. If two sysops have different opinions regarding consensus, they shouldn't try to "out-sysop" each other, rather discuss it with each other to find out what consensus really is. This isn't new; it's the same principle behind our behavior when two users disagree about the content of an article. Do we tell such users to just revert each other (eventually breaching 1RR), or do we ask them to discuss the matter and find consensus?
3. "how many should be needed to form a quorum and adjust or overturn blocks?": as many as it takes to reach a consensus (which is not the same of voting, for the records). Isn't that how many decisions are taken in the wiki?
4. "When is it appropriate for the arbitration committee to make a decision about whether to, endorse, modify or lift a block?": DE and Aiiane have answered that; when it's a matter of sysop malconduct. Isn't that how ArbComm works? Bureaucrats aren't expected to overseer and question every decision the sysops make; they only act to undo the decision of a sysop when there has been evidence of sysop malconduct and no consensus can be found within the sysops. This already applies to everything, including blocks and unblocks.
5. "Should they only take cases the sysops don't want to handle or can't resolve?": that's how it is. As seen on current and previous ArbComm requests, bureaucrats have stated (and the community has accepted it) that there is no point in bureaucrats trying to solve a case that is just sysop matters. Again, it's not something new; that's how the wiki has been working for a long time.

Gordon, all your questions had already been answered before you asked them. You may not like the replies, but they were there already. Erasculio 11:38, 8 January 2010 (UTC)

"I don't think that any of those questions has an obvious, intuitive answer."

None of them have particularly intuitive answers, but all of them have obvious answers. Just look around. Look at how we do things. Apply the same mindset to unblocks and your questions are answered before you asked them. Consensus drives the wiki, revert(/wheel) warring is bad, not everything has to be explicitly written into policy, and ArbComm is for arbitration, not undoing sysop actions. This stuff is old news. -Auron 11:58, 8 January 2010 (UTC)

Do they? Would an average user expect the information to be buried on some rejecting arbitration request page? How long do you think it would take someone to find it without knowing where to look? -- Gordon Ecker (talk) 12:32, 8 January 2010 (UTC)

Gordon, there is no buried information average users would have to find. Blocked users are told per the blocking notice to contact an administrator if they would like to discuss the block, and that's all they have to do. The sysops have to know they need to discuss things with each other instead of just hitting "revert", "revert" and "revert", but then again that's how we do everything in the wiki (and even average users who bother to edit articles are expected to know about GWW:1RR, which is the same idea). Erasculio 12:37, 8 January 2010 (UTC)

Exactly, and we can expect sysops to know how it works, otherwise they would not be appointed in the first place. And even if they don't know, they will learn quickly and ask if they aren't sure; sysops are no idiots that just hit a button when they disagree, those candidates are sorted out via the RfA. poke | talk 15:31, 8 January 2010 (UTC)

Okay, let's test that theory. If someone you blocked sent you an email saying "I'd like to appeal my block, what should I do?", how would you respond? What about if the email was from someone blocked by another sysop? Last month, my response to a request to appeal or lift another sysop's block probably would have probably been a more concise version of "If you can't convince the original blocking sysop to lift your block, you should probably request arbitration, since traditionally, an arbitration committee is the closest thing a wiki has to a court, and our arbitration policy heavily implies that arbitration is the way to go when all other appeals have failed, and that's how things work on Wikipedia, which much of our policy structure is modelled after.", today, my response would probably be something along the lines of "Unfortunately, if you can't convince the original blocking sysop to lift your block, I can't help you, and I don't think anyone else can.". -- Gordon Ecker (talk) 04:01, 9 January 2010 (UTC)

If I blocked someone and then subsequently received such an email, I would most likely do the following. First, I would reexamine my block. If I determined there was legitimacy to the request, I would obviously unblock the user myself. Otherwise, the next thing that I would do would be to talk the request over with a few other sysops. If one or more convinced me that there was something to be said for the request, I would obviously unblock the user. If there was a substantial argument in favor of unblocking, but I was still adamant that the user shouldn't be unblocked, I would either attempt to discuss the matter with a larger number of sysops or take the case to arbitration. If at any point it became clear that consensus among the sysops was against me, I would unblock the user. If, on the other hand, the other sysops with whom I spoke all agreed with me, I would send the user back an email saying that I'd looked into his request and had personally declined it, but that he was still welcome to follow up with another sysop or with the arbitration committee (though I would expect arbcomm to decline the request if there was strong consensus among the sysops). I would probably follow a nearly identical procedure if I wasn't the sysop who had administered the block except that I would be sure to talk to the sysop who had and I would advise the user in question to do the same. — Defiant Elements +talk 04:17, 9 January 2010 (UTC)

(Reset indent) I think the problem with leaving the decision to unblock to the acting sysop and "consensus" is that it's often difficult to tell the difference between agreement and apathy. I cannot tell you how many times I've seen (on IRC) "Well, I don't agree with the block (or edit or revert or policy), but I don't care enough to argue about it." elix Omni 04:24, 9 January 2010 (UTC)

While you're correct in saying that it can be hard to distinguish between agreement and apathy, I've always found that if I seek out a few sysops and just ask them flat out "Do you think that my ban of such and such was unwarranted," I'll get a straight answer. Apathy generally only becomes a problem if your SOP requires that people go out of their way to disagree with you (as opposed to the system I outlined, in which I actively seek out the counsel of others). — Defiant Elements +talk 04:48, 9 January 2010 (UTC)

(Edit conflict) Not much of anything can be done about general apathy, but I think we have enough reasonable and active sysops here, especially after the wave of promotions, that if the unblocking of a major vandal/troll/general rabblerouser was even remotely contentious, at least one, if not more of the sysops would start up some sort of discussion in which actual opinions were introduced and the relative merits of each option were weighed. Similarly, I think that all the sysops have enough common sense not to make a decision of such magnitude unilaterally, and would consult other sysops and relay the blocked user's argument/reasoning before unblocking. calor (talk) 04:50, 9 January 2010 (UTC)