Knowledge:Requests for adminship/Bureaucrat Unchecking/Poll

2949:. I've thought about this for a bit and whilst I think the arguments in support are valid - this is only a technical ability, the current position has arisen slightly by accident rather than design, etc - I am not comfortable with this proposal. I think it is premature to expand the scope of bureaucrats before sorting out the fact that inactive bureaucrats appointed long ago with little (if any) community input may now lack its confidence. I am not convinced that we are doing a good job of handling requests for restoration of admin rights at the moment and worry about an apparent increased willingness by crats to exercise discretion over the objection of other crats without seeking consensus. I worry about pressure being placed on crats to desysop without a community process being in place to provide for it - there are merits to the stewards' independence. At the very least, I would like to see a mechanism for the community to remove 1617:

tasks aside from those they already perform. The type of scrutiny applied to candidates when the ability to desysop is at stake is likely to be quite different than what they currently undergo, and I'm not sure we necessarily want to grant this right to all bureaucrats (particularly those who were selected 5 or more years ago). There will be a time to re-evaluate the role of a bureaucrat with respect to any desysopping process; it will be after such a process is developed or even approaches consensus. I am generally opposed to granting bureaucrats expansive new roles, particularly in dispute resolution and in controversial processes, and I don't see a convincing argument here to change my position.

2554:: There's been no compelling explanation provided here demonstrating any kind of problem that requires solving. And, to the contrary, I think the current system of having an impartial person doing the task of de-adminning is a very good idea. De-adminnings are pretty rare. The process for requesting de-adminship (i.e., going to Meta) is fairly standardized among the 700+ wikis and is common knowledge for most admins. Changing it needlessly here hasn't been justified for a number of reasons. The feigned fear of split logs is also a non-starter. The logs are currently fairly consistent. Adminnings are local; de-adminnings are at Meta. Implementing this will only make 749:

agrees that a mistake was made. As it stands now, the 'crat cannot simply remove the bit, but has to get somebody else to do it. IMO, if a 'crats decision is challenged by other crats, this would become time for a 'crat chat---during which time the candidate should NOT have the bit. But once granted, the 'crat can't remove them. Various abilities generally come with the ability to reverse the action, this makes complete sense as mistakes may occur or situations may arise requiring the reversal.---

621:, each very unlikely and not, on the whole, that horrifying. I fully trust the 'crats with this responsibility and furthermore, it seems the community is aching for it as well. A number of the de-sysop mechanisms that have been proposed at least nudge toward a larger role for bureaucrats, and the RfB bar is set so high that it's logical to give them a small tool worthy of that invested trust. This seems definitely in-line with what is desired here. ~ 100:, there does seem to be both support and justification to take this forward. Given the concerns raised about the possibility of a rogue 'crat turning off all the admins, and also that existing 'crats were not elected under the understanding that they had the power to turn off admins, it would seem appropriate to have a checks and balances discussion on the implications of this proposal. A new discussion, widely advertised, and linking to this and the 3026:- I have read most of the content below, and I still fail to see that there is a problem that requires solving; this seems to me to only be for its own sake. In addition, I dislike the bureaucrat system in general and feel that adding rights would only make it harder for people to get promoted (and it is already far too hard). I would prefer it is the general standards for 'crats were decreased, and we left this to the stewards. 2648:

multiple attempts to clarify, there is nothing I can do. I understand people will choose to misrepresent things for political purposes here in wiki, but reading the two statements at the top of the proposal, to continue to conflate this with CDA or to assume that this gives 'crats any more decisive power seems to take willful thought for whatever motive and there is nothing I or anyone can do about that, unfortunately. --

2974:. Are there any complaints about the response speed of stewards? Usually, when an account is compromised (which is arguably the only situation I can see where it would be useful for local bureaucrats to summary desysop somebody), a steward is available within a minute or so, so I don't see any problems there. Additionally, I find myself agreeing with MZMcBride: we all know that the "desysop log" is in Meta, not here. 2497:

result of this proposal some desysopings will be recorded in the local log, while other in the global (stewards will continue to desysop in some cases). So anyone who wants to know when and by whom an admin 'A' was desysoped would need to check two logs instead of just one now! I think the desire of some bureaucrats to obtain a new powerful userright can lead to a lot of problems. By the way why

599:(which does in fact have a far lower potential for destructive effect anyway)? We don't need a community de-adminship process before granting 'crats this ability. For example, when ArbCom decides to desysop someone, why should we need a steward to flip the switch? A bureaucrat could do it. Why should an admin be required to request their own desysopping at Meta rather than simply posting at 2838:

inconsequential. A well-planned attack of that form could not be stopped by on-wiki activity: the sysadmins would probably have to suspend all permissions from the affected groups until we could sort out from the top down who was supposed to have what. Certainly granting -sysop to bureaucrats does not make such an attack either more likely, or noticeably more damaging.

4254: 1930: 4138:, the logs for their +sysop follow them to their new name, but their -sysop logs do not, and are hence impossible to find unless the user's former name is known (which may not be the case, and at the least requires a lot of digging to uncover). Not only are the logs on a different project, they may not even remain synchronised with the user. 1170:- we should not be relying on stewards, who by their nature may not be particularly familiar with the en-wiki community, to be our sole desysop mechanism. Obviously the methods of when a desysop is appropriate will always be under discussion, but I for one trust our local crats to be more familiar with that than the stewards are. ~ 3201:

with the "tools". I think changing these tools after a person gets made a crat could be unfair to some people that commented in an RfB. I would support this if it my "suggestion" is incorporated. If anyone has a question regarding my oppose, please let me know on my talk page as I won't have this one watchlisted. Thank you.--

162: 3471:

administrators, bureaucrats or arbitrators remain uninvolved in situations where they may have a conflict of interest. I don't see why bureaucrats would not do the same in this situation. I don't have experience in administrative or bureaucratic activities so I may be severely misinformed, but that's how I see it. Regards, --—

3838:. Many people believe the proposal is better; you do not. You are more than welcome to both feel that way and to post your opinions as clearly and forcefully as you can to best state your case. That's exactly what the RfC is for. However the mere fact that things are function now is no excuse not to explore what may be 2532:

will create additional workload on stewards thus undermining one of the arguments in favor of this proposal (c) is not allowed by the current policy because stewards are not permitted to suddenly become bureaucrats here (d) will confuse local uses who might think that the acting steward is a bureaucrat.

4072:

Hammersoft, could you step away from the dead horse and drop the stick? I think anyone reading this page will realise that you don't think the fact that logs logs are currently split between this project and meta is enough to warrant bureaucrats being given the technical ability to remove rights. You

3724:

However, stewards would probably still perform voluntary removals when requested to do so and no English Knowledge bureaucrat performed the task for some time (there is no such thing as an urgent self-requested removal). This is because there is no policy (nor could there ever be) which forces a user

3627:

Ok, but they actually aren't allowed to run CU's in an emergency, as we saw during numerous grawp-attacks when no local checkuser was available or during that weird grawp-attack that required an account to be renamed, in neither case did or could a steward step into the local wikis shoes since we are

3103:

Which has nothing to do with this proposal; even if a user is community banned on ANI, neither 'crat (proposed) nor steward (current) can do anything to the sysop bit without prior authorization from ArbCom, and any one who does would be brought before ArbCom (or complained to the foundation/stewards

2531:

I do not know why simple and meta decided to go that way, but this is irrelevant for this discussion. As to the temporally assigning to themselves the crat's bit before desysosping, I would say that this (a) is impractical in an emergency when a permission should be removed as quickly as possible (b)

1755:

The position of supporters is that it has no bearing. I disagree with that position; there is no misunderstanding. They are intrinsically related, whether or not one is strictly dependent on the other. To put it a different way, I do not believe we would be having this discussion if it weren't for

1672:

Add to my oppose the issue about the logs: many supporters have argued that this change will unify rights logs and make them easier to read. In my view, the current log arrangement is simple - all sysops are local, all desysops are at meta. In this new arrangement, some desysops will be at meta, some

1372:

I would prefer as fast a response as possible if a crat or admin goes rogue. Of course there's the reverse possibility that a rogue crat can decrat and desysop others, but I think that the former would be more damaging than the latter. Plus if they can give crat or sysop status they should be able to

1227:

20:36, 11 January 2010 (UTC) Although MBisanz makes some valid points, I believe too many of the arguments against are really arguments from inertia, or attempts to rationalize what is no more than a historic accident. We trust the bureaucrats to promote and rename users in accordance with policy, we

3957:

Answered above, you disagree. This is not an issue where further discussion helps. I think this proposal is more elegant and efficient than what we have now, even though we can live with the current. You do not. We can play "ring-around-the-rosie" back and forth until the cows come home, since it is

3931:

that is being addressed, but it's certainly something that many, many people have always found confusing about how the bureaucrat userright has traditionally been set up. I'm not sure what's wrong with questioning, and fixing, something that's always struck people as odd; your chief argument against

3428:

Finally, I am aware of at least one crat war at meta-wiki, where a crat closed an RFB as a promotion and another crat disagreed and undid the promotion. As of now this technical feature prevents such an event from occurring and I am not certain that changing it permit such an event to possibly occur

3420:

While crats would in theory (at least I would) only de-flag on user request or on arbcom decision, this new capacity would put crats in the uncomfortable position of seeing a consensus to do something, but being restrained by policy from doing it. I am thinking of several user conduct RFCs and admin

3086:

The ANI threads are just a prediction of what I think may happen if this passes. ANI probably has threads every now and then about someone claiming admin abuse, so it's not unreasonable to think that someone would eventually propose a de-adminship there, which would result in long-winded discussions

1191:

I really think too much of a fuss is being made of this, but whatever. One of the basic principles of the site is that nearly anything is reversible. Because bureaucrats were elected based on the community's trust in their ability to judge consensus, I would have no issue with them judging consensus

3661:

I think Matt's point #3 is an excellent one and I don't is adequately addressed by anyone here. After all, the word "consensus" is used frequently on this page even though there is no process to desysop by consensus (since arbcom doesn't work by consensus but by strict voting). This suggests that

3413:

Stewards will not act if a local wiki has the ability to do something. That means if crats can deflag an admin, stewards will not do it. This is their policy and not ours, so if we approved this change, crats would become the only people capable of de-adminning. Given that the stewards already have

2815:

They could desysop many admins. Stewards are a significantly more trusted group (for example, stewards disclose their identities to the WMF, unlike local bureaucrats). The very small number of local desysopings is not enough to warrant the added security risk. In other words, there is a significant

2647:

But that is more misleading, because that implies that 'crats can make a decision, where this proposal is solely one about flipping a bit after an exogenous determination is made. I've tried to be VERY clear about that in both the proposal and the nutshell; if people continue to misunderstand after

2141:

I find the argument that this proposal needs to be put on hold until CDA "gets done" to be just as uncompelling as you find this proposal. This proposal very clearly restricts the opportunities that the bureaucrats can remove someone's flag (emergency, mistake, or request , which are the exact same

1866:

So what are you suggesting, that bureaucrats should only desysop if the CDA being closed is 100% in favor of desysop???? Come on. This proposal IS linked to CDA. You can't tell me we're not going to have bureaucrats making the decisions at CDA. Unless you intend on creating an entirely NEW class of

1803:

I think your supporters are confused about that. For example, in #20, Joe says, "it's a logical step for them to determine when consensus exists for the bit to be removed," and in #21, Ironholds says, "'crats are trusted to determine consensus to promote; no reason to suggest they can't determine

1616:

There is no current community process that would require bureaucrats (or anyone) to "uncheck the box" on adminship. I think that enabling the technical ability for crats to desysop should be a follow-up step to the creation of such a process. Additionally, bureaucrats have not been selected for any

923:

I've never understood why the bureaucrat toolbox has lacked this ability. I've also been a pretty vocal advocate for there eventually being a community-mandated system in place for removing administrators, and as I consider such a process to be in the (eventual) purview of the bureaucrats, it makes

458:

It's really very simple—if we trust someone to give the bit, we should trust them to take it away again. As Jim Miller said, this has a much lower risk than simply becoming a bureaucrat. Ideally, I'd like this to be combined with a process for actually taking away the bit, rather than on an one-off

76:

I think I may have erred in looking at this. I was looking at the oppose votes as mostly ivotes with little rationale, and the oppose comments as carrying more justification, and then I did a quick calculation in which I took the oppose votes away from the support and that left 38 which I then held

4650:

Another thing to consider when looking at RfA's we often hear that the system is broken. There have been numerous suggestions in the past about ways to fix it or approaches we might take to tweak the process. Various models of "temporary adminship" or "mentorship" are killed (in part) because we

4119:

The logs are a problem. If CDA did not exist I would support this proposal because of the added transparency in the logs it would create. Also, I want to say that I'm very disappointed, as one of the dissenters, in the tone this discussion has taken. There is no need for that at all. I believe

3601:

So for one instance we should prevent something sensible? And let us say that happens with a bot - which can have its bit removed by crats? That is similar to blocking/unblocking, which we allow even though the potential for a wheelwar exists. If that happens again, ArbCom can be called in. Anyway

2859:

IMHO: The attack vector Carl refers to is someone going rogue, not someone gaining control of an account. Theoretically a Steward is less likely to go rogue than an en:wp 'crat, (if you consider identifying to the foundation and having support from more wikis than just en:wp as factors) although I

2760:

I didn't realize you were moving the logs to en.wiki, nor did I realize this was technically possible. I assumed that this proposal would break the log of removals up into two pieces, one on en.wiki and one on meta. Whether they are en.wiki contributors or not, their steward authority comes from a

1902:

And has asking a non-local person ever been a problem? Doesn't seem so. Has going to meta to turn off your bit ever been a problem before? I don't recall any incidents. What problem is this supposed to solve that is currently hampering the project? In a word, nothing. That's what. And I'm sorry, I

748:

It has never made sense to me that they should be. Let's take a hypothetical RfA where Crat_A passes the candidate, but that decision is challenged not by just the general community, but by other 'crats. The community disagrees with the 'crat who promoted the canddidate, and eventually the 'crat

406:

from why they should be able to do so. This discussion is only about the "whether" they should be able to do so when desysopping, for whatever reason, is needed. The only reason one could oppose it is that a rogue crat might run amok and desysop all admins or desysop anyone they like but that same

3712:

Currently, stewards will perform desysops when requested by the English Knowledge's Arbitration Committee. We will also perform them as requested by administrators themselves. Finally, in clear emergencies, we would remove the administrator tools to protect the wiki. For each of these cases, I'll

3384:

will soon find themselves without the bit, and the damage done is very simple to reverse. There is far more risk giving someone the bit, as they could allow unruly bots, and administrators (albeit for not very long before being caught). Solution without a problem or not, I don't see any harm from

3351:

All the comments above (in support and here) have said it better than I. In a nutshell, a 'crat can check the box on for another 'crat, after a successful RfB or a return to 'crat status after a vacation (ala WJB Scribe), so it is logical that they should be able to uncheck the box, in situations

3200:

I oppose this with the current wording. I think this ability should only be given to crats there were promoted after (and if) this gets put into effect. I don't think I've ever commented on an RfB, but I've read some. Some people comment in RfBs based on whether or not they trust the candidate

2558:

of a mess of the logs. How is that a benefit? The stewards are generally available at the same rate as bureaucrats, if not faster—and most of these de-adminnings aren't particular time sensitive anyway. Finally, from reading this page, it seems pretty clear that this is a thinly-veiled attempt to

2430:

I think that would be a fantastic compromise to ensure that the damage done by a rogue bureaucrat (which I still consider unlikely) would be even further minimized. (though that would, in turn, mean that stewards should still be on-hand for emergency de-sysopping, as a 'crat arriving on the scene

669:

I agree with the same sentiment expressed by most (all?) above: bureaucrats are trusted to determine consensus when adding the bit (in either case—RfA or RfB), so it's a logical step for them to determine when consensus exists for the bit to be removed. I also agree that having local control over

4384:

that our 'crats can grant the ability without being able to take it away. The process by which the community allows them to do so is completely irrelevant to this conversation. The wp-en community grants adminship, the wp-en community must be able to remove it without requiring intervention from

4379:

original question, the problem that this is meant to solve is that this entire process, from implementation, has been broken. Like many of our procedures, removing the sysop bit relies on an ability that is not an integral part of our processes here at wp-en. The process has been broken from the

3056:

Without much compelling arguments to show flaws with the current system, this is extra buttons for the sake of extra buttons. We really don't need those dreadful ANI threads where a user proposes a desysoping (whether frivolous or not) and then a bureaucrat has to decide consensus, which is made

2496:

As I understand this is another solution in a search of a problem. It was mentioned by some that it can solve the problem with logs. I think this is a bizarre suggestion, because it can only make the log mess much worse. Now all +bits are in the local log, while -bits are in the global one. As a

598:

Certainly. It's a good idea to keep these things local (as opposed to on Meta), and bureaucrats are already considered our most trustworthy users. Jim Miller hits the nail on the head: If we trust bureaucrats not to sysop without consensus, why shouldn't we trust them with the ability to desysop

588:

I don't see any reason why we can't keep things local. If anyone's worried about bureaucrats desysopping people for no reason at all, I'm sure any bureaucrat who did that would have their bureaucrat rights removed pretty quickly. I'm also not worried about inactive bureaucrats having the feature

432:

Absolutely. There is no reason for them to be only able to go one way. People say that if they abuse it and remove all admin bits, we'll be in a deep hole. However, they're already trusted not to sysop people without an RfA. In my opinion, being able to sysop everyone is much more dangerous than

3546:

Interesting point, but if that is the case then it really is entirely irrelevant, because what Wikipedians percieve is irrelevant. What is true is what counts, at least in theory. We trust bureaucrats to make consensus-based decisions, and if they cannot act impartially, as Avi says below, they

2179:

I really fail to see how that's relevant to this proposal. You're arguing that the bureaucrats may not be the ones to close a future CDA system. Alright, that's fine; perhaps a different group will. What does that have to do with allowing bureaucrats to undo mistakes, or to be the ones to make

4348:

How does it "make it worse"? I simply do not agree with Ruslik's reasoning. If this proposal is enacted, then in maybe 90% of cases going forwards, you wouldn't need to look in the global rights log because it would be right there in front of you in the local log. If you see two sequential

2837:

an army of socks with illegal permissions. Compared to the (disruptive but almost entirely reversible) damage that a thousand admin-vandals rampaging around the site deleting pages and unblocking each other would do, the fact that a thousand legitimate admins were desysopped in the proces is

3470:

I can't refute point two, but points three and four seem to be focused around the same idea of a 'crat being biased towards a decision if they're somehow involved in the "enwiki affair". Why is this any different to any system we have in place today? It has always been a firm advisement that

2628:

Exactly. I'm not saying I haven't used these tactics before myself, but there are definitely some deliberate attempts to downplay this discussion, from the page title to the notification on various noticeboards. Want to bet if I changed the section headers from "Bureaucrat Unchecking RfC" to

4049:

It'd be lovely if you could take a time out of your badgering Avi (who it's looking like you have a personal dislike for outside the confines of this proposal) and address my statement above; I think I did a fairly reasonable job of answering your repeated call for a problem this address.

3736:

Let me emphasize that these are my opinions; I expect they'd be discussed on stewards-l as necessary before this is implemented. Of course, if the English Knowledge community decides that they still wish to have stewards perform Arbitration Committee-mandated removals, we would oblige.

4160:

I've asked WHY having the logs on separate servers is a problem, to which there's been no answer. I've asked how the vacation bit suspension has been problem, to which there is no answer. And on it goes. Yet, I'm the one who apparently has a personal problem with Avi. Utter disbelief,

3583:

themselves the CU/OS on the wiki prior to running the check. This is different firstly, as changeuserrights is something stewards have by nature anyway, and two, all of us are clear that we would like them to be available in cases of emergency (as they are in CU/OS anyway). When it is

1784:

a crat can flip the bit instead of a steward. Antecedents and consequents. It is there for completeness, because it is in current discussion, but in no way shape or form does THIS proposal allow a crat to "make a decision". Even if CDA is approved, it is still not clear WHO makes the

589:

either: they don't use their current bureaucrat tools, and I don't think that any of them would start using them just to desysop people for fun (I don't remember admins who hadn't been active for years coming back in huge numbers when the ability to give out rollback was introduced).

2112:

That is still up for discussion and completely independent of this. If this fails and that passes, the crats will decide and then contact a steward. If that fails and this passes, arbcom/voluntary/emergency are still the only desysoping procedures but a 'crat could flip the bit. --

3716:

When your Arbitration Committee orders that an administrator be desysopped, a bureaucrat from this wiki would perform the job. I don't anticipate there would ever be a case where a steward would perform the task instead of a local bureaucrat - but perhaps I simply lack imagination

3973:

You're saying it's answered above, but you've not shown anything conclusive that this solves, other than it's a new process to improve the project but with a nebulous feel-good aspiration for it. Can you or can you not identify a problem this actually solves? Answer the question.

3424:

Stewards by their nature are impartial since they do not edit enwiki. Crats are by their nature highly involved in enwiki affairs. Desysopping, both due to the social stigma of it and the social consequences for the person performing it, seems better left to entirely uninvolved

3421:

recalls which indicated a broad consensus that someone should resign as an admin and pair that with the moans that arbcom is a cabal refusing to desysop fellow admins quickly. The same complaints would be placed on crats who refuse to implement an RFC or admin recall decision.

3646:

Re #1, They would have, I believe, had need been severe enough. Re #2, my point was that stewards edit here frequently and can be trusted to control themselves, so merely being frequent editors of a wiki does not make someone have an inherent COI --either steward or crat. --

1630:

To address the "emergency/voluntary" situations directly: has there been a problem with such requests through stewards in the past? I'm not aware of any situation where a delay encountered by the inability to reach a steward caused any significant problems in this project.

4507:

What is interesting, at least to me, is that I am on record opposing CDA (although I have taken part in the conversation in regards that IF it comes about, there are safeguards I would want to see put in) so, at least for me, this continued conflation is frustrating :D --

131:, is there consensus to allow bureaucrats to manually uncheck the sysop/crat bit when instructed per policy (currently by ArbCom, uncontroversial request by admin or crat to remove their own bit, in emergency desysop situations that would normally require a steward, and 4757:). Participation is actually much lower than in the previous poll (89 against 122). So, this poll can not be used to gauge consensus. At best it can serve as the first stage of a long process, which needs to be followed by a better organized and advertised discussion. 4651:

can't burden the Stewarts with that responsibility. If we granted 'crats the ability to remove the bit, then we will open up the doors for actual reform at RfA. Plus, if adminship really isn't that big of a deal, then it needs to be easier to move into and out of.---

2516:

Simple and Meta have their crats doing the removal so there is no "clean" log for all of wikimedia. Furthermore, in an emergency desysop, the steward could just grant themselves the 'crat bit and keep the log on EnWiki, the same way they do emergency OS and CU now. --

3733:. Since stewards are specifically elected to provide something closer to 'round-the-clock coverage than the English Knowledge's bureaucrats are, it wouldn't be unlikely that stewards would still perform that task. Your bureaucrats are not known for high availability. 2731:

Sure it does. It allows bit vacations to happen at the same place the restorations occur and keeps the logs on EnWiki. As for uninvolved parties, the stewards who respond here most often are EnWiki contributors (Lar, Cary, Pathoschild) so that is an error as well. --

3455:

Re (1), the hundreds of suppressions by stewards on enwiki suggest this is no longer the case. If we make it clear we are happy for stewards to continue to desysop in emergency cases, I am sure they will to do so even if crats gain the ability to do so as well.

3278:

part is not really discussed in the sections above. So without taking a stance on the issue myself, I'd like to pose the question: Should bureaucrats have the technical ability to de-crat other bureaucrats as well, or should that only be reserved for stewards?

1804:

any consensus to demote." Their rationales suggest that they are indeed imagining bureaucrats determining consensus, not just flipping the metaphorical switch. I believe you that this was not your intention, but I'm not sure it was as clear as it might be.

4004:

Fine. Then can you please answer (1) has this ever been a problem? Requests not handled properly or timely? Backlogged? (2) Does having the logs on separate projects create some problem I'm not aware of? (3) Only happened once and it's a problem to solve?

3313:

Yeah, basically. It's not exactly a common process, so there's not too much to worry about. Besides, if de-cratting was something that ever needed to be done ASAP, we might as well have the chance for someone here to do it faster, and for nicer logs. ~

4882:

I used a crude method (links on page, convert from talk pages, eliminate duplicates and pages with a /) and that gave 151 pages with only 32 who also showed up in this discussion. And yes, I know there's 1 missing. I was never a good mathematician ;p

2244:? I don't think so. Would reconfirming every 'crat be a huge waste of time? Yes. Also, this is a solution looking for a problem (as was said above): can anyone point to a specific case where local-desysopping would have provided any advantage at all? 3871:

I also think this proposal should be put on ice until the CDA advocates finish up their work. If (and God help us is it does) passes, we'll have an answer as to who closes CDAs, not a nebulous indecisive cloud that might or might not be bureaucrats.

2383:

How many rogue admin accounts have there been, ever? How many rogue bureaucrat accounts have there been, ever? How is there a higher chance for a compromised bureaucrat account than a compromised steward account? (a rogue steward would be far,

739:- If bureaucrats are trusted to make administrators, they should also have to power to take the mop away. Agree with Amory that the RfB bar is set quite high for the 'crats, so this is a logical duty for them. Talk about having been vetted! 374:

Yes. If crats can hand out the admin bit, they should also be able to remove it - there's no reason for it to be a one-way process. As we're limiting the use of this proposed ability to uncontroversial cases, I don't see any problems with it.

2573:

I agree with most of the above and see no reason to change anything. Also, I think we could have named this RfC in a way that actually describes what it relates to, and not some obscure title like "Bureaucrat Unchecking" (yes, I know that's

2295:

In every case of desysopping, it would be preferable to have a local log keeping track of it. As it is, the logs are split between meta and enwiki, which makes them less useful and more cumbersome to review. This is the biggest benefit, IMO.

4581:

That is 1) subject to change and 2) irrelevant to this discussion. Even if this fails, if that passes, 'crats may or may not have a role. And if that fails, this will determine who should be handling the rights losses on a process basis. --

3756:

Personally, I think it wiser in cases which are not emergencies to keep the logs all on EnWiki. In emergency cases, all hands are on deck, and I would hope a steward would step in immediately if they were notified of a rogue sysop/crat. --

2613:

I'd be willing to guess that most people won't read the title and think "Oh, giving crats the ability to remove rights". I think the title is inappropriate and perhaps intentionally misleading. But I'm not making a big deal about that. -

4214:

a personal dispute between you and Avi if you could address my addressing you, where I did my best to answer your "what problem does this solve?" question. From what I can tell, Happy-melon may be the only person that actually read it. :)

1887:

the same way they do to get it back (uncontroverisal, of course). When ArbCom decides that such-and-such user needs to be desysopped based on an RFaR, they can ask a local crat instead having to go to Meta. It's rather clear, actually. --

170:

Whenever a steward would have been asked to press the button to desysop/decrat, a bureaucrat can now press that button. The decision as to who gets desysopped does not change; only who presses the button once the decision is made. This is

4276:

I expect the reason why no one has expanded on the question "why having the logs on separate servers is a problem" is that they consider it to be blindingly obvious. As an example, please give me the log summary for the desysop between

3071:

No one is proposing that a crat desysop based on an ANI thread, any more than we would make someone a sysop based on an ANI thread. There is no current involuntary community based desysop method, and this proposal wouldn't change that.

4498:

where this was publicized, and soon after (I presume) on the RfC page. Most likely opposers started to spread the word late, which was why their response was so delayed, but, what can you do. I cannot control canvassing by opponents :(

3818:

Ok, in order (1) has this ever been a problem? Requests not handled properly or timely? Backlogged? (2) Does having the logs on separate projects create some problem I'm not aware of? (3) Only happened once and it's a problem to solve?

1644:

I do think that if there is a crat who desysops without consensus, they will be quickly decratted themselves. These crats were chosen to judge consensus fairly, and desysopping fits into the category of consensus-judging as sysopping.

1325:

This seems like a good (and obvious) idea. The recent farrago where it took forever to get the bit taken from Cremepuff at the point where everyone thought the account was compromised is one reason, keeping the records in one place is

1090:- As per last time. I think we should keep things local but I'm sure stewards would still take action in the event of an emergency with a rogue admin. This will also become even more useful if community de-adminship is ever approved. 4635:. They will simply have to take a longer route in asking for a steward to desysop (which they will do based on the crat's judgement) rather than do the deed themselves. The point is irrelevant to whether they have the right or not. — 4471:

As an (obviously failed) attempt to prevent conflation with anything resembling 'crats making a decision. This is solely regarding once a decision is made in the regular wiki way, who unchecks the box (see the interface - it is a

1130:

Striking support as some have pointed out that this (rights being removed both here and at meta) might make more of a mess as opposed to less. A technical solution would be ideal. I may revisit this on its merits at a later date.

2354:

a lot of admins (presumably fairly easily, I don't know what the interface looks like). Unless there's a problem with the work load for stewards that this is meant to solve, it seems to me that the costs outweigh the benefits.

298:

Re-confirming my support, following the clarification of the CDA situation. (Note that I have italicised the CDA part, emphasising that this is not under discussion here, and it is only a potential possibility in the future) --

3047:. No Ta the current system works well and I'm opposed to extending 'crat roles into areas in which in the incumbents were not elected to work within. Absent reelecting the whole 'crat cadre I'm not interested in this proposal. 2411:

It could be a problem, but it wouldn't be a new one; as you say, a compromised steward account always has been and probably always will be far more dangerous. Would throttling Special:Userrights to non-bot speeds be helpful? –

3006:- Although some projects allow this, I think for this project I'm not in favor. Going to Meta to ask and having to show that the request is within process seems a good check. Also, per WJBScribe, Titoxd, MZMcBride, et al. ++ 4738:

The boilerplate text says that RfCs get automatically delisted after 30 days, but that does not mean it cannot be closed earlier. Perhaps the uninvolved admin should make the decision if it warrants being open longer? --

3889:

Your case is made as has been mine. The project's membership, of which you and I are but two individuals, will decide. If there is a consensus that this is not necessary, trust me, wikipedians will let it be known :) --

4099:

You believe having to send a sysop requesting a vacation off-wiki is not a specific problem; I believe it is. You believe having separate logs is not a specific problem, I believe it is. So, you are clear about what

3856:

Yet you've so far been incapable of identifying a problem this proposal solves. We've gone for many, many years with the structure as it has been. You want to change that structure for apparently no reason. Why?

1821:

have a community-dictated de-adminship system without 'crats unchecking the box, it's just more convenient if they can uncheck, just like we can have 'crats capable of removing bits upon request without having a

1867:

users who are responsible for determining consensus at CDA. That's not going to happen and you know it. No sense in creating a new class when we already have a class that does the same thing (if in reverse). --

2081:

you can go to a crat and not a steward. Most often, this will deal with the requests we get at WP:BN for people who want to take a vacation from their bits that right now we have to send to the stewards. --

3594:

And so? We have strict policies on EnWiki regarding these situations. If a bureacrat cannot be trusted to adhere firmly to the policy and guideline despite personal discomfort, that person should not be a

2718:

I think the current system works well; the proposal doesn't manifest any benefits, while introducing new potential security risks. I also agree with MZM that introducing an uninvolved party is beneficial.

2164:

We don't know what CDA will result in. It is blatantly obvious that this proposal and that are tied together. Far better to do this in serial than parallel, so we know what we are getting ourselves into.

3417:

If someone can do something, they will. We saw how the turning on of the ability to grant rollback was done before we had a policy on granting it, and I believe this is putting the cart before the horse.

2045:

I am misunderstanding nothing. CDA is mentioned in the intro to this proposal. I am not making a mistake. If I am, then you should be addressing the person who formed this RfC, namely yourself, not I. --

520:

I think it is commonsense that anyone wanting to give up the mop should simply be able to do so by asking a crat on this wiki, and that a crat should be able to desysop an obviously compromised account.

4617:, as a bureaucrat could request that a steward removes the rights. It is important not to confuse the question of (1) who can remove the rights with (2) who decides when those rights should be removed. 2388:

more damaging) The idea of a rogue 'crat is always hauled out of the dungeon of wiki-fears whenever this gets mentioned, yet I've never heard any actual rationale for why this would ever likely happen.

3414:

an emergency request system in place and are positioned around the globe to give 24/7 coverage and the crats are biased towards English-speaking countries, this would result in a decrease of coverage.

2702:

Sure it does. It allows bit vacations to happen at the same place the restorations occur and keeps the logs on EnWiki. What do you believe is better about the current process, other than inertia? --

2350:- it strikes me as a security risk. Currently a compromised Bureaucrat account could create a lot of admins (which could cause some problems), but with this extra power, a compromised account could 4159:

I find it interesting that these oh-so-entrusted users have taken the time and effort to disparage my adamant opposition to this proposal as a form of a vendetta against Avi. Right. <cough: -->

2142:

restrictions that the stewards have). If CDA is accepted by the community, we'll be adding a fourth item to the list of flag removal criteria, but it can exist just fine with the existing three.

655:

Yes, this really is just common sense. However, per the comment in the discussion section below, I'm not sure about letting Bureaucrats remove fellow Bureaucrats, as opposed to Administrators. --

2501:

is not mentioned anywhere? It would be very useful for everybody to re-read it. The present discussion seems to be just a repetition of past one. In fact no new arguments have been made so far.

1852:

I thought it was clear in the description (as did others, see the talk) and I added a clarification nutshell. Other than renting a megaphone, I'm not sure what else I can do 8-). Any ideas? --

3591:

Which is why this RfC is coming BEFORE any requests to developers to change the 'crat rights package. Only if this has a consensus will the developers be approached to adjust the crat package.

2061:

See above where I answered you, and yes, you somehow missed the antecedent of the hypothetical syllogism. I've said this a bunch of times on this board already, but for you I'll say it again.

3709:

I was asked by MBisanz to provide an opinion here. Broadly, I think it makes more sense to leave things the way they are, however let me make some comments on the proposed future situation:

2031:

I believe you are misunderstanding this proposal. This proposal adds no new judgement to desysop someone. Just whenever we would ask a steward to to remove a bit, we can now ask a 'crat. --

218:

I think this is an excellent suggestion. If local 'crats can flick the switch on when they have judged concensus has shown it to be desired, I think they should be able to flick it off if

4349:+sysops, you know that there's a -sysop sitting in the global rights log which you need to find, but if there's no break in the logs, then problem solved. As opposed to now, when you are 1237:

Obviously - they should be able to undo if needed to. It makes no sense that it is the only irreversable thing. That's the problem, not that there needs to be a problem to try new ideas.

407:

risk exists with stewards. But even such actions could be swiftly reverted, so the slight risks involved (which are involved everytime someone is granted any rights) are minimal. Regards

4430: 3253:

Leaning toward WJB Scribe's well-argued oppose, but also inclined to agree with some of the supportive comments. Will continue to monitor this page and may be persuaded either way. --

2498: 4292:+sysops on metawiki, which is a wiki where bureaucrats can desysop. In the meantime I will maybe have time to check my watchlist, if your internet connection is particularly slow. 21: 3666:

confusion about what circumstances will lead to desysopping. My concern (and I gather Matt's) isn't that the bureaucrats will succumb to that confusion but that other people will.

2860:

grant that there is no way to judge whether stewards practice better account security precautions than crats so are not necessarily less likely to lose control of their account. ++

4285:, my current article project, or maybe a whole section if you don't know off the top of your head Harej's previous username. Then give me the log summary for the desysop between 1817:

proposal is about the 'crats being able to uncheck a box (and only that). There's a relationship, yes, but not necessarily a direct cause-and-effect between the two proposals. We

4436:

Why in the first 24 h after this RFC was started (at 8:36, 10 January) 36 users !voted support and 4 oppose, while in the next 24 h 14 supported and 13 opposed? Were the former

2746:

Please don't tell me you're going to respond to the majority of dissenters on here individually. Sort of poor form, in my opinion (coming from somebody who supports this idea).

2599:

what this RfC is about; people who continue to conflate this with CDA or new ways to desysop are confused and incorrect, at least as to what the intent of the proposal was. --

3675:

That is an error on the part of the people using the word then; I think I re-clarified in the nutshell above that there is no decision being made here. There is no change to

4353:

to have to look in both logs. In a few cases, the situation is the same as the status quo, and in the vast majority it is better. How is that "making the problem worse"??

3725:

to retain tools against their will. Nonetheless, we'd probably prefer for that to be handled by your bureaucrat team whenever possible. Likewise, in an emergency situation,

2933:

been a problem caused by the hop to meta to request bit removal: the response time there is measured in minutes, and stewards are both careful and measured. Personally, I

2479:

per Guettarda and Nathan. No good policy reason to do this, serious security risks and it isn't like this is a substantial workload that is going to be moved over this way.

4289: 4286: 1192:

at a Request for de-Adminship. And come on, let's face it. How likely is it that we are going to get a rogue bureaucrat? I suppose it is theoretically possible to create a

4930: 1951:

I personally don't care what subordinate-to-me hats you've decided to put on your head. Back to the point, what incidents have happened that this us supposed to solve? --

509:

Sure, much clearer to have the relevant process in our logs than meta's. The decision mechanism when to desysop is unchanged (ArbCom), just the implementation is nicer. —

4678:

It's clear that this poll is winding down, with only two contributions in the past week. Is it time for closure? If so, I'll poke AN for an uninvolved administrator.

3380:

At the end of the day, there is really no danger in implementing this; certainly far less danger than giving someone the bit in the first place. Any bureaucrat who goes

3274:

If this proposal passes, bureaucrats will have the technical ability to desysop administrators. Avi also proposes giving them the ability to de-crat fellow bureaucrats.

3123:

I truly don't trust some of the crats enough that are currently active to remove the bit absent of their own POV on the situation, this is why we have stewards do it. --

2559:

move the "community de-adminnings" process further forward, something that I don't think is particularly wise given the competency of the general Knowledge community. --

101: 97: 3834:

Can we go on as we are doing now? Of course. However, the purpose of this RfC is to determine whether or not the project and its members believe that we can do things

2899:

Bureaucrats having -sysop (and -crat) is the software default and is the case on wikis like meta and simplewiki. It is not in any way "incompatible with WMF rules".

2937:

having uninvolved outsiders as a buffer to bit removal and the trivial improvements of centralizing logs is most certainly not worth losing that added protection. —

4130:

I think EVula's half-buried point above is extremely important: if this proposal is implemented, rights logs will follow the user around with renames. Currently if

1765:

Also, Hammersoft's point is quite correct: CDA is mentioned at the top of this page, so it's a little strange to claim that there's no relationship between the two.

903:, and I'll say it again: 'crats are elected to judge RfX consensus and grant the +sysop and +crat flags. Let's give them a job they were basically meant to perform. 3496:

unhappy). It could make 'crats more of a target than they are now, as opposed to Stewards, who are decidedly neutral and largely beyond such petty criticisms. ~

2833:

Any admin on any project can gain control of a steward or bureaucrat account. The real danger from such a compromised account is that it will then be used to

3492:

I don't think MBisanz is so much saying that an involved 'crat would take an action, but rather that people might perceive it as such (desysops always leave

2279:

RfB may very well be more rigorous than the presidential election. I'd say they're trusted to unchecked the same button then checked in the first place. –

4502:

If there is a consensus that approves, the developers will be approached to add the userrights package to 'crats to allow unchecking of sysop/crat boxes.

3295:

I think it's the same question. They are after all able to grant +crat as well so it's only logical that they should be able to de-crat as well. Regards

2069:

whatever decision process be accepted in the proposal actually happen (be it a community vote, an RfAR, or the collected writings of a thousand monkeys)

356:

I don't see why they should only be able to make the change one way. This is a quite separate discussion from the perennial "community de-sysop" debate.

3923:

be a smidgen of "under a cloud"-ness to the removal. Renames will apply to the logs, more direct references can be made in the bit removal, and someone

3440:

But, I also think that crats should not be seen as aggrandizing more power, even technical, to themselves, so that is why I am neutral on the proposal.

3352:

where the box needs to be unchecked (voluntary vacation, ArbCom, emergency, and, if CDA ever gets implemented, in that case too). This RfC is not about

1395:. My only fear is that RFB will be much harder to pass from now on. Users, especially those careless crats, do have the tendency to go rogue after all. 771:

If crats are trusted to judge consensus to promote someone to an admin, they should be able to judge consensus to demote someone from an admin as well.

4426:

supposed to mean: (a) Bureaucrats unchecking some RFC; (b) RFC about a need to uncheck all bureaucrats; (c) RFC about bureaucrats unchecking something?

718:

situations are eligible for unchecking bits, just, when bits are supposed to be unchecked for acceptable reasons (voluntary resignation, ArbCom, etc.)

4563: 3721:

When users wish to have their own tools removed, they would ask a local bureaucrat. When there is some emergency, a local bureaucrat would intervene.

1731:

Huh? I don't think you understand. Stewards already routinely do desysops as instructed by ArbCom or the user's request. This proposal doesn't change

812:

Why not? The role receiving the extra option is the one that turns on the bit. This accords no new discretion or decision making powers. No big deal.

1508:

as per "if they can be trusted to do so & so why not this?", plus additional controls over potentially uppity admin/crats isn't such a bad idea.

852:

Better log system if we kept it local, and a one-way "flip of the switch" doesn't make much sense. It seems like the logical choice to enable this.

4482:

Statistically, that means that the opposers were more likely canvassed. The initial respondents likely saw it pop up on their watchlists of either

2180:

userright changes locally when the editor in question requests it, or why bureaucrats can't be the ones to execute ArbCom flag-removal dictations?

2127:

And if they both pass then bureaucrats will be making that call. Sorry, ice this proposal until CDA gets done. Now. For the good of the project. --

3153:

I just don't see how this is such an current issue that it needs the energy and attention of developers. Focus energies on more important things.

3432:

However, I do agree that the split enwiki and meta logs are annoying and that it would be better if all transactions were placed in the same log.

3057:

worse when consensus could go either way. The current system, which works fine, will have abusive admins have their bits stripped in due course.

4389:

is supposed to be. To me, any process that must be implemented outside of the community, other than for legal reasons, is broken to begin with.

1689: 579:

Allowing our crats to flip the switch in the other direction will take load off foundation and make the action just that little more responsive.

1427:

guidelines for when this can be used (instructions by ArbCom, fixing one's own mistake, and request by user being desysoped/decratted, etc).

3842:

options. Having local people doing local project work and keeping the logs in one place is preferable to me, and apparently many others. --

4385:

outside. We are a self-policing communtity. Going to outsiders to implement our already policy-based decisions flies in the face of what a

1933:. I'm sorry you have a personal issue with me, and, if you can find any instance where I abused any privileges, please let both me and the 1473: 1408: 492:

Clearly sensible. I would also trust bureaucrats to add and remove oversight and checkuser flags, when requested to do by ArbCom. — Martin

4772:

Your procedural questions have been responded to, Ruslik. An uninvolved admin will make the decision, neither you or I are uninvolved. --

1069:

Cleaner and more rational to keep enwiki stuff on enwiki whenever possible. Mike.lifeguard's assurance (in discussion section below) that

96:

Given the numerical support for 'crats being able to turn off as well as turn on the admin bit, and looking at the additional comments at

3364:

may check the box. For symmetry, efficiency, and keeping the logs here, it makes sense, in my opinion, that 'crats are able to do so. --

2009:, the need of a steward's presence to emergency desysop someone has always been met rapidly. The supporters of this should at least show 4020:

Responded above yet again. Just because something works does not mean we should not investigate more elegant and efficient methods. --

4820:

I've been meaning to work out how great the overlap is between the two groups; haven't got round to that yet. Do you fancy doint it?

3516: 3334: 3219:. If we want to have this on en.wiki, then it should be given to those who have been elected to do this, and have identified to WMF. - 641: 319: 287: 242: 4858:

Your first list seems to have as many people on it as contributed to the old discussion at all; I assume there's some issue there...

2258: 1883:

No, that when somoene comes to voluntarily relinquish the bit, they do not have to go to meta to get it turned off, but can come to

959: 389:

Of course. If they can be trusted to give it out, then why not to perform the removal which has a much lower potential for harm.

17: 1150:

Frankly, I thought they had this ability already, probably because it makes so much sense to be able to undo what you've done.--

4237:

For some reason all your text appears in rot13 :) Seriously, please assume some good faith. I have no axe to grind with Avi. --

402:

Seems only the logical wiki-way: If you can add something, you should be able to remove it again. And as JzG says above, it's

3631:

Second, Lar, Cary, and Pathoschild do not do rights changes on enwiki specifically because the steward policy prevents them.

3284: 2304: 678: 608: 4891: 4877: 4853: 4836: 4815: 4802: 4781: 4767: 4748: 4731: 4710: 4694: 4665: 4639: 4626: 4591: 4575: 4548: 4532: 4517: 4456: 4401: 4369: 4341: 4327: 4312: 4266: 4246: 4232: 4203: 4189: 4170: 4154: 4124: 4113: 4082: 4067: 4044: 4035:

So there's no specific problems this is intended to solve? Am I clear? Just an abstract notion that this might be better? --

4029: 4014: 3998: 3983: 3967: 3949: 3914: 3899: 3881: 3866: 3851: 3828: 3812: 3786: 3766: 3750: 3692: 3670: 3656: 3639: 3622: 3563: 3525: 3487: 3465: 3448: 3401: 3373: 3343: 3308: 3288: 3262: 3248: 3228: 3210: 3193: 3178: 3145: 3113: 3096: 3081: 3066: 3051: 3039: 3018: 2998: 2981: 2962: 2941: 2915: 2894: 2872: 2854: 2828: 2810: 2789: 2768: 2755: 2741: 2726: 2711: 2697: 2683: 2657: 2638: 2623: 2608: 2587: 2568: 2542: 2526: 2511: 2488: 2469: 2448: 2425: 2406: 2378: 2364: 2340: 2314: 2290: 2274: 2265: 2224: 2197: 2174: 2159: 2136: 2122: 2105: 2091: 2054: 2040: 2026: 2017:

It's already damned difficult to become a bureaucrat. Adding another privilege to the mix is going to make it impossible. --

1980: 1960: 1946: 1916: 1897: 1876: 1861: 1843: 1808: 1798: 1769: 1760: 1750: 1726: 1712: 1696: 1681: 1665: 1639: 1625: 1604: 1573: 1556: 1533: 1517: 1500: 1479: 1451: 1434: 1415: 1387: 1364: 1347: 1335: 1317: 1301: 1284: 1267: 1250: 1232: 1219: 1186: 1162: 1139: 1106: 1082: 1064: 1040: 1022: 1009: 996: 979: 963: 941: 918: 894: 877: 861: 847: 838: 821: 807: 763: 743: 731: 709: 688: 664: 650: 612: 593: 583: 574: 558: 537: 515: 504: 487: 475: 453: 420: 397: 384: 369: 351: 325: 293: 262: 248: 210: 152: 117: 91: 66: 1459:. If we trust crats to not grant +sysop or +crat without prior approval, then we can trust them not to remove them either. 2458: 2765: 2723: 2270:

Why would there be an additional level of trust needed to desysop an admin? It is by far the less damaging of the two. —

1673:

local, and a search for rights changes will often require checking both places. That doesn't seem like a benefit to me.

4566:. In the current proposal, bureaucrats will indeed be responsible for determining consensus on deadminship requests. -- 3435:

Additionally, I agree it makes sense that things on the wiki should be able to be undone by the person performing them.

2691:

the_ed17 ditto. As Ruslik and MZM point out there's nothing that this solves that makes any process better or easier.

1594: 1331: 843:

Makes desysopping local; less chance of a steward doing an action which he is ill-informed about. More transparency. —

549: 528: 2005:, ArbCom is well capable of de-adminning someone, and once requested it's not something that needs rapid resolution. 1116:-if only to make the rights log make sense for desysopped admins. I would revisit this for deeper consideration if a 4318:

And this proposal would not fix that, as Ruslik0's opposed (currently #8) shows. In fact, it would make it worse. --

3989:

There are three situations listed above which will be more elegantly and efficiently addressed by this proposal. --

696:. 'crats are trusted to determine consensus to promote; no reason to suggest they can't determine any consensus to 1813:

I think that it's a natural jump to make (one I myself made in my comment), but that doesn't change the fact that

3280: 3169: 3015: 2869: 2001:

has not achieved acceptance (nor is it likely to), so there won't be some sudden flood of de-adminship requests.

604: 2970:. There is no convincing explanation why the status quo is broken, so per the tried-and-true engineering adage, 4753:

The participation in this discussion has been very low, so far. Why it has been so low is explained above (See

3744: 1529: 1513: 1494: 1468: 1403: 1212: 1193: 1280: 2096:

We are NOT going to be creating an entirely new class of user to decide CDA. It will be up to bureaucrats. --

1564:

per WJBscribe's concerns, only if bureaucrats automatically loose their privilege on extended inactivity. --

2762: 2720: 834: 3579:

That is a policy specific to oversight and checkuser, I beleive, not switching bits, as the steward has to

4433:

was not mentioned? And why a wrong impression was created that this a new proposal never discussed before?

3958:

no longer a matter of logic but of emotion. You like A and I like B. Do you disagree with my analysis? --

3510: 3328: 2288: 1748: 1710: 1327: 972: 635: 544: 523: 313: 281: 236: 208: 3547:

should not be a 'crat and that would most likely be picked up by the community/other 'crats. Regards, --—

2953:

who no longer has its confidence before assigning another ability that is likely to prove controversial.

1276: 4870: 4829: 4795: 4724: 4687: 4362: 4305: 4251:

OK, I'll put it down to the heat of the moment; something I am only too well aware of in my own editing

4147: 2908: 2847: 2803: 2751: 2420: 2252: 1380: 1315: 1157: 1078: 857: 580: 344: 2215:

We did not elect 'crats to do this. The discussion at Neutral #1 also convinces me it is a bad idea.--

4440:? (Especially taking into account that some of the supporters did not understand what they voted for.) 4660: 4571: 4323: 4242: 4199: 4166: 4040: 4010: 3979: 3927:

can be asked about why they removed someone's right. I'll admit that (perhaps) there isn't a problem

3910: 3877: 3862: 3824: 3782: 3556: 3480: 3394: 3216: 2170: 2132: 2101: 2050: 2022: 1956: 1912: 1872: 1722: 1660: 1600: 1431: 1343:'crats should be technically able to desysop. They shouldn't do so unless prescribed to, of course.-- 1200:. A bureaucrat with the ability to desysop people is no more (and in fact far less) dangerous than a 758: 660: 468: 448: 52:

Despite gathering some support, consensus has not been achieved for this proposal. Discussion closed.

787: 4636: 4622: 4332:

Which is already the case on simple and meta, IIRC, which all have crats doing the + and minus. --

4078: 3738: 3461: 3092: 3062: 2994: 2958: 2634: 2564: 2360: 2271: 1569: 1525: 1509: 1489: 1463: 1460: 1398: 1263: 1205: 844: 705: 4443:

What will be the significance of this strange and poorly organized RFC? (I suppose close to zero.)

1309:

I agree it would be beneficial for an additional pool, to act expeditiously when and if required.

4282: 4094: 3919:

Honestly, I think this would go a long way towards killing any returned-bit requests where there

3206: 2671: 2310: 1045:

Makes abundant sense to me, though it does seem mildly amusing that in order to avert unecessary

1006: 954: 912: 890: 830: 817: 684: 427: 380: 183:

that occur in the future, the role of 'crats in that process will be determined then (please see

128: 114: 88: 63: 3598:

Lar does not edit Enwiki? Bastique does not edit EnWiki? Pathoschild does not edit EnWiki? etc.

2629:"Proposal to allow bureaucrats to remove adminship," the opposition here would grow rapidly? -- 4777: 4762: 4744: 4705: 4587: 4544: 4527: 4513: 4451: 4437: 4337: 4262: 4185: 4135: 4109: 4025: 3994: 3963: 3895: 3847: 3808: 3762: 3688: 3652: 3618: 3504: 3369: 3322: 3258: 3189: 3109: 3037: 2737: 2707: 2653: 2619: 2604: 2583: 2537: 2522: 2506: 2484: 2374: 2281: 2220: 2118: 2087: 2036: 1976: 1942: 1893: 1857: 1794: 1741: 1703: 1245: 1102: 1059: 992: 727: 629: 570: 302: 270: 258: 225: 201: 148: 3777:

Could someone please answer the simple question of what problem this is supposed to solve? --

2777:

The reason that crats cannot remove rights is to mitigate a particular attack vector. — Carl

4862: 4821: 4787: 4716: 4679: 4395: 4354: 4297: 4225: 4139: 4121: 4060: 3942: 3667: 3132: 2900: 2890: 2839: 2795: 2747: 2578:

what happens, but that's the least of what should be noticed when looking over this RfC). -

2441: 2414: 2399: 2333: 2247: 2190: 2152: 2013:

case where the project was damaged because a rogue admin wasn't removed in a timely manner.

1836: 1805: 1766: 1757: 1693: 1679: 1637: 1623: 1551: 1374: 1360: 1310: 1229: 1224: 1151: 1074: 934: 853: 484: 391: 337: 31:

RfC: Should bureaucrats be allowed to uncheck the sysop and bureaucrat bit when instructed?

4653: 4567: 4376: 4319: 4238: 4221: 4195: 4162: 4056: 4036: 4006: 3975: 3938: 3906: 3873: 3858: 3820: 3778: 3550: 3474: 3388: 3381: 3302: 3224: 2437: 2395: 2329: 2186: 2166: 2148: 2128: 2097: 2046: 2018: 1952: 1908: 1868: 1832: 1718: 1590: 1428: 1293: 1197: 1035: 1019: 930: 751: 656: 618: 462: 414: 77:

up against the 65 support votes instead of the total participating - 94. I'll look again.

2816:

downside potential and very little benefit that I see, so I oppose the proposal. — Carl

4889: 4851: 4813: 4807:

What if we were to ping the previous respondents that haven't weighed in here as yet? –

4619: 4562:

Just to be clear, since there seems to be some disagreement on this point, please read

4075: 3458: 3088: 3077: 3058: 2990: 2955: 2929:

attempts to presuppose CDA (or shore up the proposal). I don't believe that there has

2692: 2630: 2560: 2356: 1934: 1565: 1447: 1344: 1259: 1137: 1126: 873: 701: 590: 565:

Clearly a good idea for them to be able to uncheck an admin in certain circumstances -

499: 3730: 1073:

stewards will still do an emergency desysop addresses the only minor concern I had. --

267:

Thanks for clarifying that, Avi (and adding it to the proposal above for clarity). --

4924: 4786:

Why can this poll not be used to gague consensus? That's not a rhetorical question.

4614: 4608: 4604: 4600: 4555: 4416: 4296:

is the problem: it is genuinely difficult to view the past history of enwiki users.

3905:

So you're not going to continue the discussion on what problem this solves? I see. --

3202: 3162: 3138: 3011: 2865: 2823: 2784: 2677: 2666: 2297: 2233: 1998: 1924: 1823: 1117: 1049:(having to send de-sysop requests to stewards) we would grant an additional power to 1002: 950: 904: 900: 886: 813: 740: 671: 376: 364: 358: 184: 136: 107: 81: 56: 1692:), so there it is not relevant to the current or historical purview of bureaucrats. 1373:

take it away, of course with orders to do so. The crat giveth the crat taketh away.

4773: 4758: 4740: 4701: 4583: 4540: 4523: 4509: 4447: 4333: 4281:+sysops on enwiki. In the meantime, I will write a paragraph of sourced prose for 4258: 4181: 4131: 4105: 4021: 3990: 3959: 3891: 3843: 3804: 3758: 3684: 3648: 3633: 3614: 3442: 3365: 3254: 3242: 3185: 3105: 3048: 3027: 2733: 2703: 2649: 2615: 2600: 2579: 2533: 2518: 2502: 2480: 2463: 2370: 2216: 2114: 2083: 2032: 1972: 1938: 1889: 1884: 1853: 1790: 1654: 1239: 1091: 1054: 988: 723: 600: 566: 442: 254: 144: 4631:

If the CDA passes, bureaucrats will be deciding the outcome of the de-adminship

3126: 2975: 2886: 1674: 1632: 1618: 1544: 1356: 773: 481: 3798:

Preventing an accident from being corrected quickly (only happened once though)

3792:

Having to send requests for bit vacations to Meta and not handling it on EnWiki

4216: 4051: 3933: 3297: 3220: 2938: 2432: 2431:

could potentially find himself hitting that throttle, although it's unlikely)

2390: 2324: 2181: 2143: 1827: 1583: 1297: 1171: 1028: 1015: 925: 511: 409: 987:. If we trust them to grant the bit, we can trust them to remove it as well. 175:

at present, a referendum on 'crats judging consensus for desysops, and there

4884: 4846: 4808: 3073: 1443: 1132: 1121: 868: 495: 4522:

You misunderstood the item 5—it was not really a question but a statement.

603:? In my opinion, this proposal makes a lot more sense than the status quo. 4415:

Why this discussion is held on rather an obscure subpade, but not on the

3154: 3007: 2885:

Solution looking for a problem. May also be incompatible with WMF rules.

2861: 2819: 2780: 4611:

should also oppose this proposal, which raises different considerations.

4539:

Perhaps; you listed it as a question, it was only polite to respond. --

4194:

I'm sorry if you feel that was a personal disapprobation. It was not. --

3704: 3406:

There are several reasons I have opined in the neutral on this proposal.

2319:

I posted my thoughts to the "what problem does this solve?" question at

2240:. Are we sure that every single one of them also has community trust to 1903:

find it odd that a user here with virtually every bit is asking for yet

1541:

We trust them to gauge consensus, and we can trust them with this tool.

1201: 4253: 3932:

is that it's tradition, which I (and several others) find rather weak.

3184:

I believe it is the matter of making a small change to a text file. --

1648: 436: 4613:

This proposal passing is not, after all, a necessary pre-requisit for

3588:

an emergency, keeping everyting on EnWIki instead of Meta is sensible.

1929: 1120:

made the desysopping done at meta reflected in the local rights log. –

220:

concensus in a community discussion (or as instructed by Arbcom) shows

4603:

is implemented. If someone doesn't like the idea, they should oppose

2457:

You can see what the interface looks like and play around with it at

1198:

so many more ways of causing damage with just the administrator tools

829:. Minor change to procedure that will bring a small efficiency gain. 1442:

This really isn't a big deal. It should have always been this way.

949:. However, the unchecking should only be limited to administrators. 98:

Wikipedia_talk:Requests_for_adminship/Archive_194#Unchecking_the_box

1275:

It makes sense to be able to undo pressing a button you can push.

971:. Eliminate unnecessary red tape – more power to the bureaucrats! — 1228:

should also trust them to demote users in accordance with policy.

2761:

different community, which increases the degree of impartiality.

542:

Also per HappyMelon below and for implementing Arbcom decisions.

4596:

If don't think there's any disagreement as to what would happen

4386: 104:, to look into mechanics of the proposal should now take place. 433:

being able to desysop someone. This proposal just makes sense.

156: 4120:

wholeheartedly that the proposal was intended in good faith.

3576:

Hi, Matt. Let me try and address your concerns individually:

2369:

The interface is checkbox, the way every userrright is. --

2320: 1968: 1789:. This is solely about who can check and uncheck a box. -- 1688:

Desysopping is not currently based on community consensus (

670:

this is a good thing, especially in cases of emergency. ···

617:

As per everyone, it just makes sense. There are plenty of

4073:

don't think this is a problem, Avi does. Can we move on?

253:

It would be defined as it is now "not under a cloud". --

4633:

regardless of whether they have the userright to desysop

4464:

Similar to RFB Bar, it is a bit related issue. The pump

2989:

Per WJBscribe above, MBisanz and Ruslik concerns below.

1701:

This proposal has no bearing on community desysopping. –

216:

As long as "incontroversial" is defined, then definitely

4842: 4495: 4491: 4487: 4483: 4465: 4278: 4177: 3628:

too large to qualify for small wiki monitoring efforts.

3795:

Having the +bit and -bit logs on two separate projects

4422:

Why the title of this page is so misleading? What is

4210:

Hammersoft, I'd be more willing to believe that this

3360:

an English Knowledge valid situation for an uncheck,

4915:

Subsequent comments should be made in a new section.

4843:

http://en.wikipedia.org/search/?&oldid=340594877

1717:

Then why does it mentioned it in the header?????? --

44:

Subsequent comments should be made in a new section.

4134:is sysopped here, then desysopped, then renamed to 3385:

this and potentially a lot of benefit. Regards, --—

1780:it is implemented, then once the decision is made 4909:The above discussion is preserved as an archive. 4564:Knowledge:Guide_to_Community_de-adminship#Closure 4178:You did bring personal issues into the discussion 3727:stewards will do whatever we can that's necessary 2664:I find myself in agreement with Ruslik and MZM. — 714:As nom. To reiterate, this RfC is not discussing 4257:. Thanks for the clarification, Hammersoft. -- 2234:made bureaucrats due to trust by the community 4607:. It doesn't follow that someone who opposes 3729:to fix the situation, in accordance with the 179:no consensus-based desysop process in place. 47:A summary of the conclusions reached follows. 8: 1907:power to add to his cap. That bothers me. -- 141:should that be implemented at a future date) 4931:Matters related to requests for adminship 4715:Why? That's not a rhetorical question. 2321:#What problem is this supposed to solve? 2065:CDA ever comes around and should it do, 1969:#What problem is this supposed to solve? 722:is able to actually uncheck the box. -- 199:Best to keep things local if possible. – 4558:will have bureaucrats deciding outcomes 3773:What problem is this supposed to solve? 3713:outline the changes this might bring. 1196:of bureaucrats, but there are already 885:I have believed this for a long time. 3602:that is less likely because of chats. 2925:; this does not solve a problem, and 2077:process is decided upon to be valid, 1355:, per logic put forth by Cyclonenim. 924:sense for them to have that ability. 7: 4104:belive, but not about what I do. -- 1782:by whatever process CDA decides upon 38:The following discussion is closed. 3683:implements the valid decision. -- 28: 3703:For those who don't know, I am a 4252: 3240:See detailed explanation below. 2972:if it's not broken, don't fix it 2236:actually only received trust to 1994:Solution looking for a problem. 1928: 1776:It is mentioned in as much that 975:what a crazy random happenstance 160: 18:Knowledge:Requests for adminship 4393:is the problem we need to fix. 3356:situations get an uncheck, but 3104:wrt stewards) very quickly. -- 1937:know, for everyone's sakes. -- 1: 2459:Special:UserRights/MBisanzBot 1605:09:56, 12 February 2010 (UTC) 1128:16:44, 11 January 2010 (UTC) 118:14:03, 14 February 2010 (UTC) 92:13:43, 14 February 2010 (UTC) 67:19:39, 13 February 2010 (UTC) 4892:02:09, 29 January 2010 (UTC) 4878:21:36, 28 January 2010 (UTC) 4854:21:14, 28 January 2010 (UTC) 4837:21:04, 28 January 2010 (UTC) 4816:21:01, 28 January 2010 (UTC) 4803:20:59, 28 January 2010 (UTC) 4782:20:07, 28 January 2010 (UTC) 4768:19:29, 28 January 2010 (UTC) 4749:15:53, 28 January 2010 (UTC) 4732:10:17, 28 January 2010 (UTC) 4711:10:15, 28 January 2010 (UTC) 4695:08:50, 28 January 2010 (UTC) 4666:16:17, 20 January 2010 (UTC) 4640:23:23, 11 January 2010 (UTC) 4627:17:11, 11 January 2010 (UTC) 4592:16:29, 11 January 2010 (UTC) 4576:16:18, 11 January 2010 (UTC) 4549:14:08, 14 January 2010 (UTC) 4533:12:51, 14 January 2010 (UTC) 4518:21:30, 12 January 2010 (UTC) 4457:19:48, 12 January 2010 (UTC) 4402:21:49, 12 January 2010 (UTC) 4370:12:14, 12 January 2010 (UTC) 4342:22:45, 11 January 2010 (UTC) 4328:22:43, 11 January 2010 (UTC) 4313:20:50, 11 January 2010 (UTC) 4267:18:36, 11 January 2010 (UTC) 4247:18:05, 11 January 2010 (UTC) 4233:17:40, 11 January 2010 (UTC) 4204:16:01, 11 January 2010 (UTC) 4190:15:42, 11 January 2010 (UTC) 4171:15:31, 11 January 2010 (UTC) 4155:10:53, 11 January 2010 (UTC) 4125:05:27, 11 January 2010 (UTC) 4114:02:15, 11 January 2010 (UTC) 4083:12:48, 11 January 2010 (UTC) 4068:02:14, 11 January 2010 (UTC) 4045:02:07, 11 January 2010 (UTC) 4030:02:06, 11 January 2010 (UTC) 4015:02:04, 11 January 2010 (UTC) 3999:02:00, 11 January 2010 (UTC) 3984:01:56, 11 January 2010 (UTC) 3968:01:51, 11 January 2010 (UTC) 3950:02:01, 11 January 2010 (UTC) 3915:01:49, 11 January 2010 (UTC) 3900:01:47, 11 January 2010 (UTC) 3882:01:44, 11 January 2010 (UTC) 3867:01:43, 11 January 2010 (UTC) 3852:01:41, 11 January 2010 (UTC) 3829:01:38, 11 January 2010 (UTC) 3813:01:35, 11 January 2010 (UTC) 3787:01:31, 11 January 2010 (UTC) 3767:03:32, 11 January 2010 (UTC) 3751:03:24, 11 January 2010 (UTC) 3693:00:22, 11 January 2010 (UTC) 3671:00:11, 11 January 2010 (UTC) 3657:00:02, 11 January 2010 (UTC) 3640:23:38, 10 January 2010 (UTC) 3623:22:31, 10 January 2010 (UTC) 3564:22:44, 10 January 2010 (UTC) 3526:22:30, 10 January 2010 (UTC) 3488:22:05, 10 January 2010 (UTC) 3466:21:47, 10 January 2010 (UTC) 3449:21:04, 10 January 2010 (UTC) 3402:20:46, 10 January 2010 (UTC) 3374:20:06, 10 January 2010 (UTC) 3344:19:02, 10 January 2010 (UTC) 3309:18:51, 10 January 2010 (UTC) 3289:18:25, 10 January 2010 (UTC) 3263:13:26, 12 January 2010 (UTC) 3249:21:05, 10 January 2010 (UTC) 3229:21:06, 5 February 2010 (UTC) 3211:07:49, 4 February 2010 (UTC) 3194:20:18, 21 January 2010 (UTC) 3179:17:34, 21 January 2010 (UTC) 3146:04:10, 21 January 2010 (UTC) 3114:14:43, 17 January 2010 (UTC) 3097:13:58, 17 January 2010 (UTC) 3082:19:03, 16 January 2010 (UTC) 3067:09:33, 16 January 2010 (UTC) 3052:14:41, 15 January 2010 (UTC) 3040:12:39, 14 January 2010 (UTC) 3019:16:07, 13 January 2010 (UTC) 2999:00:19, 13 January 2010 (UTC) 2982:18:13, 12 January 2010 (UTC) 2963:13:18, 12 January 2010 (UTC) 2942:11:23, 12 January 2010 (UTC) 2916:12:17, 12 January 2010 (UTC) 2895:09:31, 12 January 2010 (UTC) 2873:02:04, 14 January 2010 (UTC) 2855:17:01, 12 January 2010 (UTC) 2829:12:44, 12 January 2010 (UTC) 2811:12:15, 12 January 2010 (UTC) 2790:03:14, 12 January 2010 (UTC) 2769:14:35, 12 January 2010 (UTC) 2756:23:39, 11 January 2010 (UTC) 2742:23:35, 11 January 2010 (UTC) 2727:23:34, 11 January 2010 (UTC) 2712:23:35, 11 January 2010 (UTC) 2698:23:30, 11 January 2010 (UTC) 2684:21:41, 11 January 2010 (UTC) 2658:23:27, 11 January 2010 (UTC) 2639:23:19, 11 January 2010 (UTC) 2624:23:13, 11 January 2010 (UTC) 2609:22:07, 11 January 2010 (UTC) 2588:21:38, 11 January 2010 (UTC) 2569:20:32, 11 January 2010 (UTC) 2543:14:33, 12 January 2010 (UTC) 2527:22:51, 11 January 2010 (UTC) 2512:20:21, 11 January 2010 (UTC) 2489:19:21, 11 January 2010 (UTC) 2470:17:57, 11 January 2010 (UTC) 2449:01:03, 12 January 2010 (UTC) 2426:00:39, 12 January 2010 (UTC) 2407:17:55, 11 January 2010 (UTC) 2379:17:53, 11 January 2010 (UTC) 2365:17:50, 11 January 2010 (UTC) 2341:17:41, 11 January 2010 (UTC) 2315:15:22, 11 January 2010 (UTC) 2291:14:28, 11 January 2010 (UTC) 2275:11:50, 11 January 2010 (UTC) 2266:10:23, 11 January 2010 (UTC) 2225:02:41, 11 January 2010 (UTC) 2198:02:17, 11 January 2010 (UTC) 2175:02:06, 11 January 2010 (UTC) 2160:01:54, 11 January 2010 (UTC) 2137:01:46, 11 January 2010 (UTC) 2123:01:43, 11 January 2010 (UTC) 2106:01:41, 11 January 2010 (UTC) 2092:01:33, 11 January 2010 (UTC) 2055:01:26, 11 January 2010 (UTC) 2041:21:44, 10 January 2010 (UTC) 2027:20:18, 10 January 2010 (UTC) 1981:01:49, 11 January 2010 (UTC) 1961:01:48, 11 January 2010 (UTC) 1947:01:45, 11 January 2010 (UTC) 1917:01:41, 11 January 2010 (UTC) 1898:01:33, 11 January 2010 (UTC) 1877:01:26, 11 January 2010 (UTC) 1862:00:35, 11 January 2010 (UTC) 1844:01:26, 11 January 2010 (UTC) 1809:00:27, 11 January 2010 (UTC) 1799:00:20, 11 January 2010 (UTC) 1770:00:12, 11 January 2010 (UTC) 1761:22:12, 10 January 2010 (UTC) 1751:21:15, 10 January 2010 (UTC) 1727:21:11, 10 January 2010 (UTC) 1713:21:05, 10 January 2010 (UTC) 1697:19:04, 10 January 2010 (UTC) 1682:15:10, 12 January 2010 (UTC) 1666:16:26, 10 January 2010 (UTC) 1640:16:20, 10 January 2010 (UTC) 1626:16:18, 10 January 2010 (UTC) 1574:02:23, 9 February 2010 (UTC) 1557:21:21, 8 February 2010 (UTC) 1534:02:32, 28 January 2010 (UTC) 1518:18:44, 25 January 2010 (UTC) 1501:18:31, 18 January 2010 (UTC) 1480:07:58, 16 January 2010 (UTC) 1452:20:05, 15 January 2010 (UTC) 1435:09:32, 14 January 2010 (UTC) 1416:04:53, 14 January 2010 (UTC) 1388:02:32, 14 January 2010 (UTC) 1365:01:29, 13 January 2010 (UTC) 1348:16:56, 12 January 2010 (UTC) 1336:15:23, 12 January 2010 (UTC) 1318:09:03, 12 January 2010 (UTC) 1302:00:58, 12 January 2010 (UTC) 1292:States Rights for Software! 1285:00:14, 12 January 2010 (UTC) 1268:00:06, 12 January 2010 (UTC) 1251:23:49, 11 January 2010 (UTC) 1233:20:36, 11 January 2010 (UTC) 1220:20:28, 11 January 2010 (UTC) 1187:19:38, 11 January 2010 (UTC) 1163:19:03, 11 January 2010 (UTC) 1140:20:35, 11 January 2010 (UTC) 1107:15:41, 11 January 2010 (UTC) 1083:15:16, 11 January 2010 (UTC) 1065:14:39, 11 January 2010 (UTC) 1041:11:22, 11 January 2010 (UTC) 1023:08:56, 11 January 2010 (UTC) 1010:08:36, 11 January 2010 (UTC) 997:08:01, 11 January 2010 (UTC) 980:05:05, 11 January 2010 (UTC) 964:02:54, 11 January 2010 (UTC) 942:01:20, 11 January 2010 (UTC) 919:01:19, 11 January 2010 (UTC) 899:Keep it local. I said it at 895:00:42, 11 January 2010 (UTC) 878:00:26, 11 January 2010 (UTC) 862:00:21, 11 January 2010 (UTC) 848:23:56, 10 January 2010 (UTC) 839:23:39, 10 January 2010 (UTC) 822:22:35, 10 January 2010 (UTC) 808:22:30, 10 January 2010 (UTC) 764:22:26, 10 January 2010 (UTC) 744:22:20, 10 January 2010 (UTC) 732:20:07, 10 January 2010 (UTC) 710:19:31, 10 January 2010 (UTC) 689:19:18, 10 January 2010 (UTC) 665:18:42, 10 January 2010 (UTC) 651:18:41, 10 January 2010 (UTC) 613:18:25, 10 January 2010 (UTC) 594:18:23, 10 January 2010 (UTC) 584:18:06, 10 January 2010 (UTC) 575:17:47, 10 January 2010 (UTC) 559:18:23, 11 January 2010 (UTC) 538:17:27, 10 January 2010 (UTC) 516:16:46, 10 January 2010 (UTC) 505:16:44, 10 January 2010 (UTC) 488:16:28, 10 January 2010 (UTC) 476:16:27, 10 January 2010 (UTC) 454:16:26, 10 January 2010 (UTC) 421:16:21, 10 January 2010 (UTC) 398:16:19, 10 January 2010 (UTC) 385:16:05, 10 January 2010 (UTC) 370:15:41, 10 January 2010 (UTC) 352:15:29, 10 January 2010 (UTC) 326:13:43, 11 January 2010 (UTC) 294:15:42, 10 January 2010 (UTC) 263:15:28, 10 January 2010 (UTC) 249:15:19, 10 January 2010 (UTC) 211:15:10, 10 January 2010 (UTC) 153:08:34, 10 January 2010 (UTC) 4700:It should run for 30 days. 1735:we do desysops, but rather 4947: 4755:Some procedural questions 4646:Another thing to consider 4475:I plumb forgot about it, 4424:Bureaucrat unchecking RFC 4410:Some procedural questions 1923:You don't happen to know 129:WT:RFA#Unchecking the box 4912:Please do not modify it. 4466:was notified immediately 2073:the decision is made by 1027:Yes, it would be ideal. 168:This page in a nutshell: 127:Per the discussion here 41:Please do not modify it. 4431:the previous discussion 3679:causes a desysop, only 480:This is a no-brainer. 4380:beginning. It is just 3087:like a ban proposal. 2499:the previous proposal 1423:. We do need to have 22:Bureaucrat Unchecking 3281:A Stop at Willoughby 3217:Separation of powers 605:A Stop at Willoughby 1967:Responded below at 1601:uprising! uprising! 1194:Von Neumann machine 459:basis. Regards, --— 102:original discussion 4625: 4283:Hustle (TV series) 4081: 3464: 2961: 2763:Christopher Parham 2721:Christopher Parham 1739:we preform them. – 1677: 1635: 1621: 619:possible scenarios 222:it is desired. -- 187:for that process). 4618: 4098: 4074: 3562: 3523: 3486: 3457: 3400: 3341: 3176: 3144: 3035: 2954: 2827: 2788: 2424: 2313: 1675: 1664: 1633: 1619: 1603: 1581:. They ought to. 1328:Elen of the Roads 1142: 1105: 962: 957: 687: 648: 503: 474: 452: 431: 368: 191: 190: 4938: 4914: 4875: 4867: 4861: 4834: 4826: 4800: 4792: 4765: 4729: 4721: 4708: 4692: 4684: 4656: 4530: 4454: 4398: 4377:User:Hammersofts 4367: 4359: 4310: 4302: 4256: 4231: 4228: 4152: 4144: 4092: 4066: 4063: 3948: 3945: 3731:m:Steward Policy 3720: 3708: 3636: 3561: 3559: 3548: 3524: 3519: 3513: 3507: 3501: 3499: 3485: 3483: 3472: 3445: 3399: 3397: 3386: 3342: 3337: 3331: 3325: 3319: 3317: 3305: 3300: 3245: 3161: 3141: 3135: 3124: 3034: 3031: 3030: 2979: 2913: 2905: 2852: 2844: 2817: 2808: 2800: 2778: 2695: 2682: 2680: 2674: 2669: 2540: 2509: 2466: 2447: 2444: 2417: 2413: 2405: 2402: 2339: 2336: 2311:Talk to Nihonjoe 2307: 2303: 2300: 2284: 2264: 2261: 2255: 2250: 2232:—those who were 2196: 2193: 2158: 2155: 1932: 1842: 1839: 1744: 1706: 1690:nor should it be 1657: 1651: 1646: 1599: 1597: 1591:Don't be too CNN 1586: 1554: 1549: 1547: 1497: 1492: 1476: 1471: 1466: 1411: 1406: 1401: 1384: 1313: 1248: 1242: 1215: 1184: 1160: 1154: 1129: 1118:technical change 1101: 1098: 1095: 1038: 1033: 977: 958: 953: 940: 937: 915: 909: 866:Seems sensible. 806: 803: 800: 797: 794: 791: 785: 782: 779: 776: 754: 685:Talk to Nihonjoe 681: 677: 674: 649: 644: 638: 632: 626: 624: 556: 552: 547: 535: 531: 526: 493: 473: 471: 460: 445: 439: 434: 425: 417: 412: 394: 362: 349: 342: 322: 316: 308: 305: 290: 284: 276: 273: 245: 239: 231: 228: 204: 164: 163: 157: 116: 110: 90: 84: 65: 59: 43: 4946: 4945: 4941: 4940: 4939: 4937: 4936: 4935: 4921: 4920: 4919: 4910: 4871: 4863: 4859: 4830: 4822: 4796: 4788: 4763: 4725: 4717: 4706: 4688: 4680: 4676: 4654: 4648: 4560: 4528: 4452: 4412: 4396: 4363: 4355: 4306: 4298: 4226: 4219: 4148: 4140: 4061: 4054: 3943: 3936: 3775: 3718: 3702: 3634: 3557: 3549: 3517: 3511: 3505: 3500: 3497: 3481: 3473: 3443: 3395: 3387: 3335: 3329: 3323: 3318: 3315: 3303: 3298: 3271: 3243: 3237: 3139: 3133: 3129: 3032: 3028: 2977: 2909: 2901: 2848: 2840: 2804: 2796: 2693: 2679:majestic titan) 2678: 2672: 2667: 2665: 2538: 2507: 2464: 2442: 2435: 2415: 2400: 2393: 2334: 2327: 2305: 2298: 2282: 2259: 2253: 2248: 2245: 2191: 2184: 2153: 2146: 1837: 1830: 1742: 1704: 1655: 1649: 1613: 1595: 1584: 1552: 1545: 1543: 1495: 1490: 1474: 1469: 1464: 1409: 1404: 1399: 1382: 1311: 1246: 1240: 1213: 1172: 1158: 1152: 1099: 1093: 1036: 1029: 973: 935: 928: 913: 905: 804: 801: 798: 795: 792: 789: 783: 780: 777: 774: 772: 752: 679: 672: 642: 636: 630: 625: 622: 554: 550: 545: 533: 529: 524: 469: 461: 443: 437: 415: 410: 392: 345: 338: 320: 314: 306: 303: 288: 282: 274: 271: 243: 237: 229: 226: 202: 196: 161: 108: 105: 82: 79: 57: 54: 39: 33: 26: 25: 24: 12: 11: 5: 4944: 4942: 4934: 4933: 4923: 4922: 4918: 4917: 4906: 4905: 4904: 4903: 4902: 4901: 4900: 4899: 4898: 4897: 4896: 4895: 4894: 4805: 4784: 4736: 4735: 4734: 4675: 4672: 4670: 4647: 4644: 4643: 4642: 4629: 4612: 4594: 4559: 4553: 4552: 4551: 4537: 4536: 4535: 4505: 4504: 4503: 4500: 4480: 4473: 4469: 4445: 4444: 4441: 4434: 4427: 4420: 4411: 4408: 4406: 4373: 4372: 4346: 4345: 4344: 4274: 4273: 4272: 4271: 4270: 4269: 4208: 4207: 4206: 4128: 4127: 4090: 4089: 4088: 4087: 4086: 4085: 4018: 4017: 3987: 3986: 3955: 3954: 3953: 3952: 3887: 3886: 3885: 3884: 3869: 3816: 3815: 3800: 3799: 3796: 3793: 3774: 3771: 3770: 3769: 3700: 3699: 3698: 3697: 3696: 3695: 3644: 3643: 3642: 3629: 3611: 3610: 3609: 3606: 3603: 3599: 3596: 3592: 3589: 3574: 3573: 3572: 3571: 3570: 3569: 3568: 3567: 3566: 3535: 3534: 3533: 3532: 3531: 3530: 3529: 3528: 3468: 3438: 3437: 3436: 3433: 3430: 3426: 3422: 3418: 3415: 3408: 3407: 3404: 3349: 3348: 3347: 3346: 3292: 3291: 3270: 3267: 3266: 3265: 3251: 3236: 3233: 3232: 3231: 3213: 3198: 3197: 3196: 3172: 3167: 3159: 3148: 3127: 3118: 3117: 3116: 3101: 3100: 3099: 3054: 3042: 3021: 3001: 2984: 2965: 2944: 2920: 2919: 2918: 2883: 2882: 2881: 2880: 2879: 2878: 2877: 2876: 2875: 2775: 2774: 2773: 2772: 2771: 2758: 2716: 2715: 2714: 2686: 2662: 2661: 2660: 2645: 2644: 2643: 2642: 2641: 2571: 2549: 2548: 2547: 2546: 2545: 2491: 2474: 2473: 2472: 2455: 2454: 2453: 2452: 2451: 2381: 2345: 2344: 2343: 2317: 2293: 2277: 2227: 2210: 2209: 2208: 2207: 2206: 2205: 2204: 2203: 2202: 2201: 2200: 2110: 2109: 2108: 2059: 2058: 2057: 1989: 1988: 1987: 1986: 1985: 1984: 1983: 1965: 1964: 1963: 1921: 1920: 1919: 1881: 1880: 1879: 1850: 1849: 1848: 1847: 1846: 1774: 1773: 1772: 1763: 1686: 1685: 1684: 1670: 1669: 1668: 1612: 1609: 1608: 1607: 1596:I'LL DO MY JOB 1579:Strong support 1576: 1559: 1536: 1526:Christian List 1520: 1510:Semitransgenic 1503: 1482: 1454: 1440:Strong support 1437: 1421:String support 1418: 1390: 1367: 1350: 1338: 1320: 1304: 1287: 1277:Bradjamesbrown 1270: 1253: 1235: 1222: 1189: 1165: 1145: 1144: 1143: 1085: 1067: 1043: 1025: 1012: 999: 982: 966: 944: 921: 897: 880: 864: 850: 841: 824: 810: 788: 766: 746: 734: 712: 694:Strong Support 691: 667: 653: 615: 596: 586: 577: 563: 562: 561: 518: 507: 490: 478: 456: 423: 400: 387: 372: 354: 334: 333: 332: 331: 330: 329: 328: 213: 195: 192: 189: 188: 165: 126: 124: 123: 122: 121: 120: 72: 71: 70: 69: 34: 32: 29: 27: 15: 14: 13: 10: 9: 6: 4: 3: 2: 4943: 4932: 4929: 4928: 4926: 4916: 4913: 4907: 4893: 4890: 4888: 4887: 4881: 4880: 4879: 4876: 4874: 4868: 4866: 4857: 4856: 4855: 4852: 4850: 4849: 4844: 4840: 4839: 4838: 4835: 4833: 4827: 4825: 4819: 4818: 4817: 4814: 4812: 4811: 4806: 4804: 4801: 4799: 4793: 4791: 4785: 4783: 4779: 4775: 4771: 4770: 4769: 4766: 4760: 4756: 4752: 4751: 4750: 4746: 4742: 4737: 4733: 4730: 4728: 4722: 4720: 4714: 4713: 4712: 4709: 4703: 4699: 4698: 4697: 4696: 4693: 4691: 4685: 4683: 4673: 4671: 4668: 4667: 4664: 4663: 4662: 4658: 4657: 4645: 4641: 4638: 4634: 4630: 4628: 4624: 4621: 4616: 4610: 4606: 4602: 4599: 4595: 4593: 4589: 4585: 4580: 4579: 4578: 4577: 4573: 4569: 4565: 4557: 4554: 4550: 4546: 4542: 4538: 4534: 4531: 4525: 4521: 4520: 4519: 4515: 4511: 4506: 4501: 4497: 4496:WP:VP(policy) 4493: 4489: 4485: 4481: 4478: 4474: 4470: 4467: 4463: 4462: 4461: 4460: 4459: 4458: 4455: 4449: 4442: 4439: 4435: 4432: 4428: 4425: 4421: 4418: 4414: 4413: 4409: 4407: 4404: 4403: 4400: 4399: 4392: 4388: 4383: 4378: 4375:To return to 4371: 4368: 4366: 4360: 4358: 4352: 4347: 4343: 4339: 4335: 4331: 4330: 4329: 4325: 4321: 4317: 4316: 4315: 4314: 4311: 4309: 4303: 4301: 4295: 4291: 4288: 4284: 4280: 4268: 4264: 4260: 4255: 4250: 4249: 4248: 4244: 4240: 4236: 4235: 4234: 4229: 4223: 4218: 4213: 4209: 4205: 4201: 4197: 4193: 4192: 4191: 4187: 4183: 4179: 4175: 4174: 4173: 4172: 4168: 4164: 4157: 4156: 4153: 4151: 4145: 4143: 4137: 4133: 4126: 4123: 4118: 4117: 4116: 4115: 4111: 4107: 4103: 4096: 4095:edit conflict 4084: 4080: 4077: 4071: 4070: 4069: 4064: 4058: 4053: 4048: 4047: 4046: 4042: 4038: 4034: 4033: 4032: 4031: 4027: 4023: 4016: 4012: 4008: 4003: 4002: 4001: 4000: 3996: 3992: 3985: 3981: 3977: 3972: 3971: 3970: 3969: 3965: 3961: 3951: 3946: 3940: 3935: 3930: 3926: 3922: 3918: 3917: 3916: 3912: 3908: 3904: 3903: 3902: 3901: 3897: 3893: 3883: 3879: 3875: 3870: 3868: 3864: 3860: 3855: 3854: 3853: 3849: 3845: 3841: 3837: 3833: 3832: 3831: 3830: 3826: 3822: 3814: 3810: 3806: 3802: 3801: 3797: 3794: 3791: 3790: 3789: 3788: 3784: 3780: 3772: 3768: 3764: 3760: 3755: 3754: 3753: 3752: 3748: 3747: 3742: 3741: 3734: 3732: 3728: 3722: 3714: 3710: 3706: 3694: 3690: 3686: 3682: 3678: 3674: 3673: 3672: 3669: 3665: 3660: 3659: 3658: 3654: 3650: 3645: 3641: 3638: 3637: 3630: 3626: 3625: 3624: 3620: 3616: 3612: 3607: 3604: 3600: 3597: 3593: 3590: 3587: 3582: 3578: 3577: 3575: 3565: 3560: 3554: 3553: 3545: 3544: 3543: 3542: 3541: 3540: 3539: 3538: 3537: 3536: 3527: 3522: 3520: 3514: 3508: 3495: 3491: 3490: 3489: 3484: 3478: 3477: 3469: 3467: 3463: 3460: 3454: 3453: 3452: 3451: 3450: 3447: 3446: 3439: 3434: 3431: 3427: 3423: 3419: 3416: 3412: 3411: 3410: 3409: 3405: 3403: 3398: 3392: 3391: 3383: 3379: 3378: 3377: 3375: 3371: 3367: 3363: 3359: 3355: 3345: 3340: 3338: 3332: 3326: 3312: 3311: 3310: 3307: 3306: 3301: 3294: 3293: 3290: 3286: 3282: 3277: 3273: 3272: 3268: 3264: 3260: 3256: 3252: 3250: 3247: 3246: 3239: 3238: 3234: 3230: 3226: 3222: 3218: 3214: 3212: 3208: 3204: 3199: 3195: 3191: 3187: 3183: 3182: 3181: 3180: 3175: 3173: 3170: 3168: 3166: 3163: 3160: 3158: 3155: 3152: 3149: 3147: 3142: 3136: 3130: 3122: 3119: 3115: 3111: 3107: 3102: 3098: 3094: 3090: 3085: 3084: 3083: 3079: 3075: 3070: 3069: 3068: 3064: 3060: 3055: 3053: 3050: 3046: 3043: 3041: 3038: 3036: 3025: 3022: 3020: 3017: 3013: 3009: 3005: 3002: 3000: 2996: 2992: 2988: 2985: 2983: 2980: 2973: 2969: 2966: 2964: 2960: 2957: 2952: 2948: 2945: 2943: 2940: 2936: 2932: 2928: 2924: 2921: 2917: 2914: 2912: 2906: 2904: 2898: 2897: 2896: 2892: 2888: 2884: 2874: 2871: 2867: 2863: 2858: 2857: 2856: 2853: 2851: 2845: 2843: 2836: 2832: 2831: 2830: 2825: 2821: 2814: 2813: 2812: 2809: 2807: 2801: 2799: 2793: 2792: 2791: 2786: 2782: 2776: 2770: 2767: 2764: 2759: 2757: 2753: 2749: 2745: 2744: 2743: 2739: 2735: 2730: 2729: 2728: 2725: 2722: 2717: 2713: 2709: 2705: 2701: 2700: 2699: 2696: 2690: 2687: 2685: 2681: 2675: 2670: 2663: 2659: 2655: 2651: 2646: 2640: 2636: 2632: 2627: 2626: 2625: 2621: 2617: 2612: 2611: 2610: 2606: 2602: 2598: 2594: 2591: 2590: 2589: 2585: 2581: 2577: 2572: 2570: 2566: 2562: 2557: 2553: 2550: 2544: 2541: 2535: 2530: 2529: 2528: 2524: 2520: 2515: 2514: 2513: 2510: 2504: 2500: 2495: 2492: 2490: 2486: 2482: 2478: 2475: 2471: 2468: 2467: 2460: 2456: 2450: 2445: 2439: 2434: 2429: 2428: 2427: 2422: 2418: 2410: 2409: 2408: 2403: 2397: 2392: 2387: 2382: 2380: 2376: 2372: 2368: 2367: 2366: 2362: 2358: 2353: 2349: 2346: 2342: 2337: 2331: 2326: 2322: 2318: 2316: 2312: 2308: 2301: 2294: 2292: 2289: 2286: 2285: 2278: 2276: 2273: 2269: 2268: 2267: 2262: 2256: 2251: 2243: 2242:remove admins 2239: 2235: 2231: 2228: 2226: 2222: 2218: 2214: 2211: 2199: 2194: 2188: 2183: 2178: 2177: 2176: 2172: 2168: 2163: 2162: 2161: 2156: 2150: 2145: 2140: 2139: 2138: 2134: 2130: 2126: 2125: 2124: 2120: 2116: 2111: 2107: 2103: 2099: 2095: 2094: 2093: 2089: 2085: 2080: 2076: 2072: 2068: 2064: 2060: 2056: 2052: 2048: 2044: 2043: 2042: 2038: 2034: 2030: 2029: 2028: 2024: 2020: 2016: 2012: 2008: 2004: 2000: 1997: 1993: 1990: 1982: 1978: 1974: 1970: 1966: 1962: 1958: 1954: 1950: 1949: 1948: 1944: 1940: 1936: 1931: 1926: 1925:User:JayHenry 1922: 1918: 1914: 1910: 1906: 1901: 1900: 1899: 1895: 1891: 1886: 1882: 1878: 1874: 1870: 1865: 1864: 1863: 1859: 1855: 1851: 1845: 1840: 1834: 1829: 1825: 1820: 1816: 1812: 1811: 1810: 1807: 1802: 1801: 1800: 1796: 1792: 1788: 1783: 1779: 1775: 1771: 1768: 1764: 1762: 1759: 1754: 1753: 1752: 1749: 1746: 1745: 1738: 1734: 1730: 1729: 1728: 1724: 1720: 1716: 1715: 1714: 1711: 1708: 1707: 1700: 1699: 1698: 1695: 1691: 1687: 1683: 1680: 1678: 1671: 1667: 1662: 1658: 1652: 1643: 1642: 1641: 1638: 1636: 1629: 1628: 1627: 1624: 1622: 1615: 1614: 1610: 1606: 1602: 1598: 1593: 1592: 1588: 1587: 1580: 1577: 1575: 1571: 1567: 1563: 1560: 1558: 1555: 1550: 1548: 1540: 1537: 1535: 1531: 1527: 1524: 1521: 1519: 1515: 1511: 1507: 1504: 1502: 1499: 1498: 1493: 1486: 1483: 1481: 1477: 1472: 1467: 1462: 1458: 1455: 1453: 1449: 1445: 1441: 1438: 1436: 1433: 1430: 1426: 1422: 1419: 1417: 1414: 1413: 1412: 1407: 1402: 1394: 1391: 1389: 1386: 1385: 1378: 1377: 1371: 1368: 1366: 1362: 1358: 1354: 1351: 1349: 1346: 1342: 1339: 1337: 1333: 1329: 1324: 1321: 1319: 1316: 1314: 1308: 1305: 1303: 1300: 1299: 1295: 1291: 1288: 1286: 1282: 1278: 1274: 1271: 1269: 1265: 1261: 1257: 1254: 1252: 1249: 1244: 1243: 1236: 1234: 1231: 1226: 1223: 1221: 1218: 1216: 1209: 1208: 1203: 1199: 1195: 1190: 1188: 1185: 1183: 1179: 1175: 1169: 1166: 1164: 1161: 1155: 1149: 1146: 1141: 1138: 1136: 1135: 1127: 1125: 1124: 1119: 1115: 1114: 1110: 1109: 1108: 1104: 1097: 1089: 1086: 1084: 1080: 1076: 1072: 1068: 1066: 1063: 1062: 1058: 1057: 1052: 1048: 1044: 1042: 1039: 1034: 1032: 1026: 1024: 1021: 1017: 1013: 1011: 1008: 1005: 1004: 1000: 998: 994: 990: 986: 983: 981: 978: 976: 970: 967: 965: 961: 956: 952: 948: 945: 943: 938: 932: 927: 922: 920: 917: 916: 910: 908: 902: 898: 896: 892: 888: 884: 881: 879: 875: 871: 870: 865: 863: 859: 855: 851: 849: 846: 842: 840: 836: 832: 831:Sam Blacketer 828: 825: 823: 819: 815: 811: 809: 805: 786: 770: 767: 765: 762: 761: 760: 756: 755: 747: 745: 742: 738: 735: 733: 729: 725: 721: 717: 713: 711: 707: 703: 699: 695: 692: 690: 686: 682: 675: 668: 666: 662: 658: 654: 652: 647: 645: 639: 633: 620: 616: 614: 610: 606: 602: 597: 595: 592: 587: 585: 582: 578: 576: 572: 568: 564: 560: 557: 553: 548: 541: 540: 539: 536: 532: 527: 519: 517: 514: 513: 508: 506: 501: 497: 491: 489: 486: 483: 479: 477: 472: 466: 465: 457: 455: 450: 446: 440: 429: 428:edit conflict 424: 422: 419: 418: 413: 405: 401: 399: 396: 395: 388: 386: 382: 378: 373: 371: 366: 361: 360: 355: 353: 350: 348: 343: 341: 336:Yep. Per JC. 335: 327: 323: 317: 311: 310: 309: 297: 296: 295: 291: 285: 279: 278: 277: 266: 265: 264: 260: 256: 252: 251: 250: 246: 240: 234: 233: 232: 221: 217: 214: 212: 209: 206: 205: 198: 197: 193: 186: 182: 178: 174: 169: 166: 159: 158: 155: 154: 150: 146: 142: 138: 134: 130: 119: 115: 112: 111: 103: 99: 95: 94: 93: 89: 86: 85: 78: 74: 73: 68: 64: 61: 60: 53: 50: 49: 48: 45: 42: 36: 35: 30: 23: 19: 4911: 4908: 4885: 4872: 4864: 4847: 4831: 4823: 4809: 4797: 4789: 4754: 4726: 4718: 4689: 4681: 4677: 4669: 4661: 4659: 4652: 4649: 4632: 4597: 4561: 4476: 4446: 4438:WP:CANVASSed 4423: 4417:Village Pump 4405: 4394: 4390: 4381: 4374: 4364: 4356: 4350: 4307: 4299: 4293: 4275: 4211: 4176:To be fair, 4158: 4149: 4141: 4132:User:Example 4129: 4101: 4091: 4019: 3988: 3956: 3928: 3924: 3920: 3888: 3839: 3835: 3817: 3776: 3745: 3739: 3735: 3726: 3723: 3715: 3711: 3701: 3680: 3676: 3663: 3632: 3585: 3580: 3551: 3502: 3493: 3475: 3441: 3389: 3361: 3357: 3353: 3350: 3320: 3296: 3275: 3241: 3177: 3174: 3164: 3156: 3150: 3120: 3044: 3023: 3003: 2986: 2971: 2967: 2951:a bureaucrat 2950: 2946: 2934: 2930: 2926: 2922: 2910: 2902: 2849: 2841: 2834: 2805: 2797: 2688: 2596: 2593:Au contraire 2592: 2575: 2555: 2551: 2493: 2476: 2462: 2385: 2351: 2347: 2283:Juliancolton 2280: 2241: 2237: 2229: 2212: 2078: 2074: 2070: 2066: 2062: 2014: 2010: 2006: 2002: 1995: 1991: 1904: 1818: 1814: 1786: 1781: 1777: 1743:Juliancolton 1740: 1736: 1732: 1705:Juliancolton 1702: 1589: 1582: 1578: 1561: 1542: 1538: 1522: 1505: 1488: 1484: 1456: 1439: 1424: 1420: 1400:bibliomaniac 1397: 1396: 1392: 1381: 1375: 1369: 1352: 1340: 1322: 1306: 1296: 1289: 1272: 1255: 1238: 1210: 1206: 1181: 1177: 1173: 1167: 1147: 1133: 1122: 1112: 1111: 1087: 1070: 1060: 1055: 1050: 1046: 1030: 1001: 984: 974: 968: 946: 911: 906: 882: 867: 826: 768: 759: 757: 750: 736: 719: 715: 697: 693: 627: 543: 522: 510: 463: 408: 403: 390: 357: 346: 339: 301: 300: 269: 268: 224: 223: 219: 215: 203:Juliancolton 200: 180: 176: 172: 167: 140: 135:in cases of 132: 125: 106: 80: 75: 55: 51: 46: 40: 37: 4841:Sure - see 4468:by the way. 4351:guarranteed 4122:Chick Bowen 3668:Chick Bowen 2794:Which is? 2748:Killiondude 2576:technically 2416:Luna Santin 2238:make admins 1806:Chick Bowen 1767:Chick Bowen 1758:Chick Bowen 1694:Chick Bowen 1562:Support but 1312:Ohconfucius 1153:Fabrictramp 1096:Christopher 1075:Floquenbeam 1071:in extremis 1051:bureaucrats 1047:bureaucracy 854:Killiondude 581:Josh Parris 340:Pmlineditor 133:potentially 4655:Balloonman 4568:Hammersoft 4397:Jim Miller 4320:Hammersoft 4239:Hammersoft 4196:Hammersoft 4163:Hammersoft 4037:Hammersoft 4007:Hammersoft 3976:Hammersoft 3907:Hammersoft 3874:Hammersoft 3859:Hammersoft 3821:Hammersoft 3779:Hammersoft 3552:Cyclonenim 3476:Cyclonenim 3390:Cyclonenim 3269:Discussion 3134:have a cup 2595:, that is 2167:Hammersoft 2129:Hammersoft 2098:Hammersoft 2047:Hammersoft 2019:Hammersoft 1953:Hammersoft 1909:Hammersoft 1869:Hammersoft 1719:Hammersoft 1432:Od Mishehu 1159:talk to me 753:Balloonman 657:Tryptofish 464:Cyclonenim 393:Jim Miller 4620:WJBscribe 4477:mea culpa 4472:checkbox) 4279:these two 4076:WJBscribe 3746:lifeguard 3662:there is 3459:WJBscribe 3089:Spellcast 3059:Spellcast 2991:Sole Soul 2956:WJBscribe 2927:obviously 2631:MZMcBride 2561:MZMcBride 2357:Guettarda 1566:SmokeyJoe 1429:עוד מישהו 1345:Unionhawk 1260:Everyking 702:Ironholds 591:Acalamari 4925:Category 4136:User:Foo 3429:is wise. 3425:parties. 3203:Rockfang 2249:Treasury 2075:WHATEVER 1927:do you? 1787:decision 1496:Pieterse 1487:Per JC. 1326:another. 1003:Andrevan 951:ConCompS 947:Hell yes 887:Icewedge 814:Vassyana 741:Jusdafax 555:Chequers 534:Chequers 404:separate 377:Robofish 321:contribs 289:contribs 244:contribs 109:SilkTork 83:SilkTork 58:SilkTork 20:‎ | 4674:Closing 3705:steward 3664:already 3635:MBisanz 3494:someone 3444:MBisanz 3255:Dweller 3244:MBisanz 3235:Neutral 3049:Spartaz 2616:Rjd0060 2580:Rjd0060 2481:JoshuaZ 2465:MBisanz 2260:cabinet 2217:Wehwalt 1935:WP:AUSC 1905:another 1539:Support 1523:Support 1506:Support 1485:Support 1461:King of 1457:Support 1393:Support 1370:Support 1353:Support 1341:Support 1323:Support 1307:Support 1290:Support 1273:Support 1256:Support 1241:Majorly 1202:steward 1168:Support 1148:Support 1113:Support 1092:Camaron 1088:Support 989:Jafeluv 985:Support 969:Support 883:Support 827:Support 769:Support 737:Support 567:Dumelow 304:Phantom 272:Phantom 227:Phantom 194:Support 4759:Ruslik 4702:Ruslik 4623:(talk) 4615:WP:CDA 4609:WP:CDA 4605:WP:CDA 4601:WP:CDA 4556:WP:CDA 4524:Ruslik 4488:WT:RFA 4448:Ruslik 4079:(talk) 3929:per se 3840:better 3836:better 3608:Concur 3605:Concur 3595:'crat. 3462:(talk) 3151:Oppose 3128:Coffee 3121:Oppose 3033:le_Jrb 3024:Oppose 3004:Oppose 2987:Oppose 2968:Oppose 2959:(talk) 2947:Oppose 2887:Stifle 2835:create 2766:(talk) 2724:(talk) 2689:Oppose 2552:Oppose 2534:Ruslik 2503:Ruslik 2494:Oppose 2477:oppose 2352:remove 2348:Oppose 2230:Oppose 2213:Oppose 2015:Fourth 2003:Second 1999:WP:CDA 1992:Oppose 1676:Nathan 1634:Nathan 1620:Nathan 1611:Oppose 1585:Kayau 1546:hmwith 1491:Lourie 1425:strict 1376:Valley 1357:Greg L 1230:Ucucha 1225:Ucucha 1037:(talk) 960:review 700:mote. 512:Кузьма 485:(talk) 482:Friday 185:WP:CDA 181:Should 143:)? -- 137:WP:CDA 4873:melon 4865:Happy 4832:melon 4824:Happy 4798:melon 4790:Happy 4727:melon 4719:Happy 4690:melon 4682:Happy 4492:WP:AN 4484:WP:BN 4382:wrong 4365:melon 4357:Happy 4308:melon 4300:Happy 4287:these 4217:EVula 4212:isn't 4180:. -- 4150:melon 4142:Happy 4052:EVula 3934:EVula 3925:local 3581:grant 3558:Chat 3498:Amory 3482:Chat 3396:Chat 3382:rogue 3358:given 3354:which 3316:Amory 3221:Atmoz 2939:Coren 2911:melon 2903:Happy 2850:melon 2842:Happy 2806:melon 2798:Happy 2673:(talk 2433:EVula 2391:EVula 2325:EVula 2182:EVula 2144:EVula 2007:Third 1996:First 1885:WP:BN 1828:EVula 1756:CDA. 1659:) · 1298:harej 1016:Conti 926:EVula 907:Jamie 716:which 623:Amory 601:WP:BN 551:Spiel 530:Spiel 470:Chat 447:) · 365:Help! 307:Steve 275:Steve 230:Steve 16:< 4886:xeno 4848:xeno 4810:xeno 4778:talk 4764:Zero 4745:talk 4707:Zero 4637:Dark 4588:talk 4572:talk 4545:talk 4529:Zero 4514:talk 4453:Zero 4429:Why 4391:That 4387:wiki 4338:talk 4324:talk 4294:That 4263:talk 4243:talk 4222:talk 4200:talk 4186:talk 4167:talk 4110:talk 4057:talk 4041:talk 4026:talk 4011:talk 3995:talk 3980:talk 3964:talk 3939:talk 3911:talk 3896:talk 3878:talk 3863:talk 3848:talk 3825:talk 3809:talk 3783:talk 3763:talk 3740:Mike 3689:talk 3677:what 3653:talk 3619:talk 3370:talk 3285:talk 3276:That 3259:talk 3225:talk 3215:per 3207:talk 3190:talk 3110:talk 3093:talk 3078:talk 3074:Gigs 3063:talk 3045:Nope 2995:talk 2976:Tito 2935:like 2931:ever 2891:talk 2824:talk 2785:talk 2752:talk 2738:talk 2708:talk 2654:talk 2635:talk 2620:talk 2605:talk 2584:talk 2565:talk 2556:more 2539:Zero 2523:talk 2508:Zero 2485:talk 2438:talk 2421:talk 2396:talk 2375:talk 2361:talk 2330:talk 2272:Dark 2221:talk 2187:talk 2171:talk 2149:talk 2133:talk 2119:talk 2102:talk 2088:talk 2079:THEN 2071:ONCE 2051:talk 2037:talk 2023:talk 1977:talk 1957:talk 1943:talk 1913:talk 1894:talk 1873:talk 1858:talk 1833:talk 1815:this 1795:talk 1733:when 1723:talk 1661:@727 1656:talk 1570:talk 1530:talk 1514:talk 1448:talk 1444:Gigs 1383:city 1361:talk 1332:talk 1281:talk 1264:talk 1247:talk 1214:Talk 1134:xeno 1123:xeno 1103:talk 1079:talk 1056:Sher 1031:Tony 993:talk 955:talk 931:talk 891:talk 874:talk 869:Cirt 858:talk 845:Dark 835:talk 818:talk 728:talk 706:talk 661:talk 609:talk 571:talk 546:Ϣere 525:Ϣere 500:talk 496:MSGJ 449:@727 444:talk 430:× 2) 381:talk 315:talk 283:talk 259:talk 238:talk 149:talk 4774:Avi 4741:Avi 4584:Avi 4541:Avi 4510:Avi 4494:or 4334:Avi 4290:two 4259:Avi 4224:// 4220:// 4182:Avi 4106:Avi 4102:you 4059:// 4055:// 4022:Avi 3991:Avi 3960:Avi 3941:// 3937:// 3921:may 3892:Avi 3844:Avi 3805:Avi 3803:-- 3759:Avi 3749:| 3737:— 3685:Avi 3681:who 3649:Avi 3615:Avi 3613:-- 3586:not 3366:Avi 3362:who 3304:Why 3186:Avi 3165:(t/ 3157:NJA 3143:// 3140:ark 3137:// 3131:// 3106:Avi 3008:Lar 2862:Lar 2820:CBM 2781:CBM 2734:Avi 2704:Avi 2650:Avi 2601:Avi 2597:all 2519:Avi 2440:// 2436:// 2398:// 2394:// 2386:far 2371:Avi 2332:// 2328:// 2299:日本穣 2296:··· 2254:Tag 2189:// 2185:// 2151:// 2147:// 2115:Avi 2084:Avi 2033:Avi 2011:one 1973:Avi 1971:-- 1939:Avi 1890:Avi 1854:Avi 1835:// 1831:// 1824:CDA 1819:can 1791:Avi 1737:how 1061:eth 1053::) 933:// 929:// 914:S93 901:CDA 802:iew 799:Rev 796:or 778:e T 724:Avi 720:who 673:日本穣 416:Why 359:Guy 255:Avi 173:not 145:Avi 4927:: 4860::D 4780:) 4747:) 4598:if 4590:) 4574:) 4547:) 4516:) 4490:, 4486:, 4340:) 4326:) 4265:) 4245:) 4230:// 4202:) 4188:) 4169:) 4161:-- 4112:) 4065:// 4043:) 4028:) 4013:) 4005:-- 3997:) 3982:) 3974:-- 3966:) 3947:// 3913:) 3898:) 3880:) 3872:-- 3865:) 3857:-- 3850:) 3827:) 3819:-- 3811:) 3785:) 3765:) 3719::) 3691:) 3655:) 3621:) 3515:• 3509:• 3376:# 3372:) 3333:• 3327:• 3299:So 3287:) 3261:) 3227:) 3209:) 3192:) 3171:c) 3125:— 3112:) 3095:) 3080:) 3065:) 3010:: 2997:) 2978:xd 2923:No 2893:) 2864:: 2822:· 2783:· 2754:) 2740:) 2710:) 2676:• 2668:Ed 2656:) 2637:) 2622:) 2607:) 2586:) 2567:) 2525:) 2487:) 2461:. 2446:// 2404:// 2377:) 2363:) 2338:// 2323:. 2309:· 2306:投稿 2302:· 2287:| 2263:─╢ 2246:╟─ 2223:) 2195:// 2173:) 2165:-- 2157:// 2135:) 2121:) 2104:) 2090:) 2067:IF 2063:IF 2053:) 2039:) 2025:) 1979:) 1959:) 1945:) 1915:) 1896:) 1875:) 1860:) 1841:// 1826:. 1797:) 1778:if 1747:| 1725:) 1709:| 1663:· 1653:· 1650:X! 1572:) 1532:) 1516:) 1478:♠ 1450:) 1363:) 1334:) 1283:) 1266:) 1258:. 1207:NW 1204:. 1156:| 1081:) 1014:-- 995:) 939:// 893:) 876:) 860:) 837:) 820:) 793:it 790:Ed 784:ng 781:hi 775:Th 730:) 708:) 698:de 683:· 680:投稿 676:· 663:) 640:• 634:• 611:) 573:) 498:· 451:· 441:· 438:X! 411:So 383:) 324:\ 292:\ 261:) 247:\ 207:| 177:is 151:) 4883:– 4869:‑ 4845:– 4828:‑ 4794:‑ 4776:( 4761:_ 4743:( 4723:‑ 4704:_ 4686:‑ 4586:( 4570:( 4543:( 4526:_ 4512:( 4499:. 4479:. 4450:_ 4419:? 4361:‑ 4336:( 4322:( 4304:‑ 4261:( 4241:( 4227:☯ 4198:( 4184:( 4165:( 4146:‑ 4108:( 4097:) 4093:( 4062:☯ 4039:( 4024:( 4009:( 3993:( 3978:( 3962:( 3944:☯ 3909:( 3894:( 3876:( 3861:( 3846:( 3823:( 3807:( 3781:( 3761:( 3743:. 3707:. 3687:( 3651:( 3617:( 3555:| 3521:) 3518:c 3512:t 3506:u 3503:( 3479:| 3393:| 3368:( 3339:) 3336:c 3330:t 3324:u 3321:( 3283:( 3257:( 3223:( 3205:( 3188:( 3108:( 3091:( 3076:( 3061:( 3029:A 3016:c 3014:/ 3012:t 2993:( 2907:‑ 2889:( 2870:c 2868:/ 2866:t 2846:‑ 2826:) 2818:( 2802:‑ 2787:) 2779:( 2750:( 2736:( 2706:( 2694:Q 2652:( 2633:( 2618:( 2603:( 2582:( 2563:( 2536:_ 2521:( 2505:_ 2483:( 2443:☯ 2423:) 2419:( 2401:☯ 2373:( 2359:( 2335:☯ 2257:► 2219:( 2192:☯ 2169:( 2154:☯ 2131:( 2117:( 2100:( 2086:( 2049:( 2035:( 2021:( 1975:( 1955:( 1941:( 1911:( 1892:( 1871:( 1856:( 1838:☯ 1793:( 1721:( 1647:( 1568:( 1553:☮ 1528:( 1512:( 1475:♣ 1470:♦ 1465:♥ 1446:( 1410:5 1405:1 1379:2 1359:( 1330:( 1294:@ 1279:( 1262:( 1217:) 1211:( 1182:a 1180:c 1178:z 1176:a 1174:m 1131:– 1100:· 1094:· 1077:( 1020:✉ 1018:| 1007:@ 991:( 936:☯ 889:( 872:( 856:( 833:( 816:( 726:( 704:( 659:( 646:) 643:c 637:t 631:u 628:( 607:( 569:( 502:) 494:( 467:| 435:( 426:( 379:( 367:) 363:( 347:∞ 318:| 312:/ 286:| 280:/ 257:( 241:| 235:/ 147:( 139:( 113:* 87:* 62:*

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.

Knowledge

:Requests for adminship/Bureaucrat Unchecking/Poll - Knowledge

Index