Guild Wars Wiki talk:Adminship/draft B/Archive 2

Reasons
Could we have some reasons for this draft and how it might be better than the current policy, and ongoing proposals? At the moment I see it as a clearer, perhaps slightly more constrained, version of the Guild Wars Wiki:Adminship/Draft 2008-02-06. -- Brains12 \ Talk 20:44, 24 March 2008 (UTC)
 * (ec) In particular, formatting aside, could someone explain how, in practice, this would differ from this? The obvious difference that I can see is (to some extent) the manner by which discretion can be contested, but I'd like to know if I'm missing any major elements. [[Image:User Defiant Elements Sig Image.JPG|19x19px]] *Defiant Elements*   +talk  20:45, 24 March 2008 (UTC)
 * Also, what constitutes a verification of consensus? From what I've seen of "consensus" on this wiki, I'm inclined to believe that if say... a block were contested, by the time any kind of consensus was reached, the block would almost certainly have expired.  [[Image:User Defiant Elements Sig Image.JPG|19x19px]]  *Defiant Elements*   +talk  20:50, 24 March 2008 (UTC)


 * No formal definition is given, but it should be analogous to the consensus required in GWW:POLICY (though perhaps quicker since the consensus is expected). Besides, if the expected consensus was reached, the block term would be left alone anyways. =) --Rezyk 07:05, 26 March 2008 (UTC)


 * Brains, the primary differeance in the sysop section is that effective power is not transfered from the group of users to the group of sysops. The primary difference in the bcrat section is that he goes further than DE and makes them full actrive sysops. Backsword 09:04, 25 March 2008 (UTC)


 * The draft is still being worked on, but I'll try to answer some of this. This is mainly something that attempts to be much clearer overall, and especially in precisely attempting to fulfill these various demands: powerful admins with open-ended discretion when necessary (bureaucrats), sysops that can discretionarily act immediately along consensus without waiting for policy, and a system that generally keeps consensus as the core decision-making process.
 * Giving a thorough comparison to other adminship proposals/policy is somewhat difficult because it appears that there are still some widely varying interpretations of them. I'll give one example: I tend to agree with Xeeron that your description here arguably fits current policy (and this draft) much more than Draft 2008-02-06. I see Draft 2008-02-06 as having disputed decisions generally fall to an arbcomm opinion-vote, effectively making the wiki a representative democracy rather than decision-making based on consensus.
 * So it's really something that is (hopefully) much better in terms of clarity, with the other benefits listed above depending on how each reader interprets the other proposals/policy.
 * --Rezyk 06:39, 26 March 2008 (UTC)

My small change in the discretion part: The old version did not clearly specify what happens while consensus is being discussed. I added a part that to the effect that actions that contradict policy and are not backed by consensus are always to be reverted while discussion is ongoing. --Xeeron 13:52, 27 March 2008 (UTC)

I'm not quite sure how to put any of this into a wall of text, but I'll just say this draft looks good. I'm watching this talk page so if anyone brings up some good/bad points I'll likely put more of my two pennies in. -- Brains12 \ Talk 15:22, 29 March 2008 (UTC)

2
I was a bit surprised on how synced we are. I was considering floating something very similar with regard to the sysop role. Less formal and a bit less drastic. Perhaps I should write up a proposal too? Two propsals are never enough.

When considering this I was struck by hopw well our control system fits such a system. Better than it does our current one in fact. If a sysop claims consensus when there are clear reason to think otherwise, and people suspect abuse, ArbComm is perfectly suited to handle it. And the more likely scenario where a sysop keeps getting it honestly wrong, causing a growing feeling that they're not cut out for the job, well, that's just what reconfirmations were designed to dela with.

I'm glad to see you've taken some steps to deal with the issue of unwritten policy, as both your and DE's proposal would lead to the creation of a body of such. Yet it's an issue that hasn't sen any discussion. At all. The power transfer point have had long and infected debate, and there has been mentions now and then about the difficulty of taking initiative, but nothing on the desirability of this. Backsword 09:36, 25 March 2008 (UTC)
 * Up to you, but if it's a similar core to this one, we could try the collaborative-editing-thing on this draft. Just edit it up and I'll do the same; if it doesn't work out I'll either kick you out to your own draft or move out myself. =) (Btw, there are at least 4 proposals around now.) --Rezyk 07:14, 26 March 2008 (UTC)
 * If I understand you correctly, I really don't deserve any credit for providing a decent impetus to turn unwritten policy into written policy; I'd take it as a natural benefit of a consensus-driven system. --Rezyk 18:04, 26 March 2008 (UTC)

I like this draft quite a bit. It's concise and provides the features a working adminship policy needs. &mdash;Tanaric 00:39, 27 March 2008 (UTC)


 * Initially, I thought I'd put up a full review of all adminship proposals, but I decided against that, for the simple reason that most other proposals are either very similar to this one or inactive. I like this proposal a lot, mainly because it simplifies and clarifies many points also present in the current policy. While I feel that almost everything in this policy is already backed by the current policy and also currently handled that way, it helps to put it into the policy in a clear, easy to read manner. --Xeeron 13:48, 27 March 2008 (UTC)

Main differences with current policy
Since people might not be willing to read the full diff, I'll point out the two main differences (apart from much rewording/simplifying/reordering):
 * Bureaucrats are now full sysops
 * Sysop discretion is fleshed out and a way how do deal with conflicts about that discretion included. --Xeeron 13:45, 27 March 2008 (UTC)

Here is a comparison that covers every individual line of policy text in current policy and this draft. I ask that evaluators read and evaluate the written draft directly first -- mainly because that is the form in which people would end up reading it. Then come back and use this table to scour the list of changes more thoroughly. And please don't make this form of diff into an expected practice of policy writing.. =P --Rezyk 19:23, 27 March 2008 (UTC)

Discretion

 * "A sysop has the discretion to make such actions according to whatever he or she believes would be supported directly by community consensus, even in the absence of or in contradiction to written policy. However, 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 contradict written policy, the action(s) are to be reverted while that consensus is not yet established."

IMO allowing sysops to violate policy based on hypothetical concensus is overkill. If we are going to allow this level of discrution, I believe that sysops should be obligated to document such actions on a page similar to the admin noticeboard in order to make them easier to keep track of and dispute. -- Gordon Ecker 01:32, 29 March 2008 (UTC)
 * I'm not sure about it being overkill, but should there be provisions for what should happen after a consensus is reached on whether to uphold or revert? Such as requiring policy changes? But overall, I like the brevity and clarity of it. -- ab.er. rant [[Image:User Ab.er.rant Sig.png| ]] 08:05, 29 March 2008 (UTC)
 * I put in the line about reverting with just that thought in mind Gordon. There are some few instances when it is reasonable to breach policy (since policy is never perfect), but of course we never want trigger happy sysops doing what they want with no regard to policy. With the revert rule as it stands, any dissent about the action will lead to it being reverted immediately, meaning only actions with are uncontested will be allowed to stand. I feel that puts enough of a check on sysops to stop them from circumventing policy should the community not agree. --Xeeron 12:00, 29 March 2008 (UTC)
 * I believe this is a good change as it closes a loophole some vandals would use in the past, "but it isn't written down anywhere" before a policy existed to cover their actions. It definitely would allow a greater flexibility of the sysop position without being trigger happy because of the revert clause. -- Lemming [[Image:User Lemming64 sigicon.png]] 13:11, 31 March 2008 (UTC)
 * If we try to require policy change afterwards, but don't put the responsibility on anyone specific, it wouldn't be any better than leaving the drive up to natural incentives instead (and would be fluff in the exceptional cases that don't need it). And putting the responsibility on anyone specific would be rather onerous. So it's something I would avoid codifying despite being what we would generally want. (Maybe just mention the path if it's felt that the idea is not obvious enough.) --Rezyk 17:17, 31 March 2008 (UTC)
 * Hmm..I see one of the main functions of this discretion being "cutting through some potential wikilawyering by allowing consensus to easily override policy here", and because of that am hesitant to build up mechanical distinctions between "breaks policy" and "doesn't break policy" in the discretionary clause. What if we added something like "be made visible in some appropriate public log (usually automatic)" to the rules along with "must have a clear reason provided"? Could you take those together as ensuring enough easy visibility for open review, even though sysops would still not be obliged to package up the "breaks policy" actions separately? --Rezyk 18:25, 31 March 2008 (UTC)
 * As long as sysops are required to list and provide rationales for policy-contradicting discretionary actions in a public log, I don't think that there would be a problem. On the other hand, I think that it would be more appropriate to cover discretionary blocking, deletion and protection in the blocking, deletion and protection policies to keep all the rules in one place. -- Gordon Ecker 01:24, 3 April 2008 (UTC)
 * I prefer to not involve further organizational cleanup of that level within this particular iteration of proposed change. Is this new draft version generally acceptable to you regarding the main issue here? --Rezyk 02:36, 3 April 2008 (UTC)
 * No, the current version would allow actions which contradict policy to be buried in the automatic logs. I think that only a separate, manually updated, watchlist-compatible log for such actions would be sufficient. The current proposal would also technically add unnecessary red tape to the rollback user right, making rollbacks counterproductive. -- Gordon Ecker 04:16, 3 April 2008 (UTC)
 * How about this new version? Note that said actions could still be only buried in automatic logs if the contradiction is purportedly unknown. I also tried to reword stuff to more clearly exclude simple rollbacks, viewing deleted pages, etc. --Rezyk 19:30, 3 April 2008 (UTC)
 * I'd prefer a centralized log / notice board, and I don't think the authority to act outside of policy is necessary (particularly now, when we don't even have a blocking policy), but if we are going to give sysops the authority to act outside policy, the current draft is acceptable. By the way, in response to this discussion, I've added a "general misconduct" criterion to the draft at Guild Wars Wiki:Blocking policy. -- Gordon Ecker 01:15, 4 April 2008 (UTC)


 * As I see it, the difference between changing current rules and creating new policy is mostly semantic. And change could be seen as creating a new rules, that just happens to include obsoleting an old one. Any new rule could be seen as changing policy from it's default state of 'allowed'.


 * I guess the concern would be that when an policy is accepted, there is a concnsus for it, so such an initiative must autmatically go against it, in which case you'd need to have evidence that it had changed to something new, which you could only have if the issue had been discussed and led to a new concensus and in that case, the policy is changed anyway. But I think that scenario is already covered.


 * Instead, I that line as being relevant to dealing with what you could call 'unintended sideeffects' of a policy, where there has not been any consensus but it's still in the policy document. Going against that should be no different from a situation where no document exists. I'd even argue that such a policy is no policy, since it never had consensus support. Backsword 00:52, 5 April 2008 (UTC)

Anyone have any strong issue with the current version for this matter? --Rezyk 01:31, 4 April 2008 (UTC)


 * I think the current proposal would be acceptable, and I will not oppose it, but I'd prefer a different discretion clause, something like this:


 * A sysop has the discretion to make such actions according to whatever he or she believes would be supported directly by community consensus as long as those actions do not contradict written policy.
 * The discretion clause seems to be in response to blocking-related drama. This would explicitly authorize sysops to block, unblock, protect, unprotect and undelete however they see fit unless they are restricted by some future policy without the red tape or speedy deletion authority of the current version. Discretionary blocking can be specifically addressed in blocking policy policy proposals. -- Gordon Ecker 08:33, 19 April 2008 (UTC)


 * Also, I think that it should be clear that the discretion clause only applies to sysop user rights, not to user rights restricted to bureaucrats. -- Gordon Ecker 09:01, 19 April 2008 (UTC)

Bureaucrats
Since bureaucrats are proposed to be full sysops (which can be a good thing), do we now have a hierarchy where a user should first be a sysop before being a bureaucrat? Also, again because they are now sysops, would it be of concern that bureaucrats may now arbitrate issues that they themselves have been involved in as a sysop? -- ab.er. rant  08:14, 29 March 2008 (UTC)
 * To be honest, although there are different standards for becoming a Sysop and becoming a Bureaucrat, if the community elects a non-Sysop to be a Bureaucrat, I'm inclined to think that they've demonstrated enough trust in that user that it's not such a stretch to grant them Sysop authority as well (at least for the duration of the Bureacratship). And, from a practical standpoint, has a non-Sysop ever actually been elected to Bureaucratship on this Wiki?  [[Image:User Defiant Elements Sig Image.JPG|19x19px]]  *Defiant Elements*   +talk  22:37, 29 March 2008 (UTC)
 * Dirigible? (No points made on anything else than answering your last question with "yes" :P) - anja  [[Image:User Anja Astor sig icon.png|talk]] 23:05, 29 March 2008 (UTC)
 * I agree with DE. Even if "sysop first" is what we might generally expect, it's (again) something that we should not codify without a stronger reason, especially due to the potential for exceptional cases. Leave it up to voters to enforce it or not with their vote. Concerning bureaucrat in an arbitration case + their involvement as a sysop (or user!!), there is some strong obligation, depending on interpretation of arbitration policy, for the individual bureaucrat to simply abstain if the involvement could create an unfair bias (though there is some gray area because that is not the only principle at work and cursory involvement might not be enough to warrant abstaining). If you mean regarding a hard check for a more roguish bureaucrat, note that 2 bureaucrats can still drive through a ruling against a 3rd who does not abstain appropriately. --Rezyk 18:41, 31 March 2008 (UTC)


 * It doesn't change anything technically. But as you mentioned on DE's proposal, these sort of changes are rather seperate from the others. They could do with an discussion of their own, especially as the proposal as a whole could be held back due to seperate parts. With peoples focus being on sysops, this isn't getting much attention. Backsword 00:57, 5 April 2008 (UTC)

Clarification
Regarding the discretionary clause: (it's a poor example I know, but) let's say that a vandal is blocked by Tanetris for 3 days. For some obscure reason, the ban is challenged, and the vandal is unbanned for the duration of the discussion. Now, while the discussion is ongoing (and I'm still a little worried about the sheer time it may take to establish consensus) the vandal is blocked again. In this instance, the ban is incontrovertible, and like the original ban, it lasts for 3 days. Now, a week later (by which time the vandal's second ban has expired), consensus is reached that the first block was the correct course of action. In this instance, is the vandal blocked for another 3 days or is the original nullified by the second ban? It seems like a small point, I know, but I feel like there's the potential to get into all kinds of these mini debates under the current proposal. Also, what constitutes a serious challenge of expected consensus? If Readem is banned for trolling Izzy's user page, and a few user who support Readem's views challenge the ban, does that constitute a serious challenge? If so, while that's begin debated, do you allow Readem to continue trolling?

In general though, I'm pretty happy with this proposal. *Defiant Elements*  +talk  17:03, 29 March 2008 (UTC)
 * I'm not sure if I'm reading it right, but if something is enacted in absence of written policy, then the action can still be upheld/doesn't need to be reverted, but consensus should be sought if the action is challenged - if consensus is reached and it's against said action, then said action should be reverted (although, if it's a short term block, that probably will have no effect). If, however, the action contradicts written policy, then it has to be reverted until consensus supporting the action is reached. Using your examples, blocking for trolling or vandalism isn't forbidden by any policy so it doesn't require the action to be reverted if challenged. If someone blocked Readem for not personally attacking someone, thus contradicting NPA, then that block should be reverted until consensus says Readem has to personally attack someone. (Again, using arbitrary examples.)
 * I have a feeling I'm seeing this wrongly, so clarification would be nice. --[[Image:User Brains12 Spiral.png|15px| ]] Brains12 \ Talk 17:22, 29 March 2008 (UTC)
 * From what I understand of the policy, whenever an Admin uses discretion (i.e. acts in a manner that is either contradictory to or not defined by policy) there's the potential for their action to be challenged, and while that action is being challenged/discussed, it is reverted until a proper consensus can be achieved. I couldn't think of a great example of a block that would be contested, so my example presupposes that for some arbitrary reason, an Admin is forced to use that discretion to block a vandal, and that discretionary action is challenged.
 * As I said, I realize it's a bad example, but I'm trying to get a grasp of the practical nature of this policy. [[Image:User Defiant Elements Sig Image.JPG|19x19px]]  *Defiant Elements*   +talk  19:12, 29 March 2008 (UTC)
 * Hmm, I think the "However, 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 contradict written policy, the action(s) are to be reverted while that consensus is not yet established. " parts need to be cleared up slightly. I see it as quite ambiguous in that it only mentions the challenged actions which contradict policy need to be reverted, not necessarily unwritten policy. --[[Image:User Brains12 Spiral.png|15px| ]] Brains12 \ Talk 19:18, 29 March 2008 (UTC)

Also, regarding the "consensus:" these kinds of discussions can go on for quite a long time in my experience, and one of the benefits of Admin discretion is that it allows for (potentially) faster decisions. Are we ignoring that possible benefit? And what happens if the discussion is thoroughly deadlocked? Does ArbComm become involved in such instances or if a decision cannot be reached period, is the discretionary action reverted (since no consensus was reached to institute that action)? And, in a more general sense, what is the role of ArbComm under this policy? *Defiant Elements*  +talk  22:34, 29 March 2008 (UTC)

Ok, there are 3 possible cases of challenged blocks, I'll explain my reading of said sentence (btw, substitute block for any discretionary action): Your example seems a lot like No2 or even No1, but that sentence only applies to No3. --Xeeron 20:27, 30 March 2008 (UTC)
 * 1) Block is directly backed by policy (e.g. the vandal) and challenged.
 * Block stands. Only if after discussion there is consensus that there should not be a block is the offender unblocked.
 * 1) Block is for something not mentioned in policy (e.g. blocking someone with the username "gwwsucks") and challenged.
 * Block stands. Only if after discussion there is consensus that there should not be a block is the offender unblocked.
 * 1) Block is directly contradicting policy (e.g. blocking someone for voting in a RFA) and challenged.
 * Block is reverted. Only if after discussion there is consensus that there should be a block is the offender reblocked.
 * Ah, I was closer than I thought. Perhaps the line could be changed slightly to show that only contradictory acts of discretion need to be reverted if challenged? --[[Image:User Brains12 Spiral.png|15px| ]] Brains12 \ Talk 21:17, 30 March 2008 (UTC)
 * I'm not keen on using "only", and not allowing for a little leeway for odd situations, but I'm OK with that clause. Anyone have anything to add into that?  Calor  [[Image:User_Calor_Sig.png|19px|Talk]] 21:21, 30 March 2008 (UTC)
 * Well the particular sentence needs to be made a little clearer in some way, so anything else that does it is ok. --[[Image:User Brains12 Spiral.png|15px| ]] Brains12 \ Talk 21:25, 30 March 2008 (UTC)

Here is how I see some of this stuff, (but don't take my word for it): "In this instance, is the vandal blocked for another 3 days or is the original nullified by the second ban?" The checking should be about whether the original block is supported, not whether to do it again. That said, if consensus is actually to block for another 3 days, then so be it. If a user is banned for trolling another's user page, and a few users who support his views challenge the ban, does that constitute a serious challenge? Yes, with the minor point that the "challenge" should be about whether or not there would be a consensus, not simply whether one agrees with it. The sysop believed there would be a consensus, while a challenger does not. In the case of challenged discretion without contradicting policy, "an actual consensus needs to be established and implemented or the action(s) should be reverted". So if no consensus is established (deadlocked or whatever), the action(s) should be reverted. When exactly that should happen: this draft does not specify. I'd hope that it's clear enough that the intention is to have discretionary sysop actions stand only if okay by consensus (but allowing for that implicitly by lack of challenge), and some sysop just reverts if it's obvious enough that there won't be a consensus anytime soon. Or if after being challenged, the discretion-ing sysops feel they may have simply been mistaken, they can just revert and we don't have to officially establish a consensus. If sysops lawyer up against this spirit and push the boundaries to follow what they can get away with rather than following consensus, then we may have a need to iron out some seriously unwieldy bureaucracy to keep discretion in line (this time for real). ArbComm's role within this process, as far as user conduct cases, is to potentially intervene with their "discretionary faster decision" only when they believe it is necessary enough (and it is requested). What/when qualifies as "necessary enough" ultimately falls to how they interpret arbitration policy, and is a balancing point for evaluating how far our having an ArbComm bends/breaks away from a consensus process. (If they were to always reliably intervene/decide whenever there was no consensus, this would just be a wiki dictated by the bureaucrats.) In terms of mechanics, arbitration can be requested before/during/after/whenever the discussion, operates as an independent process, and can (if accepted) provide working decisions if it is a case of user conduct. Yes, "mini debates" and testing the boundaries of consensus may be an issue, especially in cases of blocking where timeliness and the inherent personal nature can strongly exacerbate it. That is one reason why I personally would have had blocks be specially more hard-limited than other actions, practically requiring policy/arbitration first and eating the slowness of finding consensus up-front rather than endless drama afterwards...but I digress. Anyways, ways to mitigate this are to get the unwritten policy written down, see if ArbComm believes their intervention is warranted enough, or to scrap the consensus ideal altogether (though that has larger ramifications). Specifically allowed in policy: Indeterminate / absence of supporting policy: Contradict written policy: Not an "action": Doesn't "rely on" the relevant access: --Rezyk 00:12, 1 April 2008 (UTC)
 * Blocking users who "insist on a confrontational style marked by personal attacks".
 * Blocking or protecting pages per 1RR.
 * Speedy deletion as given in deletion policy.
 * General deletion as given in deletion policy.
 * Blocking someone for vandalism.
 * Blocking someone for voting in a RFA.
 * Blocking someone for not obeying a sysop.
 * Someone knowingly kept making edits that break some guideline and is blocked for not abiding by consensus.
 * Blocking someone for putting an uncommon build in main namespace.
 * Quick deletion for some reason not given in deletion policy.
 * Rollback with "&bot=1".
 * Someone knowingly kept making edits that break some guideline and is blocked for not following a guideline.
 * A sysop undeletes his own user page into some version that has some content owned by ArenaNet that is not available under GFDL...
 * Viewing deleted pages.
 * Looking at the list of unwatched pages.
 * Rollback without "&bot=1". (Can be simulated with plain user access..)


 * I don't think this distiction makes any sense whatsoever. Partly because, as I emntioned above, the difference is mostly semantic, but mostly becuase our policies are not written in a way to support it. Our tradition has been to use an basis of things being allowed, and then resticting this with things that are disallowed. Anything that is mentioned as allowed are so incidently, often as clarification of some point. There is no comprehensive listing of things supported of allowed, there is no sytem to what happens to be mentioned as allowed. That makes the rule effectivly random, which is not a trait that is generally sought after in policy. Backsword 01:04, 5 April 2008 (UTC)
 * Sorry for not being clearer -- I meant to have the distinctions in relation to written policy, not tradition-policy. Updated the draft too. --Rezyk 02:21, 5 April 2008 (UTC)

Opinion/status check
Are there any remaining/new issues that we should discuss before implementing this?

For those who have reviewed the version proposed one week ago, here is a diff between that and this new version. How much do the changes alter your level of support? (Is it still acceptable?)

--Rezyk 17:26, 4 April 2008 (UTC)
 * As Gordon said above, I'd prefer a central log of the written contradictory acts. Most people probably don't have every policy page watchlisted, so the discussion process may be generally slow, which is not a good thing when trying to get an action supported or rejected. Something like Guild Wars Wiki:Administrator log, or a subpage of the noticeboard (i.e. /Log) perhaps? --[[Image:User Brains12 Spiral.png|15px| ]] Brains12 \ Talk 17:31, 4 April 2008 (UTC)
 * Do you feel that this change is necessary for you to accept this proposal? I will make this change if nobody else prefers this policy-talk-page-log-version, but wish to avoid this overly stalling the overall proposal if there is general disagreement. --Rezyk 17:39, 4 April 2008 (UTC)

Anything else? --Rezyk 17:39, 4 April 2008 (UTC)
 * It wouldn't stop my support of the proposal, nor do I intend for it to halt its acceptance, but I think it would be a good step in reaching consensus as soon and as easily as possible.
 * Nothing else. --[[Image:User Brains12 Spiral.png|15px| ]] Brains12 \ Talk 17:42, 4 April 2008 (UTC)
 * Okay, I'll give it a while in case anyone else prefers to not have the special log, and to see if there are any major issues for other changes. If not, I'll change it and try a re-propose/re-check. Thanks. --Rezyk 17:54, 4 April 2008 (UTC)


 * Does this put the burden on me to look up every potentially relevant policy and verify the specific wording relating to every act I perform as a sysop? Because, honestly, I'll just stop sysoping if that's the case -- that's way too much minutia for me to do my job effectively. It's easier to ask for forgiveness than to ask for permission -- also "Be bold!", and any other catchy one-line-summary of our ideals that tend to go against this sort of bureaucratic idea.


 * That said, this policy is still better than our current one, and so this complaint should not be taken as opposition to its adoption.


 * &mdash;Tanaric 19:00, 4 April 2008 (UTC)


 * I still support this policy change. While Tanaric is correct in noting that it places a burden on admins, I don't believe it is an undue one: Knowing our policies should be expected from them. --Xeeron 19:55, 4 April 2008 (UTC)
 * By my interpretation, the wording of this change conveniently dodges formalizing this burden because it only applies when a sysop knowingly contradicts policy, rather than simply whenever contradicting policy. However, it also does not suppress any such existing burden in the court of public opinion, and may somewhat heighten it in that regard as far as the potential for the unknowing-ness to not be believed. Also, do not take my word for it, etc. --Rezyk 20:19, 4 April 2008 (UTC)


 * I do not see this wording as changing the burden already put on sysops. We should know our policies quite well already, but "knowingly" removes the need for tiny details. And I cannot see a big ruckus coming out of it (kill me now :P) since I think all sysops have the judgement to see when an action is questionable and prepare for what may come out of it accordingly. - anja  [[Image:User Anja Astor sig icon.png|talk]] 21:05, 4 April 2008 (UTC)
 * By the way, I think Guild Wars Wiki:Elections/Draft 3 should be pushed along with this proposal as discussion plays a larger role in choosing the bureaucrat -- if this adminship proposal is accepted, the bureaucrat-election process may need to change as well, and I think the draft 3 would be better than the current ELECT. Voting should take a smaller role in the elections as the bureaucrat will become a sysop in addition -- so, essentially, the draft may become a typical election and RfA mixed in one, which I think is a good idea. --[[Image:User Brains12 Spiral.png|15px| ]] Brains12 \ Talk 21:50, 4 April 2008 (UTC)
 * I believe this draft's current discretion clause provides both sufficient flexibility and sufficient checks and balances. Replacing "Actions that rely on this access" with "When effecting a change that requires this access" eliminates the possible rollback and deleted page viewing loopholes. -- Gordon Ecker 02:01, 5 April 2008 (UTC)