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. *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. *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. —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

#	Current policy	This draft at the time of this writing (version 766226)	Some basic reason(s)/note(s)
1	The English language Guild Wars Wiki is administered by the community. New administrators are selected by a democratic process in the English language Guild Wars Wiki. There are two levels of adminship: sysop and bureaucrat.	The English language Guild Wars Wiki is administered by the community. There are two types of formal administrator status: sysop and bureaucrat.	Selection process details covered by RFA/election policies; people can now evaluate those to decide if democratic or not. Rewording for clarity and because bureaucrats now sysops; "levels" implies separation
2	(nothing)	This status is not intended to represent extra weight within community decisions or generally directing the wiki, nor is it a requirement for moderating or enforcing policy.	Capture some established culture and core principles here. Tried to word it to dodge the "technically wrong because of unintended natural extra influence" issue while still communicating the admins-are-really-just-users stuff.
3	ArenaNet is not formally involved in the administrator selection process. Community decisions may not be appealed to them. ArenaNet staff may participate in the administrator selection process just as any other contributor in good standing, but their opinions are given equal weight as other members of the community.	ArenaNet is not formally involved in the administrator selection process except where explicitly specified, and community decisions may not be otherwise appealed to them. ArenaNet staff may participate in the administrator selection process just as any other contributor in good standing, but their opinions are given equal weight as other members of the community.	Exception clause needed because of potential special role in elections.
4	Sysops are administrators who perform cleanup tasks (deleting pages, undoing page move vandalism) and can block accounts and IP addresses according to the rules of the Guild Wars Wiki policy. Sysops also protect critical or unusually contentious pages from editing.	Sysops are users that are also granted technical access to a few restricted features (including blocking users and deleting pages), and the additional responsibility of not misusing them. Actions that rely on this access must have a clear reason provided, and must only be performed in these cases (or else be reversed): As specifically allowed in any policy, e.g. deletion policy. In accordance with an arbitration ruling or injunction.	Technical difference explained/linked more clearly for those who aren't familiar, and to cover it all. Worded responsibility is just to avoid misuse; general responsibility of executing tasks should not be imposed on individual sysops, but rely on people filling niches as needed (the wiki way). Clearly include arbitration results.
5	Sysops are granted reasonable discretion, but they are expected to apply policy rigorously and respect consensus.	Like all users, administrators are expected to respect policy and consensus. 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 is seriously challenged by any user, 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.	Clearer and outlines path for disputed cases. Perhaps more open towards contradicting policy.
6	Sysops are expected (but not required) to provide a publicly reachable e-mail address or other means of private contact.	(nothing)	"Expected" is too strong a word if it's not required. Was going to switch it to "encouraged", but then it's really just up to the sysop anyways and could go into the Sysop guide or something.
7	Sysops are selected by a review process based on nominations. New nominations may be made by any contributor in good standing, and nominators may nominate any contributor in good standing, including themselves. The nomination is reviewed for a fixed period of time, after which a bureaucrat will assess the community consensus and appoint the nominee if the consensus is in favor. Sysops are appointed for life, but may voluntarily resign. Their status may also be formally examined by the arbitration committee. To start a new nomination, see Guild Wars Wiki:Requests for adminship.	The sysop selection (and reconfirmation) process is governed by the policy for requests for adminship. Any sysop may voluntarily resign the position at any time.	Some stuff generally covered in RFA policy now.
8	For a complete list of sysops, see Special:Listadmins/sysop.	See also Guild Wars Wiki:Admin noticeboard Guild Wars Wiki:Administrators (list of administrators) Guild Wars Wiki:Requests for technical administration Guild Wars Wiki:Sysop guide	Link to the manual list instead (which has a link to the automatic list within it). Added/organized more links that might be relevant to what one is looking for.
9	Bureaucrats have the power to appoint or revoke the administrative status of users based on community decisions.	Bureaucrats are sysops with these additional powers and responsibilities: Altering the assigned groups and administrator status of user accounts based on community decisions. This includes appointing or revoking sysops based on requests for adminship and managing bot status.	Explained/linked technical difference for those who aren't familiar. More general assigned groups control (such as bot flag control) included now too; never seemed to be an issue.
10	Additionally, the group of bureaucrats, as long as there are at least 2, form an arbitration committee, who are the final arbiters on the English language Guild Wars Wiki of user conduct (but not content decisions), including that of administrators. Bureaucrats are considered members of the ArbComm based upon the date the request for arbitration is made. If a bureaucrat loses his seat during an arbitration, he still acts as a member of ArbComm for that case until the arbitration is complete. Similarly, if a user attains a bureaucrat seat in the middle of an arbitration, he is ineligible to participate in that arbitration.	The group of bureaucrats, as long as there are at least 2, form an arbitration committee, which is conducted according to arbitration policy. The committee membership for each arbitration case is determined by the list of bureaucrats at the time of the request for arbitration (so gaining/losing bureaucrat status in the middle of a case does not result in joining/leaving the active committee for that case).	"final arbiter" identity covered in arbitration policy. Concise/organized rewording.
11	The group of bureaucrats is mutually exclusive from the group of sysops -- any status as sysop is temporarily revoked while appointed as a bureaucrat.1 Bureaucrats have some extra user rights, such as editing protected pages and viewing deleted pages, but are forbidden from executing page deletions/undeletions or user blocks/unblocks (although they may unblock their own account for arbitration purposes if necessary). While ArbComm injunctions and rulings may involve those, the enforcement of such is left to sysops. Any revoked sysop status is reinstated at the end of the bureaucrat term, or upon resignation. 1 The current wiki configuration requires sysophood for some rights that bureaucrats should have. Until this is changed, accounts for bureaucrats should retain the sysop tag in the database purely as a technical workaround.	One also gets sysop status temporarily during a term as bureaucrat.	Discussed in some other proposals. Don't want to soft-limit our pool of potential sysops/bureaucrats with "one or the other"; if they are good for contributing in a position, just have them. Note that arbitration policy now allows a single bureaucrat to be arbitrated by the other two quite naturally.
12	Due to their important role in the community, bureaucrats are held to a higher standard than sysops. All bureaucrats are expected to provide explanations for the use of their powers, and they are additionally expected to respond to any questions about their actions from anyone, including via e-mail. All bureaucrats are required to list a publicly reachable e-mail address.	They are expected to respond to any questions about their actions from anyone, including via e-mail. Each bureaucrat is required to give a publicly reachable e-mail address (listed below).	Explanation of motivation (first sentence) pretty unnecessary/obvious enough. Dropped the blanket "provide explanations" because I think it's covered well enough within each case (and some cases, like clearly accepted/rejected RFAs, don't need it).
13	Bureaucrats are generally appointed for fixed terms of 6 months from their date of appointment. The terms are staggered to have at least one bureaucrat active at all times. New bureaucrats are elected to an open position by community-wide open elections. Bureaucrats may run for re-election arbitrarily often. Any contributor (even non-administrators) in good standing may run for an open position. See Guild Wars Wiki:Elections for a description of the bureaucrat election process and a list of current open elections. Bureaucrats may resign at any time. Sitting bureaucrats can only be removed by unanimous votes of the other bureaucrats.	The bureaucrat selection process is governed by the policy for elections. Bureaucrats are generally appointed for fixed terms of 6 months from their date of appointment, with the term periods being staggered to have a functional and unchanging subgroup during the transitions. Bureaucrats can only be removed before their term end by voluntary resignation (which may be done at any time) or by unanimous votes of the other bureaucrats.	Some stuff generally covered in election policy now. Reworded/organized for conciseness.
14	(list of current bureaucrats)	(table of current bureaucrats)	Cleaner and easier to understand munged e-mail addresses.

--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 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 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? *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 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. -- 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. *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. -- 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):

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.

2. 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.

3. 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.

Your example seems a lot like No2 or even No1, but that sentence only applies to No3. --Xeeron 20:27, 30 March 2008 (UTC)

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? -- 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 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. -- 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:

• 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.

Indeterminate / absence of supporting 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".

Contradict written policy:

• 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...

Not an "action":

• Viewing deleted pages.
• Looking at the list of unwatched pages.

Doesn't "rely on" the relevant access:

• Rollback without "&bot=1". (Can be simulated with plain user access..)

--Rezyk 00:12, 1 April 2008 (UTC)

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? -- 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. -- 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.

—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 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. -- 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)