Guild Wars Wiki talk:Adminship/draft E

Case law

I don't like this part:

"At their own initiative when they believe it would be supported directly by community consensus (regarding the specific change/action). If this discretion is exercised and the expected consensus is seriously challenged by any user, an actual consensus needs to be established and implemented or the action(s) should be reverted. In challenged cases that are disallowed by other written policies, the action(s) are to be reverted while that consensus is not yet established. If doing something under this point for previously undocumented or rejected reasons, the sysop is to have this action noted on the page set aside for this."

It would allow the accumulation of case law, resulting in clutter. Furthermore, if an action was performed for a specific reason, documented and not challenged, or challenged but ultimately supported by concensus in that particular case, similar actions action could be performed for the same reason any number of times with no further obligation of documentation. The rest of the proposal is fine. -- Gordon Ecker 21:33, 29 April 2008 (UTC)

Gordon covered one of my main concerns. I've been trying to figure out how you intended this otherwise (and tend to believe I am just missing something) because it seems like this draft actually exacerbates the issues brought up before about nonwritten policy. Personally, I don't even directly care to keep the obligation of special documentation (I only want it indirectly in seeking the best consensus), but with this I am more afraid of ambiguity becoming an issue over what is considered "documented" regarding similar/related cases. And then this trigger potentially driving people to challenge cases (to avoid "case law" effect) where they needn't otherwise do so. Also, the other side of it is the extra logging action expanding to everything-not-covered-already. I could see asking people to accept it as fair (even if disliked) for stuff we've written as disallowed...but I strongly dislike expanding it so far. But go ahead and see what others think. --Rezyk 22:10, 29 April 2008 (UTC)

I agree that the documentation requirement is overly broad. I think that "If doing something under this point for previously undocumented or rejected reasons" should be replaced with "If an action is disallowed by other written policies". -- Gordon Ecker 22:31, 29 April 2008 (UTC)

Hmm, not quite sure what you are concerned about what you write 'Case Law', but I think I think you are wrong. Both B and E would allow that, this proposal just makes it more organised. In fact, that is intended to reduce clutter in a way; by having it all in one place, and only mentioned once. The alternative is mentioned every use and spread out over a number of pages and logs.

You are right about your claim about "any number of times". That's the exact intention, as it happens. THe hope is to reduce the burden of documentation, eventually to near zero, while retaining the benefits. Do find this an issue? (No clear from your post) In the cases you mention, where people are OK with it being done, does it need extra documentation? Backsword 00:10, 3 May 2008 (UTC)

As I see it, the purpose of documentation should be to prevent potentially controversial actions from passing under the radar. If a sysop is doing something disallowed by policy frequently enough that documentation would be a burden, I think that the sysop should propose a policy change to include an exception for similar circumstances. By "case law" I mean "a body of rules automatically derived from decisions made for specific incidents". There's also the question of whether an action would need to be documented if similar actions in similar circumstances were chalenged and rejected in some cases and unchallenged or challenged and upheld in other cases. -- Gordon Ecker 03:08, 3 May 2008 (UTC)

Hmm, as I see it, such case law must necessarily exist in this context. Both this proposal, Rezyk's and DE's would have it. This is mainly about where and when it get's documented. It wouldn't be binding, of course, but the effect is still there, and, I think, unavoidable. The only way to avoid it would have every sysop action taken froma completly fresh standpoint, which we could only get by preventing sysops from being aware of the actions of any sysop. I think most find that undesirable, and impossible in the case of previous actions of that same sysop.

I can see 'under the radar' as one (of several) valid reason to require centralised documentation, but that is rather unconected to existing policy. Fo instance, we nowhere prohibit blocking for skin colour, which I'm sure you'd agree would be controversial, to say the least. This is almost always the case. So that reason would support this proposal better than the others.

You have a point in your last statement, which of course could also be aplied to draft B. I thinka rewording is called for, making it clear when which applies. Backsword 03:47, 3 May 2008 (UTC)

I don't think that "case law" is an inevitable result of documentation. Under this proposal, if an action is performed, documented and either unchallenged or challenged and upheld, the fact that the action was either unchallenged or upheld changes the rules by allowing similar actions to be performed in the future without documentation. Without the exceptions for actions similar to previously unchallenged or upheld actions, any previously upheld, unchallenged or overturned actions would not be rules, merely an account of the habits of sysops and other discretion log regulars, the actual rules would remain the same: every sysop action contrary to policy must be documented and every such action may be challenged and overturned. One significant problem with "case law" is that policy changes can be proposed at any time, while "case law" can only change in response to cases, with this proposal, that problem would be exacerbated because actions similar to those which have been upheld or unchallenged do not need to be documented, placing an unreasonable burden on anyone trying to overturn a precedent in favor of an action. -- Gordon Ecker 05:01, 3 May 2008 (UTC)

I wasn't clear; I meant it was unavoidable under this sort of sysop policymaking system, that all proposals are founded on. Documentation can only affect proples awareness of it.

Also, I think you may be missing that all admin actions, no matter the justification, fall under the "a clear reason must be provided" rule, that exist in both B and E. So when I framed this as 'documentation vs no dcumentation', it may have been misleading. It's more of 'Centalised documentation vs documentation on varisous, talk pages, noticeboards and logs'. That's also one reason it's only needed the first time; further uses of the same reason can simply refer to that first case, and still be as well understood. A made a change I think make this somewhat more clear.

Mainly, I don't think we are reallly talking about the same issues. As far as I understand both drafts, they are the same in what sysops may do (which is not quite the same as what you may think), but differs in 'awareness and information' aspects; the key point would be consideration on which acts pewople would be especially concerned to know about. And in my reading of people, that is when something controversial happens.

Additionally, I'll have to admit to not understanding what you mean by "changing the rules". Obviously all policydocuments are meant to do that, and all of them are conditional, so I'm not aware of a difference here. Backsword 06:29, 7 May 2008 (UTC)

The difference is that changing the rules through a policy change requires concensus support, while this proposal would make any administrative actions contrary to policy automatically change the rules to accomodate those actions as long as no one objects. In this case particular instance, the initial de facto documentation rule would be "any administrative action forbidden by policy must be documented in the sysop discretion log". If a sysop performs action X for reason Y and it goes uchallenged, or is challenged and upheld, the de facto documentation rule would change to "any administration forbidden by policy except action X for reason Y must be documented in the sysop discretion log". The only thing the second half of point 3 would actually accomplish is allow sysops to fast-track new speedy deletion criteria, because deletion is the only sysop user right explicitly forbidden by policy. The purpose of the discretion clause seems to be to give sysops something to point to when someone says "That's not fair, you're not allowed to block be for X.", the second half of the discretion clause is completely superfluous because we have no policy restricting blocking. Furthermore, a well written blocking policy would contain a discretionary block or emergency block clause, which would make blocks forbidden by policy completely unnecessary in any conceivable situation. I don't think that our adminship policy should be design to pre-emptively compensate for flaws which may exist in a hypothetical future blocking policy, but if we are going to do so, I think we should do so in a way which minimizes the impact on policies unrelated to blocking. -- Gordon Ecker 10:40, 7 May 2008 (UTC)

Hmm, I think you are making a mistake here, Gordon. GWW:DELETE is not the policy that's been under consideration there. I fear I may be at fault here, misrepresenting this on the talk page of B. But the delete policy is written as most of our policies are; autohrising sysops, not prohibiting use. It gives two criteria for when sysops may delete. But, as is the general case, that it shouldn't be done otherwise is left implicit. Strongly so, but it's never explicitly stated, besides four special points, which are there to clarify the speedy criterias.

Thus, unless it randomly happens to fall under one of those four, new reasons for speedy deletes do not have to use the log at all under B. (Once under E, and then refer to that one.)

I'm not really getting what you see the problem is with having conditional rules. All policies must be, really. The deltion policy does it to; it changes from 'don't delete under the general rule' to 'delete under the general rule' depending on an earlier action; if someone has tagged it three days earlier.

Asides, while I'm not directly against a blocking policy, this proposal is standalone, and in my mind not directly connected. Backsword 05:27, 8 May 2008 (UTC)

You are correct, the deletion policy does not currently contain any explicit restrictions, only strong implicit restrictions. I don't have a problem with conditional rules, situational or specific rules whych bypass or go around broader general rules, I believe that the current deletion policy is a great example of how broad general rules and narrow situational rules can work well together. But speedy deletion criteria cannot be added or removed without proposal, discussion and concensus. Under this proposal, any sysop action performed despite being forbidden by policy would change the rules automatically as long as it was unchallenged or challenged and upheld, resulting in the erosion of the restrictions on sysop actions in other policies and the expansion of the non-documentation rule, both of which could only be halted by active opposition. One potential problem I have not yet mentioned is actions which would be correct in one particular case, but would be bad as a general precedent, if actions forbidden by other policy for previously documented reasons used the same rules as actions forbidden by other policy for previously undocumented reasons (in other words, if all sysop actions forbidden by policy had to be documented in the discretion log), every sysop action (or group of actions with a single entry in the discretion log) forbidden by other policy would be treated as a special case with its' own unique circumstances, allowing more freedom. If any sysop action forbidden by policy which was performed and went unchallenged or was challenged and upheld automatically created a precedent, it would discourage sysops from taking otherwise appropriate actions due to the precedent they would set, and actions could be challenged due to the precedent they would set despite being otherwise appropriate. -- Gordon Ecker 08:53, 8 May 2008 (UTC)

(Reset indent) As I said on B's talk, this isn't really related to documentation. The rules for what sysops are allowed would not change by documentation. The documentation rule is as all others, for certain resaons, things should be done at some times, and not at other. One could debate if the condition is a good one, and that was what I did iwth Rezyk, but the point you raise here seems unrelated to that. Additionally, I think you may be reading that clause differently than me and Rezyk; I think B's version would not trigger in most cases, so the nondocumentation issue would 'grow' much larger there.

As for your second point, that's correct. It's intentional and the same as in all existing polices. My reading of the community is that the it's considered appropriate to apply the same rules to everyone, and the prefered tratment was undesirable. Quite some drama in the ArbComm case before about this. Also, it further illustrates why we are talking about different things; precedent is set with or without centralised documentation, and thus that dame in B and E. Backsword 15:56, 11 May 2008 (UTC)

IRL, precedent can only be set if there is room for interpretation (a law is unclear, two laws contradict eachother etc.), and if one of the laws a precedent is based on changes, the precedent is weakened or outright invalidated. This proposal goes far beyond that. -- Gordon Ecker 23:14, 11 May 2008 (UTC)

~

This is very true, and is what some see as important. It's changing paradigm from 'laws and enforcement' to what some proponents have called "Organically grown policy". (Perhaps it's good for the environment?). I'd point to Tanaric, but he's no longer around. Perhaps DE is a sufficent replacement. Backsword 13:17, 13 May 2008 (UTC)

Other stuff

Other stuff: Would strongly prefer to keep the sysop responsibility note for clarity. (Is it really any problem?) Am generally ambivalent about the bureaucrat impeachment requirement, but could it be slightly reworded to: unanimous votes of the other bureaucrats (as long as there are at least 2 others)? --Rezyk 22:21, 29 April 2008 (UTC)

You mean the tautology? I decompressed that to 'Sysops should not do what sysops should not do.' (Very MacIntyre of you.) If I got it wrong, and you meant something else, I'd probably be happy to include a reword. Backsword 23:52, 2 May 2008 (UTC)

The other change is fine with me, and Iäve included it. Though it only makes a differeance if we increase the number of bcrats, in which case wqe could have changed it then. Backsword 23:54, 2 May 2008 (UTC)

Bureaucrats

As I mentioned on Guild Wars Wiki talk:Adminship/draft B, I think that it should be mentioned that the three reasons outlined in the sysop section only apply to those user rights which are available to all sysops, not to user rights restricted to bureaucrats. -- Gordon Ecker 22:31, 29 April 2008 (UTC)

I don't think that would be a problem. But I'm unsure of what part you are refering to, as you haven't posted on B's talk since I copied the relevant part of B. Backsword 23:49, 2 May 2008 (UTC)

Made some changes in hope of addressing this. Backsword 06:07, 7 May 2008 (UTC)

Eh?

Was it really necessary to create a new draft for that instead of changing the draft B? poke | talk 20:31, 30 April 2008 (UTC)

Ha. Yah, I thought the same. Thus it not happenin until now. Backsword 23:50, 2 May 2008 (UTC)

A, B,... E?

What happened to drafts C and D?-- Brains12 \ Talk 01:14, 5 May 2008 (UTC)

Wait... draft A? All i see is:

• Guild Wars Wiki:Adminship/Draft-2007-9-16
• Guild Wars Wiki:Adminship/Draft_2007-11-14
• Guild Wars Wiki:Adminship/Draft_2008-Jan-12
• Guild Wars Wiki:Adminship/Draft_2008-02-06
• Guild Wars Wiki:Adminship/draft B
• Guild Wars Wiki:Adminship/Draft C
• Guild Wars Wiki:Adminship/draft E

There is no A :).--Fighterdoken 01:35, 5 May 2008 (UTC)

This is really meh! one-draft-only and discussion changes on that draft ftw.. Or if it is totally different, explain your idea on the policy talk page first if there are people even interested... poke | talk 01:36, 5 May 2008 (UTC)

Can we have less than ten drafts at a time? One is enough. You can discuss additional changes on that page. Calor 01:37, 5 May 2008 (UTC)

Draft A would really be the policy proposal itself -- whatever was accepted and is now the admin policy is draft A (although it's actually draft B because it was on that page, but still). -- Brains12 \ Talk 01:39, 5 May 2008 (UTC)

Speaking of drafts...

This one may need to adress the same issue as Guild Wars Wiki talk:Adminship/draft B#My Issues With This.--Fighterdoken 06:12, 7 May 2008 (UTC)

Am aware, and following the discussion there. One thing; while the protection tool is underused here, experience from wikipedia shows that it can be just as controversial. Any concerns there? Backsword 06:34, 7 May 2008 (UTC)

I don't really see problems with protections (be it from anons or total, as long as they stay temporal), even more, i would gladly agree to it. Not sure other users, though.--Fighterdoken 06:39, 7 May 2008 (UTC)

Draft B and understanding this draft

I've tried to keep a watch on this talk page and the draft page, but I'm not really sure how this is different to draft B. I'm probably not the only one. A clear summary of how this is different and how those differences affect the policy would be helpful.

Also, I'd rather see draft B implemented as soon as possible, instead of discussing and proposing this draft. I have a feeling that if we focus on this draft too much, draft B will never be implemented and the current policy will stay as it is. Once draft B has been implemented and its successes/failures accounted, then I might be willing to discuss another draft; even this one which seems to be almost the same, but reworded ever so slightly. -- Brains12 14:47, 13 May 2008 (UTC)

I don't even feel like reading this. It'd be nice to see some primary differences being written down or at least clarify as to which draft will conflict with which. -- ab.er.rant 17:47, 13 May 2008 (UTC)

Brains, this is the less radcial change, intended to be implemented without fuzz instead of B. We can then discuss the further changes B wants to do to documentation, or other proposals. (Tho' I'd rather not see B's new semirandom documentation system). Backsword 11:26, 14 May 2008 (UTC)

Differences with B

As B this is intended as a foundation for further change, it's even less of a end solution, as it doesn't seek to change how things are documented. The alterations are primarily to maintain the current situation there, while still allowing what I think many see as the main point: the third one under sysops.

Other things include a few clarifications Gordon asked for. I don't know how B handled those, so there may be further deviation. There is also a slight difference in the bcrats as sysops section. Backsword 11:26, 14 May 2008 (UTC)

Could you be a tad more explicit with the differences between the two? As in "B says blah, E says bleh. That will have an effect on X because of whatever." As Ab.er.rant says, I'd rather go with B. Unless I'm convinced and informed that this is better, I won't be bothering with this. -- Brains12 21:17, 15 May 2008 (UTC)

IMO the main difference is that draft B requires documentation in the sysop discretion log whenever a sysop takes uses their sysop user rights in a manner contrary to policy, while draft E only requires documentation in the sysop discretion log when such actions are taken for new reasons. -- Gordon Ecker 08:48, 21 May 2008 (UTC)

Clarification

According to the current draft:

"At their own initiative when they believe it would be supported directly by community consensus (regarding the specific change/action). If this discretion is exercised and the expected consensus is seriously challenged by any user, an actual consensus needs to be established and implemented or the action(s) should be reverted. In challenged cases that are disallowed by other written policies, the action(s) are to be reverted while that consensus is not yet established. If doing something under this point for previously undocumented or rejected reasons, the sysop is to have this action noted on the page set aside for this."

What does that mean?

1. If an action prohibited by policy is taken for a specific reason and that reason is rejected, then, later on, the same action is taken for the same reason and upheld, does it still count as a previously rejected reason because it was rejected in the past? If "prevously rejected" status depends on the most recent case, what would happen if two separate cases are resolved at roughly the same time, with one rejecting the reason and the other one upholding it?
2. If an action prohibited by policy is performed by one sysop and then undone by a second sysop (or the same sysop), and no one objects to the reversal, would the reason for the first action be considered a previously rejected reason?
3. Would it be possible to challenge the reason behind an action without challenging the action itself? What about situations in which the action cannot be reversed, such as image deletion or blocks which have already expired?

Could the draft be clarified to answer those questions? -- Gordon Ecker 08:48, 21 May 2008 (UTC)

These issues were rendered moot by this edit. -- Gordon Ecker 09:03, 23 May 2008 (UTC)

Actually, point three is still pertinent to both the current draft and to draft B, as both allows it.

I'd say yes, you could. You would logically have to have some other reason for wanting the action to be upheld, so the question there would be answered by whatever that reason was, while the original reason would be as rejected as any other reason. I think this answer stays the same whether you consider this version, earlier version or draft B. Backsword 09:48, 23 May 2008 (UTC)

Why the revert of the implementation?

I would just like to know why the implementation of this was reverted.-- Wynthyst 16:57, 26 May 2008 (UTC)

User talk:Backsword#Adminship poke | talk 16:59, 26 May 2008 (UTC)

ooops... wrong draft... my bad-- Wynthyst 17:00, 26 May 2008 (UTC)