905:
active again (not a bad thing) and not respond, and others will not respond because they have no interest, or are not checking their email (the dead are so rude sometimes). Lastly, we are qualifying inactivity as being inactive on the wiki-en, right? If someone is a global admin on several meta-wikia, but has never acted within the wiki-en, does their resignation of admin here apply to their global admin status? Sorry, I heard talk of the global admin some months back, but heard that we had chosen to not participate in that; unlike many folk, my question is actually prefaced on not knowing the answer to the question before I am asking it. -
1436:
lowering of access level. This short RfC is to make sure that there is indeed community consensus for what we are about to do. This RfC will close on or about
February 15th assuming there is not any vigorous objections that need to be addressed. The rough consensus seemed to be that we should never bug the same administrator twice, even if we do this again in the future, so the most any administrator will ever get is one email in their lifetime.
1579:
might work better and avoid people responding along the lines of "can't someone spend a couple of years doing a degree/having a baby" etc. Whilst I hope that those who are irritated by getting a security warning about something they have long finished with respond by resigning their adminship. As for the wiki link - yes they can only use that by going to
Knowledge.
995:
purposes of the mailing? And how to we calculate non-responses? To the first question, I would say that the "6 months with no edits" rule being mentioned earlier makes sense. To the second, I would say that it does not matter; as it stands there is nothing that can be done in the case of non-responses and therefore no value in calculating them.
1701:
appointed two, had one unretire, gained one admin bot and lost another and had one admin desysopped by arbcom, but instead of a net increase of two we have a drop of three. Now its entirely possible that there are other explanations for our drop of five admins, but there could be up to five resignations resulting from that email.
1487:
I'm not happy with the currently proposed wording. Remember the message needs to be that we miss you and wonder when you'll be back. - Something like the
Strategy wiki's survey. Alternatively we could do a newsflash - an admin account was recently compromised and we'd like to suggest that you revisit
1149:
enjoys going through 1700+ editors to determine the time of their last edit. A bot could also store the activity state for each account and pretty easily make a comparison from one month to the next to determine who has gone inactive or who has become active, but there's really no need for that. It
1124:
Well, that would be obvious if - and this might only be a small 'if' - we are able to calculate, say, 30 days out, who was inactive and is now active. Do we have ways of determining that, or is there not going to be any way to determine that? A follow-up question would be whether the list of inactive
1040:
However, I still have an outstanding question. How do we calculate the number of non-responses? Calculating who writes back in to voluntarily release the bit is easy. Harder to calculate (but not impossible, I'd wager) is the number of inactive admins that suddenly become active. What I think we also
1064:
I think we need to calculate the number of non-responses as well, Gigs. While you are correct in noting that there is nothing that can be done currently regarding admins who have simply abandoned the project (via death, disinterest or whatnot), that may not always be the case, and among the goals of
978:
I seem to recall at least several of the smaller language wikis doing something similar with reconfirmation/inactivity as well. I can't read the languages so it's hard to check. Anyway my point was, none of them have a massive backlog of inactive administrators like en does. And besides, we can't
295:
I think that even with a bot, we should just direct them to pages on en and meta where they can request bit removal. As has been pointed out, the idea of wiki-identity is based on making an edit here under that name (or solving a committed hash). We shouldn't create new security holes while trying
904:
A few questions spring to mind. First, what inactivity criteria are we going to utilize? I opted earlier for 6 months, but am also amenable to including those who might have been absent for 3-4 months. As well, how do we calculate the number of non-responses? Some admins will see it as a hint to be
204:
Global sysops is a red herring. We don't have an en.wiki equivalent for m:SRP, but the admin in question could edit their talk page and say something to the effect of "Please remove my administrator privileges effective immediately", and then someone could point a steward at m:SRP to that difflink.
994:
Might want to refocus the discussion before we get off-track; this isn't really supposed to be a discussion on the merits of reconfirmation or what other projects do it. It's not really relevant to the question posed - specifically, what do we want to define as our criteria for inactivity for the
925:
Global admin is irrelevant really. Yes, we are only interested in en. If they aren't using these permissions then we want them to consider giving them up. They could consider giving up other adminship as well... but to be honest, most of the other smaller Wikis have a much more reasonable admin
781:
On that note, my programming skills are nowhere near where they should be. Gigs, if I grab you some source code for an already-running bot, do you think you can work with it? What language would you prefer? I've seen php and python bots kicking around, could probably find something else if need
389:
The purpose of the email is to assess who's intending on returning to the
Project and who is not. We know what to do if they respond in the positive (yep, coming back "soon") or in the negative (nope, voluntary de-sysop), but so far, I have not heard about what we do if we receive no reply at all.
335:
intend to give up the bit. If we did, would we track this and then use it as an opt-out list from further emails? Is this overcomplicating things? Should we just ask them to consider giving it up and ignore it if they don't want to? We will lose any data on reachability of inactive admins, but
1700:
10,000 edits before I got round to creating a separate account for
Knowledge, but yes I'd agree that a fair few of those emails will be sitting in accounts that are no longer used. However I wouldn't assume that no replies has to mean no result. At the beginning of March we had 1720 admins, we've
1578:
I agree that the main aim is to get inactive admins who have no intent to return to give up the bit, though I'm also concerned there could be admins out there who haven't changed their password for years and such passwords might have become compromised. But I think that a more diplomatic approach
479:
Arcayne, anything more than what is proposed would require a change in policy, which would require a large RfC with much forum-shopping. This, on the other hand, can probably be dealt with here, with maybe a thread at AN to judge opinion, plus bot authorization should we choose to go that route.
1614:
I was actually thinking of accounts which were still under the admins control but where they knew the password to have been compromised. However there is a risk that you are emailing a completely different person. For example if someone used a work account for their
Knowledge Email and they have
1435:
to every administrator that has an email on file and hasn't edited in 6 months or more. The mails with have a From address of en.wiki.inactivemailerbot@gmail.com, which will be monitored. It will not solicit replies to the email, but will direct them to edit a page on enwiki or meta to request
112:
Arcayne, if you'd like to get something done here, may I strongly suggest you drop the personal crusade angle? It isn't helping, and is only further dividing people. As far as the stewards are concerned, that's why we need to put the link in the email, as I don't see anything getting adopted as
1544:
Well, I think it's a better basis to work from than what we started with, but I think the emphasis should be on giving up the bit if they don't need it. Strong passwords aren't much of a concern because the devs already run cracking against the admin's accounts. The primary goal here was to
330:
I'm not sure it's a critical point either way, but if we do it that way, we need to pick a longer interval so that people don't get mad about the spam if they are irregular editors who definitely don't want to give up the bit. Another question is whether we should even solicit a reply if they
291:
If it's a bot job, we should probably make it so it does not do the same person more than once ever. This ensures that no one ever gets more than one email from the bot. If they ignore it then we shouldn't keep harassing them, and if they no longer read the email then we aren't accomplishing
251:
I'm not sure need a formal RfC for what will be a relatively uncontroversial action, but it might be nice to break this conversation and the draft email off onto its own page because we are veering pretty far offtopic for this page and it looks like we do have resolve to actually get something
236:
Works for me. If they don't have meta accounts, then that's fine. The goal shouldn't be to desysop every inactive admin or get them back editing, but rather to offer the opportunity to inactive admins to relinquish their bit and help us out on the housecleaning front. It's totally up to them
758:
Shouldn't be too hard to whip something up in php, python, perl, etc, that grabs names from the inactive list, navigates to their userpage, hits "email this user", and sends them the email. I think we should make sure everyone agrees on the content of the email, then take it to
444:
For now that's all we have consensus for. I think it's important that you accept that as the scope of this mini-project at least for now. The numbers and data that come out of this endeavor might be useful for any future discussion regarding non-voluntary inactivity de-sysop.
423:
Let me see if I understand you, Xeno. The only way that you are willing to consider de-sysoping an editor is if they themselves choose it? How do you address the matter of dead admins or admins who have abandoned the project, either out of disinterest or disaffection? -
273:
Yeah if we want to sign it as the community and have a bot doing this on an ongoing basis then I agree we should do an RfC... probably just a simple talk page one though. I'm going to move this conversation over to the talk page there and leave a pointer on WT:RfA
1615:
subsequently changed jobs, I know of companies where mailboxes of former employees are monitored, or worse if someone was foolish enough to use a role account such as sales@ or support@ that account might now be in the possession of a completely different person.
514:
A sound analogy - as the proposal was handily rejected, yet you tried to push it through like a freight train with this "you're inactive! email" Of course the answer is "do nothing" - until the community agrees that inactive administrators may be deadminned.
368:
hit someone up with a second email; if they got the first and then came back, there is no reason to assume that their second (or third or fourth) period of inactivity will be any deviation from the pattern that they have sent. It's probably not harmful
1805:
If you e-mail all the inactive admins, you'll find there's more than 76 you can't reach. All the old admins who haven't edited since before 2007 cannot be reached by e-mail. Back then, it was different as far as having an e-mail address on record.
844:
There's really not much involved from a programming standpoint. Someone codes a bot that goes through our list of admins, determins which ones are "inactive" based up on the criteria we give it, and then it sends them an email pointing them to
98:, if you will. The problem of inactive admins is not nearly so great that it requires such a measure, and this is by far the wrong place to claim some sort of consensus has arrisen supporting it. My preferred method of enacting this would be
528:
I was proposing a means by which active admins are more appreciated. I'm terribly sorry you are unable/incapable of seeing that. Maybe you could stop trying to provoke me or trying to have the last word, Xeno. What are you so terrified of? -
162:
So long as the bot (if it is to be one) posts the reply somewhere in their userspace, or stewards have access to the raw emails (not forwarded, etc), then I could see that happening. Desysopping based on some editor's say-so seems unlikely.
1089:
I think the only relevant data we can make sure to preserve right now is the last edited date for each editor before the email went out. This gives us the baseline. All other data can be collected later or calculated after the fact.
681:
Well the holder of the bot account would have access to that, but I'm not sure it's a good idea to concentrate access to information like that, even if they were a well-respected and highly trusted member of the community.
72:
I largely agree with Xeno's changes that you reverted as well. One problem is that inactives probably won't know what a global account is or have an account on meta... Xeno can't we do a local page here just for this?
1340:
Agreed on the RfC part. As for what to sign it with, let's just sign it with the bot's name. I propose "InactiveAdminEmailBot". Esoteric, I know. As for the email address, let's just ask a dev to assign <botname:
1324:
I don't think we need a full 30 day RfC on this. There's nothing that says an RfC can't run for less time, and 7 days seems customary for giving people notice of things. So I propose a 7 day RfCtag on this page.
390:
Are they intending to come back? Are they dead? I'd like to hear a little more about what we do at that point, for I believe that in the absence of reply, we might need to assume that they do not plan to return. -
1653:
940:
Which other wikis have reconfirmation? I checked Meta, Mediawiki, Commons, Mediawiki, Frwiki, and Dewiki and all of them are admin for life unless the admin goes inactive. None of them use reconfirmations.
1563:
BTW- can't use wiki links since the contents of this will be the email, not a link to this page. I kept most of what you wrote but reworked it a little to try to retain more emphasis on the sysop part.
668:
If it did that, it would need to advise the users it was going to reproduce private correspondence on wiki. I think
Arcayne is more talking about the emails that said "returning" or "no" or something. –
1431:
This RfC is regarding the above discussion and the project page associated with this talk page. Our current plans are a bot named "InactiveAdminEmailBot" which will email the contents of the
974:
Meta: Any sysop inactive on Meta will be desysopped. "Inactivity" is normally defined as fewer than 10 logged actions in the past six months. Stewards do undergo reconfirmation each election.
1170:
I agree completely. Are we going to wait 30 days before discussing the results of the emailing? As I mentioned before, those who are going to respond/react will likely do so by that time. -
266:
The RfC was so that we could legitimately sign it as "the community". What about making a bot for it? I sure don't feel like sending 800 emails manually. Anyways, shall we move things to
1037:) I recall that MBisanz made that same point elsewhere. Like you, I'm not up on all the languages of the other wikis, but I appreciate Gigs' greater breadth of knowledge of other wikis.
696:
I think we should just dodge that whole issue and only solicit resignations by telling people where and how they can do it. Then we don't need to worry about the return address.
1432:
94:
I too prefer the revisions that Xeno and Gigs have made. My intent in propsing the draft was never that there would be a default to desysop unless the editor responds--an admin
1748:), though all of them still have +ops except for the one decedent desysopped by arbcom mentioned above. So perhaps we rustled them out of their slumber? Still a net benefit! –
1699:
I suspect a lot of them are very unlike you. We have hundreds of admins who only made a handful of admin actions and /or never made more than a few thousand edits. I had : -->
1510:
Please do feel free to make your suggestions by directly editing the project page (and I agree the message should start with some sweetness and then get down to business =). –
190:
Is there an en.wp equivalent to the meta link you posted? Also, if the global sysops deally goes through, as seems likely, then wouldn't they have to go to meta anyways?
1549:
principles as much was possible with a voluntary program. I'll give it a go and we can go back and forth a little until we can get something we are both happy with.
630:
Why wouldn't you just have the bot post them to its userspace? I thought the issue was moot anyways due to the requirement of the editor themselves posting to meta.
926:
policy that says that all admins need to be reconfirmed periodically which leads to them expiring. I think en is mostly unique in making adminship until death.
890:
Yeah, I figured one of us would clerk for them on the local page. It shouldn't be much work. I don't anticipate a huge response after the first week or two.
1190:
That's probably about the right amount of time, but we'll know for sure based on the rate that replies come in. We don't need to plan everything up front.
1684:
If they're anything like me, they have a separate email just for wiki business, and are probably not checking it along with not logging in to the 'ped. –
1249:
has a module for e-mailing users. Should be simple enough to write and I think bots are (or should be) excluded from the usual rate limits". Thoughts? -
1523:
OK I've changed the approach, I think this might do the job and doubt if any reasonable person would object to being asked to use a strong password.
51:
Yes, the stewards tend to be rather particular that it must be communicated directly to them, either via private communication from the admin or via
316:. That is, if an editor is inactive for a year, comes back for a year, then is inactive for another year, it seems reasonable to resend the email.
1104:
The math really isn't that hard; Take the number of emails you sent out, subtract the number of responses, subtract the number of admins who are
1670:
No apparent replies thus far. I guess if we've proven anything, solicitation is not an effective way to eliminate inactive administrator bits.
17:
1044:
A question from the T:RfA discussion as well: how long do we wait before looking at the results of the email? 7 days? 14 days? 30 days? -
849:
if they intend on resigning the bit. The user logs in, posts a request at that page, and stewards will remove the bit; pretty simple.
107:
To make a bot that handles the emailing automatically, and sends future emails as admins pass whatever activity cutoff we decide upon
1370:
I've registered en.wiki.inactivemailerbot@gmail.com, and will hand it over to whoever decides to oversee it. Does that sound good?
1763:
I'm sure a few changed their password and updated their email as well, though that's harder to measure. It wasn't all for naught.
312:
I agree with both of those points. A slight modification to your first: Should not message the same person more than once
1818:
1790:
1772:
1758:
1732:
1717:
1694:
1679:
1664:
1631:
1609:
1595:
1573:
1558:
1539:
1518:
1504:
1474:
1460:
1445:
1410:
1396:
1382:
1365:
1351:
1334:
1264:
1240:
1219:
1199:
1185:
1165:
1140:
1119:
1099:
1084:
1059:
1020:
1006:
988:
949:
935:
920:
899:
885:
860:
835:
814:
791:
776:
733:
719:
705:
691:
676:
639:
605:
576:
544:
523:
509:
489:
454:
439:
418:
405:
384:
359:
345:
325:
305:
283:
261:
246:
213:
199:
185:
172:
157:
122:
82:
63:
1465:
InactiveAdminEmailBot is blacklisted because it has the word Admin in it. I'm going to use a
InactivityEmailBot instead
1108:
inactive after the email push, and you have the number of admins who became active again without replying to the email.
597:
Someone would need the password for the email address registered to the bot, in order to login and check the replies. –
1708:
1622:
1586:
1530:
1495:
149:
As long as its on en.wp the steward will probably act on it, but an edit to m:SRP is the best way to go about it. –
966:
Well, I guess I was mistaken. Many of them do have a process that removes the bit due to inactivity in some way:
1356:
When the blast goes out, we need to make sure that user is around so they don't quota out. Gmail might be best.
969:
Commons: An "inactive admin" is one who has made fewer than 5 admin actions on
Commons in the past 6 months
1703:
1617:
1581:
1525:
1490:
1406:
1347:
787:
772:
715:
687:
635:
494:
Fair enough. I'll be patient. I guess this is what pulling a freight train by one's teeth feels like. -
485:
355:
321:
242:
195:
168:
118:
763:. As far as the MW bot interface goes, there's plenty of opensource bots out there already. We can
1814:
89:
252:
accomplished here rather than just talk, and we just need some space to hammer out the details.
1257:
1212:
1178:
1160:
1133:
1114:
1077:
1052:
1001:
913:
855:
828:
569:
537:
502:
432:
398:
379:
1402:
1343:
1309:
Decide whether return email should be a noreply or not - en.wiki.inactivemailerbot@gmail.com
1229:
846:
802:
783:
768:
711:
683:
631:
481:
351:
317:
238:
191:
164:
114:
1342:@en.wikipedia.org, then forward it to the email addy of whoever's going to oversee things.
205:
Though, it would be more efficient for the admin in question to post directly to m:SRP =) –
1738:
1546:
760:
95:
350:
Doesn't hurt to solicit, then at least have it shown as received somewhere. Either way.
724:
So what's our next step? I'm a programmer but I have pretty much no MW bot experience.
1807:
1788:
1768:
1756:
1730:
1692:
1675:
1660:
1605:
1569:
1554:
1516:
1470:
1456:
1441:
1392:
1378:
1361:
1330:
1238:
1225:
1195:
1095:
1016:
984:
931:
895:
883:
810:
729:
701:
674:
603:
521:
450:
416:
341:
301:
279:
257:
211:
183:
155:
78:
970:
1600:
Interesting, I didn't think about accounts that may have already been compromised.
1250:
1205:
1171:
1155:
1126:
1109:
1070:
1045:
996:
943:
906:
850:
821:
562:
530:
495:
425:
391:
374:
57:
1387:
Boldly taking out the signature line entirely. We don't really need a signature.
561:
So, please tell this non-admin how we track this bot'd email to the inactives? -
1451:
Well, I guess no one cares that much. Closing the RfC and removing the RfCtag.
1154:
admins became active, all you really need to know is how many did (or did not).
55:, I can't see them bending the rules they apply to all 700+ wikis just for us.
1488:
EN wiki and make sure your admin account is protected with a strong password.
1781:
1764:
1749:
1723:
1685:
1671:
1656:
1601:
1565:
1550:
1511:
1466:
1452:
1437:
1388:
1374:
1357:
1326:
1233:
1191:
1091:
1012:
980:
927:
891:
878:
806:
725:
697:
669:
598:
516:
446:
411:
337:
297:
275:
253:
206:
178:
150:
74:
820:
Not being programming-savvy, could you explain how this plays out? -
1654:
Wikipedia_talk:Requests_for_adminship/Inactive_admin_email/results
1069:
respond. Indeed, I think that information is actually critical. -
710:
Good plan. A "please do not reply to this email" should suffice.
1145:
A bot would make the most sense unless you can find someone who
874:
52:
1315:
Decide whether we need an RfC or what. - Looks like we should.
1065:
this email is to gather information about those admins who do
1427:
RfC - Inactive administrator resignation solicitation email
1246:
268:
Knowledge talk:Requests for adminship/Inactive admin email
104:
To start an RfC to determine if there is community support
1041:
need to be able to watch those who do not respond at all.
1778:
1745:
1742:
336:
I'm not sure that it is worth the extra complication.
177:
Stewards will want an edit on en.wp or meta. Period. –
1245:
I submitted the request. Someone has suggested that "
1224:I suppose after someone writes the bot and files a
296:to close them by trusting emails instead of edits.
1777:Damn freedom fighters and their thunder-stealing!
1011:Right. It looks like 6 months is a good standard.
1125:admins is a manually maintained or bot'd one. -
1232:if there's anyone available to write the bot. –
1722:So let's troll the logs and see what happen! –
8:
1312:Decide how to sign the email - No signature
1306:Decide on a bot name -InactiveAdminEmailBot
26:
1741:as of March 1 are no longer there today:
1401:Heresy! But yeah, I'm fine with that.
29:
1204:When are we to send the email out? -
373:, it just seems a bit like overkill.
18:Knowledge talk:Requests for adminship
7:
1373:Works for me. Listing the RfC now.
364:I don't know that it's necessary to
1652:195 sent 76 with emails disabled.
24:
979:speak on their behalf anyway.
1:
1610:13:04, 26 February 2010 (UTC)
1596:09:16, 26 February 2010 (UTC)
1574:03:38, 26 February 2010 (UTC)
1559:03:32, 26 February 2010 (UTC)
1540:20:54, 25 February 2010 (UTC)
1519:18:05, 24 February 2010 (UTC)
1505:17:56, 24 February 2010 (UTC)
1475:14:08, 23 February 2010 (UTC)
1461:19:03, 22 February 2010 (UTC)
1411:07:51, 11 February 2010 (UTC)
314:for each period of inactivity
101:To make desysopping voluntary
1446:22:17, 8 February 2010 (UTC)
1397:22:12, 8 February 2010 (UTC)
1383:22:04, 8 February 2010 (UTC)
1366:05:23, 3 February 2010 (UTC)
1352:01:10, 3 February 2010 (UTC)
1335:16:49, 2 February 2010 (UTC)
1265:18:16, 30 January 2010 (UTC)
1241:20:24, 27 January 2010 (UTC)
1220:18:30, 27 January 2010 (UTC)
1200:14:21, 27 January 2010 (UTC)
1186:12:53, 27 January 2010 (UTC)
1166:17:38, 26 January 2010 (UTC)
1141:17:30, 26 January 2010 (UTC)
1120:16:48, 26 January 2010 (UTC)
1100:16:40, 26 January 2010 (UTC)
1085:16:30, 26 January 2010 (UTC)
1060:16:24, 26 January 2010 (UTC)
1021:16:23, 26 January 2010 (UTC)
1007:16:18, 26 January 2010 (UTC)
989:16:02, 26 January 2010 (UTC)
950:14:53, 26 January 2010 (UTC)
936:14:46, 26 January 2010 (UTC)
921:05:27, 26 January 2010 (UTC)
900:18:10, 25 January 2010 (UTC)
886:17:39, 25 January 2010 (UTC)
861:17:38, 25 January 2010 (UTC)
836:17:36, 25 January 2010 (UTC)
815:14:40, 25 January 2010 (UTC)
805:created. Feel free to edit.
792:00:31, 26 January 2010 (UTC)
777:09:50, 25 January 2010 (UTC)
734:04:46, 25 January 2010 (UTC)
720:04:10, 25 January 2010 (UTC)
706:03:34, 25 January 2010 (UTC)
692:05:50, 24 January 2010 (UTC)
677:20:05, 22 January 2010 (UTC)
640:20:04, 22 January 2010 (UTC)
606:19:59, 22 January 2010 (UTC)
577:19:57, 22 January 2010 (UTC)
545:21:26, 21 January 2010 (UTC)
524:19:12, 21 January 2010 (UTC)
510:02:54, 21 January 2010 (UTC)
490:02:45, 21 January 2010 (UTC)
455:02:39, 21 January 2010 (UTC)
440:02:31, 21 January 2010 (UTC)
419:01:59, 21 January 2010 (UTC)
406:01:56, 21 January 2010 (UTC)
385:22:38, 20 January 2010 (UTC)
360:21:50, 20 January 2010 (UTC)
346:21:38, 20 January 2010 (UTC)
326:21:30, 20 January 2010 (UTC)
306:21:19, 20 January 2010 (UTC)
284:21:05, 20 January 2010 (UTC)
262:20:42, 20 January 2010 (UTC)
247:20:39, 20 January 2010 (UTC)
214:20:34, 20 January 2010 (UTC)
200:20:32, 20 January 2010 (UTC)
186:20:23, 20 January 2010 (UTC)
173:20:21, 20 January 2010 (UTC)
158:20:17, 20 January 2010 (UTC)
123:20:16, 20 January 2010 (UTC)
83:20:04, 20 January 2010 (UTC)
64:20:13, 20 January 2010 (UTC)
31:Discussion working up to RfC
1228:for approval. Maybe ask at
410:We do nothing, of course. –
1835:
1791:18:10, 30 March 2010 (UTC)
1773:16:45, 30 March 2010 (UTC)
1759:16:15, 30 March 2010 (UTC)
1733:16:07, 30 March 2010 (UTC)
1718:15:59, 30 March 2010 (UTC)
1695:15:18, 30 March 2010 (UTC)
1680:15:08, 30 March 2010 (UTC)
1665:17:59, 23 March 2010 (UTC)
1632:08:52, 12 March 2010 (UTC)
873:Someone will need to ping
1819:19:37, 7 April 2010 (UTC)
877:when requests come in. –
1150:doesn't really matter
798:Local resignation page
1737:39 admins listed on
767:borrow their code.
292:anything by sending.
237:whether they do so.
1302:Feel free to edit:
1294:
1293:
1262:
1217:
1183:
1138:
1082:
1057:
918:
833:
574:
542:
507:
437:
403:
93:
1826:
1811:
1786:
1754:
1728:
1715:
1711:
1706:
1690:
1629:
1625:
1620:
1593:
1589:
1584:
1537:
1533:
1528:
1502:
1498:
1493:
1261:
1258:
1255:
1216:
1213:
1210:
1182:
1179:
1176:
1137:
1134:
1131:
1081:
1078:
1075:
1056:
1053:
1050:
946:
917:
914:
911:
847:Knowledge:Resign
832:
829:
826:
803:Knowledge:Resign
573:
570:
567:
541:
538:
535:
506:
503:
500:
436:
433:
430:
402:
399:
396:
87:
60:
27:
1834:
1833:
1829:
1828:
1827:
1825:
1824:
1823:
1809:
1782:
1750:
1724:
1713:
1709:
1704:
1686:
1650:
1627:
1623:
1618:
1591:
1587:
1582:
1547:least privilege
1535:
1531:
1526:
1500:
1496:
1491:
1485:
1429:
1322:
1300:
1298:To do as of now
1295:
1259:
1251:
1214:
1206:
1180:
1172:
1135:
1127:
1079:
1071:
1054:
1046:
944:
915:
907:
830:
822:
800:
571:
563:
539:
531:
504:
496:
434:
426:
400:
392:
96:Dead man switch
58:
32:
22:
21:
20:
12:
11:
5:
1832:
1830:
1822:
1821:
1803:
1802:
1801:
1800:
1799:
1798:
1797:
1796:
1795:
1794:
1793:
1735:
1649:
1646:
1645:
1644:
1643:
1642:
1641:
1640:
1639:
1638:
1637:
1636:
1635:
1634:
1561:
1484:
1481:
1480:
1479:
1478:
1477:
1428:
1425:
1424:
1423:
1422:
1421:
1420:
1419:
1418:
1417:
1416:
1415:
1414:
1413:
1321:
1318:
1317:
1316:
1313:
1310:
1307:
1299:
1296:
1292:
1291:
1290:
1289:
1288:
1287:
1286:
1285:
1284:
1283:
1282:
1281:
1280:
1279:
1278:
1277:
1276:
1275:
1274:
1273:
1272:
1271:
1270:
1269:
1268:
1267:
1102:
1042:
1038:
1026:
1025:
1024:
1023:
976:
975:
972:
965:
964:
963:
962:
961:
960:
959:
958:
957:
956:
955:
954:
953:
952:
866:
865:
864:
863:
839:
838:
799:
796:
795:
794:
757:
756:
755:
754:
753:
752:
751:
750:
749:
748:
747:
746:
745:
744:
743:
742:
741:
740:
739:
738:
737:
736:
653:
652:
651:
650:
649:
648:
647:
646:
645:
644:
643:
642:
617:
616:
615:
614:
613:
612:
611:
610:
609:
608:
586:
585:
584:
583:
582:
581:
580:
579:
552:
551:
550:
549:
548:
547:
478:
477:
476:
475:
474:
473:
472:
471:
470:
469:
468:
467:
466:
465:
464:
463:
462:
461:
460:
459:
458:
457:
309:
308:
293:
286:
235:
234:
233:
232:
231:
230:
229:
228:
227:
226:
225:
224:
223:
222:
221:
220:
219:
218:
217:
216:
136:
135:
134:
133:
132:
131:
130:
129:
128:
127:
126:
125:
110:
109:
108:
105:
102:
70:
69:
68:
67:
66:
34:
33:
30:
25:
23:
15:
14:
13:
10:
9:
6:
4:
3:
2:
1831:
1820:
1817:
1816:
1813:
1812:
1804:
1792:
1789:
1787:
1785:
1779:
1776:
1775:
1774:
1770:
1766:
1762:
1761:
1760:
1757:
1755:
1753:
1747:
1743:
1740:
1736:
1734:
1731:
1729:
1727:
1721:
1720:
1719:
1716:
1712:
1707:
1698:
1697:
1696:
1693:
1691:
1689:
1683:
1682:
1681:
1677:
1673:
1669:
1668:
1667:
1666:
1662:
1658:
1655:
1647:
1633:
1630:
1626:
1621:
1613:
1612:
1611:
1607:
1603:
1599:
1598:
1597:
1594:
1590:
1585:
1577:
1576:
1575:
1571:
1567:
1562:
1560:
1556:
1552:
1548:
1543:
1542:
1541:
1538:
1534:
1529:
1522:
1521:
1520:
1517:
1515:
1514:
1509:
1508:
1507:
1506:
1503:
1499:
1494:
1482:
1476:
1472:
1468:
1464:
1463:
1462:
1458:
1454:
1450:
1449:
1448:
1447:
1443:
1439:
1434:
1426:
1412:
1408:
1404:
1400:
1399:
1398:
1394:
1390:
1386:
1385:
1384:
1380:
1376:
1372:
1371:
1369:
1368:
1367:
1363:
1359:
1355:
1354:
1353:
1349:
1345:
1339:
1338:
1337:
1336:
1332:
1328:
1319:
1314:
1311:
1308:
1305:
1304:
1303:
1297:
1266:
1263:
1256:
1254:
1248:
1244:
1243:
1242:
1239:
1237:
1236:
1231:
1227:
1223:
1222:
1221:
1218:
1211:
1209:
1203:
1202:
1201:
1197:
1193:
1189:
1188:
1187:
1184:
1177:
1175:
1169:
1168:
1167:
1164:
1163:
1159:
1158:
1153:
1148:
1144:
1143:
1142:
1139:
1132:
1130:
1123:
1122:
1121:
1118:
1117:
1113:
1112:
1107:
1103:
1101:
1097:
1093:
1088:
1087:
1086:
1083:
1076:
1074:
1068:
1063:
1062:
1061:
1058:
1051:
1049:
1043:
1039:
1036:
1032:
1031:
1030:
1029:
1028:
1027:
1022:
1018:
1014:
1010:
1009:
1008:
1005:
1004:
1000:
999:
993:
992:
991:
990:
986:
982:
973:
971:
968:
967:
951:
948:
947:
939:
938:
937:
933:
929:
924:
923:
922:
919:
912:
910:
903:
902:
901:
897:
893:
889:
888:
887:
884:
882:
881:
876:
872:
871:
870:
869:
868:
867:
862:
859:
858:
854:
853:
848:
843:
842:
841:
840:
837:
834:
827:
825:
819:
818:
817:
816:
812:
808:
804:
797:
793:
789:
785:
780:
779:
778:
774:
770:
766:
762:
735:
731:
727:
723:
722:
721:
717:
713:
709:
708:
707:
703:
699:
695:
694:
693:
689:
685:
680:
679:
678:
675:
673:
672:
667:
666:
665:
664:
663:
662:
661:
660:
659:
658:
657:
656:
655:
654:
641:
637:
633:
629:
628:
627:
626:
625:
624:
623:
622:
621:
620:
619:
618:
607:
604:
602:
601:
596:
595:
594:
593:
592:
591:
590:
589:
588:
587:
578:
575:
568:
566:
560:
559:
558:
557:
556:
555:
554:
553:
546:
543:
536:
534:
527:
526:
525:
522:
520:
519:
513:
512:
511:
508:
501:
499:
493:
492:
491:
487:
483:
456:
452:
448:
443:
442:
441:
438:
431:
429:
422:
421:
420:
417:
415:
414:
409:
408:
407:
404:
397:
395:
388:
387:
386:
383:
382:
378:
377:
372:
367:
363:
362:
361:
357:
353:
349:
348:
347:
343:
339:
334:
329:
328:
327:
323:
319:
315:
311:
310:
307:
303:
299:
294:
290:
289:
288:My thoughts:
287:
285:
281:
277:
272:
271:
269:
265:
264:
263:
259:
255:
250:
249:
248:
244:
240:
215:
212:
210:
209:
203:
202:
201:
197:
193:
189:
188:
187:
184:
182:
181:
176:
175:
174:
170:
166:
161:
160:
159:
156:
154:
153:
148:
147:
146:
145:
144:
143:
142:
141:
140:
139:
138:
137:
124:
120:
116:
111:
106:
103:
100:
99:
97:
91:
90:edit conflict
86:
85:
84:
80:
76:
71:
65:
62:
61:
54:
50:
49:
48:
47:
46:
45:
44:
43:
42:
41:
40:
39:
38:
37:
36:
35:
28:
19:
1815:
1808:
1783:
1751:
1725:
1702:
1687:
1651:
1616:
1580:
1524:
1512:
1489:
1486:
1433:project page
1430:
1323:
1301:
1252:
1234:
1207:
1173:
1161:
1156:
1151:
1146:
1128:
1115:
1110:
1105:
1072:
1066:
1047:
1034:
1002:
997:
977:
942:
908:
879:
856:
851:
823:
801:
764:
670:
599:
564:
532:
517:
497:
427:
412:
393:
380:
375:
370:
365:
332:
313:
267:
207:
179:
151:
56:
1403:Throwaway85
1344:Throwaway85
784:Throwaway85
769:Throwaway85
712:Throwaway85
684:Throwaway85
632:Throwaway85
482:Throwaway85
352:Throwaway85
318:Throwaway85
239:Throwaway85
192:Throwaway85
165:Throwaway85
115:Throwaway85
1545:implement
1230:WP:BOTREQ
1739:WP:LOA/I
1714:Chequers
1628:Chequers
1592:Chequers
1536:Chequers
1501:Chequers
1320:Comments
761:WP:RFBOT
1483:wording
1253:Arcayne
1226:WP:BRFA
1208:Arcayne
1174:Arcayne
1129:Arcayne
1073:Arcayne
1048:Arcayne
945:MBisanz
909:Arcayne
824:Arcayne
565:Arcayne
533:Arcayne
498:Arcayne
428:Arcayne
394:Arcayne
59:MBisanz
1810:Enigma
1147:really
371:per se
113:policy
1710:Spiel
1624:Spiel
1588:Spiel
1532:Spiel
1497:Spiel
1152:which
1106:still
875:m:SRP
765:steal
333:don't
53:m:SRP
16:<
1784:xeno
1769:talk
1765:Gigs
1752:xeno
1746:list
1726:xeno
1705:Ϣere
1688:xeno
1676:talk
1672:Gigs
1661:talk
1657:Gigs
1648:Done
1619:Ϣere
1606:talk
1602:Gigs
1583:Ϣere
1570:talk
1566:Gigs
1555:talk
1551:Gigs
1527:Ϣere
1513:xeno
1492:Ϣere
1471:talk
1467:Gigs
1457:talk
1453:Gigs
1442:talk
1438:Gigs
1407:talk
1393:talk
1389:Gigs
1379:talk
1375:Gigs
1362:talk
1358:Gigs
1348:talk
1331:talk
1327:Gigs
1235:xeno
1196:talk
1192:Gigs
1157:Sher
1111:Sher
1096:talk
1092:Gigs
1017:talk
1013:Gigs
998:Sher
985:talk
981:Gigs
932:talk
928:Gigs
896:talk
892:Gigs
880:xeno
852:Sher
811:talk
807:Gigs
788:talk
782:be.
773:talk
730:talk
726:Gigs
716:talk
702:talk
698:Gigs
688:talk
671:xeno
636:talk
600:xeno
518:xeno
486:talk
451:talk
447:Gigs
413:xeno
376:Sher
366:ever
356:talk
342:talk
338:Gigs
322:talk
302:talk
298:Gigs
280:talk
276:Gigs
258:talk
254:Gigs
243:talk
208:xeno
196:talk
180:xeno
169:talk
152:xeno
119:talk
79:talk
75:Gigs
1780:. –
1341:-->
1247:API
1162:eth
1116:eth
1067:not
1003:eth
857:eth
381:eth
1771:)
1678:)
1663:)
1608:)
1572:)
1557:)
1473:)
1459:)
1444:)
1409:)
1395:)
1381:)
1364:)
1350:)
1333:)
1260:()
1215:()
1198:)
1181:()
1136:()
1098:)
1080:()
1055:()
1035:ec
1019:)
987:)
934:)
916:()
898:)
831:()
813:)
790:)
775:)
732:)
718:)
704:)
690:)
638:)
572:()
540:()
505:()
488:)
453:)
435:()
401:()
358:)
344:)
324:)
304:)
282:)
270:?
260:)
245:)
198:)
171:)
121:)
81:)
1767:(
1744:(
1674:(
1659:(
1604:(
1568:(
1553:(
1469:(
1455:(
1440:(
1405:(
1391:(
1377:(
1360:(
1346:(
1329:(
1194:(
1094:(
1033:(
1015:(
983:(
930:(
894:(
809:(
786:(
771:(
728:(
714:(
700:(
686:(
634:(
515:–
484:(
449:(
354:(
340:(
320:(
300:(
278:(
256:(
241:(
194:(
167:(
117:(
92:)
88:(
77:(
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.