600:'s account were compromised and actually used for anything, Bryan would notice. Anonymous accounts where the user has never made their real identity public, and where the user is no longer familiar to Wikipedians, pose the greatest risk because even if suspicions were aroused there would be no way to determine whether the account was in control of its original owner or not. Finally, I note that Knowledge itself, its adminship standards, and its public profile have changed dramatically in the last couple of years, and some of the people who have had extended absences may no longer make suitable admins for these reasons.
133:
something like a 85-90% consensus and a trial run. I don't really believe blackmail will be an issue, because users who use that as blackmail will lose all credibility, and the user getting blackmailed will easily overturn the nomination for de-adminship, earning himself some pseudo-martyr points with the community. I think we should try this proposal out with a high consensus percentage. Let's all remember that Jimbo Wales' opinion on the matter is just that...it's not divine word. He's a computer programmer, not a social psychologist...unless he is one of those, then I'm just an idiot.
943:. That you do not like this may be true, but that it cannot happen is not. That it may never happen may also be true, but that does not preclude the possibility that it could. This is not policy creep, I would argue instead that it is policy creep to remove it, since there is no policy which dictates we cannot do this if there is a consensus to do it. It's not clear that "the dispute resolution system ending with the arbcom is the mechanism for such requests", since we have a category of admins open to recall, and we also have Jimbo desysopping and we also have RFC's on admins.
1448:(Full disclosure -- I'm an admin). I don't see a cause for concern that an editor who is ticked that I deleted his page extolling the virtues of pooooooop will get 10 meat puppets and start a de-admin request just to harass me. (Well, they can try, but I'd be surprised if they got far.) The process looks like it could deal with the worst cases. And it looks like it could get some community support. (The best proposal in the world isn't worth much if it never gets implemented. *grin*) It seems like a good first step, and hopefully we'll be prepared to go further if needed.--
1176:...we could certainly have a five year term no problems, and a four year term would hold no problems either. A three year term would be manageable, we'd have a hurried start, but it's doable. We could deadmin the first day of the month following the month an admin was created. It looks workable, and it might be needed to make RFA workable again. We have to return to the fact that adminship is no big deal. It should be within any editor's grasp but the very worst, those that an argument against is mounted on behavioural issues rather than any given random criteria.
1340:}} tag from this page. Although the concept of a "requests for de-adminship" page is historical, the sections on desysopping cases are still being updated. The last one was in July, but I can't think of any cases since then. In that sense, it's still being watched and edited, and is thus not historical. More than a year ago I brought up the idea of moving this page to "Knowledge:De-adminship", but nothing came of it. Maybe we should give that a try, to mitigate any confusion about its "historical" status.
148:
930:. It's merely your POV that only arb-com can do it. It's quite clear that there is no consensus for a de-admin procedure, but it's not correct to say that the community can't de-admin someone. If an admin went rogue and protected every single page and deleted all images and made the main page a gallery of porn, I'd think we'd pretty quickly bypass arb-com and head straight for the nearest steward.
2015:
sufferers. Additional administration (eventuel censorship) as a serious problem for Wiki User's. What to do with the administration
Knowledge.org (eg) illegal migrants from Africa and mogametanischen Narco Band's? They have set up its own Internet Survilance (incl. Survilance Knowledge.org). That's not the problem in the States without a political crisis or held in the framework of Islam.
153:
1766:. It's conservative enough that abusive requests for de-adminship seem very unlikely to succeed. The biggest worry is in cases like the recent (alleged) mailing list used to coordinate Eastern European editors. But then, the risk is no greater than having such coordinated groups vote in their own "pocket" admins...
2257:
the last proposal failed. Even if you are minded to ignore arguments by admins, there were plenty of non admins who pointed out flaws in the proposal. Simply dismissing the consensus view as ridiculous might leave some people thinking that you aren't engaging with those arguments, let alone rebutting them.
957:. The mechanism I described in my addition to the page is a mechanism which can be used, and I would like to see it added back. It's in the right section and it describes the process. I don't tend to edit war, but this is going to need more than the fact that you don't like it to convince me it's wrong.
1713:
Just a question out of principle, should there be a wording regarding the timeframe? An admin who makes the same controversial actions in a short timespan is probably a pattern. One who does it four time over 5 years, not so much. Not angling for a formal codification on this but a "use common sense"
1525:
Looks good to me. It contains some strong safeguards against harassment via abusive RfDAs, and the high percentage required to desysop will make it an efficient system for removing genuinely abusive admins that have lost all community trust - while leaving an ArbCom case still the correct venue for a
1310:
I just came across the summary on this page of my desysopping incident, which was seriously slanted and partially false. This is a pretty high-visibility page, so who knows how many people were influenced in their perceptions of me by that summary? I propose that in the future desysopped users should
1200:
You have made a leap of logic here which caused me to go "Huh?" at first. If I understand your argument correctly, the reason that fixed terms would "make RFA workable again" is that RFA voters could be less stringent knowing that, in the worst case, the admin in question would be up for re-election
1920:
Also, would it be prudent to direct the admin against use of admin tools whilst they have a claim open (ie once it's past the point of certification) -- or atleast the tools in relation to where the alleged abuse took place, e.g. deletion, etc? Again, these are just my thoughts on the wording as is.
1734:
The proposal mentions the lack of a "robust desysopping process". The implication seems to be that there are admins out there who should not have the bit, but are not being desysopped under the current arbitration process. Do the proposers have anyone in mind that they would submit to this process?
849:
These are kinda abstruse points. I think some understand the various levels of subtlety involved; some confuse a few things. When I put in the line about stewards, I simply wanted the section to reflect the actual truth of the technical power structure around here. This information is probably of no
576:
I think if any kind of unathorized activities started to take place, it would be pretty easily recognized and could be dealt with. If a long inactive user suddenly reappears and begins doing odd things, we can de-sysop in such circumstances quite easily, I'd imagine. There's no particular need for
82:
I listed her in a different section because she was banned, not de-sysoped. Since there are many other users who have been banned for one reason or another, it isn't entirely clear that she belongs here at all. However, since one could argue that banning a sysop implies de-sysoping them as well, I
1559:
process :) which, while more bulletproof, is less suitable as a general process) as a start point, so that's goodness. I remain unkeen on mandatory recall processes in general, but this is better than most processes that come down the pike, it's probably even one that, while not supporting, I would
966:
I've done my part, I've sourced my info and I've read the rules and I've engaged in discussion on this issue all over
Knowledge and on the mailing list. It has been made clear to me that it has always been the case that this method is open to the community if they want to use it. That we don't is
952:
It may be true that there is a dispute resolution system ending with the arbcom, who have the power to desysop, but it has also been made clear that the community has the power too but chooses not to exercise it. At no point have I seen the community dictate it will never desysop through the above
730:
I am very sensitive to policy creep in this area. While the stewards have acted upon requests from other projects, the
English Knowledge has never in the history of the project permitted this by policy let alone actually conducted such a process successfully. In all the cases of which I am aware,
2256:
The vote wasn't limited to admins, not that there are as many admins around these days. If you want to restart the debate and try to get a different result you could open a new RFC on it. But I'd suggest reading the arguments and trying to modify the proposal to accommodate some of the reasons why
1782:
I think that
Chillum makes a good point about sticking to policy. I'd also like to see the provision somewhere that a person being put up for de-admin. could have the right to reject who closes - kind of like they have alternates for jury duty. (I'm hesitant to phrase it quite that way .. I think
1748:
I would far prefer if desysoping was handled through consideration of evidence as applied to policy(like we already do) rather than a big vote. Admins need to make unpopular decisions sometimes and unless evidence shows they have violated policy or community norms then I don't think they should be
1134:
If an administrator carries out a willfully coarse act, they probably will lose their admin's-cap through sanction of the arbitration committee, when it meets. Before that point, distrusting community members can petition for an admin's removal. In both cases, the process risks to create prolonged
987:
And I want to make it clear I too can't square the circle of how to make de-admin requests civil, but I'd point out that not making the effort because of that fact implies a lack of good faith. I include myself amongst those who start from a position of no faith. But just because we can't see it
886:
To request the another user's de-adminship, please gain consensus on your own wiki first. All discussion must be kept on your local wiki. When it is finished and there exists community consensus that the user should be de-adminned, a trusted person from that wiki should just provide a link here to
807:
From a political point of view, this is a perfectly sensible statement. Yelling at
Stewards when you want somebody deadminned is just plain stupid; they're not going to listen. Nor do we really want to provoke people into thinking this is a route, so I had reservations about making the edit in the
550:
While administering many other Wiki sites, some sites desysop admins for long (such as one year) inactivity. Security concerns have been raised should abandoned admin accounts get broken in by unauthorized users to misuse and abuse admins' privileges. Why not bother with those who are inactive for
2014:
Interests conflicts between wiki
Admionistratoren, Conditions Knowledge.org and the various administrations, state services as elite power. This find Wiki Admin's and Knowledge administration as insufficient. Neither political nor religious angagiert for one or other State / authority or a polio
1916:
I'm unclear of what happens once the case is certified and opened. Do we do it RFC or RFA style? I'd hope the latter, as I think once a case is filed and certified we either support removal, oppose removal, or are neutral. Obviously diffs and a brief description by the people bringing the claim,
1666:
It would be a very unusual single admin action that would lead to deadmin, and actions of such wrongness are well handled by arb com. I think it impossible for an active admin to make no mistakes. I've done over eight thousand speedy deletions, and I think I'm exceedingly cautious, but I know of
595:
I agree that inactive admin accounts pose a problem and have suggested systematically removing them in the past. There has been widespread opposition. Inactive accounts pose a unique security problem because if compromosed, their rightful owner is unlikely to notice. On the other hand, if for
680:
In my opinion, what should be done is maybe make a ridiculous time limit of inactivity (2 years would be what I'd do, maybe 3), and if they have made 0 edits in that time, we remove the adminship, but leave a notice that if they want to be reinstated they can be without having to go through the
1424:
I invite commentary from the community as to whether we should adopt this proposal. Obviously I think we should. The general feeling from those who have commented on the talkpage in my userspace is support, with a couple of exceptions. The proposal as it stands is, I think, eminently workable,
1124:
they have term limits for admins; each admin serves for about a year. The "about" part comes because they create new admins continuously but only remove them from office quarterly -- so as to put a neat package before the stewards. I think this is really smart. The driving philosophy is plain
734:
I think that it is important to be clear that the dispute resolution system ending with the arbcom is the mechanism for such requests. The arbcom has demonstrated that it is willing to act on such requests, and has a history of doing so effectively. Accordingly, there is no need to create a
132:
This is an interesting idea at face value, but I think there would need to be a massive consensus to get rid of a user...and only admins can vote. If that is the case, then 99% of the voters are respected members of the community who can be trusted to read into the issue at hand. I reccomend
1135:
conflicts and (spä) on top of what already exists. That already ordained administrators must be appointed again gives instead the community the chance of a more natural way to sort out administrators who don't correctly have confidence in wikicommunity, and that thereby cause excitements.
1625:
The proposal looks good. I had a couple of questions: 1) Scope. Should !voters be considering all of the admin's conduct, or only conduct related to the incident(s) described in the nomination? 2) The list of admin powers at "Grounds for initiating an RFDA" includes minor things like
2217:. To the issue itself; I've reviewed what Nblund and Sandstein did and find nothing sanctionable in their actions. Nevertheless, if you feel motivated enough to do something about this, and your motivation isn't just because you dislike their conclusions, then please do follow
1667:
about two dozen mistakes. Assuming an equal number I don't know about, that's ½ of 1%. I;'ve only done about 100 blocks, but I know 2 or 3 of them were incorrect. Some admins may be better, but none of them are perfect. We need some specific statement about pattern of behavior.
697:
The initial wording, and other instances in the document, need dating: "Throughout the history of the project" means different things when read in 2005, 2006, 2007, 2008, 2020, etc. Readers shouldn't be expected to go to the page history to find out when something was written.
525:
I guess the question is whether someone who is an admin would be willing to sell, and someone else would be willing to buy, the ability to access an account with the admin bit set. Presumably this business opportunity (such as it is) is open to active admins too... --
1356:
A new de-adminship scheme seems to come along about once every three months. These proposals are regularly rejected. As an aid to anyone who would like to draft the next proposal, I've prepared a list of questions that all new proposals ought to be ready to answer:
1225:
At the very least, you'd see admins with agendas behaving more properly and circumspectly in the period leading up to the expiration of their term of adminship. At the worst, it would degenerate into people campaigning against those who were coming up for renewal.
1912:
methods with the admin. Also there should be a time frame for when to raise a grievance (possibly one month from the alleged abuse, unless of course during that month they've been actively in some type of dispute resolution with the admin that ultimately failed).
904:
I limited myself to this little technical note because I don't see how to make RfDA a civil process. I don't mind rotten tomatoes thrown at admins, even in bad faith; our trusted servants must be above such; they must fail to react in bad ways to bad comments. I
1249:
community has found fault with the idea. Other WM communities have adopted it and find it works well. There is considerable pressure on the entire adminship process right now; that's why we're here. Maybe our community is ready to take a fresh look at term
637:
If someone has hacked into an inactive admin account and starts using it to do dubious things, the problem will become apparent very quickly. If they return and are not doing dubious things, we should assume good faith. I don't see what the big deal is.
909:
mind the inevitable cross-bickering and personal attacks that go back and forth from supporters and opponents on RfA and I don't see that it will be any better on RfDA. I won't feel comfortable supporting any RfDA process until this concern is met.
1492:
Looks fine to me too (admin disclaimer per
Fabrictramp). I'm not personally convinced its necessary, but the proposal's perennial nature suggests plenty of other people think it is. And as formal desysop processes go this seems a reasonable one.
1907:
As for my thoughts on the current structure of the procedure, first I believe that the wording needs to be clearer that the user(s) making the complaint should have first attempted legitimate discussion or other recognised
2075:
It seems a little hard to believe that in the past 12 months, only 1 Admin has lost their Admin rights. Is this list up-to-date? Because I've certainly come across several disputes in process about misuse of Admin tools.
1144:
This seems like a sane and rational approach. The Swedes have ArbCom and it works but not always; they may have some sort of RfDA and it causes additional contention; they have term limits and seem pretty happy about it.
577:
a preventative policy - no sysop action is so potentially damaging as to require protecting against it in advance - another admin can always protect/unprotect, block/unblock, or delete/undelete as the situation requires.
1783:
there is already too much "legal role-playing" going on at WP, but for lack of a better term I added it.) While I agree that RFA is often a popularity contest - it shouldn't be. As such, this should not evolve into an
1903:
Just read this over, and I think generally the goal is a good idea. The article itself needs some tidying, and I think the first paragraph is a little odd in that it tells me that I likely agree that RFA is broken.
1111:
2188:
action (and there's no procedure to request the latter.) Suggesting broad dispute-resolution is misleading because it gives readers the impression that they could get it done via earlier steps in the process, eg.
2034:
After tolling up the votes in the revision proposals, it emerged that 5.4 had the most support, but elements of that support remained unclear, and various comments throughout the polls needed consideration.
2104:
1031:. In some cases, an arbitrator may also be a steward and he just tells himself to do it. Anyway you look at it, stewards really are the ones with the big red buttons in their hands. Period. That's a
731:
the stewards have de-sysopped people in response to a community request only from projects where there either is (a) no arbcomm or (b) a policy that adminship must be renewed on a periodic basis.
51:
967:
our choice, not something dictated to us. The stewards, by the rules under which they operate, can not refuse a request provided a consensus exists and it is linked to alongside the request.
1044:
on the page, for the benefit of editors who don't know as much as you and I do. You have rejected all of these statements. I don't believe we are going to think up anything you like better.
840:
to demands for deadminship made by whoever they think is responsible enough to bring up the matter. I simply don't know; you'd have to be a polyglot to really understand what's going on
664:
I guess I just don't see what the point of bothering with this is. If you all want to come up with some policy, far be it from me to interfere, but it seems entirely unnecessary to me.
1201:
in a year. The very worst admins would get hauled up in front of ArbCom and the bad but not quite ArbCom-quality admins would get booted at the end of the year. Did I get this right?
1057:, together with whatever explanation of this user class's power and scope you think is accurate. Be nice, suit yourself, and please don't blow this up into a shoving match. Thank you.
219:. For what it's worth, I think this page is fine where it's at, there's a LOT of namespace taken up by these ideas, and any one that does finally get approval will become clear. --
1279:
The question is whether the problem is that RFA's are too slow (which John Reid's proposal addresses) or whether RFA's are too stringent (which fixed terms attempts to address) --
32:
1735:
Feel free to email me if you don't want to discuss this openly, but I'd be interested to see the what the developers of this proposal have in mind when it comes to brass tacks.
753:
think ArbCom is enough. The text you removed isn't "policy creep"; it's a statement of fact. You're factually inaccurate in your statement; ArbCom is only able to de-op
1870:
36:
1560:
at least not be massively unhappy to see implemented. (for those keeping score at home, that's about the highest praise it's possible to get from me on this topic) ++
2040:
1954:
104:
Jimbo Wales has stated that the presence of any process to remove adminship would result in a reduced motivation for all parties to work together to seek consensus.
1362:
1255:
One way to speed up RfA is to go over to a straight vote, no comment allowed on the voting page. You want to discuss somebody's adminworthiness, you do so on his
1204:
If I got your line of reasoning right, my counter-argument is that a recall mechanism would keep us from having to put up with a bad decision for a whole year. --
369:
832:
is only the biggest. Most smaller projects lack our elaborate bureaucracy; some don't even have b'crats to promote admins and go to stewards for this. Note that
229:
2108:
780:. Since that explains the procedure, and sits in a section headed "How to request someone's de-adminship" I hope it's tight enough, but see what you think.
1027:
The thing is, this is eventually the only way it ever gets done. Some individual editor makes a request of a steward and the admin loses his hat. That's
899:
At first blush, it would seem stewards might respect a RfDA, just so long as it looked reasonable. I really have no idea; we'll have to try it and see.
1958:
1358:
83:
included her -- mainly in the interest of thoroughness, since my purpose in having a list here is to demonstrate how rare "de-sysopping" actually is.
836:
has a number of project-specific subpages; most redirect to some sort of RfA. I imagine that for smaller projects lacking ArbComs, stewards actually
1874:
1831:
1823:
407:
1674:
Wouldn't the requirement that two admins certify the request (after other methods of dispute resolution fail) take care of the occasional goof? --
1602:. Whether it should be in the page history (via merge or whatever) of the final page, should this be approved? Shrug... I leave that to others. ++
383:
988:
happening, doesn't mean it is impossible. I doubt anyone will ever get desysopped through a community process, but that doesn't mean they can't.
2053:
ascertain whether there is support for a 'two-phase' poll at the eventual RfC (not far off now), where CDA will finally be put to the community.
2213:
Concur with
Iridescent. This isn't a page to request someone be de-adminned. As Iridescent noted, there's methods for doing that, most notably
1172:
Did we ever think of having longer terms. That would cut out the time consuming aspect, surely? What, if we made a term, um, let's check
2147:
2077:
1595:
341:
I thought he was sysop. Hmmm. I know that user rights log isn't kept for very long though, but this is odd. I guess my memory is bad.
288:
356:
117:
I've replaced that line, which was still uncited after over a year, with a sourced quote from a recent mailing-list post by Jimbo.
1984:
1888:
471:
389:
246:
170:
de-adminship process page. Therefore, I propose moving it to "Knowledge:De-adminship" or something to that effect. Any thoughts?
1241:
I object to the no-comment link to "perennial proposals"; a quick way to dispose of something without thinking about it. Making
35:
contains discussion surrounding a de-adminning process suggested in March 2005, which failed to gain support and now resides at
1691:
Bingo. One action that someone whines about? Not likely to result in a successful request. That action, repeated? Likely to. →
1917:
along with a statement by the admin in defence should be allowed, but that should all be done during the certification stage.
1877:. I hope this is self-explanatory. Please feel free to amend or comment. No idea if it has legs, but I think its worth a try.
216:
47:
652:
1391:
1387:
1158:
450:
321:
182:
2218:
2214:
2128:
No, it doesn't work like that; you can't just declare that you want someone to give up the admin bit. I've removed your
1770:
1739:
1173:
142:
864:
2264:
1292:
1245:
exactly equal to 3 is a perennial proposal; it's never going to fly. Term limits have been discussed before and the
71:
Why is Isis' de-sysopping listed in a separate section from the other "involuntary revocations of sysop status"? --
740:
605:
242:
The title should change. I was expecting it to be an attempt at an actual process like the requests for adminship.
88:
2003:
1937:
1611:
1569:
1425:
difficult to game, and is most importantly community-driven in a way that the current desysop options are not. →
1414:
75:
1095:
1370:
648:
121:
2176:, which is a bit vague; to my understanding, at the moment involuntary removal of an admin bit on enwiki can
1311:
be notified of and consulted about their summaries to ensure that the wording is agreed upon by all parties.
2081:
1767:
1736:
1627:
282:
166:
I think the title of this page might be confusing for new readers. They come across the title and expect an
2259:
927:
877:
833:
722:
620:
200:
61:
1322:
1681:
1478:
1455:
736:
601:
84:
1551:
By starting with MBisanz's recall process you've probably taken the second most bulletproof process in
887:
the discussion and a very brief explanation of the reason for de-adminship and results of discussion.
2226:
2061:
1966:
1883:
1839:
1796:
1635:
1591:
1418:
72:
749:
Well, UC, you're just objecting to the entire effort being made on this page. We're here because we
2273:
2250:
2230:
2202:
2198:
2167:
2154:
2120:
2116:
2085:
2065:
2024:
1970:
1946:
1893:
1858:
1843:
1817:
1803:
1775:
1757:
1742:
1723:
1707:
1686:
1656:
1639:
1614:
1599:
1585:
1572:
1542:
1520:
1516:
1502:
1483:
1460:
1441:
1403:
1399:
1374:
1366:
1346:
1337:
1325:
1315:
1299:
1283:
1270:
1267:
1230:
1208:
1185:
1164:
1152:
1149:
1064:
1061:
997:
976:
917:
914:
789:
767:
743:
702:
687:
668:
659:
642:
632:
608:
581:
555:
533:
510:
501:
488:
478:
461:
454:
422:
365:
345:
332:
325:
267:
225:
206:
193:
186:
156:
110:
91:
2044:(intended, if possible, to be one last poll before finalising the CDA proposal) has been run to;
2174:
requests to revoke another user's adminship may also be made using the dispute resolution process
1978:
1855:
1498:
1421:
here (transclusion so that edits only need to be made once, and to avoid cross-namespace redir.)
1296:
597:
257:
243:
2246:
2150:. Incidentally, Nblund isn't an admin in the first place so there's no admin bit to remove. ‑
2048:
gather opinion on the 'consensus margin' (what percentages, if any, have the most support) and
2020:
1813:
1750:
1280:
1205:
717:
Nominally, it is possible for the
Knowledge community to decide The community may request the
446:
317:
303:
178:
2185:
1719:
1675:
1472:
1449:
1181:
993:
972:
785:
665:
639:
578:
507:
485:
138:
147:
2222:
2151:
2057:
1962:
1878:
1835:
1791:
1652:
1631:
1468:
1380:
1227:
1007:
699:
530:
1808:
I'd support the version as currently worded. Seems like it covers most serious concerns.
1511:
Looks like a very good system to me. I hope it can get some kind of community approval.
1471:
shortcut that comes here. Now I've snorted tea all over my keyboard. Thanks a lot. ;-)--
361:
221:
2194:
2181:
2112:
2092:
1699:
1583:
1512:
1433:
1395:
1312:
1264:
1146:
1058:
911:
682:
647:
Different Wiki sites have different rules. For example, inactive admins desysoped from
118:
107:
58:
2190:
1996:
1930:
1851:
1607:
1565:
1494:
954:
940:
725:, and must provide a link to the page where the decision was taken by the community.
309:. Perhaps he's an administrator on another project, such as Wikibooks or Wikiquote.
2242:
2241:
That vote was ridiculous. It's like asking chickens whether they're OK with a KFC.
2132:
2016:
1909:
1809:
1341:
1161:
939:
The
English Knowledge doesn't permit, preclude or prohibit anything by policy, see
439:
419:
310:
171:
17:
2160:
2096:
1715:
1177:
989:
968:
781:
656:
552:
475:
474:
has too many inactive admins. Do we have any policies to end their adminships?--
415:
134:
2138:
template to prevent anyone else wasting their time reading this. If you have a
2148:
Knowledge:Requests for de-adminship#Current methods of requesting de-adminship
1648:
1527:
863:
From our local, political point of view, the most interesting section here is
822:
721:
to revoke another user's adminship. The community should make the request at
615:
527:
498:
438:
show only uploads and moves. So if he was a sysop, he never used his buttons.
386:
342:
264:
203:
152:
43:
2142:
reason for suggesting misconduct—and "they did something I didn't like" does
1826:. In particular, I have noted what I see as some problems with the list, in
1692:
1578:
1426:
1321:
Nothing stopping desysopped users who aren't banned from editing the entry.
712:
I removed this from the section on "how to request someone's de-adminship:"
651:
require regular voting to be readmitted, but inactive admins desysoped from
263:
Will he be going up here? He is forever banned but retains his adminship.
55:
50:
process remains the first step for dealing with abuse of admin powers; see
1054:
1988:
1922:
1603:
1561:
1552:
1394:. Editors of this page are requested to re-word it so it sounds better.--
1100:
I don't read Swedish so I took a look with the help of the good folks at
1018:
any individual, acting alone, to ask a steward to deadmin anybody. And I
1647:
I think this is very conservative but I think that's a good thing here.
1101:
1040:
Now, Hiding and I have tried a number of different ways to include this
718:
1259:, the same way you would discuss the subject of any page. Yeh, this is
1626:"Special:Unwatchedpages" but doesn't include all admin abilities (see
276:
1392:
Knowledge:Perennial_proposals#It_should_be_easier_to_remove_adminship
828:
a steward.) Stewards hold sway over all Wikimedia projects, of which
800:
Doesn't matter how you word it; somebody's not going to like it. See
506:?? Does this mean something? It seems to be a complete non sequitur.
776:
I tightened up the language in your edit after it was reverted, see
199:
Good idea. Requests for de-adminship is really along the lines of
382:
Well it doesn't have all sysops. For example why is this blank?
40:
2105:
Knowledge:Articles for deletion/Jessica Yaniv genital waxing case
1577:
Shouldn't this starting point be indicated in the page history? –
867:, a sub-section of #Removal of access. Note well the instruction:
406:
RFA didn't always use individual subpgages for discussions. e.g.
359:...not likely. He was a vigorous entity on talkpages, though. --
926:
I object to this removal, since this is how stewards act as per
805:...Stewards and Jimbo are not starting points for such requests.
306:, and the user rights log shows no record of him being sysopped
2030:
Community de-Adminship - finalization poll for the CDA proposal
854:
RfDA; it is extremely pertinent to the question of whether the
1112:
sv:Knowledge:Administratörer in machine translation to English
411:
302:
is not an administrator. He doesn't show up as a sysop in the
1084:
sort of easier road out of adminship than ArbCom. I like the
102:
Can someone please cite a source that justifies this line - "
655:
just require the request with evidence of recent activity.--
215:
Which is now superceded by the revised process proposals at
52:
Knowledge talk:Requests for review of administrative actions
1242:
1014:
now. We do understand what you're trying to say; you don't
410:
doesn't exist either, but you can find my admin nomination
2172:
Perhaps we should update that section. It currently says
890:
Do not begin or continue de-adminship discussions here.
817:. ArbCom can't deadmin anybody; neither can any b'crat.
801:
777:
435:
307:
294:
1263:
idea that's been floated before. Maybe it's time now.
1159:
Knowledge:Perennial_proposals#Reconfirm_administrators
1987:
is the current process that enjoys majority support.
1830:
proposal, of "bright line" reasons for desysopping,
1822:Please note that there is a parallel discussion at
1630:). Is this intentional? Overall though, very good.
1053:to include, on the front of this page, a link to
1871:Knowledge:WikiProject Administrator/Admin Recall
1850:Support in principle. Details can be worked out.
1415:User talk:Roux/RFA-reform#Moving to projectspace
1035:, not some biased opinion or political movement.
37:Knowledge:Requests for de-adminship/Old proposal
1955:Knowledge talk:Community de-adminship/Draft RfC
54:for the discussion that led to this process. —
8:
2109:Knowledge:Deletion review/Log/2019 August 10
1120:The Swedes do seem to have their own ArbCom
1361:. Suggested additions are welcomed on the
819:Only stewards have this technical capacity.
2159:Well, sure, if you want to split hairs...
871:
761:
1959:Knowledge:Guide to Community de-adminship
1359:Knowledge:De-adminship proposal checklist
472:Knowledge:List_of_administrators#Inactive
1824:Knowledge talk:WikiProject Administrator
408:Knowledge:Requests_for_adminship/Stormie
953:removed mechanism, and even if it did,
874:
764:
384:Knowledge:Requests_for_adminship/ContiE
2173:
2146:count—then your options are listed at
7:
1957:, and the current draft proposal at
1352:Checklist for de-adminship proposals
414:- and as coincidence would have it,
1953:Hi, please see the current talk at
1596:Knowledge:Requests_for_de-adminship
551:more than one year of inactivity?--
1293:Been there, done that, didn't work
25:
1137:(my loose, assisted translation)
151:
146:
2025:15:27, 22 September 2015 (UTC)
1983:Note that I know realise that
1875:Talk:WikiProject Administrator
1776:04:58, 19 September 2009 (UTC)
217:Knowledge:Administrator recall
48:Knowledge:Requests for comment
1:
2203:15:49, 17 November 2019 (UTC)
1787:popularity contest either. —
1326:09:23, 12 November 2007 (UTC)
1300:22:06, 18 November 2006 (UTC)
850:use to somebody who wants to
2219:Knowledge:Dispute resolution
2215:Knowledge:Dispute resolution
2066:01:00, 18 January 2010 (UTC)
2012:17:26, 20 January 2010 (UTC)
1971:17:24, 20 January 2010 (UTC)
1947:17:11, 20 January 2010 (UTC)
1894:19:21, 22 October 2009 (UTC)
1404:02:10, 28 January 2009 (UTC)
1375:18:16, 26 October 2008 (UTC)
1347:17:39, 28 October 2007 (UTC)
1284:03:36, 2 November 2006 (UTC)
1271:03:34, 2 November 2006 (UTC)
1231:22:38, 1 November 2006 (UTC)
1209:03:36, 2 November 2006 (UTC)
1186:20:05, 1 November 2006 (UTC)
1165:17:58, 1 November 2006 (UTC)
1153:17:47, 1 November 2006 (UTC)
1096:sv:Knowledge:Administratörer
1065:03:20, 2 November 2006 (UTC)
998:19:43, 1 November 2006 (UTC)
977:19:38, 1 November 2006 (UTC)
918:17:47, 1 November 2006 (UTC)
790:13:37, 1 November 2006 (UTC)
744:17:24, 1 November 2006 (UTC)
703:14:08, 1 November 2006 (UTC)
669:19:05, 23 October 2006 (UTC)
660:16:20, 23 October 2006 (UTC)
643:15:59, 23 October 2006 (UTC)
633:15:39, 23 October 2006 (UTC)
609:15:28, 23 October 2006 (UTC)
582:15:18, 23 October 2006 (UTC)
556:14:55, 23 October 2006 (UTC)
534:23:13, 22 October 2006 (UTC)
511:22:01, 22 October 2006 (UTC)
502:18:25, 22 October 2006 (UTC)
489:17:24, 22 October 2006 (UTC)
479:17:06, 22 October 2006 (UTC)
2231:17:13, 18 August 2019 (UTC)
2168:15:11, 18 August 2019 (UTC)
2155:13:51, 18 August 2019 (UTC)
2121:13:14, 18 August 2019 (UTC)
2091:Please remove adminship of
1859:22:16, 7 October 2009 (UTC)
1844:21:50, 7 October 2009 (UTC)
1818:21:36, 7 October 2009 (UTC)
1804:23:59, 6 October 2009 (UTC)
1758:14:24, 29 August 2009 (UTC)
1743:20:46, 27 August 2009 (UTC)
1724:15:43, 27 August 2009 (UTC)
1708:16:29, 24 August 2009 (UTC)
1687:14:32, 24 August 2009 (UTC)
1657:03:16, 19 August 2009 (UTC)
1640:21:59, 17 August 2009 (UTC)
1615:21:37, 17 August 2009 (UTC)
1586:21:17, 17 August 2009 (UTC)
1573:21:10, 17 August 2009 (UTC)
1543:15:09, 17 August 2009 (UTC)
1521:08:00, 17 August 2009 (UTC)
1503:05:22, 13 August 2009 (UTC)
688:16:04, 8 January 2007 (UTC)
462:00:03, 16 August 2006 (UTC)
423:21:36, 15 August 2006 (UTC)
390:21:27, 15 August 2006 (UTC)
370:21:20, 15 August 2006 (UTC)
346:20:07, 15 August 2006 (UTC)
333:11:31, 15 August 2006 (UTC)
268:08:29, 15 August 2006 (UTC)
247:00:02, 26 August 2007 (UTC)
230:21:13, 17 August 2006 (UTC)
207:08:28, 15 August 2006 (UTC)
194:07:32, 15 August 2006 (UTC)
157:14:31, 3 January 2006 (UTC)
2290:
2274:21:54, 17 March 2023 (UTC)
1484:16:26, 9 August 2009 (UTC)
1461:17:59, 8 August 2009 (UTC)
1442:21:09, 3 August 2009 (UTC)
1306:Summaries of desysop cases
928:m:Requests_for_permissions
878:m:Requests_for_permissions
834:m:Requests for permissions
813:The thing is, this is the
723:m:Requests for permissions
78:18:14, May 17, 2005 (UTC)
63:05:28, 26 Mar 2005 (UTC)
2251:17:56, 5 March 2023 (UTC)
2193:or consensus-building. --
2103:They abused adminship on
2086:18:31, 29 July 2013 (UTC)
1409:New proposal on this page
1316:04:47, 28 July 2007 (UTC)
1132:(from the last citation)
122:22:19, 17 June 2006 (UTC)
113:21:12, 2005 May 17 (UTC)
97:
467:Too many inactive admins
128:Trial run with consensus
92:20:48, 17 May 2005 (UTC)
1628:Special:ListGroupRights
1467:And I just noticed the
1526:more nuanced issue. ~
1388:WP:Perennial proposals
858:of RfDA's is possible.
618:if you are interested.
418:is on the same page. —
273:As far as I can tell,
201:Knowledge:Admin recall
2237:Adminship term length
1749:voted out like this.
1417:, I have transcluded
1386:I have added this to
1336:I have removed the {{
1006:UC, you've made your
2071:Time to update list?
1598:, I think?) credits
1592:User:Roux/RFA-reform
1088:(Swedish) approach:
1080:feel we really need
955:consensus can change
693:Wording needs dating
1600:User:MBisanz/Recall
1071:Swedish term limits
844:the entire WM farm.
768:User talk:John Reid
18:Knowledge talk:RFDA
1737:Christopher Parham
1714:reminder on this.
735:parallel process.
653:English Wiktionary
598:User:Bryan Derksen
2041:finalisation poll
2010:
1982:
1944:
1857:
1802:
1773:
1710:
1444:
1184:
996:
975:
895:
894:
796:
795:
788:
681:process again. --
649:Wikimedia Commons
460:
331:
192:
98:Jimbo's statement
16:(Redirected from
2281:
2271:
2267:
2262:
2165:
2137:
2131:
1995:
1976:
1929:
1891:
1886:
1881:
1854:
1801:
1799:
1788:
1771:
1755:
1706:
1704:
1697:
1684:
1678:
1555:(excepting only
1540:
1481:
1475:
1458:
1452:
1440:
1438:
1431:
1344:
1180:
992:
971:
872:
784:
762:
685:
629:
626:
623:
457:
444:
442:
434:Nathanrdotcom's
328:
315:
313:
301:
300:
297:
279:
189:
176:
174:
155:
150:
21:
2289:
2288:
2284:
2283:
2282:
2280:
2279:
2278:
2269:
2265:
2260:
2239:
2161:
2135:
2129:
2101:
2073:
2032:
1901:
1889:
1884:
1879:
1867:
1797:
1789:
1751:
1700:
1693:
1682:
1676:
1594:(trancluded to
1590:Paragraph 4 of
1528:
1479:
1473:
1456:
1450:
1434:
1427:
1411:
1384:
1354:
1342:
1334:
1308:
1073:
896:
880:
797:
770:
710:
695:
683:
627:
624:
621:
469:
455:
440:
326:
311:
295:
280:
275:
274:
261:
187:
172:
164:
162:Move this page?
130:
100:
73:DropDeadGorgias
69:
30:
23:
22:
15:
12:
11:
5:
2287:
2285:
2277:
2276:
2238:
2235:
2234:
2233:
2210:
2209:
2208:
2207:
2206:
2205:
2145:
2141:
2126:
2100:
2093:User:Sandstein
2089:
2072:
2069:
2055:
2054:
2050:
2049:
2031:
2028:
2006:
2001:
1993:
1974:
1973:
1940:
1935:
1927:
1900:
1897:
1866:
1863:
1862:
1861:
1847:
1846:
1820:
1806:
1779:
1778:
1746:
1745:
1732:
1731:
1730:
1729:
1728:
1727:
1726:
1669:
1668:
1664:single actions
1660:
1659:
1642:
1622:
1621:
1620:
1619:
1618:
1617:
1548:
1547:
1546:
1545:
1508:
1507:
1506:
1505:
1487:
1486:
1464:
1463:
1410:
1407:
1383:
1378:
1367:TenOfAllTrades
1353:
1350:
1333:
1330:
1329:
1328:
1323:193.95.165.190
1307:
1304:
1303:
1302:
1289:
1288:
1287:
1286:
1274:
1273:
1252:
1251:
1238:
1237:
1236:
1235:
1234:
1233:
1218:
1217:
1216:
1215:
1214:
1213:
1212:
1211:
1202:
1191:
1190:
1189:
1188:
1156:
1155:
1141:
1140:
1139:
1138:
1127:
1126:
1117:
1116:
1115:
1114:
1106:
1105:
1072:
1069:
1068:
1067:
1049:So, I ask you
1046:
1045:
1037:
1036:
1024:
1023:
1003:
1002:
1001:
1000:
982:
981:
980:
979:
961:
960:
959:
958:
947:
946:
945:
944:
934:
933:
932:
931:
921:
920:
901:
900:
893:
892:
882:
881:
875:
870:
869:
868:
860:
859:
846:
845:
810:
809:
794:
793:
772:
771:
765:
760:
759:
758:
728:
727:
709:
706:
694:
691:
678:
677:
676:
675:
674:
673:
672:
671:
593:
592:
591:
590:
589:
588:
587:
586:
585:
584:
565:
564:
563:
562:
561:
560:
559:
558:
541:
540:
539:
538:
537:
536:
518:
517:
516:
515:
514:
513:
492:
491:
468:
465:
432:
431:
430:
429:
428:
427:
426:
425:
397:
396:
395:
394:
393:
392:
375:
374:
373:
372:
351:
350:
349:
348:
336:
335:
260:
255:
254:
253:
252:
251:
250:
249:
235:
234:
233:
232:
210:
209:
163:
160:
129:
126:
125:
124:
99:
96:
95:
94:
68:
65:
29:
26:
24:
14:
13:
10:
9:
6:
4:
3:
2:
2286:
2275:
2272:
2268:
2263:
2255:
2254:
2253:
2252:
2248:
2244:
2236:
2232:
2228:
2224:
2220:
2216:
2212:
2211:
2204:
2200:
2196:
2192:
2187:
2183:
2179:
2175:
2171:
2170:
2169:
2166:
2164:
2158:
2157:
2156:
2153:
2149:
2143:
2139:
2134:
2127:
2125:
2124:
2123:
2122:
2118:
2114:
2110:
2106:
2098:
2094:
2090:
2088:
2087:
2083:
2079:
2078:69.125.134.86
2070:
2068:
2067:
2063:
2059:
2052:
2051:
2047:
2046:
2045:
2043:
2042:
2036:
2029:
2027:
2026:
2022:
2018:
2013:
2009:
2007:
2004:
2002:
2000:
1997:
1994:
1992:
1989:
1986:
1980:
1979:edit conflict
1972:
1968:
1964:
1960:
1956:
1952:
1951:
1950:
1949:
1948:
1943:
1941:
1938:
1936:
1934:
1931:
1928:
1926:
1923:
1918:
1914:
1911:
1905:
1898:
1896:
1895:
1892:
1887:
1882:
1876:
1872:
1864:
1860:
1856:
1853:
1849:
1848:
1845:
1841:
1837:
1833:
1829:
1825:
1821:
1819:
1815:
1811:
1807:
1805:
1800:
1794:
1793:
1786:
1781:
1780:
1777:
1774:
1769:
1765:
1762:
1761:
1760:
1759:
1756:
1754:
1744:
1741:
1738:
1733:
1725:
1721:
1717:
1712:
1711:
1709:
1705:
1703:
1698:
1696:
1690:
1689:
1688:
1685:
1679:
1673:
1672:
1671:
1670:
1665:
1662:
1661:
1658:
1654:
1650:
1646:
1643:
1641:
1637:
1633:
1629:
1624:
1623:
1616:
1613:
1609:
1605:
1601:
1597:
1593:
1589:
1588:
1587:
1584:
1582:
1581:
1576:
1575:
1574:
1571:
1567:
1563:
1558:
1554:
1550:
1549:
1544:
1541:
1539:
1535:
1531:
1524:
1523:
1522:
1518:
1514:
1510:
1509:
1504:
1500:
1496:
1491:
1490:
1489:
1488:
1485:
1482:
1476:
1470:
1466:
1465:
1462:
1459:
1453:
1447:
1446:
1445:
1443:
1439:
1437:
1432:
1430:
1422:
1420:
1419:this proposal
1416:
1408:
1406:
1405:
1401:
1397:
1393:
1389:
1382:
1379:
1377:
1376:
1372:
1368:
1364:
1360:
1351:
1349:
1348:
1345:
1339:
1331:
1327:
1324:
1320:
1319:
1318:
1317:
1314:
1305:
1301:
1298:
1297:Mailer Diablo
1294:
1291:
1290:
1285:
1282:
1278:
1277:
1276:
1275:
1272:
1269:
1266:
1262:
1258:
1254:
1253:
1248:
1244:
1240:
1239:
1232:
1229:
1224:
1223:
1222:
1221:
1220:
1219:
1210:
1207:
1203:
1199:
1198:
1197:
1196:
1195:
1194:
1193:
1192:
1187:
1183:
1179:
1175:
1171:
1170:
1169:
1168:
1167:
1166:
1163:
1160:
1154:
1151:
1148:
1143:
1142:
1136:
1131:
1130:
1129:
1128:
1123:
1119:
1118:
1113:
1110:
1109:
1108:
1107:
1103:
1099:
1097:
1091:
1087:
1083:
1079:
1075:
1074:
1070:
1066:
1063:
1060:
1056:
1052:
1048:
1047:
1043:
1039:
1038:
1034:
1030:
1026:
1025:
1021:
1017:
1013:
1009:
1005:
1004:
999:
995:
991:
986:
985:
984:
983:
978:
974:
970:
965:
964:
963:
962:
956:
951:
950:
949:
948:
942:
938:
937:
936:
935:
929:
925:
924:
923:
922:
919:
916:
913:
908:
903:
902:
898:
897:
891:
888:
884:
883:
879:
873:
866:
865:#en:wikipedia
862:
861:
857:
853:
848:
847:
843:
839:
835:
831:
827:
824:
820:
816:
812:
811:
806:
803:'s edit sum:
802:
799:
798:
792:
791:
787:
783:
779:
774:
773:
769:
763:
756:
752:
748:
747:
746:
745:
742:
738:
737:The Uninvited
732:
726:
724:
720:
715:
714:
713:
707:
705:
704:
701:
692:
690:
689:
686:
670:
667:
663:
662:
661:
658:
654:
650:
646:
645:
644:
641:
636:
635:
634:
631:
630:
617:
613:
612:
611:
610:
607:
603:
602:The Uninvited
599:
583:
580:
575:
574:
573:
572:
571:
570:
569:
568:
567:
566:
557:
554:
549:
548:
547:
546:
545:
544:
543:
542:
535:
532:
529:
524:
523:
522:
521:
520:
519:
512:
509:
505:
504:
503:
500:
496:
495:
494:
493:
490:
487:
483:
482:
481:
480:
477:
473:
466:
464:
463:
458:
452:
448:
443:
437:
424:
421:
417:
413:
409:
405:
404:
403:
402:
401:
400:
399:
398:
391:
388:
385:
381:
380:
379:
378:
377:
376:
371:
368:
367:
363:
358:
355:
354:
353:
352:
347:
344:
340:
339:
338:
337:
334:
329:
323:
319:
314:
308:
305:
298:
293:
290:
287:
284:
278:
277:Nathanrdotcom
272:
271:
270:
269:
266:
259:
258:Nathanrdotcom
256:
248:
245:
241:
240:
239:
238:
237:
236:
231:
228:
227:
223:
218:
214:
213:
212:
211:
208:
205:
202:
198:
197:
196:
195:
190:
184:
180:
175:
169:
161:
159:
158:
154:
149:
144:
140:
136:
127:
123:
120:
116:
115:
114:
112:
109:
105:
93:
90:
86:
85:The Uninvited
81:
80:
79:
77:
74:
66:
64:
62:
60:
57:
53:
49:
45:
42:
38:
34:
33:/Old proposal
27:
19:
2258:
2240:
2177:
2162:
2140:policy based
2102:
2074:
2056:
2039:
2037:
2033:
2011:
2008:
1998:
1990:
1975:
1945:
1942:
1932:
1924:
1919:
1915:
1906:
1902:
1868:
1827:
1790:
1784:
1763:
1752:
1747:
1701:
1694:
1663:
1644:
1579:
1556:
1537:
1533:
1529:
1435:
1428:
1423:
1412:
1385:
1355:
1335:
1309:
1260:
1256:
1246:
1157:
1133:
1121:
1093:
1089:
1085:
1081:
1077:
1050:
1041:
1032:
1028:
1019:
1015:
1011:
1010:-- at least
906:
889:
885:
876:Copied from
855:
851:
841:
837:
829:
825:
818:
814:
808:first place.
804:
775:
766:Copied from
754:
750:
733:
729:
716:
711:
696:
679:
619:
594:
484:Why bother?
470:
433:
360:
291:
285:
262:
220:
167:
165:
131:
103:
101:
70:
31:
2180:happen via
2097:User:Nblund
1869:Please see
1677:Fabrictramp
1474:Fabrictramp
1451:Fabrictramp
1332:Historical?
1090:term limits
1012:three times
416:User:ContiE
357:Survey says
2223:Hammersoft
2152:Iridescent
2058:Matt Lewis
1963:Tryptofish
1836:Tryptofish
1683:talk to me
1645:Looks good
1632:Shubinator
1480:talk to me
1457:talk to me
1338:historical
1228:Carcharoth
1055:m:Stewards
757:a steward.
700:Carcharoth
44:March 2005
2195:Aquillion
2186:WP:OFFICE
2113:Sharouser
1865:Draft RfC
1513:Ironholds
1396:Aervanath
1363:talk page
1313:Everyking
1257:talk page
1022:with you.
684:Wizardman
304:user list
296:block log
119:Tim Smith
108:Netoholic
2270:Chequers
1921:Cheers,
1899:Comments
1852:Amerique
1553:CAT:AOTR
1495:Euryalus
1469:WP:FIRED
1381:WP:PEREN
1051:politely
852:instance
842:all over
719:stewards
708:Stewards
596:example
289:contribs
2243:Synotia
2191:WP:RFCs
2182:WP:RFAR
2017:1FWZ071
1810:JoshuaZ
1764:Support
1753:Chillum
1390:. See
1343:szyslak
1281:Richard
1261:another
1250:limits.
1206:Richard
1162:Raul654
1125:enough:
1102:Systran
1029:reality
755:through
441:szyslak
420:Stormie
312:szyslak
173:szyslak
106:". --
56:Charles
28:Comment
2163:Nblund
1740:(talk)
1716:MLauba
1178:Hiding
990:Hiding
969:Hiding
941:WP:IAR
838:listen
821:(BTW,
782:Hiding
666:john k
657:Jusjih
640:john k
579:john k
553:Jusjih
531:(Talk)
508:john k
497:eBay.
486:john k
476:Jusjih
168:actual
135:JHMM13
76:(talk)
46:, the
2266:Spiel
1910:WP:DR
1649:Hobit
1265:John
1174:stats
1147:John
1059:John
1020:agree
1008:POINT
912:John
856:class
823:Jimbo
815:truth
751:don't
739:Co.,
622:Voice
604:Co.,
528:ALoan
499:Anomo
387:Anomo
343:Anomo
265:Anomo
204:Anomo
87:Co.,
41:As of
2261:Ϣere
2247:moan
2227:talk
2221:. --
2199:talk
2178:only
2117:talk
2111:. --
2107:and
2095:and
2082:talk
2062:talk
2021:talk
1985:this
1967:talk
1961:. --
1873:and
1840:talk
1834:. --
1832:here
1828:this
1814:talk
1792:Ched
1772:ping
1768:Pcap
1720:talk
1695:ROUX
1653:talk
1636:talk
1580:xeno
1517:talk
1499:talk
1429:ROUX
1413:Per
1400:talk
1371:talk
1295:. -
1268:Reid
1182:Talk
1150:Reid
1094:See
1082:some
1062:Reid
1042:fact
1033:fact
1016:want
994:Talk
973:Talk
915:Reid
786:Talk
778:here
741:Inc.
625:-of-
616:this
614:See
606:Inc.
436:logs
412:here
366:blis
283:talk
244:A.Z.
226:blis
89:Inc.
67:Isis
2184:or
2144:not
2133:rfc
1999:(t/
1991:NJA
1933:(t/
1925:NJA
1890:Dui
1885:Mac
1880:Ben
1785:un-
1604:Lar
1562:Lar
1247:en:
1122:but
1086:sv:
830:en:
628:All
362:nae
222:nae
2249:)
2229:)
2201:)
2136:}}
2130:{{
2119:)
2084:)
2064:)
2038:A
2023:)
2005:c)
1969:)
1939:c)
1842:)
1816:)
1798:?
1795::
1722:)
1680:|
1655:)
1638:)
1606::
1564::
1557:my
1519:)
1501:)
1477:|
1454:|
1402:)
1373:)
1365:.
1243:Pi
1092:.
1078:do
1076:I
907:do
826:is
453:,
449:,
324:,
320:,
185:,
181:,
145:)
141:|
59:P.
39:.
2245:(
2225:(
2197:(
2115:(
2099:.
2080:(
2060:(
2019:(
1981:)
1977:(
1965:(
1838:(
1812:(
1718:(
1702:â‚Ş
1651:(
1634:(
1612:c
1610:/
1608:t
1570:c
1568:/
1566:t
1538:a
1536:c
1534:z
1532:a
1530:m
1515:(
1497:(
1436:â‚Ş
1398:(
1369:(
1104::
1098:.
459:)
456:e
451:c
447:t
445:(
364:'
330:)
327:e
322:c
318:t
316:(
299:)
292:·
286:·
281:(
224:'
191:)
188:e
183:c
179:t
177:(
143:C
139:T
137:(
111:@
20:)
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
