NAC - people with the right decline their respective PERM?
Latest comment: 12 years ago13 comments9 people in discussion
Since users with the specified right obviously know what it takes to get it, maybe we could allow people with the specified right to close their respective PERM (eg rollbackers non-admin closing rollback requests, file movers closing file mover requests etc)? CyanGardevoir (used EDIT!)07:06, 17 July 2012 (UTC)
What does the right do? (Or better saying what does the not-right prevent you from doing NACs?) a new user right for handling 'user rights? Sounds a bit wired... mabdul09:52, 17 July 2012 (UTC)
I agree, but you should only be allowed to close the requests that are outlined in the proposal above, and you may only do so by a new user who WP: DTTR doesn't apply to. Electriccatfish2 (talk) 12:22, 17 July 2012 (UTC)
I don't know. People who are given specific userrights are given those rights based on their ability to use the right properly (to know when rollback should be used, to be trusted to create new articles, etc). At the moment, the ability of a user to determine whether someone else would be able to use the right is not taken into account (which is a different skill to being able to use the right oneself, and requires someone to be a good judge of character). I'm not sure it is necessarily the case that people with a right will always know whether someone else should have it. Additionally, I worry that this would make getting some rights much more difficult, as admins granting the right would have to judge whether the person would be able to close requests well, in addition to using their own right. If we take autopatrolled as an example, there are many users who create tens of thousands of acceptable articles who are not necessarily the best people to determine who else should/should not be autopatrolled. This would mean that some people don't get the right, even though they'd be able to use it well (with autopatrolled, this could back up the new pages feed for NPPers, which is unhelpful. Also, NACs would only work for declines (unless you plan to allow people to grant rights as well, which presents even more problems). So, while I understand where you're coming from, I don't think it would be very helpful. ItsZippy(talk • contributions)14:28, 17 July 2012 (UTC)
I concur with ItsZippy above. It is better to just leave the final done/not done with the administrator. I have unfortunately seen too many requests by users that have a particular right overruled because they failed to take other issues into consideration. I have seen an example of stating not enough reverts performed for an editor; however, the editor in question does them manually and gives a more detailed edit summary than the simple twinkle default. I have seen core content contributors declined as not being vandal fighters, even through they state they only want it for the very occasional vandalism they come across when editing the article space, and have otherwise shown to be responsible in their judgement. The only way to stop biting from those who mean well, but occasionally get it is wrong, is by vetting who performs these. For now that is at RFA. CalmerWaters01:44, 7 August 2012 (UTC)
I agree with both of you. You shouldn't be declining if you can't accept. This is different at WP: PERM/C where many of the requests don't require an administrator's attention. If you would like to comment on a request, you may use the (Non-administrator comment) template. ElectricCatfish23:29, 7 August 2012 (UTC)
I don't see any need for any closures or generally even commenting from non-admins. It's not as if there is a ever a backlog on these pages. Kudpung กุดผึ้ง (talk) 09:17, 10 August 2012 (UTC)
Kudpung, although I agree with reducing the NAC'S, I really can't see an issue with NAOS. Non-admins are encouraged to point anything out to admins, I know the admin will also check, but if something pops up that causes an issue for them and they think it will cause an issue for the right to be granted, let them speak because Wikipedia is a community, non admins are free to comment.--Chip12345608:16, 14 August 2012 (UTC)
My stance on participation in all things 'semi admin' - especially by inexperienced users - may not be shared by everyone, but many admins and highly experienced users appear to concur with it. Over-bureaucratisation and maturity issues are the reasons why one unofficial project has caused eyebrows to be raised. I'll recap:
There are never any backlogs
WP:PERM is not a mini RfA.
Admins run checks by using tools that non-admins do not have access to, so NAC generally don't help.
Clerking, where officially required, has been established by major community discussion and consensus.
Being technically 'allowed' is not to be interpreted as 'encouragement' nor strictly even an invitation.
New users may get it wrong (and occasionally do).
Users with the specified right (see thread header) obviously know what it takes to get it, maybe we could allow people with the specified right to close their respective PERM. Admins can do this on PERM, but nowhere else are such decisions for rights made unilaterally.
New users may BITE other users (and occasionally do).
And the question to which I have been seeking an answer for years is: why are such semi-admin areas, including for example NPP, RfA, and AfD such a magnet to new users.
See also: WP:HATSHOP - 'clerking' is another 'Tell-tale sign that admins look for'
I'm pretty strongly opposed to any clerks on the RFPERM pages. We'd just get a large number of people who don't know what is going on accepting or denying requests and then getting overruled by an admin. I've also seen cases where one user, after being denied autopatrolled, went on to deny it for several others in what was clearly just revenge editing. Reaper Eternal (talk) 18:59, 15 August 2012 (UTC)
First of all, the title "clerk" is not considered to be a high-level position, nor a position of authority in the real world. I think that the only PERM venue that could use non-admin involvement is Confirmed. Many of the requests don't need an administrator's attention. I've been helping out at confirmed only for a few months now. You use standardized templates that either ask a question or close the request by directing the user to use an ESP template, going to FUU, or Commons. I've seen many non-admins closing requests incorrectly, often biting the requester while doing so. I think that the only area non-admins should be allowed to participate in at PERM is confirmed. Admins have the other PERM venues well-covered and except for blatant trolls and blocked users, there is no real need for NAC's at other PERM venues. I think that if admins do decide to appoint clerks for PERM, it should only be at confirmed. Clerks should have some experience here and should have a history free of biting newcomers. ElectricCatfish14:25, 22 August 2012 (UTC)
Latest comment: 12 years ago1 comment1 person in discussion
Hi, I requested AP rights almost 6 days ago. I don't have a problem waiting, I was just wondering why all the newer requests are being reviewed before mine? Thanks, TRLIJC19 (talk • contribs)15:25, 26 August 2012 (UTC)
Anyone going to complete the requests for Autopatrolled?
Latest comment: 12 years ago6 comments5 people in discussion
And again, can we have less superfluous clerking? I don't know about other admins, but I don't take a blind bit of notice of NAO comments - I do my own research. Applicants need to understand that there is absolutely no urgency whatsoever for these rights, even if there is a minor backlog.Kudpung กุดผึ้ง (talk) 02:20, 26 August 2012 (UTC)
I tend to agree with you. The amount of "clerking" that has been going on here is starting to become ridiculous. Unless there is some highly important and inconspicuous reason why a user should not receive the rights, I tend to find all the {{nao}}'s to be unhelpful. Maybe I'm assuming bad faith, but this looks like an attempt to forcibly inject clerking into the RFPERM process and to buff up one's "resumé" for future RFAs. Furthermore, receiving several "(Non-administrator comment) I don't think you are ready yet" messages followed by a Not done is a bit of a pile-on and probably disheartening for the user. In addition to this, when the closing admin goes against the (Non-administrator comment)'s, the process looks bizarre. Reaper Eternal (talk) 12:53, 26 August 2012 (UTC)
I agree with Kudpung and Reaper Eternal here, I mean we have users making non-admin closures in the very same section where their own request still stands, this is ridiculous and way out of hand. The comments have become un-helpful, and it seems that the only reason a {{nao}} is made is to have the users signature posted to the page. I have purposely cut my activity to a minimum because WP:PERM has become a joke. We have three or four request right now that have two users stating the very same thing. I have an idea, if you really want to make constructive comments at WP:PERM then post your own RfA then you can make all the closures you like. Mlpearc (powwow) 15:37, 26 August 2012 (UTC)
Latest comment: 12 years ago5 comments5 people in discussion
- in the right hands. Most automated processes at Wikipedia need a clear demonstration of skill and competency before they can be used, and the acquisition of user rights specific to the task is also generally required. Although Stiki does not currently need a user right, its developer has recommended a minimum experience of 1,000 mainsapce edits and/or Rollbacker rights. Let's help ensure that developer's recommendations are upheld and that the permission request page for Sticky is kept free of any over enthusiastic requests. Kudpung กุดผึ้ง (talk) 13:59, 28 August 2012 (UTC)
Speaking as the developer of STiki, I am personally aware of no abusive behavior since we implemented our current permissions system. Never have we had an intentionally malicious user. Have their been accidental reverts which were innocent (or more likely, good-faith damage)? Sure. However, I'd venture our human false-positive rate falls below that of CBNG. Everyone makes mistakes.
We have asked editor(s) to stop using STiki because their good-faith efforts did not demonstrate a thorough understanding of WP:VANDAL and WP:NOTVANDAL. We often caught these instances proactively via our new user checks (i.e., before the community brought them to our attention). Explicit permission is not handed out without follow-up. We've had a lot of these permission discussions recently, I don't want to re-hash to death. West.andrew.g (talk) 15:00, 28 August 2012 (UTC)
FWW, I am one of the people who occasionally pushed Andrew on the permissions issue before the current system came in. I am happy that the current system is working fine.
Like others, I'm really unsure as to why this has been brought up here at WT:PERM, as well as a couple of other areas. I really like Callans comments about non-admin comments being overlooked in places. Its the developers decision., they will look at your comments, but no matter if your an admin or not, they can overlook it. As far as I'm aware, there has been no STiki incidents, touch wood, so I really see no problem with granting the STiki bit to editors who don't meet the criteria, yet demonstrate a fair amount of knowledge in reveting.Chip12345609:33, 29 August 2012 (UTC)
Policy / process development area for non-admin assistance in RFP
Latest comment: 12 years ago13 comments4 people in discussion
Appropriate responses in RFP help to a) prevent WP:BITE situations, b) give editors the tools they need to help the project, and c) help ensure that there is consistency in application. In order to best create the processes, administrators who work (or have worked) in the RFP areas are asked to assist in policy/process development.
Once a process/policy is determined, non-admins will be able to "apply" where needed.
Clerking
Would formal clerks benefit the RFP areas you work in
if the work in the file namespace is not disputet (NFCC wrongly uploaded)
normal page moves are not disputet
AWB
Checking that the user has at least 500 mainspace edits.
Find yours
Latest comment: 12 years ago12 comments6 people in discussion
Find out what your permissions are. Go to Special:ListUsers and enter your name in the box after "Display users starting at:".
I thought it might be useful to provide a prominent link to allow users to figure out what rights they have. This sidebox is what I came up with. Does anyone know of a more elegant way to extract the information? WhatamIdoing (talk) 21:58, 7 September 2012 (UTC)
Code for linking directly to it, is: <includeonly>[[User:{{sub<noinclude></noinclude>st:REVISIONUSER}}|Your Userrights]]</includeonly> [struck per WhatamIdoing's point below, this only works if you're the last person to edit a page]
However, I'm not sure how to turn the link directly into output. (It must be possible, because wp:popups includes userrights info when hovering over a usernamelink.) —Quiddity (talk) 07:13, 8 September 2012 (UTC)
I believe this is it -- the portion that calls the user rights starts at: "// If on a user or user talk page, and not a subpage..." I'd take a look, but am turning in for the night -- will check it out tomorrow if no else already has. Theopolisme07:31, 8 September 2012 (UTC)
The REVISIONUSER ones I think only work if you're editing a page. I want something that lets people find out what they've got before they edit the page to make a request. WhatamIdoing (talk) 17:20, 8 September 2012 (UTC)
Much digging... See Bug:4196 for the technical details. Basically "WONTFIX" because it completely destroys page-caching (page has to be re-rendered for every single view). The magic word REVISIONUSER used to work like we wanted, due to a bug, which has since been fixed (see this thread for details/links).
Latest comment: 12 years ago11 comments7 people in discussion
As the question of user experience for this right is till very much under discussion - and as the implementation of PC may even be delayed until a consensus is reached, perhaps a moratorium on applications for reviewer rights would be in order. Otherwise, the preemptive requests are beginning to look like possible hat collecting. Thoughts from admins please? Kudpung กุดผึ้ง (talk) 02:54, 26 August 2012 (UTC)
Then let them ask for rollback. The point is that a current discussion on the implementation is implying, amongst other things, that reviewer rights might require a much higher level of cue than rollbacker. --Kudpung กุดผึ้ง (talk) 12:28, 26 August 2012 (UTC)
I am also not an admin, but that's not a problem. 'Let them ask for rollback' what if they don't venture into anti-vandalism, the whole point of rollback? If they want to help with AFT5 they need reviewer, so it will need to be granted. Also, we my as well hand out them now, instead of having loads of requests when it actually is launched. Hope that's helped :)--Chip12345615:19, 26 August 2012 (UTC)
There exists a pool of some 5,578 users with reviewer rights already. They would probably be grandfathered in. There is also the fact that most of them have two years more experience by now already. Kudpung กุดผึ้ง (talk) 16:07, 26 August 2012 (UTC)
Rollback is rollback, and reviewer is reviewer. We don't give out one set of tools merely because the requester has another tool package which has some tools which overlap.
It all comes down to whether the admin in question feels from doing due diligence that the requester may be trusted to be responsible with the requested tools (and associated responsibilities).
As for whether there is a "backlog", that's all a matter of perspective. There is no deadline on this, and shouldn't be. As granting of tools is at an admin's perogative, and we would like to presume that admins are checking contributions, etc. Or perhaps are waiting for answers to certain questions, then a request can take as long as it takes. Or perhaps no admin feels comfortable granting the tools to the individual.
If you want to add a section for "long standing requests" (longer than a week, let's say), which may be automatically archived after a month, I wouldn't oppose that, but only if it meant that the individual should wait a few months before asking again. Yes, it would be nice if every request received a clear "decline", but if no admin is willing to grant after a month, that sounds like a decline as well. - jc3717:53, 26 August 2012 (UTC)
We seem to have two quite different uses of the reviewer right - AFT5 reviewing, and pending changes. I wonder if it is worth separating these two - having an AFT5 reviewer permission, and a pending changes reviewer permission. Alternatively, remove AFT5 from reviewer and have it just for rollback (because the AFT5 use is mostly dealing with vandalism). I don't think we need to close requests; however, with the present set-up, we should reject request from people who could do the AFT5 stuff but not the pending changes stuff (I'd say the latter requires more trust). ItsZippy(talk • contributions)22:33, 28 August 2012 (UTC)
Well, there could perhaps add a new separate account for AFT5 hiding, which sounds like a decent idea. If you think about it, rollbacker is granted for antivandalism; AFT5's purpose of reviewer is for 'hiding feedback', often vandalism, sometimes email addresses and such; PC's purpose of reviewer is for vandalism, too, I believe. We probably can separate, but perhaps it might seem okay to have both included in one policy - both reviewers 'hide' or 'unaccept' revisions or feedback - quite similar, when you think about it.
For information only, and without prejudice to any discussions elsewhere regarding the forthcoming deployment of PC, here are the German Wikipedia requirements for Reviewer rights (Note that unlike some other Wikis, en.Wiki does not impose a voting right). See also the original German.:
Granting
The granting of the active or passive Reviewer status can be automatic or manual, users automatically become reviewers when certain conditions are met. In addition, any administrator may manually grant or withdraw the Reviewer right.
Automatic
1. Automatic granting of "Passive reviewer" status:
The passive reviewer right is granted automatically to users who meet the following criteria: [1]
The user has been registered for at least 30 days.
The user has made at least 150 mainspace edits , or at least 50 edits where the newly created, or a later version has been reviewed (includes file, template, and category namespaces). Deleted edits do not count. Edits the last two days will not be counted for this criterion.
At least 7 of the user's edits are each separated by a minimum time span of 3 days.
At least 8 different mainspace articles have been edited
At least 20 edits have used manual edit summaries. (automatically generated summaries do not count).
The user has never been blocked before.
These criteria will be checked after each edit until the conditions are met. Then the right is assigned automatically. Administrators can grant or withdraw the passive reviewer right manually.
2. Automatic assignment of status "Active reviewer"
Automatic issue of the active reviewer right, the following requirements are necessary:
The user has been registered for at least 60 days.
The user has made at least 300 mainspace edits, or at least 200 edits where the thus created, or a later version has been reviewed (includes file, template, and category namespaces). Deleted edits do not count. Edits the last two days will not be counted for this criterion.
The user has never been blocked before.
At least 15 of the user's edits are each separated by a minimum time span of 3 days.
5 edits in the article namespace under recent changes (changes in the last 30 days).
At least 12 different mainspace articles have been edited.
At least 30 edits have used manual edit summaries. (automatically generated summaries do not count).
Maximum of 3% of the user's edits were undone (by "rolling back" or "undo").
Manual
Manual granting of active and passive Reviewer right.
On the Wikipedia page: Pending changes / rights assignment, users can apply for active or passive Reviewer status.
As a guideline, not a rule, for the granting of the active reviewer status is the right to vote, except for the requirement "50 posts in the last 12 months," that is 60 days after registration, and 200 articles edits.
The passive reviewer right is usually also given to users with much less experience, provided their collaboration is in a clearly constructive manner.
Withdrawal
Any administrator can manually remove a user's Reviewer right.
Latest comment: 12 years ago1 comment1 person in discussion
Most useful for those who patrol RFP/C ... since one of the steps is to formally welcome anyone who requests Confirmed using a template that is appropriate to their interests/request, I have created one for those who want to upload images, etc. Right now it's located at User:Bwilkins/Welcome-image, but could possibly be moved into templatespace - comments/corrections are welcome. I've added it to my personal Twinkle config right now. (✉→BWilkins←✎) 15:30, 4 December 2012 (UTC)
Substituting?
Latest comment: 11 years ago2 comments1 person in discussion
Any specific reason why the rfp template needs to be substituted? The only effect substituting has is placing tons of code down, which only makes it even harder to see where the request is and where the user info is, in the code. So again, why does the rfp template need to be substituted for pages like Wikipedia:Requests for permissions/Confirmed? Michaelm55 (talk) 15:05, 21 December 2012 (UTC)
Latest comment: 11 years ago3 comments2 people in discussion
I'm wondering if there is a way I can get my rollback rights temporarily suspended. I've been traveling quite a lot recently, which means checking my watchlist on (often phone-sized) touchscreens. The risk of unwittingly hitting the rollback button suddenly seems unreasonably high (I seem to have done this earlier today, and it took a good while before I noticed). Homunculus (duihua) 01:52, 15 January 2013 (UTC)
That was fast. I did see the instructions on customizing my watchlist, but um....couldn't quite figure out how to do that. This is just as good. Thanks! Homunculus (duihua) 02:05, 15 January 2013 (UTC)
Templating the user
Latest comment: 11 years ago3 comments2 people in discussion
I suggest that admins actually press the very small text button on the rfp template to notify the user that they have granted him/her the right. FrankDev (talk) 04:37, 15 January 2013 (UTC)
Copy-edit issue
Latest comment: 11 years ago2 comments2 people in discussion
So I gathered up the nerve to ask for a level of permission and went to post the request. As I was reading something raised an eyebrow pertaining to the instructions.
Do not fill in the section heading.
I would like to see this written as follows;
Do not fill in the Subject/headline.
Although intermediate to advanced editors will most likely be the only ones filling this request out, it's near remiss to not mention;
3.Remember to sign your post.
The reason for this is because there is a semblance of automation already inferred by the statement
Do not fill in the section heading. Geremy Hebert (talk | contribs)19:16, 24 February 2013 (UTC)
Latest comment: 11 years ago1 comment1 person in discussion
Hello everyone, I'm DeltaQuad (also known as DQ), an account creation interface administrator and developer. Recently, our project has had an increased backlog in getting accounts for new users. Our numbers are currently above 250 people waiting for accounts on the English Wikipedia. If you could even spare a moment to do a few requests a day to help us clear this backlog. If this interests you and your willing to help, and you match the following description, then please do apply! Ideal users are:
We have a very friendly team to help you get started and we also have an IRC channel. If you have any questions for us or about the process, feel free to ask at the talkpage. If you can help out, we would greatly appreciate it. For the ACC Administration and Development Team, -- DQ(ʞlɐʇ)23:20, 18 March 2013 (UTC)
Something a bit odd at "confirmed" subpage
Latest comment: 11 years ago2 comments2 people in discussion
Three consecutive requests by users making their first edits, citing past work on Wikipedia. Obviously they could've all just forgotten their passwords and created new accounts, so no reason to suspect them individually... but the timing strikes me as a tad anomalous. Anyone think we should be concerned? — PinkAmpers&(Je vous invite à me parler)20:28, 3 May 2013 (UTC)
Latest comment: 11 years ago56 comments31 people in discussion
Per a request at WP:ANRFC, this RfC is closed with the consensus in favor of proposal 2 There was wide agreement that users performing these actions be active account creators. -Nathan Johnson (talk) 16:11, 26 June 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hello everyone, it's been bugging me for the past while that people have been using the Account creator flag for other purposes, such as pagenotices and overriding the blacklist. It was originally intended to just be for account creators, but now it's essentially an unbundling of the admin abilities of noratelimit (ability to edit like a bot - needed for Account creators to override the 6 accounts per day limit), tboverride (allowing page notices to be changed and blacklists to be overridden - needed to override blacklisted usernames when appropriate), and give them override-antispoof (which is for overriding similar account names, etc. - directly needed for Account creation work). We give admins the ability to do these because we trust them. So what makes us trust people who are getting these flags for non-account creation reasons over normal members of the community?
I originally thought, like with a few other admins that I've talked to, that this was only for account creation purposes. I would like to know where the community stands on this, so that the proper use is reflected in policy, and the community knows how these permissions are being used.
Proposal 1: Active account creators (both ACCers and people at educational institutions creating multiple accounts) are allowed to carry this flag while they are performing their duties, and not use them for other purposes such as edit notices, overriding the rate limit, and title blacklist overriding.
Proposal 2: Active account creators (both ACCers and people at educational institutions creating multiple accounts) are allowed to carry this flag while they are performing their duties, and are allowed to use them for other purposes such as edit notices, overriding the rate limit, and title blacklist overriding.
Proposal 3: Anyone who an admin at WP:PERM feels is ready are allowed to carry this flag to perform edit notice changes, overriding the rate limit, and title blacklist overriding. (Obviously Account creators/ACCers are allowed to use the flag freely also)
While it's well known now that Account Creators have the technical ability to make these kinds of edits, the fact remains that they are not what the users signed up to do when the became ACCs, and it's not what they were vetted for. Sven ManguardWha?17:37, 22 April 2013 (UTC)
Support: I don't see any problem with using this to perform other minor things like editing edit notices and whatnot if they are active account creators and not abusing the privilege. Technical 13 (talk) 01:46, 22 April 2013 (UTC)
Support: There has been several times where I have used the AC right to fulfill ignored protected edit requests. -- Cheers,Riley03:15, 22 April 2013 (UTC)
While I recognize the partly-sensitive aspects of editing page notices and blacklist overriding, my reaction is mostly pragmatic: are non-admin Account Creators abusing these tools? And conversely: are they using them to help Wikipedia? I don't like the idea of creating more rules, that prevent people from solving problems, from an abstract notion that non-admins are less trustworthy than admins. A better reason to implement it would be because non-admin Account Creators are actually abusing the tools, and in that case I'd probably support Proposal 1. But without that I don't want to see the red tape. NTox · talk03:39, 22 April 2013 (UTC)
Support - There's been times I've had to ask an ACC to make a minor editnotice change. I mean, they have to identify to get ACC anyway, and we have to trust them (rather the tool admins) to not abuse things, so why not just trust them to do something that it's basically only a software issue why everyone isn't allowed to? gwickwiretalkediting04:15, 22 April 2013 (UTC)
While the current editnotice hacks are still in place, I seen no issue with this. I'd prefer it if it was split away from +accountcreator though. [stwalkerster|talk]05:36, 22 April 2013 (UTC)
Support As long as you're not causing problems, there's nothing wrong with this. If you're misbehaving by doing things against policy or against consensus, your flag should be removed. Nyttend (talk) 16:03, 24 April 2013 (UTC)
Support - Meh, Account Creator is a good hack, in that people who are given the flag under the guise of actually using tboverride for what it was meant for, can do that if they're given the flag and simply not given access to the internal account creation interface. No consensus for that exists yet, but it would be a lot easier to add a hook to the application process than to tweak (and inevitably break further) core software functions. Credit for the idea though, I do like it. -T.I.M(Contact)19:09, 25 April 2013 (UTC)
Support (first choice) I understand the issues raised by some of the supports of proposal one, however I echo NTox's comment above - if there isn't a problem to fix and if they are being used to help then why should we stop people helping and solving problems. In one sense the trust given to an account creator is similar to that of an admin (eg. you can't uncreate an account but you can unblock or undelete something, and the damage done to reputation can be similar when a mistake is made), so why should we be suggesting at a non-admin is less trustworthy. If there is pattern that the ACC right is being abused (primarily with editnotices or other blacklist protection) so removing it isn't an option then I can see where this would be helpful. But while ever an admin can giveth and taketh away at their discretion I don't see the need for a blanket rule to stop the right being used. And I'll also add that when moving pages you don't get the option to override the blacklist (or rate limits I'm fairly sure) it just happens automatically. Callanecc (talk • contribs • logs) 02:32, 26 April 2013 (UTC)
Support, so long as whether someone has or doesn't have the flag is solely determined by their level of activity at account creation. It Is Me Heret / c14:56, 28 April 2013 (UTC)
Support With no history of abuse and some benefit, why not? The privilege can be pulled instantly if abused. AGF of those with the flag. DocTree (ʞlɐʇ·cont) Join WER23:14, 12 May 2013 (UTC)
Support per NTox. I am a moderately active account creator, and not an admin. I actually wasn't aware of these other possible uses of the flag. We do need to concentrate on genuine problems. If someone is abusing the flag (using it to do harm), take it away from them. Ummm... and yeah, I'm not less trustworthy because I'm not an admin. ●Thane — formerly Guðsþegn 22:41, 19 June 2013 (UTC)
I had the flag but it was removed as I haven't time for ACC at the moment. Sadly I do need the flag on a regular basis for edit notice (and also for the blacklist needed at AfC). mabdul09:37, 22 April 2013 (UTC)
I've edited edit notices for people, specifically people using the edit request templates to request the change. It's one of those things where most people probably don't even know how to do it, and like anything else, abuse is grounds to have the right removed. I think less trust is required in giving someone the ability to edit editnotices than to create similar usernames anyway. — Bility (talk) 23:13, 22 April 2013 (UTC)
Second choice - whilst I can see the benefit in allowing other editors to have the right I just think that the power it gives is too much for it to be handed out like reviewer or rollback or even autopatrolled for that matter. However if the consensus goes this way or against proposal 2, I'm here. I'd rather have people able to fix things then give people the power to do it and make them submit edit requests instead. Callanecc (talk • contribs • logs) 02:32, 26 April 2013 (UTC)
First and only choice: The threshold for users to be accepted for ACC tool access is quite high and rightly so considering the access to non-public data; furthermore, ACC users must demonstrate competence on the tool before the flag is given, that's how it works currently. I don't see a problem with users who meet these criteria using the flag to its full potential, nor am I aware that any such users have used this flag abusively. On the other hand, I don't believe in dishing this flag out to users involved in the education program. They are an unknown and untested quantity. How do we know what, if any, knowledge they have of the username policy? Do they know how to properly check for similar accounts before using their flag to override anti-spoofing? Do they understand they implications of SUL? Do they know not to create disruptive/promotional/ISU account names? Pol430talk to me20:34, 28 April 2013 (UTC)
I think this is the right direction to go in. I'm not even old enough to do ACC, but am fond of editnotices (see Template:Editnotices/Page/2012 Delhi gang rape case, e.g.), and would love to be able to work in them more extensively someday. As a sidenote, if there were consensus to go down this road (which I acknowledge would be something of a departure from the bit's original purpose), a renaming of the flag might be in order. — PinkAmpers&(Je vous invite à me parler)20:36, 3 May 2013 (UTC)
Support as the status quo. I've seen users such as Headbomb (talk·contribs) need this flag for various things unrelated to ACC, which was not in my eyes a power-seeking behavior but rather a genuine desire to help Wikipedia. —Soap—03:06, 12 May 2013 (UTC)
The user group is relatively small, the admin vetting process is selective in bestowing this right, and any member of the group in breech of trust or similarly found incompetent to carry the flag can see it removed without the need for procedural wrangling.--My76Strat (talk) 20:49, 4 June 2013 (UTC)
Users who are no longer involved in the ACC process (meaning their ACC account has been suspended), or with the Education Program may have the user right removed at any time. Furthermore, administrators automatically inherit all the individual user rights of this user group. — Wikipedia:Account creator
It does not say a thing contrary to Wikipedia:Editnotice and where it says the flag may be removed does not imply that it should be removed. Also consider WP:Account creators where it is again asserted as a proper function of users in the group. There it says, "Additionally, the accountcreator flag allows users to edit or create editnotices."--My76Strat (talk) 05:12, 5 June 2013 (UTC)
Just curious, what is the rationale for account creators to be able to edit editnotices? (Not saying it's a bad idea, just wondering.) -- King of♥♦♣ ♠ 03:17, 22 April 2013 (UTC)
Editnotices are protected by a messy hack - using the title blacklist. Account creators need the ability to override that title blacklist. Thus account creators are given the technical ability to edit editnotices cos nobody thought (or could be bothered - idk, the result is the same) to actually implement the editnotice protection properly in the first place, which if they had done, we wouldn't have this mess with editnotices and +accountcreator. [stwalkerster|talk]05:31, 22 April 2013 (UTC)
If that's a bit strong, I apologise. I'm running on no sleep for at least 24 hours and am just taking a quick break from writing my dissertation which is due in about 6 hours. But that is how I feel about it. I may tone it down when when I next get chance to look at it. [stwalkerster|talk]05:33, 22 April 2013 (UTC)
Oh, and there's also been zero community consensus (AFAIK) about using +accountcreator for editnotices. People just started doing it. [stwalkerster|talk]05:34, 22 April 2013 (UTC)
Ironically, long before I became an admin I applied for and was granted ACC because I needed to create/edit edit notices for various project pages I was working on. I never fully understood - and still don't - why ACC and edit notices are bundled together, but unbundling them will almost certainly be another boon for hat collectors. Kudpung กุดผึ้ง (talk) 11:06, 25 April 2013 (UTC)
Just noting that, as I understand it, any technical unbundling of editnotice-editing (as proposed to a moratorium on it) would require alterations to the user rights on a software level, as opposed to simply moving around a few lines of code on a .php file. Or reconfiguring the editnotice system to something properly in the MediaWiki: namespace, since tboverride doesn't extend there. — PinkAmpers&(Je vous invite à me parler)20:43, 3 May 2013 (UTC)
Any actual abuse? Problems? Or are we trying to fix a problem that isn't actually problem? Can we see difs or other evidence of problems? I'd like to know more before I support or reject any of the above. DocTree (ʞlɐʇ·cont) Join WER21:23, 25 April 2013 (UTC)
I second that request for information. Is this making things look prettier/more rational for its own sake, or is there a practical problem that we're trying to solve? WhatamIdoing (talk) 23:48, 9 May 2013 (UTC)
I think that we need to separate the creation of editnotices from the account creator right. I don't get how those tasks are related.--Jasper Deng(talk)07:40, 12 May 2013 (UTC)
I think option two has caused confusion. It is easy to construe "Active account creators" as meaning "Active users with the account creator flag" and it seems that some participants may have. The several comments that have echoed "I don't see a need to change it", or the variations of "As long as [they're] not causing problems" and "[Are] Account Creators actually abusing the tools" seem content leaving the matter as it currently is. However option two does not leave things like they currently are but instead requires "active tool access". I want to poll supporters of option two (Technical 13, DeltaQuad, Riley Huntley, Mlpearc, NTox, Gwickwire, Stwalkerster, Nyttend, The Illusive Man, Callanecc, It Is Me Here, Doctree, and ItsZippy) to ensure they fully understand that some members of the account creator group will lose their competent abilities if option two passes and that it definitely does not keep things as they have been and are.--My76Strat (talk) 21:35, 4 June 2013 (UTC)
I personally understand that and wouldn't have supported that option if it wasn't the case. They should be active in the community and still actively have a need to have the bit (for example educational purposes) should be allowed to do these extra things. My thinking is that if they have a need to create a number of accounts for educational purposes, then it would be useful for them to be able to create sandboxes and what not and create/modify edit notices and what not for those sandboxes to aid the students in the tasks set before them. Technical 13 (talk) 21:47, 4 June 2013 (UTC)
Looks to me as if many who voted for #2 (including me) interpreted it as meaning "people with ACC rights who are active with Wikipedia". It would be disingenuous for a closer to interpret our comments as reason to remove ACC rights from people who are currently qualified for them. Nyttend (talk) 21:58, 4 June 2013 (UTC)
Please don't confuse my statement. I interpret it as meaning "people active with ACC and people at educational institutions creating multiple accounts who need the rights". Technical 13 (talk) 12:11, 5 June 2013 (UTC)
Earlier you gave a good rationale for why people in the education outreach program had a valid need. Are you now moving away from that position?--My76Strat (talk) 12:21, 5 June 2013 (UTC)
Nope... Added that to be clearer. Sorry if it caused more confusion. I was trying to add to and not replace my previous comment... Technical 13 (talk) 13:05, 5 June 2013 (UTC)
This is what concerns me about that:When you say "people at educational institutions" you are excluding the entire group of online ambassadors who arguably are the ones who would know how to create an account in accordance with policy and best practice. The people "at [the] educational institution", who ironically do the majority of the account creations, are very often no more qualified as a Wikipedia editor than any other freshly autoconfirmed account. With a plan like that, I am curious of who wouldn't anticipate problems. The rest of why I find this whole direction completely asinine considers this cause and effect. As an account creator I've surely created at least 7 or 8 hundred good accounts, and was the first wikipedian to welcome most of them. I believe I was around the forth or fifth wikipedian to join the ambassador program and although my participation has waned, I have remained an active member and given of my volunteer hours in supporting it. I did identify to the WMF as a reluctant requirement so I could continue volunteering my efforts. And now I find that I will very likely see this permission removed, mostly because of verbiage that is trying to fix where no problem exists, while it favors on campus account creations from undergraduates and course instructors with very limited clue about editing Wikipedia. I'll spare you the rest of the sad story since my opinion hardly matters around this place anywho. Cheers--My76Strat (talk) 16:46, 5 June 2013 (UTC)
It is my understanding that Option Two is indeed the system we are supposed to be following now, whether or not it actually is. See Wikipedia:Account creator, where it says that any user with the flag who no longer needs it for ACC/Education/Outreach may have it removed. The intent is that you are in fact supposed to be active, and many users who are not have had the right removed. NTox · talk22:04, 4 June 2013 (UTC)
I think where it currently says the flag "may be removed" will become "should be removed" under the stipulations of option two. Tools are granted based upon need, they are retained based upon competence and trust. Consider arbitrators for example; they are granted checkuser upon being properly vetted and appointed as arbs; they retain the bit as former arbitrators after serving. And of course the permission may be removed, like all permissions, but this is generally for some instance of cause. Therefore I disagree that implementing option two will be a continuation of current practices but rather a decisive step in a new direction. Nowhere has it been asserted that a problem exists that this proposal intends to fix; although the question has been asked several times.--My76Strat (talk) 04:26, 5 June 2013 (UTC)
I thought it was pretty clear that proposal 2 meant only those active with "ACC[ers] and people at educational institutions creating multiple accounts", that's certainly what I intended. And the rest per NTox. Callanecc (talk • contribs • logs) 01:19, 5 June 2013 (UTC)
Re. My76Strat: Aye for those who need/use the flag. Nay to 1; why limit if there's no problem? Nay to 3; flag implies/should show capability and action, shouldn't just be a hat to decorate a userpage. DocTree (ʞlɐʇ·cont) Join WER16:30, 5 June 2013 (UTC)
I agree with you. Here's where I diverge. I would rather depend on the administrator who assigns the permission to have vetted that need, which option 3 depends upon. The other two attempt to "legislate" a vetting criteria with prose as if an admin isn't capable of determining qualification and need. And by such prose you see created the cause and effect I outlined above. Pretty cool, huh.--My76Strat (talk) 16:59, 5 June 2013 (UTC)
In response to My76Strat, my view is that I can see no obvious problem with the current system, so don't see any need to change it. OF the three proposals I guess I'm probably closer to #3, though I would like to abstain from fully backing any option. ItsZippy(talk • contributions)13:37, 9 June 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Edit request on 10 June 2013
Latest comment: 11 years ago11 comments5 people in discussion
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I'm requesting that {{Anchor}} points be put in for each letter of the Approved users section.
Something in the nature of: {{Anchor|Approved users - 0}} {{Anchor|Approved users - 1}} {{Anchor|Approved users - 2}}
Through: {{Anchor|Approved users - X}} {{Anchor|Approved users - Y}} {{Anchor|Approved users - Z}}
To facilitate easy linking from other pages such as a verify link on a userbox/topicon/User## template or other types of requests. Grouping of short sections would be fine by me (such as {{Anchor|Approved users - X|Approved users - Y|Approved users - Z}} or what have you). Thank you for your consideration.
Technical 13 (talk) 13:51, 10 June 2013 (UTC)
That is a reasonable concern. I'm not in too big of a rush, just think that this would be useful because the list is so long and it would make it so much easier to link to a name (I'm thinking about mostly trivial things like userbox/topicon but it would also be nice for slightly larger User## template). Thanks for a response Mr. Stradivarius. Technical 13 (talk) 16:54, 11 June 2013 (UTC)
I've deactivated the request for now. Feel free to reactivate it if you get the ok from one of the three users listed above (the AWB developers). Best — Mr. Stradivarius♪ talk ♪09:13, 12 June 2013 (UTC)
It shouldn't be that difficult to add I suppose, the bot will probably require a complete rewrite when renaming moves away from local wikis anyway. Personally I don't really see much of an advantage to these anchor links though. The example you give above of allowing users to link closer to their name in topicons doesn't really convince me. Personally, if I want to verify if someone has AWB rights already I just use a Ctrl+F search on the page, so it doesn't make much difference what the starting point is. - Kingpin13 (talk) 17:18, 12 June 2013 (UTC)
If you could add it on the re-write, that would be great. I use [ctrl]-[f] too, but some people actually still use browsers without search features and some just don't want to be bothered. That is why I was asking... Thank you. Technical 13 (talk) 18:36, 12 June 2013 (UTC)
If there is consensus that having the anchor tags is a good idea I'll rewrite the bot to manage them. Personally though I would be opposed to them. I just don't see the advantage, I find it hard to believe there are any users who want to check the approval list of AutoWikiBrowser and don't use a browser with a search feature. The list is sorted alphabetically anyway, so it's not exactly difficult to check. I just don't think the anchors are going to help at all in locating users, in almost every single case. - Kingpin13 (talk) 18:55, 12 June 2013 (UTC)
For what it's worth, I don't think the effort is worthwhile. The list is not that big and I doubt that it is frequently visited by humans (who are not admins maintaining it). Mcewan (talk) 19:14, 12 June 2013 (UTC)
Backlog
Latest comment: 11 years ago1 comment1 person in discussion
Some parts of PERM are getting backlogged. Although it's an area I often work in, I will admit to recently only going for the low hanging fruit - I'm just too busy to do the more complicated ones that require more research. Can we get some more admins interested in working here? How about asking admins who have recently been given the bit? Kudpung กุดผึ้ง (talk) 00:05, 5 July 2013 (UTC)
Kingpin bot
Latest comment: 11 years ago2 comments2 people in discussion
Latest comment: 11 years ago5 comments4 people in discussion
I was recently asked what the criteria for the rollback right are. I can't speak for the other admins, but I'm copying my response here as a point of general interest:
"From WP:ROLLBACK: While there is no fixed requirement, a request is unlikely to be successful without a contribution history that demonstrates an ability to distinguish well intentioned edits with minor issues from unconstructive vandalism.
There are no fixed guidelines for rollback and it depends entirely on admin discretion. It's something admins don't discuss among themselves, noted that there are very few admins who actually work on PERMS. Those who do so regularly more or less appear to use similar criteria. What we look for is an overall edit count of around 500 or more to article space with a couple of hundred correct manual reverts of clear cases of vandalism, and without having to examine every edit to see what it was. The ES is therefore very important, even if using Twinkle. We also check block logs, and the users' talk pages for other warnings because a degree of general maturity/competency also needs to be determined."
Is it accurate to say the majority of admins want 500 or more edits to articles? It may be; I am not sure. And do you consider Twinkle's rollback function a 'manual' revert? I think many admins are fine with Twinkle-only vandalism work. NTox · talk16:58, 5 July 2013 (UTC)
I also doubt that.NottNott's request is accepted when this user has around 310 article space edits,of which 110 are reverts.Lsmll05:21, 15 July 2013 (UTC)
I'm known to be stingy with my according of rights, just as I am with supporting RfAs (although I have been accused more than once by at least one editor of being over eager to support). That said, my own experience at PERM tells me it's best to er on the side of caution. If anyone really wants to know, they will have to review all the Rollback closures over the past 12 months or so. It would probably be better than citing just one or two and assuming they are the majority. Kudpung กุดผึ้ง (talk) 12:17, 1 August 2013 (UTC)
RFC on removal of Account Creator user right
Latest comment: 11 years ago1 comment1 person in discussion
Latest comment: 11 years ago3 comments3 people in discussion
I'm sorry, but what is the actual point of a confirmed permission, when every time I see the page there is a flood of submissions marked as 'Not done' or 'You are already autoconfirmed?' Insulam Simia (talk) 09:40, 7 August 2013 (UTC)
It allows you to do everything an auto-confirmed account can, such as edit semi-protected pages, make page moves, and upload files. The reason it is so rarely granted is that administrators are reluctant to take responsibility for the potential misuse of the right, and it is pretty hard to establish a track record sufficient to justify granting the right without hitting auto-confirmed. There are also processes that allow a non-autoconfirmed editor request all those things be done on a case by case basis. Its really there for the exceptional case where the autoconfirmed restrictions are causing significant problem. Monty84515:35, 9 August 2013 (UTC)
Wouldn't changing *{{AWBUser|your username}} ~~~~~ to * {{AWBUser|{{subst:REVISIONUSER}}}} ~~~~~ eliminate any issues with Enter your user name exactly as the software displays it, for example in the 'Basic information' section of your preferences. Do not use underscores instead of spaces or change the case of the first letter. Note that all usernames begin with an uppercase letter or a symbol.? Technical 13 (talk) 12:30, 6 August 2013 (UTC)
Oppose If an editor isn't capable of following this easy instruction, than xe isn't ready to use AWB. Also as I see most editors' requests are properly filled, so this is slightly a solution in search of a problem. ArmbrustTheHomunculus09:35, 8 August 2013 (UTC)
Oppose per Armbrust. One good reason for declining such rights for the use of software is exactly that: if they don't understand the simple instructions for applying for access to the software, they aren't ready to use it. Kudpung กุดผึ้ง (talk) 09:39, 13 August 2013 (UTC)
Comment: So it being moved was why I was having a hard time finding it. I see the current instructions as WP:CREEP (as it is creating an unnecessarily long instruction for a simple task), which is why I am suggesting simplifying them. I would even go so far as to say it should be a button they can click that will load the edit page pre-filled in and all they have to do is confirm and hit Save page. Technical 13 (talk) 13:47, 21 August 2013 (UTC)
Support. I made essentially this change, not realizing there was opposition to this, and was then reverted and referred here. I don't think keeping instructions complicated on purpose is a good way of seeing whether people are smart enough to use a tool. Jackmcbarn (talk) 22:50, 24 August 2013 (UTC)
Comment These instructions are not really complicated and are there for a reason. If somebody can't make that, than they shouldn't have access to such a powerful tool as AWB. ArmbrustTheHomunculus23:02, 24 August 2013 (UTC)
Comment It should be supper simple... If the "bots requests" section was moved above the "users requests" section, then [[?title=Wikipedia_talk:AutoWikiBrowser/CheckPage&action=edit§ion=new&preload=Wikipedia_talk:AutoWikiBrowser/CheckPage/PermissionRequest&summary=Requesting%20%5B%5BWP%3AAWB%7CAWB%5D%5D%20permissions&wpMinoredit=1&wpWatchthis=1 Request AWB permissions |?title=Wikipedia_talk:AutoWikiBrowser/CheckPage&action=edit§ion=new&preload=Wikipedia_talk:AutoWikiBrowser/CheckPage/PermissionRequest&summary=Requesting%20%5B%5BWP%3AAWB%7CAWB%5D%5D%20permissions&wpMinoredit=1&wpWatchthis=1 Request AWB permissions]] would do the trick... Click that and then click Save page and your request is submitted.
Requirements for autopatrolled
Latest comment: 11 years ago6 comments4 people in discussion
I think the requirements currently listed at WP:AUTOPAT are not very good. For example; if a user has created 10 GA's they should probably be autopatrolled. But if a user has created 100 articles that are copyvios or 500 unreferenced stubs, they should not. The 50 article suggested requirement, which used to be 75, is arbitrary and somewhat useless. There needs to be enough articles to show a user's history and an understanding of our policies and guidelines. Anything more than that is unneeded and needlessly burdensome on our NPPers.
I'd like to suggest that we come up with more accurate criteria and focus less on the 50 article suggested requirement and focus more on good referencing, no BLP or copy vios, etc. I'd like to get input here before bringing this idea to the village pump. What do you think? 64.40.54.157 (talk) 04:00, 27 August 2013 (UTC)
The system has been working perfectly well for a long time. The admins who work on these pages do in-depth research of the users' creations and editing history before granting the 'right'. It's boring tedious work, but you can be sure it's done. They have the discretion to accord the right at a lower level than the recommended 50 articles and often do, while sometimes, they will even decline a request although the 50 article threshold has been achieved or passed. I see no compelling argument to change the status quo. A solution looking for a problem. To get an idea, you may wish to review several hundred accepted and declined applications (see the archives). Kudpung กุดผึ้ง (talk) 05:37, 27 August 2013 (UTC)
(Non-administrator comment) Kudpung กุดผึ้ง, I have to agree that the requirements here aren't ideal. I personally believe that the requirement that they be non-redirect "article" new pages is causing extra work for NPP. Personally, I've created 37 redirects in article (verify), 190 user pages (18 are redirects (verify count-verify redirects), 52 "Wikipedia" project pages (19 are redirects verify count-verify redirects), Uploaded 3 files to Wikipedia (verify) and 14 to commons for use on Wikipedia (verify),31 templates (4 are redirects verify count-verify redirects), 18 categories (verify), 1 module (verify) and yet with a total (not including talk pages) of 346 "New" pages (including 78 redirects) and the reviewer usergroup allowing me to patrol others' works, I do not qualify for autopatrolled. I think this kind of thing for myself and other users is a large part of the cause of backlogs at WP:NPP. Technical 13 (talk) 13:55, 27 August 2013 (UTC)
FWIW, I actually know quite a lot about NPP. After several years and 100s of hours of solid research into it, I was partly responsible for initiating the events that accumulated in us getting the Page Curation tool. I can assure you that the problems that still persist with NPP are in no way related to a lack of users with autopatrolled rights. If you're in for some heavy bedtime reading - at least as much as will fill a 300-page doorstopper, you can start with the archives at WT:NPP. There are things in there that will have you howling with laughter, fuming with anger, and beating your head in desperation! Happy reading ;) Kudpung กุดผึ้ง (talk) 14:23, 27 August 2013 (UTC)
I agree that the current criteria appear to be unduly arbitrary. However, I can't see a reason why a user like Technical 13, who has apparently never created an article, should have the autopatrolled permission. --Orlady (talk) 14:28, 27 August 2013 (UTC)
I believe you do Kudpung, and I think that the page curation tool should replace NPP as it seems to be far superior from my usage. Orlady, FWIW, I've actually created 3-4 stubs, that were turned into redirects or userfied years after the fact, that shouldn't count against me that someone found someplace else to merge that information into and turned my article into a redirect. Furthermore, the "New" flag doesn't discriminate by namespace, so all of my 346+ New pages needed to be manually reviewed. I consider that significant enough of a drag on the system to apply the autopatrolled usergroup. Kudpung, I will spend a little time glancing through some of those... Thanks for the idea. :) Technical 13 (talk) 15:25, 27 August 2013 (UTC)
semiprotected edits
Latest comment: 11 years ago2 comments2 people in discussion
hi I would like to edit a semi protected article on Tony Abbott, and Kevin Rudd, and the labor leadership. I want to change it to show that the prime minister is tony abbott, and that kevin rudd is not labor leader anymore — Preceding unsigned comment added by Yfewuv (talk • contribs) 06:32, 8 September 2013 (UTC)
And seeing as that argument is currently continuing on the talkpages of those articles, it would be a good idea to join those discussions to help gain WP:CONSENSUS. Ensure you have sources to show things first ES&L09:44, 8 September 2013 (UTC)
Edit request on 16 September 2013
Latest comment: 11 years ago2 comments2 people in discussion
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Copyright status question at confirmation requests
Latest comment: 11 years ago8 comments3 people in discussion
When people ask to be confirmed early because they want to upload a picture they routinely get this as a reply:
Question - What is the copyright status of the image(s) or file(s) you wish to use?
Isn't this kind of a trick question with no right answer? If they have a free image we direct them to upload it at Commons. If they have a non-free image we tell them to use Files for Upload. Either way the answer is an automatic no, so it seems kind of pointless to have this extra step. There is already a notice at the top of the page indicating that if uploading an image is the only reason they want to be confirmed early it probably isn't going to happen.
So, I suggest we simply develop a new template that combines these two
Not done - These types of images must be free as they are replaceable. Free images should be uploaded to our free image repository, the Commons. You do not need any special permissions to upload there and you can use the same username and password you use here.
Not done - As per the notice at the top of this page, this type of file can be uploaded using the Files for Upload process which will not require advanced permissions.
into one template that explains both options and we deprecate the use of the image status question altogether.
Not done - If the file you want to upload is not available under a free license, it should be requested using the Files for Upload process, which does not require any special permissions. If it is available under a free license, it should be uploaded to our free media repository, the Commons. You do not need any special permissions to upload there, and you can use the same username and password you use here.
Okay, I've updated the template and its documentation. I kept the old options in for now, but listed them as deprecated on the doc page. Jackmcbarn (talk) 01:55, 22 September 2013 (UTC)
Actually, the question was intentional: most people who come here looking to upload images think they can pull anything from the web and upload it. The original "question" was actually more of "hey, did you understand copyright", designed to make them think. ES&L10:21, 22 September 2013 (UTC)
I get that, but it seems kind of dishonest to ask them a question when we know that no matter what their reply is they still aren't going to get confirmed early. Seems better to just give them pointers to the relevant information on copyright and direct them to use whichever of the two processes seems more appropriate.
The more I think about this the more I think we should make a greater effort to make it clear that almost nobody gets confirmed early. Seems like >95% of requests for the confirmed right are denied. The only time it ever does get granted is in the case of legitimate alternate accounts. Everyone else gets told no for one reason or another. I don't disagree with that, there is almost never a valid reason to confirm early when the bar for autoconfirmation is so low, but maybe we should just tell people that right up front and save both applicants and reviewing users and admins the effort of maintaining a process whose sole purpose most of the time is to automatically say no. Beeblebrox (talk) 21:03, 22 September 2013 (UTC)
I went ahead and changed the edit notice and the box at the top of the page to more honestly reflect the relaity of the situation. Not sure it will help, seems like a lot of people just ignore such things, but ti's worth a try. Beeblebrox (talk) 21:23, 22 September 2013 (UTC)
Latest comment: 11 years ago4 comments3 people in discussion
Is there a particular order to the list? With 11 entries, there ought to be some rationale for the order. If none, I propose alphabetical. If something else, it eluded me.--SPhilbrick(Talk)17:16, 17 October 2013 (UTC)
I agree, didn't notice or see any particular order for the list previously. And I also think that having an alphabetical order will be much better and helpful, so yes I believe that can be done. TheGeneralUser(talk)18:43, 17 October 2013 (UTC)
Latest comment: 11 years ago6 comments3 people in discussion
Is there anyone who could knock up one of those dropdown thingies with a table of ready to paste answer templates for Rollack? Something on the lines of:
::{{notdone}}. Please see the notice at the top of this page. With only {{x}} edits to mainspace I don't think you have sufficient editing experience yet. Take a moment to check out what counter-vandalism is at [[WP:CVU]] and when you have made 200 or so edits you may wish to enroll at the [[WP:CVUA]|Counter Vandalism Academy]] to learn more. ~~~~
::{{notdone}}. Please see the notice at the top of this page. I see you just also applied for Reviewer. Let's see how you get on with that first and then we'll take another look again when you've made a few more edits. ~~~~
::{{notdone}}. Please see the notice at the top of this page. This is not what Rollback is for. Take a moment to read [[Wikipedia:Rollback]] and if that's what you would like to do, you can then check out the [[WP:CVU|Counter Vandalism Unit]] to learn more. ~~~~
Latest comment: 10 years ago4 comments3 people in discussion
I asked my question over here already.... User_talk:Steven_(WMF)#question_about_active-editor-counts. Basically, I'm trying to find out the total counts of active&veryActive reviewers&rollbackers, and the percentage which have more than 500 total edits. For contrast, I'm also interested in the totals and percentages of active&veryActive non-reviewers&rollbackers that have more than 500 total edits. Is there some wiki-tool or API page that would allow me to answer such queries myself, in a SQL-style language perhaps? Thanks. 74.192.84.101 (talk) 02:13, 30 December 2013 (UTC)
That's actually asking for a lot of stats. Although I'm fairly active in all these areas, I don't know how to get stats myself. The WMF makes many claims and promises, but generally if they can't see a use for them for their own purposes, in my experience they won't do it for us. You could try asking Ironholds - he's quite helpful and at least knows how to do this sort of thing.. Kudpung กุดผึ้ง (talk) 05:04, 30 December 2013 (UTC)
The important question is "define active/very active"? If by that you mean "more than five edits in the last month", that's fairly trivial to work out; I'm happy to put some volunteer time into it next weekend. Drop me a note on my talkpage. Ironholds (talk) 06:40, 30 December 2013 (UTC)
Thanks much, will do. Part of the reason that I asked Steven is he's on the WMF "growth team" and they're busy researching similar things. The choice of 5+edits/mo as the definition of active, and 100+edits/mo as the definition of veryActive, was because WMF already has that exact raw data; they publish totals[2] (just not split out by user-right which is what I'm seeking). And the other part of the reason I asked Steven, is because I don't know who the dev is behind reportcard.wmflabs.org , and I hadn't met Ironholds before. :-) Anyhoo, I'll head over to that user-talkpage, and if we come up with anything useful, will post it onto my own talkpage. Thanks for improving wikipedia, folks, see you around. 74.192.84.101 (talk) 13:10, 30 December 2013 (UTC)
Already done By Kudpung. Can we get some admins at WP: PERM/RW, by the way? Thanks, Electric Catfish 13:48, 23 August 2012 (UTC).
Not done is a bit of a pile-on and probably disheartening for the user. In addition to this, when the closing admin goes against the (Non-administrator comment)'s, the process looks bizarre. Reaper Eternal (talk) 12:53, 26 August 2012 (UTC)
Moved from Wikipedia talk:AutoWikiBrowser/CheckPage
Not done: You didn't specify what you wanted changed. Jackmcbarn (talk) 17:59, 15 September 2013 (UTC)
Question - What is the copyright status of the image(s) or file(s) you wish to use?
Done Callanecc (talk • contribs • logs) 01:29, 19 October 2013 (UTC)