Jump to content

Wikipedia talk:Requests for permissions

Page contents not supported in other languages.
Page semi-protected
From Wikipedia, the free encyclopedia

Requirement AP: nearly perfect

The admin instructions for autopatrolled now say that a sample of articles need to be "nearly perfect", including details like the MOS. Is that too high a bar? I suggest we change this to "of high quality" instead. I don't think NPP checks for these more minor issues anyway.

I'm now declining if I see more than one uncited sentence across my sample of articles, but not for category or MOS issues, even though I do note them when I decline for issues with clop or citations. I believe that's in line with how others assess requests? —Femke 🐦 (talk) 17:45, 3 February 2025 (UTC)[reply]

Declining for an uncited sentence sounds a bit strict. Maybe uncited paragraph might be a good bar? –Novem Linguae (talk) 21:51, 4 February 2025 (UTC)[reply]
One uncited sentence I let slide, but if I see some uncited text in more than one article, I do decline now. This might still be too strict of course. The admin instructions do set a very high bar, which I don't think makes that much sense. —Femke 🐦 (talk) 08:40, 5 February 2025 (UTC)[reply]
Isn't it pretty normal to put citations at the end of a paragraph though? My understanding (correct me if I'm wrong) is that even at FA you don't need a reference at the end of every sentence. –Novem Linguae (talk) 21:06, 5 February 2025 (UTC)[reply]
Yes, when I say uncited, I mean fully uncited. For instance, a final sentence in a paragraphs, where the citation before that sentence does not cover the fact. It's permitted iirc, but discouraged, to put a citation "in the wrong spot", so you could have a fully cited paragraph, with the citation in the penultimate sentence. —Femke 🐦 (talk) 21:12, 5 February 2025 (UTC)[reply]
Honestly this is why I don't work on autopatrolled requests. I end up feeling like such a stickler and like very few are perfect enough in what they do, but the instructions do say to look for near perfection. Hey man im josh (talk) 13:15, 5 February 2025 (UTC)[reply]
Apparently, the requirement of 'nearly perfect' articles was added quite recently [1]. Novem, do you remember if you added this after a discussion? —Femke 🐦 (talk) 21:00, 5 February 2025 (UTC)[reply]
I don't recall exactly, but I probably added it after seeing the standards that WP:PERM/AP admins were using at that time. I remember autopatrol requests getting declined for things like not adding DEFAULTSORT. So I think my motivation was to align the instructions with current practice. I don't mind if you want to revert. From a high level perspective, I'd actually like to see autopatrol given out more easily, to help with the NPP backlog. –Novem Linguae (talk) 21:04, 5 February 2025 (UTC)[reply]
Thanks. I would like for us to check only core policies, as the NPP team doesn't check for formatting nitpicks anyway. There is diversity in how admins respond to requests, and many do not decline on these metrics. The decline reasons are simply more visible. Will revert when at computer tomorrow. —Femke 🐦 (talk) 21:16, 5 February 2025 (UTC)[reply]
I agree that we should generally adjust expectations for Autopatrolled downwards. Ultimately this user right's purpose is to control the queue of articles reviewed through NPP, and it should be serving that purpose, rather than anything else. As such, I think the bar for AP should be thought of as "Given the minimum standard we expect of an article to be marked as reviewed without significant numbers of tags also being added or modifications being made, does this user regularly create articles that meet or exceed that standard?" It shouldn't require any more than that to be an effective filter for the NPP queue, and I think the current standards are definitely way beyond this. Sam Walton (talk) 00:02, 6 February 2025 (UTC)[reply]

I've removed the sentence on formatting needing to be 'nearly perfect'. One other criterion I'm not certain about is "regularly create articles". I feel this is sometimes used to justify declining requests where we're got a slow steady pace of creation over a long period of time. This adds just as much to the NPP queue on average as somebody making articles over a shorter period of time, but flaming out after a year. —Femke 🐦 (talk) 08:09, 6 February 2025 (UTC)[reply]

EC-protection of PERM/NPR

Regarding [2], @Daniel Case: WP:NPPCRITERIA does include an EC-ish requirement but it also says administrators may grant the permission to editors who do not meet the strict criteria but that they otherwise deem to be competent. Requests by non-EC users are not very common but still permitted and I don't recall ever seeing any disruption from non-EC edits to WP:PERM/NPR, so protection seems unnecessary. – Joe (talk) 15:32, 29 May 2025 (UTC)[reply]

Pinging @GoldRomean: since they had requested it. Daniel Case (talk) 16:27, 29 May 2025 (UTC)[reply]
FWIW, the requests for AfC are extended protected. Also I think it's very unlikely that an admin will grant a non-ec request, and I see a lot of them being declined for simply the reason "does not meet min reqs". If one was truly serious about NPP, staying a bit until they do reach EC shouldn't be that hard. Ultimately I'll respect whatever ya'll (as the actual admins dealing with the requests) decide. Cheers, GoldRomean (talk) 17:02, 29 May 2025 (UTC)[reply]
I don't mind the protection. I don't think we grant exceptions often enough to justify the extra effort and sting of declining all the other requests. –Novem Linguae (talk) 03:34, 30 May 2025 (UTC)[reply]
"Unlikely" is not impossible and protection should be reserved for clear-cut cases of disruption. As I said, there has been no disruption from non-EC users editing WP:PERM/NPR. It rarely comes up and when it does it is not burdensome or stinging to occasionally write "sorry you're not eligible yet". What is the point of explicitly saying that exceptions are allowed in WP:NPRCRITERIA if we prevent people from asking for an exception at the software level?
Also Daniel, with all due respect to GoldRomean, it might have been a good idea to check with someone who is actually involved with NPP or PERM before fulfilling this request? – Joe (talk) 07:49, 30 May 2025 (UTC)[reply]
Joe Roe has reverted the protection. –Novem Linguae (talk) 16:28, 11 June 2025 (UTC)[reply]

Discussion at Wikipedia:Village pump (policy) § Adding checkuser-temporary-account to rollbackers and NPP folks

 You are invited to join the discussion at Wikipedia:Village pump (policy) § Adding checkuser-temporary-account to rollbackers and NPP folks. Sohom (talk) 17:39, 9 June 2025 (UTC)[reply]

RfC on new temporary account IP viewer (TAIV) user right

There is an RfC on the new temporary account IP viewer (TAIV) user right at Wikipedia:Requests for comment/Temporary account IP-viewer. voorts (talk/contributions) 17:03, 21 June 2025 (UTC)[reply]

"This access is only required for editing highly contentious pages"

WP:PERM/EC says "This access is only required for editing highly contentious pages...". This is false. I just had someone ask if it is possible to get EC early to use the content translation tool. May I update the text on the page?

Technically, there are other, more niche uses, like voting in RfAs and AELECT, but as I am certain that someone asking for EC solely for that purpose will be denied it's not worth mentioning. The content translation tool, on the other hand, does not seem as clear-cut. Toadspike [Talk] 16:23, 31 July 2025 (UTC)[reply]

I have edited the text to mention WP:CXT. Toadspike [Talk] 19:28, 31 July 2025 (UTC)[reply]
Looks good. I've tweaked things further. Schwede66 01:40, 1 August 2025 (UTC)[reply]
I reverted before seeing this discussion (sorry!), but I do disagree with adding this to the box. I don't think I've ever seen this granted early for content translation tool purposes, and since EC isn't required to use the content translation tool except in mainspace, we decline granting and direct them to target draft space with the tool and go through AFC instead. Adding content translation to the box here IMHO gives false hope as to someone's chances for getting EC early. stwalkerster (talk) 10:32, 1 August 2025 (UTC)[reply]
That's a reasonable explanation. I didn't know you could have the tool publish to draftspace. I would still remove the word "only" from the bit I quoted, though, since the statement as written is categorically false. Toadspike [Talk] 12:52, 1 August 2025 (UTC)[reply]
Oops, I misunderstood: you only reverted the second edit. I think the current version is good. Toadspike [Talk] 12:59, 1 August 2025 (UTC)[reply]

TAIV requirement of agreement to abide by Foundation policy

Resolved. voorts (talk/contributions) 19:19, 3 August 2025 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

@CoconutOctopus, Sohom Datta, Asilvering, HouseBlaster, Mz7, Femke, and Robertsky: I've noticed that many editors have been approved for the right without their application stating that they they agree to abide by the Foundation policy. I think we need to be careful to enforce that requirement. voorts (talk/contributions) 19:12, 3 August 2025 (UTC)[reply]

@Voorts: After being granted the right, folks do not immediately get access to the permission. They have to first opt-in via a checkbox in Special:Preferences which requires them to confirm that they agree to abide by the Foundation policy. Mz7 (talk) 19:13, 3 August 2025 (UTC)[reply]
That, I don't think we should be the ones policing that part. Sohom (talk) 19:15, 3 August 2025 (UTC)[reply]
Fair enough. voorts (talk/contributions) 19:15, 3 August 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Process for granting TE to DYK editors?

Moved from WP:PERM/TE § User:Darth Stabro
WT:DYK should really come up with a formal criteria/guidelines for granting the right and aim for a amendment to WP:TPE. The WP:TPE criteria and this process were never meant to deal with these kinds of requests (primarily because the folks who watch this venue are technical admins and have limited interactions with WP:DYK). See also Hilst's request at [3] which imo was also misjudged. Sohom (talk) 14:56, 7 August 2025 (UTC)[reply]
Or they really should split "DYK queue editor" out of "template editor" as a completely separate right. The current situation is an affront to logic. * Pppery * it has begun... 14:59, 7 August 2025 (UTC)[reply]
We do not need all these separate user rights, we just need to give out adminship to everyone who would volunteer more effectively with it. I would happily vote for abolishing the template editor permission. —Kusma (talk) 15:13, 7 August 2025 (UTC)[reply]
@Kusma That is very much a systemic issue, I think the WP:TPE user-right has a place when it comes to technical work -- it is a simple check of "do you understand that editing templates is very different from normal editing with different social expectations". However, WT:DYK appears to see it more as "adminship but not really" and that thinking is (I agree with you) kinda redundant and flawed to begin with and should be remedied by giving out adminship more freely. Sohom (talk) 05:52, 8 August 2025 (UTC)[reply]
I agree that how DYK uses TPE is a bit weird, but it was a reaction to an untenable situation. We had a chronic problem with not enough people working on queues. The few admins working on that were burned out and the work wasn't getting done. And unlike most other processes on the wiki, DYK runs on a clock. When the big hand hits midnight and all the queues are empty, that's bad.
Despite numerous entreaties to the various regulars who were working on other DYK tasks, I was unable to convince any of them to run for admin. I agree with @Pppery that a distinct user right (or a more fine-grained user rights system in general) would make more sense, but we don't have that. So, given a toolbox stocked with a variety of tools that don't fit our needs, we've gone with the least bad way to get done what we needed to get done. Since we've done that, DYK has been running a lot better (i.e. not in a state of perpetual crisis). If the cost of fixing DYK was that WP:PERM occasionally has to handle requests that it's not really set up for, I'm happy with that. If somebody wants to do the legwork to get a new DYK-specific permission created, I'd be happy with that too. RoySmith (talk) 12:26, 8 August 2025 (UTC)[reply]
The only thing stopping us from creating a separate permission is internal bureaucracy. It's a technically trivial to go through the m:Wikimedia site requests process. * Pppery * it has begun... 15:44, 8 August 2025 (UTC)[reply]
Having never done that, my guess is you need to create both a new type of page protection and a new user right which grants you the ability to edit through that type of protection. And maybe a role which includes that right? And then perhaps some interface changes to include the appropriate menu items and/or checkboxes to grant/revoke those things?
And, of course, the really hard part would be the haggling over what to name these things :-) RoySmith (talk) 18:46, 8 August 2025 (UTC)[reply]
Pretty much that. But this is all something the people there are familiar with, and would no doubt be willing to do. Especially since it's technically the same as the existing TPE right, in terms of changes to the config files. It's something that, given sufficient consensus, I might code up myself. * Pppery * it has begun... 19:00, 9 August 2025 (UTC)[reply]
I would like to point out that the biggest problem we have had with using templateeditor for editing the queues has been the lack of clarity on who is responsible for granting the right to candidates, as evidenced by this very discussion. In other words it has been extremely successful and not caused any major problems. —Kusma (talk) 13:23, 8 August 2025 (UTC)[reply]
Perhaps the right thing would be for the candidate to first ask at WT:DYK and if consensus emerges, then come here for the rubber stamp, providing a link to the WT:DYK discussion. Stewards use that process when approving permission grants which have been discussed elsewhere. RoySmith (talk) 14:09, 8 August 2025 (UTC)[reply]
I know nothing about the inner workings of DYK, but I occasionally dabble in WP:PERM and, speaking for myself, I would not be opposed to granting TPE to editors who deal with DYK queues, provided they showed familiarity with that process and I trusted them not to break anything with the new userright. For me, it's a matter of trust, in the end. After all, it's the same for administrators: we have the technical ability to do many things and, for the most part, we try to stay away from areas where we know we may cause damage through lack of competence or familiarity. —  Salvio giuliano 14:25, 8 August 2025 (UTC)[reply]
I don't see a need to rubber stamp at PERM, individual admins can grant rights when they need to. —Kusma (talk) 14:32, 8 August 2025 (UTC)[reply]
I don't think a project can develop criteria for granting a permission on the project. And let me note my general agreement with Kusma's first comment: I think we should be nudging more people to adminship. This creates a wider project capacity in multiple ways, including allowing for no friction opportunities for that editor to eventually branch out into new areas whether they stay with just +sysop or they decide they want to try CU/OS/ArbCom where +sysop is a prerequisite. Best, Barkeep49 (talk) 14:30, 8 August 2025 (UTC)[reply]
I fear that it would be a case of the perfect being the enemy of the good, however. Admin elections have somewhat made the problem better, but admin selection is still broken. Nudging more people to adminship would force them to subject themselves to a process which can be, and has been multiple times in the past, unpleasant and hostile. So, yes, while we should continue to improve the way we select administrators, as a stopgap measure I see nothing wrong with using TPE for the purpose. —  Salvio giuliano 14:39, 8 August 2025 (UTC)[reply]
Yes, I would prefer that we spend time figuring out how to improve processes for helping people to pass RfA, than to further devolve tools as a "solution" to the problem. For me that includes needs that various projects have around maintaining front page content. Devolution creates other problems, as I noted in my original comment. Best, Barkeep49 (talk) 14:49, 8 August 2025 (UTC)[reply]
The concepts of granular permissions and asking for additional permissions are extremely un-wiki. Having to ask or making edit requests is the standard process in the non-wiki world; the wiki way is to make everything as open as possible and to just revert when people get something wrong. To give an example from my own experience, as someone who is not really a techie, I would never have applied for something like editing rights to the MediaWiki namespace, but as I have them as part of the sysop package, I have been able to WP:BOLDly make fixes. no friction opportunities [...] to eventually branch out into new areas are empowering and help people grow as editors and admins. —Kusma (talk) 15:02, 8 August 2025 (UTC)[reply]
I disagree that we (admins) cannot ask a project for what they feel would be an appropriate metric for making what is essentially an equivalence principle to our existing guidelines; as SD0001 stated, to the unfamiliar admin 32 promotions might seem like a suitable equality to 3 sandboxes/5 requests, but the DYK folk find that insufficient. If someone were to say "the DYK folk want me to have this perm to help out" I would absolutely grant if the other criteria were solid. Primefac (talk) 14:29, 9 August 2025 (UTC)[reply]
I think requesting a non-TE requesting to fill queues would count as a TE edit request. Possibly also my edit request to AmandaNP's userpage (to reflect the fact she no longer hold CU/OS rights) also counts seeing as her user page is TE, even though I didn't use the request parameter. JuniperChill (talk) 21:51, 9 August 2025 (UTC)[reply]
If someone has a non-standard use for a permission, I don't have a problem with it outright; especially for well established applicants that will limit use to a niche purpose. Mostly the same as someone that wants to deal with a few highly visible templates that also has no skill with LUA - it's not a showstopper. — xaosflux Talk 14:34, 8 August 2025 (UTC)[reply]
Same, but at the moment (at least from my perspective) DYK is enough of an outlier that I'm not always sure how much of a need someone has for the right. Primefac (talk) 14:29, 9 August 2025 (UTC)[reply]
If formal criteria are requested: perhaps 600 prep set promotions for a rubber stamp approval at PERM, and less than that requires WT:DYK approval? ~~ AirshipJungleman29 (talk) 15:03, 8 August 2025 (UTC)[reply]
Counteroffer: 100 promotions or demonstrated clue at DYK. —Kusma (talk) 12:51, 9 August 2025 (UTC)[reply]
I said at the original DYK discussion on this topic that I was opposed to allowing would-be DYK template editors to simply nudge a friendly admin to get the permission, and that there should be a more robust process. Having said that, there haven't been any DYK disasters since the system was implemented, but I would still like to see greater transparency. To that end, I could endorse RoySmith's suggestion that seekers of the permission for DYK purposes get consensus at WT:DYK first, or, at minimum, at least flag the DYK community at said talk page that they intend to seek it so that DYK regulars can contribute to the discussion. There should also be a minimum period of discussion before the right is granted, say, one week. Gatoclass (talk) 11:45, 9 August 2025 (UTC)[reply]
Why should template editor for DYKers ve the only permission with forced discussion period? Generally we should aim to reduce bureaucracy around permissions. —Kusma (talk) 12:50, 9 August 2025 (UTC)[reply]
Well it's not the only permission - there are also set discussion periods for adminship, for example. And why have it? Because not everybody is watching WT:DYK like a hawk and users may need some time to notice the discussion. Gatoclass (talk) 14:19, 9 August 2025 (UTC)[reply]
The admin-granted permissions do not require discussion. If we ask for a week long discussion I think we should go back to full protection: after a week long discussion people should just become admins. —Kusma (talk) 15:00, 9 August 2025 (UTC)[reply]
What's the big deal over waiting a week to close the discussion? It just gives interested parties an opportunity to participate. If you are not going to have a set time for discussion you might as well just allow admins to grant the permission unilaterally, and there are obvious hazards with such an approach. Gatoclass (talk) 18:03, 9 August 2025 (UTC)[reply]
I have granted the TE permission unilaterally to @AirshipJungleman29 and @Theleekycauldron; both of these were good decisions that would not have been improved by a week of discussion. I oppose any additional bureaucracy; indeed that is a big deal to me. We have lost the ability to easily give people +sysop; let us not lose the ability to easily allow people to edit DYK queues. —Kusma (talk) 18:30, 9 August 2025 (UTC)[reply]
I know the inner workings of DYK very well. What RoySmith says in his first post is entirely correct: this initiative has made a substantial improvement to the project. There are only ever a handful of editors who have the necessary experience to work with queues who are not admins. The DYK admins will be able to judge who those editors are and they can grant TPE. I see zero need to formalise anything; what's happening is working well. We should have this discussion when problems arise. At the moment, this discussion is in search of a problem that does not exist. Schwede66 15:22, 9 August 2025 (UTC)[reply]
@Schwede66 The problem is that the admins who are manning WP:PERM/TPE have nothing to go on when they need to decide whether to grant a request when a user primarily requests it for edits to DYK queues. I think the answer/consensus in this thread is that to get TPE for editing DYK, a user should eithier ask a DYK admin or start a lightweight discussion on WT:DYK and not ask for it at WP:PERM/TPE. I think that itself is a valid outcome and could be a workable solution over the status quo if we decide to document it somewhere. Sohom (talk) 18:51, 9 August 2025 (UTC)[reply]
Agreed. I think some requests have come up here because some of us DYK admins have tried not to overstep our authority, but it makes a lot of sense for us to just handle this in house. —Kusma (talk) 19:11, 9 August 2025 (UTC)[reply]
I see. Sorry, I wasn’t aware of it. Yes, it’s easiest if this gets assigned based on a discussion at DYK talk. Schwede66 19:17, 9 August 2025 (UTC)[reply]
  • Someone should probably WP:RFCBEFORE some text to add to Wikipedia:Template editor#Guidelines for granting, then RFC it, then we make the change. There's enough lack of clarity and consensus in this discussion that I think an RFC would be helpful to crystallize things. –Novem Linguae (talk) 16:00, 9 August 2025 (UTC)[reply]
    I think we've pretty much converged on adding the following to Wikipedia:Did you know/Admin instructions:

    The queues are template protected, so you need to either be an admin or template editor to edit them. Editors lacking the required permissions who have extensive experience at DYK (including promoting hooks and managing the prep area) and wish to help manage the queues may make a request at WT:DYK; if there is consensus to do so, an admin will grant you the Template Editor user right.

    In addition, the top two queues currently active set and the top queue are subject to the Main Page cascading protection, so you need to be an admin to edit those.

    Any objections to my adding that? RoySmith (talk) 19:33, 9 August 2025 (UTC)[reply]
    Only the top queue is cascade protected, not the top two. Other than that I think this is what we converge on. —Kusma (talk) 19:42, 9 August 2025 (UTC)[reply]
    Hmmm, yeah, I worded that badly. It's the currently active set and the top queue. Thanks for pointing that out. RoySmith (talk) 19:46, 9 August 2025 (UTC)[reply]
  • Fundamentally, we might have made becoming a queue mover easier by removing all the trappings of RfA and letting any admin grant the perm, but the DYK-based qualifications for moving queues are essentially still the same. There are a couple of people in this thread, myself included, who ran at RfA and failed even though the community thought we were more or less qualified to do the tasks at DYK specifically – we just had other issues to overcome that led the community to oppose adminship. That's the scenario where I think template editor should be granted: if, but for other issues, an editor would pass an RfA where their Q1 pitch was becoming a DYK admin. (and if they would pass outright, we should push them into doing that, but that's a broader issue). SL93, Launchballer, Airship, NLH, all of them would meet and exceed the RfA criteria on that narrow question. For the request that spawned this thread, I don't think the same is true. theleekycauldron (talk • she/her) 19:24, 9 August 2025 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Requests_for_permissions&oldid=1305070848"