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

I made this draft in response to some issues that were brought up in Guild Wars Wiki talk:Adminship, concerning bureaucrats/arbcomm consisting of sysops. The idea I have is basically that bureaucrat/arbcomm office does not need sysop powers to be effective. They can still make the big rulings, but leave it to sysops & users to enforce them. (Analogous to how the US Supreme Court cannot directly enforce its rulings.)

Currently I don't support or oppose this change myself, but I'm hopeful it could help with others' concerns and in reaching a stronger consensus.

I started this draft by copying Guild Wars Wiki:Adminship, and then revised it, so the diff in its history can be used to see all the changes. --Rezyk 21:59, 18 March 2007 (EDT)
 * For what it's worth, I actually really like this version =P Having a guard for the guards is always a good thing, so the if(bcrat) then !sysop makes sense to me. MisterPepe talk 23:36, 18 March 2007 (EDT)

Discussion
I have two concerns on this version. First, I still feel a one-year term for bureaucrats is more appropriate - that results in a new election/appointment process every six months. At six month terms, we have new appointments every three months - which seems a bit much to me.

My other concern is the line "Sitting bureaucrats can only be removed by unanimous votes of the other bureaucrats". This seems an unfair method given the current model of only two bureaucrats. I could see this if we move up to four bureaucrats; but that honeslty seems more that what we require for a wiki of this relatively small size. I would rather see a different removal process, I just have no suggestions for a change at this time. --- Barek (talk • contribs) - 12:00, 19 March 2007 (EDT)
 * As Barek said, having a 'unanimous vote' of the other one bureaucrat seems rather pointless. Practically speaking if a bureaucrat is going to have to be removed this'd almost certainly done by Anet.  There's nothing we can do to remove that ability from Anet... it's their wiki (their domain running on their servers) to pretend otherwise seems kind of silly... we shouldn't worry too much about the procedures to remove bureaucrats at this point I'm sure there are more pressing needs.  I have no doubt, if they do something to severely piss off Anet or try to royally screw up the Wiki then they'll be removed by Anet.   Vladtheemailer 13:22, 19 March 2007 (EDT)
 * If four is too much and two is too few, then go with three =\ An odd number would probably work better anyway. One-year terms makes sense, though. And really, does it matter all that much how many BCrats we have, if they're not sysops as well? MisterPepe talk 13:53, 19 March 2007 (EDT)

I like the idea of making sysops and bureaucrats mutually exclusive since it is a step away from sysops controlling themselves. The "top level" of the wiki should be directly elected by the users and concentrate on arbitration and control rather than performing normal sysop tasks. --Xeeron 13:30, 6 April 2007 (EDT)

Because Rezyk is a bureaucrat now, I've added him to the list. This should address concerns that "unanimous removal" is meaningless. Further, an odd number of bureaucrats is ideal -- I believe such a stipulation should be in the policy itself. That said, I believe this is a good proposal, and I fully support it. &mdash;Tanaric 03:41, 8 April 2007 (EDT)


 * This amendment does not sit well with me. I feel very uncomfortable with the idea of no longer being able to carry out daily tasks on the wiki, such as deleting articles, editing protected articles for other users, or blocking vandals. I understand the reason for the separation, and in principle I don't entirely disagree with it. My main concern is that this slows many processes down. Tanaric cannot decide that someone has acted unfairly and block them, he has to tell Barek to do it.


 * Maybe I'm not quite understanding the procedure. LordBiro 07:44, 8 April 2007 (EDT)
 * To be fair, the policy as written would allow bcrats to give themselves temp powers - while deletions and blocks are not allowed, it does specifically allow editing protected articles =P While it might slow things down a hair, in terms of enforcing arbcomm decisions, it avoids the whole "Quis custodiet ipsos custodes?” problem and leaves cleanup to the sysops. And, really, to be fair, there's pretty much always at least one sysop online =P Theoretically, it makes a lot of sense to me. Logistically, perhaps we have a couple kinks to work out -_- MisterPepe talk 14:21, 9 April 2007 (EDT)


 * I think most of your understanding is correct, and I share some of the same concerns (although mine are probably a lot weaker). I also find it pretty annoying to put a stop to my performing sysop tasks. =) Here's some more details on my thoughts:
 * It is something of a disadvantage/sacrifice for the wiki in terms of manpower. There would be 3 less users available for deletion/protection/blocking duty. In principle, however, we should be able to make up for any loss in manpower by just promoting more users to sysop -- although this is somewhat contingent on the size of the user pool, and on setting up the sysop role such that having lots and lots of sysops is really No Big Deal. This proposal can also lessen the pool of possible bureaucrats; a particular user could make a great bureaucrat but prefers to retain sysop powers. This is probably my main concern.
 * It does slow down and add steps to arbitration processes, but I see that as a little bad and more good. The problems that should really be handled fast and easy should already be made handle-able by sysops without needing to wait for a bureaucrat. For the controversial disputes over user conduct that require arbitration, things should be slowed a lot by it being a committee process rather than individual. So if there's a big dispute over someone allegedly acting unfairly or some other matter, things might pan out like this:
 * Dispute starts.
 * Someone asks for arbitration.
 * Individual bureaucrats might issue temporary injunctions, as a purely preventative measure against the dispute getting much bigger during the potential arbitration case.
 * Bureaucrats, as a committee, decide whether or not to accept the case.
 * If accepted, we go through the hearing, get statements from both sides of the dispute, etc.
 * Bureaucrats, as a committee, (and probably with some private discussion) decide what rulings to decree. Some rulings might only be favored 2-to-1 but still pass.
 * Sysops and regular users enforce the rulings as necessary.
 * Does this seem like too much process? I think it's worthwhile to deliberate this slowly for anything controversial enough to require arbitration. If things are too simple, we run the risk of having formed a general-decision-making position rather than an arbitration committee. The individual power of injunctions is hopefully open enough to work as imperfect-but-fast-enough temporary solutions for the worrisome cases. Having this process also helps lessen worries of injustice/corruption (whether or not they are justified). In your example, it seems better to me to let the final block be slow and obviously backed by at least 2 bureaucrats and 1 sysop, rather than fast and backed by only 1 bureaucrat. (Actually, isn't this the main point of having a committee in the first place?) What real advantage is there to fast blocking if there's no ongoing disruption?
 * I also hope to encourage more effective kinds of dispute-resolving measures with this. Straightforward blocking-for-bad-behavior is a simple but clumsy tool, and relied on way too much, so I don't mind seeing it made as hard as more precise/elegant solutions, like probations and bans against specific behavior. (Although I'm concerned more about future bureaucrats here rather than current ones. =) Anyways, that's my conception of where things should be headed; it hasn't all been worked into policy drafts, and much of it is just my personal opinion, but I'd like to know of any general disagreement and concerns.
 * Getting the correct set of user rights here to avoid loopholes and annoyances seems harder than I originally thought it would be. I'd like to leave bureaucrats with some ability to view deleted pages, edit protected pages, and unblock themselves (so they can't get locked out of their arbitration duties and have to grant themselves temporary sysop, which is a hack workaround), but it seems like those abilities are tied in with general deletion/protection/blocking abilities in MediaWiki. I'm still looking into this.
 * --Rezyk 17:03, 9 April 2007 (EDT)


 * Are the arbitration committee basically responsible for dealing with user disputes and similar requests? That is my understanding. Such situations arise rarely (or at least they are not that common). I understand that under this system bureaucrats would deal with more disputes than on GuildWiki, but even so I cannot see there being more than 1 user dispute taking place at any time, and I think it very likely that there will be considerable gaps between user disputes. Please correct me if you think I am underestimating!


 * Here is a scenario: Say there are 10 sysops. 3 sysops are promoted to bureaucrat status (I know anyone can be voted a bureaucrat, but I think it is likely that most bureaucrats will be elected from the group of sysops). It is very likely that at the 3 chosen sysops are the most experienced sysops who have proven themselves in dealing with day to day administration on the wiki. They now deal pretty much solely with user disputes and the like, which come up occasionally. In order to fill the gap, 3 new sysops must be chosen, who are undoubtedly less experienced than the 3 sysops who are now bureaucrats.


 * This scenario might be unrealistic or too simplistic (it's late here and I'm falling asleep). I realise this scenario doesn't really make too much sense if being a sysop is "no big deal", as you say.


 * Anyway, I'm going to sleep, good night :P LordBiro 19:37, 9 April 2007 (EDT)


 * I would generally agree that it's a plausible scenario, but with a few points (more as clarity rather than disagreement):
 * This is all under the presumption that people agree with my personal preference of the ideal bureaucrat/sysop role, and accept policy that eventually makes it a reality. I wouldn't claim that sysophood is currently no big deal -- it's just something that I'd like to see, and would lessen the impact of this proposed change (conversely, this proposed change may make it more important to see that happen). If it doesn't come to pass that sysops are essentially just users here, then I'd see both the pros and cons of this proposal as weighing more heavily (although in that case we might also have to worry more about other stuff, like sysop term limits).
 * I'd consider the committee basically responsible for dealing with disputes only when necessary enough. The heavy hand of arbitration should be something of a last resort, and I think it'd be fair/wise for the committee to decline handling some disputes when there hasn't been enough attempt at resolving it between the involved parties and/or the rest of community.
 * How much of that day-to-day administration really involves sysop powers? I'd consider 99% of the actual "administrative work" on this wiki as being handled at the user level, and mostly by non-sysops. They're the ones pointing out problems to new users and editing content to conform to policy and guidelines (and even when it's the sysops doing so, they can generally be considered as acting in regular user mode). The administrative contributions that really require sysop powers are comparatively few and far between. Consider the most common sysop power invoked: Page deletion is actually almost all work that can be done at the user level (identify reasons for deletion, tagging the article, discussing and reaching consensus). The sysop-only part is mostly just pushing the button at the end. (Is this point the main reason for the difference in our views?)
 * Instead of just 3 new sysops to fill the gap, we should get more as needed. Heck, get 10 new sysops if there's 10 good applicants. Is there good reason to keep the number of sysops small here?
 * --Rezyk 08:05, 10 April 2007 (EDT)

I as well feel uncomfortable with this structure you are proposing, Rezyk.


 * 1) First of all, you are killing off the bureaucrat function on the wiki. I'm not even sure why you're still labeling them as such, just call them arbitration committee members, because that's what they truly are; according to the current policy there would be only Sysops and the ArbComm. I'm fine with the idea of having such an arbitration committee on the wiki, but I'm not fine with us losing bureaucrats. A committee is "heavy machinery" in my book, which will very likely work, but if other more practical means can be used to reach satisfying results, those should get priority. Bureaucrats should be that. Getting bogged down by too much bureaucracy is a very possible side effect of the policy you are proposing.
 * 2) I see really no point in artificially removing the sysop tools from the Arbitration Committee members. Either have them or not have them at all. If all they would do with those tools is to enforce a decision the ArbComm has taken, just write in the policy that they can't use them for anything else, or simply don't give them those tools in the first place and let someone else enforce the ArbComm's decisions. "I put on my robe and wizard hat" pretenses make no sense.
 * 3) The role of the ArbComm is still unclear. The words "big dispute" have been used a few times, but that's about as vague as it could possibly get. What exactly are the disputes that this committee would help manage? The only one I can think of from either of the wikis is the deletion of the Builds section on GuildWiki;  I'm sure many there would have welcomed a chance to use such an ArbComm to put an end to that deletion. What else would there be?

The details of how I think this should work will depend on your answer to #3 above, but the structure itself is this: Don't get rid of bureaucrats, simply integrate all these roles better, streamline them together.
 * Sysops
 * Delete/protect pages as per policy.
 * Block vandals and rollback vandalism.
 * Give administrative warnings for repeated breaking of policy.
 * Contact the bureaucrats if the breaking of the policy is getting out of hand, maybe with a temporary block if the users in question are too far over the line and escalating the situation.
 * Cannot unblock someone blocked by another sysop (1).


 * Bureaucrats
 * All of the above sysop functions.
 * (Important &rarr;) They are where User vs. User and User vs. Community disputes and policy interpretation questions should be first addressed.
 * Block users they see as disruptive to the wiki, usually as a result of #4 above (but no out-of-the-blue blocks without warning though, unless for cases borderlining vandalism).
 * Can unblock a user if they decide it was inappropriate for a sysop to block them in the first place.
 * Can appoint new sysops by gauging community consensus through the RfAs and whether more sysops are needed or not.
 * Cannot reverse any actions taken by any other bureaucrats including unblocking users. (1)
 * Cannot remove rights from sysops or bureaucrats. (1)

1. Exception if the sysop or bureaucrat in question has gone loco and is randomly blocking people, deleting pages, things like that, in which case temporary measures to prevent him from causing more harm are acceptable.


 * ArbComm
 * Mutually exclusive from the group of sysops and bureaucrats (talking about duties here, not about whether they have the technical ability to delete a page or not).
 * Depending on the size of the committee, if 1 to X committee members decide that the case has merit and is worth examining, the case is accepted from the ArbComm. (Simply to avoid wasting anyone's time by random people coming up with absurd reasons for an ArbComm case, such as "Waaah, that sysop blocked me for blanking half the wiki's articles, unfair!")
 * The cases in question should be fairly major ones, involving either the bureaucrats and sysops, or the decisions taken by them. This reflects my view that sysops+bureaucrats should be the ones that make sure the wiki keeps functioning smoothly, while the ArbComm is how the users make sure that the sysops+bureaucrats system functions properly, effectively keeping them in check.
 * They can of course also deal with any other important issue, (such as whether or not to send ANet the severed head of a horse if they refuse to install DynamicPageList for us).
 * I'm not sure whether the ArbComm members themselves should have the power to remove user rights from sysops and bureaucrats, or if they should just give the verdict and let someone else do it. I don't think it matters much either, to be honest, it's just a technicality.

To sum up: Sysops help the wiki with the tools they've been given, keeping the wiki engines going. Bureaucrats do the same while keeping an eye on the sysops and listening to any issues that users may have, and try to solve them. The ArbComm is gathered if a user is dissatisfied with either a decision taken by a bureaucrat or sysop, or with the sysops and bureaucrats themselves. This leaves the wiki with a functional and fast day-to-day administrative system and issue-handling, while providing a safety control mechanism and dispute-solving procedure in the form of the ArbComm. --Dirigible 21:26, 10 April 2007 (EDT)


 * I don't see the point in splitting up the bureaucrat and ArbComm roles. I've said this before and won't say any more about it.


 * Beyond that, I don't see why #3 and #4 in your bureaucrat list of duties can't be done by sysops. I think that the sysop role should be No Big Deal, as Rezyk so handily stated, but it's clear that we trust the sysops more than we trust any editor chosen at random. I don't think #3 and #4 require too much trust. In the case of reverting another sysop's action, I should hope the two sysops should be able to work it out if a mistake was made. If not, they could appeal to a bureaucrat or three for their opinions.


 * I like Rezyk's process for formal ArbComm hearings, but I don't think it'll usually come to that. I think that, in general, most people will accept "Okay, we disagree, let's ask a bureaucrat for his opinion and go by that." My experience on the GuildWiki leads me to believe that a bureaucrat posting "Hey, you're wrong, and here's why" is usually enough.


 * &mdash;Tanaric 16:24, 11 April 2007 (EDT)


 * Dirigible, I'm really having a lot of trouble understanding your response with respect to my proposed change. =P Do you feel that Guild Wars Wiki:Adminship/version B is a lot worse than the current Guild Wars Wiki:Adminship, or that they are both broken? I mean, it seems like you are seeking a radically different structure than both (bureaucrats as moderators outside of sysophood/arbcomm?), while this was just intended to try getting better agreement within the scope of where GWW:Adminship is already headed. (It's really just a proposed change of part of a draft, not a final policy proposal in itself!) If you want something fundamentally different than both, maybe we could work your new ideas into a whole new proposal and then discuss it side-by-side with GWW:Adminship? (similar to 1RV and 3RR being drafted separately and then discussed)
 * The only ability that the current Guild Wars Wiki:Adminship draft gives to bureaucrats outside of their arbcomm/sysop status is "to appoint or revoke the administrative status of users based on community decisions". That part is still there, word for word, in Guild Wars Wiki:Adminship/version B, so I don't get how I'm "killing off the bureaucrat function". (If anything, the structure you gave seems to drop the "revoke" part..?) Also, I'm not saying that's the only power bureaucrats should have outside of arbcomm; I think some more powers should be added too, but it just wasn't the focus of this particular change.
 * You say "just write in the policy that they can't use them for anything else, or simply don't give them those tools in the first place and let someone else enforce the ArbComm's decisions". But, that is exactly what I was aiming for when writing up this proposal! =P It's the central idea behind it -- I tried making it simply that and nothing more, and I really don't see where I veered off from it. What extra stuff did I propose that would be an artificial pretense? Which part is the robe and wizard hat? Is it some of the stuff I threw out in my discussion with LordBiro? (but those aren't even formed proposals yet, just some ideas/opinions of mine)
 * I agree that role of ArbComm is still unclear, and I also want to try writing up more stuff to make it clearer (or discussed) before we have official policy. Personally, the basic roles I favor are (although this isn't all in the current draft; further proposals would be needed):
 * ArenaNet is necessarily the ultimate authority (in case of meltdown), but we try and structure things so that authority would very very rarely ever need to come into play after the basic structure is set up (in line with their own wishes). They still have a special say in matters closely tied to their role as webhost (mostly legal issues, security, backend changes).
 * Mr. Consensus gets to make all the other decisions. His voice can mostly be found in talk pages, but we also track his wide-reaching stances in the form of policy/guideline pages.
 * Arbcomm, as a single group, is for providing a clear decision whenever we need one fast enough and Consensus is too slow or deadlocked, or needs interpretation, or is disputed. Arbcomm, as a group, also decides when that condition is true, on a case by case basis. Arbcomm members are individually empowered to decide on temporary solutions while either of these decision processes are in the works (danger!). All the controversial decisions should be made at this level or higher.
 * Bureaucrats have access to the user rights button, but should only use it in accordance with decisions made by the above 3 roles.
 * Sysops have access to the delete/block buttons, but should only use them in accordance with decisions made by the first 3 roles above. I'd put access to these in the hands of all users, except that it's simply impractical to have any malicious vandals able to push them.
 * Users comprise Mr. Consensus, and through him effectively keep the wiki engine going, listen to issues, try to solve them, do the bulk of administrative/moderator work, and decide on who fills the roles of arbcomm/bureaucrats/sysops.
 * ArenaNet is kept in check by their own best interests. Everyone else is kept in check by Consensus or Arbcomm. In the extreme cases, Arbcomm is also kept in check by term limits or ArenaNet intervention. This keeps everything going while also providing safety control mechanisms, allowing fast action wherever needed, keeping the status of consensus elevated, and consolidates the really dangerous non-consensus decisions into one position so that (hopefully) we won't need to apply term limits and limit manpower for the ever-present tasks of deletion cleanup and vandal blocking.
 * --Rezyk 16:49, 11 April 2007 (EDT)
 * My disagreement is with both versions of the Adminship policy, as they both try to merge the bureaucrat function with the ArbComm one (Version A giving more importance to the bureaucrat role, and Version B giving more importance to the ArbComm role). My first worry as a pragmatist is that I feel that both of those roles are needed, and integrating them into one entity is somewhat like tying both your hands together, it's true that their strength will be greater than them separate, but you're also losing a lot of the flexibility that they separately would have in the process. I guess I'm alone in my dislike for committees. Inside my head that word translates to "a lot of extensive formal discussion, to be awakened only if all other methods have been exhausted".
 * My second and main worry is that merging the ArbComm with bureaucrats doesn't really leave any other problem resolution methods as you are leaving no middle steps in the process, which isn't a good thing. It's the equivalent of gathering the Supreme Court to judge for every DUI offense. Similarly, Wikipedia has an entire process hierarchy for resolving disputes. It isn't simply because they're far larger than us, it's also a more practical solution that gives a fast answer to trivial issues, and also leaves you with the right to appeal/go one level higher if needed. Right now we have sysops and we also have bureaucrats having the final say on things. Under either version of this policy, we'd have sysops and we'd also have the ArbComm having the final say on things. How did that improve anything? If I'm unhappy with a decision taken by the ArbComm, my only solution is to either wait for six months for their term to expire or complain at ANet about it, (the same people that have openly stated that they want nothing to do with this and will leave the administration of the wiki to the community)? Somehow neither of those possibilities seems realistic to me. I very much disliked the finality of a bureaucrat's decision on GuildWiki, and I can't say I'm happy with them simply changing their name into ArbComm and everything remaining the same. Wasn't the point of an ArbComm keeping a system of checks and balances in the first place? Looking at the Guild Wars Wiki talk:Adminship page:
 * "An arbitration committee seems to be a good way to control admins, while at the same time giving them a freer hand in their day to day decisions. Of course that committee needs to have the clear power to remove sysops and bureaucrats and it needs to be selected by the community in some form of democratic process." --Xeeron
 * "It's not like the committee consists of one or two close friends that plan on total Wiki domination; they exist to sort out problems, make decisions, and ensure a checks-and-balances approach instead of an all-faith-in-the-sysops approach." --Auron
 * "My view on any committee of this nature is that its there for balance. The sysops/bureaucrats oversee the wiki and "general populace". The ArbCommittee would be comprised of people from the "general populace" who oversaw the sysops/bureaucrats in cases of dispute/need". --Lojiin
 * Checks and balances. What happened to all that? If the ArbComm wants you to get blocked, it'll be so and there's nothing you can do about it, just like with bureaucrats. If the ArbComm one day decides to wipe a third of the entire wiki like the Builds section, it'll happen and there's nothing anyone can do about it, just like with bureaucrats. They are still the first and final level of formal decision making on the wiki. So what exactly did we gain in the process? The only practical difference between how things are run on GuildWiki and this policy you are proposing, Rezyk, is that the bureaucrats won't need to bother with deleting and blocking pages. Otherwise, it's the same.
 * I do realise that someone will have to be in charge of having the final say, I just disagree with that someone being both the first and last one to have a say about it. If you leave the bureaucrats as a middle-level, you can keep the ArbComm as the highest decision-making function on the wiki, but which only gets called upon if the previous level fails to reach a satisfying decision.
 * If I'm alone in these worries, so be it, maybe (and hopefully) I'm mistaken in how feel about these policies. -Dirigible 19:38, 11 April 2007 (EDT)

<-- Heh, the last thing I expected was a response saying that these drafts are too GuildWiki-like and not as Wikipedia-like as your structure. I actually feel the reverse is true in many ways. I'm not arguing that we should/shouldn't do things in order to follow one of those wikis; just saying it really took me by surprise. =) Finally, please give me another chance here. =P It's too hard to satisfy everyone's concerns in one swoop; this version B is just a baby step to try and address some users' concerns (that I don't even have myself) with the main version. Apparently I hit for some, but missed for you. And if both versions are broken in your view, then it's not really my proposed change here that is so bad. ^^ I want to try and get stronger support for this direction for the main draft (not as a finalized policy yet!) and then see what I can come up with to address your concerns (which I really didn't understand until your last response) or convince you that you're mistaken. ;) Maybe we should also draft a version C to explore your separated-arbcomm structure in the meantime? --Rezyk 21:48, 12 April 2007 (EDT)
 * Note that in both drafts, ArbComm is only given jurisdiction over "user conduct", which I think means they cannot decide to wipe out builds. Maybe we should be more explicit and word this as something like "user conduct on a case-by-case basis (but not content decisions)". Also, be wary of any further drafts/proposals that I write, as I've voiced some support for expanding the scope to include content decisions.
 * You say that we currently "have bureaucrats having the final say on things". Since when?! I suspect this is the source of my confusion, as it's a very strange concept to me; I don't see it as myself proposing this away, but rather that it doesn't exist in the first place. Where did that idea even come from? Am I to understand that my opinion, outside of arbcomm hearings, on whether or not a user should be blocked counts for more than the opinion of a non-bureaucrat sysop? As far as direct consensus goes, I'd say that my opinion should not inherently count for more than your own, non-sysop opinion. I would accept such extra weight given to my opinions/actions ONLY with respect to an arbitration case.
 * Checks and balances was not the initial purpose of arbcomm here, although it may be an incentive for many. I think I'm qualified to say this since I was the first to voice support for having an arbcomm. =) I see it this way: Our foundation is simply the consensus model of decision making. The only positions that currently have real jurisdiction in resolving disputes are ArenaNet and consensus, not sysops nor bureaucrats. Because it's impractical to require an explicit consensus on a case-by-case basis, we take a lot of shortcuts; sometimes we've been relying on implicit consensus (like to block spambots) or a pre-decided consensus (like deletion policy). Unfortunately, some things, like the grey areas of user conduct, still would not be handled well since we can't pre-decide every possibility and getting explicit community consensus can be too slow/chaotic and create further problems. So we form a small committee (supported by consensus) to process them more quickly and cleanly.
 * I never meant to imply/pretend that this change provides all the checks and balances that everyone wants; apologies if anyone got that impression. To me, some direct checks and balances between offices is a bonus, but shouldn't be relied on too seriously because it's (1) building a bureaucracy and (2) still vulnerable to cliques and sockpuppetry anyways. I'm even hoping that we'll eventually reach enough of a sysophood-is-no-big-deal reality that the community will see it as No Big Deal to return sysophood to ArbComm. Personally, my primary goal for adminship policy is just to limit damage to the sacred cow of consensus, which is a general "check and balance" with much larger scope.

I see where Dirigible is comming from, because I share most of your concerns. However, I am willing to settle for less (in order to keep things less bureaucratic).

As for you, for me the main purpose of bureaucrats is to act as a check on sysops. They will receive a huge amount of power (appointing sysops, demoting them, arbitrating conflicts), but they will also be the only instance in the wiki which is directly elected by the users and up for reelection in short periods of time. I support this version B over the other version mainly because it takes away an additional power from bureaucrats (blocking users) when they already have quite enough power (and, as per Rezyks arguements, I dont see any problem in having 3 less sysops, they can be replaced by 3 new candidates if we face a lack of sysops).

Your idea of splitting up the two tasks of appointing sysops and final arbitration is fine in theory. However in practise it would mean having two elections, because both tasks definitely warrant all editors having a say (via the election), but then we all know that elections in a wiki are difficult to set up. So having only one instead of two should lessen the problems. Would these problem not exists, in my ideal world, there would be two instances: Bureaucrats as "leaders" of the sysops (with sysop power and with the power to promote users to sysops) and arbcom as "supreme court" (without sysop power, but with the power to remove both bureaucrats and sysops). It is really a matter of how important the two roles are compared to how difficult 2 elections would be to pull off. --Xeeron 10:58, 13 April 2007 (EDT)
 * Aye, I'm very aware of the extra bureaucracy layer that having a separate ArbComm from the bureaucrats group would mean, Xeeron, which is the main reason I haven't posted a proposal about that yet. There's still so few people around here interested in policy right now, that I very much doubt having elections so often about all those positions would be viable, at least for the time being. Urgh.
 * Thanks for clarifying that they don't have a say over content, Rezyk, it makes a world of difference. I think this is an acceptable policy, at least till we've grown enough to be able to afford a fancier one. So, support from me. --Dirigible 12:53, 13 April 2007 (EDT)

Another version
Well, now that there's more support I guess it's time to alter the proposal again.. =D Actually, this is an attempt to hopefully make things more agreeable to LordBiro without losing current support, and also simplify the ugly technical workaround aspect. The idea here is that it's mostly just user blocks that is the contentious aspect, and so we don't need to strip out every sysop ability from bureaucrats. They still represent a "trusted user" in other ways, and we can leave them with enough abilities to also help with generally-noncontroversial-but-needs-trust tasks, such as editing MediaWiki interface pages. I suggest that for the backend, we give bureaucrats every userright that sysops have except for 'block'. This includes: Note that this includes 'delete' and 'protect'. Unfortunately, it doesn't seem possible to separate the ability to delete from that of viewing deleted pages. The same goes for the ability to edit protected pages, and protecting/unprotecting pages. In the draft, I wrote in an express forbiddance of executing page deletions. Some particular things to consider between this and the previous version is that bureaucrats would now be able to protect/unprotect/undelete pages. Should we keep these as sysop-only? --Rezyk 14:51, 13 April 2007 (EDT)
 * 'createaccount', 'delete', 'deletedhistory', 'editinterface', 'import', 'importupload', 'move', 'patrol', 'autopatrol', 'protect', 'proxyunbannable', 'rollback', 'trackback', 'upload', 'reupload', 'reupload-shared', 'unwatchedpages', 'autoconfirmed', 'upload_by_url', 'ipblock-exempt'
 * Well there is a difference between technical means and policy. If we decide that bureaucrats should not delete articles (and I lean in that direction), we can simply write it in the policy. This being a wiki (with logs and all) it should be very simple to verify. The only two actions I really want bureaucrats away from are ban and delete (protect is fine with me), those should be executed by the sysops. --Xeeron 15:28, 13 April 2007 (EDT)
 * Yeah, I don't think whether or not we do a technical change is a big deal. I tend to prefer it just to make things a bit easier for future users to understand. It's easier to explain "I'm just a bureaucrat, you need to ask a sysop for that" rather than "Well, yes, the user list says I'm a sysop, but I'm not really a sysop, if you read our Adminship policy". --Rezyk 15:44, 13 April 2007 (EDT)


 * To be honest I was close to being won over anyway ;) I understand the reason for separation between sysop and bureaucrat, and removing the ability to ban or delete is acceptable to me, although being able to see deleted history without adding sysop privileges would makes sense. LordBiro 16:39, 13 April 2007 (EDT)


 * Just to make myself clear, I do agree with bureaucrats being separate from sysops, even though I wasn't happy about that initially. I don't think it makes sense for bureaucrats to be able to block/unblock/delete/undelete. I don't think protect/unprotect is harmful, but if it was decided that these abilities were best left to sysops then I would understand. LordBiro 16:45, 13 April 2007 (EDT)


 * I've added unblock and undelete to the forbidden actions. --Rezyk 17:08, 13 April 2007 (EDT)

I've imported version B into the main draft; I suggest that any general discussion of these changes should continue on its talk page. --Rezyk 19:11, 13 April 2007 (EDT)