Wikipedia talk:Requests for adminship

From Wikipedia, the free encyclopedia
(Redirected from Wikipedia talk:RfA)
Jump to navigation Jump to search
    Requests for adminship and bureaucratship update
    No current discussions. Recent RfAs, recent RfBs: (successful, unsuccessful)
    Current time is 02:57, 23 July 2024 (UTC). — Purge this page
    Recently closed RfAs and RfBs (update)
    Candidate Type Result Date of close Tally
    S O N %
    HouseBlaster RfA Successful 23 Jun 2024 153 27 8 85
    Pickersgill-Cunliffe RfA Successful 15 Jun 2024 201 0 0 100
    Elli RfA Successful 7 Jun 2024 207 6 3 97
    DreamRimmer RfA Withdrawn by candidate 31 May 2024 45 43 14 51
    Numberguy6 RfA Closed per WP:SNOW 27 May 2024 5 23 2 18
    ToadetteEdit RfA Closed per WP:NOTNOW 30 Apr 2024 0 0 0 0

    Extended-confirmed protection

    [edit]

    Apologies if this has been brought up before, but as Svampesky suggested here (and as I had been thinking myself), why don't we have a separate page for votes à la the comments sections on The Signpost? The vote page can be extended-confirmed protected and transcluded to the main, unprotected RfA page. This way non-30/500 folks can still comment and ask questions but their votes, by nature of not being able to be cast, won't have to be publicly struck off - what we're doing now is a bit bitey imo. Wilhelm Tell DCCXLVI (talk to me!/my edits) 05:37, 20 June 2024 (UTC)[reply]

    Or perhaps an edit filter that specifically detects edits to the Votes section and disallows non-ECP editors from submitting a vote? Is such a section-specific filter possible? Wilhelm Tell DCCXLVI (talk to me!/my edits) 05:41, 20 June 2024 (UTC)[reply]
    Detecting sections probably not, but detecting votes by non-ECP editors should be easy. Nobody (talk) 06:08, 20 June 2024 (UTC)[reply]
    The recent 2024 RfA review voted to prevent non-ECP editors from !voting and it was strongly supported. The closer of that review took the view that the vote was not to make the page ECP protected, but that was their view and I don't think it was properly debated.
    It makes no sense that an almost new editor can make comments on an RfA candidate, and ironically, when many of the typical objections are that the candidate does not have experience. At the 2024 RfA review, it seemed clear that there have been instances where the non-ECP/IP editor was an experienced editor trying to disrupt the process and derail the RfA. Aszx5000 (talk) 09:19, 20 June 2024 (UTC)[reply]
    The idea of an RfA is for any editor to bring up concerns that can refute the nominator(s)' assertion that the candidate is suitable for the mop. This is why Opposers are badgered if they don't give a rationale, even if they're otherwise respectable editors - let alone a throwaway doing the same thing and disappearing without explanation (which is why I think Kusma used the narrow language that they did while writing up the proposal, of explicitly saying comments were welcomed from all). In my opinion IPs and newbies should be allowed to bring up actual concerns, but if indeed the constructive-to-nonconstructive ratio here is extremely low as Extraordinary Writ said in Support #6, we could probably exclude them from that as well. Would need fresh consensus though ~ Wilhelm Tell DCCXLVI (talk to me!/my edits) 10:39, 20 June 2024 (UTC)[reply]
    Edit filters are run on every single edit page on the wiki, so they have a performance cost, and they are not usually a great choice for restricting very specific pages and sub pages. –Novem Linguae (talk) 11:49, 20 June 2024 (UTC)[reply]
    I'm so stupid, I read about this technical cost just a couple days ago. Yea edit filters are off the table –Wilhelm Tell DCCXLVI (talk to me!/my edits) 14:15, 20 June 2024 (UTC)[reply]
    Not a bad idea, but there'd be a cost in terms of making it more awkward to edit and watchlist the voting page, especially for the first few RfAs as people get used to it. I think the simpler option of just applying ECP to the whole page would be fine. Participation by non-EC editors was already very low before they were prohibited from voting, and if the handful that do find their way to an RfA really want to comment without voting, they could do so on the talk page and ask for it to be copied over. I agree that what we do now, making it look like anyone with an account can freely edit and therefore vote in an RfA, then striking the comment—because oops didn't you read down to the sixth subsection of WP:RFA??—is a pretty unfriendly approach. – Joe (talk) 13:11, 20 June 2024 (UTC)[reply]
    Right, I've thought up one more approach, so this can be framed as three proposals as below, for further input/consensus-building. In decreasing order of complexity:
    • Option 1: Votes shall be cast on a separate, EC-protected subpage that will be transcluded onto the main, unprotected RfA page.
    • Option 2: RfAs shall be EC-protected after the two discussion-only days. After this, IPs and newbies can bring up further concerns on the talk page.
    • Option 3: RfAs shall be EC-protected altogether. IPs and newbies can bring up concerns on the talk page alone.
    Is there a place for this to be proposed? RFA2024? Wilhelm Tell DCCXLVI (talk to me!/my edits) 14:23, 20 June 2024 (UTC)[reply]
    Should consider adding an "Option 4 - No change / status quo / strike non-EC votes" if you end up RFCing this. –Novem Linguae (talk) 14:31, 20 June 2024 (UTC)[reply]
    If these options are being considered, we could also consider making the watchlist notice visible only to extended-confirmed accounts. DanCherek (talk) 14:29, 20 June 2024 (UTC)[reply]
    I don't think using subpages will be an issue for adding comments. Wikipedia:Arbitration/Requests is set up with subpages and editing each section happens transparently. If desired, a link could be added to the top of the section to watchlist the subpage. An extra step would be required to create the subpage. isaacl (talk) 18:39, 20 June 2024 (UTC)[reply]
    • Why are we trying to solve a very minor problem with a long RFC discussion and new technical processes? I'd prefer Option 0: Just leave it as is, and any votes by non-EC people can quickly and easily be struck by, you know, humans. Who can leave a short message on the user's talk page. I understand the use of templates and bots and protection and edit filters for stuff that's overwhelming the humans, but this isn't. If anyone else agrees with me, perhaps they can better articulate this vague feeling I have that this increasingly common approach is the Wrong Direction(TM). --Floquenbeam (talk) 14:41, 20 June 2024 (UTC)[reply]
      I think there's a common belief that restrictions on new/unregistered users that rely on undoing/striking are more WP:BITEy than ones that technically prevent users from editing restricted spaces. I generally agree, but I don't think the trade-off is worthwhile if it inconveniences experienced editors and if the vast majority of participants are experienced. That's the case here; I'd prefer not to have a whole RfC about this, and if it does happen, I'm likely to vote Option 0, or what Novem is calling Option 4. Firefangledfeathers (talk / contribs) 14:55, 20 June 2024 (UTC)[reply]
      Well it needn't be long if we can simply find consensus right here, and these technical processes are hardly new. Most RfA regulars must be familiar with the Signpost approach and they'll be fine with whatever's up next. EC-protection is not complicated at all. The reason I am opposed to the current approach is purely because of how striking out the votes of newbies and IPs is BITE-ey. Consider their POV - they walk in, they find a community process they may be interested in, participate in it (because it seems to be allowed)... then bam, their vote has a black line through it and there's a senior editor on their page telling them they're not allowed to do that. In contrast, if they just see a blue lock right from the beginning, there won't be any hard feelings. This is pushing me towards Option 3. Wilhelm Tell DCCXLVI (talk to me!/my edits) 14:57, 20 June 2024 (UTC)[reply]
      Thanks for explaining the motivation. I guess I just really disagree; having a human come and explain why they can't vote yet seems much less bitey to me. I doubt anyone who isn't allowed to vote knows what a blue lock means, so they're going to try. I think all the system message says is something to the effect of "you can't edit this page", without explaining why. Floquenbeam (talk) 15:05, 20 June 2024 (UTC)[reply]
      On desktop, the system doesn't say a thing, they simply don't get the option to edit (only to view the source). On mobile, they get "this page has been protected" or similar. Wilhelm Tell DCCXLVI (talk to me!/my edits) 15:10, 20 June 2024 (UTC)[reply]
      Well, they can state a support/oppose opinion from a technical perspective; they're just not permitted to do so from a process perspective. If a human would pop up at the moment they tried to edit the page, sure, that would be ideal, but failing that, stopping them from being able to edit the page is, in my view, less confusing. isaacl (talk) 18:45, 20 June 2024 (UTC)[reply]
      Although I think that having a human explain it certainly is non-bitey, having their !vote stay on the RfA page with it struck-through isn't. For that reason, I like Options 2 and 3, because that prevents any embarrassment. There should be (yet another) note to that effect near the top of the RfA page, explaining the protection and pointing to the talk page, in the hopes that some will read it. --Tryptofish (talk) 19:48, 20 June 2024 (UTC)[reply]
    • Comment I was pinged in this. Leave it as is, the striking is okay and I didn't feel bitten. I'd've felt bitten if people got on my case about it, but no one did. I cast a new !vote and didn't reinstate the original one because it's nothing to be embarrassed about. You cast an invalid !vote, it’s not a big deal; good-faith mistakes aren't something that should be swept under the carpet. Svampesky (talk) 15:37, 20 June 2024 (UTC)[reply]
      How about this? Option 5:
      - Wikipedia talk:Requests for adminship/Username - Not protected (for comments)
      - Wikipedia:Requests for adminship/Username/!Votes - ECP protected
      - Wikipedia:Requests for adminship/Username - Not protected, but transcludes both above like The Signpost
      - Wikipedia talk:Requests for adminship/Username/Off-topic - Not protected (for the badgering) Svampesky (talk) 15:49, 20 June 2024 (UTC)[reply]
    • If protection would be too controversial, an alternative would be to have a large bold-faced red message that YOU ARE NOT ELIGIBLE TO !VOTE IN THIS RFA and then use Template:If extended confirmed and its relatives to hide it from anyone who's extended confirmed. A passing mention in the editnotice isn't conspicious enough to be noticed. Extraordinary Writ (talk) 20:27, 20 June 2024 (UTC)[reply]
      This seems like the best idea so far, since it is easy and effective and would not need an RFC. –Novem Linguae (talk) 20:30, 20 June 2024 (UTC)[reply]
      Out of curiosity, is it possible to nest if admin and if extended confirmed given that the latter doesn't hide text from admins? Perfect4th (talk) 20:43, 20 June 2024 (UTC)[reply]
      It is: see User:Extraordinary Writ/sandbox7. Extraordinary Writ (talk) 20:49, 20 June 2024 (UTC)[reply]
      This is actually harder than it looks as long as this and this remain unresolved. I guess the workaround in the current revision of User:Extraordinary Writ/sandbox7 does the trick, but maybe someone more technically minded can think of something better. Extraordinary Writ (talk) 21:40, 20 June 2024 (UTC)[reply]
      Maybe try <div class="extendedconfirmed-show sysop-show">Your message here.</div>. That might work and be a bit neater. –Novem Linguae (talk) 21:58, 20 June 2024 (UTC)[reply]
      Is there an easy way to do the opposite of that (to show it only to non-EC non-admins)? Typically <div class="nonextendedconfirmed-show nonsysop-show">Your message here.</div> would work, but interface admins haven't wanted to add nonsysop-show. Extraordinary Writ (talk) 22:10, 20 June 2024 (UTC)[reply]
      Ah, I forgot about the "else" case. Sadly, I can't think of anything better than what you have in the sandbox. –Novem Linguae (talk) 22:22, 20 June 2024 (UTC)[reply]
      The last thing is that sometimes editors with 500 edits/30 day account get EC removed. Usually it's an accident/side-effect when other roles are edited, like an admin resigning their bit. Is that enough people to add a fix for them? I don't think any template solution has a way to check edit count anyway. Soni (talk) 22:34, 20 June 2024 (UTC)[reply]
      Enacting this seems like the right move, would prevent an unnecessary RFC. As Floq said, this is a pretty minor issue that we shouldn't waste too much time with. ULPS (talk • contribs) 21:13, 20 June 2024 (UTC)[reply]

    Temperature check: Applying for the Researcher right

    [edit]

    The Researcher access right allows users to view deleted content, but not to actually delete (or block, or protect pages, or do anything else admin-y that isn't viewing deleted content).

    I am one of the more active admins on Commons (and just picked back up admin on Wikidata to better deal with cross-project spam), and it would be useful for me to be able to see user's deleted English Wikipedia contributions in order to better assess whether images nominated for deletion on Commons as spam are, in fact, spam.

    However, there really isn't a precedent for applying for this right, as far as I'm aware, so before I went down the path of actually trying, I wanted to do a temperature check to see if such a thing was something this community would even approve of.

    Cheers, The Squirrel Conspiracy (talk) 01:36, 21 June 2024 (UTC)[reply]

    @The Squirrel Conspiracy: It looks like we have 3 editors with this permission [1]. My gut instinct is to tell you that getting approved for this would be difficult. I wonder what people who are sysops on both projects think of these sorts of situations? There might be viable alternatives. Courtesy ping to Red-tailed hawk who happens to be the only person that I know to be an enwiki and commons sysop (at least off the top of my head). Clovermoss🍀 (talk) 03:19, 21 June 2024 (UTC)[reply]
    I don't know of any local process to grant it. My understanding is that the WMF holds that viewing deleted data is something that requires vetting (and requires some RFA-like process or elections for a local wiki to give out a role with that right), so we can't quite give it out ad-hoc.
    That being said, I believe that it is theoretically possible to create a local process to grant the right. We just don't have one on EnWiki, and the process would probably need some WMF eyes to actually get approval.
    Pinging @Vermont and RAdimer-WMF: Can you confirm my understanding on this is correct? — Red-tailed hawk (nest) 02:38, 22 June 2024 (UTC)[reply]
    Red-tailed hawk, thanks for the ping. I've brought this up internally and will get back to you when I can :) RAdimer-WMF (talk) 02:55, 22 June 2024 (UTC)[reply]
    @Red-tailed hawk: Any ideas on possible alternatives if this perm doesn't get granted for whatever reason? I'm not sure how common the above scenario described for the use case is. If it's a small scale issue, collaboration with individual enwiki admins might make it unnessecary. It likely wouldn't be all that different from the admins who provide copies of deleted articles to users with reasonable requests. Clovermoss🍀 (talk) 03:44, 22 June 2024 (UTC)[reply]
    @Clovermoss: Individual requests might be overkill. When an image on Commons gets tagged for deletion on Commons as spam and is in use in the draft space, I can check out the article and gain a lot of valuable content with just a quick glance - is this an SEO optimizer, someone writing an autobiography, a fan of the subject, etcetera. Being able to see deleted articles would extend this ability to gain said insight into situations where instead of a live draft space article, it's a deleted main space article. Most of the time, the file is going to get deleted as spam, but every once in a while, I catch that it's a fan or other genuinely good-meaning contributor that just doesn't know how to write in an encyclopedia style, and then I convert the speedy tag into a standard-length deletion discussion or outright save the image. That being said, the ratio of non-spam to spam among files tagged for speedy deletion as spam is pretty low, and the volume of such files is decently high, so I'd be doing, say, a lot of pinging admins on Discord to save very few files. The Squirrel Conspiracy (talk) 06:06, 22 June 2024 (UTC)[reply]
    There is a lot less friction if one does not have to involve someone else. We needn't use time from two persons to achieve one task when time from one would do quite well. — Red-tailed hawk (nest) 05:53, 24 June 2024 (UTC)[reply]
    First, I'm not sure who exactly can assign the researcher right, but I can tell you English Wikipedia admins can't. It looks like it may be a WMF-only thing. Secondly, maybe a friendly neighborhood WMF person (or bureaucrat, if they're capable) can remove researcher from the three people that currently have it? It doesn't seem like it was ever meant to be a permanent right. Finally, TSC, if you have any interest in being an en.wiki admin, I'd welcome an RfA. In addition to the cross-wiki spam you mention, you'd be an asset at WP:ERRORS. Firefangledfeathers (talk / contribs) 03:53, 21 June 2024 (UTC)[reply]
    This log does give the impression that these permissions were meant to be a temporary thing [2]. Clovermoss🍀 (talk) 03:59, 21 June 2024 (UTC)[reply]
    Only Stewards (and I guess sysadmins and WMF trust and safety but they probably won't get involved here) have the technical ability to assign the right. That fact doesn't really matter much here as I'm sure if whatever the community decides is the process for this is followed sufficiently one of them will be happy to oblige. * Pppery * it has begun... 04:20, 21 June 2024 (UTC)[reply]
    This situation also reminded me of Wikipedia:Requests for adminship/lustiger seth. It's rare, but there's definitely precedent for us to RFA someone who's already trusted elsewhere and use adminship in highly technical situations. Not sure how much this applies here though. Soni (talk) 06:08, 21 June 2024 (UTC)[reply]
    All three +researcher were performed by the WMF, and the first team at least were intended to be temporary, but never removed. MarcGarver (talk) 10:59, 21 June 2024 (UTC)[reply]
    In fact, based on the page at Meta, created by the WMF team, EpochFail and Jtmorgan can have the rights removed without further discussion as they were clearly only granted until 1 September 2011. MarcGarver (talk) 11:10, 21 June 2024 (UTC)[reply]
    Well, I tried to do so and am somehow unable. Filed phab:T368577. Joe Sutherland (WMF) (talk) 19:33, 26 June 2024 (UTC)[reply]
    As an update to anyone not following phab/meta, all three users had their researcher rights removed. So it's currently an empty user-right. Soni (talk) 23:06, 28 June 2024 (UTC)[reply]
    • Short answer: You'd apply via WMF. This community didn't ask for this permission to be built here, it was forced by the site owners, who control it. — xaosflux Talk 12:20, 21 June 2024 (UTC)[reply]
    • I think the correct way to do this would be to gain consensus that these set of rights can be unbundled, create a new userright with permissions analogous to the current researcher userright and then have it be assigned by bcrats or admins based on a community procedure/vote, all of which are a lot of work for the specific situation you are describing. Regarding the researcher right, I'm pretty sure that (AFAIK) it is only given to peeps who are working on a research project that requires access to deleted edits (say something like Empowering newbies: Investigating Harassment and Safety in Wikipedia), and I would assume that it would have to be assigned after WMF review.Sohom (talk) 14:23, 23 June 2024 (UTC)[reply]
    • I don't think there's community consensus to grant this perm to additional folks. It sounds like the 3 folks that were granted this 9+ years ago were granted it by WMF staff accounts. –Novem Linguae (talk) 03:58, 24 June 2024 (UTC)[reply]
      Exactly right - unfortunately we were a lot less organised that long ago, so there were no logs maintained for the issuance of these rights. I think it's totally fine to remove them, once it's possible to do so. Joe Sutherland (WMF) (talk) 19:35, 26 June 2024 (UTC)[reply]
    • The Squirrel Conspiracy: to get specific answers to questions about deleted content, you can ask at WP:REFUND you could get an opinion, a snippet of content, perhaps a restore as a draft, or an email with the content. So for occasional investigations, this would be far easier than creating a new user group and the procedures to cope with it. Graeme Bartlett (talk) 10:58, 24 June 2024 (UTC)[reply]
      or a RfA. 😁 – robertsky (talk) 11:04, 24 June 2024 (UTC)[reply]
    • I agree with Soni, I think Lustiger seth's RFA is the best equivalent to this. That passed at 77%, but it was in 2008. IMHO, a "view deleted edits only" RFA should pass for the same reason LS's did, but I have no idea what would happen today; community opinion is (for me) harder to predict these days. If you started an RFA with the attitude "if this fails, it will be because of people's opinion on how RFA should work, not their opinion of me specifically, and I will not let it hurt me", I think you might have a decent shot. Especially since I don't think there are currently other workable options. --Floquenbeam (talk) 12:21, 24 June 2024 (UTC)[reply]

    WMF reply about userrights

    [edit]

    Hey howdy, I was invited to comment by Legal via RAdimer-WMF since it's generally T&S who give out rights to staff. Looks like, as people have noted, this one was provided a long long time ago, before we maintained internal logs and before we had a robust requesting system. (The long-story-short is that we only provide rights to staff when necessary for job actions and only with approvals from their managers and/or our T&S Global Head.) Generally you all can do as you want with the Researcher right, but historical precedent would suggest splitting up the admin tools like this on a larger scale would likely require consensus. Joe Sutherland (WMF) (talk) 20:50, 28 June 2024 (UTC)[reply]

    @JSutherland (WMF): you all can do as you want: Are you ... sure? I was under the impression that WMF-legal required that anyone wanting deletedtext rights had to go through an "RFA or an RFA-like process". Has this changed? If a wiki holds an RFC tomorrow, and the outcome is "admins can unilaterally hand out researcher rights to anyone who asks nicely" WMF-legal would not object? Suffusion of Yellow (talk) 21:33, 28 June 2024 (UTC)[reply]
    Oh yeah, my bad, that's still technically the stance since I don't think it was ever re-evaluated (meta:Limits to configuration changes, Wikipedia:Viewing deleted content). Both of those stances are at this point thirteen years old in fairness, but yeah, you're right in that they're still current. Joe Sutherland (WMF) (talk) 21:40, 28 June 2024 (UTC)[reply]
    @JSutherland (WMF) Could WMF/WMF-Legal clarify if those stances have changed in the last 13 years? Or the more general "What rights can be unbundled from admin without requiring an RFA-like process"?
    This question has come up in RFA adjacent discussion for a few years with the WMF's final say being a deciding factor in "We cannot do this". Knowing which are currently considered un-bundleable will help enWiki evauate if any of them will be better off as separated. Soni (talk) 22:52, 28 June 2024 (UTC)[reply]
    Seconding this request. I'm generally not in favor of unbundling (and I don't think the community is either), but it would at least be good to know if the options have changed. The WordsmithTalk to me 23:00, 28 June 2024 (UTC)[reply]
    WMF appears to have actually gotten more lax in the viewdeleted requirements as the years go on, as the most recent stance appears to be that CU/OS can even be handed out without adminship or a community election process, so long as ArbCom allows community feedback. See here. I would be interested to see if the community would be in favor of unbundling these types of rights, though I think the chances probably sit somewhere just above "dead in the water" and below "it's possible?" in regards to actually getting an RFC. EggRoll97 (talk) 07:41, 1 July 2024 (UTC)[reply]
    Fwiw, a bunch of projects have non-admin CheckUsers, and the method of appointment is constrained to elections or ArbCom appointments. Personally, I strongly recommend against projects appointing non-admin CUs; it makes it a lot harder to make blocks based on nonpublic information when the people who have to make those blocks (non-CU admins) can't have that information. Vermont (🐿️—🏳️‍🌈) 17:58, 3 July 2024 (UTC)[reply]
    meta:Limits to configuration changes should be updated to meet current standards wrt handing out CU/OS. And personally, I agree. But I also would like clarity on what specifically can/cannot be unbundled (even if it's arbcom instead of elections). It'll let the community decide if anything else is better off as "Arbcom appoints" or even "Crat/admin appointed", even if I cannot currently think of any, offhand.
    (I have emailed this question to ca@wikimedia.org per Joe's suggestion) Soni (talk) 18:14, 3 July 2024 (UTC)[reply]
    It seems up-to-date to me: stewards handle the technical granting and removal of CU/OS pursuant to the global CU and OS policies. Vermont (🐿️—🏳️‍🌈) 18:20, 3 July 2024 (UTC)[reply]
    Ah I was missing that distinction, thank you. Is there a general "Arbcom can request stewards to assign these rights" list somewhere? Or is it just a special exception for CU/OS. Soni (talk) 18:34, 3 July 2024 (UTC)[reply]
    All grants for CU/OS are handled on Steward requests/Permissions. When ArbCom seeks to appoint a new CU or OS, they leave a request on Meta and a steward will verify and action it. If a project without an ArbCom elects a new CU or OS, they'll leave a request at the same place with a link to the discussion, and we'll verify it was done in line with policy. Vermont (🐿️—🏳️‍🌈) 20:42, 3 July 2024 (UTC)[reply]
    I think this question would need to be emailed to the team for discussion internally (and to track it for metrics etc) - ca@wikimedia.org Joe Sutherland (WMF) (talk) 21:39, 1 July 2024 (UTC)[reply]

    We were contacted about this through email - thanks! Here's what we replied:

    I spoke with the Legal team yesterday about this. They did mention that a complete answer to this would require a fair bit of research which they don't have the bandwidth for at the moment.

    I think the general consensus is that the issue is trust. An RfA process with community votes implicitly proves that the user has this trust from the community. While the risk of deleted content containing extremely private information is low, it is not zero, and as such we'd not be comfortable allowing users access to this without first proving they have the trust of the community.

    There could be other methods to "prove" this trust that serve the same purpose, but previous suggestions haven't been sufficient; a while back there was a proposal to give prospective admins a limited tool set but since these users were basically just picked by admins the trust element wasn't as strong.

    Joe Sutherland (WMF) (talk) 18:56, 22 July 2024 (UTC)[reply]

    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Requests_for_adminship&oldid=1236071068"