Wikipedia talk:Non-admin closure/Archive 3

Proposal - limiting use of WP:XFDCloser to those on a list, similar to WP:AFC tool user list
Based on this discussion from WP:ANI (permalink) in the last day, I think it's time to move it here for wider discussion. I have copied the relevant part of discussion from there to the collapsed-and-archived area below for easy reference.

TL;DNR version: Sometimes people "clerk" at XfD discussions but do a poor job. Restricting the XFDcloser tool to people who have some experience on Wikipedia and revoking it from those with demonstrated incompetence should incentivize competence and reduce the cleanup workload caused by people who make too many mistakes, without resorting to topic bans or blocks. The WP:Articles for Creation process already works this way: You are not allowed to use the AFC scripts unless you have signed up at WikiProject Articles for creation/Participants, and your access to the scripts can be revoked if necessary. You can technically still do AFC work without scripts, but it is much more tedious and is strongly discouraged.

Initial feedback was positive, so I'm bringing the idea here for wider discussion.


 * Note: Copied from WP:ANI (permalink) at 17:07, 23 September 2020 (UTC).


 * Non-admin comment: Here's an idea, but I wanted at least a couple of people to give feedback before I post it at Wikipedia talk:Non-admin closure: Perhaps "non-admin closures" for certain types of discussions should be changed into something like the WP:AFC process, where "tools to make it easy" are only available to people who sign up, and if you sign up and display incompetence, you lose access to the tools.  It wouldn't change who could do a non-admin closure, but it would incentivize competence.  davidwr/  (talk)/(contribs)  23:20, 22 September 2020 (UTC)
 * That's an intriguing idea david - essentially limit XfD closer to those who have been granted a pseudo perm. As someone who has concerns about non-admin closing at AfD in a way that those who frequent some other deletion areas don't that could be a good way to nuance this. Best, Barkeep49 (talk) 23:57, 22 September 2020 (UTC)
 * (non-admin comment) - The one thing to keep in mind is that it would probably be best to keep a way to close your own nomination as a speedy keep withdrawn. That's about the only time I use XFD closer at AFD, although I do clerk RFD on very rare occassions.  Seems like withdrawing your own nomination is a fairly uncontroversial NAC, generally. Hog Farm Bacon 02:03, 23 September 2020 (UTC)
 * (non-admin comment) I think this is an excellent idea. I've never closed an XFD, and have no intention of doing so. I have the WP:APAT and WP:PGM privileges, and had to ask for them and show that I knew what I was doing. To assess competence at WP:AFD, there's the AFD Statistics Tool - %ages for initial sorting, and a list of recent contributions to show activity level and to weed out anyone who might be piling-on.
 * This idea would also give pileologists a useful way to indulge their hobby. Requests are likely to be rare once established XFD closers have been grandfathered in, and so unlikely to consume much admin time.
 * Another way to handle self-withdrawal might be something like the db-author tag for pages you're sorry you created. — Preceding unsigned comment added by Narky Blert (talk • contribs) 22:20, September 22, 2020 (UTC)
 * Except withdrawal often occurs after someone else points out that you missed something. See Articles for deletion/Budget Cuts, where me withdrawing quickly was the best course of action after it had been proved notable, but db-author wouldn't work, as I was not the only primary editor, and the discussion there should likely be kept around for posterity about the notability of that article.  Seems like leaving a technical exception for self-withdrawals is maybe a good thing to leave open. Hog Farm Bacon 14:10, 23 September 2020 (UTC)

I will be posting a notice of this discussion on Wikipedia talk:XFDcloser, on the ANI discussion cited above, and Wikipedia talk:Deletion process shortly. davidwr/ (talk)/(contribs)  17:07, 23 September 2020 (UTC)
 * May I suggest a notice at WT:DRV as well, as DRV often has to deal with the results of bad (or allegedly bad) closings of deletion discussions. DES (talk)DESiegel Contribs 17:22, 23 September 2020 (UTC)
 * Note: This discussion has been announced at WT:XFDcloser, WT:Deletion process, and WT:Deletion review. davidwr/ (talk)/(contribs)  17:35, 23 September 2020 (UTC)

Discussion - limiting use of WP:XFDCloser

 * Clarification needed: under this proposal, users not on the list would lose access to the XfDCloser scripts, but are they allowed to close discussion manually? --Dps04 (talk) 17:24, 23 September 2020 (UTC)
 * I would guess yes, since you can't technically stop someone from closing XFDs without a tban. Primefac (talk) 17:33, 23 September 2020 (UTC)
 * Yes, this proposal is only to restrict access to XFDcloser and possibly other tools that do the same job, not one's ability to actually edit the pages to effect a manual XfD close. That said, over time a future consensus may develop that if you've had tool access removed, there is a de facto topic-ban on closing XfDs, but I think it will be months or a year or more before such a consensus develops, if it develops at all, so let's not muddy the waters with it except to acknowledge that it might happen.  davidwr/  (talk)/(contribs)  17:40, 23 September 2020 (UTC)
 * I'm very much in favour of something like this; in fact I was one of the main proponent of trying to introduce an non-admin closer permission in the section above. Sadly both and I, the two most involved people, got quite a lot less active as a result of this springs events meaning it stalled before the RfC was started. --Trialpears (talk) 17:26, 23 September 2020 (UTC)
 * - indeed, that was a detailed draft we were working on. Do you have a link, I've had a hunt but can't find the draft proposal. I think its general and AfD sections might be of use as a proposal, but we'd probably want to leave all of the other XfDs for separate discussion, as we felt we'd need fairly detailed input from each one as to what level of participation in the userright, if at all, they wanted. Whether as part of that or any distinct proposal, we need to know if there's a way that AfD can be limited to a (pseudo)-userright, without cutting off, say CfD/TfD users (or causing problems by auto-granting there). Nosebagbear (talk) 17:59, 23 September 2020 (UTC)
 * Non-admin closure/draft and it's definitely technically possible to limit only certain venues; Evad37 the maintainer of XFDCloser is quite active and some other people could possibly write an update as well, including me if no one more experienced is willing. --Trialpears (talk) 18:15, 23 September 2020 (UTC)
 * I would not want to start closing if I did not have access to XFD closer. I pity any potential-NACer who would like to close things as well. It might be preferable to add a blacklist for users who are having problems using this tool. --Izno (talk) 18:30, 23 September 2020 (UTC)
 * I nac-close so rarely that I usually do it by hand. Doing it by hand invites, almost forces, you to think about what you are doing and why you are doing it. It also forces you to double-check everything to avoid leaving loose ends un-done.  In any case, one of these days I will install the tool and do more XfD non-admin-closures.  davidwr/  (talk)/(contribs)  18:43, 23 September 2020 (UTC)
 * Self-followup: I was doing WP:AFC reviews by hand way back in the day before the scripts were written.  Then I left for a few years and came back.  I had to add my name to the list to be allowed to use the AFC tools. It took a day or two for me to be added to "the list" of approved AFC script users. Before asking for access, I made sure I understood how AFC had changed over the years.  Before getting access, I took the time to do at least one AFC review "by hand" since even the "manual" process had changed over the years.  It was a very educational experience, both from a "re-learn the technical aspects" end and the "learn what AFC is TODAY, it's changed since you were a big-time AFCer back in the day.
 * Bottom line: I recommend everyone new to a particular XfD including administrators new to a particular XfD do at least a few actual, possibly supervised, XfD closes or mocked-up "fake" XfD closes of that type before asking for or being granted access to the tools.  It teaches a lot, and it demonstrates competence.  OK slight correction:  Administrators should get the tools upon getting the bit, but they should be encouraged to do a few "by hand" for the experience it provides.  davidwr/  (talk)/(contribs)  18:56, 23 September 2020 (UTC)
 * I have both practical and doctrinal concerns. On a practical level I doubt this will affect me personally since I've been here a while and I don't think anyone has had problems with XfD's I've closed. That said, there is a maintenance cost associated with this.  Who controls access to the list, who removes people form the list, what standards it takes to get on the list, etc. etc. add up to non-trivial maintenance burdens.  Unless there is a definite agreement that these maintenance tasks will be undertaken by particular users or (preferably) admins, we are committing some other editor to taking up a burden for us.  That is both unfair and likely to fail.
 * On the doctrinal side, I generally dislike creating in-groups and out-groups within the WP community that can create "second-class editor" status perceptions. The barriers to entry for new editors are already very high and are growing all the time.  Each and every time that a new barrier has been erected, the arguments in favor of it are essentially the same: "Yes, well, we like to treat editors the same but this particular area of editing activity needs more control and editors need more experience to participate." Pending changes, page protection, AfC, etc. are all in and of themselves perfectly defensible and in some cases absolutely necessary.  Raising barriers to entry on a website with declining participation is a recipe for disaster, however.  I'm not convinced that this particular barrier is one that is necessary. There have been, what, 5 or so AN/ANI threads this calendar year about inexperienced users closing or relisting inappropriately?
 * Overall, the documented level of disruption that this attempts to address does not appear to justify this particular barrier or outweigh the maintenance costs we are evidently planning on getting some-one else to undertake. Temporary frustration is not a good reason to create permanent solutions. Eggishorn (talk) (contrib) 18:44, 23 September 2020 (UTC)
 * ... the documented level of disruption that this attempts to address does not appear to justify this particular barrier or outweigh the maintenance costs we are evidently planning on getting come-one else to undertake.
 * This type of "cost benefit analysis" is something that should be done before proceeding before any big/expensive change like this. Thank you for bringing it up.  Sometimes the gain is worth the pain, sometimes it is not.  davidwr/  (talk)/(contribs)  18:59, 23 September 2020 (UTC)
 * So consideration that the disruption is usually temporary is part of why I didn't return to this a couple of months when I realised I'd left it by the wayside when some minor IRL events occurred around March. Another part is that I am strongly against some of the additional restrictions on NACers proposed - if we wanted extra safeguards I'd much rather limiting the pool than further limiting the abilities and thus, utility. If people feel that it's not necessary to rewrite both the rules and the gadget in order to handle disruption that occurs a few times a year, that's fine with me. Nosebagbear (talk) 19:12, 23 September 2020 (UTC)
 * There is, in my view, ongoing regular disruption at AfD; this has basically been my view since before I became an admin and continues to be a problem I see now as an admin. Essentially whenever I take a look at the NAC for a day I find someone who is doing it who's not qualified (and sometimes I don't have to go looking - they show up to an AfD I'm watching). When I come across it I either ask questions or write a nice note asking them to reconsider what they do. This is normally effective. This might only rise to level of disruption worth someone formulating an ANI thread about it a couple times a year but imperfect NAC is a regular ongoing problem at AfD. And I am entirely open to the idea that this is, purely, a problem at AfD which is the most prominent and busy of our deletion venues. Best, Barkeep49 (talk) 19:40, 23 September 2020 (UTC)
 * , I've read this comment and the one you made below and I have to admit to some confusion. You state that the normally effective intervention is just a word from an admin but also say that it regularly disrupts AfD.  I'm not clear if you think that the proposed solution is preferable to the normally effective one or if the regular disruption of AfD is addressed by the proposed solution. I realize that sounds like, "please express yourself according to my preferred terms of discussion" or something but I honestly don't know how your comments should be read in relation to the proposal. Thanks in advance. Eggishorn (talk) (contrib) 20:12, 24 September 2020 (UTC)
 * , happy to clarify. I support this change but it's really about AfD for me. I'm not sure it's necessary or needed (and potentially counterproductive) at other deletion venues. Best, Barkeep49 (talk) 16:10, 25 September 2020 (UTC)


 * I've dropped some suggested criteria below. Personally I think 6 months may be a little long, while 3 would be too short. No technical reason we can't go for 5 months etc, or could rely on the exceptions bit. 3-5 all seems reasonable non-controversial, the specifics (or even relevance) of 2 could also be disputed. Nosebagbear (talk) 19:53, 23 September 2020 (UTC)
 * I participated in working on this draft and I think the language is heading in the right direction. My only comment, which did not carry the day in the draft discussion, is that if we are going to consider making AfD closures a user right, we should consider a separate question of whether a NAC should be limited to uncontroversial keep discussions or expanded to close all types of discussions. But, this could also be a separate discussion and I don't think it should derail the current proposal. --Enos733 (talk) 20:10, 23 September 2020 (UTC)


 * Oppose There is usually a significant backlog at XfD, and this would make that problem significantly worse. I know there are some editors who loathe NAC, but it would make more sense to set up a blacklist for the small number of editors who are actually causing problems. (t &#183; c)  buidhe  21:46, 23 September 2020 (UTC)
 * Oppose AFC is not a good model as it is permanently backlogged and generally agreed to be dysfunctional. See also WP:CREEP. Andrew🐉(talk) 07:11, 24 September 2020 (UTC)
 * I agree we're backlogged. But the solution to that isn't to have more people who are unqualified performing closes, it's to have more people qualified to do so doing them. Best, Barkeep49 (talk) 14:49, 24 September 2020 (UTC)
 * Comment: I am not too concerned that creating this pseudo-perm would greatly increase the backlog (as suggested above), as most XfD discussions today are closed by administrators anyway. We have AfDs dating back to Sept 11 (13 days ago!) still open, and even if all non-admins are allowed to use the XfDtool (as is the case now), the backlog still exists, simply because no non-admin would dare to close such discussions without being immediately accused of BADNAC. If we want to solve the backlog at XfD, the solution is to either (1) appoint more admins who would work in the XfD area, or alternatively (2) expand the closing powers for some selected, trusted, experienced non-admins (who would be the users with this pseudo-right), and allow them to close some controversial discussions (with the understanding that the most controversial ones are to be left to admins). If the proposal seeks to allow experienced non-admins to close discussions AND (at least slightly) expand their closing powers, I can reasonably see the backlog going down, not up. --Dps04 (talk) 09:43, 24 September 2020 (UTC)
 * I also think this is unnecessary bureaucratic creep. Bad closes aren't that common and can usually be handled with a quiet word to the (invariably new) editor doing them. A key difference between AfC and AfD here is that, while bad AfC decisions tend to disappear into the draftspace blackhole, AfD closes are relatively visible (at least the nominator will have it on their watchlist) and we have clear processes for reviewing them. –&#8239;Joe (talk) 10:19, 24 September 2020 (UTC)
 * If I find a bad non-admin close in an AfD I'm not involved in, I am empowered to just fix it, as are you, because we're sysops. In fact we both did so for the user that triggered this discussion. That works nicely for us. It works less great if you're not a sysop. Because your quiet word doesn't have the same impact. So then you either need to find an admin to have a quiet word or you need to know how to raise a stink at the appropriate place which carries its own costs. Best, Barkeep49 (talk) 14:48, 24 September 2020 (UTC)
 * Oppose but happy to change my mind if evidence can be presented that changes it: I came here after reading the ANI thread suggesting a topic ban for a user who has apparently made some dodgy NACs. I'm very much of two minds: I've not seen that much in the way of bad non-admin closures. In the time I've spent at AfD, I very rarely see a NAC where I end up concluding the decision of the closer is outrageous. I had a look at a few days worth of AfD closes for the NACs and none of them stood out to me as being unreasonable or particularly controversial. There were one or two where I thought "in an ideal world, maybe the closer should have left it for an admin to close" but even there, I thought the closer probably came to the right decision. I'll freely admit I have not been looking much at XfD (or at Wikipedia more generally), so perhaps I'm missing something, but I'm not seeing a problem here. The process of handing out, and revoking, another set of user permissions seems a disproportionate response if we haven't established there is a problem with NACs. While admin numbers decline, and RfA reform is a seemingly eternal stalemate, NACs will remain a necessity to ensure the XfD backlogs don't grow to the size of, say, the AfC backlogs. It might be an idea if those proposing this change set out some compelling evidence there is a problem by, for instance, collecting the number of NACs, whether NACs are more likely to get challenged at WP:DRV than admin closes, whether those DRVs are upheld or not. Without evidence, we're just going on hunches. —Tom Morris (talk) 11:01, 25 September 2020 (UTC)

The Draft's AfD-closer criteria
The below was the early set (and while it had been discussed, even the set to take to RfC had absolutely not been fully agreed upon), to give the discussion some thoughts, should it go forward: Nosebagbear (talk)

The non-admin closer user right is granted by administrators, usually to users requesting the right at PERM. Administrators use their own discretionary assessment of an editor's competency for performing non-admin closures as well as the following general guidelines:
 * 1) The editor should be a registered Wikipedia user for at least 6 months.
 * 2) The editor should have made at least 3,000 overall edits.
 * 3) The editor should have voiced an opinion in at least 50 discussions.
 * 4) The editor should have demonstrated knowledge of and competency in applying policies and guidelines relevant to the discussions they wish to close.
 * 5) The editor should have read and understood guidelines related to closing discussions.

The above items are guidelines. An administrator may grant non-admin closer rights to users they otherwise deem competent and may deny the requests if they do not see a need for the tools or have other concerns.
 * Just to be clear, what you posted is a copy from a previous discussion. The current proposal under development/discussion would not create a user right and it would not prohibit anyone from doing a non-admin closure (nor of course would it "un-prohibit" anyone who is currently not eligible, such as non-logged in users and topic-banned users).  It would restrict access to a tool (XFDcloser), or maybe more than one tool (tools similar to XFDcloser), that makes non-admin closures easy to do rather than laborious and time-consuming.  davidwr/  (talk)/(contribs)  20:57, 23 September 2020 (UTC)
 * Absolutely - the original discussions had primarily (though not entirely) focused around asking for a userright (as opposed to a AfC-style pseudo-userright) to be tied to the gadget, but also required for manual closes, and this is just a copy out of that discussion - primarily to see what people thought of the criteria (if and only if we went ahead with proposing the change at all). If someone wants to amend the above to reflect that, that's fine. Nosebagbear (talk) 21:06, 23 September 2020 (UTC)
 * I have thoughts on these but I'd rather see consensus for doing this at all before we get into the weeds as to what sort of requirements there might be. Best, Barkeep49 (talk) 01:33, 24 September 2020 (UTC)
 * I have thoughts on these but I'd rather see consensus for doing this at all before we get into the weeds as to what sort of requirements there might be. Best, Barkeep49 (talk) 01:33, 24 September 2020 (UTC)


 * My first thought when I saw this proposal (I missed the previous one) was that this was a good idea. But when I read the concerns raised by I found them rather persuasive. So, pending further discussion, my inclination is not to support such changes. I would mention that while I haven't done much AfD closing in recent years, I did quite few manually, and never found that particularly onerous technically, the hard part was always deciding what the outcome should be. In fact, I did my first AfD closes back when it was a head count, with a rule that there had to be at least a 2-1 ratio of deletes over keeps to justify a delete result. But my point is that I don't think that denying access to the script would keep an enthusiastic would-be closer for doing closes. We also see plenty of less than wonderful closes by admins at DRV, and endorse quite a few challenged NACs. I am not sure there is a real need for this. DES (talk)DESiegel Contribs 14:50, 24 September 2020 (UTC)
 * Oppose. The tool is not the issue; the issue is editors without the requisite experience/temperament/independence closing discussions that they shouldn't. All this proposal does is add a heaping mound of administration - someone has to maintain the access list - eating up scads of otherwise productive editor time, and putting bureaucratic hurdles in the way of competent editors to use a helpful tool in a critically under-resourced section of Wikipedia. All of that bureaucratic nonsense is obviated by using the existing procedure for problematic editing of this type: a topic ban on closing discussions. Maybe that procdure needs to be explicitly added to some of the noticeboards, but it is the appropriate response to problematic discussions closures. Something like this proposal should only be considered if there is a recurring and manifest inadequacy in topic bans managing this problem. VanIsaacWScont 21:08, 24 September 2020 (UTC)
 * Support I personally believe that the amount of editor time currently wasted by dealing with inappropriate NACs and relists is more than what would be needed to grant access to the tool to those non-admins who have shown themselves to be competent in this area. This is exactly what happens today with access to the AFC script. It's not a great deal of overhead for an admin to add a name to a list. If it help to cut down the amount of disruption and necessary cleanup at XfD, I am all for it.  C Thomas3   (talk) 16:31, 25 September 2020 (UTC)
 * This is roughly where the de-facto minimum standards for becoming an administrator were around the time I became one, with similar daily AFD load (but considerably more participation). Just saying. —Cryptic 00:58, 27 September 2020 (UTC)
 * comment and probably an outright oppose, not one of the condition makes the contributor any better at closing afd's or addresses the issue. This is part of a project wide systemic problem stemming from the RFA process.  The demands there are so high that users have to spend months making non-admin closures to even get considered as suitable to be an admin. That is what is driving people to do as many closures as possible to ensure they have the numbers and boxes ticked. Making it harder on who can close a discussion is going to increase the issue as more people will focus on less opportunities.  If we can have a criteria that lets a non admin decide what can be closed as kept, surely they are also ready to actually be able to also decide when something can be deleted and therefore ready to be admins themselves.  is right though, it's what we once looked for in giving contributors the mop, instead of band-aid fixes how about just addressing the cause. Gnangarra 03:16, 27 September 2020 (UTC)
 * Nominator's comment It's obvious from the replies above that this change does not have consensus at this time. However, the discussion is good and I don't want to shut it down before everyone has had a chance to give their view.  What you say now will be useful if this idea comes up again in the next few years.  Everyone's reasoned, thought-out input is welcome and encouraged.  When things dwindle down my guess is that this will close with either "no consensus" or "consensus against."  How it closes is not nearly as important as us listening to each other.  davidwr/  (talk)/(contribs)  14:48, 27 September 2020 (UTC)
 * Oppose How would people ever be able to show competence at closing AFDs when they're unable to do so in the first place? Don't tell me they can still close manually -- that's a tedious and error-prone process and the tool was written to overcome exactly that. – SD0001  (talk) 17:02, 27 September 2020 (UTC)
 * Oppose per SD0001. Hobit (talk) 20:19, 21 October 2020 (UTC)

Splitting RFCs out of this
At WT:RFC, we've been discussing how this page, which is primarily about XFDs, does/doesn't apply to closing and summarizing RFCs. Obviously, having the mop doesn't make you suddenly better at understanding content, and admins are supposed to the same as anyone else when it comes to content decisions. But when you're talking about deletion, then whether you have the extra buttons really does make a world of difference.

One idea we've had is to split NACRFC off this page, and put it in the WP:RFC section on closing RFCs. It might let this page focus better on its core subject. If you're interested in this idea, then please put WT:RFC on your watchlist. WhatamIdoing (talk) 22:13, 8 October 2020 (UTC)


 * Having the mop doesn't suddenly make you better, but it does mean that you have been examined on a number of things, including temperament, understanding of Wikipedia, policies, reading and judging of consensus, etc. --SmokeyJoe (talk) 22:32, 8 October 2020 (UTC)
 * Sure, but I'd still pick your assessment over some admins', especially if the question is on a subject you know well. The median admin is better than the median non-admin, but not better than all non-admins. WhatamIdoing (talk) 01:23, 9 October 2020 (UTC)
 * And the fact that SmokeyJoe is perfectly qualified to be an RFC closer is why I think that this needs to stay here. We need something that shows the many valuable ways non-admin can contribute to our consensus process. Best, Barkeep49 (talk) 02:11, 9 October 2020 (UTC)
 * Barkeep49, why should it be here, and not in WP:RFC, where has said "Any uninvolved editor can post a formal closing summary of the discussion" for years, on a page that has never preferred admins as closers, and where the only subject is entirely actions for which the admin toolset is irrelevant? A good deal of this page is irrelevant. WhatamIdoing (talk) 02:51, 28 October 2020 (UTC)
 * Why should it be here? Because it's in the scope of this essay: how do closes by non-admins work? WP:RFC is about how RFCs work. Clearly there is some overlap, just as there is overlap here and with XFD. Overlap isn't a problem, only inconsistency and I'm not seeing that at the moment (and if there were, this page, as an essay would be what needs to change). Best, Barkeep49 (talk) 03:10, 28 October 2020 (UTC)
 * Theoretically, there is no distinction between an "admin" and a "non-admin" close with RFCs. There are only "editor" closes at RFC.  That's not true for XFDs. WhatamIdoing (talk) 22:49, 30 October 2020 (UTC)

Inappropriate closures
The first two numbered reasons don't make a lot of sense as they are not admin only requirements or are at best redundant to the third. Number one says basically that you shouldn't close discussions you are involved in. That in no way applies just to non-admins. Worse the way it is written seems to imply that admins can make involved closes. I don't see the point in adding that here as it is a general don't do for closing discussions. As to the second, I would trust many non-admins more than a lot of admins as to their ability to judge consensus in controversial cases. This just adds another impediment to closing discussions and gives more ammunition to those that disagree with a close because it doesn't reflect their view more than whether it was a bad close or not. The third point is commonsense, but probably worth mentioning as at least admins should have experience and we should discourage newbies from closing discussions until they have some. It does however cover the previous two points (i.e. if you have experience you should be aware of INVOLVED and able to judge your ability to close controversial cases - at least as much as most admins). The forth is technically the only real inappropriate close. Aircorn (talk) 00:14, 7 July 2021 (UTC)
 * Yes, INVOLVED applies to more than just non-admins but it is a good reminder to have in place. I would strongly oppose removing the second point though. Close calls aren't fair for non-admins to make because they don't have access to the delete button, so they are biased towards a decision that would favor a non-deletion outcome. Admins need to make these calls because they have all the tools in the toolbox to be able to judge an outcome fairly. Not to mention, admins have been approved by the community to make tough deletion-related decisions. -- Tavix ( talk ) 00:25, 7 July 2021 (UTC)
 * Isn't that covered by the last point. Many discussions don't need the use of tools so I don't see the issue with experienced non-admins closing contentious RFC's, merges, splits etc. Aircorn (talk) 00:53, 7 July 2021 (UTC)
 * I've seen a lot of BADNACs over the years and contentious or otherwise close calls are at the root of most of them, so removing this close will cause more harm than good. Besides, any experienced user that I would trust to close contentious discussions I would also trust with the mop, so we should instead be funneling those editors towards RfA. -- Tavix ( talk ) 02:30, 7 July 2021 (UTC)
 * It has no effect except placing another level of bureaucracy in the process. There are many experienced non-admins that have no interest in becoming admins so eliminating or downplaying their exercise of judgment just because they don't want to patrol AIV or whatever is short-sighted. There is a constant cry of "There are too many backlogs." Why further restrict one backlog that you don't need the tools for? There is nothing in the admin tools that magically grants a person the ability to determine consensus in close cases so adminship should not be tied to closing. Eggishorn  (talk) (contrib) 03:14, 7 July 2021 (UTC)
 * In practice, no one will bat an eye if an experienced non-admin makes a good close call closure. This is to protect against inexperienced bad closes where an uninvolved admin can simply revert the bad closure by quoting this clause. And yes, if you want to take on additional responsibilities, it is best for you to be vetted by the community first. The admin toolkit is designed to deal with contentiousness since it includes the tools of blocking, protecting, and deletion. -- Tavix ( talk ) 03:23, 7 July 2021 (UTC)
 * There is a small number of very good closers who are non-admins. They are the exception, and they know how to close without coming here for the advice.  For the vast majority of adventurous bold non-admins who close contentious close call discussions, their doing so does NOT help the project.
 * This page offers excellent advice for non admins who think they can be helpful in closing a discussion. The repeat of INVOLVED is very good here, because it is the most frequent failing.
 * The discouragement of closing contentious close calls is very important. Anyone considering closing a contentious close call needs to know that.  Admins know that, it is one thing thoroughly examined at RfA.  Many adventurous ambitious non-admins do not know this, and the advice is very valuable to helping them not be counter-productive.
 * Backlogs are not improved by clumsy closes, or closes that will not be respected, or closes that will be taken to review for a week or more before being relisted. SmokeyJoe (talk) 04:29, 7 July 2021 (UTC)
 * In practice, no one will bat an eye if an experienced non-admin makes a good close call closure. The advice in any essay should follow practice. Here we are calling a non-admin closure of a contentious discussion inappropriate, when it is agreed that it is appropriate if it is a good close. It also goes contradicts the consensus that a RFC close should not be overturned just because it is done by a non-admin.
 * I think we are conflating inexperienced non-admins with experienced non-admins. I agree that we should discourage inexperienced non-admins from closing discussions, but I strongly feel that the project would benefit from encouraging more experienced non-admins to get more involved in closing discussions (contentious or not - because lets face it what I consider contentious someone else might not), instead of leaving it to a few editors with the admin bit. Judging consensus is something most experienced editors can do admin or not. Are you seeing bad non-admin closes from experienced non admins?
 * I don't understand the RFA argument. If they are prevented from closing any contentious discussions how do you vet their ability to judge consensus in contentious discussions. There are lots of experienced editors here who for a variety of very valid reasons do not want to become an admin. Many of these have a lot of experience in content development or are subject specific experts, making them ideally suited to judge consensus for many content related discussions. Handicapping them from closing discussions seems counterintuitive (and yes it is used to bludgeon good non-admins).
 * Can we at least move point 4 to the top as it is the most legitimate reason for a non-admin not to close a discussion (as mentioned in the first paragraph) and make the INVOLVED section more universal instead of repeating non-admin (i.e. say "closer" instead). Also it should probably say A non-admin closure is usually not appropriate in any of the following situations (bolded to highlight the change - not to be bolded on the page) as there are clearly exceptions. I would actually support strengthening the experience advice and am pretty sure number 2 should be removed, but can we do the first three at least. Aircorn (talk) 07:43, 7 July 2021 (UTC)
 * That non-admins should not make close calls should very much be the advice given on the page (and I like the way SmokeyJoe explains it so I'll leave it at that). The "practice" I mentioned is and should be rare, and the exception to the rule than the rule itself. Ironically, the consensus in the ANI thread you linked was that Buidhe should run for adminship, and I completely agree with the sentiment raised there; experienced users who want to take on those kind of responsibilities need to be admins. I totally understand if someone does not wish to run for whatever reason, but if they have no desire to be an admin, they should not be getting involved with admin-like activities. A caveat would be if someone is preparing for an RfA run, it'd be nice to have some examples of closes to look to, so it makes sense for someone like Trialpears to semi-regularly break the close-call point as long as an RfA is on the horizon. I would be fine with reversing the order completely. It does seem that the current order starts with the least important and works down towards the most important. I disagree with adding "usually", it would give the "adventurous bold non-admins" something more solid to cling to if they were to push back against their bad closes. I think the fact that the heading says "general cautions" makes the distinction clear enough. -- Tavix ( talk ) 13:30, 7 July 2021 (UTC)
 * Sure I would support them too, but that is beside the point. They should not need to be an admin to continue with the closes, which was the consensus of that thread and an RFC on this very issue. This essays should reflect this consensus and currently it contradicts it, not to mention itself. While the heading is general cautions, it then goes on to say it "is not appropriate" to close a close call. This is quite clearly false in some circumstances and adding "usually" or something similar should be non-controversial? The focus of any close should be on the quality of the close, not whether the person closing it is a admin or not. Aircorn (talk) 21:55, 7 July 2021 (UTC)
 * Yes, non-admins can make closes. That is clearly backed by consensus and practice. No, they should not make close, controversial, or contentious closes. There is no contradiction here. Like all guidances, there are exceptions. -- Tavix ( talk ) 00:01, 8 July 2021 (UTC)
 * Just out of curiosity, : Just what part of your RfA do you think evaluated your ability to make close, controversial, or contentious closes? The most consistent theme I see mentioned is your wikignomishness, which is sort of the exact opposite of an editor who makes close, controversial or contentious edits. There were many who praised your RfD activity but the majority of those discussions are not "C3" discussions. Because I don't see that there was any significant vetting by the community on this ability at your RfA or the vast majority of RfA's so I really don't see how admins should be treated differently. If an admin or a non-admin screws up a close, then anyone can question it or bring it to AN and life goes on either way. The rest is just second-classing non-admins. Eggishorn  (talk) (contrib) 00:17, 8 July 2021 (UTC)
 * At the time of my RfA I had closed hundreds of RfD discussions, so praising my RfD activity would include praising my closes. That none in particular came up signifies that no one found any to be problematic. In a more general sense, RfAs vet one's trustworthiness, behavior, levelheadedness, etc. all of which are important with controversial closes, especially when dealing with any fallout from it. There is no second-classing involved here—any experienced editor with clue that is not a jerk can become an admin. It is simply that this particular task falls firmly falls under the "administration" category and needs to be handled by that kind of editor. -- Tavix ( talk ) 00:41, 8 July 2021 (UTC)
 * If closing discussions fell so clearly under the administration category it would be in that category. It is explicitly not by the agreement of the editing community. And while "any experienced editor with clue that is not a jerk can become an admin" is a fine sentiment, it does not match observable reality.  These were all experienced, clueful editors with impressive nominators (you among them) and, whatever failings torpedoed their RfA's, none are what I'd call jerks. It was called a "horrible and broken process" 10 years ago and hasn't significantly improved since.  Demanding that people subject themselves to it to carry out an explicitly non-admin edit strikes me the same way that the justifications of residency did when my spouse went through that broken process.  "I had to do it so you should, too."   Eggishorn  (talk) (contrib) 01:24, 8 July 2021 (UTC)
 * A non-admin can make a close controversial close of a RFC and it should not be overturned just because they are a non-admin. There was no exception at the RFC on this. Only this page is saying that, so yes that is a contradiction. The section is talking about closes generally so this obviously includes RFC. It also includes many other closes, so I would also challenge the exceptions argument. I would argue that outside of deletion discussions this is more the rule. I don't know if we keep easily accessible archives of other community discussions, but the GAR process is almost exclusively closed by non-admins (Good article reassessment/Archive 66). This essay not only gives incorrect advice, it is giving advice that is generally ignored at most venues outside AFD. Aircorn (talk) 12:56, 12 July 2021 (UTC)
 * It should not be overturned just because they are a non-admin, but it can be unilaterally overturned by an uninvolved admin due to being a bad close.
 * This essay gives very good advice.
 * Are non-admins making bad closes at WP:GAR? SmokeyJoe (talk) 14:20, 12 July 2021 (UTC)
 * That's the whole point. The issue is bad closes, not non-admin closes. Even then to overturn it would have to be an unambiguous bad close.
 * It gives some good advice. The advice (which is more presented as a stipulation) about close contentious closes is not.
 * Like most there are very good closes, alright closes, closes I disagree with - but are justifiable and the odd one I think are bad. Being an admin or not has not changed the incidence of this, more how experienced editors are with the GA process and criteria. A lot of the facts and numbers presented in these arguments are anecdotal. One is that non-admins closing contentious discussions is rare. GAR is a well maintained archive of community closes that we can look at. Out of 65 closes last year, three were by admins. This year 38 closes so far and not a single one by an admin. If there was a similar archive of move, merge or RFC closes it would be interesting to see what percentage of closes were done by Non-Admins. Aircorn (talk) 19:41, 12 July 2021 (UTC)
 * You’re not saying how many contentious closes are done by non-admins. You are saying that some closes are disagreeable or bad.  I think that the real problem is a lack of close review for GAR closes?  The proper place is WP:AN, but I think that WP:AN may feel to be overkill?  If this is remotely close, then weakening advice for non-admins to not make contentious closes will be counterproductive. At GAR, has anyone ever responded to a bad close by pointing the closer at BADNAC?  At GAR, are there at least some admins around?
 * When there is a bad GAR close, what are the consequences? Is there a time period for waiting to start a process to downgrade the rating?  Or is there a culture of finding weak Good Articles and bringing them up to standard? SmokeyJoe (talk) 22:43, 12 July 2021 (UTC)
 * That's a bit subjective. Community reviews are in theory for contentious reviews as there is the option to do individual ones for the obvious ones. In practise some editors use them when an individual one would have been fine (and vice versa). But that's just Wikipedia (and life) in general. The best place to review a GAR close is probably a related talk page (WT:GAR or WT:GAN). The major problem is the back log, something found at other venues too Administrators' noticeboard (I like that even at the administrators noticeboard there is acceptance that anyone can close a requested move with no contentious caveat). It is not really fair to Piotrus that his article sits in GA limbo for 9 months. From memory I have been personally challenged four times on a close (to keep it in perspective I have closed close to a hundred GARs over many years). One I reverted so someone else could close, one I changed my close, one was brought to a talk page and then went nowhere and one was reverted for me and I just turned it into a comment instead. Personally I think one of the main things with closing discussions is to not take it too personally. I don't recall being pointed to BADNAC, I don't think being an admin has ever come up. I don't think that supports your argument though as it more defacto suggests that being an admin has no bearing on a close. There are a few admins around (Barkeep has closed some, but ironically I think that was before they became an admin).
 * To be honest the stakes are low at GAR. The article might be delisted when it shouldn't have been or kept when it no longer meets the criteria. In either case there are no real changes in how the content is seen except for a green spot. It is nice to maintain standards as they are often held up as examples of good work, but in the end another GAR could be started or the article nominated at GAN depending on the outcome. I chose this example because I know a lot about it and I can access the archives easily. It would be more interesting and possibly relevant to analyse RM, RFC or MERGE closes. Anecdotally many I have participated in have been closed by a few dedicated non-admin editors without any major issues. No official time period for GAR (average is probably a month or two), it really depends when someone is around and can do it. They tend to get closed in bursts. Improving depends, mainly on the presence of previous nominators. The good thing about GA's is that usually if someone is dedicated enough to improve the article, they will also try and save it. It works on the premise that the aim is always to improve the article to GA standard. Old GA's unfortunately have often lost this dedicated editor.
 * Either way taken at face value this essay says I should not be closing Good article reassessment/Home Army/1. I am going to anyway, right after I finish this as I believe I have the experience and knowledge to do so and leaving it for a potential admin has caused more harm than good. I also believe this is probably true for many other areas. Aspects of this essay don't reflect how Wikipedia works. Or at least how I have seen Wikipedia work. Its not a big deal as I feel it is only an essay and this part carries little weight in areas I edit or may edit in the future. Aircorn (talk) 06:52, 15 July 2021 (UTC)
 * User:Aircorn, that was an interesting thread. Did we stop posting because we reached a consensus?  I have no criticism of your last post, I should have replied noting my support.  Is the agreement actionable in any way?User:Aircorn SmokeyJoe (talk) 11:25, 1 November 2021 (UTC)
 * This was all so long ago. I just don't have the time or energy at the moment for these type of discussions. The thread below popped this back into my watchlist and I saw that it was essentially saying the same thing I was. It has attracted much more attention than my post (maybe something happened that led editors here or it was just put together much more coherently). Either way I still believe that this essay is actually harmful in places. The GAR stuff was just because that is an area I have fallen into, but it applies to pretty much any other close outside of AFD. I really don't have the time or energy to participate much in the new discussion, but would support any major rewrite of this essay to better reflect community practice. One of the comments about changing non-admin to inexperienced closer was exactly what I was trying to achieve and very strongly follows my POV on this issue. An editor in good standing who has been here long enough (experience can be hard to define with a number) can close any discussion as well as most admin editors, many probably better. Air<b style="color: green;">corn</b> (talk) 17:39, 2 November 2021 (UTC)
 * Up until recently I would classify myself as one of those non-admins who were willing and able to deal with contentious closes. That meant semi-regularly breaking the close-call point for a reasonable definition of close-call. I have never gotten a close to DRV even then. My feeling then is that it's possible for experienced and suitable non-admins to perform more contentious closes in practice. It still feels quite bad giving at times dubious guidance, but I feel it is in general good advice that likely has prevented a lot of bad closes. --Trialpears (talk) 07:23, 7 July 2021 (UTC)