Knowledge talk:Requests for permissions/Archive 5

3361:

edits. They have spent the same time on wikipedia, and they have pumped out the same number of edits. So telling someone to come back in a month or two doesn't really do anything to ensure they are any better than someone who puts some time in and returns the next week. Obviously using edit count as proxi for suitability is what your lamenting. So is there something different we could do? What about coming up with a way to quiz them on policy? (maybe have a threshold after which the quiz isn't mandatory) The number of people who deliberately seek out permissions with the intent to use them inappropriately is very low. So really, we should care almost exclusively whether the person is competent to use the tool, and very little whether they are trustworthy. Rollback doesn't even let you disrupt Knowledge much more effectively than Twinkle, and Reviewer, with PC2 banned, could at most be used to abusively reject IP edits, but you can just revert them anyway. We don't get much pagemove vandalism, so filemoving shouldn't be a big issue either, and that covers the frequently requested, frequently denied ones. Autopatrolled already has clear guidelines that are hard to spam to meet, and template editor receives much more meaningful review.

5378:

of wiggle room, however. For example, if the user has 100 mainspace edits, but from those it is clear they know how to tell the difference between good-faith edits and vandalism, and are they are willing to help out, I think we can take the leap of faith and ignore the 200 mainspace edit rule. Similarly, unless they have themselves been disruptive in the past, I don't think it's necessary to look beyond contributions relevant to counter-vandalism. It's okay if the only thing they're interested in is reverting vandals all day with Huggle. It is fun, constructive, and we could always use another helping hand. All this being said, I'd consider pending-changes reviewer the lowest bar for user rights, as it merely re-enables a tacit ability autoconfirmed users possessed prior to the implementation of pending changes—the ability to approve anonymous edits (this explanation borrowed from the

5252:(which is what I meant by "the history", as opposed to the diff view). Yes, Twinkle links could be added to the history, and to RC as well I'm sure, which I disagree is useless. I see that my concerns are not strictly valid: there is no pressing need for rollback to exist, as Twinkle performs the same function. But is it really worth it to get rid of rollback? I don't see what we'd gain by doing so; we'd have less examination of those wanting the right, thus increasing the risk that it would be misused (indeed Twinkle can be abused, but having at least some people go through the scrutiny of rollback requests cuts down on that kind of thing), and modifying the Twinkle script and its preferences seems a great deal of fiddling for little benefit. 4801:

declined I would never have known. There is also a minor issue of at the request for confirmation. As we all know, most request there are declined. However, we are dealing almost exclusively with brand new users there. I for one feel it is important in almost all cases to welcome those users, even (especially actually) if they deeply misunderstand what Knowledge is and how it works. Unfortunately not everyone sees it that way and there are some who just decline requests without following it up with a welcome on their talk page, so I end up following up for them and welcoming all the people they decline. As this is an editor retention/

702:

permission to make it yourself? Is requesting a move as good as getting the permission and being able to do it yourself? Only after answering that question should we get to how we deal with all the currently rejected requests. The permission description at the top suggests it may be granted for those reasons, so a first step could be making it clearer in what circumstances we do actually grant it. So, for instance if we are never going to grant confirmed for file uploads by new contributors, absent really peculiar circumstances, I don't see why non-admins couldn't direct them to commons/FFU as appropriate.

4272:) that have been marked as done for almost 4 weeks now, and there are many that where marked as done over a week ago. I see no reason that the sections marked as "done" explicitly should be kept on the page for more than 24 hours (or 3 days max) as the user that received the additional group to their rights would have gotten a notification through the system. Anyone that would know to look at the PERM page to object to a user being granted certain rights should be experienced enough to know to look at the archives if it has been longer than that in most cases I would think. — 475: 161: 5617: 5495: 3745: 1362: 1204: 822: 269: 4184: 2327: 3328:

up the right numbers, followed by new requests. This is not a good trend asi ti encourages users to see these rights as a "level up" as if this were a video game. Now, putting a time limit on re-application may cause a similar effect, making users believe if they just wait the mere passage of time is enough. The message they should be getting is that rollback/reviewer is easy to get if they just do some good article work. So, I guess I'm asking if anyone else sees this as a problem and if they have any ideas what me might do to curb it.

4647:: I think we need to take a look at my questions above which no one has taken the trouble to address. Also, the archiving is still too fast, we have users reposting their declined requests within two days. All declined requests should preferably only be archived after 7 days. And thank you , Armbrust, for stepping into the breach and doing what you have been doing for years so much better than a bot. We ae getting to the stage on Knowledge where in many cases we are placing too much reliance on bots. -- 2513:. The key arguments are: 1) Removal of enhanced user rights (non-admin) is not required as blocked accounts are largely incapable of exercising such rights while blocked. 2) There is discretion for blocking admins to unilaterally remove enhanced user rights where the reason for the block correlates to use of an enhanced user right. 3) There are already mechanisms in place for the removal of especially powerful non-admin user rights, as result of inactivity or abuse, specifically 'account creator' and 'template editor'. 5091:, I agree with most of what you said. Twinkle isn't available from day one, it's available from whenever autoconfirmed is obtained (day 4 if they have 10 edits). Also, the only real reasons to have rollback is to be able to use a few userscripts and tools like Stiki and Huggle. I'm actually wondering if the hat shouldn't just be done away with or rolled into reviewer or something. Scripts and tools that rely on it could certainly be updated. Is there any valid reason for keeping it around and not doing this? — 3423:

manually revert vandalism and make some AIV reports to demonstrate that they are capable of distinguishing bad-faith edits from other types of edits? That level of clarity should deal with the issue. If they don't do it, they aren't interested in vandal fighting and didn't need the right to begin with. If they do do it, it should be easy to tell if they are able to tell the difference between vandalism and other edits that may be problematic but were made in good faith.

5583: 4447:

is a bad idea as it means that "other" parties that may have been following a certain request have to look in two places instead of one to find the result if it wasn't the result they expected) or if we should configure CBot to archive it all on one archive page. I'll need to know this before I make a special module for OCA to archive these discussions (if it is the first option, it may require two clicks to archive correctly each time). —

31: 4881: 2772: 4956: 4890: 2763: 5198:

when edit warring with a vandal or reverting oneself), and also makes it possible to see which edits in recent changes are current revisions. Twinkle also opens popup windows, which may not be desirable, is allegedly slower, and may stop working when we upgrade to MW 1.26. I don't know about anyone else, but I'd rather have rollback than resort to using Twinkle's "vandalism" links (I haven't got round to asking, though).

2456:

such, there needs to be an allowance for people who create hundreds (or thousands) of new templates, modules, etc. If someone wants to propose that only articles show up in the NPP queue, and there is community consensus, I'd be happy to assist with the creation of the Bugzilla ticket to make that technically possible; but, until this is done, I can't support any "NPP is article only" proposals. —

5678: 5548: 5442: 4137: 4028: 3957: 3684: 3604: 2280: 2207: 2138: 2069: 2000: 1912: 1799: 1313: 1163: 1084: 874: 763: 412: 225: 115: 3511:. As usual, the yellow ones are unpatrolled. When I visit a talk page that exists but is not yet patrolled, and at least one of the edits was useful (starting a discussion, sending a templated warning, adding a WikiProject banner), I normally mark it as patrolled. But if the sole content is rubbish like "djkvbdfjkvbjfvkdfb", I don't patrol it but instead mark it 4126: 5002: 4751: 4491: 5014: 3791: 3651: 3438:

the last 500 edits, and found everything I needed there. But this tool is for clear vandalism, not reverting good faith requests. I feel our granting of the tool should fall with editors doing that. We should revamp the template too, I really don't see the proper use for it, but then again, that's me jumping in brand new as an outsider. --

1270: 4098: 5164:

tools, unless they want it done directly as is done with AWB. However, to make that change will require a big RFC, and I'm in the middle of putting together one of those on an entirely separate issue right now and it will probably need me to babysit it for a while after it goes live. Anyone up for it? I can at least offer

5337:

that want to use those tools specifically and not everyone that 'just wants the hat' or misunderstands what the group does/is for. I think elimination of the hat is a net gain. You are welcome to disagree, and I encourage productive discussion if that is the case or an agreeance to disagree. :) Happy editing! —

1548:

article about a particular article about a golfer (Rory McIlroy or Adam Scott, for example) and see that the latest edit is vandalistic in nature, and I try to correct it as soon as possible. My typical edits though tend to be the week-to-week entries for the latest winners of the different golf tours.

5386:

vandalism but more so just understanding basic policy and with that being able to infer if any given edit is appropriate for the encyclopedia. Finally, barring blatant misjudgement, I respect any admin's decision and do not question their decisions in granting the rights or declining requests. I also

5336:

I assume that if rollback were eliminated, one would gain access either through gaining access to the group it was added to (perhaps reviewer, or if it passes the proposed 'vandal figther/senty') or a CheckPage like AWB does. This would still be less work because it would only be requests for people

5143:...Or instead of having the rollback, why don't we just do a dummy edit on a previous version of the page we want to restore, save, and magically, a non-rollback ... rollback! Seriously, I always found this user right to be a bit redundant, given that the function can be accomplished via other means. 5065:

Personally I never had rollback until I became an admin and I never missed it because I use twinkle. Actually, I would rather not have it as it just gets in my way but apparently if you are an admin you have it whether you want it or not. The point is, this is an extremely low-level user right, there

4746:

Please bear in mind that this is coming from someone with no clue about bot programming, but perhaps it would make sense to leave declined requests a bit longer than accepted ones in order to insure the user has seen them? When granting permissions, I certainly hope all of us are leaving the standard

4434:

We don't really need a formal RFC type discussion on this, it is a completely non-controversial task in that noone opposes having an archive; if one set of archiving tools is more reliable than another for this set of pages, discussion on this page is all that is needed to swap / augment. This page,

3468:

The guideline for autopatroller refers to “articles”, but does the creation of pages in the Talk: and User talk: namespaces add to the NPP workload? Although I have a couple of ideas for articles, I haven’t actually written any yet, and I’m a champion procrastinator. OTOH, when I undo poor edits from

2968:

I'm not a fan of the idea, mainly because I don't think it's worth the effort, but if anyone wants to take the time to remove rollbacker, reviewer, etc. from blocked accounts they should be allowed to; however, I don't think it's necessary to remove these rights from users who are simply inactive but

2718:

The procedure is literally two clicks; I'm simply trying to determine if consensus supports this to be allowable; I had assumed that a rule wouldn't be needed and that admin-discretion would be sufficient, though the prior discussion was mentioned and I wanted to poll the current community consensus.

3219:

And actual cases of "hacked accounts" are incredibly rare so I don't think we should be making policy based on fear of that contingency. In the event that there is an actual compromised account, blocking is immediate and permanent, so the minute it is detected user rights are by definition no longer

3183:

you don't consider the power to mass rollback hundreds of edits in a very short period of time to be a "powerful" userright? I certainly do. The only userright I wouldn't consider overly powerful in a way that could be misused on a hacked account might be reviewer, but if all the rest are going to

2394:

The "confirmed" user-right is almost never given out to editors with accounts less than 96 hours old or who have less than 10 edits. If your account is well over 4 days old and you've had 10 or more non-deleted edits for at least the last day, there may be a technical reason why your account is not

1547:

Okay, thanks. Is there a specific place where I find out about possibly becoming a reviewer? I can be on Knowledge for an hour a day, maybe more on the weekend, if it's a certain amount of time needed. I've been editing mostly golf-related pages for nearly two years. Once in a great while, I find an

1512:

Thank for your response. Well, apparently I was thinking of the actual being a reviewer (now that I know the difference). Occasionally, I see when certain articles (such as the Mike Tyson page) are pending review on edits waiting, and I had wondered about that. Is there a specific qualification that

5377:

Since counter-vandalism is what rollback is (primarily) intended for, it makes sense that it's the borderline prerequisite for the semi-automated tools. So long as rollback is the key to powerful software like Huggle and STiki, I think we need to be careful who we grant the right to. There's plenty

5317:

I assume that if rollback were eliminated, one would gain access to those tools via a request on wherever you make special requests now. This would create more work, potentially balancing out the reduction in work created by eliminating the rollback request page, though there would be some overlap

5197:

Possibly not worth worrying about, but rollback links--unlike Twinkle links--show up on the history and recent changes, which makes it easier to revert edits that are obviously revert worthy without checking the diff (e.g. if it's an obvious malicious blanking as per the size change and summary, or

5009:

request that you can't action; like the others above say, only NAC SNOW here, only place you certainly can help is reviewing AWB requests, if they are under the threshold and didn't specify a special reason the requester should be asked for a a reason--if they ignore it for say a week it can be NAC

4446:

I wasn't suggesting a formal "30 days and closed by uninvolved" RfC, just wondering if there should be a short note on AN to see if anyone else has any feedback on whether or not it should be continued to be archived by KpBot in the current format splitting the approved from declined (which I think

3469:

new users that I notice in my watchlist, I usually leave a (low-level or welcome-variant) UW template, after which I see the red exclamation mark beside the entry. Is this type of ‘maintenance’ activity, along with non-article page creations in Help:, File: &c., generally worth auto-patrolling?—

3327:

I haven't been active here forth elast several months, but have been poking my head back in a bit recently. What i am seeing is a lot of users who request rollback or reviewer (or both), get told no because they are inexperienced, then go on an editing frenzy in a rather transparent attempt to rack

3165:

user rights as such users are able to override blocks and can do considerable damage in a very short period of time. (the dreaded "rogue admin" scenario) A "rank and file" user who is blocked can't do that, they can't use any of their permissions outside of their own talk page. Summarrily removing

2423:

The rollback right is a "convenience right." It makes it slightly easier for you to undo all of the most-recent editor's edits in a single click instead of using multiple steps. Please do not ask for this user-right unless the last few months of your edit history shows that you generally use good

1344:

I would like to create a page for my father Murv Jacob!! He is a well knoown artist and writer. How do I create a page for him Can I have my account confirmed so I can create the page? I was going to work on it for him this weekend but this four day rule kinda messes up my plans. Thanks you ~ Holly

696:

I think the first question we need to answer is: whether the existence of a process whereby a non-confirmed editor can request the action be performed by someone else is sufficient grounds to reject requests for confirmed. So, I want to upload a file, I'm not confirmed; I can request confirmed, and

5278:

of this? Is it a high priority for our volunteer programmers who have badly functioning tools on Labs to fix? Frankly I never really understood the difference between Twinkle's rollback and the user right Rollback - which leads me once more to think thst it's only of interest to the hat collectors

5163:

I think getting rid of it as a separate user right probably makes a lot of sense. It could instead be an optional gadget like twinkle. I know it is a prerequisite for some anti-vandal tools, but frankly I don't really think it should be the job of admins at PERM to act as the gatekeepers for those

4800:

I kind of like that idea, but not the immediate part. Just today I ran across what I feel to be a poorly reasoned decline of a request, and have asked the declining admin to reconsider and/or provide more solid reasoning for their decline. If the request has been bot-archived the as soon as it was

3437:

Having jumped in on the last two Rollback requests and denying them, I think as Beeblebrox said, we can look at the clues given to us to see if they 1) truly have a need for the tools 2) are interested in the work 3) are competent enough to do the work. When I looked through those reuqests, I took

3360:

The problem is there is no really good way to deal with the problem. Whats the difference between the editor who responds by patrolling recent changes 5 hours a day for 4 days, racking up 1-2k edits, and the other editor who spends 2 hours a week, and comes back in 10 weeks with the same number of

3205:

First of all, I'm going to go out on a limb here and guess that this concern with the stats is not something the vast majority of users are worried about. As for the awesome power of rollback, anyone can have that without needing to ask permission by simply turning on Twinkle, and they still can't

2455:

I support the proposal for Confirmed and Rollback, but oppose it as worded for Autopatrolled. The proposed wording is too article focused and per other relatively recent discussions, this is inappropriate. ALL new pages show up in the NPP queue, even templates, modules, and wikiproject pages. As

2413:. Having your newly-created articles on a list for new-page patrolled is generally a good thing. Please do not to ask for this right unless you are frequently creating new articles (not redirects) AND your most recent few dozen articles have not required cleanup by others after your initial edits. 701:

and request someone else do it. On the one hand, requiring FFU is not entirely consistent with the pillar, but on the other, it will avoid the upload of many files that would either be copyright violations, or should be at commons instead. Is requesting a semi-protected edit as good as getting the

275:

please be more specific about what needs to be changed. Are you requesting to have an edit made to this article for you or are you inquiring if it is okay to use the material on this page for your own publication? If it is the first, please respond with a clear change x to y or please add this to

3422:

After some thought about this I wonder if the problem isn't in our replies to these type of requests. I'm primarily concerned with Rollback and Reviewer. Both of these are tools for keeping vandalism out of articles. Instead of just saying "not enough edits" should we not be telling applicants to

3406:

I do agree that the percentage of bad-faith requests is vanishingly low. That's not really what I'm getting at, it's users who rack up edits, any edits, in the hope that if their numbers are better they will just be granted the right automatically. This is often an issue with very young users who

2701:

hmm, I stumbled on this when I saw the change to user:OrangeMarlin. The way he was hounded off of wp was a disgrace. His response to the admin indef given him 12 Dec 2011 to offset the two other parties' arbcomm-directed blocks was to retire. He hasn't been back except to clean out his talk page.

4520:

Let's not make a big fuss about this proposal because all that will be achieved by inviting a broader community will be no consensus at all. The issue only really concerns the admins who patrol the PERM requests and who accord or decline them, and any bots that do the archiving. There is quite a

3243:. There is nothing preventing an administrator from stripping user rights at the time of a block, for the purpose of avoiding skewed statistics for such rights. This would be appropriate for blocked accounts that would never have any chance of being unblocked (established sockpuppets and obvious 2969:

in otherwise good standing. These editors can return at anytime and I see no point in giving admins (and the inactive users when they return) extra work for no reason; as Nikkimaria said above, template editor and account creator have time limits for inactivity, anyway, so they're not a problem.

520:

Looking at the archive history, it appears that the page to request Confirmed permission can safely be removed. 99.9% of the requests are denied. Those few that are granted, are granted for experienced editors (e.g. public doppelganger account) who know how to contact an administrator to make a

1399:

you all do this. Do you just do the easier ones first then the harder ones later? I was skipped over twice, so I just think it would be helpful if we could add this to the page on the subject (possibly). Thanks for taking the time. I don't want to seem like I am impatient or anything; I'm just

4758:

notation here is just a formality so others know not to review the request and the bot knows to archive it. There is not, and should not be any such protocol for declined requests. If we leave everything up for a week the page could get quite crowded at times, if the bot could remove accepted

664:

be granted, and anyone with a legitimate alternative account should contact an administrator, the same way people already do for rollback. Instructions on uploading images should also be included, as well as a recommendation that new users should work on draft articles in their sandbox, or at

599:

What about people who want to create books? They need confirmed status as well, and they're usually new enough that they won't know to go to an admins page. We're better off with a centralized place that at least follows certain protocol (i.e. the aforementioned legitimate alternate account

4822:

What if it was immediate with a 7 day rolling archive like RFPP has? Then admins that want to follow the feed can but it won't break the dashboard for others. As for the concerns of biteyness with new user's requesting confirmed, part of the process of archiving those requests could be to

2795:

Those two userrights, like sysop, already have provisions for removal for inactivity. However, I see no convincing reason why this should apply to other userrights with far less potential for disruption. After all, we do want to encourage experienced / previously active editors to return.

3295:- If an account is indefinitely blocked, is likely never going to be used, then there is no reason as to why the userights should be left as is. Blocking someone just takes a few seconds and so does this thing. Any user or admin can find blocked users who currently hold userrights at 3010:

Hmm... well first of all, I do think this is process for the sake of process, which is not a good precedent and has done us harm in the past. But then again, not having specific guidelines spelled out in policy has also caused us some damage, with people more or less going by their

5358:

I forgot about the need of the Rollback right to access Huggle. My bad. Perhapd deprecate the Twinkle version of Rollback? (although I'm not saying I come across a lot of misuse of either tool. I've probably never stripped more than three or four users of their Rollback flag).

3798:

There are all sorts of out-of-process ways one could request this (e.g. to a WMF staff user, a system admin, etc), but steward requests is the standard process; this section may need some updating--but anyone with those advanced permissions knows how to deal with them already. —

3820:

I noticed that the "reviewer" user right is now the "pending changes reviewer" right. What other reviewer rights are there besides that, for the reviewer right to need to be distinguished? I'm just wondering about this; I am not looking to seek these "other reviewer rights".

2759:

for the removal of any advanced userright of an editor that has been inactive for more than a year. These accounts are more likely to be unnoticed if hacked and may pose a threat to the wiki if the rights granted are misused. This is especially true for userrights such as

604:

requires its holder to pop by and post confirming that it's theirs). RFPC also gives us the opportunity to educate selectively and in a targetted manner - if a user drops by to ask for confirmed to upload an image, the responder is SUPPOSED to go by their page and drop a

142:

I would appreciate help in getting my page published. I am new to this system and unsure of what I'm doing. Please assist. I think there is public interest in the page going public. Not sure how to upload a photograph to go with it. Please advise. Kathryn L. Smithen

4571:

KingpinBot was on Christmas holiday, sorry. Running again now. As far as problems with if the bot does die for good, I can always be contacted via email and make the source code available to someone else to run it (clearly I'm not particularly active myself these days).

2333:

it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format. Please note that the account creator permission will not be given to new users; it is only given to those editors who meet certain criteria as detailed at

1627:

There's no separate right for new page patrol, though I think it was proposed at some stage. I think you just read the instructions there carefully, and away you go. You might like to ask an experienced patroller to check your work after you've done a hundred or so.

3247:

accounts). Even if there was a community consensus that inactive blocked accounts be stripped of rights, this is a task that can easily be performed by a bot if anyone cares to write one. No need to burden administrators further with unnecessary pointless work.

4896:. Be careful with declining requests for autoconfirmed, I've seen IAR (I am one) invoked to grant that right for people who have created hundreds or thousands of non-article pages (templates, help pages, wikiproject pages, etc). I hope this answer helps. :) — 4407:(the maintainer) to tweak stuffs... It's going to require me to to some tweaking to make it so that OCA is usable as well for the same reason unless it is decided to do away with the whole separate categorized archives method... Should this be posted on 5379: 2579:

this change as nominator, cleanup is easy to do and re-adding such permissions are easy should the need arise. In general, users that have been blocked in excess of a year have either retired or have been blocked for being disruptive to the project. —

5387:

like the system of pinging admins who have recently declined requests from a new requester. They may be able to offer insight into how the user's competence has improved. It would be nice if we had a bot that automatically did this, though! —

2371:

The number of obviously-reject-able requests for "Confirmed," "Autopatrolled," and "Rollback," could be greatly reduced by putting a small paragraph at the top reminding editors of who will and won't be given these rights. Here is a draft:

5126:

After considering a request many times, I find the TW more easy since pressing UNDO usually fails from an edit conflict. The difference of course is the twinkle and the permission allows it on one click. You just have to be more careful.

3015:

rules in the absence of specific regulations. The removal of advanced permissions from indefinitely blocked accounts should probably be based more on the activities of the user in question; for example, if they were blocked for persistent

3126:, exactly sixteen months before I became an admin. In that sixteen months, I only ever used the reviewer right once, and nobody complained about non-use; indeed, in the first three years of me having that right, I used it a total of 1660:

If that error message (and I don't know what it is) can be modified to include all the ways an image can be contributed, similar to the big box at the top of the project page here, or similar to the standard boilerplate response

914:

No semi-protected edit has been requested here, You have made 2 edits today since your account was made today, and that is not enough to grant the reviewer right. This is not the right place to ask for the permission either.

1459:

Hello, I was wondering what all is involved in being a reviewer and what qualifications one needs? I've noticed in the past, when I would make a golf article, it would be reviewed by someone, but I never knew what that meant.

3184:

have rights pulled, then reviewer should too for consistency's sake if not because it is skewing the core stats generation for the number of people with the userright that can actively help someone else without that right. —

2653:

I have the same question as HJ Mitchell. Is there any harm a blocked user can do if the permissions are left? I don't know of any, and there's no need to create yet another admin backlog unless there's a benefit to doing it.

1421:

I would say yes, the "easier" requests do often get answered more quickly and I admit that I have done this myself; that being said, the easier requests receive no less scrutiny. In the meantime, I've fulfilled your request.

901:

I have been editing now for 3 Months. I am requesting to be a reviewer because I am really enjoying being an editor. I can see myself doing this for a while and have a great understanding of what is needed to do the job.

4665:. Feel free to up the number. As far as the reliance on bots goes, it's not a problem with the bot or bots in general so much as this operator in this case. This kind of task is a complete waste of time to do manually. - 654:

My point is that this confirmation request page is a waste of time. It wastes the user's time with requests that are almost 100% guaranteed to be denied, and it wastes administrators time because ~0% of the requests are

2395:

auto-confirmed or that it is auto-confirmed one day but not the next. You you may ask for the confirmed user-right. You may also ask if you can demonstrate experience on another Wikimedia project and you can state a

1562:

To be honest, if you edit constructively for six months and don't get involved in any drama, it's possible an admin will come to you an ask you if you want it. Otherwise, at that time, you can just post a request on

1726:

substitutes a canned reason from some other source, which hopefully isn't hard-coded in the software. Even if it is, the 'reason' substitution could still be changed, with a request to the maintainers of the source.

2554:

I propose that a process for removing permissions for indefinite blocked users that are no longer active with the project (greater than a year without any logged activity) be implemented, similar to the process at

5214:

Twinkle links show up on History and I never use RC because that feed is useless here so can't say for sure there. Twinkle is compliant with the upcoming changes, and as long as you're not using any of the other

3776:

That's not what I mean: what I mean is that it could also be listed for people with the founder right to remove breaucrat access NOT a RFP for founder right. Thanks for your understanding. 09:15, 7 October 2014

3569:

I added some collapsed sections pending archival, not sure if the page is just very busy right now and/or if the archive bot has stalled. Please feel free to remove once the page gets back to a normal size. —

3900:. I agree, maybe the "pending changes reviewer" label isn't as correct, either, because one can technically "review" - meaning "examine" in this sense - the change, without being a pending changes reviewer.) 3220:

an issue. This is a non-problem that does not require a solution. Run-of-the-mill user rights should only be removed if they have been abused, not as a punitive measure when blocking for something unrelated.

3854:

There are no other "reviewer rights". The problem was ambiguity. There are something like four (or more) unrelated processes on Knowledge, all termed "reviewing", and some people who wished to work in, say,

4526:

Are we 100% certain that users who receive the additional group to their rights are given a notification through the system. AFAIK, the recommendation is that they check back at PERM (or check their rights

1882: 4065:, could all of the pending requests be cleared from the page? Apparently, this page is no longer valid, so requests should not be posted there. If the requests are removed, the page should appear as this: 2665:

I'm not suggesting that the work would be required, just that it would be allowed. As with all administrative tasks, mopping can be done anywhere, "you should mop over here instead" is not a directive. —

5473:

I would like to change the photograph currently showing on wikipedia on my page information for Diana Binks. Please confirm how i can do this by email to binksdb@outlook.com Many thanks . Diana Binks

3103:

None. There are 6,850 rollbackers and 8,001 reviewers, so a margin of 20-odd doesn't make much difference. I'd wager there are easily 200-odd who make insufficient use of the tools for T13's tastes.

2599:

Prior to bringing this up, I did remove some rights that appeared to be unused--I got a talk note about it today and reverted my last change and brought it here to see what the consensus is. —

5709:

Dear Wiki Editor, I am kulamani, a computer engineering student from NIT Allahabad University, India. Want to write technical article in wiki users. Please allow me user permission. Thank you.

4269: 2619:

inactive user, not just indef blocked, please feel free to discuss below. Same rational that it would be very swift to restore if they return and still require; exceptions for (WMF) staff. —

644:

If you want to create a book, by the time you're done editing that book in your sandbox, you will have more than enough edits and time elapsed to be autoconfirmed. That is not a good argument.

674:

Another alternative is to draft an army of entrusted users to monitor pages like this, and empower them to deny requests. We've experimented with this, with some success, on admin pages like

4878:, I wouldn't recommend NACing requests for confirmed or other permissions unless they are clearly SNOW. Examples might include a person who has never touched a template or module requested 4783:. I'd rather see them archived immediately when resolved and then have the archiver post a message on the requester's talk page giving them the result and a link to the archived result. — 4534:

receive the additional group to their rights are given a notification through the system. AFAIK, the recommendation is that they check back at PERM (admins are not obliged to inform them).

2873:) and has never been used or used once or twice shortly after receiving the flag, that it is allowed to be removed at the discretion of the navigator. this is a major pet-peeve at RfA, " 5108:. If "real" rollback is ever changed to not bypass things like the spamblacklist, I'd support removing the rollbacker group and giving the right to autoconfirmed (or maybe even user). 649:

Most users who have made any contribution at all will get a welcome message anyway, so that isn't a good argument either. I've seen welcome messages appear before users make any edits.

3296: 977: 5073:

I don't know that any formal policy changes are needed here or anything, but I'd like to discuss the matter with PERM regulars and anyone else with an interest in rollback requests.

3343:

I have seen this also. There are a few users who just come in every few days to request especially rollback and reviewer. I used to be like this. I have grown out of it though.

4773:

The problem I have with leaving these requests around longer is that they are already left around too long as it is which has constantly caused page size transclusion errors with

5070:

a user with rollback can damage that a user without it couldn't, and we implicitly grant it to every single registered account by having twinkle available to them from day one.

4550:

who has been doing it for years. Note: we do not want to invite a plethora of other NAO/NAC to these pages from admin wannabes - the unnecessary 'clerking' is bad enough already.

3032:

probably wouldn't be a suitable flag for them. Those are generally taken away at the time of abuse, not long after the fact. On balance, I find myself in greater agreement with

847:

This page (WP:PERM/A) has backlog since 7 days apparently because of non-functionality of tools, however it is working now. It requires attention of some willing administrator.

4346:, I can't think of anything it would hurt by having the archiving systems overlap. Is there something you have in mind that could be a problem I'm not thinking of? Thanks. — 3751:

Seeing as only one user (two users?) can possibly have the founder right, I don't think it makes sense to list it at requests for permissions. We didn't even give the right to

5287:

for years who actualy did a good job of it as de facto PERM clerk. He also fixed a lot of other stuff on the fly too, such as malformed requests, vandalism, and other junk. --

4003:

Hi. Looks like you may be a bit lost. This is the page for discussion of permissions requests. You need to post this to the talk page of the article you would like to change.

3299:. And in any case if an editor returns and is unblocked, the removed permissions can be restored on a case by case basis after evaluation by the reviewing admin. No big deal. 1653:

It occurs to me that this message might be why we get so many requests for confirmation from people who cannot upload images: because they are being told that confirmation is

4403:, I now understand what you are saying. KingpinBot archives them based on status (approved or not approved) and cluebot wouldn't do that, at least not without some help from 1830:

I want to insert Mr. Neville Tuli's officially verified image onto his page. Also, reference no. 8 and 12 should have text but they are not appearing correctly on the page.

5040:

I think some of us may be taking request for rollback a bit too seriously. I think we should be aware of the reality of the situation when reviewing these request, to wit:

5688: 5452: 3967: 3614: 2290: 2010: 1922: 1809: 1323: 1173: 97: 3040:; advanced permissions are irrelevant when the account is blocked, and an editor's status within the community is not determined by the flags bestowed on their account. 89: 84: 72: 67: 59: 4721:? I don't see why it would be an issue with running it on labs, but I can certainly check for you. I'll note that it doesn't have to be on labs for me to restart it ( 3407:

don't get that this is not supposed to work like a video game, where points are all that matters. If it were that simple we could have a bot handle all these requests.

2079: 521:

request anyway, or who could easily wait the required 4 days. Even if I created such a legitimate account for myself, it does me no harm to confirm it the usual way.

4236: 2565:

Such removal would be procedural, and would not prevent the user from requesting permissions again should they even become unblocked and return to the project.

2217: 5732: 5403: 4231:'s ability to archive discussions that are already closed (I'll not that it is used on this very talk page). Another benefit of this is that it would allow 3868: 2634:

Does it really matter? If they're blocked, they can't use the permissions anyway. We have enough real work to be doing without making more unnecessary work.

200:

Unfortunately this is not the venue for requesting page edits or page creations. I will shortly providing you with some help on your talk page.

5165: 4038: 3864: 2548: 2148: 4935:

and for that reason almost all requests to be confirmed early are denied, it is pretty much only done in cases of verified legitimate alternate accounts.

3926:

Was on a break when this change was made, but I for one think it is a good move as it should help eliminate newbie confusion about exactly what this is.

4581: 1723: 1687: 5283:

wrong with the archiving? Except perhaps that the declined request were archived too soon. Do we even need a bot at all to do the archiving? We had a

2702:

This smacks of slamming the door "and stay out", rather than anything that would welcome him back should he choose to forgive the abuse he received.

4827:

for Account Creation (since the bot that is suppose to do the welcoming for that project has been down longer than I've been a member). Thoughts? —

3267:, solution in search of a problem. Though if an admin wants to unilaterally remove permissions from a banned user, they should be free to do so. -- 449: 3836:

That is it, the group was recently renamed to make it clear what it was about, perhaps "pending changes acceptor" would have been more accurate. —

4808:

Somewhere in between "a week" and "immediately" lies a middle ground that will keep the page from being cluttered but alow some time for review.

4521:

small group of admins who work here and they do so fairly regularly. Whatever solutions the bot handlers reach, what we need to bear in mind are :

4239:)) to be used for on the fly archiving when the dashboards are hitting page size limits for a quick fix. Thanks for any consideration on this. — 1484: 502: 47: 17: 4464:

Oh sure, an in-link from AN to this thread would be good to get some more eyes on this-I would like to hear from Kingpin too (already pinged) —

4824: 2353: 5576:

Oversight and Checkuser should also include identification. Yes it's on the pages focusing on them but it wouldn't hurt to mention it here.

5059:

better rollback function and all you have to do to access it is turn it on in your preferences literally the second you register an account

4580:

As far as the problem of having to look in multiple places for an archived discussion if you don't know the result, I made a search box at

3503:

but by default that page only lists those in article space. To see all pages, go to the "Namespace" drop-down and select "all", then click

3281: 253: 5082: 4981:

Oh, and apparently I was an IAR for a request for Confirmed as well (take a look), so extreme caution should be used there as well. :) —

3547: 1594:, which has little or nothing to do with either Articles for Creation nor the reviewer user right. It's a regular source of confusion. -- 4540:

IMO, requests not yet handled by an admin should ideally be left permanently open until adressed. Exception: if NACd as 'not done' by a

3092:

OK, that makes more sense. Nevertheless, I'm still not sure what inconvenience this would cause in Knowledge's day-to-day functionings.

1277:– Anonymous editors cannot be granted additional privileges. Although not formally needed to edit Knowledge, there are many benefits to 1285:

Feel free to change the wording, but I found it succinct, and includes some of the "custom" replies that IP's have been given recently

5506: 4147: 3989: 3872: 3694: 3486: 1373: 1215: 790: 486: 179: 4537:

I think it appropriate to archive all admin decisions after seven (7) days in order to give 'weekend Wikipedians' a chance to log in.

5216: 1431:

Okay, I guess that makes sense. If I were in your position, I bet I would do the same thing. Thanks for giving me a hasty response!

1038: 994: 625:...and so on. This allows us (hopefully) to nip certain unwelcome behaviours in the bud, and start a new editor on the right path. 4601:

where is KpBot located? If it's on toollabs or someplace I can access, I would be happy to push the restart button when needed.

3660:

Please note that, as stated above "This is not the place to request a user permission", so you are possibly in the wrong place -

3546:

are still happening. I would update the links myself but I am not sure of all of the things that need to be moved (e.g. if seems

1747: 277: 1650:

Someone recently posted a confirmation request, saying "When I try to upload an image, I'm told I have not been autoconfirmed."

456: 4232: 4210: 1709: 583: 527:

I suggest that we replace this page with a notification to all users that confirmation requires 10 edits and 4 days, period. ~

5248:

After discussing this on IRC we've concluded that, no, there are no links on the page created by appending the query string

4931:

T13, I think you are confusing autoconfirmed with autopatrolled. One onmy needs 10 edits with a 4 day old account to become

2810:

I suspect that getting past the part about having a non-expiring block would be the hurdle to returning, not these flags. —

1669:

that we slap onto all such requests, then maybe the number of requests received on this page would decrease significantly. ~

5668: