Knowledge (XXG) talk:Redirects for discussion/Archive 9

3418:, even if admins do not review the closing they'll have to reviw thye speedy deletion. Not reviewing the closing is not a problem, as interested parties will contest a poor decision anyway. But the admin must review the speedy deletion. That is quick, for sure, but we must check if it is a legitimate G6 (or whatever for other speedy deletion requests). So, a admin-delete-closure (ADC) goes: 1) user assesses the deletion discussion; 2) user closes the discussion; 3) user deletes the redirect. A non-admin-delete-close (NADC) goes as: 1) user assesses the deletion discussion; 2) user closes the discussion; 3) user tags as G6 4) second-user assesses the G6 5) second-user deletes the redirect. The NADC process has all the same steps from the ADC, which will take on average the exact same time, PLUS steps 3) and 4) (tagging and assessing the G6). It is not speculation, I'd say, that the second process must inevitably take longer to be carried out. Even not including the possibility that the deleting admin may also do a sanity check on the RfD closing. Nor including a risk of increased litigation (undeletions, ANI cases against abusive NACs, and so on) If this longer process brings more eyes hands on the job and ultimately results in a overall improvement, fine by me. But we would be better off getting those non-admins willing and able to help to become admins. Hmmm... give the admin flag on to any non-admin getting to the 100 NADCs without a revert? :-) (half joking, but it is something of an idea, no?) - 3475:, I see. I don't do Twinkle so I have not thought of automated deletion. But I still think it is a simple fact that admin-delete-closes (ACD) are overall faster than non-admin-delete-closes (NADC). NADC have at least two extra steps: tagging as G6 and assessing the G6 (i.e. checking that there is a closed discussion about the redirect to delete). Note that "skim the discussions" as you say is a third extra step, even if a quick one. Assessing and Closing should take just about the same time. As you say, the deletion itself may be faster. Maybe... if I understood your process, you copy/paste the discussion heading to one page; you write one summary; you click a button once. I need to click a button for each deletion I do, but on the other hand I do not need to copy which pages to delete to nowhere. I do copy paste that same amount of summaries, though, so the net gain is N clicks versus one click. Overall, I bet there is no time gain. There is not much time lost either - maybe none, I admit after your explanation - but then... If it saves no time, why do it? Get more admins - You say NAC are producing new admins? great! Why do we need mini-admins commanding auto-deletion-admins? Let's get more full-admins! (we are having the wrong discussion anyway, deletion probably should be much different, we should have lots more built-in automation) - 2053:. I roam many XfD pages on occasion, I am not a regular at any. I often do a short run at Speedy Deletion as a way to (1) help out a little (2) while not requiring too much of my time. If I wanted to assess template deletion's, or redirects, or..., I would go there and do it. Sure, probably all such closes I saw are clear and did'n take long to re-review; still a "delete" non-admin closure involves the exact same steps than a admin close, plus tagging as G6 and reassessing by the deleting admin. Overall that is *more* work to process the same ammount of discussions, in the long run I doubt it is any improvement. Much better is that editors wanting to decide on deletion to become admins. I understand, (un)becoming an admin probably should be easier than it currently is, but circumventing the process of acknowledging some level of community trust is not the solution - 2936:. If a non-admin can close these discussions to "delete" but having access to the "delete" function would be one of their eventual tasks as an administrator, granting permission to close discussions to "delete" without having the actual ability to delete the page reduces the need to have the delete function. And, on the flip side (again), the English Knowledge (XXG) may never run out of administrators to perform the deletions since the English Wikipeda currently has over 1000 administrators, but however, non-admins having the allowance to close these discussions to "delete" could further prove that they could become a good administrator. So ... there's good and bad on both sides, and I can't place myself in either camp. 3399:

at TfD, this claim is in fact false. I wrote the original TfD RfC and monitored the process there for a long time after it was implemented. I probably hold the record on number of NAC-as-delete G6s. It could be true that Tavix's observations are correct, RfD works differently, and NACs wouldn't help here - though I'd add from the TfD experience that a consistent throughput time maintained by experienced regulars is much superior to accumulating large backlogs and then occasionally running an "all hands on deck" effort to catch up. But as this is moving toward closing time, I have to emphasize that a number of the oppose votes here appear to be based on speculation rather than evidence.

2625:, so even if an administrator has to fully review the closure (which shouldn't take too long since NACs are designed for obvious closures only) before carrying out the deletion, it is unlikely that the administrator from CSD would have closed the RfD discussion and deleted the redirect anyway had it not been listed at CSD. In other words, by closing the RfD discussion, the non-administrator actually made the process faster by directing an administrator's attention to an obvious closure that would have otherwise just sat in the backlog for an indefinite time, waiting for an admin to just stumble on it. This kind of system has already been put into place at 2206:. I wanted to get a little experience on the admin side of the fence before I weighed in, thinking that it would influence my views. It has, from neutral (largely in line with Steel1943's original train of thought) to here. Closing an RFD discussion as delete is extremely simple if you have access to the delete button. After the discussion is closed, all that needs to happen is a push of the delete button, and that's it (with a couple rare-ish exceptions). If a non-admin were to close the discussion, s/he would need to tag it, wait a bit for a CSD admin to come around, who would then need to confirm that the closure is correct, 497:

disputed NACs that have come up in the last year - that would be less than a dozen substantive disputes, and about five DRVs, so overall there has been very little friction and very few poor calls. It's true that some of the original arguments in favor were specific to TfD: first, there's sometimes a lot of work to do between closing the discussion and actually deleting the template, and that orphaning work has always been mostly done by non-admins; and second, some discussions are best evaluated by people who are experienced template editors, and the number of admins who are in that category

2885:

we have below adminship; anyone who qualifies for it is also competent to do RfD closures, because they involve the same level of careful consideration of consensus and P&G, and mindfulness of potential unintended negative consequences or other disruption. Exercising page-mover ability already involves redirect-related judgment calls. (I also have no prejudice against the idea of "RFDNAC" having its own vetting process, or there being a new userright, per IJBall, it just seems like additional unnecessary complication).

3045:. A proposal like this one allows more community-level control over content, I think, and with respect to RfD makes admins mere button-pushers, which is what they're supposed to be. If you want to be someone who pushes the button, you run for RfA. If you want to evaluate discussions as to what gets kept and what doesn't, you don't need to be an administrator to do that. Of course, someone with little experience or demonstrably poor judgement shouldn't be closing complex discussions, but RfA is not our control on that. 2359:. If you have to spend an extensive amount of time thinking whether a non-admin closure was appropriate – then the non-admin closure was not appropriate. The goal with this is to speed up the process by bringing obvious closes to the attention of administrators. Even if administrators have to check the closure as if they closed the discussion, the benefit is that the closing process happens more quickly, making the deletion process as a whole more efficient. 3008:

for "drive-by" admins to notice and act. An RfD-regular who is not an admin is in a better position to close the discussion than an admin with no RfD experience. There's also no way this would affect the number of RfAs, pretty much by definition: The very problem is that not enough people are interested in RfD work, so probably no one, ever, is going to think "the only reason I want to be an admin is to do RfD, and now I don't need to bother with RfA."

2568:. Me too, I like the idea in theory, but XfD 'delete' closure is and should remain an admin responsibility. If we allow this sort of unbundling, there will be a stampede to dilute even more admin rights on the basis of minor exceptions. It is true that there are backlogs in some areas, but unbundling of this kind is not the answer to a lack of active admins. To address that issue , one needs to find ways of attracting new candidates for adminship. 3374:

an invalid criteria, or the discussion is actually still open, or it's clearly vandalism; a blatant and obvious error, not just that they interpreted consensus incorrectly. If there is an issue with a closure of any result, it's not up to a passing administrator to correct it, that is the purview of a closure review. I've seen exactly two of those in the couple years that I've been hanging around RfD, and they were both for the same redirect.

31: 216:, some of us just want the forum to function smoothly. Also, I disagree that it weakens anyone's ability to demonstrate need; if anything, a glut of non-admins closing discussions where they need an admin to push buttons shows that more admins are needed in this area, and also demonstrates that the users doing the closing know what they're doing, and you can highlight that experience in an RfA if you choose to do so. But you're right about 2143:(unless it becomes a pattern), performed by non-administrators than administrators. Administrators are expected to know what they're doing and have been entrusted by the community to act appropriately. We shouldn't ask them to burden themselves with entries in the deletion log that aren't based soley on their own assessment of consensus (additionally: if we require them to vet the close, then work is being done twice, which is pointless). 1990:: As a non-admin I instinctively oppose this proposal as a lowering of standards in the interest and name of pragmatism. Practicality is fine and everyone would like shorter waiting periods to close out pending AFDs, etc. but this is a bridge too far. We may live in a world of low and lowered standards (just take a look at the two main presumptive POTUS candidates) but this is a reality for Knowledge (XXG) to record, not emulate. 3300:: I think no. The criterion (whether it's new or not) is going to say something like "a redirect where the discussion closed as delete", and if a closer is reviewing a discussion and finds related redirects which weren't discussed, I think it's better (and undoubtedly less drama) if they either ignore them or list them as new discussions, rather than tagging for deletion. The deleting admin might decide to do so anyway. 3146:, if any discussion is closed as requiring admin action (outright deletion, moving over a redirect with useless history, etc.) and an admin comes along and disagrees, this has huge potential to cause problems. Sure, in many cases the users involved will just shrug and move on, but imagine if this is a highly contentious debate we're talking about, perhaps even one that has been relisted numerous times. We're talking 2032:

will waste enough time to make this proposal "not worth it", shouldn't we already have evidence to demonstrate that? Why would adding "delete" as an option necessarily lead to an influx of incompetent closers? Non-admin closures are designed for when the consensus is so clear that an administrator would undoubtedly close it in the same way. That is a longstanding principle and it doesn't change with this proposal.

1637:

was sane, and the close is not being contested. They don't have to go wade into the substance of the arguments. That's the job of the non-admin closer, and that's who is ultimately responsible for making the deletion call. If you want to argue that a non-admin closer should not be given the responsibility to close the discussions, that's one thing. However, this is not going to make more work for an admin.

118: 2223:. Sending more RFD regulars to RFA would solve the problem a lot more than this band-aid would, as I have hopefully shown, and I want to encourage that over bothering the already-thin CSD admins. Instead, I'd like to support the "all hands on deck" suggestion that came up earlier. If the backlog ever gets too long, then I would definitely support allowing non-admins to work on the backlog in the name of 2492:– I feel that only admins should be entrusted with this responsibility and that having non-admins involved only muddies the process as the admins then have to double check the conclusion of the non-admin closer before the admin can proceed with the deletion. The non-admins could better spend their time doing something that does not require a rubber stamp of approval from an admin. Cheers! 585:. With respect to the original closer, history shows that strong and obvious community support is needed to implement any sort of change where administrator rights and/or deletion are perceived to be affected, not just the strength of arguments but an obvious numeric majority as well, else the result does not have the confidence of the community and is effectively invalid. The 518:

it should be made clear that the assisting admins are not the ones responsible for the close. Admins should be able to assist in the procedure without having to recheck everything, nor should there be any reprisals against the admins who aid a nac closer. It's the closer who should shoulder all the responsibility of the nac. The nac closer might get under the gun; however,

3531:, if you get a process that is more time consuming, but also get a few more hands on the job, then the overall result may be that you do get to reduce the backlog. I already said so above. ("If this longer process brings more eyes hands on the job and ultimately results in a overall improvement, fine by me") But this is a bad solution. Noted how one of their defensors, 2262:. After reading some more of the more recent comments here (as well as considering my original thoughts), at least on RfD, I now think that anyone who closes a discussion to "delete" should have access to the delete function. And yes, as stated above, I would support an "All Hands On Deck" option as I referenced in the original section of this discussion above the RfC. 3181:, or an admin agreeing with an editor's unblock request; in all such cases, another admin is unlikely to personally challenge this decision, and the acting admin who made it effectively trumps non-admin opinion (subject to community review at AN, ANI, etc.). Rewinding, if a non-admin closes an RfD as delete and an admin objects because they want to add a 3645:) and when users have done it in the past, as well as cutting down the backlog at RfD. Conditional support for another RfC to review 6 months after adoption also received a strong level of support by many. Other reasons mentioned point towards building trust to run for RfA, and increasing the number of admins willing to delete pages in the area 2339:

to be incorrect. This means admins effectively have to endorse any non-admin delete closures anyway. As an admin I would not feel comfortable performing one of these deletions without reading the original discussion as if I was closing it and satisfying myself that the close was correct, and at that point I might as well have closed it myself.

1537:. Either don't let non-admins close, or else let them close fully. It's silly to ask a person to spend time -- sometimes a lot of time -- cogitating on a question, and then only allowing them to make one decision and not the other. Hey, this would give us a much fuller idea of how an admin candidate will handle closes. And so forth. 3117:

actual severity of the matter not being really relevant. I see way more drama about article moves than I do about redirects being deleted. (That said, I am not an admin, and do not have to deal with uniquely admin drama, so there may be some RfD-related pit full of radioactive, flame-spitting alligators I'm just not aware of.)

472:

for any means to overturn the close. The question therefore arises whether an admin should review the close before implementing it. In practical terms this itself is a judgement call - if someone has been making good NACs for some time, an admin may reasonably assume that they know what they are doing.

1088:– that principle should not change if this proposal passes. Even if an administrator has to check the validity of the closure (which shouldn't take too long since many RfDs are near-unanimous), the benefit is that the deletion would happen more efficiently, as more administrators patrol CSD than RFD. 3398:

I commented early on in this discussion and haven't followed it since, but I see there's been a significant amount of opposition building up on the basis that "admins will still have to review closures so it won't be any faster/will be too risky". Based on the experience accumulated from NAC closures

3373:

That's really not what I'm suggesting at all. I expect that the deleting administrator's review will be limited to checking that there actually was a discussion and it actually closed as delete, not going so far as to review and evaluate the close itself. By "clearly erroneous" I mean the closer used

2835:

The simplest approach would be to limit this to editors who have the page-mover right. This would both provide a minimum (and non-trivial) hurdle of community trust to make such closures, and provide a means of going through with them that does not add to admin workload: The closer would very briefly

1971:

It is pointless for someone without the ability to decide on a delete when the delete cannot be performed unless an admin takes responsibility for it. Ultimately it is the admin who is responsible for the deletion, so they should make the decision to delete. Admins are picked for their ability to use

1835:

I'm an admin and I used to have this view until I began participating in RfD regularly. In a deletion forum with ≤5 admin regulars (such as RfD), we regularly run into a situation where there is a consensus to delete but it stays in the backlog for weeks just because all the admin regulars have taken

1750:

And the backlogs and dwindling number of both admins and adminship candidates, despite major attempts to reform RfA, demonstrate the the "organizational lifecycle stage 1" solution that RfA is has not been working, for quite some time. We have to augment Ye Olde Ways with new approaches, if we're not

1121:

per BDD, Mz7, Malcolmxl5, Deryck Chan (create corresponding CSD template; write a "WP:RFDNAC" instruction set, with NACD reminder and other good instructions to closers and admins; have a review in 6-12 months). I agree with the overall gist here that this will be an efficiency boon for little cost,

496:

I don't spend much time around RfD, but I can speak to the TfD experience with this process - it has indeed been very successful at reducing the backlog, and in fact most TfDs are now closed by a few experienced non-admins, with very little work left for me :) I think I've seen most if not all of the

471:

This is actually a little more subtle. Some closes require spending time, but little judgement. These would be unexceptional NAC. What we want to avoid is the situation where a NAC occurs, and an admin implements it, and ructions ensue either because it's a bad close, or because someone is looking

3650:

While the vote numbers are slightly in favour of oppose (29 vs 31), I find the support arguments to be stronger, and also counteract some of the opposes. For example, the opposes saying "why is this needed" appear to be countered by RfD regulars saying there are often no uninvolved admins willing to

3489:

Let me put it this way. When I first started looking at TfD a little over a year ago, the backlog had grown so large that the oldest daily logs were no longer visible on the main TfD page because the transclusion limit had been exceeded. Not long after NAC-deletes started, I wrote a script to make a

2866:

What? That's not a simple approach at all. Closing redirect discussions has nothing at all to do with moving pages. If you mean that it would be "simple" to allow pagemovers (or any non-admin user of any existing or new usergroup) to delete redirects, that is technically improbable: redirects can be

2480:

articles have been lost - or moved should be read thoroughly by a closer, then make a mental map of the arguments, and decide on many factors. Too many closers count heads, and think that's consensus Closers should be trained and, hopefully, be perceptive admins, in order to make such drastic moves.

2214:

much more work, spread out amongst multiple people, for a problem that really doesn't exist right now. Since Patar knight and I have started closing discussions towards the end of May, we've been flirting with no backlog ever since. It shows that the real problem isn't the fact that non-admins can't

2172:

and others. Given that only an admin can actually do the deletion and is responsible for their use of the tool, they have to do more than rubber stamp a close. I am also concerned that the current climate is too quick to delete as it is; I find that too many articles are AfD nominated when a merge

2117:

The backlogs are not a problem. I do come to RfD from time to time. Most redirects are not any problem if they stay a few days over the seven days deadline. Or a month. The ones that could be a problem most likely get more attention and get closed sooner. Also, I doubt making the process longer (one

1686:

admin actions. If a user is disruptively abusing this power, closing discussions as delete when everyone says keep—sure, chide the admin for running without his or her brain on. (The bigger problem there, though, is the abusive user.) If it's more of a judgment call, if it's taken to DRV, it's still

1636:

The admin doing the deletion in this way does not have to do more than sanity check the closer. If the admin clicks the link in the template, they just have to glance at the discussion for maybe 10 seconds. The things the closing admin needs to ensure are the right page is being deleted, the close

852:

Let me repeat an argument I've made elsewhere on this page: In a deletion forum with few admin regulars (such as RfD), we regularly run into a situation where all regular admins have chimed in. Allowing NAC-delete frees up admins to participate in discussions with less concern that they'll stall the

3322:

At the moment, I would agree that we don't need to set formal restrictions on who can close. The idea of a non-admin closure is not new: right now, anyone (except IPs) can close discussions as keep and no consensus. If we need formal restrictions, we should already have evidence to demonstrate that

3194:

basis, and is not apt to let an insane pattern arise, especially when we already have mechanisms in place and norms of decision-making behavior (and review thereof) that actively prevent this, generally and site-wide, in all the directly analogous situations. Have some faith that the community will

3111:

To whom? We have similar processes for both, DRV and MR. Both action types can take some effort to undo, both can raise disproportionate ire, and both scenarios are caused by the exact same chain of events (non-admin comes to a conclusion about consensus, and asserts an admin should act on it, and

3007:

Why? And why do you feel this "undermines the role and value of administrators"? Admins who are RfD regulars have explained here that this will be a help to them, because they are so few of them and often they've all !voted in a particular RfD so can't close it, leading to a backlog of RfDs waiting

2884:

I do not mean the latter; your objection to that idea is an objection to what IJBall proposed, above me. Regarding what I actually did propose, have you read the page mover abilities, requirements and, most importantly, archives of the vetting process? It's the most unlikely-to-be-granted userright

2585:

Frankly, I've never been fond of non-admins closing to keep because I think it invites a bias toward keep just so they can do the close. But while allowing non-admins to close to delete would seem to address that problem of possible outcome bias, when they can't actually do the delete, I submit it

2338:

administrators are responsible for the actions they take with their administrative tools and can be held accountable for them. If anyone disputes the correctness of a deletion based on a non-admin close then the deleting admin will be obliged to defend it and could face consequences if it is deemed

2285:

The idea of someone reaching a closure decision that they can't actually implement doesn't make a lot of sense. An admin is still going to have to review it and do the deletion, so all it does is add an extra step to the process. The rules at NAC say not to make a closure that you lack the power to

2031:

I can't help but feel that your oppose (along with a few others in this section) seems like an oppose against non-admin closures as a general concept, rather than this narrow proposal to allow them to close redirect deletion discussions as delete. If allowing non-administrators to close discussions

2009:

believe non-admins (and I know most are well-intentioned) can or should be trusted and relied upon in AFD cases with apparent delete consensuses. The confusion and appeals that would likely ensue would make any quantitative savings (of time and energy) too minimal to be of value. If the XfDs are so

517:

There was a time when non-admins were able to close deletion discussions at RFD by interpreting that they did have the power to do so simply by getting an admin to aid the process. Guess that's not the case anymore, which seems rather arbitrary to me. One thing though, if we go back to nacs, then

173:

I like the idea in theory, but.... There are often discussions that have lingered open recently solely because BDD or Dereck Chan (and especially if both) have participated in them. When personally looking for discussions in need of a close, there are often discussions that have clear consensus to

3647:

On the opposing side, several users point towards the deleting admin having to review the decision, as they are responsible for the deletion - so it might take longer than claimed above. Additionally, they pointed towards there being no fixed criteria for whom can close such discussions, and that

3189:

argument to the discussion about it, that's an editorial opinion not an administrative one, and so has no administrative weight. Regardless, the DRV process would remain, to handle any disputes arising. So, there does not appear to be room for this "huge potential to cause problems" to actually

3154:

involvement. None of this is the case when an admin simply rejects a request posted by a user (where other users have not demonstrated consensus support for the proposal), nor is it the case when closing a discussion without required admin action, as the entire burden of any potential review then

1616:

The admin who will consider the deletion will have to review the close anyway, as he or she is accountable for the administrative action. I think this might even create more work, as someone will have to seek out an administrator to delete the page. (Or wait for an admin to come by who would just

1217:

On the question of responsibility, where some note that the deleting admin still has to take responsibility for the use of the delete button: True, but reviewing a close can far easier than doing the close, and if the non-admin wants to volunteer their time and effort in this way, then good. But

942:

I've done several of these in the past without incident. It's important, though, that if the community decides to allow experienced non-admins to close discussions, then the closer should take full responsibility for the decision just as if an admin had closed the discussion. To be clear, if the

263:

My personal life is pretty busy right now, and I'm not able to adjudicate at RfD as much as I have in the past. I'm sure this has been noted. RfD also seems more active than in the past, which generally gladdens me, but definitely makes us understaffed, especially when I or another closer becomes

3116:

arises because people make it happen, not because it's innately a part of WP functionalities and processes. Most of it arises from personality disputes, and I've learned from long experience here that the personalities that generate such conflict will generate it about whatever is at hand, the

1369:

on the understanding that non-admin closures are restricted to experienced editors who understand the RFD policies, that non-admins avoid close calls and controversial decisions, and that administrators review the speedy deletion request as they would any other speedy deletion request (in other

437:

Actually I was one of the people who pushed for the clause " result will require action by an administrator" a few years ago, because it wouldn't reduce the amount of work that needs to be done by admins. But I made that argument in the context of AfD. I'm now open to the idea after reading the

3176:

I still don't see it. If an admin objects (e.g., by refusing to carry out the post-close CSD request) because the closer's consensus-assessment or policy-and-procedures interpretation were incorrect, that would be exactly like an admin refusing to carry out an alleged non-controversial move at

3539:

was closed as 'support', despite having 20 opposes and 15 supports. It may not be a vote count, but there is also no rationale for disallowing any of the opposes. So?... Lets ignore all rules, sometimes it works - looks like it did in this case. OK. But lets not say that it had agreement from

3439:

Have you tried it, especially on a big batch? For awhile I did most of the post-NAC deletions at TfD, and it's undoubtedly faster than doing all the closes myself. Collect them all from one day's log, skim the discussions (very quick, since most are very obvious results), put all the intended

2479:

from my experience with RM's letting non-admins delete or close any page is not a good idea. I've recently seen RM's with large discussions moved with non-admin closes of under a minute. Every discussion about a page being deleted - probably the saddest area of Knowledge (XXG) where many fine

2084:

Tries to solve a problem that does not exist. Admins do not need someone to put a set of tags around a nomination telling them that the outcome is obvious. What they do need (or at least, did, as of the last time I was active here) is/was to be made to exercise maximum restraint in the highly

3040:

I'm somewhere in the middle on the effect of proposals like this with regard to RfA. I don't really believe that this is taking away a reason to apply for adminship, on the balance. In theory, any competent editor can evaluate any discussion for consensus and produce a reasoned argument; the

2139:- Some of the opposing rationales have swayed me to a point where I can't lend my support to this proposal. I've seen many more closes that I disagree with in some aspect, but aren't quite egregious enough for the time and effort it takes for a discussion with the editor and a potential 3651:

close to keep the page. Additionally, most of the users that regularly participate in RfD are in the support section (by my count), so the extra weight I attach to regulars pushes this over my personal boundary where I would close this as no consensus (which was my initial thought).

974:

I think this is a great idea in principle, though I raised some questions in the discussion section below that we may want to consider if this is ultimately implemented. I am also open to the idea of holding an additional RfC in 6 or 12 months to reassess how things are going. --

3509:

All that said: what made this work at TfD was, everyone who was active in the process at the time of the RfC agreed that this was a good idea, and we started out with a few very productive TfD regulars who knew what they were doing and were happy to do the work. (More on that in

3112:

after a perfunctory sanity check, assumes good faith and takes the action, only to find out after the fact that people actually are prepared to object strenuously). I tend to agree with BDD's take that the one becomes a bigger deal than the other "only if we want it to".

144:, referring to the discussion. This will help with the backlog by allowing more of the obvious result threads to be closed without waiting for a patrolling admin. There's of course some risk that a user could abuse this to get a redirect deleted out of process, but 1218:

there is an implied fear of non-admin closer irresponsibility. To address that, I suggest that any admin for forbid, subject to consensus in a later discussion, a poor closer from closing any more discussions. I don't think this will be called for very often. --

438:

argument here, noting that the problem we have is we have very few regular closing admins, so an effective stall would happen if all admin regulars opined in a discussion. Maybe non-admin "delete" closures will even attract admins to take an interest in RfD.

2931:

geared to make it so the administrator who deletes such redirects as a result of RfD's should be absolved of any responsibility related to the deletion of the redirect(s) in question, but on the flip side, this may potentially reduce the amount or need for

2760:

Will there be any formal procedures in place to limit the kinds of non-admin editors that can close discussions as delete? Is there any practical way to limit this power to editors who have, for example, 1,000 edits or editors who have "extended confirmed"

943:

closer needs the service of an admin to actually finish the close, the admin should not be expected to have to check the details and take any responsibility for the closer's decision. If the close comes under the gun, then it's the non-admin closer, and

1465:, where I used consensus to allow non-admins to close as delete to eliminate large backlogs (2 months in the former case, 200 discussions in the latter). A backlog at CSD hasn't been an issue, even when I've listed 400 categories as G6 in one night. Why 296:

That sounds like "the me of the past", but I cannot recall what specific plan or suggestion I had in mind. If I would suggest/support anything of the such these days, it would be ... to allow non-admins to close discussions to delete if a backlog in any

2354:

But I think the relevant question is would you have closed the discussion if the non-administrator hadn't brought it to your attention at CSD? My understanding is that few administrators actively seek out and close RfDs relative to those who patrol

1782:

and I am surprised that this is even up for debate. All of the admin noticeboards are perpetually backlogged as it is, and there is no reasonable question that this would add to the overall admin workload (if only because of more contested closes).

1939:

et al. If the admin is going to have to assess the discussion anyway, how is this not just "look at me, I closed a discussion - um, now let me find an admin to reclose it and implement." Complete waste of time better spent doing something else. -

3568:

The 30-day period runs in about 24 hours. I'll go post a notice over at WP:ANRFC and WP:AN asking for 3 closers, and let it run until we get 3 or a week goes by. If we get 3, great. If we get 1 or 2, I'll probably ask them a couple of questions.

1729:

per Od Mishehu. Non-admins aren't supposed to close discussions resulting in deletion because they don't have the authority to delete content. We have RfA's to gauge worthiness to this task and allowing non-admins is antithetical to the process.

1154:

non-admin RfD closes should not be available to newbie or trouble-maker editors, and b) it would still create work for (some) admins to have non-admins do closes that admins still had to execute, could both be obviated by limiting these

2643:

I'm still opposed. It's a dumb idea, a solution to a problem that does not exist. In other words, I don't buy even one bit of your explanation. If someone really wants to close to delete, let them nominate themselves to be an admin.

1656:. It's similar to other admin actions. A user might request a block for edit warring, protecting a page from vandalism, or making an interface edit, but ultimately the admin must be able to justify why the action was (or wasn't) taken. 2586:

makes no sense at all for them to make the call. What's supposed to happen next? It just sits there until an admin comes along who agrees and is willing to do the delete the non-admin has decided should happen? This is just dumb.

2770:

I don't think any of these issues are serious obstacles to the implementation of non-admin delete closures, but these are issues that I think we should keep in the back of our minds if the system is ultimately implemented. Best, --

182:, and subsequently start closing said discussions (if we allow this sort of clause, it will weaken the ability of regular participants here to demonstrate a need for adminship). We aren't even close to being in as bad of a state as 3268:: I personally agree with the latter approach; so long as the non-admin closer's action is not clearly erroneous, the deleting admin is viewed as simply executing the discussion's result. And I suggest we create a new R-series 2764:

I remember seeing past RfD closures where a closing admin will apply the decision of that discussion to closely related redirects that were not included in the original discussion. Will non-admins have discretion to do so as

1797:

I was under the impression, when I put my name under "Support", that this is not entirely unprecedented. A couple editors and administrators mentioned above that a similar idea was put in place at TfD, and it worked fine.

253:

I remain very supportive of allowing such NACs. The fact that an actual admin needs to do the deletion is a huge check against abuse. There's another precedent for NACs that need admin intervention to complete, over at

3692:

I've been asked to reword my comment above. There is consensus that this close be overturned. It is not necessary that it is closed by an administrator, but an experienced editor would be desirable. Regards — Martin

1701:

I've deleted hundreds of templates under G6 after NACs of TfDs. The argument that NACs take more time because the admin has to review the discussion has that tempting scent of truthiness, but in practice isn't true.

1319:...And downgrading my support to "weak" after reading some of the recent opposes. I'm sort of reminded of part of the reason I was originally "neutral", as referenced in my struck comment in the discussion section. 3323:

need based on current practice. I understand that deletion is more destructive than keeping or retargeting, but I'm not sure if expanding a non-admin's repertoire will bring a sudden influx of incompetent closers.

2512:

What if the deleting admin thinks the resolution should be kept? Keep it contrary to the NAC? Do it anyway? It would create more drama. Admins are who actually do the job, they should decide what to do. — regards,

3068:; if an allegedly non-controversial move actually turns out to be controversial after the fact, RM admins are not blamed, the user who wrongly listed the the move at RMT get the eggs and tomatoes thrown at them. 2443:. Per Mike V, an admin is going to have to review before actually deleting anyway, so there shouldn't be two steps to the process. That's why we elect admins, to make those decisions and then carry them out. 1821:- It makes no sense to me why you would even want this. A non-admin can't perform the final deletion action necessary. Closing the discussion and performing the deletion should be simultaneous. Thus, no. 140:, non-admins are not allowed to close discussions where they can't carry out the result. My thinking is a non-admin user could close such a discussion as "consensus to delete (nac)" and then tag the redirect 2756:

review of the discussion or should they defer to the closing non-admin unless the closing non-admin's interpretation was clearly in error (i.e. a clear abuse of discretion)? I personally prefer the latter

1885:. The deleting admin bears responsibility for the deletion, so they need to satisfy themselves that the consensus of the discussion is to delete. Since they have to do that, they might as well close it. -- 1651:

But that's the thing, the closing admin doesn't have the ability to glance at the discussion for 10 seconds. If they were to enact the closing non-admin's deletion and they were wrong, the admin would be

733:- I suppose I am the proposer, or one of them anyway. I want to emphasize that the potential for lasting harm from this small change in just this forum is quite minor: abuse is likely to be detected, and 258:, where non-admin closers put speedy deletion tags on redirects that hold up page moves after a closure. I would also like to see more editors step up at RfA, and more current admins getting involved. 2118:

extra G6 tagging plus one extra quick-sanity-check by the deleting admin) will make it faster. Unless there are many more non-admins closing. In which case, why do not some of them become admins? -

3494:

listed, dating back well over a month. (And that was an underestimate, because I didn't really try to catch oddly formatted nominations.) When we switched to a bot-maintained version, there were

1577:- the decision of deletion will ultimately fall on an admin; since this admin will need to decide for himself/herself that deletion is appropriate, (s)he should be the closer of the discussion. 3535:, arguments that admins should be mere button-pushers? I can not agree with that at all, and that is why this is a bad idea. Also note that not everyone agreed it was a good idea, on TfD. The 1972:

their tools correctly, this includes deleting stuff. I will not be putting my name in any deletion log unless I took at least the same amount of effort I would take to do the actual closure.

1080:– The goal of the proposal, as I'm reading it, is not solely to "lighten the load" on administrators, but to improve the efficiency of the redirect deletion process as a whole. As always per 3673:, there is consensus that this contentious discussion should be closed by an administrator. I am not volunteering to close this myself, but I am reverting the closure at this time. — Martin 2554:. The closing admin would be responsible for the tool use and would therefore have to check that s/he agreed with the close. So this middle step would not be a good use of an editor's time. 800:

on the condition that we mandate another RfC to review the decision to allow NAC delete closures a fixed period of time - 6 months of 12 months - from the enactment of this new experiment.

3712:

How come we do not have any kind of closure? Has discussion became absolutely futile? We decide how? Whomever pushes the most? Can someone please at least summarise what is going on? -

3349:

need to review the close. Possibly to a lighter level of scrutiny than if they were closing themselves, but possibly not, because admins need to be careful not to act irresponsibly.

3097:, I think you're missing the chasm of a difference between making a request and closing a discussion. Reversing one of those has far stronger implications than reversing the other. 908:

no harms associated with discussion closure in itself, and redirects still require an actual admin to delete them, who will presumably also check the discussion. A good proposal. --

1428:

with Deryck Chan's review option. If there are discussions long outstanding that need an admin to close, please feel free to ping me. I'll try and get here more often in any case.

2099:

It's a bit galling to see someone who doesn't participate in RfD waltz in here and declare that the backlogs we've dealt with for years are a nonexistent problem. Gee, what have

1004:

What opposers fail to realize is that redirects, like templates, need to be orphaned prior to deletion, so it's not as simple as letting the admin close the discussion like AfD.

3536: 3234: 1840:

creating additional workload in such situations. (By "regular" I mean "comes around to close or participate in discussions every few days or more frequently over a long time.")

129: 97: 89: 84: 586: 72: 67: 59: 2815:

I'd like this more if this the proposal was actually for a userright to delete (just) redirects as well as close – I've got to think such a thing is technically possible. --

3294:, most likely). And technically restricting it means making some users not able to participate in discussions at all, which I'm sure most people would agree is a bad thing. 174:

delete, that I don't close because it isn't allowed if you lack the ability to fulfill the outcome (as you state above). However, all that being said: I'd rather see a few

2927:'s reasoning, but it doesn't overshadow the fact that I think that such a proposal undermines the role and value of administrators. I mean, yes, in theory, this proposal 2722: 781:

but we need a way to make sure something closed as delete actually gets deleted. I'd hate to see a discussion closed as delete, not get deleted, and then get archived.

925:, While I don't think there's a huge chance of misuse, I would like to see a restriction of this feature to certain usergroups. I also like Deryck Chan's idea above. 3290:, any editor can close a discussion. Editors who repeatedly close discussions incorrectly can be asked to stop, or formally banned from doing so by usual processes ( 1251:

Supported at TFD, will support here too. The optimal solution would be to fix RFA, but seeing as that doesn't look like happening soon this is a decent stop gap.

3540:

everyone, because it did not. I was not much of a regular - because I am a irregular contributor anyway - but I did a few TfD by then, and I did not agree. -

1445:. The amount of admins who can close RfD discussions are only those familiar with redirect policies; a choice few. The amount of admins who can delete as per 155:

I do have some ideas for conditions in mind, but don't want to waste time on it if there's just no interest in talking about it at all. What do you think?

2867:

in any namespace, so you would have to give those users universal delete rights for that to work at all. And that won't fly, I pretty much guarantee it.

501:

care to monitor TfD is not large. But I think the success in that relatively limited context is a very good sign for expanding the NAC scope elsewhere.

47: 17: 3670: 1404:

While on the one hand an admin has to do the deletion anyhow, as a practical matter this seems like it would help get the work get done much faster.

2750:

To what extent should the deleting admin give deference to the closing non-admin's interpretation of consensus? Should the deleting admin conduct a

2535:. What they would do is revert the closure and leave a comment explaining why. That's current practice and it doesn't change with this proposal. 757:- I suppose someone who is not competent to close RfDs will do so, they will simply have to be told. Apart from that, no issue. All the best: 148:

and that kind of thing would get noticed and repaired pretty quickly if it resulted in significant disruption. A while back they tried this at

122: 3363: 1897: 1503:

If it is obvious that consensus is "Delete", i.e. WP:SNOW, non-admins should be able to close as delete and put a speedy tag on the article

666: 212:

Personally, I think that weakening participants' ability to demonstrate a need for adminship is a poor reason not to do this. We're not all

3440:

deletions in a list in your sandbox, and run Twinkle's D-batch with a link to the log in the deletion summary. Maybe an RfD equivalent of

2743:

This proposal raises some interesting practical questions that I think we may want to consider if this proposal is ultimately implemented:

1453:

if necessary. This isn't just moving a backlog from one place to another. This is greatly increasing both the number of potential closers

872:- looks like a good idea. I would also like to see the removal of the NAC tagging requirement for closes that do not require sysop tools. 1954:

Responsibility is key in these situations. I want deletions to be approved by admins who represent Knowledge (XXG), not agenda-warriors.

1122:

and I generally favor "unbundling" (i.e., delegation) approaches, as WP enters a new, more mature phase of the organizational lifecycle.

3190:

arise. It sounds like "terriblizing", imagining the worst vaguely possible outcome instead of expecting the probable one. WP works on a

2219:

understaffed. I can name at least three RFD non-admin regulars that I'd personally nominate for admin if they want to get more involved

2090: 3351:

So, regardless of the level of incompetence among closers, admins stil need to do as nearly much work as if they were they closers. --

2466: 2460:

per Tavix, Mike V. RfD needs more admins, and this proposal would just add more steps (CSD tag+admin review of the discussion). ----

3671:

Knowledge (XXG):Administrators' noticeboard#Review of Knowledge (XXG) talk:Redirects for discussion#Allow non-admin delete closures?

3514:.) If the regulars at RfD aren't in agreement that this is the best way forward, then it probably won't work, even though it could. 3207: 3129: 3080: 3020: 2897: 2852: 2797: 1763: 1193:. Closing discussions per the consensus of the discussion seems well appreciated by admins. Yes, create more specific versions of 1175: 1134: 2189:

As pointed out above, why do admins need help with obvious closes; and if the close is not obvious, why is the non-admin closing?

556: 455:

Meanwhile, I'll strongly recommend non-admins to close RfDs that do not require the delete button, and for RfD regulars to run for

408:

I disagree, just because I've seen proposals like this fail in the past. I would rather see certain venues, such as RfD, serve as "

3608:

Sorry for not being clear ... the week has expired. I'm not going to be involved. I mentioned that at ANRFC but not here. - Dank (

2531:

Uninvolved administrators right now have the authority to overturn non-admin closures if they believe it was not appropriate—see

581:, as (ironically) there seem to be no admins available to implement a close, and per what I continue to believe is the spirit of 3305:

And as for the suggestion that if we do this we should review how it's working after some period of time, I fully support that.

2617:

tag to the redirect in question. The fundamental principle behind this proposal, in my view, is that more administrators patrol

3041:

judgement of administrators is not meant to be automatically superior to that of mere lowly users. Adminship is supposed to be

1040: 1802:

advises non-administrators to avoid controversial decisions – that principle will remain even after this proposal is enacted.

1387:

as a step towards unbundling, although we will probably have to visit the question of eligibility requirements down the road.

1237:

as nearly routine maintenance, with the option of a review some months down the road, though I don't think it will be needed.

2836:

move the target page over the redirect, and then move it back without leaving a redirect again (or adapt the instructions at

2086: 702:, will work here, especially as participation grows faster than the stock of available admins. All we need is something like 662: 642: 639:

for this proposal. Strangely enough this is a NAC endorsing a NAC confirming lack of consensus to expand the scope of NACs…

600: 416:, "laboratories of consensus") with an eye to making such a proposal in the future, where we can say, "Look, this works!" -- 3731:

Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

2405:

As a non-admin cannot delete an article, a non-admin shouldn't close a deletion request as "delete". It's common sense.

992:. Sure, why not. This may make RfAs even more difficult though, as it means another reason to gain the sysop tools gone. 3502:, which are a grand total of eight days old. Switching to a system that made better use of the available volunteer time 2821: 1450: 2322: 2152: 825: 395: 195: 213: 3519: 3511: 3463: 3449: 3404: 1707: 1370:

words, the non-admin will effectively recommend deletion and the admin will review and make the final decision). --

896: 589:

is clear indication that this is the case here, thus the only result which can be determined here is that there is

506: 38: 3359: 2776: 2725:(November 2015). There's a pretty significant difference between them in that the other discussion was about RfD 2194: 1893: 980: 957: 762: 532: 480: 409: 413: 3721: 3705: 3685: 3662: 3613: 3603: 3578: 3549: 3523: 3484: 3467: 3453: 3427: 3408: 3386: 3368: 3332: 3317: 3249: 3216: 3164: 3138: 3106: 3089: 3057: 3029: 2995: 2974: 2951: 2906: 2879: 2861: 2830: 2806: 2780: 2738: 2713: 2653: 2638: 2595: 2577: 2560: 2544: 2519: 2504: 2484: 2470: 2452: 2435: 2418: 2397: 2368: 2349: 2326: 2295: 2277: 2252: 2236: 2198: 2181: 2160: 2127: 2112: 2094: 2079: 2062: 2041: 2029: 2024: 2015: 2000: 1991: 1982: 1963: 1946: 1921: 1912: 1902: 1869: 1860: 1847: 1830: 1811: 1792: 1772: 1745: 1738: 1711: 1696: 1670: 1646: 1631: 1606: 1597: 1584: 1562: 1546: 1529: 1512: 1475: 1437: 1419: 1396: 1379: 1355: 1334: 1312: 1277: 1260: 1246: 1227: 1212: 1184: 1143: 1109: 1097: 1072: 1056: 1015: 999: 984: 965: 934: 917: 900: 883: 860: 847: 833: 807: 792: 768: 749: 725: 684: 651: 618: 540: 510: 486: 466: 449: 425: 403: 374: 332: 284: 244: 203: 167: 3191: 737:. Non-admins won't actually be deleting anything, simply moving processes along to their logical conclusions. 2840:

relating to preserving redirs that have edit history worth saving, in the unusual case that concern arises).

3598: 3591:

The result seems fairly obvious, cemented by previous rejections of deletion closes for non-admins in XfDs.

2431: 1959: 1163:

user right, as detailed in the discussion section below, or creating similar criteria, as Carrite suggests.

386:'s would be the way to go down this road if desired, instead of having it vary at different deletion forums. 2670:

Pinging participants in origins discussion to inform them that this has been converted to an official RfC:

2070:

A non-admin can't delete anyway. We make admins for a reason, non-admins should not be closing as delete. -

1415: 2448: 2005:

In case my overly cautious and politically correct opinion (directly above) did not make it clear -- I do

1508: 1491: 128:

Wondering if there's appetite to explore allowing non-admins to close a redirect discussion (for example,

3042: 2837: 2335: 1653: 1160: 3528: 3515: 3472: 3459: 3445: 3415: 3400: 3204: 3126: 3077: 3017: 2894: 2849: 2794: 2691: 2499: 2249: 1856: 1844: 1760: 1703: 1542: 1242: 1172: 1131: 892: 857: 804: 502: 463: 446: 593:

for this change. However, with deference to the result at AN, for procedural purposes this proposal is

3382: 3352: 3313: 3255: 3245: 3053: 2875: 2772: 2695: 2687: 2388: 2190: 2169: 1936: 1908: 1886: 1642: 1593: 1581: 1558: 1375: 976: 843: 788: 759: 745: 614: 477: 240: 163: 2991: 2970: 2947: 2731: 2709: 2273: 2179: 1732: 1433: 1351: 1330: 1308: 1223: 1208: 1203:, which will enable admins to run cursory checks within specific areas and to do the deletions. -- 1046: 930: 878: 680: 370: 328: 3151: 2221:(you probably know who you are, send me a message if you want to run and I'll gladly nominate you) 137: 3594: 3490:

list of discussions over seven days old and maintained it in my userspace; the first version had

3458:

BTW, two people who did a lot of NAC'ing at TfD are admins now, so your idea sort of works... ;)

3160: 3102: 2427: 2291: 1974: 1955: 1788: 1525: 1457:

the number of admins who know enough to press the delete button. This has successfully worked at

1106: 1010: 993: 913: 3441: 3113: 2729:

AfD. I feel like there may have been another similar thread, too, but I can't remember where. —

734: 703: 145: 3658: 2649: 2591: 2573: 2461: 2444: 2075: 1504: 1485: 1409: 1392: 1273: 1256: 348: 3287: 3178: 2532: 1799: 1297:. I never thought of "it" that way until now, and that statement makes complete sense to me. 1081: 133: 3198: 3143: 3120: 3094: 3071: 3011: 2888: 2843: 2825: 2788: 2683: 2495: 2246: 1853: 1841: 1826: 1754: 1664: 1625: 1538: 1483:

Good idea, I like it. This should help with massive backlog on most of the delete lists. -

1287: 1238: 1166: 1125: 854: 801: 460: 443: 225: 3291: 3277: 3269: 3230: 3065: 2933: 2626: 2622: 2224: 2140: 1679: 1676: 1462: 1458: 950: 582: 578: 525: 456: 383: 352: 314: 310: 306: 302: 298: 272: 183: 179: 175: 149: 3717: 3545: 3532: 3480: 3423: 3375: 3338: 3306: 3238: 3046: 2868: 2671: 2611: 2555: 2481: 2406: 2379: 2318: 2123: 2058: 1932: 1882: 1638: 1590: 1578: 1554: 1371: 1197: 1117:, per comments by actual RfD admins who say this will help them, and per BU Rob13, et al. 839: 784: 738: 710: 632: 608: 605: 233: 156: 3642: 3147: 1446: 699: 574: 255: 141: 3700: 3680: 3609: 3574: 3002: 2981: 2960: 2937: 2699: 2263: 2174: 1429: 1341: 1320: 1298: 1219: 1204: 1032: 926: 873: 670: 360: 318: 268: 2014:

until things can be straightened out, and perhaps a daily limit on all XfDs, as well?

3328: 3171: 3156: 3098: 2752: 2634: 2540: 2364: 2287: 2108: 2037: 1807: 1784: 1692: 1521: 1471: 1093: 1005: 909: 721: 421: 280: 3654: 3630: 2645: 2602: 2587: 2569: 2342: 2286:

implement. Changing that rule won't solve any problem, and will create new ones. --

2071: 1405: 1388: 1269: 1252: 1066: 3229:

For those who may be interested, the discussion on allowing non-admin closes at

2816: 1822: 1658: 1619: 1291: 229: 46:

If you wish to start a new discussion or revive an old one, please do so on the

3713: 3541: 3476: 3434: 3419: 2675: 2526: 2514: 2313: 2304: 2228: 2146: 2119: 2054: 2011: 819: 389: 189: 3696: 3676: 3586: 2785:

Agreed with all three points. See comment below about the page-mover right.

1942: 123:

Knowledge (XXG) talk:WikiProject Redirect § Allow non-admin delete closures?

271:

pushed for this sort of thing in the past and was rebuffed. But of course,

947:

the non-admin closer, who must shoulder any fallout from their decision.

3324: 2924: 2679: 2630: 2536: 2360: 2104: 2033: 1803: 1688: 1469:

we apply this highly successful strategy for backlog reduction to RfD? ~

1089: 1086:

close calls and controversial decisions are better left to administrators

1026: 717: 648: 417: 342: 291: 276: 221: 2426:- As Kosh Vorlon says, if you can't enforce it, you shouldn't close it. 2241:

I think you're right. But it depends on those RfD's non-admin regulars (

3641:

The main supports point out that this method works fine elsewhere (eg.

2618: 2356: 2308: 2173:

with redirect or other less drastic method of trimming could be used.

1617:

close it anyways.) I'm not quite sure what benefit this would serve.

1449:

is all admins, and whether the closure was correct can be handled by

522:

the nac closer should come under the gun, not the assisting admin.

3506:. That wouldn't be possible if you were right that it takes longer. 2917:

I thought I should state that even though I started this RfC, I'm

1268:. It works well at TFD and will work equally well in this case. 3343:

so long as the non-admin closer's action is not clearly erroneous

3195:

opt for, and optimize for, sensible results not unworkable ones.

783:

I didn't see the speedy G6 on the first read through, that works.

3286:: I don't think we can formally restrict this; except maybe for 2210:

after all that is completed, s/he would then delete it. That is

3276:

rare for redirects) then they can follow the usual process at

891:

works just fine at TfD where the cost of a mistake is higher.

317:'s current backlog ... it goes back to March 18 right now ... 25: 232:) are really the only admins patrolling this area regularly. 2378:

Separating the closer from the action is a really bad idea.

1687:

the closer's judgment that really needs to be discussed. --

1520:

Provided that the same caveats that apply to RM apply here.

548:

RfC: Allow non-admins to close RfD discussions to "delete"?

1105:

Yes, a admin should detete it when closed by a non-admin.

313:) is a certain amount of days backlogged. I mean, look at 3272:

for just these cases. If anyone objects to the deletion (

1682:. And the point of this is to designate these closes as 3499: 3495: 3491: 1836:

part in the discussion. NAC-delete gives us an way out

1294: 627: 2923:

on the proposal. My support for this proposal matches

2227:, although I don't think that needs to be codified. -- 3498:, still going back over a month. Right now there are 555:

The following discussion is an archived record of a

565:

No further edits should be made to this discussion.

3177:WP:RMT, or an admin refusing to protect a page at 2607:Ideally, the non-administrator would then apply a 838:This is a good condition, and should be adopted. 661:Should non-administrators be permitted to perform 3648:there are enough admins to deal with the closes. 3571:If we get 2, I'll probably offer to join them. 853:process by depleting it of uninvolved admins. 573:I am boldly re-closing this per discussion at 2307:. Instead of moving the backlog from here to 1654:responsible for not doing their due diligence 568:A summary of the conclusions reached follows. 220:admins, I guess I hadn't really noticed that 18:Knowledge (XXG) talk:Redirects for discussion 8: 1413: 1150:PS: Concerns that a) the ability to make 635:'s closing statement: there is obviously 667:Knowledge (XXG):Redirects for discussion 382:I agree. I think a broader proposal for 3150:at the very least, and likely outright 1751:going to try something completely new. 3669:Pursuant to the request for review at 3342: 347:Yeah, that's what I suggested ... an " 152:and it seems to be working just fine. 44:Do not edit the contents of this page. 3504:completely solved the backlog problem 2245:) to offer themselves up for an RfA. 1159:non-admin closes to editors with the 716:or create a more specific version. -- 669:that result in a "delete" consensus? 7: 2723:similar RfC somewhat recently at VPP 2664:Discussion (Non-admin delete closes) 111:Original discussion for delete NACs 2311:, we should promote more admins. — 2215:close as delete, but that RFD was 24: 3345:... so the admin implementing it 951:OUR Knowledge (XXG) (not "mine")! 690:Support (Non-admin delete closes) 351:" option in certain scenarios of 3727:The discussion above is closed. 3442:the holding cell's deletion list 3155:falls upon that non-admin user. 2959:Moving my opinion to "Support". 1569:Oppose (Non-admin delete closes) 1147:Revised 03:22, 5 July 2016 (UTC) 359:I posted the suggestion though. 116: 106:Allow non-admin delete closures? 29: 3635:Overall, there appears to be a 2980:...And now, moved to "oppose". 1047: 1041: 1033: 136:delete results. Currently, per 2010:backlogged, why not declare a 1496:• 20:15 on June 24, 2016 (UTC) 1031: 301:forum (with the exceptions of 1: 3298:Discretion to delete related? 3196: 3118: 3069: 3009: 2886: 2841: 2786: 1752: 1164: 1123: 706:written up. We can recommend 1037: 3722:16:08, 14 August 2016 (UTC) 2103:been wasting my time on? -- 652:09:40, 17 August 2016 (UTC) 619:17:16, 14 August 2016 (UTC) 355:backlogs. I don't remember 3746: 1675:But see, that's only true 114: 3706:21:33, 15 July 2016 (UTC) 3686:13:31, 11 July 2016 (UTC) 3579:17:22, 23 June 2016 (UTC) 3550:00:53, 17 July 2016 (UTC) 3524:23:49, 12 July 2016 (UTC) 3409:22:43, 23 June 2016 (UTC) 2996:18:41, 18 June 2016 (UTC) 2654:15:40, 20 July 2016 (UTC) 2639:15:27, 20 July 2016 (UTC) 2596:02:06, 17 July 2016 (UTC) 2471:16:39, 28 June 2016 (UTC) 2453:09:26, 25 June 2016 (UTC) 2436:21:49, 24 June 2016 (UTC) 2419:11:19, 24 June 2016 (UTC) 2398:00:37, 24 June 2016 (UTC) 2369:16:37, 27 June 2016 (UTC) 2350:22:03, 23 June 2016 (UTC) 2327:12:12, 20 June 2016 (UTC) 2296:03:01, 20 June 2016 (UTC) 2278:18:41, 18 June 2016 (UTC) 2253:19:19, 20 June 2016 (UTC) 2237:17:51, 18 June 2016 (UTC) 2199:16:57, 18 June 2016 (UTC) 2182:05:29, 16 June 2016 (UTC) 2161:02:43, 12 June 2016 (UTC) 2128:13:43, 12 June 2016 (UTC) 2113:14:56, 11 June 2016 (UTC) 2095:04:19, 11 June 2016 (UTC) 2087:StillWaitingForConnection 2080:16:26, 10 June 2016 (UTC) 2063:16:16, 10 June 2016 (UTC) 2042:05:13, 14 June 2016 (UTC) 2025:14:19, 13 June 2016 (UTC) 2001:12:17, 10 June 2016 (UTC) 1922:14:08, 13 June 2016 (UTC) 1870:14:08, 13 June 2016 (UTC) 1607:14:08, 13 June 2016 (UTC) 1563:18:53, 12 July 2016 (UTC) 1547:14:29, 12 July 2016 (UTC) 1530:19:14, 25 June 2016 (UTC) 1513:04:19, 25 June 2016 (UTC) 1476:17:41, 23 June 2016 (UTC) 1438:13:53, 12 June 2016 (UTC) 1356:18:36, 18 June 2016 (UTC) 1335:16:32, 10 June 2016 (UTC) 861:11:28, 25 July 2016 (UTC) 816:put forth by Deryck Chan. 410:laboratories of democracy 267:All this said, I believe 264:involved in a discussion. 3729:Please do not modify it. 3663:19:01, 9 July 2016 (UTC) 3614:20:25, 7 July 2016 (UTC) 3604:20:18, 6 July 2016 (UTC) 3485:11:56, 9 July 2016 (UTC) 3468:05:09, 9 July 2016 (UTC) 3454:20:55, 8 July 2016 (UTC) 3428:20:31, 7 July 2016 (UTC) 3387:20:06, 4 June 2016 (UTC) 3369:10:27, 4 June 2016 (UTC) 3333:18:43, 31 May 2016 (UTC) 3318:14:58, 31 May 2016 (UTC) 3284:Who can close as delete? 3250:23:18, 30 May 2016 (UTC) 3231:Templates for discussion 3217:14:51, 31 May 2016 (UTC) 3165:23:08, 30 May 2016 (UTC) 3139:03:25, 30 May 2016 (UTC) 3107:02:59, 30 May 2016 (UTC) 3090:02:48, 30 May 2016 (UTC) 3058:23:27, 30 May 2016 (UTC) 3030:03:45, 5 July 2016 (UTC) 2975:17:50, 2 June 2016 (UTC) 2952:21:04, 27 May 2016 (UTC) 2907:03:45, 5 July 2016 (UTC) 2880:14:42, 31 May 2016 (UTC) 2862:14:32, 31 May 2016 (UTC) 2831:02:11, 27 May 2016 (UTC) 2807:14:32, 31 May 2016 (UTC) 2781:18:23, 26 May 2016 (UTC) 2739:03:59, 26 May 2016 (UTC) 2714:17:32, 25 May 2016 (UTC) 2578:01:10, 8 July 2016 (UTC) 2561:23:21, 4 July 2016 (UTC) 2545:15:39, 9 July 2016 (UTC) 2520:18:56, 3 July 2016 (UTC) 2505:08:55, 3 July 2016 (UTC) 2485:14:23, 2 July 2016 (UTC) 1983:13:43, 8 June 2016 (UTC) 1964:06:37, 6 June 2016 (UTC) 1947:10:12, 4 June 2016 (UTC) 1903:08:01, 4 June 2016 (UTC) 1848:15:26, 1 June 2016 (UTC) 1831:02:23, 31 May 2016 (UTC) 1812:21:00, 29 May 2016 (UTC) 1793:04:13, 29 May 2016 (UTC) 1773:03:30, 30 May 2016 (UTC) 1746:16:54, 28 May 2016 (UTC) 1712:05:14, 29 May 2016 (UTC) 1697:17:22, 27 May 2016 (UTC) 1671:16:46, 27 May 2016 (UTC) 1647:00:37, 27 May 2016 (UTC) 1632:22:09, 26 May 2016 (UTC) 1585:05:20, 26 May 2016 (UTC) 1420:01:12, 9 June 2016 (UTC) 1397:13:25, 8 June 2016 (UTC) 1380:20:42, 2 June 2016 (UTC) 1340:...And now, I "oppose". 1313:17:50, 2 June 2016 (UTC) 1278:14:26, 1 June 2016 (UTC) 1261:18:59, 30 May 2016 (UTC) 1247:16:29, 30 May 2016 (UTC) 1228:04:12, 9 June 2016 (UTC) 1213:11:13, 30 May 2016 (UTC) 1185:14:35, 31 May 2016 (UTC) 1144:02:44, 30 May 2016 (UTC) 1110:02:59, 28 May 2016 (UTC) 1098:20:44, 27 May 2016 (UTC) 1073:12:11, 27 May 2016 (UTC) 1057:08:55, 27 May 2016 (UTC) 1016:01:01, 8 June 2016 (UTC) 1000:01:56, 27 May 2016 (UTC) 985:18:24, 26 May 2016 (UTC) 966:16:05, 26 May 2016 (UTC) 935:14:32, 26 May 2016 (UTC) 918:06:07, 26 May 2016 (UTC) 901:23:07, 25 May 2016 (UTC) 884:22:25, 25 May 2016 (UTC) 848:00:30, 27 May 2016 (UTC) 834:04:07, 26 May 2016 (UTC) 808:22:20, 25 May 2016 (UTC) 793:20:16, 25 May 2016 (UTC) 769:18:54, 25 May 2016 (UTC) 750:18:03, 25 May 2016 (UTC) 726:17:37, 25 May 2016 (UTC) 685:17:18, 25 May 2016 (UTC) 562:Please do not modify it. 541:20:46, 21 May 2016 (UTC) 511:01:46, 21 May 2016 (UTC) 487:00:15, 21 May 2016 (UTC) 467:10:25, 19 May 2016 (UTC) 450:22:25, 18 May 2016 (UTC) 426:20:38, 18 May 2016 (UTC) 404:19:40, 18 May 2016 (UTC) 375:20:32, 18 May 2016 (UTC) 333:17:04, 18 May 2016 (UTC) 285:15:54, 18 May 2016 (UTC) 245:15:47, 18 May 2016 (UTC) 204:04:56, 18 May 2016 (UTC) 168:04:27, 18 May 2016 (UTC) 1907:Absolutely -- I second 1852:Absolutely -- I second 1589:Absolutely -- I second 628:I was asked to weigh in 3637:consensus to implement 1064:No extra work at all. 1119:With some to-do items 595:withdrawn by proposer 587:raising of this at AN 42:of past discussions. 3629:Original closure by 3266:Admin responsibility 2085:contentious closes. 1937:User:BrownHairedGirl 631:and I fully endorse 442:: Let's experiment. 798:Conditional support 735:redirects are cheap 557:request for comment 180:request for the mop 146:redirects are cheap 3665: 1451:WP:Deletion review 3704: 3684: 3634: 3367: 3064:Mike V, see also 2829: 2716: 2559: 2222: 2159: 1981: 1980: 1901: 1497: 1422: 1148: 1052: 968: 954: 882: 832: 772: 646: 643:non-admin closure 604: 601:non-admin closure 543: 529: 526:Stick to sources! 490: 402: 377: 202: 186:was backlog wise. 103: 102: 54: 53: 48:current talk page 3737: 3694: 3674: 3602: 3590: 3529:Opabinia regalis 3516:Opabinia regalis 3473:Opabinia regalis 3460:Opabinia regalis 3446:Opabinia regalis 3438: 3416:Opabinia regalis 3401:Opabinia regalis 3380: 3358: 3355: 3311: 3258:'s points above: 3243: 3215: 3175: 3144:User:SMcCandlish 3137: 3095:User:SMcCandlish 3088: 3051: 3028: 3006: 2988: 2967: 2944: 2905: 2873: 2860: 2819: 2805: 2736: 2734: 2706: 2692:Opabinia regalis 2669: 2616: 2610: 2606: 2558: 2530: 2517: 2503: 2416: 2415: 2393: 2384: 2345: 2270: 2234: 2220: 2177: 2155: 2149: 2144: 2022: 1998: 1979: 1973: 1919: 1909:@BrownHairedGirl 1892: 1889: 1867: 1771: 1744: 1741: 1735: 1704:Opabinia regalis 1669: 1630: 1604: 1494: 1488: 1484: 1348: 1327: 1305: 1202: 1196: 1183: 1146: 1142: 1069: 1054: 1053: 1049: 1043: 1038: 1035: 1013: 1008: 997: 964: 960: 948: 893:Opabinia regalis 876: 828: 822: 817: 767: 743: 715: 709: 677: 663:non-admin closes 640: 630: 611: 598: 564: 539: 535: 523: 503:Opabinia regalis 485: 398: 392: 387: 367: 346: 339: 325: 295: 238: 198: 192: 187: 178:regulars make a 161: 120: 119: 81: 56: 55: 33: 32: 26: 3745: 3744: 3740: 3739: 3738: 3736: 3735: 3734: 3733: 3732: 3627: 3592: 3584: 3566: 3533:User:Ivanvector 3432: 3378: 3353: 3341:adds the rider 3309: 3278:deletion review 3256:Notecardforfree 3241: 3213: 3169: 3135: 3086: 3049: 3026: 3000: 2982: 2961: 2938: 2903: 2871: 2858: 2803: 2773:Notecardforfree 2732: 2730: 2700: 2696:Paine Ellsworth 2688:Rich Farmbrough 2666: 2614: 2608: 2600: 2570:Kudpung กุดผึ้ง 2524: 2515: 2493: 2469: 2411: 2407: 2391: 2382: 2343: 2264: 2229: 2191:Unscintillating 2175: 2170:BrownHairedGirl 2158: 2153: 2147: 2019:Quis separabit? 2016: 1995:Quis separabit? 1992: 1988:Oppose strongly 1933:User:Od Mishehu 1916:Quis separabit? 1913: 1887: 1864:Quis separabit? 1861: 1769: 1739: 1733: 1731: 1657: 1618: 1601:Quis separabit? 1598: 1571: 1492: 1486: 1342: 1321: 1299: 1290:'s response to 1200: 1194: 1181: 1140: 1067: 1011: 1006: 995: 977:Notecardforfree 958: 940:Strong support. 831: 826: 820: 741: 713: 707: 692: 671: 658: 626: 609: 560: 550: 533: 401: 396: 390: 361: 340: 319: 289: 236: 201: 196: 190: 159: 126: 125: 117: 113: 108: 77: 30: 22: 21: 20: 12: 11: 5: 3743: 3741: 3726: 3725: 3724: 3709: 3708: 3652: 3649: 3646: 3640: 3626: 3623: 3621: 3619: 3618: 3617: 3616: 3565: 3562: 3561: 3560: 3559: 3558: 3557: 3556: 3555: 3554: 3553: 3552: 3507: 3496:46 discussions 3492:97 discussions 3456: 3396: 3395: 3394: 3393: 3392: 3391: 3390: 3389: 3350: 3303: 3302: 3301: 3295: 3281: 3260: 3259: 3252: 3227: 3226: 3225: 3224: 3223: 3222: 3221: 3220: 3219: 3211: 3192:WP:COMMONSENSE 3133: 3084: 3062: 3061: 3060: 3038: 3037: 3036: 3035: 3034: 3033: 3032: 3024: 2915: 2914: 2913: 2912: 2911: 2910: 2909: 2901: 2856: 2812: 2811: 2810: 2809: 2801: 2768: 2767: 2766: 2762: 2758: 2745: 2744: 2741: 2733:Rhododendrites 2718: 2717: 2665: 2662: 2661: 2660: 2659: 2658: 2657: 2656: 2580: 2563: 2549: 2548: 2547: 2507: 2487: 2474: 2465: 2455: 2438: 2421: 2400: 2373: 2372: 2371: 2329: 2298: 2280: 2257: 2256: 2255: 2201: 2184: 2163: 2151: 2134: 2133: 2132: 2131: 2130: 2082: 2065: 2048: 2047: 2046: 2045: 2044: 1985: 1966: 1949: 1926: 1925: 1924: 1876: 1875: 1874: 1873: 1872: 1816: 1815: 1814: 1777: 1776: 1775: 1767: 1734:Chris Troutman 1724: 1723: 1722: 1721: 1720: 1719: 1718: 1716: 1715: 1714: 1611: 1610: 1609: 1570: 1567: 1566: 1565: 1549: 1532: 1515: 1498: 1478: 1440: 1423: 1418:comment added 1399: 1382: 1364: 1363: 1362: 1361: 1360: 1359: 1358: 1286:after reading 1263: 1249: 1232: 1231: 1230: 1188: 1179: 1138: 1115:Strong support 1112: 1107:KGirlTrucker87 1100: 1075: 1059: 1020: 1019: 1018: 987: 969: 937: 920: 903: 886: 867: 866: 865: 864: 863: 836: 824: 795: 774: 773: 752: 728: 698:Works fine at 696:Strong support 691: 688: 659: 657: 656: 655: 654: 621: 572: 571: 570: 551: 549: 546: 545: 544: 514: 513: 494: 493: 492: 491: 475:All the best: 473: 435: 434: 433: 432: 431: 430: 429: 428: 394: 380: 379: 378: 309:... and maybe 265: 260: 259: 250: 249: 248: 247: 214:hat collectors 207: 206: 194: 115: 112: 109: 107: 104: 101: 100: 95: 92: 87: 82: 75: 70: 65: 62: 52: 51: 34: 23: 15: 14: 13: 10: 9: 6: 4: 3: 2: 3742: 3730: 3723: 3719: 3715: 3711: 3710: 3707: 3702: 3698: 3691: 3690: 3689: 3688: 3687: 3682: 3678: 3672: 3666: 3664: 3660: 3656: 3644: 3638: 3632: 3624: 3622: 3615: 3611: 3607: 3606: 3605: 3600: 3596: 3595:Esquivalience 3588: 3583: 3582: 3581: 3580: 3576: 3572: 3563: 3551: 3547: 3543: 3538: 3534: 3530: 3527: 3526: 3525: 3521: 3517: 3513: 3508: 3505: 3501: 3497: 3493: 3488: 3487: 3486: 3482: 3478: 3474: 3471: 3470: 3469: 3465: 3461: 3457: 3455: 3451: 3447: 3443: 3436: 3431: 3430: 3429: 3425: 3421: 3417: 3413: 3412: 3411: 3410: 3406: 3402: 3388: 3384: 3377: 3372: 3371: 3370: 3365: 3361: 3357: 3348: 3344: 3340: 3336: 3335: 3334: 3330: 3326: 3321: 3320: 3319: 3315: 3308: 3304: 3299: 3296: 3293: 3289: 3285: 3282: 3279: 3275: 3271: 3267: 3264: 3263: 3262: 3261: 3257: 3253: 3251: 3247: 3240: 3236: 3232: 3228: 3218: 3209: 3206: 3203: 3201: 3193: 3188: 3184: 3180: 3173: 3168: 3167: 3166: 3162: 3158: 3153: 3149: 3145: 3142: 3141: 3140: 3131: 3128: 3125: 3123: 3115: 3110: 3109: 3108: 3104: 3100: 3096: 3093: 3092: 3091: 3082: 3079: 3076: 3074: 3067: 3063: 3059: 3055: 3048: 3044: 3039: 3031: 3022: 3019: 3016: 3014: 3004: 2999: 2998: 2997: 2993: 2989: 2987: 2986: 2979: 2978: 2977: 2976: 2972: 2968: 2966: 2965: 2957: 2956: 2955: 2954: 2953: 2949: 2945: 2943: 2942: 2935: 2930: 2926: 2922: 2921: 2916: 2908: 2899: 2896: 2893: 2891: 2883: 2882: 2881: 2877: 2870: 2865: 2864: 2863: 2854: 2851: 2848: 2846: 2839: 2834: 2833: 2832: 2827: 2823: 2818: 2814: 2813: 2808: 2799: 2796: 2793: 2791: 2784: 2783: 2782: 2778: 2774: 2769: 2763: 2759: 2755: 2754: 2749: 2748: 2747: 2746: 2742: 2740: 2735: 2728: 2724: 2720: 2719: 2715: 2711: 2707: 2705: 2704: 2697: 2693: 2689: 2685: 2681: 2677: 2673: 2668: 2667: 2663: 2655: 2651: 2647: 2642: 2641: 2640: 2636: 2632: 2628: 2624: 2620: 2613: 2604: 2599: 2598: 2597: 2593: 2589: 2584: 2581: 2579: 2575: 2571: 2567: 2564: 2562: 2557: 2553: 2550: 2546: 2542: 2538: 2534: 2528: 2523: 2522: 2521: 2518: 2511: 2508: 2506: 2501: 2497: 2491: 2488: 2486: 2483: 2478: 2475: 2472: 2468: 2467:contributions 2463: 2459: 2456: 2454: 2450: 2446: 2442: 2439: 2437: 2433: 2429: 2425: 2422: 2420: 2417: 2414: 2410: 2404: 2401: 2399: 2396: 2395: 2394: 2387: 2386: 2385: 2377: 2374: 2370: 2366: 2362: 2358: 2353: 2352: 2351: 2348: 2347: 2346: 2337: 2333: 2330: 2328: 2324: 2320: 2316: 2315: 2310: 2306: 2302: 2299: 2297: 2293: 2289: 2284: 2281: 2279: 2275: 2271: 2269: 2268: 2261: 2258: 2254: 2251: 2248: 2244: 2240: 2239: 2238: 2235: 2232: 2226: 2218: 2213: 2209: 2205: 2202: 2200: 2196: 2192: 2188: 2185: 2183: 2180: 2178: 2171: 2167: 2164: 2162: 2156: 2150: 2142: 2138: 2135: 2129: 2125: 2121: 2116: 2115: 2114: 2110: 2106: 2102: 2098: 2097: 2096: 2092: 2088: 2083: 2081: 2077: 2073: 2069: 2066: 2064: 2060: 2056: 2052: 2049: 2043: 2039: 2035: 2030: 2028: 2027: 2026: 2023: 2021: 2020: 2013: 2008: 2004: 2003: 2002: 1999: 1997: 1996: 1989: 1986: 1984: 1978: 1977: 1970: 1967: 1965: 1961: 1957: 1956:SteveStrummer 1953: 1950: 1948: 1945: 1944: 1938: 1934: 1930: 1927: 1923: 1920: 1918: 1917: 1911:'s comments. 1910: 1906: 1905: 1904: 1899: 1895: 1891: 1884: 1880: 1877: 1871: 1868: 1866: 1865: 1859:'s comments. 1858: 1855: 1851: 1850: 1849: 1846: 1843: 1839: 1834: 1833: 1832: 1828: 1824: 1820: 1817: 1813: 1809: 1805: 1801: 1796: 1795: 1794: 1790: 1786: 1781: 1780:Strong oppose 1778: 1774: 1765: 1762: 1759: 1757: 1749: 1748: 1747: 1742: 1736: 1728: 1725: 1717: 1713: 1709: 1705: 1700: 1699: 1698: 1694: 1690: 1685: 1681: 1678: 1674: 1673: 1672: 1668: 1667: 1662: 1661: 1655: 1650: 1649: 1648: 1644: 1640: 1635: 1634: 1633: 1629: 1628: 1623: 1622: 1615: 1612: 1608: 1605: 1603: 1602: 1596:'s comments. 1595: 1592: 1588: 1587: 1586: 1583: 1580: 1576: 1573: 1572: 1568: 1564: 1560: 1556: 1553: 1550: 1548: 1544: 1540: 1536: 1533: 1531: 1527: 1523: 1519: 1516: 1514: 1510: 1506: 1502: 1499: 1495: 1489: 1482: 1479: 1477: 1474: 1473: 1468: 1464: 1460: 1456: 1452: 1448: 1444: 1441: 1439: 1435: 1431: 1427: 1424: 1421: 1417: 1411: 1407: 1403: 1400: 1398: 1394: 1390: 1386: 1383: 1381: 1377: 1373: 1368: 1365: 1357: 1353: 1349: 1347: 1346: 1339: 1338: 1337: 1336: 1332: 1328: 1326: 1325: 1317: 1316: 1315: 1314: 1310: 1306: 1304: 1303: 1296: 1293: 1289: 1285: 1281: 1280: 1279: 1275: 1271: 1267: 1264: 1262: 1258: 1254: 1250: 1248: 1244: 1240: 1236: 1233: 1229: 1225: 1221: 1216: 1215: 1214: 1210: 1206: 1199: 1192: 1189: 1187: 1186: 1177: 1174: 1171: 1169: 1162: 1158: 1153: 1145: 1136: 1133: 1130: 1128: 1120: 1116: 1113: 1111: 1108: 1104: 1101: 1099: 1095: 1091: 1087: 1083: 1079: 1076: 1074: 1071: 1070: 1063: 1060: 1058: 1055: 1050: 1044: 1036: 1028: 1024: 1021: 1017: 1014: 1009: 1003: 1002: 1001: 998: 991: 988: 986: 982: 978: 973: 970: 967: 963: 962: 961: 953: 952: 946: 941: 938: 936: 932: 928: 924: 921: 919: 915: 911: 907: 904: 902: 898: 894: 890: 887: 885: 880: 875: 871: 868: 862: 859: 856: 851: 850: 849: 845: 841: 837: 835: 829: 823: 815: 814:the condition 811: 810: 809: 806: 803: 799: 796: 794: 790: 786: 782: 778: 775: 770: 765: 764: 761: 756: 753: 751: 747: 740: 736: 732: 729: 727: 723: 719: 712: 705: 701: 697: 694: 693: 689: 687: 686: 682: 678: 676: 675: 668: 664: 653: 650: 644: 638: 634: 629: 625: 624: 623: 622: 620: 616: 612: 607: 602: 596: 592: 588: 584: 580: 576: 569: 566: 563: 558: 553: 552: 547: 542: 538: 537: 536: 528: 527: 521: 516: 515: 512: 508: 504: 500: 495: 488: 483: 482: 479: 474: 470: 469: 468: 465: 462: 458: 454: 453: 452: 451: 448: 445: 441: 427: 423: 419: 415: 411: 407: 406: 405: 399: 393: 385: 381: 376: 372: 368: 366: 365: 358: 354: 350: 344: 338: 337: 336: 335: 334: 330: 326: 324: 323: 316: 312: 308: 304: 300: 293: 288: 287: 286: 282: 278: 274: 270: 266: 262: 261: 257: 252: 251: 246: 242: 235: 231: 227: 223: 219: 215: 211: 210: 209: 208: 205: 199: 193: 185: 181: 177: 172: 171: 170: 169: 165: 158: 153: 151: 147: 143: 139: 135: 131: 124: 110: 105: 99: 96: 93: 91: 88: 86: 83: 80: 76: 74: 71: 69: 66: 63: 61: 58: 57: 49: 45: 41: 40: 35: 28: 27: 19: 3728: 3668: 3667: 3639:the proposal 3636: 3631:User:Mdann52 3628: 3620: 3610:push to talk 3575:push to talk 3570: 3567: 3537:realated RfC 3503: 3444:would help. 3397: 3346: 3297: 3283: 3273: 3265: 3233:is archived 3199: 3186: 3182: 3121: 3072: 3012: 2984: 2983: 2963: 2962: 2958: 2940: 2939: 2928: 2919: 2918: 2889: 2844: 2838:WP:PAGEMOVER 2789: 2751: 2726: 2721:There was a 2702: 2701: 2582: 2565: 2551: 2509: 2489: 2476: 2462:Patar knight 2457: 2445:Softlavender 2440: 2423: 2412: 2408: 2402: 2390: 2389: 2381: 2380: 2375: 2341: 2340: 2331: 2312: 2300: 2282: 2266: 2265: 2259: 2242: 2230: 2216: 2211: 2207: 2203: 2186: 2165: 2136: 2100: 2067: 2050: 2018: 2017: 2006: 1994: 1993: 1987: 1975: 1968: 1951: 1941: 1928: 1915: 1914: 1878: 1863: 1862: 1837: 1818: 1779: 1755: 1726: 1683: 1665: 1659: 1626: 1620: 1613: 1600: 1599: 1574: 1551: 1534: 1517: 1505:Jjjjjjdddddd 1501:Weak Support 1500: 1487:Neutralhomer 1480: 1470: 1466: 1454: 1442: 1425: 1401: 1384: 1366: 1344: 1343: 1323: 1322: 1318: 1301: 1300: 1284:Weak support 1283: 1282: 1265: 1234: 1190: 1167: 1156: 1151: 1149: 1126: 1118: 1114: 1102: 1085: 1077: 1065: 1061: 1030: 1022: 989: 971: 956: 955: 949: 944: 939: 923:Weak support 922: 905: 888: 869: 813: 797: 780: 776: 758: 754: 730: 695: 673: 672: 660: 637:no consensus 636: 594: 591:no consensus 590: 567: 561: 554: 531: 530: 524: 519: 498: 476: 439: 436: 363: 362: 356: 321: 320: 217: 154: 132:) which are 127: 78: 43: 37: 3512:this thread 3200:SMcCandlish 3122:SMcCandlish 3073:SMcCandlish 3043:no big deal 3013:SMcCandlish 2890:SMcCandlish 2845:SMcCandlish 2790:SMcCandlish 2761:privileges? 2684:Deryck Chan 2496:Checkingfax 2260:Weak oppose 2137:Weak Oppose 1756:SMcCandlish 1539:Herostratus 1414:—Preceding 1288:Deryck Chan 1239:First Light 1168:SMcCandlish 1127:SMcCandlish 226:Deryck Chan 121:Moved from 36:This is an 3376:Ivanvector 3356:HairedGirl 3339:Ivanvector 3307:Ivanvector 3288:topic bans 3254:Regarding 3239:Ivanvector 3047:Ivanvector 2869:Ivanvector 2672:Ivanvector 2482:Randy Kryn 2012:moratorium 1890:HairedGirl 1883:Od Mishehu 1677:if we want 1639:Tazerdadog 1594:Od Mishehu 1582:Od Mishehu 1555:Agathoclea 1372:Malcolmxl5 1161:page-mover 840:Tazerdadog 785:Tazerdadog 763:Farmbrough 739:Ivanvector 633:Ivanvector 606:Ivanvector 481:Farmbrough 234:Ivanvector 157:Ivanvector 98:Archive 15 90:Archive 11 85:Archive 10 3270:criterion 3152:WP:ARBCOM 3003:Steel1943 2985:Steel1943 2964:Steel1943 2941:Steel1943 2757:approach. 2703:Steel1943 2267:Steel1943 2243:ahem ahem 2176:Montanabw 1591:עוד מישהו 1579:עוד מישהו 1430:Thryduulf 1345:Steel1943 1324:Steel1943 1302:Steel1943 1220:SmokeyJoe 1205:SmokeyJoe 1034:Anarchyte 927:Tpdwkouaa 874:Ajraddatz 674:Steel1943 364:Steel1943 322:Steel1943 269:Steel1943 138:WP:BADNAC 79:Archive 9 73:Archive 8 68:Archive 7 60:Archive 5 3653:Thanks, 3573:- Dank ( 3414:Hmmm... 3364:contribs 3172:Mdrnpndr 3157:Mdrnpndr 3114:WP:DRAMA 3099:Mdrnpndr 2822:contribs 2288:MelanieN 2217:slightly 2208:and then 1976:HighInBC 1898:contribs 1785:Mdrnpndr 1680:it to be 1522:PaleAqua 1467:wouldn't 1103:Support: 972:Support. 910:Tom (LT) 812:Support 704:WP:RMNAC 577:and per 130:this one 3655:Mdann52 3625:Closure 3564:30 days 3337:Hmm. @ 3179:WP:RFPP 2934:WP:RFAs 2920:neutral 2753:de novo 2646:Msnicki 2619:CAT:CSD 2603:Msnicki 2588:Msnicki 2583:Oppose. 2556:SarahSV 2533:WP:NACD 2357:CAT:CSD 2344:Hut 8.5 2309:CAT:CSD 2072:DJSasso 1838:without 1800:WP:NACD 1552:Support 1535:Support 1518:Support 1481:Support 1443:Support 1426:Support 1416:undated 1406:Nwlaw63 1402:Support 1389:Carrite 1385:Support 1367:Support 1270:Deli nk 1266:Support 1253:Jenks24 1235:Support 1191:Support 1082:WP:NACD 1078:Support 1068:Lugnuts 1062:Support 1023:Support 990:Support 906:Support 889:Support 870:Support 777:Support 755:Support 731:Support 412:" (or, 218:current 134:obvious 39:archive 3360:(talk) 3292:WP:ANI 3066:WP:RMT 2817:IJBall 2694:& 2627:WP:TFD 2623:WP:RFD 2612:db-xfd 2566:Oppose 2552:Oppose 2510:Oppose 2490:Oppose 2477:Oppose 2458:Oppose 2441:Oppose 2424:Oppose 2413:Vorlon 2403:Oppose 2392:apolis 2376:Oppose 2336:policy 2332:Oppose 2301:Oppose 2283:Oppose 2247:Deryck 2225:WP:IAR 2204:Oppose 2187:Oppose 2168:: per 2166:Oppose 2068:Oppose 2051:Oppose 1969:Oppose 1952:Oppose 1929:Oppose 1894:(talk) 1879:Oppose 1857:yck C. 1845:yck C. 1823:Fieari 1819:Oppose 1727:Oppose 1660:Mike V 1621:Mike V 1614:Oppose 1575:Oppose 1463:WP:CfD 1459:WP:TfD 1292:Fieari 1198:db-xfd 1157:delete 1152:delete 855:Deryck 805:yck C. 711:db-xfd 583:WP:NAC 579:WP:IAR 464:yck C. 457:WP:RFA 447:yck C. 353:WP:XFD 315:WP:FFD 311:WP:MFD 307:WP:TFD 303:WP:AFD 299:WP:XFD 273:WP:CCC 230:JohnCD 150:WP:TfD 3714:Nabla 3643:WP:RM 3542:Nabla 3477:Nabla 3435:Nabla 3420:Nabla 3354:Brown 3148:WP:AN 2765:well? 2676:Godsy 2621:than 2527:-revi 2314:Kusma 2305:Nabla 2148:Godsy 2120:Nabla 2055:Nabla 1888:Brown 1881:per 1447:WP:G6 1012:flyer 996:flyer 959:Paine 821:Godsy 700:WP:RM 575:WP:AN 534:Paine 440:tl;dr 391:Godsy 357:where 256:WP:RM 228:(and 191:Godsy 142:WP:G6 16:< 3718:talk 3701:talk 3697:MSGJ 3681:talk 3677:MSGJ 3659:talk 3599:talk 3587:Dank 3546:talk 3520:talk 3481:talk 3464:talk 3450:talk 3424:talk 3405:talk 3383:talk 3347:does 3329:talk 3314:talk 3274:very 3246:talk 3235:here 3161:talk 3103:talk 3054:talk 2992:talk 2971:talk 2948:talk 2876:talk 2826:talk 2777:talk 2710:talk 2650:talk 2635:talk 2592:talk 2574:talk 2541:talk 2516:Revi 2500:Talk 2498:}} { 2494:{{u| 2449:talk 2432:talk 2409:Kosh 2383:Mini 2365:talk 2334:per 2303:per 2292:talk 2274:talk 2233:avix 2195:talk 2154:CONT 2124:talk 2109:talk 2091:talk 2076:talk 2059:talk 2038:talk 1960:talk 1943:jc37 1931:per 1827:talk 1808:talk 1789:talk 1740:talk 1708:talk 1693:talk 1666:Talk 1643:talk 1627:Talk 1559:talk 1543:talk 1526:talk 1509:talk 1493:Talk 1461:and 1434:talk 1410:talk 1393:talk 1376:talk 1352:talk 1331:talk 1309:talk 1295:here 1274:talk 1257:talk 1243:talk 1224:talk 1209:talk 1094:talk 1048:talk 1042:work 1025:per 981:talk 945:only 931:talk 914:talk 897:talk 879:talk 844:talk 827:CONT 789:talk 760:Rich 746:talk 722:talk 681:talk 615:talk 520:only 507:talk 478:Rich 422:talk 397:CONT 371:talk 349:AHOD 329:talk 305:and 281:talk 275:. -- 241:talk 224:and 197:CONT 164:talk 3500:six 3362:• ( 3325:Mz7 3214:ⱷ≼ 3210:≽ⱷ҅ 3187:con 3185:or 3183:pro 3136:ⱷ≼ 3132:≽ⱷ҅ 3087:ⱷ≼ 3083:≽ⱷ҅ 3027:ⱷ≼ 3023:≽ⱷ҅ 2925:BDD 2904:ⱷ≼ 2900:≽ⱷ҅ 2859:ⱷ≼ 2855:≽ⱷ҅ 2804:ⱷ≼ 2800:≽ⱷ҅ 2737:\\ 2727:and 2680:BDD 2631:Mz7 2537:Mz7 2464:- / 2428:BMK 2361:Mz7 2141:DRV 2105:BDD 2034:Mz7 2007:not 1896:• ( 1854:Der 1842:Der 1804:Mz7 1770:ⱷ≼ 1766:≽ⱷ҅ 1689:BDD 1684:not 1472:Rob 1455:and 1182:ⱷ≼ 1178:≽ⱷ҅ 1141:ⱷ≼ 1137:≽ⱷ҅ 1090:Mz7 1027:BDD 1007:SST 994:SST 802:Der 718:BDD 665:on 649:JFG 499:and 461:Der 444:Der 418:BDD 414:umm 384:XFD 343:BDD 292:BDD 277:BDD 222:BDD 184:TfD 176:RfD 3720:) 3699:· 3679:· 3661:) 3633:: 3612:) 3593:— 3577:) 3548:) 3522:) 3483:) 3466:) 3452:) 3426:) 3407:) 3385:) 3379:🍁 3331:) 3316:) 3310:🍁 3248:) 3242:🍁 3237:. 3197:— 3163:) 3119:— 3105:) 3070:— 3056:) 3050:🍁 3010:— 2994:) 2973:) 2950:) 2929:is 2887:— 2878:) 2872:🍁 2842:— 2824:• 2787:— 2779:) 2712:) 2698:. 2690:, 2686:, 2682:, 2678:, 2674:, 2652:) 2637:) 2629:. 2615:}} 2609:{{ 2594:) 2576:) 2543:) 2451:) 2434:) 2367:) 2325:) 2294:) 2276:) 2250:C. 2212:so 2197:) 2126:) 2111:) 2093:) 2078:) 2061:) 2040:) 1962:) 1935:, 1829:) 1810:) 1791:) 1753:— 1710:) 1695:) 1663:• 1645:) 1624:• 1561:) 1545:) 1528:) 1511:) 1490:• 1436:) 1412:) 1395:) 1378:) 1354:) 1333:) 1311:) 1276:) 1259:) 1245:) 1226:) 1211:) 1201:}} 1195:{{ 1165:— 1124:— 1096:) 1084:, 1045:| 1029:. 983:) 933:) 916:) 899:) 858:C. 846:) 791:) 779:, 748:) 742:🍁 724:) 714:}} 708:{{ 683:) 647:— 617:) 610:🍁 597:. 559:. 509:) 459:. 424:) 373:) 331:) 283:) 243:) 237:🍁 166:) 160:🍁 94:→ 64:← 3716:( 3703:) 3695:( 3683:) 3675:( 3657:( 3601:) 3597:( 3589:: 3585:@ 3544:( 3518:( 3479:( 3462:( 3448:( 3437:: 3433:@ 3422:( 3403:( 3381:( 3366:) 3327:( 3312:( 3280:. 3244:( 3212:ᴥ 3208:¢ 3205:☏ 3202:☺ 3174:: 3170:@ 3159:( 3134:ᴥ 3130:¢ 3127:☏ 3124:☺ 3101:( 3085:ᴥ 3081:¢ 3078:☏ 3075:☺ 3052:( 3025:ᴥ 3021:¢ 3018:☏ 3015:☺ 3005:: 3001:@ 2990:( 2969:( 2946:( 2902:ᴥ 2898:¢ 2895:☏ 2892:☺ 2874:( 2857:ᴥ 2853:¢ 2850:☏ 2847:☺ 2828:) 2820:( 2802:ᴥ 2798:¢ 2795:☏ 2792:☺ 2775:( 2708:( 2648:( 2633:( 2605:: 2601:@ 2590:( 2572:( 2539:( 2529:: 2525:@ 2502:} 2473:, 2447:( 2430:( 2363:( 2323:c 2321:· 2319:t 2317:( 2290:( 2272:( 2231:T 2193:( 2157:) 2145:— 2122:( 2107:( 2101:I 2089:( 2074:( 2057:( 2036:( 1958:( 1900:) 1825:( 1806:( 1787:( 1768:ᴥ 1764:¢ 1761:☏ 1758:☺ 1743:) 1737:( 1706:( 1691:( 1641:( 1557:( 1541:( 1524:( 1507:( 1432:( 1408:( 1391:( 1374:( 1350:( 1329:( 1307:( 1272:( 1255:( 1241:( 1222:( 1207:( 1180:ᴥ 1176:¢ 1173:☏ 1170:☺ 1139:ᴥ 1135:¢ 1132:☏ 1129:☺ 1092:( 1051:) 1039:( 979:( 929:( 912:( 895:( 881:) 877:( 842:( 830:) 818:— 787:( 771:. 766:, 744:( 720:( 679:( 645:) 641:( 613:( 603:) 599:( 505:( 489:. 484:, 420:( 400:) 388:— 369:( 345:: 341:@ 327:( 294:: 290:@ 279:( 239:( 200:) 188:— 162:( 50:.

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.

Knowledge (XXG)

talk:Redirects for discussion/Archive 9 - Knowledge (XXG)

Index