Knowledge

talk:Requests for removal of adminship - Knowledge

Source 📝

1879:
minority to remove the tools doesn't make sense, because as in most social structures, on Knowledge the preference is generally not to change the current order, thus a large majority is required to grant adminship, and a large majority would be required to take it away. Granted, that isn't how XfD works or how other community-based decisions are made, but recall that Knowledge is not about democracy, it's about consensus, and the percentages don't really matter that much. Anyway, according to my reading of the proposal, the result would be determined by a Bureaucrat, and judging consensus would be entirely at their discretion. Then, to top it all off, the final decision is made by Arbcom. Even with all the safeguards, there's some concern that the requirement of only a simple majority would lead to greater risk of lynch mobbing, which is why a supermajority has been suggested.
862:
I'm assuming a recall would demand just as much time as a contentious RFA, but in this proposal the timing is not under the control of the subject. Arbcom has a similar issue, but they build in more time and have been known to delay things. You could mitigate this by having the timing decided by the three admins, but they would be unsuitable as they are presumably amongst those clamouring for a desysop. Alternatively you could have a system whereby the admin in question could say "now is not a good time for me to start a 7 day process like this, but I'll start this off within x weeks at the first time that suits me". Though somehow I doubt that a group of people sufficiently riled up to call for a desysop would be impressed at such a statement however it was phrased and however much personal detail the admin was inappropriately pressurised into revealing.
1170:
applied to XFD among other things. Either we embrace community-wide discussion, or we don't. I don't believe you're suggesting this, but I have seen others suggest that we elect arbcom to do the community's "dirty work". I just don't like that idea. If anything, I think the project is suffering because the community is becoming less and less involved in such processes. Accountability for one's actions is really starting to look like it's buried under paperwork "over there" somewhere, and if one is a decent wiki-lawyer, they can pretty much do whatever, carte blanche, for some time. The negative peer pressure (by that editor's "friends") for starting action against an editor can easily dissuade someone from initiating such proceedings, as "not worth the effort". And so, this is a very real hindrance to
598:
5 years, at which time an admin would have to stand for "re-election". My feeling is that such a limitation would take the pressure off of the desire to de-admin someone, since they would be coming up for renewal in a relatively short time anyway, and would also be something of a check on admin misbehavior (which I do not perceive as being widespread) and malfeasance (which is somewhat more prevalent), since an admin's behavior would be subject to periodic review. The "renewal" process would not be as comprehensive as RfA -- in legal terms, there would be a "presumption of innocence" about the renewing admin, and renewal would be the expected result of the process, unless compelling evidence or commentary was presented to prevent it.
1105:
one "right answer"), this could effectively serve to cause administrators to leave Knowledge. Even if a determination is made that a nominated admin should not be de-sysopped, the negativity of the process could be enough to cause a user to leave. This process would not be about looking for the good in users, but in actively pursuing the bad. There would be a presumption of guilt and wrongdoing on a basis of nomination, and I see no way of overcoming this obstacle. Some users whose RfAs fail choose to leave Knowledge and feel personally hurt by the experience; there's no doubt this could easily happen if an administrator feels unjustly attacked or accused. Personally, I think this matter is best left to ArbCom.
1062:— it encourages people to humiliate and degrade their colleagues for not being perfect. Never underestimate the power of a gang mentality and its tendency to snowball into something out of control. I'm not one to support bureaucracy, but if a sysop is causing problems for the site and their conduct continues unabated, then they can be desysopped through contacting ArbCom, who've lately shown no reluctance in removing the bit from those who've lost the confidence of the community to retain it. This process has the potential to bring out the absolute worst of the Knowledge community, and I seriously doubt it'll make adminship less of a "big deal" (quite the contrary, in fact). 2009:
appropriate use of the admin toolset, and of course other admins by definition have a better understanding of the pressures admins are subject to and should generally be able to recognize the difference between an honest mistake and abuse of the tools. This process would have admins as its gatekeepers, they would not have more of a say in the discussion itself than any other user. I'm not entirely sure I support it myself, but I think it is important that we consider the actual role admins are intended to have in this if we are going to have a serious discussion about such a process.
645:
simultaneous RFAs would be ridiculous, even thirty would stretch the community to properly handle. More seriously our problem is a declining number of active admins, getting rid of pretty much all the semi active ones and many active ones is only going to make the problem worse. Term limits are sensible for roles such as politicians and judges where there are a limited number of positions, but they don't make sense for an unpaid volunteer role where there is no shortage of mops, just of mop wielders.
2533:
those numbers to this language Knowledge, and we stand to lose about 75 active admins just from quitting when being challenged. Another approximately 65 administrators will not pass their recalls. I.e., we will lose about 1/4 of our active admin pool. This is what loss we can expect in the first year alone. This number, by itself, is twice the number of administrators who have been forcibly de-adminned by ArbCom in the entire history of the project. Questions rapidly evolve from this reality;
1298:– an average of 2.5 per month in 2012, compared to roughly 10 per month in 2009, about 30 per month in 2006 and 10 per month in 2003. Therefore, it is crucial that we take steps to prevent the abuse of this process for the purpose of harassment. The requirement for three administrators to certify a nomination is a fine idea, though I favor a higher number, but it is not enough. I propose at least one more limitation: specifically, that the RRA process be used no more than 1162:
spirit. And incidentally, if the community did decide to have such a community-wide discussion, regardless of whether in the format I propose, would anyone actually suggest that a "consensus" of over a hundred commenters (typical of these sort of discussions) should be ignored? I think in such a case, arbcom would likely meet and follow up with endorsing (or not) the results of the community discussion. (Which is what I have inherent in this process.)
2476:
has been admonished. There has to be a policy on quickly dealing with recidivists, and if the community has admonished an admin, they clearly are on thin ice, and another certification within 12 months by admins that certified a proposal that resulted in an admonishment should be okazay. I'll leave you to work out how that should read, but I think the current arrangement is too restrictive to deal with repeat offenders. Cheers,
2398:
will necessarily be follow by a arb com discussion of the issue, where every question that was brought for discussion will be discussed yet another time. If they do not wish to desysop, they will still have to decide to do nothing--I cannot imagine they will not discuss all community requests. It's not clear to me whether they will do it in private--at present, except for emergencies, their decisions are generally in public.
1605:
participate in the voting). The process provides a privileged place from which to attack an admin without risk of blowback. The process will suffer from chaotic back-and-forth submission of evidence and rebuttals while voting goes on. Bureaucrats weren't selected or evaluated by the community to decide this type of situation; their traditional role hasn't involved adjudicating inter-editor disputes. And so on.
1135:
revocation of someone's adminship was being considered, to be sure and understand context and be sure no exculpatory considerations were being missed. Understanding the timelines of disputes was the most difficult aspect of this, as events leading to calls for revocation of adminship often unfold quickly on multiple pages with people making edits and other actions too quickly to have seen discussion elsewhere.
1775: 1426:
this system is due to the limitations of the possible results, those commenting are limited as well. So for example, "So-n-so should have the tools removed because they reverted my edits" isn't going to cut it in an RRA, as it didn't involve the tools. But that reversion could potentially be part of an arbcom case, because a case handles much more in
2884:
or decisions, often someone voiced their support against what may have been determined to be consensus (not every discussion is 100% or a SNOW close) so I understand wanting to spare admins lynch mobs for merely following consensus. Which is why this is more than merely an ad hoc discussion (the way ban discussions are currently handled). -
2288:(never blocked, 2000 edits, 6 months). If it is approved, then a new request for adminship is filed. If the user gets a support rate of 75% or more, they retain the rights; otherwise, the user loses the bit and the right is removed by a bureaucrat or a steward under a cloud (the user will only be able to regain the sysop through a fresh RFA). 2667:
community agreeing that an editor should be banned (the analogy to starting a case about removing administrative privileges is starting a case about banning an editor). Most of the time the community raises the issue to the arbitration committee to handle, because it isn't sufficiently unanimous it its views to reach a decision itself.
2272:, a process called "Revalidation of Administrators" exists. The process is activated after a short discussion held in their Administrators' Noticeboard, where a user requests the revalidation by posting evidence of incorrect behaviour and other things that would be considered grounds for a desysop. After some time, if 12 users 1861:
do we require later that 80% is needed to find the person unqualified? I do not know what the number should be: UI'd suggest the same standard we use for arbcom, a simple majority. With the support levels suggested, this is unnecessary, because anyone who can actually get 80% opposition will have been removed already.
751:
Both serve to certify someone as being suitable for having access to some tool which could do some serious damage if used inappropriately. However in many places driver's licences do not expire, at least not until the holder reaches advanced age, though it is possible to lose it for serious rule-breaking.
2883:
arbcom is supposed to representative of the community. It doesn't replace the community. As I've said elsewhere, the community can ban (completely remove the ability to edit) but cannot merely remove some tools and responsibilities? Adminship can be a tough job, and (for example) in admins' closures
2752:
The three admin gatekeepers clause resolves some of the concerns re kangaroo courts, but it would be good to clarify when if ever this process would be used instead of arbcom. Remember as Arbcom has shown more than once of late they are quite capable of summarily desysopping someone much more rapidly
2731:
It took time for rfa to turn into the inquisition that it at times has become. it will take time for it to shift from that. Both being due to the comunity feeling this is their "last chance" to vedt an "admin for life". If that sense of "last chance" is blunted (by giving the community a process to
1878:
I don't see anything in the proposal about !vote percentages, supermajorities, or an 80% number, but I'll proceed as if it were there anyway. The RfA process (Not WP policy or guideline) generally requires 70-80% support !votes for the RfA to pass. However, turning this on its head and allowing a 30%
1604:
In particular, note that presenting this as a 'mirror RfA' is a specious, misleading, and dangerous analogy, for the reasons I outline. This process will also suffer the same problems with canvassing and a tainted jury pool (editors contacted and invited to submit relevant evidence will also tend to
1343:
the community at the same time; and also, somehow with minimal bureaucracy. I'm definitely leaning more than a bit on the 3 admin certification requirement. But I think that those who do the job, while of greatly divergent opinion and/or perspective, are most likely to have a unique insight into such
1165:
As you may or may not already know from my comments here, there, and elsewhere, on your first point, you're preaching to the choir : ) - Yes, adminship is not a popularity contest by any means. And for the reasons you note, among other reasons, there are good reasons to not want it to become so. And
838:
there's an admin who's regularly getting their decisions overturned by community consensus, that's a different matter, and perhaps a re-examination of their administrator status might be appropriate. Admins whose decisions are routinely upheld though, shouldn't have to jump through any extra hoops. --
750:
Thinking of adminship as a "position" isn't accurate. Adminship is fundamentally different from political positions in that (a) admins are not expected to be leaders, and (b) there is no limit on the number of administrators. A more accurate comparison would be with something like a driver's licence.
597:
This comment is not particularly pertinent to the current discussion (except that it might mitigate against the need or desire for a separate de-adminship procedure), but for a while I've been contemplating the notion that adminship should not be for life, but for a pre-determined period of time, say
198:
The discussion process is essentially the same as RfA. This is for several reasons. First, it would again be using an existing process, for the same reasons noted above. It allows for community-wide discussion. And it allows for utilising bureaucrats as closers in the exact same way the assess an RfA
2683:
The one definite advantage I see from the proposal is the ability for the community to "Admonish" or at least "Advise" (i.e. "recommend" certain changes to) Admins, which is something the community really can't do right now. (I find ArbCom to be toothless on this score.) I still think the nomination
2397:
As it stands, the process is no simpler than going to arb com directly; the community can and does express its opinion there; as it stands, The effect of this with the present default to not desysop, will be to force arb com to consider it within the time limit if they wish to desysop every case
2147:
I am agreeing with TotientDragooned, and you can see my comment above. Arbcom can assert their jurisdiction, but I think if they do not make a statement at all, then the community choice should be honored. Perhaps they can say "hang on" and then we can give them more time to chose to override. But
1860:
The failure to give specific numerical values for this makes this proposal ambiguous. Depending on the percentage,, this would either be an extremely easy or an extremely difficult way of removing an admin. If we reject a RfA when between 30 and 40% of the community think the person unqualified, why
1433:
Or to put it another way: RRA is not about sanctioning an admin. Being an admin is merely a set of tools and responsibilities added. It's about giving the community the opportunity to withdraw their collective consensus of entrusting an editor with those tools and responsibilities. While at the same
1169:
Your next point is very worrisome - I think we've all seen such things. And I will not argue that at times, Knowledge discussions can have a "bandwagon" feature to them. But again, this is one of the "con" arguements of representative vs community-wide. The same arguement could be quite successfully
1134:
A well-researched vote on a decision to revoke adminship requires effort. Past experiments have shown that marginally researched votes are the norm (even as is the case at RFA). When I was working on arbitration cases I would typically spend several hours going through the evidence in a case where
1104:
Like Master&Expert, I have concerns about the type of environment this could create. If this became a sort of witch hunt and many users decided to request de-sysopping for issues that may be largely trivial (and based on subjectively-made individual calls in situations in which there may not be
925:
Concur with Isaacl - that is a presumption of guilt Callanecc. WereSpielChequers makes a good point. Most of us have real lives and don't have infinite time for WP. BUt on balance I think if the admin who was a subject of the recall was sufficiently busy that they had no time for it then they should
837:
Requiring all administrators to undergo a renewal process, is not the way to go. Administrators already go through a review process every time they make a controversial decision. If the decision is upheld by community consensus, then the administrator's status does not need to be questioned. Now, if
822:
I think after a period of adjustment, renewal, an ordinary process with the presumption of success, would be much more drama-free than any of the de-sysoping proposals, all of which are not ordinary and regular and therefore would attract much more polarized commentary -- but, as you say, YMMV. I'm
202:
The sections Support/Oppose/neutral are both from RfA and most any other straw poll discussion on Knowledge. Advise and Admonish are from many Arbcom final decisions concerning admins. One of these are what arbcom would often enact as a final decision regarding an admin's actions, when not endorsing
2920:
I do not think the proposal is strong enough to handle a controversial cases without provisions to account for these questions. I could very easily see something like a paid editing case involving an admin greatly divide the community and it would not be difficult for whichever said that loses in a
2715:
600% rise in admin promotions. Such explosive growth has never happened on this project. Yet, in order to maintain the size of the current admin pool this is what would need to happen. I also fail to see how this process will be able to properly identify administrators who should not have the tools
2614:
Yes. And it will also temper the negative tone there. When people really feel that "the community giveth, the community taketh away", It will reduce fear of "adminship-for-life", which should reduce the harshness of RfA. And that should indeed allow for those who currently want nothing to do with
2475:
I would observe that the nomination restriction :"Once a party has proposed or certified an RRA, that party may not propose or certify another RRA for a period of 12 months, although the party may participate in proceedings certified by others", should not fully apply to nomination of an admin that
2182:
So this is a request, for comments, on a proposal, to create a new process, to allow for removal of adminship, through community discussion, but subject to arbcom adjudication. Furthermore, arbcom retains full jurisdiction, and can alter this process in any (valid) way it sees fit. Then it might be
2041:
I'm in agreement. I think administrators will be able to provide useful insight into the challenges admins face and would know first hand when an administrator has conducted themselves outside the status quo. That being said, administrators were never endowed with the duty or trusted with the moral
1425:
to have all the rest of the bureaucracy of a case. Community discussion, closed by a bureaucrat, reviewed by arbcom. Though of course at any time, arbcom can turn it into a case if they so wish. But a case allows for broader things, both in scrutiny and in possible sanctions. One of the benefits of
1325:
While I suppose I wouldn't mind more admins acting as "gatekeeper", I dunno if we'll be able to set more than the 3 admins. the reason is that there are those who might see it as "cabalism" amongst admins. I've heard arguements that any "established editor" (a term which is unfortunately subjective
1177:
For your next point, I agree. But, again, this also well applies to RfA (and XfD for that matter). So like any such process we will have "drive-by voting", unfortunately. One way to help counter that is that we tend to require 2/3 rather than 1/2 for success in such discussions. If anyone has a way
861:
In an RFA the timing is up to the candidate, I've run twice and nominated several times and I know how important it is to fit an RFA into your real life commitments. You need to start it at the beginning of a long editing session and be available every day for the first three or four days at least.
809:
YMMV, but I find the idea of a "renewal" process to be a drama fest waiting to happen. And as has been said many times by others, admins often do the unpopular jobs that need doing. And if they have to constantly go before a renewal process, they would become more politically/diplomatically minded,
666:
Agree with WereSpielChequers being a sysop is just not the same thing as being a politician. Being a sysop is not a higher status and it shouldn't be treated as such. De-sysoping is necessary in a very few cases. Regularizing it is not a bad idea. Turning sysops into politicians creates an internal
448:
It's not a binary process; some will want to discuss the certification to more closely examine the evidence, as is appropriate in Knowledge's (for better or worse) consensus driven environment. Sure, this could be done in an RFC/U, but I suspect many people will dislike breaking up the conversation
2603:
I disagree with your premise. The reason for this is to more directly empower the community, while still trying to avoid "pitchforks". Let's put it this way. Right now, the community can ban an editor. That is, completely remove their ability to edit. But the community doesn't have the direct
1898:
I think that you need to set some specific level of support that would be needed to retain the tools—personally, I think that, at the very least, you ought to have 50% of the community supporting someone's continuing adminship. That's much less than required to obtain the tools in the first place,
1608:
Finally, when I wrote my comments nearly three years ago I noted that there were other routes to desysopping that did not require the rigamarole of a brand-new process. At the time, the ArbCom had just handled the desysopping of Craigy144 by motion at the community's request; from start to finish
1186:
process. After all, the result of this process is merely removal of some extra tools. I am surprised that we seem to consider that as some "higher" thing than banning an individual from Knowledge. If the community can be trusted to ban someone, why can't the community be trusted to say that "we no
1130:
Anyone who is a regular at RFA, RFC, or AN/I can tell you that scope of conflict is a big deal. Anyone who can mobilize one or two dozen seasoned editors can create the appearance of consensus, early, and the result can snowball. The worst conflicts we've had as a project have involved groups of
705:
3. This is not intended as a social experiment at building a model community (a complaint which canbe turned around and leveled at the current Knowledge infrastructure as well), it's intended to make editing Knowledge a better experience by making admins more responsive to the needs and desires of
147:
The application of editorial sanctions (such as a topic ban) due to such discussions, presumes that such sanctions also apply to the editor's use of administrative tools and/or responsibilities. So, there is no reason to expand/complicate this process. (Especially as Bureaucrats have made it clear
2818:
For the purposes of this, I will group admin "abuse" cases into four types: minor misjudgement, grave/rapid abuse, long-term abuse, and general, obvious abuse. Minor misjudgements can be resolved with proper dispute resolution + AN if necessary to seek a tool restriction; grave/rapid abuse can be
2631:
I think the current informal process is actually similar to how a community-based ban proceeds: the community can decide upon a ban, but it relies on admins to implement the ban. Similarly, the community can decide to revoke administrative privileges, but it relies on the Arbitration Committee to
1161:
arbcom vs. community sounds similar to the comparison of representative gov't vs "true" democracy. There are pros and cons to each. We have a long tradition of embracing community discussion. I think that allowing the community to have a community-wide discussion regarding de-adminship is in that
1122:
Master&Expert speaks my mind on this. At this point, the main reason we have an arbitration committee is to deal with removal of adminship in an evenhanded, fair, evidence-based fashion. While the committee is not perfect I believe they are far better than a community-based system would be:
261:
The current text lists a "pattern of misbehavior or abuse" as the reason for initiating this process. I believe that problematic administrative actions do not have to stem from misbehaviour or abuse. In the end, what is at question is whether or not an administrator can appropriately evaluate and
2666:
During the recent years, in the few times when the community has reached a clear agreement that administrative privileges should be revoked, the arbitration committee has acted swiftly to implement the decision. I'm not talking about initiating an arbitration case, as this isn't analogous to the
2532:
The proposed system is effectively identical to the German system of de-adminship. Within the first year of starting their process, they lost about 1 out of every 8 administrators from their process by way of challenged admins failing to respond or just retiring when faced with recall. Translate
1946:
There are several reasons for requiring approval specifically from admins, the most obvious being that admins are considered trusted members of the community. This isn't the best reason though, especially when considering that if all admins were saints, we wouldn't need RRA in the first place. A
754:
I don't think a system of term limits would do much good. For a start a lot of admins would choose to resign rather than go through the process, especially inactive or semi-active ones. If the reconfirmation process looks anything like RfA then this problem would get a lot worse. Consequently we
718:
misbehavior. In the real world, doling out permanent positions is done only rarely, and for good reason. Making adminship a lifetime appointment endows the position with much too much importance (hence point 2 above), while making it a limited position subject to periodic renewal makes it more
189:
So it's not preventing those processes in any way. So, for that reason, and because RRA (like any discussion of an editor (like RFA, AN/I, RFC/U, etc.) can be a contentious environment (and so inappropriate nominations should be weeded out as soon as possible), the gatekeeping mechanism has more
1965:
I appreciate your reply but I'm not convinced. The inference is that other members of the community are not as trustworthy as admins which I reject. I also reject the idea that admins are uniquely capable of understanding that admins are sometimes placed into difficult situations that require
463:
I wasn't specific about this on the page, just pointing at the certification process of RFC/U. It has a time limit of 48 hours for the certification process. That said, I'm open to the question of whether people should be able to plant their thoughts under support/oppose/neutral/etc. during the
2713:
Jc37, I don't think my comments are going to sway you as to why this process will cause significant unintended consequences. I spoke from real data, and you are speaking from supposition. With all respect, I trust the data more than I will trust anyone's supposition. For my part, I find myself
1613:
when they were presented with a clear pattern of poor judgement capped by a bad block. When there is a clear and unambiguous breach of the community's trust, the ArbCom is capable of acting decisively and promptly. (The long, slow Arbitration cases are the messy ones involving many different
722:
4. I don't suggest this because I believe admins, in general, do a bad job. In fact, I believe precisely the opposite, that they're generally pretty good at what they do. However, my observation of the community convinces me that a mechanism is needed to allow the release of pressure for some
505:
This is a remarkable example of the hazards of decentralizing discussions. While I appreciate that this page has been written in good faith, it's not helpful to the community to have two competing proposed policies as well as an RFC on the same topic all at once. I urge the author to consider
215:
I have read comments from bureaucrats where they are uncomfortable with expanding the bureaucrats' role in determining consensus much beyond what they do now. So the choice is still just an up or down result; successful or unsuccessful. Is there consensus whether the community does or does not
1286:
It is quite likely, in my opinion, that the atmosphere of many RRAs would become toxic. However, the same can be said of the alternative to RRA: formal arbitration. Often, cases before ArbCom are characterized by acrimony, accusations, and an unhealthy and unproductive exchange of grievances,
644:
Only half of those admins are active and rather fewer sufficiently active to pass an RFA, so while there would still be a problem handling the first wave it wouldn't be close to 1500, I suspect we'd be lucky if three hundred admins were willing to go through another RFA. Even so three hundred
248:
And while this is all going on, the admin who has had the RRA closed as successful has had adminship removed. This is to prevent any issues. If the community has decided they cannot trust the editor, then there may be a question of trusting them with the tools while arbcom reviews everything.
2291:
If needed, we can also add that two or more bureaucrats are needed to certify the evidence and request to be legitimate before opening the new RfA. As we have a great trust on bureaucrats, I think they are the ones needed to certify the requests if this is needed. Also, this new request for
1396:
The problem with setting any sort of limitation on the number or frequency of RRA nominations is, as you note, that it will invariably be either ineffective (too weak), inflexible (too strong, such as "never") or arbitrary (e.g., "2 years"). I think, however, that an inflexible or arbitrary
1282:
Prior to the initiation of an RRA, genuine attempts should be made to correct the sysop's behavior. These attempts should include, at a minimum: (1) direct communication and engagement with the sysop; (2) informal mediation or advice by one or more neutral, uninvolved editors; (3) community
181:
And the reason for the minimum of 3 admins as certifiers is because on one hand: those who currently have the tools and responsibilities of adminship are more likely to understand how it is to carry those tools and responsibilities. And admins are a pretty diverse bunch. If you can't find 3
2008:
It's relevant to consider the context of the "trustworthiness". We do not trust admins to make unilateral decisions about content itself above and beyond any other user, even if they just signed up or are editing as an IP. We do trust them, for the most part, to know what is and is not an
1392:
You might be right about RfA. The knowledge that there is a community-driven mechanism for removing administrators might allow editors to be less stringent in their evaluation of admin candidates. You also make a convincing case for limiting (to 3) the number of admins needed to certify an
1899:
but it also prevents having a situation where someone gets to continue while having only minority support. I also think the proposal needs to be simplified a bit: get rid of the advise and admonish options and just have support or oppose. The advise option seems particularly superfluous.
407:
Maybe I should make that more clear on the page - That this process is only to begin if inappropriate behaviour is asserted and certified, and the singular question of the process is, in relation to that assertion: Does the community continue to entrust this individual with the tools and
1218:
When considering any proposed process, I think it is useful to ask the following question: Would the new process address a need that currently is unaddressed, or improve existing processes, without imposing an excessive administrative burden or causing significant negative side-effects?
174:, as well as wasting the community's time. Admins may close contentious discussions, or need to take actions for the good of the project and the community. And those actions may be unpopular. If there was no "gatekeeper" on this process, then not only would it lead to potential constant 395:
I wasn't going to add the advise and admonish sections, but after several lengthy discussions (some which I read and also some I was in), I can see the value of having those sections, as long as we make it clear that they are still implicit opposition to the question of de-adminship. -
1138:
This doesn't solve any problem we actually have. In most cases, admins who don't understand what the community expects resign by themselves. In some cases the arbitration committee becomes involved. Where is the list of bad admins that will provide grist for Jc37's beautiful new
2651:
I disagree. there's a difference between an admin (or bureaucrat) assessing a community discussion and closing it, and starting arbcom processes. A similar (though not the same) comparison might be the difference between direct democracy and a representational republic. A definite
387:
Not quite, but close. The idea is to keep this process very focused. If it gets bogged down into anything beyond a simple question of assessing an admin's behaviour related to the use of the tools and responsibilities, it will becomes the typical trainwreck, and nothing will gain
2494:
My preference would leave the length of time between "ReDos" in bureaucrat hands, just as admins do with speedy closing renommed XfDs. But I'm really trying to keep the bureaucrat role focused, based on comments the bureaucrats have made over the years concerning their role in
211:
The closure choices of successful/unsuccessful are intentional to match the current close at RfA. This allows bureaucrats to assess consensus and close an RAA the same way they close an RFA, with advisement and admonishment being something additional to potentially note.
2753:
than this process would allow for. Also you need to come up with some concrete benefits to this scheme and they need to be significant. We have a declining number of admins, this will obviously make the situation worse, and there need to be some benefits to offset that.
2126:
I have to assume that this provision was included in the proposal to avoid trespassing on ArbCom's jurisdiction. If the tools could be taken away without consensus from ArbCom, then this process would obtrude upon ArbCom's current jurisdiction over removal of adminship.
2023:
Nod BB. The certification part is one that just obviously needs strength but "not too much" strength. There are those who want it free and open to anyone, and others who feel that even 3 admins is not enough. from reading over quite a few (a LOT of) discussions, I think
977:
Arbcom deals with such timing issues as well. The simple way to deal with it is to acquiesce to the request, while noting that obviously that also means they won't be taking any admin actions in the interim. If they do, then obviously they have time for the process. -
1947:
better explanation might be that admins have knowledge of the tools and how to use them properly, and therefore should know, even more than a typical editor, when an admin has misused their tools, and when they have merely made a difficult or unpopular decision.
2548:
Do people honestly think that putting a de-adminship proposal such as this in place will open the floodgates of RfA such that we will see a net gain of active administrators? Such a mass shift in promotions would cause about as many promotions as have happened
1181:
I believe that this solves (or helps solve) several issues actually. Though YMMV, of course. The main one is to help reduce the community fear related to entrusting someone with adminship. It also helps cut through the bureaucracy that currently exists in the
2947:
in that example you give, I could see arbcom stepping in any way. The goal here isn't to make a secondary arbcom process, it's to give the community a process IN ADDITION. Right now, the community can ban, but they can't desysop, which doesn't make sense. -
1548:
I would prefer if arbcom fail to complete the review by the time limit or don't do it at all then the decision from this process should stand and not be reversed. By using Arbcom as a final review the process is still very similar to what we have now.
1192:
That last point is the crux. So far most of the arguements against this process essentially come down to not trusting the community. With the implication that the tools are sacrosanct to whomever is granted them, and shouldn't be removed by community
127:
The community can already ban (completely remove the ability to edit) through a simple ad hoc discussion. This proposal provides for a process for the community to desysop, that is, to merely remove some tools and responsibilities from an editor.
228:
granting some authority to a community-selected committee. Back then, arbcom would ask a steward to "push the button" to remove the adminship. Now bureaucrats can push that button. (Back then they could only push a button to grant, not remove).
2335:
Afaik, the ability to ask stewards or bureaucrats to desysop rests solely in the hands of Jimbo Wales and arbcom, and so having arbcom be part of the process is necessary. To hear that that is not the case on another wikimedia wiki, is very
1264:, it should be easy enough for the community and bureaucrats to handle. Even for ArbCom, I see no significant increase in workload; after all, in the absence of RRA, any request to remove adminship would be processed through ArbCom anyway. 884:
Sounds good, and the way to fix the 'putting it off issue' is that the admin right is temporarily removed pending the RRA. That way if they want to put it off they don't have the admin right - giving them an incentive to get the RRA done.
601:
It seems to be that Wikpedia's lifetime adminship policy was a reasonable one for a start-up project which had no idea how successful it was going to be, but now that Knowledge is middle-aged and successful, a different standard should be
2509:
I definitely think what I'm suggesting should only apply to admins admonished less than a year ago, not to any other results, for which I think the one-year rule is fine. I wouldn't imagine there would be a lot of admonishments. Cheers,
558:
Perfectly fine with me. This proposal (in its previous layout of a bulleted list) was transcluded to the RfC at request of WTT, the RFC's creator. If there was a way to transclude this, I would. But I hesitate to do so due to length. -
2684:
hurdles are too high (requiring 3 Admins to sign on probably dooms almost any nomination that comes down the pike under the current proposal), but I'll probably support this just based on the "Admonish" & "Advise" provisions. P.S.
1166:
yes, we shouldn't be penalising those who perform tasks which may be considered unpopular. That said, what is unpopular to some, may be considered appropriate by others. So I dunno if this concern has as much weight as we might think.
2937:
We don't have double jeopardy now afaik. if you keep trying to delete the main page then... That said, if your concern is multiple attempts at RRA due to that single attempt at the main page, the community itself is the barrier, as
163:), already has a process for requesting comment concerning an admin's actions related to the tools and responsibilities of adminship. So the nomination and certification part of that process should work well enough for this process. 2069:
I don't like that Arbcom has an effective "pocket veto" where by completely ignoring the community, it can overturn a community decision. If the Arbcom wishes to overturn a community decision, it should have to do so affirmatively.
123:
The goal is to create a process for community-wide discussion concerning the question of whether a particular admin should continue to be entrusted with the tools of adminship; with the possible result of those tools being removed.
391:
Also, I've read commments from several bureaucrats that they don't want the role of bureaucrats expanded much beyond what they do now. Which is why I've kept this very clearly to use terms that already exist in RfA and are used by
1339:. We of course don't want constant cases, harrassment and so on. But "never" is a problem too. The tough part is setting a "how often" is rather arbitrary, and almost never matches community need. I want to protect the admin 990:
I suppoort jc37's solution - it addresses the problem (the admin in question won't fdo any admin actions during the delay period), while also addressing the issue of the admin's right to time it for when (s)he's available.
2632:
direct the bureaucrats to implement the removal of privileges. The lack of a direct ability is not an issue in practice, as clear-cut cases raised by the community are quickly handled by the committee. The problem is that
1131:
3-5 editors who are heavily involved in Knowledge and who also have close personal ties to each other in real life. Such groups mutually reinforce and distort any sort of threshold or voting system that might be in place.
2778:
This won't make that worse, it will make it better. If the community has a direct way to desysop, rfa will (albeit slowly) get less "nasty". This will help restore community trust levels in the admins. Not because they
755:
would have decimated the admin corps for no particular reason. You admit that admins are generally good at what they do, so the reconfirmation process would in most cases be a waste of time (assuming it works properly).
2364:
I considered the 3 bureaucrats for closers idea, but since arbcom will review the close of an RRA, I didn't think it necessary. If arbcom wasn't there, then probably the "3 closers" practice would probably be needed. -
2228:
So this proposal is a way to allow for such community discussion. That said, afaik, only arbcom (and/or Jimbo Wales) can ask a steward (or bureacrat now) to desysop someone. So this proposal is in deference to that. -
1349:
RRA would likely have a tone similar to what we see at RfC and/or AN/I. People are involved, and asked to express their thoughts. As you note, there's not much that can be done about that save clamping down on needless
1283:
discussion at an appropriate noticeboard (such as the Administrators' noticeboard or AN/I) or a full-fledged user request for comment. I think that this should be a prerequisite to any request for removal of adminship.
269:
is a process for the community to call for a review of an administrator's actions while carrying out administrative duties, to examine if they have exhibited a problematic pattern of misjudging community consensus or
327:
Thanks for making the change. Naturally, I believe my wording to be more concise :P (and in the interest of collegiality, I'd prefer to avoid the imagery of a no confidence motion) – but let's see what others think.
1621:
While there seem to be a lot of editors who like the idea of developing a shiny new process, there seems to be a shortage of actual admins engaged in a pattern of abuse who are somehow slipping through our cracks.
2906:? (Administrators cannot undergo a second request for removal over the same thing; ArbCom would be the only avenue for removal of the tools as they have the right to overrule a community decision for desysopping) 1321:
To take your last point first, I think by having such a process in place should actually help with the tone at RfA, an so by extension, should help with gaining more suitable admin candidates willing to request
2633: 2276:
support the evidence and the revalidation, the revalidation proccess begins. In this process, similar to an RfA, users vote to find consensus to remove or not the sysop bit from the administrator in question.
1233:
To be honest, I am not convinced that there is a need for such a process. However, the fact that every year there is usually at least one formal proposal (and lots of general discussion) about this issue (see
422:
I suspect there will be those who will choose to dispute the certification, and so the discussion will inevitably review the actions in question. Thus the process may as well incorporate this review into it.
943:
period time (of the admin saying I'm too busy) they temporarily lose the mop. Plus if they are too busy to talk to the community, then (maybe) they are too busy to be an admin anyway (for that time period).
1983:
While I'm sure that some admins are less trust-wortyhy than some other admins, I think that the average admin is probably more trustworthy than the average user from any less-autherized group on Knowledge.
1235: 2827:
removal procedure, opening a case if there are objections. The only case that I can think of where RRA would actually be useful is when ArbCom has no quorum (one-third of active non-recused arbitrators?).
2537:
Is admin abuse so entrenched, so powerful that 140 administrators who need to be de-adminned have failed to rise to the level of scrutiny by ArbCom? ArbCom so corrupt that even if they did they were not
2590:
Ok, so, I'm setting aside your presumption that the numbers there will have any bearing on numbers here (projects are just different - number of contributors, tone, and policy and procedure sets, etc).
620:
Does this 'renewal process' you suggest require a bureaucrat to close it? Currently there are approximately 1500 admins. Term limit of 5 years would mean approximately one renewal process every day. --
144:. Questions of concerns or sanctions which may apply to any editor (and not directly to the tools and related responsibilities of adminship) are beyond the scope of this proposal for similar reasons. 1335:
I'm not sure about the last limitation you suggest. "Now that I've been through an RRA, I've now a licence to do whatever I want, with at least some impunity." It's the main flaw of any rule against
2166:
act. Look at how often arbcom sidesteps making a decision if they don't "have" to. In the case of desysopping, they should follow through on this responsibility. This helps "nudge" them to do so. -
2280:
I think we can take that example and design a similar process for en-wiki. The Spanish Knowledge has 131 sysops and we have 1600 here, so, modifying a bit their design, we can have three users in
2944:
certification - that's a fair point - did RfCs have a certification time limit? Do arbcom cases? might be worth checking to see how the community currently (and in the past) has handled this
1401:
to a standard ArbCom case, and neither a replacement of nor a prerequisite for it. As such, admins who "survive" an RRA still can be held accountable through the standard arbitration process.
73: 2114:
Is this a theoretical issue, or is there a specific case you're talking about? And yes, ArbCom should explicitly say it's overruling the community consensus when it does so, not ignore it.
823:
not opposed to having a de-sysoping procedure below ArbCom, I just think that renewal would be structurally and psychologically better. I won't push the idea, I just wanted to put it out.
2376:
There is a fundamental difference asking someone to re-run versus stripping them of their tools. Maybe I'm wrong but I think that's what Hahc21 is indicated to be the hallmark difference.
1127:
Admins who do the job well accumulate enemies over time as every close call an admin makes upsets someone. Initiatives like this disincentivize measured involvement in difficult matters.
178:
or lynch mobs, but would have the affect of causing admins to no longer wish to deal with contentious situations. And as this is a volunteer project, that would obviously be detrimental.
2292:
revalidation of adminship will last for 14 days instead of 7 (It can last for 7 days, but es-wiki has them lasting for 14). If you want to see an example, an es-wiki administrator named
2251: 688:
1. The "first wave" for currently standing admins would have to be staggered in some way so as to deal with them over a period of time. New admins would go by the standard time period.
2322: 2775:
Used anytime the community so deems. This is just to provide an adjunct process. And arbcom vacating the discussion due to emergency desysopping is already listed in the proposal : )
2491:
An interesting point. The reason for the restriction comes from past discussions where editors were concerned about repeat nominations as a form of harrassment of an individual admin.
1477:
RfA has a time frame as well. The idea is to have a process which is shorter than a full arbcom case. If Arbcom decides they need a full case, they can elect to start one as noted at
1410:
I can't think of any other tweaks at this time. As I mentioned elsewhere, a large part of the appeal of this proposal (for me, at least) is its simplicity and straightforwardness. --
1312: 1742: 1014:
It occurs to me that we might also allow admins to ask their renewal to be done early, say, up to two months before it would normally happen, at a timing of their own choosing. --
1753:
There is no good reason offered. The edit-summary gives some lame reason like "soon to have high visibility". Well, so what? I see no vandalism thus far. It's not a good sign.
1640:
And I think I must respectfully disagree with your assessment. AFAICT, this proposal very clearly has attempted to deal with the vast majority of the concerns you noted there.
2877:
certify as well. As varied as our admins are, if you can't get three to certify, there likely isn't a substantive case, or b.) it should probably be handled by arbcom anyway.
1832: 1563:
My understanding when making this, is that the power to desysop lays with arbcom (due to deferral by Jimbo Wales), and that is something we as the community cannot change. -
2109: 1434:
time, making certain that it's not being attempted for harrassment or frivolous or lynch-mob reasons. The latter being the purpose of the RFC/Admin-style certification step.
2157: 283: 906: 302:
Misbehaviour carries the connotation of knowing the correct behaviour and choosing to act differently, whereas misjudging community consensus can be done in good faith.
22: 661: 2873:
the bar is a compromise that came out of discussions at Talk:RFA. some wanted more, some less. so this was "at least" 3 admins, but also othercommunity membbers can
2864: 2593:
I looked at the German process. It's essentially an RfC with no rules whatsoever that I see. No gatekeepers, No review. No restrictions in format. Etc. Aparently it's
2297: 2121: 1287:
complaints and criticisms. The only way to counteract this is for uninvolved editors to attempt to exert a calming influence and to demand a civil and honest exchange.
1213: 683: 2852: 2797: 2079: 1095: 1080: 526: 522: 69: 65: 2018: 1558: 1306:
On the whole, I like this proposal for removal of adminship more than any other I've seen over the past several years and think that it needs only a few tweaks. --
1205: 1150: 1020: 1009: 763: 639: 2172: 1847: 1569: 848: 744: 2140: 1665: 2890: 2451: 2439: 1991: 832: 2519: 2504: 2211: 1443: 1416: 1374: 793: 61: 1978: 1960: 965: 920: 256: 2913:? (I could easily see this bringing up a lot of history in controversial cases; perhaps any incidents that exceed 2 years be automatically deferred to ArbCom) 2741: 2578: 2050: 2036: 1631: 998: 565: 553: 2192: 1920: 1478: 723:
editors under some circumstances, and the renewal process would act as a more benign pressure valve than the "de-sysoping" process, since the emphasis is on
2707: 2485: 1803:
Three noms is not bad, but restricting them to 1 per year is impractical. Restricting users to 1 decline per year, however, might change the tenor of RFA?
1792: 1458:
I haven't read the other threads here. One thing pokes out—I don't think ArbCom will appreciate being given a deadline (well, especially such a short one).
934: 1892: 581: 2676: 2661: 2371: 1649:
an editor with similar discussions, and that without the safety valves that this proposal has, I would think that the community should be able to desysop.
1114: 535: 470: 458: 443: 432: 402: 382: 368: 337: 322: 311: 297: 2916:
Do request pages stay open indefinitely until they're certified? i.e. a request page stay in limbo for years while it awaits a third admin to certify it.
2246: 2235: 1539: 1513: 1487: 1332:
Plus, the admins are there more to stop frivolous or harrassing noms. Arbcom review is what is more acting as the prevention of miscarriage, or lynching.
136:
The process is focused only on "the tools and responsibilities of adminship", per existing practice and policy concerning such discussions, including at
2954: 2769: 2725: 2621: 2566: 2462: 2384: 417: 1706: 515: 2430:
Is this proposal still being considered? It seems like after this much time has passed, a decision either way (to close or to adopt) should be made.
1940: 1766: 1712:
After having read the proposal, while I do feel it may be a little too difficult to certify a request, I nevertheless strongly support the proposal.
706:
the community, rather than being (in effect) self-regulating. De-sysoping by ArbCom is too remote and unused a procedure to be an effective check on
2645: 236:
process. (Besides JW and the foundation etc.) Afaik, in practice (and policy) no one else can ask for de-adminship (outside of emergency de-sysop).
1814: 316:
I kinda agree - I was thinking about it and changed it to "inappropriate behaviour", and came back to tell you only to find you've responded : ) -
2839: 1823:
I am supporting Rich on this issue, no need to restrict. If someone goes crazy nominating inappropriately, then a topic ban may be appropriate.
667:
conflict of interest for them (they'd need to NOT take appropriate but tough decisions in certain areas), and deviates from core aims of WP: ie
614: 878: 2668: 2637: 1908: 912: 450: 424: 374: 329: 303: 275: 605:
I don't expect this idea to take root immediately, but I'd like to put a bug in people's ears to perhaps inculcate the idea for the future.
2941:
Look at RfA - no codified "statute of limitations", the community members commenting just decide whether to "forgive" past offenses or not.
587: 2929: 2445:
I'm re-looking over all the contributions to the discussion(s), and will be proposing something similar in the not-too-distant future. -
911:
If the issue is dire enough that an immediate removal of administrative privileges is warranted, there are existing procedures for this.
31: 2557:
There are very serious potential unintended consequences to any de-adminship system that need to be considered before moving forward. --
2812:
The bar for initiating a RRA is too high. It may cut off all lynching, but the cases that this process can handle is severely narrowed.
2420: 1872: 362:
I'm not totally tied to the phrase. But it seems to me to convey rather well that this is entirely (and only) about community trust. -
77: 2409: 816: 580:
Is it real? Can we FINALLY create a de-adminning process that actually holds sand? This is a proposed process that I support 100%. -
544:
I had the same thought Risker did... so I'm going to post my comparisons and thoughts (and hopefully others will follow) at the RfC.
2611:
admins, not just any bodies. And especially not ones determined to be untrustworthy of the tools and responsibilities of adminship.
1383:
Thanks for your detailed response. Your reasoning is convincing, and I am happy to see that we are in agreement on some main points.
1966:
unpopular actions. Both ideas seem to assume a sufficient level of experience, judgment, and maturity is only possessed by admins.
1735: 1699: 1471: 2284:(never blocked, 5000 edits, 1 year, preferably admins) requesting the revalidation, which has to be approved by 25-to-50 users in 1583: 1601:. While that proposal and this one aren't identical, there are enough similarities to make the last round's critiques relevant. 1597:
in 2010. I would strongly urge this proposal's proponents to review my comments on the last proposal's more serious problems at
1036: 984: 1522: 1178:
to get people to even read a nom/proposal, much less do the due dilligence related to that topic at hand, please let me know : )
2064: 1355:
I do like your points about steps to try before requesting an RRA. Contact the admin first, and try to work it out. Then try a
2815:
If ArbCom has to review all cases, and editors claim that ArbCom is slow, then wouldn't this process be slowed down by ArbCom?
2636:
to handle discussions with many people, and so the community is unable to reach a clear consensus on many contentious issues.
2425: 2030:
3 admins as certifiers was a fair compromise amongst all the concerns. That said, I'm happy to see this further discussed. -
1041: 148:
previously that they would prefer to not have their responsibilities expanded as to require them to close such discussions.)
1594: 506:
folding this into the current RFC rather than further dividing the community's ability to focus on the central concepts.
91: 2431: 1397:
limitation is better than an ineffective one or none at all. My thinking hinges on my understanding that RRA would be an
1295: 81: 2823:
removal procedure, long-term abuse probably should be handled by ArbCom, and general, obvious abuse can be handled with
2217:
The idea is to give the community more of a voice in the process. As I've said elsewhere, if the community can totally
500: 1969:
Of course, leaving the process of removing admins completely in the control of admins is inherently problematic, too.
690:
2. The idea that there is nothing special about being an admin is a relict of Knowledge's past, and is no longer true
2470: 1748: 1588: 1421:
I don't see RRA as an alternative to an arbcom case so much as a way to request tool removal from an editor without
2855:. For standard cases, there are no quorum restrictions. Theoretically, 1 arbcom member alone can handle an RFAR. -- 2545:
the number of active administrators, is reducing our admin corps by 25% in the first year alone really a good idea?
1294:. We have, at this time, roughly as many administrators as we did in 2007. Perhaps more worrying is the fact that 437:
Disputing the certification is easy: place your reasoning and signature under "oppose" section in the RAA. QED. -
274:
This wording may also help keep the discussion focused on the administrator's behaviour in serving the community.
2716:
when ArbCom has failed to do so. That said, I'm convinced you are convinced this will work. So, put it to RfC. --
2527: 1926: 1598: 1593:
I'm seeing many of the same mistakes being made in structuring this proposal as took place with the last (major)
955: 896: 783: 2301: 2225:. The latter merely removes some tools and responsibilities. The former removes the ability to edit altogether. 1618:
be handled by a speedy, sloppy RRA, CDA, or RfDA process that doesn't and can't examine more than one party.)
1676:
I haven't looked into this very much just yet (I do intend to do so), but I expect to support this proposal.
1609:
the entire process took less than two weeks. In July of this year, the ArbCom desysopped Carnildo by motion
2735:
It will just take time for the community to shift its perception, just as it did to get where we are now. -
2698: 2352:
The percentage requirement is to be considered the same as RfA, rather than saying a set number like "75%".
1727: 1691: 1291: 845: 449:
into two phases (many attempts I've seen to structure discussions into phases have failed to be observed).
2760: 1529: 869: 652: 1046:
I'm opposed to this idea in theory. I just don't feel comfortable having a community process similar to
224:
Historically, Arbcom was given the ability to ask for de-sysopping of an admin long ago. It was part of
2655:
And if your last point is true, then neither this and nor any other proposal will gain consensus : ) -
2075: 1368:
I'm of course happy to discuss the above. In addition, are there any other tweaks you would suggest? -
1147: 1074: 2824: 2820: 1359:
of some kind. And finally an AN/I on the particular actions in question. And noting that these should
1242:
perceive a need. The attraction of RRA is that it is essentially an expansion of an existing process (
112:
The idea is to not create something out of whole cloth, but to use existing terms and processes so to
2153: 1828: 1808: 1554: 1329:
If we add more than 3 admins, how would we avoid turning the certification into a mini RRA of itself?
1054:
with the administrator in question. It is the same inherent flaw that exists in other venues such as
2349:
it adds the "advise" and "admonish" options that arbcom has used when assessing a desysop situation.
1837:
I'm not strongly tied to this restriction, but I'll note that it came out of several discussions at
2747: 2515: 2481: 1627: 2896: 2435: 2100: 1713: 1677: 828: 740: 610: 584: 1274:
Potentially. In particular, I have three concerns: the good-faith pursuit of alternatives; the "
2910: 2755: 2692:
You probably want to copyedit the Nomination section now that RfC/U & RfC/A are defunct. --
2042:
authority to judge administrator conduct, only editorial conduct -- and there is a difference.
1671: 864: 647: 373:
It's a bit too absolute for my tastes; personally I think it implies an all-or-nothing choice.
1652:
And there is of course the processes for emergency desysop. This is merely adding another way.
2803: 2071: 1855: 1798: 1225: 1143: 1063: 262:
carry out community consensus and policies. Thus I suggest rewording to something like this:
2860: 2721: 2562: 2392: 2149: 2118: 2014: 1988: 1824: 1805: 1550: 1018: 1007: 995: 549: 182:
experienced admins to support an RRA, then there's a reasonable doubt whether it is valid.
1187:
longer trust the editor with the admin tools and responsibilities, so please remove them".
668: 8: 2594: 1904: 1623: 1089:
And the certification stage is designed to be a safety valve against "gang mentality". -
951: 892: 779: 592: 156: 141: 2833: 2260: 2205: 2188: 2134: 2086: 1954: 1886: 1838: 824: 736: 606: 239:
So we need to leave the channels open. Arbcom needs to be free to take whatever action
2607:
if they should not have the tools, then they should not have the tools. We want more
2511: 2477: 2269: 1974: 1936: 1787: 1412: 1308: 960: 901: 788: 629: 60:
Note: This proposal stems from several lengthy discussions and proposals, including:
2498:
There's some middle ground in there somewhere, and I'd be happy to discuss it : ) -
2293: 1931:
Why does this process require certification specifically from other administrators?
1278:" of RRA nominations; and the decline in the number and activity of administrators. 193: 187:
RRA is an adjunct process. It doesn't replace current processes to remove adminship.
151: 107: 2702: 2672: 2641: 2316: 1430:
than merely whether the community continues to trust the individual with the tools.
1110: 916: 842: 511: 454: 428: 378: 333: 307: 279: 225: 171: 464:
certification process, or need to wait until after the nomination is certified. -
203:
de-adminship. So adding these two sections, gives the community that same option.
2903: 2856: 2717: 2558: 2346:
3 admins to certify a go-ahead for the process (instead of the two tiered 3 + 12)
2240:
Note: I have removed the arbcom mandatory review and vest pocket veto clauses. -
2115: 2010: 1985: 1761: 1508: 1466: 1453: 1336: 1260:
I do not think so. Since the process is quite streamlined and designed to mirror
1055: 1015: 1004: 992: 575: 545: 160: 1637:
Ok, I've read through your comments, and the links (I liked KB's bus analogy : )
529:), which predates (and may have inspired) the RFC, and everything subsequent. - 131: 2927: 2382: 2305: 2048: 1900: 1252: 1059: 946: 887: 856: 774: 672: 521:
I've already linked this in the current RfC. This is actually an extension of
137: 117: 113: 2148:
by totally ignoring it, it should not mean that they are opposing a decision.
772:, I think that term limits would just be a lot of work for not a lot of gain. 206: 2405: 2329: 2199: 2184: 2128: 1948: 1880: 1868: 1356: 1261: 1243: 1047: 926:
petition the 3 admins or ArbCom for a continuance of the commtte's choosing--
1518:
I know that in the US there is a preference to use "that" for everything : )
219: 2456:
Wow, it's been over two years - So much for "not-too-distant future" : ) -
2414:
I have removed the arbcom mandatory review and vest pocket veto clauses. -
1970: 1932: 1783: 1577:
I have removed the arbcom mandatory review and vest pocket veto clauses. -
1427: 1183: 1171: 769: 757: 621: 233: 167: 1437:
Anyway, as you said, it sounds like we are of similar minds on this : ) -
2693: 2309: 1363:
help with acting as gatekeepers against frivolous or harrassing requests.
1106: 927: 839: 676: 507: 2634:
English Knowledge's current decision-making traditions do not scale well
1754: 1533:
Anyway, that and which aside (lol), thanks for looking this over : ) -
1501: 1459: 2950: 2922: 2886: 2793: 2737: 2687: 2657: 2617: 2597:. (And this without going into their temporary de-adminning process.) 2574: 2500: 2458: 2447: 2416: 2377: 2367: 2242: 2231: 2168: 2043: 2032: 1916: 1843: 1661: 1579: 1565: 1535: 1483: 1439: 1370: 1201: 1091: 1032: 980: 812: 561: 531: 466: 439: 413: 398: 364: 318: 293: 175: 88: 2714:
incredulous that this process, if put in place, would cause a : -->
2584: 2400: 1914:
Advise and admonish are directly taken from arbcom case results. -
1863: 1269:
Would the proposed process cause significant negative side-effects?
2339:
except for the arbcom part of the process, it just takes 7 days.
1643:
As for the cabalish/votestacking concerns, if the community can
810:
and not help in such ways, and then the project would suffer. -
2604:
ability to remove some tools from an editor? That needs fixing.
1655:
I'd respectfully ask that you re-read the proposal, as this is
1479:
Knowledge:Requests_for_removal_of_adminship#Arbcom_jurisdiction
21: 2600:
But all that aside, to try to answer your questions/concerns
1050:
where people are by necessity discussing everything that is
2183:
simpler to just let arbcom deal with removing adminship.
1296:
we are gaining new admins at the slowest rate since 2002
1158:
Let me try to respond to your several points in order:
1841:, and I included it merely due to others' concerns. - 166:
The reason for certifiers is to create a "gatekeeper"
669:
being an encyclopaedia not an experiment in democracy
2221:
someone, I think it's odd that the community cannot
1086:
People say such things even without such processes.
80:; and many past discussions, including those found 1214:Some considerations: need, burden and side-effects 2252:A "Request for Revalidation of Adminship" process 1614:editors and interests: the cases that absolutely 1275: 702:true in principle. I'd rather deal with reality. 216:continue to trust the individual with adminship? 1030:I'll add the proposed solution to the page. - 257:Reasons for requesting an administrator review 2732:"taketh away"), then so will the inquisition. 1500:, have you read the Chicago Manual of Style? 1228:, to strip editors of the 'sysop' user right? 1318:Thank you for commenting. And great points. 1174:. And needless to say, the project suffers. 291:That, I think, falls under misbehaviour. - 1224:Is there a need for a process, other than 2808:I have some concerns about this process: 2615:RfA to possibly stand for the process. - 2332:process I have proposed. How it differs: 1326:in definition) should be able to certify. 190:weight than "anyone can propose an RRA". 170:of sorts. The idea is to try to minimise 2880:Arbcom doesn't have to review all cases. 2572:Please link to the German WP process? - 1003:Indeed, this feels about right to me. -- 928: 677: 1246:) rather than an entirely new process. 2308:and supported by 16 users. Regards. — 1060:the incidents noticeboard at its worst 232:Arbcom is at the top of the community 114:reduce creating additional bureaucracy 2298:request for revalidation of adminship 1659:different than CDA (as I read it). - 1251:Would the proposed process impose an 43: 2921:close call to want to "try again". 13: 2902:Would there be any provisions for 14: 2968: 2541:In an era where we are trying to 2359:Otherwise, it looks very similar. 1773: 267:Request for administrator review 20: 2551:in the last five years combined 1599:User:TenOfAllTrades/CDAresponse 1253:excessive administrative burden 2206: 2200: 2135: 2129: 2065:Restoring adminship by default 1955: 1949: 1887: 1881: 1528:And here's one from Kent Law: 1199:But as I said, above, YMMV. - 1196:I find that arguement un-wiki. 408:responsibilities of adminship. 1: 2955:20:31, 12 December 2015 (UTC) 2891:20:31, 12 December 2015 (UTC) 2798:20:31, 12 December 2015 (UTC) 2742:20:31, 12 December 2015 (UTC) 1743:04:35, 15 December 2012 (UTC) 1707:03:57, 15 December 2012 (UTC) 1666:20:12, 12 November 2012 (UTC) 1632:21:21, 11 November 2012 (UTC) 1540:15:45, 10 November 2012 (UTC) 1514:10:54, 10 November 2012 (UTC) 1290:The number of administrators 1238:) suggests that many editors 1042:Potentially toxic environment 2930:09:35, 27 October 2015 (UTC) 2865:20:48, 26 October 2015 (UTC) 2840:20:42, 26 October 2015 (UTC) 2770:20:15, 26 October 2015 (UTC) 2726:18:55, 26 October 2015 (UTC) 2708:18:53, 26 October 2015 (UTC) 2677:18:07, 26 October 2015 (UTC) 2662:17:36, 26 October 2015 (UTC) 2646:16:56, 26 October 2015 (UTC) 2622:14:56, 26 October 2015 (UTC) 2579:14:32, 26 October 2015 (UTC) 2567:13:48, 26 October 2015 (UTC) 2520:21:46, 26 October 2015 (UTC) 2505:14:32, 26 October 2015 (UTC) 2486:09:10, 26 October 2015 (UTC) 2463:05:16, 26 October 2015 (UTC) 2421:05:06, 26 October 2015 (UTC) 2385:09:23, 27 October 2015 (UTC) 2372:23:12, 25 January 2013 (UTC) 2328:This is very similar to the 2323:22:29, 25 January 2013 (UTC) 2247:05:06, 26 October 2015 (UTC) 2236:21:52, 25 January 2013 (UTC) 2212:02:54, 21 January 2013 (UTC) 2193:03:55, 20 January 2013 (UTC) 2173:21:52, 25 January 2013 (UTC) 2158:10:33, 18 January 2013 (UTC) 2141:19:40, 17 January 2013 (UTC) 2122:11:43, 17 January 2013 (UTC) 2110:05:04, 15 January 2013 (UTC) 2080:19:37, 11 January 2013 (UTC) 2051:20:26, 26 October 2015 (UTC) 2037:21:52, 25 January 2013 (UTC) 2019:03:26, 15 January 2013 (UTC) 1992:19:22, 13 January 2013 (UTC) 1979:09:15, 13 January 2013 (UTC) 1961:00:19, 11 January 2013 (UTC) 1941:19:25, 10 January 2013 (UTC) 1921:21:52, 25 January 2013 (UTC) 1909:16:23, 10 January 2013 (UTC) 1893:02:56, 10 January 2013 (UTC) 1873:02:24, 10 January 2013 (UTC) 1848:21:52, 25 January 2013 (UTC) 1833:10:30, 18 January 2013 (UTC) 1815:01:01, 10 January 2013 (UTC) 1793:18:48, 10 January 2013 (UTC) 1584:05:06, 26 October 2015 (UTC) 1570:21:52, 25 January 2013 (UTC) 1488:14:56, 9 November 2012 (UTC) 1472:10:44, 9 November 2012 (UTC) 1444:06:58, 19 October 2012 (UTC) 1417:03:36, 19 October 2012 (UTC) 1375:23:51, 17 October 2012 (UTC) 1313:20:44, 17 October 2012 (UTC) 1276:potentially toxic atmosphere 1037:05:06, 26 October 2015 (UTC) 1021:16:46, 21 January 2013 (UTC) 1010:02:49, 16 January 2013 (UTC) 999:19:19, 13 January 2013 (UTC) 849:23:16, 21 January 2013 (UTC) 7: 2553:. I.e., extremely unlikely. 2162:In that case, arbcom would 1767:14:03, 9 January 2013 (UTC) 1559:21:05, 9 January 2013 (UTC) 1206:23:55, 15 August 2012 (UTC) 963:(etc) template appreciated. 904:(etc) template appreciated. 791:(etc) template appreciated. 712:malfeasance, as opposed to 116:, and also to minimise any 10: 2973: 2410:04:06, 26 March 2013 (UTC) 2296:is currently undergoing a 1595:failed de-adminship scheme 1151:19:53, 6 August 2012 (UTC) 1115:09:01, 4 August 2012 (UTC) 1096:13:40, 2 August 2012 (UTC) 1081:06:21, 2 August 2012 (UTC) 985:13:38, 2 August 2012 (UTC) 966:16:53, 1 August 2012 (UTC) 935:16:30, 1 August 2012 (UTC) 921:13:59, 1 August 2012 (UTC) 907:13:41, 1 August 2012 (UTC) 879:12:38, 1 August 2012 (UTC) 833:17:13, 2 August 2012 (UTC) 817:13:38, 2 August 2012 (UTC) 794:12:31, 2 August 2012 (UTC) 764:10:40, 2 August 2012 (UTC) 745:20:38, 1 August 2012 (UTC) 684:16:46, 1 August 2012 (UTC) 662:12:21, 1 August 2012 (UTC) 640:09:08, 1 August 2012 (UTC) 615:08:34, 1 August 2012 (UTC) 501:Centralize this discussion 2471:A thought on the proposal 2452:18:59, 29 July 2013 (UTC) 2440:18:23, 29 July 2013 (UTC) 1749:Why has this been locked? 1589:Not learning from history 1492:Perhaps you're right. On 588:14:48, 31 July 2012 (UTC) 566:05:01, 31 July 2012 (UTC) 554:04:46, 31 July 2012 (UTC) 536:04:40, 31 July 2012 (UTC) 516:04:26, 31 July 2012 (UTC) 471:01:08, 31 July 2012 (UTC) 459:01:01, 31 July 2012 (UTC) 444:00:54, 31 July 2012 (UTC) 433:00:45, 31 July 2012 (UTC) 418:00:40, 31 July 2012 (UTC) 403:00:37, 31 July 2012 (UTC) 383:00:26, 31 July 2012 (UTC) 369:00:20, 31 July 2012 (UTC) 338:00:17, 31 July 2012 (UTC) 323:00:02, 31 July 2012 (UTC) 312:00:00, 31 July 2012 (UTC) 298:23:56, 30 July 2012 (UTC) 284:23:25, 30 July 2012 (UTC) 92:21:19, 30 July 2012 (UTC) 50:Skip to table of contents 159:(a link to a section of 49: 2528:Unintended consequences 1927:Administrator approval? 696:, although it is still 673:not being a bureaucracy 525:I wrote at WT:RFA (per 2911:statute of limitations 2847:Well, the quorum rule 2583:Nevermind, I found it 527:the discussions there 523:the original proposal 108:The process explained 2819:handled with ArbCom 2785:, but because they 2426:Still "in process"? 1226:binding arbitration 2853:urgent resolutions 2282:very good standing 1302:per administrator. 42: 2909:Would there be a 2706: 2304:by administrator 2270:Spanish Knowledge 2263: 2107: 1818: 1741: 1705: 1611:in just four days 1056:user conduct RfCs 964: 905: 792: 635: 254: 253: 94: 55: 54: 41: 40: 15: 2964: 2925: 2836: 2767: 2763: 2758: 2748:Lack of benefits 2696: 2691: 2380: 2320: 2314: 2274:in good standing 2259:Cross-posted at 2258: 2208: 2202: 2137: 2131: 2106: 2101: 2098: 2072:TotientDragooned 2046: 1957: 1951: 1889: 1883: 1813: 1790: 1781: 1777: 1776: 1764: 1759: 1738: 1732: 1725: 1722: 1717: 1702: 1696: 1689: 1686: 1681: 1511: 1506: 1469: 1464: 1077: 1071: 1067: 959: 932: 900: 876: 872: 867: 787: 681: 659: 655: 650: 636: 631: 626: 411:Nothing else. - 226:User:Jimbo Wales 101: 100: 87: 62:My thoughts here 44: 24: 17: 16: 2972: 2971: 2967: 2966: 2965: 2963: 2962: 2961: 2923: 2904:double jeopardy 2899: 2897:Double jeopardy 2834: 2806: 2765: 2761: 2756: 2750: 2685: 2530: 2473: 2428: 2395: 2378: 2317: 2310: 2254: 2198:Amen to that. — 2150:Graeme Bartlett 2102: 2095: 2091: 2087: 2067: 2044: 1929: 1858: 1825:Graeme Bartlett 1801: 1788: 1774: 1772: 1762: 1755: 1751: 1736: 1728: 1718: 1715: 1700: 1692: 1682: 1679: 1674: 1591: 1551:Graeme Bartlett 1509: 1502: 1467: 1460: 1456: 1337:double jeopardy 1216: 1075: 1069: 1065: 1044: 874: 870: 865: 859: 657: 653: 648: 630: 622: 595: 578: 503: 259: 222: 209: 196: 154: 134: 110: 12: 11: 5: 2970: 2960: 2959: 2958: 2957: 2945: 2942: 2939: 2918: 2917: 2914: 2907: 2898: 2895: 2894: 2893: 2881: 2878: 2870: 2869: 2868: 2867: 2829: 2828: 2816: 2813: 2805: 2802: 2801: 2800: 2776: 2749: 2746: 2745: 2744: 2733: 2711: 2710: 2681: 2680: 2679: 2653: 2629: 2628: 2627: 2626: 2625: 2624: 2612: 2605: 2598: 2591: 2588: 2555: 2554: 2546: 2539: 2529: 2526: 2525: 2524: 2523: 2522: 2516:crack... thump 2496: 2492: 2482:crack... thump 2472: 2469: 2468: 2467: 2466: 2465: 2427: 2424: 2394: 2391: 2390: 2389: 2388: 2387: 2361: 2360: 2356: 2355: 2354: 2353: 2350: 2347: 2342:It just takes 2340: 2337: 2266: 2265: 2253: 2250: 2215: 2214: 2180: 2179: 2178: 2177: 2176: 2175: 2145: 2144: 2143: 2093: 2089: 2066: 2063: 2062: 2061: 2060: 2059: 2058: 2057: 2056: 2055: 2054: 2053: 2039: 1999: 1998: 1997: 1996: 1995: 1994: 1967: 1928: 1925: 1924: 1923: 1896: 1895: 1857: 1854: 1853: 1852: 1851: 1850: 1819: 1800: 1797: 1796: 1795: 1750: 1747: 1746: 1745: 1673: 1672:I support this 1670: 1669: 1668: 1653: 1650: 1641: 1638: 1624:TenOfAllTrades 1590: 1587: 1575: 1574: 1573: 1572: 1546: 1545: 1544: 1543: 1542: 1531: 1526: 1523:an OED article 1519: 1455: 1452: 1451: 1450: 1449: 1448: 1447: 1446: 1435: 1431: 1405: 1404: 1403: 1402: 1394: 1387: 1386: 1385: 1384: 1378: 1377: 1365: 1364: 1352: 1351: 1346: 1345: 1333: 1330: 1327: 1323: 1319: 1304: 1303: 1288: 1284: 1272: 1271: 1258: 1257: 1231: 1230: 1215: 1212: 1211: 1210: 1209: 1208: 1197: 1194: 1190: 1189: 1188: 1179: 1175: 1167: 1163: 1141: 1140: 1136: 1132: 1128: 1120: 1119: 1118: 1117: 1099: 1098: 1087: 1043: 1040: 1028: 1027: 1026: 1025: 1024: 1023: 975: 974: 973: 972: 971: 970: 969: 968: 858: 855: 854: 853: 852: 851: 807: 806: 805: 804: 803: 802: 801: 800: 799: 798: 797: 796: 752: 729:instead of on 594: 591: 577: 574: 573: 572: 571: 570: 569: 568: 539: 538: 502: 499: 498: 497: 496: 495: 494: 493: 492: 491: 490: 489: 488: 487: 486: 485: 484: 483: 482: 481: 480: 479: 478: 477: 476: 475: 474: 473: 409: 393: 389: 349: 348: 347: 346: 345: 344: 343: 342: 341: 340: 272: 271: 258: 255: 252: 251: 242:as a committee 221: 218: 208: 205: 195: 192: 153: 150: 133: 130: 118:learning curve 109: 106: 104: 97: 96: 53: 52: 47: 39: 38: 37: 36: 25: 9: 6: 4: 3: 2: 2969: 2956: 2953: 2952: 2946: 2943: 2940: 2936: 2935: 2934: 2933: 2932: 2931: 2928: 2926: 2915: 2912: 2908: 2905: 2901: 2900: 2892: 2889: 2888: 2882: 2879: 2876: 2872: 2871: 2866: 2862: 2858: 2854: 2850: 2846: 2845: 2844: 2843: 2842: 2841: 2838: 2837: 2835:Esquivalience 2826: 2822: 2817: 2814: 2811: 2810: 2809: 2804:Some concerns 2799: 2796: 2795: 2790: 2789: 2784: 2783: 2777: 2774: 2773: 2772: 2771: 2768: 2764: 2759: 2743: 2740: 2739: 2734: 2730: 2729: 2728: 2727: 2723: 2719: 2709: 2704: 2700: 2695: 2689: 2682: 2678: 2674: 2670: 2665: 2664: 2663: 2660: 2659: 2654: 2650: 2649: 2648: 2647: 2643: 2639: 2635: 2623: 2620: 2619: 2613: 2610: 2606: 2602: 2601: 2599: 2596: 2592: 2589: 2586: 2582: 2581: 2580: 2577: 2576: 2571: 2570: 2569: 2568: 2564: 2560: 2552: 2547: 2544: 2540: 2536: 2535: 2534: 2521: 2517: 2513: 2508: 2507: 2506: 2503: 2502: 2497: 2493: 2490: 2489: 2488: 2487: 2483: 2479: 2464: 2461: 2460: 2455: 2454: 2453: 2450: 2449: 2444: 2443: 2442: 2441: 2437: 2433: 2432:69.125.134.86 2423: 2422: 2419: 2418: 2412: 2411: 2407: 2403: 2402: 2386: 2383: 2381: 2375: 2374: 2373: 2370: 2369: 2363: 2362: 2358: 2357: 2351: 2348: 2345: 2341: 2338: 2334: 2333: 2331: 2327: 2326: 2325: 2324: 2321: 2319: 2315: 2313: 2307: 2303: 2299: 2295: 2289: 2287: 2286:good standing 2283: 2278: 2275: 2271: 2264: 2262: 2256: 2255: 2249: 2248: 2245: 2244: 2238: 2237: 2234: 2233: 2226: 2224: 2220: 2213: 2209: 2203: 2197: 2196: 2195: 2194: 2190: 2186: 2174: 2171: 2170: 2165: 2161: 2160: 2159: 2155: 2151: 2146: 2142: 2138: 2132: 2125: 2124: 2123: 2120: 2117: 2113: 2112: 2111: 2108: 2105: 2099: 2097: 2084: 2083: 2082: 2081: 2077: 2073: 2052: 2049: 2047: 2040: 2038: 2035: 2034: 2029: 2028: 2022: 2021: 2020: 2016: 2012: 2007: 2006: 2005: 2004: 2003: 2002: 2001: 2000: 1993: 1990: 1987: 1982: 1981: 1980: 1976: 1972: 1968: 1964: 1963: 1962: 1958: 1952: 1945: 1944: 1943: 1942: 1938: 1934: 1922: 1919: 1918: 1913: 1912: 1911: 1910: 1906: 1902: 1894: 1890: 1884: 1877: 1876: 1875: 1874: 1870: 1866: 1865: 1856:Supermajority 1849: 1846: 1845: 1840: 1836: 1835: 1834: 1830: 1826: 1822: 1821: 1820: 1816: 1811: 1810: 1807: 1799:Certification 1794: 1791: 1785: 1782:Unprotected. 1780: 1771: 1770: 1769: 1768: 1765: 1760: 1758: 1744: 1739: 1733: 1731: 1724: 1723: 1721: 1711: 1710: 1709: 1708: 1703: 1697: 1695: 1688: 1687: 1685: 1667: 1664: 1663: 1658: 1654: 1651: 1648: 1647: 1642: 1639: 1636: 1635: 1634: 1633: 1629: 1625: 1619: 1617: 1612: 1606: 1602: 1600: 1596: 1586: 1585: 1582: 1581: 1571: 1568: 1567: 1562: 1561: 1560: 1556: 1552: 1547: 1541: 1538: 1537: 1532: 1530: 1527: 1524: 1520: 1517: 1516: 1515: 1512: 1507: 1505: 1499: 1495: 1491: 1490: 1489: 1486: 1485: 1480: 1476: 1475: 1474: 1473: 1470: 1465: 1463: 1445: 1442: 1441: 1436: 1432: 1429: 1424: 1420: 1419: 1418: 1415: 1414: 1409: 1408: 1407: 1406: 1400: 1395: 1391: 1390: 1389: 1388: 1382: 1381: 1380: 1379: 1376: 1373: 1372: 1367: 1366: 1362: 1358: 1354: 1353: 1348: 1347: 1344:RRA requests. 1342: 1338: 1334: 1331: 1328: 1324: 1320: 1317: 1316: 1315: 1314: 1311: 1310: 1301: 1297: 1293: 1289: 1285: 1281: 1280: 1279: 1277: 1270: 1267: 1266: 1265: 1263: 1256: 1254: 1249: 1248: 1247: 1245: 1241: 1237: 1229: 1227: 1222: 1221: 1220: 1207: 1204: 1203: 1198: 1195: 1191: 1185: 1180: 1176: 1173: 1168: 1164: 1160: 1159: 1157: 1156: 1155: 1154: 1153: 1152: 1149: 1145: 1144:The Uninvited 1137: 1133: 1129: 1126: 1125: 1124: 1116: 1112: 1108: 1103: 1102: 1101: 1100: 1097: 1094: 1093: 1088: 1085: 1084: 1083: 1082: 1078: 1072: 1068: 1061: 1057: 1053: 1049: 1039: 1038: 1035: 1034: 1022: 1019: 1017: 1013: 1012: 1011: 1008: 1006: 1002: 1001: 1000: 997: 994: 989: 988: 987: 986: 983: 982: 967: 962: 957: 953: 949: 948: 942: 938: 937: 936: 933: 931: 924: 923: 922: 918: 914: 910: 909: 908: 903: 898: 894: 890: 889: 883: 882: 881: 880: 877: 873: 868: 850: 847: 844: 841: 836: 835: 834: 830: 826: 825:Beyond My Ken 821: 820: 819: 818: 815: 814: 795: 790: 785: 781: 777: 776: 771: 767: 766: 765: 762: 761: 760: 753: 749: 748: 747: 746: 742: 738: 737:Beyond My Ken 734: 733: 728: 727: 720: 717: 716: 715:extraordinary 711: 710: 703: 701: 700: 695: 694: 687: 686: 685: 682: 680: 674: 670: 665: 664: 663: 660: 656: 651: 643: 642: 641: 637: 634: 627: 625: 619: 618: 617: 616: 612: 608: 607:Beyond My Ken 603: 599: 590: 589: 586: 583: 582:Burpelson AFB 567: 564: 563: 557: 556: 555: 551: 547: 543: 542: 541: 540: 537: 534: 533: 528: 524: 520: 519: 518: 517: 513: 509: 472: 469: 468: 462: 461: 460: 456: 452: 447: 446: 445: 442: 441: 436: 435: 434: 430: 426: 421: 420: 419: 416: 415: 410: 406: 405: 404: 401: 400: 394: 390: 386: 385: 384: 380: 376: 372: 371: 370: 367: 366: 361: 360: 359: 358: 357: 356: 355: 354: 353: 352: 351: 350: 339: 335: 331: 326: 325: 324: 321: 320: 315: 314: 313: 309: 305: 301: 300: 299: 296: 295: 290: 289: 288: 287: 286: 285: 281: 277: 268: 265: 264: 263: 250: 246: 244: 243: 237: 235: 230: 227: 217: 213: 204: 200: 191: 188: 183: 179: 177: 173: 169: 164: 162: 158: 149: 145: 143: 139: 129: 125: 121: 119: 115: 105: 103: 102: 99: 95: 93: 90: 85: 83: 79: 75: 71: 67: 63: 57: 56: 51: 48: 46: 45: 34: 33: 28: 27: 26: 23: 19: 18: 2949: 2919: 2885: 2874: 2848: 2832: 2830: 2807: 2792: 2787: 2786: 2781: 2780: 2754: 2751: 2736: 2712: 2656: 2630: 2616: 2608: 2573: 2556: 2550: 2542: 2531: 2512:Peacemaker67 2499: 2478:Peacemaker67 2474: 2457: 2446: 2429: 2415: 2413: 2399: 2396: 2393:Arb com role 2366: 2343: 2336:interesting. 2318: 2311: 2290: 2285: 2281: 2279: 2273: 2267: 2257: 2241: 2239: 2230: 2227: 2222: 2218: 2216: 2181: 2167: 2163: 2103: 2088: 2068: 2031: 2026: 2025: 1930: 1915: 1897: 1862: 1859: 1842: 1804: 1802: 1778: 1756: 1752: 1729: 1719: 1714: 1693: 1683: 1678: 1675: 1660: 1657:dramatically 1656: 1645: 1644: 1620: 1615: 1610: 1607: 1603: 1592: 1578: 1576: 1564: 1534: 1503: 1497: 1493: 1482: 1461: 1457: 1438: 1422: 1413:Black Falcon 1411: 1398: 1369: 1360: 1340: 1309:Black Falcon 1307: 1305: 1299: 1292:is declining 1273: 1268: 1259: 1250: 1239: 1232: 1223: 1217: 1200: 1142: 1121: 1090: 1064: 1051: 1045: 1031: 1029: 979: 976: 945: 940: 929: 886: 863: 860: 811: 808: 773: 758: 756: 731: 730: 725: 724: 721: 714: 713: 708: 707: 704: 698: 697: 692: 691: 689: 678: 646: 632: 623: 604: 600: 596: 579: 560: 530: 504: 465: 438: 412: 397: 363: 317: 292: 273: 266: 260: 247: 245:per policy. 241: 240: 238: 231: 223: 214: 210: 201: 197: 186: 184: 180: 168:safety valve 165: 157:WP:RFC/Admin 155: 146: 142:WP:RFC/Admin 135: 126: 122: 111: 98: 59: 58: 32:the proposal 30: 2851:applies to 2652:difference. 1399:alternative 1350:incivility. 1066:Master& 768:Agree with 593:Term limits 2857:Hammersoft 2718:Hammersoft 2559:Hammersoft 2300:which was 2119:Od Mishehu 2011:Beeblebrox 1989:Od Mishehu 1809:Farmbrough 1322:adminship. 1016:j⚛e decker 1005:j⚛e decker 996:Od Mishehu 699:supposedly 546:Shadowjams 388:consensus. 194:Discussion 185:And note: 176:witchhunts 172:lynch mobs 152:Nomination 2595:Justavote 2306:Phoenix58 2302:requested 2294:Ganímedes 2116:עוד מישהו 1986:עוד מישהו 1901:Everyking 1720:Strikeout 1716:Automatic 1684:Strikeout 1680:Automatic 1616:shouldn't 993:עוד מישהו 947:Callanecc 939:Or after 888:Callanecc 775:Callanecc 719:ordinary. 270:policies. 29:See also 2825:Level II 2766:Chequers 2699:contribs 2543:increase 2538:removed? 2344:at least 2201:Rutebega 2185:Cenarium 2130:Rutebega 2085:Agreed! 2027:at least 1950:Rutebega 1882:Rutebega 1193:request. 1139:machine? 961:talkback 956:contribs 902:talkback 897:contribs 875:Chequers 789:talkback 784:contribs 709:ordinary 658:Chequers 602:applied. 161:WP:RFC/U 132:Overview 2938:always. 2821:Level I 2268:On the 2223:desysop 2096:anguard 1971:ElKevbo 1933:ElKevbo 1763:(talk) 1521:Here's 1510:(talk) 1468:(talk) 1454:Comment 1423:needing 1107:Michael 770:Hut 8.5 759:Hut 8.5 732:removal 726:renewal 693:in fact 633:talk me 624:Anbu121 576:Finally 392:Arbcom. 207:Closure 199:close. 138:WP:AN/I 2694:IJBall 2669:isaacl 2638:isaacl 2330:WP:RRA 2261:WT:RFA 1839:WT:RFA 1784:Ruslik 1357:WP:3PO 1262:WP:RFA 1244:WP:RFA 1070:Expert 930:Cailil 913:isaacl 857:Timing 679:Cailil 508:Risker 451:isaacl 425:isaacl 375:isaacl 330:isaacl 304:isaacl 276:isaacl 220:Review 76:, and 64:, and 2788:could 2762:Spiel 2406:talk 2164:never 1869:talk 1494:which 1428:WP:DR 1184:WP:DR 1172:WP:DR 1146:Co., 1052:wrong 871:Spiel 654:Spiel 234:WP:DR 2951:jc37 2924:Mkdw 2887:jc37 2875:also 2861:talk 2849:only 2794:jc37 2791:. - 2782:will 2757:Ϣere 2738:jc37 2722:talk 2703:talk 2688:Jc37 2673:talk 2658:jc37 2642:talk 2618:jc37 2609:good 2585:here 2575:jc37 2563:talk 2501:jc37 2495:RFA. 2459:jc37 2448:jc37 2436:talk 2417:jc37 2379:Mkdw 2368:jc37 2243:jc37 2232:jc37 2207:talk 2189:talk 2169:jc37 2154:talk 2136:talk 2104:Wha? 2092:ven 2076:talk 2045:Mkdw 2033:jc37 2015:talk 1975:talk 1956:talk 1937:talk 1917:jc37 1905:talk 1888:talk 1844:jc37 1829:talk 1806:Rich 1789:Zero 1779:Done 1757:Tony 1662:jc37 1628:talk 1580:jc37 1566:jc37 1555:talk 1536:jc37 1504:Tony 1498:that 1496:and 1484:jc37 1481:. - 1462:Tony 1440:jc37 1393:RRA. 1371:jc37 1361:also 1300:once 1236:here 1202:jc37 1148:Inc. 1111:talk 1092:jc37 1076:Talk 1033:jc37 981:jc37 952:talk 917:talk 893:talk 866:Ϣere 829:talk 813:jc37 780:talk 741:talk 671:and 649:Ϣere 611:talk 562:jc37 550:talk 532:jc37 512:talk 467:jc37 455:talk 440:jc37 429:talk 414:jc37 399:jc37 379:talk 365:jc37 334:talk 319:jc37 308:talk 294:jc37 280:talk 89:jc37 82:here 78:this 74:this 70:this 66:this 2401:DGG 2312:ΛΧΣ 2219:ban 1864:DGG 1646:ban 1341:and 1058:or 1048:RfA 140:or 2863:) 2831:- 2724:) 2701:• 2675:) 2644:) 2565:) 2518:) 2484:) 2438:) 2408:) 2210:) 2191:) 2156:) 2139:) 2078:) 2017:) 1977:) 1959:) 1939:) 1907:) 1891:) 1871:) 1831:) 1812:, 1734:• 1698:• 1630:) 1557:) 1240:do 1113:) 1079:) 958:) 954:• 919:) 899:) 895:• 846:ka 843:on 840:El 831:) 786:) 782:• 743:) 735:. 675:-- 638:) 613:) 552:) 514:) 457:) 431:) 381:) 336:) 310:) 282:) 120:. 86:- 72:, 68:, 2859:( 2720:( 2705:) 2697:( 2690:: 2686:@ 2671:( 2640:( 2587:. 2561:( 2514:( 2480:( 2434:( 2404:( 2204:( 2187:( 2152:( 2133:( 2127:— 2094:M 2090:S 2074:( 2013:( 1973:( 1953:( 1935:( 1903:( 1885:( 1867:( 1827:( 1817:. 1786:_ 1740:) 1737:C 1730:T 1726:( 1704:) 1701:C 1694:T 1690:( 1626:( 1553:( 1525:. 1255:? 1109:( 1073:( 950:( 941:x 915:( 891:( 827:( 778:( 739:( 628:( 609:( 585:✈ 548:( 510:( 453:( 427:( 377:( 332:( 306:( 278:( 84:. 35:.

Index


the proposal
Skip to table of contents
My thoughts here
this
this
this
this
here
jc37
21:19, 30 July 2012 (UTC)
reduce creating additional bureaucracy
learning curve
WP:AN/I
WP:RFC/Admin
WP:RFC/Admin
WP:RFC/U
safety valve
lynch mobs
witchhunts
User:Jimbo Wales
WP:DR
isaacl
talk
23:25, 30 July 2012 (UTC)
jc37
23:56, 30 July 2012 (UTC)
isaacl
talk
00:00, 31 July 2012 (UTC)

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