Guild Wars Wiki talk:Blocking/Archive 1

Drafting

Can we honestly say "Blocks are to be used purely as a preventive measure, and not for punitive purposes."? It seems to me there's a definite punishment aspect. If I... in a short space of time... vandalise several pages won't I get a longer ban than if I just made (say) one offensive remark? How is that not punishment instead of prevention? Vladtheemailer 16:21, 19 March 2007 (EDT)

I'm mixing up blocks and bans aren't I? Vladtheemailer 16:23, 19 March 2007 (EDT)

Heh, well, historically everyone has pretty much called it "ban", and it's just me trying to shift the terminology to match MediaWiki with this draft. --Rezyk 16:52, 19 March 2007 (EDT)

Could I say "This user (who so far vandalized every chance he gets) has a much greater chance of vandalizing again immediately IMO, so a long block is appropriate in helping prevent that immediate vandalism?" --Rezyk 16:52, 19 March 2007 (EDT)

Personally I don't see a reason why we have to say its not for punitive purposes and say that the length of the ban is a subjective decision made by the sysop based on the extent and nature of the offense. Vladtheemailer 17:05, 19 March 2007 (EDT)

(Edit Conflict)The term ban is used loosely to mean block in a wiki environment.

What I agree with (as this list is shorter):

• The first paragraph offers a good definition of the word block.
• A blocked IP can affect other users sometimes.
• Sysops are not obliged to perform blocks.
• A reason message is required.

Everything else I disagree with. Punitive purposes and preventive measures are both reasons why users get blocked and in some sense are combined. Preventive action is the blocking of a user violating the rules at the present. Punitive action is the blocking of a user that has violated the rules recently.

To restrict and try to mandate a sysop's ability to block a user when it is thrust upon them to do so and for an specific amount of time no less is only making an admin's duty to uphold peace and policy harder, but allowing vandals added freedom to persist in their activities if they wish.

To be an IP vandal and blank some pages, add some profanity, and know I will only receive 2 days and get to come back and do it again if I wished or to revert a section of an article, let's say six times, and get blocked. I'd get to come back after 24 hours and play the same game again. Not to mention the examples fail to mention anything regarding the breaking of any other policy.

The reason text is another restriction unneeded. Use my way of block messages for example, would it be better for an innocent IP user to see vandalism or, as I would write, continous blanking of articles or replacing text with profanity? What exactly do the links serve to an innocent user who could possibly not even be slightly curious as to what someone else did to get that IP banned?

There's just no reason for this policy other than an educational tool for users regarding the first four bulleted sections above. — Gares 17:38, 19 March 2007 (EDT)

If we want to treat sysops as site moderators that are to be 100% trusted in judgment and never second-guessed, I'd agree there's no reason for any restrictions on blocking. Otherwise, there simply is. --Rezyk 18:21, 19 March 2007 (EDT)

(Edit conflict) Well, that's fair to say, as I've never given any of my reasons before. =) But for now, I'd like to reverse the point: Why do we have to have punitive blocks? How do you know that preventive blocks aren't enough? --Rezyk 17:49, 19 March 2007 (EDT)

It seems pretty reasonable to me that people who commit a greater offense should have a greater punishment. Someone that for example vandalises a user page with "Vlad is a stupid wanker" should receive a lighter ban than if they vandalised the same page with a 5000 character swearing, ranting abuse full of racial and sexual epithets. That's not because they are necessarily likely to do it more (i.e. for preventative reasons, just because they did it worse which makes it punitive). Vladtheemailer 17:57, 19 March 2007 (EDT)

But preventative-only doesn't mean you can't take severity into account. The user who wrote 5000 characters of epithets is much more likely to perform abuse of greater severity than the first guy, and is worth blocking more just to prevent that. --Rezyk 18:09, 19 March 2007 (EDT)

Wouldn't someone who used (say) used a single racial/sexual epithet in place of someone using a more innocuous term be punished to a higher degree? Vladtheemailer 18:27, 19 March 2007 (EDT)

He/she could end up blocked longer under this draft, but I'd favor it not being considered punishment. Consider this scenario: What if someone commits an offense (say vandalism), but then repented, explained, profusely apologized, and cleaned up their own vandalism? An offense still happened, shouldn't we dole out some "punishment"? I say not necessarily -- if there doesn't seem to be any likelihood of it occurring again, there's no need for a preventative block. --Rezyk 19:15, 19 March 2007 (EDT)

I disagree. If they are blocked longer they are being punished more, there's obviously no more prevention necessarily. A spade is a spade. If they repent, profusely apologise, clean up etc... then sure may be the sentence is reduced, may be even to 'no ban just a verbal hand-slap'...but the point is there needs to be a distinct punishment for some offenses. Vladtheemailer 19:30, 19 March 2007 (EDT)

(Resent Indent)
First, admins are trusted by the majority of a wiki, else they would not become admins. This is not a place where the community is not involved in the addition of admins(moderators). Most admins here have been entrusted by not only the community that voted for them, but by the bcrat that made them an admin, as it basically is their final say. While your rebuttal is to suggest that we have to trust admins 100% or this policy is necessary, that is wrong. No one is 100% trusted by everyone in a community, especially a large one, and thus your rebuttal is an impossible occurance. Secondly, as I have stated, punitive and preventive blocks are in a sense combined. To use the word preventative is to say, "Presently someone is vandalizing something, I will block him in order to protect any vandalism he might perform right now and in the future(until the block ends)." To use the word punitive is to say, "Someone vandalized something recently, I will block him for his vandalism and thus protect from any vandalism he might perform in the future(until the block ends)." They start off separate, but after that block, they are essentially the same thing. Once a block occurs, you are punishing that user for his actions in addition to preventing any vandalism he may cause until the block ends. — Gares 20:56, 19 March 2007 (EDT)

I think there is also a case for a purely punitive response. i.e. This person committed an act which is so reprehensible that even though I have received a reasonable assurance that he won't reoffend he should have a loss of editing privileges for a reasonable ban period. Vladtheemailer 21:06, 19 March 2007 (EDT)

That's not what punitive means, and that's not what my "rebuttal" claimed. --Rezyk 21:56, 19 March 2007 (EDT)

I never stated what punitive actually meant, I was making a comparison of the two words based on the difference between punitive and preventive blocking. I will state it now. Webster's defines punitive as inflicting, involving, or aiming at punishment. A block of any kind is inflicting punishment, thus every block is punitive.

Rezyk writes, "If we want to treat sysops as site moderators that are to be 100% trusted in judgment and never second-guessed, I'd agree there's no reason for any restrictions on blocking. Otherwise, there simply is."

Gares writes, "While your rebuttal is to suggest that we have to trust admins 100% or this policy is necessary, that is wrong. No one is 100% trusted by everyone in a community, especially a large one, and thus your rebuttal is an impossible occurance."

That seems a fair assessment of your statement, a little over the top, but fair. — Gares 22:37, 19 March 2007 (EDT)

Consider the term "punitive" in the context of the draft, and this progression in meaning:

Blocks are to be used [...] not for punitive purposes.

->Blocks are not to be used for punitive purposes.

->Blocks are not to be used for purposes of inflicting punishment.

This is an example of a preventative purpose (in bold):

• Someone vandalized something recently, I will block him for his vandalism and thus protect from any vandalism he might perform in the future(until the block ends).

This is an example of a punitive purpose (in bold):

• Someone vandalized something recently, I will block him for his vandalism because he deserves to be punished.

All that we should be concerned about (with respect to this draft) is whether the purposes are punitive, not whether blocks themselves technically are. Yes, the confusion is my own fault for starting to use the shorthand term "punitive block" in this discussion while still intending to mean "block for punitive purposes". Do you agree with this? --Rezyk 03:43, 20 March 2007 (EDT)

That's a wrong assessment of my statement. Maybe we agree that we won't trust sysops 100% etc etc. Then all I was saying is that there is reason to have blocking restrictions (and yes, there is reason not to as well), contradicting the claim that "there's just no reason for this policy other than [...]". I also wouldn't consider it much of a rebuttal, since I didn't even detail any of the reasons. --Rezyk 03:43, 20 March 2007 (EDT)

Eh, might as well resurrect this discussion. Most of this draft makes sense to me (mainly because my view of adminship is very similar to Rezyk's - glorified janitors with ArbComm/Bcrats being the actual authority), but I do think that this proposal is overly restrictive, especially when dealing with repeat offenders. If we're talking about preventative blocks, and we know that a short-term block didn't prevent further vandalism/whatever, there needs to be a way to increase the time limit. Perhaps a guideline would be more appropriate (see Rainith's comment below), perhaps there would need to be a way to escalate the problem to ArbComm for an increased block ruling, perhaps sysops should be allowed to increase the length in cases of repeated violations.

I'm not really sure which one of those I agree with =\ I'd probably go with the ArbComm, but we currently have a two-man ArbComm. Unless we've got the elections up and running (we very much don't, atm), I dislike the idea of leaving decisions to a slowly-shrinking group of BCrats. MisterPepe talk 18:49, 5 June 2007 (UTC)

In short, this policy needs to be further expanded a little more. I support increasing ban durations for repeat offenders. Perhaps also specifying the maximum ban duration for certain offences. Currently it doesn't really spell out any baseline for ban duration. -- ab.er.rant 01:40, 7 June 2007 (UTC)

Make it a Guideline

I believe there should be "suggested sentencing guidelines" for blocks, but nothing hard and fast. Gares has posted above my thoughts on trusting admins (and I say that not as an admin, but as a contributor). If we force in inflexible time periods, then there is nothing to stop people from working the system, if you think it won't happen, look into the SIinky issue from recent history on GuildWiki. If all those folks got were 24 hour blocks, they would be getting them everyday. With guidelines that say, "This sort of action against the wiki should result in this sort of block time frame" would allow for admins to use their judgment, which is what they have been trusted to do. Any admin should be able to review another's action in a situation where a block fell outside of the guidelines and be able to adjust it as necessary. --Rainith 21:26, 19 March 2007 (EDT)

GWW:NPA

GWW:NPA is an official policy, and mentions blocks as a possible consequence for violating the policy.

"Consequences of personal attacks"

"Although editors are encouraged to ignore or respond politely to isolated personal attacks, that should not imply that they are acceptable or without consequences. A pattern of hostility reduces the likelihood of the community assuming good faith, and can be considered disruptive editing."

"Users who insist on a confrontational style marked by personal attacks can receive administrative disciplinary action, including short-term or extended bans."

If this becomes policy, it will either need to include punitive blocks for violation of GWW:NPA, or GWW:NPA would need to be revised, otherwise there would be a policy conflict. -- Gordon Ecker 05:31, 18 May 2007 (EDT)

Late to the discussion, but interested nonetheless: While I applaud the idealism of "we never punish, we only prevent," the fact is -- as stated in discussions elsewhere within this page -- preventative blocks could be viewed as punishment, anyway. I see no reason that we look only towards the future -- to prevent future damage -- as opposed to the present -- this person has made a concerted effort to disrupt the GWW, such behavior will bring about responsible reaction.

If a child runs into the street, a parent might give the child a time-out for that imprudent act. That punishment is also preventative. If someone engages in a concerted effort to defame another member, or engages in an excessive reversion war, or vandalizes numerous pages, his punishing block is a cultural preventative, as well, in that others will see it and be disinclined to mirror the offender's acts.

I don't think it would be prudent to adopt a policy of "no punishment, only prevention," and I agree with Gordon Ecker that this causes a conflict with the GWW:NPA. Further, I would not support a change to the GWW:NPA that, in essence, would water down a staunch position that sets the bar for an expectation of good behaviors. --Gaile 20:13, 22 July 2007 (UTC)

Yeah, there's definitely an overlap. I think that prevention is more important, and I agree that there is a place for both. -- Gordon Ecker 01:48, 23 July 2007 (UTC)

Any block generally both prevents and acts as punishment, so technically they can be considered preventative and punitive. No argument there. The question is whether to really increase block lengths just for that extra-discouraging effect (which I refer to as a "punitive reason") on top of any direct preventative measure. I'm not idealized against that extra-discouraging effect, but believe that using punitive reasons is still not a good idea here because:

• It complicates things quickly when factoring in a decentralized administration and a cultural notion of equality. In other words, people will be much more likely to complain or feel that they've been treated unfairly ("How come I'm being punished more than that guy?? His offense was greater because blah blah blah!!"). Whether it's true, false, or doesn't matter is besides the point; it'll happen more and with more emotion and with the level that we'll feel obliged to justify why, users will end up with much more negative feelings about it.
• On an open wiki, you have no real control over how discouraging the effect is. It's not like an in-game ban where you can be sure you are hitting some solid investment/resource of the user. Here the extra-punitive effect can even often be encouraging, and for the worst cases!

In practice, it doesn't even hassle us to stick with preventative reasons. If an offense is more aggravated or obviously remorseless, one is still justified in imposing a longer block because it's that much more pressing to be preventative from a practical standpoint. If everyone completely believes that an offender will not repeat an offense and there is no preventative reason, it generally does more harm than good to block anyways. --Rezyk 23:19, 27 July 2007 (UTC)

/necro

Due to the recent... variation... in blocking of those ampersand bots (everything from 3 days to infinite), I'd like to resurrect this discussion =P MisterPepe talk 21:51, 14 July 2007 (UTC)

I found a non IP account that was removing + and spamming links. - BeX 06:52, 15 July 2007 (UTC)

If it is helpful information, the Guild Wars policy for in-game behavior has different types of blocks and bans, and those are meted out, generally, without subjectivity. Infraction X is an automatic minor and receives the default block. Infraction Y is more significant and results automatically in a longer time out, even for a first time error. Infraction Z results in an immediate account ban, not a block. (There are few at the higher levels, but some rightfully belong there.) For most infractions, the player receives a "time out" as opposed to a ban. You can read about it our Conduct Breaches and Outcomes document.

We do not publicize the length of the time-outs in a general sense. They may have been divined by the public, but no matter. It's just that, as mentioned on this page, we do not want to give someone that mental impetus, "Is this worth being blocked for (period of time)? Yes, it is. I'll therefore misbehave." A little uncertainty about the duration is not a bad thing, we feel. A little discretion in the hands of trusted staff is a good thing, we know. We do inform the affected player of the period that he/she is blocked when the account is actioned. Account "marks" are cumulative, and someone receiving two marks within a limited period of time is going to be out of the game for a longer period than simply adding together two minors. In other words, there's an empirical scale but also a chance for redemption through good behavior.

Beyond all that, however, there can be cases where something grievous has occurred. In that case, the GM/Support Team member is empowered to set a higher mark on the account, thereby giving that player a longer time out. We need to be able to do this for both punishment and preventative means, I guess you could say. In one case, we required time to research a legal matter. Where normally we might have given a minor block based on the report alone, because of the potential legal nature of the matter we needed sufficient time to get a response from various other team members. Therefore, we placed a major and all support team members were informed of this, so that when the blocked player wrote to inquire about it, we were able to give an appropriate answer.

Basically, I wanted to say that having a rigid, public, "this is what you get, and all you get" policy may not be as good a thing as entrusting some degree of discretion to those making the block decision. It's hard to get everything in alignment, and there are definitely areas of subjectivity -- in opinion if not in outcome -- in dealing with issues of moderating public behavior. --Gaile 20:33, 22 July 2007 (UTC)

I can see the merits of both fixed block times and block ranges. In the current draft, ArbComm and personal attack blocks are open-ended. -- Gordon Ecker 01:40, 23 July 2007 (UTC)

I think some blocks should have a fixed lengths (e.g. page blanking = 1 week), some should have multiple values (e.g. minor vandalism = warn, then block for a day second time round) and some should be discretionary or left up to common sense within a fixed range (blanking a userpage = 1 week to 1 month, up to admin). Also, definitions should be provided on certain things... page blanking is self-explanitory, but what exactly constitutes "minor vandalism"? --Santax (talk · contribs) 18:45, 27 July 2007 (UTC)

Gordon has got it right; this draft has always been pretty open-ended. If the admins here were incredibly abusive, we technically could (without violating this policy draft, at least) ban a user indefinitely for not writing "Bork bork bork!" within every response. That's a lot of discretion... --Rezyk 23:48, 27 July 2007 (UTC)

Ultimately, we need to have some sort of guide to help keep our decentralized administration working along the same lines. If we go by a similar "hidden" guide format, devoted troublemakers can tease out the measurements at basically no cost (unlike in-game), which we don't want to encourage. So I think it's better to be generally open about it, which we have to be if it's going to be up to the community anyways. I started the constraints as relatively wide so that we can still get an "unpredictable" factor of up to 30x, and of course arbcomm rulings can still shoot for the moon, even for the existing cases. --Rezyk 09:16, 28 July 2007 (UTC)

3.1415 centuries

Oi! o_O - BeX 05:02, 28 July 2007 (UTC)

Lol. It also seems odd that there is no discretion for blocking infractions of the reversion policy. -- Gordon Ecker 06:00, 28 July 2007 (UTC)

Amusingly, I'm not the one that put that in. MisterPepe talk 06:22, 28 July 2007 (UTC)

I think that personal attacks so severe that they warrent a permanent ban should be handled by an ArbCom ruling rather than at the discretion of any single administrator. -- Gordon Ecker 06:28, 28 July 2007 (UTC)

Agreed, but what upper bound should we put for single administrator discretion? --Rezyk 08:35, 28 July 2007 (UTC)

Make it a Guideline (revisited)

This is a great idea for a guideline, but an abysmal one for a policy. We don't have bots reverting and banning vandals because we want people to use discretion on ban lengths based on the severity of policy violation - putting solid constraints on sysop's ban lengths sort of defeats that purpose. The "Text to be included in reason field" is a meh idea for a guide, and equally if not more abysmal than the ban lengths as a policy... enough is said about it in the third paragraph. -Auron 07:59, 28 July 2007 (UTC)

What's wrong with wide constraints that allow for a lot of discretion? For the reason text, is there any good reason to not be clear about it in this way? --Rezyk 08:39, 28 July 2007 (UTC)

Nothing's wrong, as long as they're guidelines. There is no reason this should be policy. -Auron 08:53, 28 July 2007 (UTC)

Spambots?

Too much potential abuse to be allowed to come back after any amount of time, imo. I think a permaban should be used for bots. --Santax (talk · contribs) 08:02, 28 July 2007 (UTC)

Yes, this discussion covers it pretty well. Spambots are pretty obvious (imo), and will never make helpful contributions to the wiki; indefinite bans are justified for them. -Auron 08:08, 28 July 2007 (UTC)

What about IP-based spambots which aren't using open proxies? -- Gordon Ecker 08:10, 28 July 2007 (UTC)

Sockpuppets

What's our policy on sockpuppets? Should we adopt and adapt this one or have our own? --Santax (talk · contribs) 08:06, 28 July 2007 (UTC)

I've added a line on using sockpuppetry to bypass blocks, but it could use some cleanup. -- Gordon Ecker 05:34, 25 November 2007 (UTC)

"Worse"

Didn't find an appropriate heading

I just don't like that wording in a policy. It sounds very arbitrary and.. unpolicylike. I would prefer a wording like (for vandalism, non bot) "several occasions", but I couldn't find more words to describe it.

And, "appears to be a single use IP account"?! Either it is a single use IP account, or it is not. Could someone tell me how you can say "This IP is not for single use", if it has just done one edit?

Also, only one occasion holds a note on what options to tick or tick off when blocking. That would be good to place on all different block variations, since (at least I) are not all familiar with what is needed. The sysop guide helps, but since we are stating "turn off autoblock" on one of the cases, I don't see why it couldn't be included in the others. - anja 09:10, 28 July 2007 (UTC)

worse is a perfect heading for me =)

There are several of problems with the current draft that make me worry:

1. I agree with auron and rainith above that this should be a guideline, not a policy. It is simply not possible to forsee all possible reasons to ban and all possible lengths that might be warranted. The big reason we want this is to have different sysops block with consistent lengths, for that a guideline is sufficient.
2. The current wording is inconsistent. Most parts read like a guideline "Following the suggested action guidelines is encouraged" while the title is "policy".
3. There should be some discussion about adding or not adding the lengths of multiple ban reasons before stating that. --Xeeron 09:26, 28 July 2007 (UTC)

Anja: I'll try to work on those.

Xeeron:

1. All possible reasons and all possible lengths that might be warranted are fully accounted for, despite not being foreseen. The idea here is that Arbcomm does the heavy deliberation and absorbs the blame (split 2-3 ways) from all the really difficult and unforeseen cases where someone is going to get angry no matter what, instead of us constantly repeating the cycle of blaming this sysop or that sysop for abusing their power, using their near-unlimited discretion inappropriately, etc, on the complicated cases. Sysops still get their discretion on all the common cases. Agree or disagree, but please give it some deep thought.
2. Hmm...lately we've been having some movement towards incorporating guidelines into policy articles with soft wording, so I thought this would fly okay. And didn't we use this "encouraged, not required" language somewhere else already?
3. You mean, "before accepting this as policy", right? I was thinking that we should get more opinions on the preventative/punitive thing, which this is guided by.

--Rezyk 10:19, 28 July 2007 (UTC)

Thanks Rezyk, sorry if I sounded a bit harsh :) I didn't know how to word it myself, so I didn't edit the article. - anja 10:23, 28 July 2007 (UTC)

Reversion

Is there any reason why undoing an unlabelled revert should be treated more harshly than intentional vandalism, even if the user who made the offending revert notices and undoes it soon after? Should editors really be expected to sift through an article's history to make sure they won't accidentally undo an unlabelled revert? -- Gordon Ecker 23:40, 31 July 2007 (UTC)

I assume you're referring to "violation of revert policy" - I'd hope no sysop would consider blocking someone who self-reverted an undo that was in violation. Furthermore, unless we decide to adopt 1RV, both of the other currently proposed policies (1RR and 3RR) would require you to make an near-identical change at least twice to be anywhere near violation of policy - thus, it wouldn't so much be "accidentally undoing an unlabeled revert" so much as "repeatedly adding in content that had been reverted more than once". However, I do think the "minor and not yet informed of policy" recommendation for violation of revert policy should be a warning and not a 1-day block (in fact, I'm going to change that as of now, if there's major opposition it can be changed back). If they continue to violate policy after the warning, then would be the time to consider blocks. (Aiiane - talk - contribs) 23:57, 31 July 2007 (UTC)

Yeah, accidental violations are pretty much impossible under the other proposals. What about including a statement that policy violation block lengths specified in the individual policies override the block lengths here, and that the table here should be updated to reflect policy changes? -- Gordon Ecker 00:08, 1 August 2007 (UTC)

Well, it seems Rezyk had already jumped somewhat in that direction (changing the draft to reflect revert policy blocks as TBD). (Aiiane - talk - contribs) 02:30, 1 August 2007 (UTC)

I did that to follow Gordon's comment. It's a fair way to go for now, right? Keeps us from getting this discussion tangled with the revert policies'. --Rezyk 02:33, 1 August 2007 (UTC)

It works for me, although I think some of the discussion on various policies was leaning towards working out blocks here and then working it back into the policy - we just need to make sure it gets worked out somewhere and not looped in some circular lack of definition. (Aiiane - talk - contribs) 02:36, 1 August 2007 (UTC)

"Idiocy": Disruptive and inappropriate behaviour

A very inappropriate request made here led to an argument and two violations of GWW:NPA. Since i&d (immature and disruptive) behavior does not contribute to the wiki and provokes disruptive reactions, I think it should be a bannable offense. I'm not alone on this, see User_talk:Skuld#Reason... and this is not a joke. It's very important that the offense is both inappropriate and disruptive. Simply disruptive behavior shouldn't be punished (assume good faith) and maturity is something you can't and shouldn't enforce. I was thinking about notifying the user with the option of a preventive 24h ban. Policy page has been updated. ~ dragon legacy 15:44, 15 September 2007 (UTC)

I think being able to give people warning when they are being disruptive or trolling would be a good thing. Nip things in the bud and promote common courtesy so to speak. I don't know that arbitrarily blocking for it is a good idea though. Some people might just be in a bad mood one day while others are permanently and purposefully like that. - BeX 01:16, 16 September 2007 (UTC)

Yes, I agree that this part of the policy could easily lead to more hostility. If our admins think they couldn't handle it correctly, we shouldn't implement it. ~ dragon legacy 08:28, 16 September 2007 (UTC)

I disagree. Immature behavior is hard to define (and apart from that, we do not disallow non-mature users on this wiki). "Disruptive" is just as soft. If something disrupts, name it (e.g. moving pages to wrong names) and disallow that explicit action, not something general which would be up to sysop discretion to define. --Xeeron 22:16, 16 September 2007 (UTC)

I agree that we should not be immediately blocking (i.e. statutory blocks) for actions which can't be strictly defined. On the other hand, I do think that we need to implement a policy which allows for a broader category of "disruptive actions" which, while not immediately earning a block, should allow for the possibility of a block after repeated warnings and potentially the consensus of multiple sysops. As it is, the wiki is quite open for "abuse of the rules" so to speak as sysops are fairly strictly bound to narrow policies, even for protracted disruptive actions. It's good for sysops to be bound to policy for short-term incidents, but for protracted antagonization I believe it is in the best interest of the wiki overall to allow at least some sysop judgement to come into play. (Aiiane - talk - contribs) 22:41, 16 September 2007 (UTC)

I'd be on the fence on this one if it came to polling the favor. On one hand, banning a person or people for something similar to the Vault Box talk page incident would be a good decision, showing the offender that "disruptiv eand immature" actions aren't tolerated on the wiki, buthow far would it be taken? Where do you draw the line between "an honest mistake" and someone trying to screw up the wiki because they're just like that. Also, how long would it be? 24h is reasonable, but it could get ugly if the person comes back going "omg wtf I was banned for only doing this tiny little thing!!!". Theoretically, it seems like a great idea, but once you finally look at it, or if it was implemented, it becomes tough as to where the line is drawn, with a lot of gray areas. I wouldn't mind seeing something like this put in place though, just to keep arguments like the Vault Box one to a minimal. Calor - talk 22:54, 16 September 2007 (UTC)

So what is "disruptive"? Something that interrupts normal wiki working, I would guess, but that is much too broad. Is it disruptive to edit my talk page 10 times in a row (easy use of RC gets interrupted), or would I have to do a full blown denial of service attack? And where inbetween do we draw a line? The policy needs to clearly spell out what is not allowed. --Xeeron 23:00, 16 September 2007 (UTC)

I'm not sure it's possible to spell it out in an objective sense, Xeeron, which is why I do not support immediate statutory bans for any merely "disruptive" action which does not violate another policy. I do however think that there should be a process in place for dealing with users which express a clear pattern of actions that is not in the interests of the wiki, such as repeatedly trolling discussions over protracted spans of time in bad faith. (Aiiane - talk - contribs) 23:04, 16 September 2007 (UTC)

(Reset indent) The problem I have with clearly spelling out what is and isn't allowed means people look for and find loopholes to exploit. Then when an admin uses the tiniest bit of discretion in the case of an unanticipated case they get policy thrown back up them when clearly they are in the right. Don't get me wrong, I agree there has to be boundaries and some sense of consistency, and it shouldn't be a free for all of control, however, should you not trust the admins to use the tools at their disposal responsibly? Just a thought :) --Lemming 23:09, 16 September 2007 (UTC)

Another possible consideration in this discussion may be the ArbComm, the duties of which we still haven't properly designated, even though we spend half the year electing them. Maybe one of the roles of the ArbComm could be to deal with trolls who intentionally avoid breaking any policies? I'm not really sure about this yet, but it's a possibility, since right now I'm having difficulty imagining what a "Don't Troll" policy in a policy-centric wiki would look like. By the way, blocking is not the only measure that can be taken (I'm thinking about restrictions limiting on which namespaces/articles an user can or cannot post, and such). --Dirigible 23:12, 16 September 2007 (UTC)

(in response to Aiiane and Lemming64) Having had the choice between dictatorial sysops, free to hand out punishment and extremely rulebound ones, without any discretion, the community here did opt for something closer to the later than the former (of course we are not totally extreme either). "Disruptive" is just too open to interpretation. One sysop could have a hugely different understanding of what is disruptive compared to another sysop - which is something we should avoid. --Xeeron 23:19, 16 September 2007 (UTC)

Which is precisely why I keep stressing that it needs to be both process-based and based on consensus among a number of sysops and/or bureaucrats (and Dir makes an extremely good point that we haven't really done much in defining the bcrat role). There's simply a point, however, where you can't predict every possible scenario. If that were the case, real life would have no need of courtrooms. ArbComm is the closest thing we have to that, and by current policies they can't even rule on anything that's not between users. (Aiiane - talk - contribs) 23:22, 16 September 2007 (UTC)

I like the idea of the ArbComm having a use for situations like this. Where the ruling is not clear cut from policy, but clearly some kind of intervention is required, in the more extreme cases. --Lemming 23:24, 16 September 2007 (UTC)

Guild_Wars_Wiki:Adminship/Draft-2007-9-16 - I hashed up a draft policy modification, there's a diff link at the top. (Aiiane - talk - contribs) 03:54, 17 September 2007 (UTC)

I agree with Xeroon. There need to be a process. Also, I feel that sysophood should grant no special privileges in communty decision making. Dirigible is right in that this is something that should end at the bcrats, though I'd prefer that as a last resort. Backsword 06:02, 17 September 2007 (UTC)

I agree that Arbcomm would be a good fit for this -- sysops can directly manage the common clear cases for blocking (like blatant vandalism) while we rely on Arbcomm's judgment (as a group) for the stuff which needs a good measure of discretion. --Rezyk 08:01, 17 September 2007 (UTC)

(Reset indent) I really don't like the way the argument is taking here. You have valid points, but you're missing out on a lot. The idea of having the commitee ArbComm involved is certainly nice, but not practical. Neither is it practical to impose formalities on sysops for minor offenses. I should clarify what I mean by "immature and disruptive". Comments which are both immature and disruptive are random, off-topic comments which do not violate NPA. They clearly stand out from common wiki behavior and may provoke violations of NPA or Revert Wars. The example given is "May i have 75K from 1 of you guys please answer in my talk". Other examples include "lol, you guys are all noobs" and "I don't care about any of this crap, Anet can kiss my ass". Apart from profanity being used, these comments disrupt (the discussion, or the reader) and are inappropriate (immature). Now please come again and tell me how and if you would handle those incidents. ~ dragon legacy 09:35, 17 September 2007 (UTC)

Personally I don't really see where "people are missing out on "a lot"". Can you be more specific in what you think is going to be left out?

As for ArbComm getting into the picture, I agree, that would be a pretty good solution for situations with foolhardy trollers, where sysops can not come to a consensus on action. As to it being non-practical, I think I disagree, although I probably need a better explanation of your definition of "not practical". AFAIK, BCrats are some of the most active users on this wiki and they can respond to issues almost as fast as sysops can.

As for your examples Dragon: my personal way of acting would be to give a warning and from that point forward see how that warning is received. If the troller continues, I think a consensus between sysops on a cooldown period for the troller, would be best. --  (CoRrRan / talk) 11:11, 17 September 2007 (UTC)

But that's exactly what I'm talking about. Alright, I did some more reading on the matter and I have to come to agreement with the supporters of making this an ArbComm decision. ~ dragon legacy 12:03, 17 September 2007 (UTC)

I don't see why the duration should be capped when an arbitration comittee can ban someone indefinitely for anything else. -- Gordon Ecker 00:25, 21 September 2007 (UTC)

For example, if someone posted that disturbing and possibly illegal fanfic in a talk page, I think that would warrent a permaban. -- Gordon Ecker 00:43, 21 September 2007 (UTC)

For now, I've simply changed it to "as determined by arbcomm" - but I also thing this is redundant, given that we already have an entry for "according to an arbitration committee ruling or injunction" 2 rows above. (Aiiane - talk - contribs) 04:18, 21 September 2007 (UTC)

Hmm, yes. Under those circumstances we might as well remove the proposal from the list. ~ dragon legacy 06:05, 21 September 2007 (UTC)

I'd like a note somewhere saying that inappropriate conduct is frowned upon and can get you banned, so that there's a place to point people to when giving them warnings. -- Gordon Ecker 09:20, 21 September 2007 (UTC)

I'm thinking that this would be better off as a guideline for sysops rather than a policy, because as a policy, it kinda implies that these are the absolute reasons that you can ban someone, making it too strict and too slow in nipping disruptive issues in the bud before it gets out of hand. As for inappropriate conduct and disruptive behavior, I would rather see a policy like Guild Wars Wiki:For the good of the wiki. -- ab.er.rant 09:26, 21 September 2007 (UTC)

I think the best place for the note would be Guild Wars Wiki:Arbitration committee. -- Gordon Ecker 09:59, 21 September 2007 (UTC)

(Reset indent) Done, someone else please check my edit. ~ dragon legacy 12:43, 21 September 2007 (UTC)

There are currently 3 policy proposals running which touch upon this (no trolling, no profanity and the adminship revision, not counting this one), so lets wait for the outcome of those before adding that note. I feel that Gordon should have rather directed you here, since such a line needs to be added into policy first before the non-policy arbcom article can make such claims. So the better way for you to proceed is adding something to that effect to that proposal (or make a new adminship proposal). --Xeeron 12:56, 21 September 2007 (UTC)

Edit made here: [1] ~ dragon legacy 17:19, 21 September 2007 (UTC)

I interpreted the current version of Guild Wars Wiki:Adminship as heavily implying that ArbComm rulings can cover user misconduct outside the scope of policy. -- Gordon Ecker 00:10, 22 September 2007 (UTC)

I agree..the change generally seems like extra clarification to me. --Rezyk 08:16, 22 September 2007 (UTC)

Since there's an overall sentiment that the ArbComm is now a sort of ruling committee, or greatest authority, I might as well also propose that the number of bureaucrats be increased in anticipation of a increase in the things they need to arbitrate about. I would like to add that by pushing things to ArbComm, it's actually resulting in something similar to what Xeeron mentioned earlier - dictatorial sysops vs rulebound sysops. The only difference is that it is the bureaucrats who will be doing the dictating. Sure you can argue that it's a committee, so it's better, but it's not like sysops cannot revoke each other's actions or engage in a discussion before a final decision. I'm not opposing the change to the policy, I'm just saying that it basically achieves the same thing. Somehow, I'm starting feel a little insulted (not sure if I'm just overreacting or getting too tired of all the silly issues that been cropping up). All this talk of "No, sysops can't do that, but sure, the bureaucrats can." I'm getting the distinct impression that people here don't trust a sysop to act sensibly and logically. It's like saying here's a broom and a stick and a set of rules of what to do with them. Don't do what the rules doesn't say because I don't you can. I'm now so much in agreement with the growing sentiment that the sysop election is really a popularity contest, not a "I trust you and believe in your character" kind of contest. It's really late over here and I've had a long and tiring day, so I'm probably overreacting. Just speaking my (sleep-deprived) mind. -- ab.er.rant 16:38, 22 September 2007 (UTC)

Thre is a certain positive side in separating the janitorial tools and the decision making form eachother to these two roles. No one is permitted from being both an admin and a bureaucrat, but we can limit people to either one if we think it is necessary. -- (gem / talk) 16:54, 22 September 2007 (UTC)

A good example being me. Many users agree that I am good at deleting/blocking/etc, but also many agree that I'm not a good leader model or decision maker. Therefor this division makes it possible for the community to only give me the admin tools and no leadership role at all. I don't have a good example for the other case, someone being only a bureaucrat and not a sysop, but I guess there might be a reason for that too some time. -- (gem / talk) 16:57, 22 September 2007 (UTC)

I hope your anticipated increase fails to materialise. Really. --Xeeron 18:57, 22 September 2007 (UTC)

What anticipated increase? I didn't quite follow you there. -- (gem / talk) 18:59, 22 September 2007 (UTC)

Xeeron's referring to Aberrant saying "I might as well also propose that the number of bureaucrats be increased in anticipation of a increase in the things they need to arbitrate about". --Dirigible 19:02, 22 September 2007 (UTC)

Ah, unintuitive indention ftl. I agree with Xeeron. -- (gem / talk) 19:07, 22 September 2007 (UTC)

Xeeron, can I ask why you would oppose an increase in bureaucrat count? I'm thinking that since we're increasing the types of issues that can escalate to become an arbitration issue, would it not be safer to have a slightly larger pool? Look at Erasculio's arbitration. What if both Dir and Biro declined or refused to arbitrate? What would happen? The case is rejected and they go back to bickering?

But I do see the value of clearly separating enforcement and legislation. I'm just trying to say that this still doesn't resolve future disruptions as peacefully and quickly as possible. How long before an ArbComm ruling can be made from the time a request is placed? You'd need to wait for an accept/reject from all of you. Then you'd need to talk things through and discuss. What happens if we get another escalating case of two users bickering with each other heatedly (and yet no NPA violation)? Or another user successfully trolling a large number of strong responses? Should there not be a mechanism in place to nip things in the bud before they can escalate? A little timeout does wonders with tempers sometimes. -- ab.er.rant 17:07, 23 September 2007 (UTC)

Addendum: I'm not saying that we skip ArbComm. I'm saying that if we put something to ArbComm, at least have some failsafe in between the time of the raised issue and the ruling. -- ab.er.rant 17:09, 23 September 2007 (UTC)

A failsafe already exists: The arbcom injunctions. If some REALLY bad was going on, any of LordBiro, Dirigible and I could stop it. However that should really only be a last, last, last resort. For matters not as grave, there are still the sysops (in case policies are violated) and the very normal way of users posting on other users page to ask them to stop doing something.

My above statement was actually not a reference to enlarging arbcom, but in references to arbcom cases. However, I do indeed see a problem with having a large arbcom: Committees have the property that, as the number of members raises, the efficiency decreases. Having arbcom members that are not actively arbitrating would be a problem of course, but if the number of members gets too large, we would never get anything done either. --Xeeron 19:14, 23 September 2007 (UTC)

What about having, say 5 arbcomm members, but only 3 need to respond to any particular request? If I don't understand what exactly "arbcomm injunctions" are, does that mean it should be somehow explained in GWW:ADMIN? -- ab.er.rant 03:56, 24 September 2007 (UTC)

You are right, it should be stated on there what an injunction is, I guess it was discussed on the talk page when the policy was created, but never clearly written into the article. You touch an important point though: On Erasculio's arb com, LordBiro refused to take part (which is entirely ok) by saying he declines to take the case. However I feel that an actual "decline" while discussing whether to accept the case should not exclude that arbcom member from the following process, should there be a majority for accept. The basic reason being that otherwise arbcom decisions could be biased against the accused. --Xeeron 09:08, 24 September 2007 (UTC)

Status Check

We've done a lot of talking about this, over the last many months. Do we yet have a policy? If not, I hope that the Bureaucrats and Sysops are not feeling unreasonably restrained in fulfilling one of the responsibilities of their position: dealing with misconduct. As the GWW grows, we, as members, need to assure that Bureaucrat and Sysops are able to do what they need to do. For the administrators of this wiki were elected for a reason, and surely they must be fully empowered to identify and act upon offenses on the GWW on the behalf of the GWW membership. -- Gaile 19:14, 14 October 2007 (UTC)

Just to clarify one thing: Even without this policy passed, sysops currently are fully able to deal with misconduct based on the current policies, most importantly GWW:ADMIN, which allows them to block accounts, and GWW:NPA which currently is the foremost policy with regards to user behavior. This policy, if passed, would restrict sysops in the length of blocks (to make block lenghts less arbitrary), but its absence is in no way preventing sysops from doing their job, including blocking accounts. --Xeeron 22:10, 14 October 2007 (UTC)

Thank you for that explanation. I'm glad that business can carry on a usual. -- Gaile 22:42, 14 October 2007 (UTC)

Coming up on 8 months

What's stopping this from moving forward? - BeX 00:43, 29 October 2007 (UTC)

I'm fine with passing it as-is. Revert wars and non-vandalous persistant disruptive editing are rare, and I think that arbitration can handle them for now. -- Gordon Ecker 06:27, 29 October 2007 (UTC)

No issues here. -- ab.er.rant 06:42, 29 October 2007 (UTC)

Repeating spam bots (IP)? My suggested action is: 1st offense: 3days, 2nd offense: 3months, 3rd offense: infinite. Or is that too harsh? --  (CoRrRan / talk) 12:10, 29 October 2007 (UTC)

I think that's too harsh. The block lengths specified currently is enough, imo. I'm fine with this policy. - anja 15:14, 29 October 2007 (UTC)

I disagree with this being policy, but it would be ok as a guideline. --Xeeron 15:38, 29 October 2007 (UTC)

I'm on the same lines with Xeeron. If it's a policy some weirder cases would be very hard to cope with. -- (gem / talk) 16:14, 29 October 2007 (UTC)

What kind of wierd cases, and how would they be any easier to cope with without this policy? Is that the only reason to not have this as policy? --Rezyk 18:02, 29 October 2007 (UTC)

Good points, I didn't even think of that :/ I blame exams. As a guideline it's ok. - anja 16:16, 29 October 2007 (UTC)

I agree, I think it makes more sense as a guideline. The suggest ban periods are quite open for interpretation with large ranges suggested anyway. --Lemming 16:17, 29 October 2007 (UTC)

For those of you who are saying that it should not be a policy, but a guideline, I'd like you to clarify: What stance are you taking for whenever a sysop blocks/unblocks outside the bounds given by this proposal? Are you basically shooting for generally allowing the sysop to completely ignore the bounds at their own discretion (being only an optional convention), and having both Executive sysops and No trolling in effect with respect to blocking? What is the effective "bottom line" that you want to give sysops for what is proper/improper usage, for whenever there is potential disagreement over a block? Please note that sysops going wild/rogue is not my concern here, nor is it about how frequently such disagreement will appear. --Rezyk 19:44, 29 October 2007 (UTC)

My concern personally is having to memorise it as a policy, the reasoning occasionally you have to block someone fast, if they are on a huge vandalism spree editing multiple pages every minute, you don't want to have to bring up the policy documentation to ensure that you don't get shouted at for using an incorrect block duration or terminology. Obviously every other situation if you were unsure you would have the time to bring it up and check on wording if needed. If it were a guideline if someone was blocked for too long it could be changed to bring it in line with the guideline, without anyone shouting at anyone for infringing on a policy. Those are my thoughts anyhow. --Lemming 19:50, 29 October 2007 (UTC)

There's nothing much to memorise as it is. Just remember a 3-month max for automated vandalism, and a 1-month max for most anything else. The lower bounds is still up to you. The important column as a policy is the "Block length bounds". The "Suggested action" is the guidelines part, a good starting point or reference for sysops who are unsure of how long to block a certain offense. Once you've blocked a few, you can establish an increment pattern for yourself and just stick to not going over the max (but currently, we have block lengths that go over that limit, so unless someone wants to discuss that? Hmm... we also have question marks still in it). -- ab.er.rant 03:47, 30 October 2007 (UTC)

I'd consider the existing blocks to be grandfathered in, but I think that grandfathered out of bounds blocks should be reviewed by the Arbitration committee and either upheld or commuted on a case by case basis. -- Gordon Ecker 04:36, 30 October 2007 (UTC)

One thing that makes we hesitant about this policy is about enforcing it on obscure cases. When a new kind of vandalism/blocking reason comes up, should we be prohibited to block just because it isn't in policy? Will it require drafting and discussion before we could finish this policy and then block that user? I don't have a specific example, else I would include it in the policy. It's just a 'what if' that makes we wonder if we really have to make this a policy. - anja 08:29, 30 October 2007 (UTC)

The "vandalism that appears intentional" and "excessive disruption in an uncivilized or unresponsive manner" seem broad enough to cover any emergency situation which would demand immediate enforcement. -- Gordon Ecker 08:38, 30 October 2007 (UTC)

Yeah. For really extreme unforeseen+uncovered emergencies there is also the arbcomm injunction case, and if GWW:PINS were ever passed, the "You can always do whatever you reasonably believe would be supported by consensus" clause (though relying on that is still risky). --Rezyk 23:36, 30 October 2007 (UTC)

Anja, I'd consider that possibly the main decision point about whether to take this kind of proposal. When there is some obscure case with an undiscussed reason to block, who gets to decide whether it is good enough? Is the special right to make that decision ultimately given by the community or by the default software configuration? Will blocking without a consensus avoid more problems and drama than it causes overall? Do we want the management of the wiki grounded in consensus, or the convenient meritocracy? (Okay, that's enough bias from me.) We don't have to make this policy, but we do have to end up with something that covers this -- hopefully intentionally. --Rezyk 23:36, 30 October 2007 (UTC)

Gordon, the proposal leaves things a bit open for a relatively informal commuting process. --Rezyk 23:36, 30 October 2007 (UTC)

Ab.er.rant, question marks filled in now. --Rezyk 23:36, 30 October 2007 (UTC)

Lemming64, a much bigger factor in dealing with that kind of vandalism is the number (and presence) of users who can block vandals efficiently. This proposal seeks to safeguard that factor by keeping sysops only incrementally different from users, thus avoiding ending up with sysops with excessive control, and thus avoiding the need to heavily restrict ourselves from having tons of vandal-blockers around. --Rezyk 23:36, 30 October 2007 (UTC)

That is a fair point. --Lemming 00:25, 31 October 2007 (UTC)

Reasons why I dont like this as a policy (and want it to be a guideline)

This policy sets out to achieve two goals: To cut down individual decision power of sysops (in line with our view of sysops) and to standardize the block lengths handed out to sysops. It fails on both of these.

Since it is set up as a policy, the variance of block lengths prescribed has to be very wide, since every possible case has to be covered. Look at the vandalism case: Block length of "1 day - 1 month". That standardizes nothing. Sysop A will still block for 3 days, Sysop B for a week and Sysop C for two weeks. At the same point it takes almost no individual decision power away from sysops. Yes, they can't block for 10 years, but noone is doing that anyway. The sysops decision what lengths to block for is essentially the same as before.

In a guideline, these problems can be avoided by setting the block lengths much closer. Say, for example, vandalism = 1 week. Then every sysop will block for exactly the same length. Of course there will be those odd 5% of cases where someone will block for a month because the case is special, but that is allowed under both the policy and the guideline and I expect our sysops to follow the guideline in the huge majority of cases. A guideline does not set strict bounds on sysops, but as I argued above, if those bounds are so lose as not to ever be binding, they are not really setting a bound on sysops either. In contrast, with a strict guideline, everyone can see whether an individual sysops consistently breaks that guideline. If so one can take it to the talk page of that sysop. Also remember that we have a very simple procedure to get rid of sysops: If enough people think that a sysop should abide by the guideline and does not, setting up a reconfirmation is easy. --Xeeron 10:59, 31 October 2007 (UTC)

I would support having a blocking guideline for that reason -- although it does not set any strict bounds, it has that much more freedom in being precise with its non-strict bounds, which is a boon in standardization. So let's have both: a strict policy with wide ranges, and a non-strict guideline with narrower ranges, serving complementary roles.

That way, this proposal can still work towards its goals that haven't been explored. One of the critical points that I want you all to not overlook is where it says sysops are only to block for one of the cases given here. This was touched on above in my questions and some comments. Who should ultimately control how blocking is used? I feel that it is generally time to discuss and/or choose between an approach like this one, or one like Guild Wars Wiki:Executive sysops, or suggest a third alternative. Simply pushing this entire proposal from policy to guideline may leave that question unanswered. Please don't do that.

Also, if this is a case where you feel that this as policy would impede sentiment towards an effective guideline, please don't oppose on just those grounds. Let's avoid getting political (perhaps not the right term) here. Part of the reason I wrote such open cases here was to just aim for a step forward that hopefully everyone can comfortably agree with.

I am moving the "Suggested action" column out of this draft and into the start of a Guild Wars Wiki:Blocking guideline. I would like everything else to be considered as potential policy.

--Rezyk 04:45, 2 November 2007 (UTC)

relative authority

If this is implemented as a policy, then that would require that any changes to it go through the policy change process. This has a potential to get sticky if (for some reason), a new policy adds another reason to block a user (which is not specified here). Might I suggest adding a clause that if a policy lays out specifics for blocking according to the policy, it overrides anything stated in this policy? That way, the new policy could lay out the details for the block, and be adopted as such, without the delay of the additional policy change procedure for this, a separate document, having to pass before the new policy could pass. After the new policy was implemented, a change for this page could then be proposed to add the new category of blocks. (Aiiane - talk - contribs) 10:12, 30 October 2007 (UTC)

Sounds good. -- ab.er.rant 10:19, 30 October 2007 (UTC)

I added a clause that attempts to "auto-accept" appropriate cases in other policies, hopefully circumventing the extra red tape. They should be made explicit enough though; I'd guess that something like this would suffice: violations of this policy are grounds for any sysop to block for 1-3 days. --Rezyk 20:25, 30 October 2007 (UTC)

No duration cap?

I really don't like the idea of uncapped unilateral blocks. I'd prefer a cap of 1 or 2 weeks for non-IP, non-arbcomm blocks, or some form of automatic appeal / review process for all blocks above a certain duration. -- Gordon Ecker 01:45, 3 November 2007 (UTC)

Capped at 2 weeks now, excluding stuff that involves arbcomm, bots, or testing. I also effectively removed any cap for automated vandalism from an IP account. That was more an issue of trying to keep sysops reminded of the splash damage of innocent users getting blocked; hopefully the guideline will be effective enough for that. --Rezyk 19:01, 4 November 2007 (UTC)

Just a note, we need to keep the policy consistent with the guideline. So if you lower the cap here, lower in the guideline accordingly: The soft limit of the guideline must be below the hard limit of the policy. --Xeeron 00:36, 5 November 2007 (UTC)

Regarding the actual numbers, I disagree with both the lower and the upper limit. The lower limit should be totally done away with. Why should sysops not be allowed to ban for an hour? I can think of circumstances where that makes sense. The upper limit is much to low for me. Remember this is a hard limit, not a suggestion. --Xeeron 21:04, 12 November 2007 (UTC)

Agreed that there is no reason to order a lower limit in general. I guess it's meant in combination with the no extention of blocks rules, to avoid a situation where someone who should be blocked for a long time gets a symbolic ban. But I don't really see that as an issue. The longest block would have been two weeks.

The upper limit seem OK, if it's intended as meaning that when regular users are to be blocked for extended periods of time, it's an ArbComm matter. Backsword 11:44, 13 November 2007 (UTC)

To me, I take the whole issue of pushing the power/responsibility/decision/control towards the community's hands as general pressure against any allowances here -- that is, to have zero items in the list of allowed cases. Then I'd take strong-enough reasons for specific cases as justifications for why we should add items (with appropriate duration windows) to the list, incrementally increasing sysop options with what amount to "pre-approved blocks", only because it is impractical to gather a consensus every time. Essentially, one purpose here is to limit blocks to those that we would expect to be directly supported by the community if reviewed on a case-by-case basis.

For the short term blocks especially, it is just not apparent to me that we could generally pre-expect enough community support for them in individual cases. Those are often the borderline cases where a block tends to be much more contentious.

Perhaps this is currently reflecting my personal bias too much, though. In terms of "the community giving the sysops direction", here is my stance: When you sysops come across a case where you are not comfortable with blocking for at least a day, please do not block at all. (This does not apply to benign cases like runaway bots.) Now, perhaps you have a good example of a common case that would change my mind, but that is my standing opinion for now. The underlying reason for it is the explosive strife and contentious actions/reactions/attitudes that tend to accompany short-term blocks.

--Rezyk 23:23, 13 November 2007 (UTC)

I see your point, but I think SysOps may well be comfortable with blocking and still think an hour is better for some reason. Backsword 13:55, 15 November 2007 (UTC)

Again, I disagree. I can imagine situations, where a 1 hour block will be just as successful as a 1 day block (think of heated discussions involving some NPA that quickly fill talk pages), so why should the sysop forced to block for a longer time period? --Xeeron 15:05, 14 November 2007 (UTC)

I completely agree with Xeeron. I think a sysop should be able to block someone for whatever period they see fit, but we should provide guidance to sysops on just what a reasonable period would be. They might decide that, since this is a minor NPA, half the reasonable NPA block would be suitable. Or they might decide that, since this is a really nasty NPA, a longer than usual block would be best. I think setting hard limits is just going to cause trouble later, since we're almost certainly going to have to tweak those limits. I think it's better just to not have them. LordBiro 08:00, 15 November 2007 (UTC)

Let me try another approach:

The idea was to keep these durations tightly bound to community control by limiting the windows to that which could be quite strongly pre-approved. I still believe this to be sound, though relatively inflexible. I guess you guys understandably want more flexibility (and perhaps see that as much more important than I do).

What I really want is to at least keep it all rooted to community opinion somehow. I do not want to strongly rely on the guideline for this -- sysops might just decide that they are not particularly interested in following that. Nor do I want to strongly rely on de-sysoping to weakly encourage this -- it is too much of a contentious control mechanism, and so imprecise (could force me to choose between having a poor NPA blocker and less good vandal blockers).

I've edited the proposal to remove the hard limits and added a more optional reactive feedback control instead. How is it? (And should we also still keep an upper bound on top of this to make arbitration support a requirement for really long blocks?)

--Rezyk 13:06, 15 November 2007 (UTC)

I disagree that indefinite unilateral blocks are a good idea for regualr contributers. If something that drastic is to be done, I prefer to have the overview that ArbComm provides. (Rezyk, I'd rather not create a second system parallel to ArbComm.)Backsword 13:55, 15 November 2007 (UTC)

So I readded the cap, but with a one month length, and with the user feedback clause. Is this a reasonable compromise between all the views here? Backsword, do you see this as a unfavorable parallel system? I see/suggest it as covering separate functions: arbcomm for needs over 1 month (for contentious cases) or where blocking at all would be heavily disputed; sysop discretion potentially followed by feedback for covered cases and some community control below the 1 month threshold. --Rezyk 21:16, 30 November 2007 (UTC)

Sorry to be so negative on this, but yet again, I don't support that proposal. "Significantly more disapproval" is not really clear: More disapproval among sysops (the group that has the expertise in blocking), among the general wiki population (how would that be elicited, setting up a dedicated page?) or among anon's complaining on the acting sysops talk page? I dislike all of the options really.

We do face a general trade-off between flexibility for the sysops and safe-guards against arbitrary blocking, but there is no perfect way to resolve this, only a choice of second bests. In my opinion, a (high) max duration cap, combined with a blocking guideline (and a strong suggestion to use this) is the best way to solve this. If some sysop consistently blocks longer than the guideline suggests without good reason, people can still complain to arbcom. So there is not only de-sysoping as a last step. --Xeeron 23:15, 10 December 2007 (UTC)

It's meant to be disapproval/approval from the group that is supposed to manage the wiki -- the community (draft edited now). I also hate to be more hardnosed about this, but I'm just asking whether you guys can consider it a reasonable compromise that you can live with, not whether it is the best way or even particularly liked. It isn't an ideal solution to me either; I favor even less sysop flexibility because I would rather see the question of when blocking is okay be closer to "when there would be a consensus for it" rather than "when there is not a consensus not to", and because I believe any flexibility will generally be stretched to its limits. It's already a fair step away from that to put the main onus on the disapprovers instead of the approvers. The one month maximum also stretches further away from what Gordon Ecker originally requested. If you still cannot support this at the "fair compromise" level, can you be more specific about what you dislike, or what you consider a "high" cap, if not one month?

Or if you just want us to continue discussing the options before seeking a compromise, that's fine. For my proposal, I envisioned the disapproval as appearing as comments on the sysop's talk page (and realistically not appearing at all in most cases). I also added that the disapproval should be reasoned. If the disapproval/approval is split 50/50, the clause doesn't restrict the sysop's practice (is that not actually obscenely flexible?). I don't even get when it should be okay for a sysop to not follow this clause already.

For your suggestion of the guideline+arbcomm control path, there are some things that put me off:

• It seems contrary to the policy that guidelines "are not to be enforced by administrative action".
• I'm not so concerned about where they block outside of bounds "without good reason". I'm more concerned about where there is both good reason to and good reason not to. Even you and I seem to have a reasonable disagreement over usage of 1-hour blocks. How should I expect to have my opinion be counted fairly appropriately (neither too much nor too little)?

--Rezyk 01:48, 11 December 2007 (UTC)

I am ok with the 1 month max cap, the part I disagree with is the "garners more ..." one. That introduces backdoor voting on the sysops blocking behavior. Not how it doesn't even read consensus, but talks about a majority. Voting on a wiki is always fraud with problems and should only be used for extremely important aspects (see how much effort goes into the bureaucrats elections each time). You need to worry about agenda setting, about sockpuppets, about counting, and so on. I'd be ok with that part if it said that sysops decisions can be overturned if there is consensus (but I guess these are not the cases you are thinking about). --Xeeron 10:44, 11 December 2007 (UTC)

The entire paragraph seems like a poor substitute for a blocking guideline. It would apply different rules to different sysops and allow popular users to get a slap on the wrist due to their popularity. If "acting sysop is" was changed to "sysops are", the precedents would creat a "virtual" blocking guideline scattered between the admin noticeboard, sysop talk pages and their archives. -- Gordon Ecker 11:30, 11 December 2007 (UTC)

Rewritten now to try and eliminate mechanical baggage. But it drifts back closer to my view of what blocks are okay. How is it? --Rezyk 20:36, 11 December 2007 (UTC)

The new version is fine. -- Gordon Ecker 22:46, 11 December 2007 (UTC)

I am ok with the new version as well. --Xeeron 23:04, 11 December 2007 (UTC)

I fully support the principle of the current version. Technically, I think there are some refinements to be done. Backsword 02:38, 12 December 2007 (UTC)

Question

What is "Excessive disruption"? Backsword 09:23, 5 November 2007 (UTC)

It allows banning of jackasses who didn't clearly break any other policy. ~ dragon legacy 13:08, 5 November 2007 (UTC)

He does have a point though, this is not meant as a catch all clause, but to prevent people from stopping the wiki working. --Xeeron 15:36, 5 November 2007 (UTC)

I'd say probably define "excessive disruption" as "actions which make it impossible to edit or access wiki pages in a timely manner". (Aiiane - talk - contribs) 06:18, 13 November 2007 (UTC)

So for example changing a template like {{!}} without reason? poke | talk 09:26, 13 November 2007 (UTC)

An accidental change, no. Repeated changes, yes. (But that's not exactly a good example given the page is protected.) (Aiiane - talk - contribs) 09:28, 13 November 2007 (UTC)

Yeah, I know, but it's a good example of a often used template :P poke | talk 09:32, 13 November 2007 (UTC)

Concensus upon a specific case?

Concensus among which group? The sysops? Isn't this the arbitration comittee's job? -- Gordon Ecker 03:12, 30 November 2007 (UTC)

The community. (Draft edited to reflect this now.) Another catch-all, mainly for missed cases that are pretty non-contentious...and because direct community consensus should trump policy anyways. Heavily disputed important cases should still fall to arbcomm, I think. --Rezyk 21:00, 30 November 2007 (UTC)

IP blocks

I think there should be a cap on these, even for automated spam, due to IP address turnover. -- Gordon Ecker 00:40, 1 December 2007 (UTC)

I set it to 1 year max; feel free to adjust the value. --Rezyk 19:36, 10 December 2007 (UTC)

I agree with Gordon, and also think this reflects on the general layout of the policy. Our reasons for setting limits are not case dependent, that sort of things are handled by a general clause and the guideline, while listing specific instances means the policy may exclude needed blocks for violations of other policies. As an example, currently someone who keeps surreptitiously changing policies in violation of GWW:POLICY can only be warned or taken to arbcomm. That's only meant as an example, there may well be other cases. Therefor I'd prefer if we not list induvidual policies, but instead apply the limits to the general case, which is what we have in mind anyway.

As for IPS, I'd suggest a max of 2 weeks for the first offence, since dynamic IPs may be reassigned and accidentally open proxies closed. A year is fine for repeaters, as if they are still around after two weeks, they'd tend to be so for a lot longer. Tho' six months should be enough. Even static IPs get new users now and then. Backsword 03:15, 12 December 2007 (UTC)

Guideline

Maybe this should be better as a guideline? This would just show how long people get banned for what offense. We should make it a suprise on how long they get banned, no some policy showing what is the maximum that is allowed and what is not. — ク Eloc 貢 01:29, 11 December 2007 (UTC)

There is a guideline to work in tandem with this. - BeX 01:57, 11 December 2007 (UTC)

There was also some discussion on the "surprise factor" above. Also, consider that a recent 1 year ban on a user was based largely on some offenses that are listed here with a maximum of 1 month, yet is completely compliant with this proposed policy. Surprise. --Rezyk 02:18, 11 December 2007 (UTC)

Which is why I think this is a better thing as a Guideline than a policy. If we were following the policy, then Raptors would have been banned only a month, instead of a year. — ク Eloc 貢 02:33, 11 December 2007 (UTC)

What about the ArbComm exception? -- Gordon Ecker 02:49, 11 December 2007 (UTC)

I was expecting there to be an ArbComm exception in here anyway. - BeX 03:12, 11 December 2007 (UTC)

Criteria List

Just wondering whether it would be beneficial to have quick references for the various blocking criteria, similar to those used in the Speedy Deletion section of GWW:DP. This would be mainly to provide a consistent link for any blocking that takes place, e.g. You have been blocked for B2: Violation of GWW:NPA. --Indecision 05:27, 12 December 2007 (UTC)

No, the few instances that a user would be "speedy" blocked are ones which the reason is obvious even to them; anything more warrants at least a somewhat informative block reason and/or notification on their talk page. (Aiiane - talk - contribs) 05:39, 12 December 2007 (UTC)

My point was not to allow for "speedy" blocking, as that clearly shouldn't happen often. My aim was to provide a consistent and clarified reference so that people know exactly what part of the blocking policy they have been blocked under. Sorry to give the wrong impression. --Indecision 05:44, 12 December 2007 (UTC)

Hence the latter part of my response - there shouldn't need to be "item codes" or the like because blocks aren't speedy and thus a sysop should have no reason not to provide a plain-English reason for the block. (Aiiane - talk - contribs) 12:41, 13 December 2007 (UTC)

Loophole

Just noticed a line had been added about usernames. This one allows any sysop to permaban any user, as long as they give the reason that they don't like their username. Probably not the intention.

Is there a reason to treat usernames differently from other text strings? Backsword 09:06, 19 December 2007 (UTC)

OK, I replaced it with something that I think is closer to what was intended. Backsword 09:18, 19 December 2007 (UTC)

Hmm..it was more for covering accounts that are obviously named to cause problems, not for ones they "don't like". I figured that sysop discretion within "plainly offensive/disruptive" would be accepted as reasonable enough. I did a partial revert, but dropped the "offensive". Does that alleviate the concern?

It isn't just meant for (as you worded it) stuff covered by other policy. Consider things like obviously impersonating another user through font tricks, etc. The root reason to treat usernames differently than comments/actions is because the user generally cannot continue using the account without continuing to exacerbate the problem. I think it would turn out cleaner in practice to have something specifically targeting it.

--Rezyk 22:49, 19 December 2007 (UTC)

For your change to the Harassment line item, I didn't mean for it to directly reflect Guild Wars Wiki:Harassment harassment, but for covering whatever-harassment-really-is harassment, even if not precisely defined (like vandalism or personal attacks). Anyways, I've dropped the line for now because it doesn't really mean anything extra with that added clause, and because I think it's better left to be discussed as a potential policy change after this base policy is considered. --Rezyk 23:02, 19 December 2007 (UTC)

Sorry for not getting back on this earlier. Limited time this time of year. It'd be OK to go after cases not covered by policy but I think it needs to be defined. That's the purpose of administative rules after all; to decide what is disrutive and what is not. I was thinking about making it 'usernames that cannot be used without causing disruption', but that's just curcular, as it still doesn't define disruptive.

I was also trying to cover accouts created for spambots and such things. Names like "Qx5yd2" are not a problem in themselves, but there is no reason to not infiblock them. Not doing so only means they spam again once the block ends. Bots have infinite patience.

Did you have anything other than impersonation in mind? If not, perhaps we could just add that to policy violation? Backsword 21:51, 29 December 2007 (UTC)

Hmm... you didn't call for a definition of what "disruptive" is in some of the other drafts I've proposed. I think you will find "disruptive" something that you won't get consensus for is you try to define it. Shouldn't this be the part where sysop discretion come in? Disruptive is plainly offensive usernames. Disruptive is when borderline cases try to do disruptive things. Like "Qx5yd2", we won't outright block it immediately, because (1) it's not offensive in itself, (2) it's not disruptive in itself. But when it starts to do spam, if it's minor vandalism, a warning or a short block is the better option. If it appears to be a link spammer, then infinite ban is the option. The intent of whatever action a particular account takes should count for more. -- ab.er.rant 01:03, 30 December 2007 (UTC)

Don't worry, I sympathize regarding limited time. =) I tend to follow Ab.er.rant's view here. I suggest letting it fall under sysop's "reasonable discretion", even if it defies having a rigorous definition. I could come up with examples other than impersonation, but I think coverage would still fall short and I'd rather not spread the ideas. Much of it is trying to capture the "obvious intent" factor without making "obvious intent" a critical needs-justification point. If it helps, note that I qualified it as "plainly disruptive"...which should be (hopefully) less gray and less prone to argumentation, while still covering all the cases it needs to. Spambots named like Qx5yd2 should just be addressed as a spam bot case. --Rezyk 22:31, 31 December 2007 (UTC)

Open proxy

I've added this in response to the discussion at Guild Wars Wiki talk:No open proxies. -- Gordon Ecker 01:10, 4 April 2008 (UTC)

General misconduct

I've added this in response to the discussion at Guild Wars Wiki talk:Adminship/draft B#Discretion. The "general misconduct" criterion is intended as a stopgap measure to handle problem users until a bureaucrat can issue an injunction. -- Gordon Ecker 01:10, 4 April 2008 (UTC)

Reviving

Is this ready to move out of the draft stage and be formally proposed? Is it missing anything? Are there any flaws or loopholes? -- Gordon Ecker 01:20, 4 April 2008 (UTC)

The only thing I can think of that's missing is an "emergency" provision - something that isn't listed but would best be served with a (short) block, i.e. less than a day, but just to allow communication to occur (for instance, someone doing massive, but well-intentioned edits of templates causing major site slowdowns accidentally - a short block, say an hour, would give time for them to notice messages et cetera). (Aiiane - talk - contribs) 03:07, 4 April 2008 (UTC)

I think that short blocks to stop good faith bad edits and unintentional technical disruption could be covered by "general misconduct". -- Gordon Ecker 03:40, 4 April 2008 (UTC)

Misconduct in general implies malice. (Aiiane - talk - contribs) 05:31, 4 April 2008 (UTC)

Yeah, it has that connotation, but it could technically cover any inappropriate behaviour including honest mistakes. I can't think of a better term, most of the synonyms are either too obtuse, too narrow or have stronger connotations of culpability. Could you write up a separate emergency provision? -- Gordon Ecker 06:36, 4 April 2008 (UTC)

"Evading a block, or claiming/emulating the identity of a blocked user" Extend the original blocked users sentence as they are going around a block, which should count as a block in the sense. — ク Eloc 貢 06:23, 4 April 2008 (UTC)

How are we supposed to determine whether it's the blocked user evading a block or someone else impersonating the blocked user? -- Gordon Ecker 06:36, 4 April 2008 (UTC)

Hmm, good point, that would just cause a loophole, nvm. — ク Eloc 貢 07:02, 4 April 2008 (UTC)

I haven't read much of the discussion here, but purely going by what's in the proposal, I'm opposed -- at least, as a policy. I think it's just another example of policy trying to cover every case and not leave "special occasions" counted for. I also don't think we need this policy, it's seems to me that it's something created because it could be created, not because it was needed to be created.

If, however, most people agree that blocking should be regulated in some way, I'd much rather see a guideline -- not something that restricts the sysops in special circumstances, or even in every-day circumstances. Heck, improve the admin policy if you really want sysops to be more restricted in how they perform their duties (which, by the way, I think Guild Wars Wiki:Adminship/draft B lets sysops have some "freedom", yet is careful with discretionary actions), but I certainly don't think something on this level is necessary. I agree with Gares's comment in the first topic in that users are made sysops because they are trusted -- this policy says to me that sysops may not be trusted and have to be told what to do. A guideline is better as it gives some.. well, guidelines to help and inform sysops of how they might deal with something, but doesn't go so far as to say "You must do this and that". -- Brains12 \ Talk 14:31, 4 April 2008 (UTC)

People have time and again argued that this would be better as a guideline (scroll up: Guild Wars Wiki talk:Blocking policy#Make it a Guideline, Guild Wars Wiki talk:Blocking policy#Make it a Guideline (revisited), Guild Wars Wiki talk:Blocking policy#Reasons why I dont like this as a policy (and want it to be a guideline), Guild Wars Wiki talk:Blocking policy#Guideline) and there is a Guideline proposal around. Some others have strongly argued that this needs to be policy, not guideline, thus the guideline has not been accepted either, but with this level of opposition, I feel the proposal is pretty much a dead duck, not going anywhere. --Xeeron 16:12, 4 April 2008 (UTC)

Yes, I was aware there were guideline suggestions and a guideline proposal. I thought I'd add to that argument. By not reading most of the discussion, I meant I hadn't read every single comment, just the main subjects and feelings behind each topic.

I would only accept a guideline if everyone else thought that would be prudent, I wouldn't argue zealously for one myself (unless I had to choose between policy and guideline). Personally, speaking as a user here (and above), I would prefer to leave things to consensus, sysop discretion and the administration policy. -- Brains12 \ Talk 16:31, 4 April 2008 (UTC)

I don't mind if this draft is pushed (and would support it without the recent changes to it), but I'd personally see if Adminship/draft_B passes first and then try a fresh approach. --Rezyk 00:23, 5 April 2008 (UTC)

Conversion to guideline draft

I've converted it from a policy draft to a guideline draft. -- Gordon Ecker (talk) 11:21, 11 November 2009 (UTC)

Don't like. Doesn't reflect practice, puts arbitrary limits on blocks, suggests those significantly higher should be reduced, only thinks in black and white instead of shades of grey. It attempts to be too instructive and restrictive, even if it's a guideline. -- pling 11:30, 11 November 2009 (UTC)

Yup, I agree with that. Nobody needs a policy or guideline on blocking.. Accepting this would just say that the sysops are too stupid to decide alone, or are not fair enough, or whatever. poke | talk 11:33, 11 November 2009 (UTC)

Oh, and btw: Guild Wars Wiki:Blocking guideline poke | talk 11:36, 11 November 2009 (UTC)

Lol? Admins are already a little too careful and you want to restrict them more? Misery 11:55, 11 November 2009 (UTC)

I don't mind the concept of a blocking guideline, but this one sucks. Needs a lot of work to reflect actual practice, to differentiate between factors that go into block lengths, and to make the language clear that the suggested block lengths are subject to change based on the sysop's appraisal of the situation. - Tanetris 12:10, 11 November 2009 (UTC)

'Maximum' block length is wording begging for trouble in the future. Misery 12:49, 11 November 2009 (UTC)

I forgot about Guild Wars Wiki:Blocking guideline. -- Gordon Ecker (talk) 03:33, 12 November 2009 (UTC)

Since none of us seem to want to make this a guideline or policy and there isn't any inactive draft guideline tag, I've restored the inactive policy proposal tag. -- Gordon Ecker (talk) 01:16, 16 November 2009 (UTC)