Wikipedia:Village pump (proposals)

New ideas and proposals are discussed here. Before submitting:

Check to see whether your proposal is already described at Perennial proposals.
Consider developing your proposal on Wikipedia:Village pump (idea lab).
Proposed software changes that have gained consensus should be filed at Bugzilla.
Proposed policy changes belong at Wikipedia:Village pump (policy).
Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
Proposed new wikis belong at meta:Proposals for new projects.
Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

add IPA on person articles

feature request:
Many times, I don't know how to pronounce a person's name.
If I could go on wikipedia and see an ipa pronunciation - that would be very nice!
my context is translation.
Thanks

New user right proposal.

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

I am very well aware of the potential fact that this has been proposed before and am very well the apprehension the community may have towards this proposal, but here goes. There are highly experienced users out there how can be trusted with additional user rights. The rollback right, the reviewer right, the account creator right, the file mover right, and the autopatrolled right given that the editor has demonstrated the necessary trust to handle such requests. There are editors out there who can demonstrate when and when it's not appropriate to edit a protected page. There are editors who tend to have to make a lot of edit requests to get their edits to go through. I am therefore proposing the tboverride, editprotected user rights be added as a separate permission for users to obtain through a standard WP:PERM request. The evaluating admin will judge the editor based on how previous edit requests were handled, and the validity of their own edit requests and how many times it gets approved or not, as well as if the trust in the editor is there or not. The edit protected user bit can come in handy as it allows access to blacklists, fully protected pages, and edit notice pages. Access to these pages can allow a user who regularly maintains a template or usually has to have an admin override the title blacklist to the work themselves. The new user right would be called Protected Page Editor. I would like the community to give some input in this.—cyberpower ^Chat_Online 14:50, 12 October 2012 (UTC)[reply]

An extended discussion on unbundling the tools is taking place at Wikipedia talk:Requests for adminship#Unbundling the tools --Epipelagic (talk) 07:41, 14 October 2012 (UTC)[reply]

New user right proposal - Support

As proposer.—cyberpower ^Chat_Online 14:53, 12 October 2012 (UTC)[reply]
I'd prefer a combination of only editprotected/tboverride, as I think that editinterface should stay only to admins, but It's okay. — ΛΧΣ21™ 16:06, 12 October 2012 (UTC)[reply]
I agree, we need to modularize these tools so that more people can help. Kumioko (talk) 16:32, 12 October 2012 (UTC)[reply]
Editinterface is not a big deal. The vast majority of interface pages require little or no skill to modify, such as MediaWiki:Blockedtext.--Jasper Deng (talk) 17:07, 12 October 2012 (UTC)[reply]
And the vast majority of deletions carried out each day are easy uncontroversial speedies that do not require much judgment to carry out, but I don't think you'll find support for making deleting pages a freely grantable right. The editinterface right allows a user to immediately wreak havoc across every single page on this wiki with a single edit. Not even vandalizing the most highly transcluded template can do that. T. Canens (talk) 17:19, 12 October 2012 (UTC)[reply]
Surely we don't need admin-level trustworthiness with this? I don't buy that argument when most editinterface edits are completely minor like spelling corrections. Yes, I would support unbundling speedy deletions. This would not be a freely-grantable right (I would otherwise oppose); it should require the trustworthiness associated with the edit filter, which is unbundled and can also cause havoc if misused.--Jasper Deng (talk) 19:24, 12 October 2012 (UTC)[reply]
The "editinterface" permission does require a high level of trust, to which even some administrators have failed to live up. —David Levy 19:47, 12 October 2012 (UTC)[reply]
Really, the only thing required for trustworthiness w/ advanced permissions is the ability to abstain from using them if in any doubt.--Jasper Deng (talk) 01:44, 13 October 2012 (UTC)[reply]
...and the ability to reliably judge when to exhibit doubt, along with the absence of malice. Once upon a time, we called such individuals "administrators". —David Levy 02:17, 13 October 2012 (UTC)[reply]
Nope. Admins also must be good content contributors and, these days, are often expected to wade into the messiest of disputes. This is way more than what I said.--Jasper Deng (talk) 02:37, 13 October 2012 (UTC)[reply]
You appear to have overlooked the "once upon a time" part. —David Levy 02:49, 13 October 2012 (UTC)[reply]
So, then what's your argument here? (I was mainly arguing against the "ability to reliably judge" part).--Jasper Deng (talk) 02:52, 13 October 2012 (UTC)[reply]
My argument is that editors demonstrating "trustworthiness w/ advanced permissions" should be made administrators, not subjected to onerous demands that drive them away from RfA or forced to settle for lesser rights packages created as workarounds. —David Levy 03:03, 13 October 2012 (UTC)[reply]
Most of our administrators were appointed for life before 2008, when school kids could get the mop by little more than asking. They make up the majority of our administrators. Yet not many of these administrators have run amuck on the interface. So why should there be a big deal about extending a little trust to veteran content developers? — Preceding unsigned comment added by Epipelagic (talk • contribs) 03:35, 13 October 2012‎ (UTC)[reply]
There shouldn't be. That's my point. —David Levy 03:44, 13 October 2012 (UTC)[reply]

"before 2008, when school kids could get the mop by little more than asking" is one of the stupidest things you've said so far, Epipelagic, out of the many stupid things you've said on the topic of administrators lately. — Hex (❝?!❞) 07:29, 15 October 2012 (UTC)[reply]
Methinks that maybe this argument is getting a bit too heated. ⁓ Hello 71 22:01, 1 November 2012 (UTC)[reply]
With the editinterface right removed, this is a good idea. I just recently had to go through a multi-step process for a simple page move that garnered absolutely zero discussion during its RM, when I was sure it wouldn't be a problem in the first place. Seems like this would help remove some clutter from a few places and speed up a few processes if used by experienced editors. —Torchiest ^talk_edits 18:32, 12 October 2012 (UTC)[reply]
Good idea, will help trusted non-admins contribute more. Mark Arsten (talk) 18:51, 12 October 2012 (UTC)[reply]
Now support -- WOSlinker (talk) 21:14, 12 October 2012 (UTC)[reply]
Support, as long as "editinterface" stays out of the proposal. Since RfA is no longer functional, we need other ways for people to get the tools they need. --Carnildo (talk) 00:25, 13 October 2012 (UTC)[reply]
Support, though I still don't think it advisable for non-admins to deal with {{editprotected}} requests arising out of content disputes that necessitated a full protection, but not enough to oppose. T. Canens (talk) 02:20, 13 October 2012 (UTC)[reply]
Unbundle the bit as much as practicle so that non-admins can help out more, and admins will be bothered less with tedious tasks that really do not require the admin moniker. ~ GabeMc ^{(talk|contribs)} 02:21, 13 October 2012 (UTC)[reply]
As long as editinterface stays out. Anomie ⚔ 02:39, 13 October 2012 (UTC)[reply]
Support, as long as "editinterface" stays out of the proposal. Lord Sjones23 (talk - contributions) 02:49, 13 October 2012 (UTC)[reply]
Somewhat reluctant support. On the one hand, this would be wonderful for people who work in templates, as the higher use ones are all protected (for a number of good reasons), and as template workers and admins are rarely the same group (for a number of poor reasons). On the other hand, the ability to lock down an article in the mainspace when everything goes to hell is a powerful one, and I worry about the effect on dispute resolution of losing that ability. Sven Manguard Wha? 00:07, 14 October 2012 (UTC)[reply]
WP:INVOLVED should be extended to this userright so that editing through an edit warring page protection while involved in the dispute should be treated as a violation of that.--Jasper Deng (talk) 00:10, 14 October 2012 (UTC)[reply]
Sure, in most cases it'll stop the two or three people that already were involved, but it won't stop the completely uninvolved people, and that'll aggravate the situation. Sven Manguard Wha? 00:22, 14 October 2012 (UTC)[reply]
Support, seemingly a good idea to unbundle this bit minus editinterface. Regards, — Moe ε 07:56, 14 October 2012 (UTC)[reply]
All right, I can get behind this, iff editinterface is out of the proposal. --Rs chen 7754 08:02, 14 October 2012 (UTC)[reply]
Support. With editinterface removed, I see no reason not to grant this to non-admins - it's a content thing, not an admin thing. In fact, I generally support the unbundling of rights as far as possible. And for those who always cry "No, you just have to fix RfA and all will be lovely", the curent "admin elite" system is a core part of that very problem, and the unbundling of rights is one of the possible ways towards fixing things. -- Boing! said Zebedee (talk) 07:58, 15 October 2012 (UTC)[reply]
On the contrary, it's likely that past unbundling of permissions — while sensible — has promoted the current climate at RfA (by encouraging opposition on the basis that admin candidates can obtain access to individual tools instead). This proposal's implementation would be an even bigger step in that direction. ("You can just become a protected page editor, so you don't need adminship.") —David Levy 14:23, 15 October 2012 (UTC)[reply]
I think you are being too narrow minded about this. No disrespect but editors do not become admins to access protected pages. They become admins to do more contentious things such as block, delete, protect, and close discussions. There's no need for admins to be doing fully protected content related work if other experienced non-admins could be doing that. And administrators can remove this bit if editors a abuse it. If this were to block or delete or protect pages which is a highly contentious thing to do and proposed as a separate user right, I would oppose it. This specific proposal should have no affect on the current RfA.—cyberpower ^Chat_Online 11:02, 16 October 2012 (UTC)[reply]
Without realizing, you're relying upon the cultural shift to which I referred.
You write that "there's no need for admins to be doing fully protected content related work if other experienced non-admins could be doing that." But I don't assert that the latter users should be excluded from such tasks; I believe that they should be made administrators. If we can trust them to not abuse the ability to edit protected pages (e.g. to vandalise them or to gain an insuperable advantage in a dispute), we can trust them to not abuse the other administrative permissions. The idea that editors shouldn't be granted access to the tools unless they need all of them is a relatively recent one (and a major factor in RfA's decline)
You note that "administrators can remove this bit if editors abuse it." Indeed, and this encourages the community to treat the unbundled permissions as safer alternatives (or at least prerequisites) to adminship. Instead of thoughtfully evaluating editors' past performance, we succumb to fears of hypothetical problems and turn away users whose histories are incompatible with arbitrary checklists (to which the proposed change would add a major item). —David Levy 14:47, 16 October 2012 (UTC)[reply]
Support, with the same editinterface caveat that others have expressed. Evanh2008 ^{(talk|contribs)} 03:54, 16 October 2012 (UTC)[reply]
Support. If it's technically feasible, I don't see any problems with this proposal. Tijfo098 (talk) 13:25, 16 October 2012 (UTC)[reply]
Support - RfA is a big deal, sorry to break it. Hasn't been "no big deal" for about half a decade now, back when you could very easily get the mop. Today you have to be some sort of community liaison, never calling people out on their crap or saying it like it's so. You have to be some sort of "model citizen" for the rest of wikipedia. Sorry; I just want to be able to edit high-use templates since... oh... right, I know the language better than 3/4 of our current admins (and I'm being generous there). As always, this userright has my total support - technical expertise trumps the perceived (whether real or not) unbundling of the administrator userright. - Floydian ^τ _¢ 15:00, 16 October 2012 (UTC)[reply]
Support; a little bit of unbundling would be helpful in this case. I think Boing! said Zebedee makes a very good point. bobrayner (talk) 11:14, 22 October 2012 (UTC)[reply]
Support - and more user groups in future would be perfect (suppress-redirect and such) Petrb (talk) 12:14, 23 October 2012 (UTC)[reply]
suppress-redirect was unfortunately shot down less than a year ago. The community believed it'd be like handing a delete button to users.—cyberpower _Online^{Trick or Treat} 12:17, 23 October 2012 (UTC)[reply]
Support - This can get more work done. -- FutureTrillionaire (talk) 16:10, 23 October 2012 (UTC)[reply]
Support - We're willing and able to help. --Funandtrvl (talk) 16:20, 23 October 2012 (UTC)[reply]
Support It would be a good way to reduce the burdens admins have to do. A reasonable minimum requirement would be 6000 edits in 1.5 years with admin approval. I am willing to help. Johnny Au _{(talk/contributions)} 16:25, 23 October 2012 (UTC)[reply]
Support yeepsi (Time for a chat?) 16:30, 23 October 2012 (UTC)[reply]
Support - Mild support, to be more accurate. Just to be clear, this right ought to be for editors of considererable experience, ones "vetted" for past bad behavior (i.e. someone tends to edit war consistently, etc.) and not for all editors in general. Just my two cents. Sector001 (talk) 18:16, 23 October 2012 (UTC)[reply]
Support - let admins deal with the blocks, deletions, protections and the more contentious things. I would, however, set the bar relatively high to start with, (say > 2 years and > 10,000 edits) it can always be lowered later, once the principle has been established, provided the prophets of doom are wrong. Equally, abuse of the right should lead to immediste suspension, pending investigation. Arjayay (talk) 18:24, 23 October 2012 (UTC)[reply]
Support, - needs to be a highish bar, but i support this.Blethering Scot 20:08, 23 October 2012 (UTC)[reply]
Support, I trust the people handing it out won't hand it out inappropriately. Gigs (talk) 20:28, 23 October 2012 (UTC)[reply]
1. ~~Support the unbundling of the tools as much as is practicable so that more people can help. ~ GabeMc ^{(talk|contribs)} 20:29, 23 October 2012 (UTC)~~ The user has voted above, see bvote #10[reply]
Support – Wow, what a great idea! To those who are saying that regular users aren't competent enough, that is why the right would only be assigned to trusted users. TRLIJC19 (talk • contribs) 20:31, 23 October 2012 (UTC)[reply]
Support: Vatican II, baby. Kiefer.Wolfowitz 21:12, 23 October 2012 (UTC)[reply]
Support - I can support this.--Amadscientist (talk) 21:21, 23 October 2012 (UTC)[reply]
Support: Current policy makes admins the arbiters of consensus on protected pages, and I think it a bad idea to have such a small group have that power or responsibility, depending on your point of view. Also, it is technically difficult to request some non-controversial changes such as fixing up citations on the talk page. Churn and change (talk) 21:33, 23 October 2012 (UTC)[reply]
Support: Good option for non-admins! --Tito Dutta (talk) 21:51, 23 October 2012 (UTC)[reply]
Support I'm a fan of unbundling the tools and this seems like a good one to unbundle. I do agree with those who say it should have a pretty high bar though. Captain panda 23:39, 23 October 2012 (UTC)[reply]
Support - I've no objections. --ceradon ^talk_contribs 01:51, 24 October 2012 (UTC)[reply]
Support I don't see why not. If individuals abuse it, they lose the privilege; if its abuse is widespread, we can consider rescinding it altogether. But I suspect this will only be a benefit to the encyclopedia. --BDD (talk) 04:41, 24 October 2012 (UTC)[reply]
Support this should be a net benefit,and if it isn't, the editors involved can have it revoked like with rollback. Imzadi 1979 → 04:50, 24 October 2012 (UTC)[reply]
Support Since there are a great many tools given to newbie admins who don't know how to use them out of the gate, I'm militantly indifferent to wailing that OMG People Won't Know How To Use This Tool Wisely. Beyond that, exhortations to fix RfA are completely specious; proposals have been mooted for several years, there's never been close to a consensus to change RfA, and as long as it's a straight popularity contest, with a large dollop of hazing, it'll stay broken. I see no reason to hold up any other improvements to the way we do things on such a pie-in-the-sky premise. Ravenswing 08:36, 24 October 2012 (UTC)[reply]
Support, with a condition I like the idea in principle; generally, if I something is edit protected, I just abandon my edit. Thus, I can see how having this option could improve the project. On the other hand, there would need to be a strong admonition from the beginning about wading into the content dispute that prompted edit protection, even accidentally. I think editors should have to explicitly promise to check why the page is protected and avoid the text at issue, perhaps by actually typing out the words. And violations should be dealt with severely. -Rrius (talk) 08:58, 24 October 2012 (UTC)[reply]
Support Can't really see any drawbacks.--Echetus Xe 09:03, 24 October 2012 (UTC)[reply]
Support editprotected/tboverride, oppose editinterface -- too dangerous. There are people who, for religious or philosophical reasons, refuse to accept any power over other users such as blocking, but are fine with the maintenance tools. There are people with Asperger's or high functioning autism who would be great at using the non-people tools but who know that they are completely unqualified for dealing with human behavior. --Guy Macon (talk) 11:16, 24 October 2012 (UTC)[reply]
I find that highly insulting. I ask you please scratch that last sentence.—cyberpower _Offline^{Trick or Treat} 11:20, 24 October 2012 (UTC)[reply]
I stand by what I wrote, and I deny that it is an insult. While I do not consider either condition to be a handicap or disability, I am on solid ground in saying that someone with high functioning autism is better at some things and worse at others compared to a neurotypical individual, and reading other people's emotions is one of the areas they tend to be worse at. --Guy Macon (talk) 11:31, 24 October 2012 (UTC)[reply]
I have aspergers and ADHD. I will say its hard to read human behavior, it doesn't mean I can't. I spent years of hard work trying to make myself less autistic, and though I still have it, I have tought myself how to sufficiently read human behavior and being more socially "normal". So the word completely makes your statement an insult towards me. If you won't strike the sentence, at least please strike the word "completely".—cyberpower _{Limited Access}^{Trick or Treat} 12:42, 24 October 2012 (UTC)[reply]
I don't think I'm reading it the same way you are. He's not saying every aspie is completely unqualified to deal with people, but that there may be some subset who are, yet are qualified to used advanced maintenance tools. I don't know if I agree with his argument (or even if it's a good thing to bring up), but that's how I read it. Gigs (talk) 16:20, 24 October 2012 (UTC)[reply]
Yes. I meant that subset who know that they are completely unqualified. I apologize for being unclear. And it is a subset; many have no problems at all in that area or even superior abilities. One of the best aspects of Asperger's syndrome is the ability to accurately evaluate your own capabilities, and I have no doubt that there are those who have correctly concluded that they are well suited for dealing with article content issues and poorly suited for dealing with user behavior issues. --Guy Macon (talk) 23:16, 24 October 2012 (UTC)[reply]
I will tell you that I am awful with CSDs but pretty good evaluating consensus and comprehending copyright policies and WP policies and regulations.—cyberpower _{Limited Access}^{Trick or Treat} 15:46, 31 October 2012 (UTC)[reply]
Support, give it to rollbackers who at least have 1000++ edit and they MUST requested the right, don't give it to anybody as trial at least editor is trusted person, other than that i see nothing can be wrong with this proposal. Ald™ ¬_¬™
Support. This is obvious, really, and it would be a great help with basic maintenance tasks. For example, I've contributed to DYK for years, but I can't do the maintenance task of moving prepared hooks into queues because I don't have admin permissions. But you shouldn't need admin permissions for such an essentially janatorial task in the first place. Prioryman (talk) 19:00, 24 October 2012 (UTC)[reply]
I shudder at the thought of admins declaring that it is perfectly normal for them to edit fully protected pages, and adding more people to this "exclusive" club doesn't seem like a bad idea. We might end up needing some kind of super-protection for specific cases, but so be it. I am hoping that this right will be granted liberally (easy to give, easy to lose), though. --Conti|✉ 19:44, 24 October 2012 (UTC)[reply]
Support cautiously. I've thought something along these lines before myself. Just some fine tuning with the etiquette about the prerequisites I think. Casliber (talk · contribs) 19:54, 24 October 2012 (UTC)[reply]
Support I don't see why not, the ability to edit protected pages doesn't require that much judgement, if someone does do something stupid with it then it should be easy enough to take the right away, and the feature would have obvious utility. I don't buy the argument that anyone who can be trusted with this can be trusted with all the admin tools, as some of them do require more judgement than others or specialised knowledge or skills. And anyone advocating RfA reform instead is ignoring the fact that it isn't going to happen. Hut 8.5 21:52, 24 October 2012 (UTC)[reply]
Support Not all editors are equal in status. This change will reflect that. More importantly, this change will reduce the workload of admins. Farrtj (talk) 22:09, 24 October 2012 (UTC)[reply]
Support For those that only want access to this tool, it beats trying to go through RFA. —Locke Cole • t • c 22:12, 24 October 2012 (UTC)[reply]
Support It would be a useful tool I'm sure. Perhaps we could have a trial to test it out? Cloudbound (talk) 23:58, 24 October 2012 (UTC)[reply]
Support We must proceed on the assumption that RfA cannot be improved unless scrapped from the outside, because too many insiders see too many different problems and thus diametrically opposing solutions. I see this as akin to the somewhat recently created filemover flag--a technical ability that some users 1) can esaily be trusted with 2) are particularly good at. I'm a perfect example of an admin who doesn't respond to edit-protected requests on template pages, because I'm not interested in learning the coding well enough to make sure I'm not making problems worse. Qwyrxian (talk) 02:09, 25 October 2012 (UTC)[reply]
Support - Knowing how most of these proposals are usually short lived I had to support as I'm with Sven mostly on this one being a frequent visitor in the #10 namespace that would be a plus in my book. Mlpearc (powwow) 02:49, 25 October 2012 (UTC)[reply]
Support – Despite some of the naysayers' concerns, I believe there are a number of responsible, trustworthy editors who could be trusted to use these rights responsibly and in furtherance of the goals of the project. — UncleBubba ^{( T @ C )} 05:45, 25 October 2012 (UTC)[reply]
Support to make life easier for non-admin template coders. It would also make it easier for trusted non-admins to help out directly at the Main Page. Graham87 05:57, 25 October 2012 (UTC)[reply]
Support - I agree that trusted editors who have proven they know what they are doing should be given such a right. It will ease the burden on administrators and improve the pace at which things move as a whole. Inks.LWC (talk) 06:33, 25 October 2012 (UTC)[reply]
Support—this makes a lot of sense. Tony (talk) 14:24, 25 October 2012 (UTC)[reply]
support-this protects special topics that inform worldwide people on sensitive subjects for better understanding of the complex human behaviour in the humanity history.User:NtimumaNtimuma 15:31, 25 October 2012 (UTC)[reply]
Support As one of those who has felt the need for it many times over my 5 years + career on Wikipedia as an experienced editor including templates. Debresser (talk) 15:40, 25 October 2012 (UTC)[reply]
Support - Due to the declining number of active admins. There is a large class of editors that are willing to do housekeeping, but dont/wont/cant be an admin. --Noleander (talk) 16:14, 25 October 2012 (UTC)[reply]
On balance. Philisophically I support this – without admin reform, Wikipedia's best hope is to unbundle most functions, and handle them in an easy-come, easy-go manner. In practise too, I can see the benefits. Articles would be a small but noticeable net positive (non-admins actioning spelling and grammar means more time for admins to action the minority of requests which involve judging the consensus of a discussion). Another consideration is fully protected templates: edit requests at protected templates are invariably technical in nature, and at certain times of day such requests can linger for hours. My one concern – although the problem is past its peak and the solution is to crack down on such behavior – is that it's not difficult for an admin to remove rights for reasons not directly relevant to the toolset in question. But on balance, I think this proposal would be a net positive, and again, the practical issue I mention seems to be on the decline. —WFC— _{FL wishlist} 16:20, 25 October 2012 (UTC)[reply]
Support - This would be an excellent tool for WikiGnomes like myself and the thousands of other gnomes out there who are familiar enough to make spelling/grammatical changes, or maintain templates, without breaking anything, but have no particular desire to become Admins. – RobinHood70 ^talk 17:06, 25 October 2012 (UTC)[reply]
Support - no problem, could be a benefit to the Project. Bearian (talk) 17:22, 25 October 2012 (UTC)[reply]
Support rights like this should be unbundled and given to trustworthy editors. Like rollback, they can easily be removed if misused. Valenciano (talk) 19:50, 25 October 2012 (UTC)[reply]
support. an editor may be trustworthy without having the temperament to be an admin, and in many cases good editors don't want to be admins, but would still find this useful. — kwami (talk) 23:14, 25 October 2012 (UTC)[reply]
Support - Having proposed and supported the move before. I don't understand the apprehensiveness surrounding this request, rights are handed out on the basis that the user is a trusted member of the community who has shown the necessary aptitude to take on the responsibilities attached to those rights. The rights which have been proposed for de-bundling are not any different, they convey more "power" to a user, yes, but admins who frequent RfPP never hand out rights liberally and when they make the decision to confer rights upon a user it's because they're satisfied by the user's experience, have seen their edits, how they respond to disputes etc. Is this any different? We shouldn't worry about possible circumvention of policy, that's an assumption of bad faith and not only that, users with visibly chequered edit histories SHOULD BY NO MEANS acquire such rights. James ^{(Talk • Contribs)} • 4:36pm • 06:36, 26 October 2012 (UTC)[reply]
Support - unbundling these parts from the admin package could help both with allowing trusted editors to gain these abilities when needed (without many users worrying that these editors may end up blocking or deleting unnecesarily), as well as serving as a stepping stone towards adminship, where users who want can gain some experience in some highly-trusted areas. And the "tboverride" right is already unbundled for the Account creators. עוד מישהו Od Mishehu 08:32, 26 October 2012 (UTC)[reply]
Support - confirmed to me by many of the comments here, i'm generally pro-unbundling for efficiency reasons. It seems there is consensus not to have editinterface as part of this package Tom B (talk) 12:38, 26 October 2012 (UTC)[reply]
Support – seems useful to me, and I would disagree that creating additional userrights is a bad thing for making Wikipedia more confusing/bureaucratic/etc., since this seems to make the (in my view, unwarranted) assumption that editors need to be able to understand all these different rights before being able to go about their editing. In my view, the Protected Editor (or whatever) policy will only take up the time of those interested in the right, and will not get in anyone else's way. It Is Me Here ^{t / c} 16:57, 28 October 2012 (UTC)[reply]
I'm not very sure where I thought this would be confusing. Do you mind expanding upon what you think I said and where I said it? Legoktm (talk) 18:23, 26 October 2012 (UTC)[reply]
Well, looking at e.g. yours and GenQuest's opposes, I took it that the general rationale behind calling Wikipedia a "lumbering beast" that "needs ... simplification" or "[doesn't] need more [hats]" is that the very existence of so many policies/userrights/etc. is confusing/detrimental to editors/etc. My opinion is that these things would, in fact, not distract editors, as a rule. It Is Me Here ^{t / c} 16:40, 27 October 2012 (UTC)[reply]
I find your assessment of my rationale misleading. My main contention is that we don't need something else to add to the WP:HATSHOP (and extension of what EEMIV said), and what Rjd said about not breaking up the admin group. You try and state that I was talking about something being confusing, which is not what WP:HATSHOP is about. It's about users trying to gain more permissions aka "wear more hats". I would ask that you please remove or strike my name from your opinion or clarify who specifically you are referring to. Legoktm (talk) 13:47, 28 October 2012 (UTC)[reply]
OK, done; sorry I misunderstood your post, although you must understand that my support vote wasn't targeted at you personally, rather at that general point of view, whoever might hold it. It Is Me Here ^{t / c} 16:57, 28 October 2012 (UTC)[reply]
SUPPORT - wish this were available years ago. There does need to be a safety valve though for PPEs who abuse their authority to take sides or act partially during a edit-war or content dispute. Otherwise, great idea. --ColonelHenry (talk) 17:48, 26 October 2012 (UTC)[reply]
Support – A able editor should get the unbundled tool he needs, it's as simple as that. --Chris.urs-o (talk) 18:41, 26 October 2012 (UTC)[reply]
Support – Necessary for people who are not admins, but know a lot about technology.. --Stryn (talk) 19:27, 26 October 2012 (UTC)[reply]
Support useful for non admins who know a lot of certain articles Redalert2fan (talk) 20:03, 26 October 2012 (UTC)[reply]
Support – I see no reason why a trusted user should have to submit themselves to an RfA to be able to edit a protected page or template. For my purposes, I'd love to be able to edit TFL blurbs if the need arises, such as with TFLs related to recent events. If somebody abuses this right, then just take it away—it will probably be easier than stripping a user of admin tools anyway (the real reason that RfA is the way it is). Giants2008 (Talk) 21:20, 26 October 2012 (UTC)[reply]
Support. An excellent and sensible idea that should have been proposed years ago. WikiPuppies _bark ^dig 21:24, 26 October 2012 (UTC)[reply]
Support - This would be actually quite useful for the project. --WhiteWriter^speaks 22:36, 26 October 2012 (UTC)[reply]
Support, despite the caveat with the high-use templates. The right to edit high-use templates like {{citation needed}} is as problematic as editinterface. But still, unbundling the "sysop" blob is a good idea. --Kurepalaku (talk) 17:00, 27 October 2012 (UTC)[reply]
Support, with sidenote, in general it is a good idea, but maybe tboverride should be judged separately from protected editing. Users who only edit after checking whether it is controversial can edit protected pages. However, when creating controversial new pages it is difficult to have a discussion before the page is actually created so more insight from the user is required. PinkShinyRose (talk) 01:57, 28 October 2012 (UTC)[reply]
Lean support, because of caution Support, since this makes the non-sysop and non-bureaucrat edit articles that are more than semi-protected. But caution lies ahead. One, Wikipedia is never safe from vandals. If they vandalized some protected article, that may be an abuse to (upcoming and deliberating) power. Second, the sysop and bureaucrat may call this as unfair since it makes all of the types of pages be open to all, which is called as publicity (except the closures and other things I don't know). TruPepitoM Talk To Me 10:24, 28 October 2012 (UTC)[reply]
Sideline Should this reach a consensus? TruPepitoM Talk To Me 10:24, 28 October 2012 (UTC)[reply]
Support. The current bundling is bad. Unbundling is the way to go. In fact, I hope that in a few years the "administrator" privilege will disappear and there will be only particular permissions. --Amir E. Aharoni (talk) 14:40, 28 October 2012 (UTC)[reply]
Support for move rights. I could give a flying flip about editing a protected page, but dang, moving over redirects with edits is a pain in the butt. Matt Yeager (talk) 19:43, 28 October 2012 (UTC)[reply]
Support but with caution over who the edit rights are given to. Inamos (talk) 21:04, 28 October 2012 (UTC)[reply]
Support. I look forward to the benefits of this right with respect to the reduction of protection requests and the maintenance of templates. I see efficiency and better service to readers. An argument I am not persuaded by is that this will inflate the oft-called hat shop. A company, by comparison, would not refuse to create a useful job position for the reason that it would motivate unqualified applicants. That being said, this ability should be given very carefully, and there should be a reasoned assessment of any editor that applies. NTox · talk 23:25, 28 October 2012 (UTC)[reply]
Support per BDD. Also, if I ever decided to run for admin, this would've been the only real reason I'd have wanted to become one. My interests are in editing, not policing. I too have simply thrown potential edits out the window when I was stopped by a fully protected page. I think this is a great idea, though it would've done me a great deal better back in the days when I had time to actually edit a lot more than I do now. Still, there are others who have filled those shoes. – Kerαunoςcopia^◁_galaxies 03:05, 29 October 2012 (UTC)[reply]
Support, a most sensible, rational, and logical proposal. — Cirt (talk) 03:26, 30 October 2012 (UTC)[reply]
Support. Archaios (talk) 11:52, 30 October 2012 (UTC)[reply]
Support. Of course. The primary argument below is "fix RfA". That's swell and all, but in the real world we all know that's not going to happen... this is a good alternative. Trusilver 19:33, 30 October 2012 (UTC)[reply]
Support cautiously. I think the general wind is blowing towards unbundling for good reason - it is most logical to have a system in which users have access to tools as they need them and when they have the trust and experience to use that specific tool, and allowing non-admins to edit protected page is the next logical step. Not to mention the situation at RfA, both in how it is run and the number of candidates, does not look good, and I'm coming to the conclusion it isn't going to get better any time soon. There is certainly valid need for non-admins to be able to edit protection pages, templates and edit notices being two key areas where this would be highly useful. I'm "cautious" because there is definitely potential for abuse here - this right shouldn't be given out willy nilly and it should be made clear, as was done with rollback, that if the user right is abused by an individual, it will be taken away very quickly. CT Cooper · talk 20:32, 30 October 2012 (UTC)[reply]
Support After reading through the proposal and the arguments on both sides, I think that this is a good idea. • Jesse V.^(talk) 00:48, 31 October 2012 (UTC)[reply]
Support as long as it's clear that the privilege is for maintenance work and will be revoked immediately if used in any way in a dispute. Dicklyon (talk) 02:22, 31 October 2012 (UTC)[reply]
Support Probably one of the more useful admin only features that I could use while editing. AIRcorn (talk) 03:21, 31 October 2012 (UTC)[reply]
Support Why not? Adminship is no big deal, so the tools shouldn't be, and if you can't trust solid content editors to have rights to edit protected pages, what exact big deal has been granted to admins that says they should be able to? A recent run for adminship showed that the community does not care if admins are competent content editors, so they are not necessarily the ones who should have this right to begin with. Expanding it to the competent is useful; gives admins time to do admin things and competent content editors time and tools to do content things. -Fjozk (talk) 05:33, 31 October 2012 (UTC)[reply]
Support This would give a relief to admins. We do have a lot of trustworthy editors. Users should also be able to nominate another editor though. --Rsrikanth05 (talk) 07:30, 31 October 2012 (UTC)[reply]
Support Ziko (talk) 20:05, 31 October 2012 (UTC)[reply]
Support Good option for people who aren't Admins! Davey2010 Talk 00:19, 1 November 2012 (UTC)[reply]
Support -- Agree, it's time to unbundle the tools. RFA is too intensive for most volunteers and many volunteers don't want access to tools like delete or block. --HectorMoffet (talk) 00:47, 1 November 2012 (UTC)[reply]
Support with the caveat expressed by others regarding editinterface, and the condition proposed by Rrius (#40).--JayJasper (talk) 05:15, 1 November 2012 (UTC)[reply]
Support I think that it's a good idea.--Nust2k11 (talk) 11:45, 01 November 2012
Strong support: Its quite irritating to even try to edit an admin protected pages. However, criteria on what user right is to be give, needs to be strengthen up. Should be close to near admin rights. -- ♪Karthik♫ ♪Nadar♫ 09:39, 1 November 2012 (UTC)[reply]
Support There are few things more galling to me than a glaring typo or a tagged sentence that can't be improved without getting permission from someone in the small group who may or may not get around to it that day. Protected articles are typically high-traffic articles often related to current events and controversies. As such, responsible editors should be allowed to edit these articles with the understanding that with rights come responsibilities. These rights should be immediately revoked if an editor makes an inappropriate change to a protected page. Articles with high traffic should be editable by as many responsible users as possible. Jokestress (talk) 20:07, 1 November 2012 (UTC)[reply]
Support Especially since it allows trusted editors to not have to go to an admin to edit fully protected pages and edit notices. Dan653 (talk) 23:52, 1 November 2012 (UTC)[reply]
Support Byelf2007 (talk) 2 November 2012
Support Anything that increases editing efficiency is good. -- talk
Support This would be a good move towards Unbundling the tools, where trusted editors can do specific jobs in the area of their interest. This would eventually heal the big deal currently made about RFA, good and trusted editors can be ease in, into various department. --Ekabhishek^talk 09:53, 2 November 2012 (UTC)[reply]
Conditional support for Protected template editor. Most of the backlogs at CAT:EP are for protected templates, and the templates are usually protected against vandalism, not content disputes like the POV edit wars that we see on articles. Trusted users who have lots of experience editing templates should be able to fulfill edit requests to templates without having to go through an RFA. My impression is that many of the changes to protected templates are non-controversial, but they require a degree of skill that even many admins don't have. The people who do have these skills should be able to use them without becoming admins. ~Adjwilley (talk) 17:13, 2 November 2012 (UTC)[reply]
Yes. Templates are they only real problem area where editing through full protection is frequently appropriate. That's why I still think Pending Changes level 2 for templates is a simpler solution than a new user right.—Kww(talk) 17:20, 2 November 2012 (UTC)[reply]
To reiterate the two points, first one being that there was no consensus to support PC2, that the protection was not designed for template space. Your idea and my idea would both require equally significant software changes to implement.—cyberpower ^Chat_{Limited Access} 17:31, 2 November 2012 (UTC)[reply]
There's no consensus for a new user right either, and I don't see that that will change during this RFC. This one isn't even going to make 70% support. Anything that narrows the scope (such as the Adjwilley's proposal) will make consensus more likely.—Kww(talk) 17:48, 2 November 2012 (UTC)[reply]

(edit conflict)@Kww, I remember that being discussed somewhere, but I don't remember where. (It came up briefly here.) I actually like the idea a lot, and I don't think it would be hard to get approval for that in a couple of months. There is one potential problem, and it is that having Pending Changes protection roughly doubles page loading times on articles. (I tested it myself.) What I haven't tested is if it doubles page loading times when it's transcluded onto articles. If it does, that's a problem, because by PC-protecting a single high-use template, you're slowing down loading times for a lot of pages. Of course, this is a problem that the developers could probably fix, but getting them to fix it is a problem in and of itself :-) ~Adjwilley (talk) 17:55, 2 November 2012 (UTC)[reply]
Support but not for bots Bots should not be able to make edits that normal editors are unable to correct, otherwise this proposal seems entirely reasonable. Monty ₈₄₅ 17:50, 2 November 2012 (UTC)[reply]
Support in principle - but something about the title description "Protected page editor" just sounds kinda too nerdy, like someone from a Gary Larson cartoon, complete with pocket pencil protectors. "Hi, I'm a protected page editor on wikipedia". Til Eulenspiegel /talk/ 19:34, 2 November 2012 (UTC)[reply]
What about calling it "vetted"? Then we can talk about autovetting.. Cesiumfrog (talk) 00:58, 5 November 2012 (UTC)[reply]
Yes, Vetted is much better, well done... Now all we need is consensus for calling it that...! Til Eulenspiegel /talk/ 04:19, 5 November 2012 (UTC)[reply]
Support as locked pages seems to become more and more popular for pages that are in the news and need updates. This class will help keep them fresh and protected. --FeldBum (talk) 19:48, 2 November 2012 (UTC)[reply]
Support I have in mind a bunch of guys who edit a lot but don't want to become admins. -- Magioladitis (talk) 00:17, 3 November 2012 (UTC)[reply]
Support - as RfA is basially failing, let's just unbundle. Claritas § 09:12, 3 November 2012 (UTC)[reply]
Support. There are many, many editors who are trustworthy to do all sorts of stuff, but who have no use for the majority of the admin tools, or who just simply don't want to do "adminny stuff", but who are perfectly trustworthy to be able to edit protected pages, have rollback, etc. Provided that this could be revoked if necessary, there really shouldn't be a problem at all. Of course the WP:INVOLVED thing would have to be just as applicable as it is to use of the admin tools. I think we have a lot of editors who could be trusted to do a lot of stuff; if they were so trusted, then handing out relevant userrights could well reduce the workload on admins. Pesky (talk) 09:39, 3 November 2012 (UTC)[reply]
Support -- Good idea. Reyk _YO! 10:48, 3 November 2012 (UTC)[reply]
Support — very much agreed! -- Infestor ^T • _C 01:09, 4 November 2012 (UTC)[reply]

Support: Because I'm not buying the "Oppose" arguments. What this right is saying is, "you won't vandalize, engage in content disputes, or harm pages in any other way" p b p 05:11, 4 November 2012 (UTC)[reply]
Which is what we require of an admin. If you fulfil those criteria, you should be an admin. Wouldn't it be weird if I said to you, "I trust you to drive a car, but I took out the accelerator and brake pedals anyway, so have fun playing with the gearshift and making broom broom noises"? Samsara (FA • FP) 12:00, 4 November 2012 (UTC)[reply]
First off, admins have a lot more tools than just editing protected pages...three that come to mind are protecting pages, blocking vandals, and performing moves. Second, you're somewhat ignoring the facts of an RfA. Should adminship be granted to everyone who fulfulls the three things I mentioned? Maybe (although a few criteria should be added for the additional duties of an admin I just delineated). But has RfA turned into requiring much higher hurdles than that? Most definitely! Also, I think you car analogy is oversimplified and generally inaccurate p b p 16:31, 4 November 2012 (UTC)[reply]

Support I must say old boy, this is a splendid idea. - John Galt ✉ 07:25, 4 November 2012 (UTC)[reply]

Support An idea whose time has come. Sasata (talk) 17:31, 4 November 2012 (UTC)[reply]

Support. A good and useful proposition. bd2412 T 17:40, 4 November 2012 (UTC)[reply]

Support. I think this would take some of the workload off of the admins shoulders. --bender235 (talk) 19:11, 4 November 2012 (UTC)[reply]

Support because approaches the "everybody can" ideal (while at the same time keeping abuse to an absolute minimum since this is so easily revoked and very arduous to reobtain by a nongenuine contributor) and it finally begins to de-emphasise the admin class (reminded of by the need to lengthily court for bureaucratic blessing on trivially uncontroversial improvements). Cesiumfrog (talk) 00:49, 5 November 2012 (UTC)[reply]

Support - I don't see a huge value in the specific tool: as noted by an admin, it will mostly be useful for infrastructure pages... protected article space pages being edited needs to be very rare indeed. But it will have some value, and I see no risk: if someone abuses the right, then they will have made an edit that is reversed, and they won't have the right any more.User talk:Unfriend12 05:41, 5 November 2012 (UTC)[reply]

Support - As long as 'editinterface' stays completely out. With 'editinterface' you could harvest users' cookie sessions and possibly hijack accounts. This will have the benefit of allowing users to edit protected templates, reducing the backlog. Reaper Eternal (talk) 00:15, 6 November 2012 (UTC)[reply]

Support. There are many trustworthy, capable editors who are not admins. Moreover, a response to a valid request for a change to a protected page/template usually takes a long time, if at all. -- P 1 9 9 ✉ 22:03, 6 November 2012 (UTC)[reply]

Support - As an editor with a fair competence level that has absolutely no interest in adminship, this is something I would be more than happy to do to help out the project. Gtwfan52 (talk) 23:50, 6 November 2012 (UTC)[reply]

Support At the moment, expert & trustworthy editing is considered somewhat orthogonal to the communities implied adminship "criteria". Thus there are plenty of editors who could be trusted with this, that would not at the moment make it through RfA. Thus to those opposing who say "just become an admin", I would encourage them to look through failed RfAs and then claim that not a single one of those editors could be trusted to edit protected pages. I know how frustrating it is to try to rely on protected edit requests, it just slows the whole editing experience down so much that it's not fun. Let's remove barriers like this for highly trusted editors. --99of9 (talk) 01:25, 7 November 2012 (UTC)[reply]

Support There are quite some long term editors and experts that I would trust with this. If editors can be trusted with rollback rights, then editors can also be trusted with this. Many, many pages are protected not because of edit warring or ongoing disputes, but pure out of protection (e.g. thousands and thousands of templates are fully protected just because they are transcluded on many pages), and there are many editors that can be trusted to edit those (even editors with only several thousands of edits), but who I would not trust to block, etc. If they edit to prolong disputes or show to cause damage too often, the bit can easily be retracted. (note: since this is handed out to logged-in editors only, using this bit to edit a protected page resulting in prolonging an edit war would be a self-invitation to an immediate block + removal of the bit ..). Please enable this and hand it out with reasonable liberty. --Beetstra (public) (Dirk Beetstra^{T C} on public computers) 05:37, 7 November 2012 (UTC)[reply]

A little late to the party, I know, but I have been pretty active on another Wiki lately so I haven't been keeping myself updated on the latest developments on Wikipedia. I'd support granting this feature to users who have demonstrated a mentality of collaboration and constructive editing. Kurtis (talk) 07:59, 7 November 2012 (UTC)[reply]

Support I may be joining the discussion late, but first things first, I need to know that editinterface has been removed from the package. This vote changes to a strong oppose if it has not been. As it stands by discussion, I think most of the dick banging here is about people worried unbundling of admin tools creates a fractured community where some editors have more powers than others. I think this is a non-concern, but some things like the AWB checkpage would need to change how they work to prevent editprotected editors from invalidly adding names to the list. While I myself will probably never need the tool, it doesn't mean other trustworthy editors shouldn't get access when working with templates. Like all user rights, rights being used in the technical and not entitlement sense, they can be revoked at a moments notice. T.I.M^(Contact) 21:26, 7 November 2012 (UTC)[reply]

Yes— Preceding unsigned comment added by Risingrain (talk • contribs)

Support After reading the proposal it seems like a good idea. §h₳un 9∞76 01:13, 9 November 2012 (UTC)[reply]

Support –sumone10154^(talk) 08:38, 9 November 2012 (UTC)[reply]

New user right proposal - Oppose
Not with editinterface rights. -- WOSlinker (talk) 15:16, 12 October 2012 (UTC)[reply]
Would you support if edit interface wasn't in there?—cyberpower ^Chat_{Limited Access} 15:31, 12 October 2012 (UTC)[reply]

The edit interface has been removed from the package. I can see where you guys are coming from though.—cyberpower ^Chat_{Limited Access} 17:40, 12 October 2012 (UTC)[reply]
Yes, without editinterface, would support. -- WOSlinker (talk) 19:59, 12 October 2012 (UTC)[reply]
He removed the editinterface a little earlier. Kumioko (talk) 20:05, 12 October 2012 (UTC)[reply]
Ok, moved to support. -- WOSlinker (talk) 21:14, 12 October 2012 (UTC)[reply]
Per WOSlinker. Editinterface is...a bit too much. I can support something with only editprotected and tboverride, if it is made clear that this right is not to be used to edit pages fully protected due to a content dispute. I think that for those pages the edit requests should still be serviced by admins only. T. Canens (talk) 16:16, 12 October 2012 (UTC)[reply]
"is not to be used to edit pages fully protected due to a content dispute." I guess we don't need to make clear that. If a user with this right uses it for content dispute, then any admin can revoke the right, just as rollback or reviewer. — ΛΧΣ21™ 17:31, 12 October 2012 (UTC)[reply]

The edit interface has been removed from the package. I can see where you guys are coming from though.—cyberpower ^Chat_{Limited Access} 17:40, 12 October 2012 (UTC)[reply]

Editinterface opens too much opportunity for mischief. I would support a package with editprotected and tboverride only. Anomie ⚔ 17:26, 12 October 2012 (UTC)[reply]
The edit interface has been removed from the package. I can see where you guys are coming from though.—cyberpower ^Chat_{Limited Access} 17:40, 12 October 2012 (UTC)[reply]
Moving to support now. BTW, is is really necessary for your signature to include two linebreaks? Anomie ⚔ 02:39, 13 October 2012 (UTC)[reply]
Oppose (with or without the "editinterface" permission included). As noted in the past, anyone who can be trusted to not abuse the ability to edit protected pages can be trusted with all of the administrative tools. This type of unbundling would worsen the RfA problem by reinforcing the perception that adminship is a "big deal". —David Levy 17:30, 12 October 2012 (UTC)[reply]
That's clearly nonsense. No wonder things go from bad to worse here. Malleus Fatuorum 17:36, 12 October 2012 (UTC)[reply]
Perhaps an explanation of which comment(s) you dispute — and why — would change my mind. Simply labeling my opinions "nonsense" definitely won't (nor will your pointy opposition to the proposal). —David Levy 17:47, 12 October 2012 (UTC)[reply]
I have no intention of trying to change anyone's mind about anything to do with unbundling user rights, as that would clearly be an exercise in futility. My comment specifically addresses your naive belief that anyone who can be trusted to edit protected pages would be trusted to become an administrator. Malleus Fatuorum 18:01, 12 October 2012 (UTC)[reply]
Then you misinterpreted my comment. My point is that the level of trust required should be the same. RfA is broken because segments of the community have begun imposing unreasonable demands (instead of simply granting adminship to trustworthy editors, as was customary not long ago). This type of unbundling would seemingly validate their approach. —David Levy 18:12, 12 October 2012 (UTC)[reply]

Also see my comments below in the discussion. The RFA process is a nightmare that many don't wish to go through. Kumioko (talk) 18:05, 12 October 2012 (UTC)[reply]
Agreed. And this type of unbundling would firmly cement it as such. —David Levy 18:12, 12 October 2012 (UTC)[reply]
I don't mean to get too far off topic here but, everyone including you it seems agrees the RFA process is crap, but yet, you proceed to try and justify its existence by opposing a process that would make it less painful for users to get the tools to do more to help the pedia? I'm sorry for the rather blunt reply but that makes no damn sense. Kumioko (talk) 18:18, 12 October 2012 (UTC)[reply]
My point is that RfA shouldn't be painful (and wasn't in the past). The process itself isn't inherently "crap"; certain segments of the community have lost sight of how it's supposed to operate.
Workarounds such as this one shouldn't be necessary. Editors trustworthy enough to be granted a hypothetical "protected page editor" permission should simply be made administrators. This proposal's implementation would amount to a formal determination to the contrary — a declaration that the onerous demands making RfA "a nightmare" are justified and should continue. —David Levy 18:44, 12 October 2012 (UTC)[reply]
Actually, on the contrary, this should make RfA easier by making it less a step-up in permissions.--Jasper Deng (talk) 19:46, 12 October 2012 (UTC)[reply]
In other words, it would promote a culture in which trustworthy editors are expected to "ascend the ranks", gradually taking on additional permissions as prerequisites to adminship. That isn't what I call making things "easier". —David Levy 20:26, 12 October 2012 (UTC)[reply]
I think the flaw in the reasoning here is the assumption that adminship is only about trustworthiness. It isn't. It's also about suitability, and there are plenty of editors who are unsuitable for adminship for various reasons unrelated to trustworthiness, but who would have my full trust with this proposed new right. -- Boing! said Zebedee (talk) 07:49, 15 October 2012 (UTC)[reply]
I'm referring to the community's trust that a user will behave appropriately, not merely that he/she is acting in good faith (which I assume is what you mean).
I understand the logic behind trusting editors to handle certain tools and not others, but I disagree that access to this particular tool (or any tool that could be abused to gain an insuperable advantage in a dispute) requires a lower level of trust. —David Levy 14:23, 15 October 2012 (UTC)[reply]
One could mandate a 0-RR policy for edits prior to protection, and 1-RR after protection, except for removing vandalism, libel, BLP and COPYVIO. That means nothing in the page before it was protected can be reverted while it is under protection (as usual, it can be copyedited, moved around and so on). New stuff added later can be reverted once per editor. Incidentally, no we don't vet admins for editing expertise, which is important for those who want to edit protected pages. Right now, most admins rarely edit protected pages directly, preferring to pull uncontroversial things in from the talk page. That is a suboptimal way to get things done; it is quite hard to ask for, say a cleanup of citations to use full ones, on the talk page. You are right admins currently have the power to edit a protected page; they use that power only indirectly, making a protected page effectively locked for many kinds of edits. Churn and change (talk) 01:09, 25 October 2012 (UTC)[reply]

Oppose yet another attempt to erode the priestly status of administrators by unbundling any user rights. In fact I'd go so far as to say that only administrators should be trusted to edit Wikipedia at all. Malleus Fatuorum 17:39, 12 October 2012 (UTC)[reply]
it is not an attempt to erode anything. It is an attempt to assist in the technical aspect of Wikipedia. PS, the comment at RfA you made towards me was unacceptable and appreciate you not doing that again.—cyberpower ^Chat_{Limited Access} 17:44, 12 October 2012 (UTC)[reply]
I have no idea what you're talking about, or why you would feel it appropriate to raise your objection here. Malleus Fatuorum 18:01, 12 October 2012 (UTC)[reply]
I'll discuss on your talk because it'd be inappropriate here as you mentioned.—cyberpower ^Chat_Offline 18:11, 12 October 2012 (UTC)[reply]

Sorry, but anybody trusted to edit the interface should be trusted to pass RfA first. PeterSymonds (talk) 17:46, 12 October 2012 (UTC)[reply]
The edit interface has been removed from the package.—cyberpower ^Chat_{Limited Access} 17:48, 12 October 2012 (UTC)[reply]

Oppose Let's wait for pending changes. The use of PC will mean that the general level of article protection can drop. Instead of full protection, we will be able to have full-protection with PC, which will speed up approvals of things which would otherwise require {{edit protected}} requests. Same with semi-protection. Let's hold on and wait to see how PC works out. —Tom Morris (talk) 18:15, 12 October 2012 (UTC)[reply]
PC level 2 (full protection to most) has been outlawed via RfC. What about title blacklists?—cyberpower ^Chat_Offline 18:20, 12 October 2012 (UTC)[reply]

A big part of {{editprotected}} requests involve fully-protected templates, and they often take a long time because most admins are unwilling to touch complicated templates with a ten-foot pole (and I can't really blame them either). PC is not going to change those. Even in mainspace, very few, if any, full protections will be affected by PC. T. Canens (talk) 02:27, 13 October 2012 (UTC)[reply]

Oppose There are far too many people who completely don't understand what is necessary to edit protected pages. While this would hopefully only be given to those who understood the purpose, I think its use is minimal. Ryan Vesey 18:40, 12 October 2012 (UTC)[reply]
I'm adding an addendum. If this is to go through a trial program, I would support considering the backlog at Category:Wikipedia protected edit requests. Ryan Vesey 21:22, 23 October 2012 (UTC)[reply]
It is easy to force pages into full protection mode; somebody did it to, of all the articles, Cat Creek, Montana. That is because the previous level of protection, the auto-confirmed level, is easy to get past. Once a page is fully protected, practically all direct editing ceases; admins almost never directly edit the page, and just pull in only the most uncontroversial stuff from the talk page. Even something such as copy-editing is quite hard to type up on a talk page, and so effectively the article gets frozen. Churn and change (talk) 01:25, 25 October 2012 (UTC)[reply]
This proposal wouldn't affect much of that. As I said, the ability to edit fully protected pages does not give the ability to make content edits without first receiving consensus. Copy-editing is minor and would be allowed, but to allow other editing, the full protection policy would need to be changed. Ryan Vesey 01:35, 25 October 2012 (UTC)[reply]
The proposal changes the policy anyway since the first line of WP:FULL is: "A fully protected page can be edited only by administrators." The policy does allow "uncontroversial" changes (see WP:PREFER first para, last sentence), and I assume that includes content editing too (in other words, assume content is uncontroversial until it gets reverted—a 1RR rule across editors for content added after protection, which means if something is challenged, it becomes controversial). I admit administrators today do not use that mechanism on a protected page. Churn and change (talk) 01:50, 25 October 2012 (UTC)[reply]

Actually, no, the last few occurences of Cat Creek vandalism had happened after the protection had expired; the last one happened exactly one day after the three-month period of semi-protection expired. So semi-protection was effective there, we just had to turn it on. The full protection was likely overkill in that case. --Joy [shallot] (talk) 09:43, 25 October 2012 (UTC)[reply]
Since the autoconfirm bar is just 4 days and 10 edits, User:Montanalions would have been autoconfirmed; User:Lionsincatcreek would have been autoconfirmed, and so on. Even if they weren't autoconfirmed at the time of a semi-protection, it would have been a simple matter to get there, and you can see from the almost-dummy edits that precisely was the intent. Cat Creek is a place with barely enough people, all put together, for even an edit war on Wikipedia. May be my view is colored by coming across a low-profile article needing full page protection in my just 3 months on Wikipedia. May be that is a statistical aberration. But I can't assume that. And I am fairly certain general editing (not just edit-warring) drops on a fully protected page. I admit it is unclear to me whether this proposal fixes that (how we define an "uncontroversial" change allowed on an FP page). Churn and change (talk) 15:47, 25 October 2012 (UTC)[reply]

Oppose Waiting for PC is a better idea. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 03:54, 13 October 2012 (UTC)[reply]
Whats PC? Kumioko (talk) 03:57, 13 October 2012 (UTC)[reply]
PC=Pending changes also known as "flagged revisions". In a nutshell, edits on pages with PC protection don't "go live" until after they've been reviewed by a "trusted" user. ~Adjwilley (talk) 17:12, 13 October 2012 (UTC)[reply]
Thank you for that explanation. I had forgotten about that. I have to be honest I initially supported Pending changes but I have a mixed feeling about it. To me its really no different than Protecting the page's now. We have thousands of templates and articles that are protected and only trusted (in this case admins) can edit them. Many of which don't really need protecting except an assumption of bad faith that someone "might" vandalize a template and that change would be visible across a large number of articles or site wide. Pending changes will compound that problem to the Nth degree. Now we will have massive amounts of content that are protected and require a trusted editor to implement the change bogging down the process and causing more and more content to be out of date. It already often takes several days for an edit request to go answered. I envision this will make things much much much worse. I envision that PC will soon be labelled as Permenantly Crippled, Permenently Crappy, etc. What we need is to get back to trusting our editors, the ones who devote hours and hours to the project and then are told they can't be trusted and are forced to ask for their edits to be implemented much like the little Orphan Olliver asking "Thank you sir, may I have another"? Kumioko (talk) 21:24, 13 October 2012 (UTC)[reply]

Oppose First of all, 'Autopatrolled' is not a user 'right'. It give the user no additional editing tools or control over Wikipedia content. Editing the interface requires a high degree of trust, any lowering of the bar for this would almost certainly invite abuse. The WMF's answer to some suggestions of creating additional user rights was that 'What is not wanted is a whole priesthood of gatekeepers' . Unbundling of the tools is a perennial discussion, and this is the fourth one this year. Finally, the 'priestly' admins would probably not be overly enthusiastic at having to administer additional requests at PERM, where the majority of requests are denied anyway.Kudpung กุดผึ้ง (talk) 04:08, 13 October 2012 (UTC)[reply]
The edit interface right has been removed from the bundle. This user group would not allow access to the interface pages.—cyberpower ^Chat_Offline 04:18, 13 October 2012 (UTC)[reply]

(in this context any permission is referred to as a "user right", per the technical use of it.)--Jasper Deng (talk) 04:22, 13 October 2012 (UTC)[reply]

Oppose unbundling, as having several tools at hand is the best way to approach the complex problems that arise here. The whole suite or nothing. Binksternet (talk) 02:47, 15 October 2012 (UTC)[reply]

Oppose - The interface is not a mild thing. that aside, I'm not convinced that "admin-granted" user-rights have sufficient oversight even for the ones we have now, much less to add more to the list. - jc37 02:56, 15 October 2012 (UTC)[reply]
I agree that there isn't much monitoring, but that's an argument that could be made for applying pending changes to all article edits, and requiring arbcom approval of all admin actions. At least with unbundled rights, once a problem is noticed it can be dealt with relatively easily. Even if the decision on whether or not to remove the rights is taken via discussion at ANI, that's a hundred times more straightforward than considering admin misuse of the same tool via a full-blown Arbcom case. —WFC— _{FL wishlist} 17:03, 25 October 2012 (UTC)[reply]

Oppose - this won't fix anything. I'm completely with David Levy on this, with regards to his comments, below, on the need to fix the RfA system instead. — Hex (❝?!❞) 07:38, 15 October 2012 (UTC)[reply]
This wasn't an intent to fix RfA. I've got different ideas formulating in my minds for that. This is an intent to add productivity to Wikipedia and let admins focus on more admin areas and let non-admins handle the endless edit requests. Besides there are automated accounts that could really use the bit, such as mine.—cyberpower ^Chat_{Limited Access} 12:48, 15 October 2012 (UTC)[reply]

Oppose - doesn't address the issue, which is over protection of pages. Nobody Ent 15:27, 23 October 2012 (UTC)[reply]
Yes, with the proposal, the bar for page protection should be higher, not lower. This is to ensure we don't wind up protecting pages to make editing cozier. Policy already does say at WP:NO-PREEMPT: "Pre-emptive full protection of articles is contrary to the open nature of Wikipedia." We could address this by providing more precise guidelines for page protection (vandalism from auto-confirmed users, edit warring by four or more users, and so on). Churn and change (talk) 01:55, 25 October 2012 (UTC)[reply]

Utterly Opposed to further unbundling of the tools. There is too much of a risk of users with limited rights sticking to what they can do rather than looking for the correct solution if that involves a tool they do not hold. Spartaz ^Humbug! 16:43, 23 October 2012 (UTC)[reply]

Oppose per Malleus and Ryan, as seen above. TBr and ley 20:20, 23 October 2012 (UTC)[reply]
You realize you are citing a sarcastic oppose-that-wasn't-really-oppose right? Gigs (talk) 20:26, 23 October 2012 (UTC)[reply]

Provisionally oppose, appears to be a solution in search of a problem until more convincing data is given.--Tznkai (talk) 21:19, 23 October 2012 (UTC)[reply]

Oppose, mainly per Ryan and Spartaz above. People that can be trusted with this ability, are usually also be trusted to be admins. This proposal seems to aim to solve a problem that does not really exit - most such edit requests are within disputes and the number of such requests is low anyway - by creating a new userright that most people won't need. I cannot imagine that there is any editor who can be trusted with this tool that is not already qualified for one of the existing rights we created over the years (rollbacker, autoreviewer etc.) If the community wants to create an admin light™ usergroup that has some but not all of the tools admins have, then we should do that instead. Of course, I also think that such a usergroup is wrong and such people should just become admins, so the solution is to promote more admins - although of course that might mean "fixing" RFA (whatever that means - point is, side discussions such as this one will not fix the underlying problem that too few qualified editors can (or want to!) get those tools through RFA). As for arguments regarding automated accounts: adminbots exist just fine so if you have a bot that needs that right, it can have it already without this proposal. Regards So Why 21:25, 23 October 2012 (UTC)[reply]
When I go to RfA, I look at whether the candidate has the experience to use the block button appropriately in difficult cases, and how suited they would be to closing RfCs and AfDs. It's rare that I support unless the candidate ticks those boxes. This is a fairly common view, albeit other users express a similar feeling in a very different way (focussing on a GA/FA/FL/DYK count rather than looking at the candidate's broader content experience). In a nutshell, there are a lot of non-admins who would not make good admins under the current system, but are well suited to technical work, particularly in the knowledge that the tools are only there for as long as they are used appropriately. —WFC— _{FL wishlist} 17:03, 25 October 2012 (UTC)[reply]

Oppose - I think this is pushing the "editing rights hierarchy" a little too far while giving admins yet another way that they have to judge member performance and in the end will only serve to make things more complicated. My main reason for opposition is seeing a time in the not-so-distant future, if this proposal is passed, when another new level of protection is added in order to keep the Protected Page Editor and Admins separate once again. On a hierarchical edit-protection scale, this is how I see things:
◌ Current system: Anon < User < Admin

◌ This proposal: Anon < User < PPE = Admin

◌ But eventually: Anon < User < PPE < Admin

— CobraWiki ^{( jabber | stuff )} 05:55, 24 October 2012 (UTC)[reply]

Well, today we have auto-confirmed, rollbackers, reviewers, autopatrollers, filemovers, sysops, oversighters, abusefitters, checkusers, crats, stewards, founder, in many combinations. Each combination has a different set of editing rights. There isn't any clear hierarchy this proposal worsens. Churn and change (talk) 02:06, 25 October 2012 (UTC)[reply]
Indeed. Of those rights only four are relevant to this discussion. File mover is a technical hack largely reserved for users who are admins on commons but not en.wiki. Autopatroller, reviewer and rollbacker were created because the risk of the tasks was deemed acceptably low, and the alternative method of dealing with the workload would have been to lower admin standards. —WFC— _{FL wishlist} 17:03, 25 October 2012 (UTC)[reply]

Oppose - I don't see a need for another stratum of user permissions. --EEMIV (talk) 15:37, 24 October 2012 (UTC)[reply]

Oppose - Making adminship further away from "regular" users will only excaerbate the most problematic issues of the entire project. Pending Changes offers a similiar, more elegant solution, uses a system already in place on other projects, and still allows for Admin-only protection. Achowat (talk) 17:43, 24 October 2012 (UTC)[reply]
Are you aware that pending changes level 2 is dead for now? Pending changes level 1 will offer nothing even similar to full protection at all. Gigs (talk) 23:38, 24 October 2012 (UTC)[reply]
Yes, I am aware of that. However, implementing Pending Changes does not prevent us from using full protection if the situation warrants it, in the same way creating this usergroup would. Achowat (talk) 15:54, 25 October 2012 (UTC)[reply]

Strong oppose – Is there any logic to this proposal? How are we going to determine who is entitled to such a user right? Shall we implement "levels of trustworthiness" to decide who isn't fit for becoming an admin but is suited for becoming a "protected page editor"? This makes no sense. Toccata quarta (talk) 20:48, 24 October 2012 (UTC)[reply]
Why not? We already have anonymous, autoconfirmed, rollbacker, articlecreator, etc. You are more trusted than an IP or a very new user, since you are autoconfirmed. Gigs (talk) 23:34, 24 October 2012 (UTC)[reply]

Oppose - as per reasoning provided by David Levy and Kumioko. As to the (what appears to me to be) sarcasm expressed here by Malleus Fatuorum, I respond with "as an initiate one day I hope to join the priesthood with my sphincter still intact." This proposal adds another level of bureaucracy to the community that does not address the underlying problems. Garth of the Forest (talk) 00:01, 25 October 2012 (UTC)[reply]
Your oppose rationale makes no sense.—cyberpower _Online^{Trick or Treat} 00:06, 25 October 2012 (UTC)[reply]

Oppose Editing protected pages isn't a big problem and this belongs bundled in the admin tools. A solution seeking a problem. Not important enough of a problem to warrant yet another user right. Someone should be judged trustworthy enough to be an admin by the community to be extended this right or else there will be drama. This user right is beyond the discretion that should be extended to admins. Royalbroil 02:34, 25 October 2012 (UTC)[reply]

Please stop breaking up the admin group...Just fix RfA. I say this every time these pops up. Sorry. Rjd0060 (talk) 16:13, 25 October 2012 (UTC)[reply]
Some how, we can never gain consensuson any improvement for the RFA system, and yet it's clearly broken. עוד מישהו Od Mishehu 20:09, 29 October 2012 (UTC)[reply]

Strong Oppose Been there, done that. The idea of having people with partial admin powers is a recipe for disaster.--Siddhartha Ghai (talk) 19:18, 25 October 2012 (UTC)[reply]
What's a recipe for disaster on one Wikipedia may just happen to be what an other Wikipedia needs. עוד מישהו Od Mishehu 20:11, 29 October 2012 (UTC)[reply]

Strong Oppose per Malleus. I note that approximately two-thirds of those opposing (above) are sysops. The "Please stop breaking up the admin group" argument smacks of the sort of them-vs-us attitude that is contributing such a hostile atmosphere at RfAs. It's time for these opposers to see that the change may be a small dilution of their powers, but overall can only help those with mops by adding to the ranks people who can draw the water and help cut the grass without giving them access to the weedkiller, as it were. -- Ohconfucius ^{ping / poke} 02:17, 26 October 2012 (UTC)[reply]
Actually, about 1 in 2 of the oppose votes are from admins (21/44), while about 1 in 3 of the support votes are (15/44). Some of the difference here may stem from the wish of some non-admions to have more rights they could gain from this proposal (many of the supoports, as well as many of the opposes, come from these rollbackers/file movers/account creators/etc), as well as from some admins thinking in the us vs. them. עוד מישהו Od Mishehu 20:06, 29 October 2012 (UTC)[reply]

Oppose per EEMIV above. Wikipedia is already a top-heavy, lumbering beast that needs more simplification, not more bureaucracy. GenQuest (talk) 04:19, 26 October 2012 (UTC)[reply]

Oppose per EEMIV and Rjd. We already have a huge enough WP:HATSHOP, we don't need more. It's interesting to note that at the beginning it was believed protection would be used extremely rarely, yet today we have...well, a lot of protected pages. Legoktm (talk) 04:28, 26 October 2012 (UTC)[reply]

Oppose. We don't need more stratification of powers in the encyclopedia anyone can edit. This proposal seeks to address a number of perceived problems, but these need to be addressed directly and specifically, not in a roundabout way that I suspect would have unforeseen consequences. Cynwolfe (talk) 17:08, 26 October 2012 (UTC)[reply]

After considerable thought, Oppose for several reasons, well enumerated above. NOT a buro... If trusted enough for that, why not run for admin? ... Pending changes in works... What does this solve? I see negative effect from this overall. KillerChihuahua^?!? 17:10, 26 October 2012 (UTC)[reply]

Oppose on the basis that it's unecessary. What I've seen a lot of, is semi-protection of pages to keep out the bored schoolkids and annonymous cowards. I can't recall any time in my last 40,000 edits that I needed to change a fully protected page - just how common a problem is this and is the extra complexity and strafication of users worthwhile? --Wtshymanski (talk) 17:21, 26 October 2012 (UTC)[reply]

Oppose. Unnecessary added layer of complexity.--Bbb23 (talk) 18:19, 26 October 2012 (UTC)[reply]

Oppose. If a page is fully protected, there is a reason. One has to ask on the talk page to make an edit, and get either consensus or an admin to make the change. If there is an emergency (BLP?), go to ANI or the BLP Noticeboard. Having a class of users that can edit such pages but who are not admins is just asking for trouble, such as an asymmetric wheel war. Given that we do not have enough admins, anybody who is trustworthy enough to be "tboverride, editprotected" should be nominated for admin right now. Speciate (talk) 21:27, 26 October 2012 (UTC)[reply]
And what about complicated templates protected automatically under WP:HRT? - Floydian ^τ _¢ 05:34, 30 October 2012 (UTC)[reply]

Oppose forking of admin rights. If someone is so trustworthy that we want to let them edit fully protected articles, there's no harm in also giving them the delete and block buttons. Der yck C. 17:03, 27 October 2012 (UTC)[reply]

Oppose, something about stratification, hat collecting, trust, and whatnot, but it also shouldn't make a difference if editinterface is included or not. There are templates that are protected precisely because they are used in part of the interface, and just as much damage can be done with the wrong template even without that as with any js... pages fully protected for a reason, and to edit them requires trust. We trust our admins. No need to complicate things. -— Isarra ༆ 20:44, 27 October 2012 (UTC)[reply]

Oppose WP:RFA. One problem at a time, please. Ajraddatz (Talk) 21:21, 27 October 2012 (UTC)[reply]
We started talking seriously about RfA reform 18 months ago. Since then change has been minimal and largely superficial. The promotion rate has significantly slowed, and we have lost at least 100 active administrators since Jimbo's oft-quoted "horrible and broken process" remark (we're at 668 according to Wikipedia:List of administrators, and were hovering slightly below 800 in March 2011).
While not wishing to tar the entire usergroup with the same brush, a significant majority of admins oppose any proposal which would change the nature of adminship. A similarly large majority of community members see the status quo as less bad than an explicit two-tier adminship system, as this would replace what seems to be a hierarchy with something that definitely is a hierarchy. The other main proposals for RfA reform can be summarised as "create rules which force people to be nicer during an RfA" and "let's lower the RfA threshold", neither of which directly deal with the reasons behind people's caution about promoting new admins.
Unless someone comes up with a magic bullet, unbundling is the only realistic way of ensuring that a lack of RfA reform will not cause the system to creak under its own weight. In response to Speciate's comment above, I'd trust several non-admins on both sides of this debate to use this tool appropriately 100% of the time. On the other hand, I shudder to think what some of them would do with the block button, or the ability to close contentious, policy-related RfCs. —WFC— _{FL wishlist} 22:36, 27 October 2012 (UTC)[reply]
Actually, we started talking seriously about RFA reform more than four years ago. —Kusma (t·c) 19:00, 28 October 2012 (UTC)[reply]

Oppose I find the argument for doing this utterly unconvincing. Full protection of actual articles is usually brief and is done to stop edit warring. It kind of defeats the purpose of protection to have a large group of users who are free to ignore it. Not the worst proposal for unbundling I have seen, but I just don't see a pressing need for it and it would inevitably become another unofficial RFA prerequisite, which we certainly don't need. Beeblebrox (talk) 23:35, 27 October 2012 (UTC)[reply]
Articles aren't the only thing that receive full protection.—cyberpower _Online^{Trick or Treat} 00:58, 28 October 2012 (UTC)[reply]
Indeed. Templates used on more than a few hundred articles (read: any complicated template) are automatically protected per WP:HRT. - Floydian ^τ _¢ 05:34, 30 October 2012 (UTC)[reply]

Oppose - I agree with User:Deryck Chan. Tony the Marine (talk) 01:33, 28 October 2012 (UTC)[reply]

Oppose Too many articles will be put on indefinite protection and will get owned by very small groups of eds. NPOV will vanish.OrangesRyellow (talk) 10:18, 28 October 2012 (UTC)[reply]
Whoa... that is a stretch... How would allowing some users to edit protected pages result in more pages being protected? - Floydian ^τ _¢ 05:34, 30 October 2012 (UTC)[reply]
The connection is that for some admins, the more users can edit the page the more easily they'll protect it. Just like we semi-protect pages more easily than we would have protected them before semi-protection was available, the same possibility going on here is the worry of some users. עוד מישהו Od Mishehu 06:06, 30 October 2012 (UTC)[reply]
But we have a declining population of users that can protect pages (admins) and an ever increasing number of pages being protected. There is no correlation. - Floydian ^τ _¢ 06:15, 30 October 2012 (UTC)[reply]
That such a problem already exists justifies measures to counter excessive page protection, not to create a workaround that validates and encourages it. —David Levy 06:36, 30 October 2012 (UTC)[reply]
But that's not the purpose of this. The purpose is to allow trusted users to modify whatever pages have been subjected to that overzealous protection, as well as templates that are automatically protected per WP:HRT. The minion cannot control the master. - Floydian ^τ _¢ 16:34, 1 November 2012 (UTC)[reply]
You wrote "But that's not the purpose of this." and then described the same purpose, so I suspect that you misunderstood my comment.
My point is that the solution is to stop "overzealous protection" from occurring, not to give certain users a special workaround (thereby legitimizing overzealous protection in the minds of those responsible for it).
I find the "high-risk template" argument uncompelling, given the fact that edits thereto are relatively uncommon and often should be discussed beforehand (and if such a permission were desirable, it could be confined to the template namespace). —David Levy 20:34, 1 November 2012 (UTC)[reply]
Full protection occurs when guarding below the level of auto-confirmed users is not good enough. Considering how easy it is to be auto-confirmed (4 days and 10 edits?) and considering how easy it is to create undetectable sock accounts (range blocks against account creation are even more disruptive than page protection), full protection is not all that surprising. The edit-protected right protects against both vandalism and against overzealous protection. Your idea that all these issues—overzealous protection, RFAs that allow in admins unwilling to use the 'mop' and want only the editing tools—should be fixed directly is unrealistic. Your assertion this worsens those issues is unfounded; RFAs may well become more civil if fewer new rights exist in the bundle. Churn and change (talk) 15:43, 7 November 2012 (UTC)[reply]

Oppose Creates more hierarchy without significant benefit. wctaiwan (talk) 16:11, 28 October 2012 (UTC)[reply]

Oppose, everyone who can be trusted with editprotected can be trusted with adminship. —Kusma (t·c) 19:00, 28 October 2012 (UTC)[reply]

Oppose without a policy that specifically defines how these user rights can and can't be used, and what criteria must be fulfilled before an editor can receive these user rights. If this goes through, half of the active non-admin editors will put in a request on the first day. Without clear policies in place for who can get these rights and what they are allowed to do with them, it would be a bad idea and probably would create a huge mess. ‑Scottywong | prattle _ 14:16, 29 October 2012 (UTC)[reply]
Well of course there would need to be a policy but it wouldn't make sense to propose one if the right does not yet exist. Don't you agree? If this proposal passes there will be a follow up RfC to establish policy and criteria for applying and receiving these rights.—cyberpower _Online^{Trick or Treat} 13:03, 31 October 2012 (UTC)[reply]

Oppose Fix RFA if it's broken. Don't implement this simply as a workaround. --Shanes (talk) 15:22, 29 October 2012 (UTC)[reply]
Almost two years of trying to fix it and almost two years of discussion and how far have we gotten to fixing it? Absolutely nowhere. It's time for something else. This proposal is primarily geared toward allowing users to productively edit fully protected pages, be it maintenance on highly visible templates, or serving edit requests on temporarily fully protected articles or creating a page that has a title blacklist for whatever reason. It occurred to me afterwards that this also can significantly or insignificantly alter the way RfA operates.—cyberpower _Online^{Trick or Treat} 13:03, 31 October 2012 (UTC)[reply]

'Wikipedia is too damn complicated already. Just as with pending changes, I see no pressing need for another elaborate mechanism. I sometimes process protected page edit requests, and I've never seen a backlog so huge that admins couldn't handle it. Sandstein 15:23, 29 October 2012 (UTC)[reply]

Opposse - I really didn't see the point of needing this right, but before I commented I wanted to approach this from a NPOV and try this process. I looked and looked and looked (took forever) to find a fully protected article. I found one and made a edit request for this article here and an administrator responded within 10 hours, which is responsible. There isn't many cases of vandalism that is protected and when it is, I bet someone could jump in IRC and have an administrator remove it [or leave a message on the talk page of an active admin who has edited in the last few minutes (Recent Changes).] Unneeded. In my mind, the right will just cause a greater attraction for hat collectors and from what I have seen, rarely used. "Fix RFA if it's broken. Don't implement this simply as a workaround." - Shanes. -- Cheers, Riley Huntley 16:37, 29 October 2012 (UTC)[reply]
So you are saying that if I want to make an edit to a complicated template, I have to wait 10 hours... Now say that the edit inadvertently messes up the template on a select few pages, not accounted for in a sandbox (complicated template, lots of possibilities). I can look and spot the single } that's screwing everything up. Guess what?!? Another 10 hours. - Floydian ^τ _¢ 05:34, 30 October 2012 (UTC)[reply]
No. We're saying that if you can be trusted to edit pages (including templates) requiring full protection, you should become an administrator. Perhaps the current atmosphere at RfA doesn't allow that. That's why we need to fix it, not reinforce it with changes like the one proposed here. —David Levy 05:57, 30 October 2012 (UTC)[reply]
It may even be a possibility that the only way to fix RfA is to dismantle it and handle userrights on an individual basis, when users demonstrate trust and understanding of the tasks they wish to undertake. - Floydian ^τ _¢ 06:15, 30 October 2012 (UTC)[reply]
Please see Wikipedia talk:Requests for adminship#Unbundling the tools for detailed discussion of why that's infeasible. —David Levy 06:36, 30 October 2012 (UTC)[reply]

Oppose. I will concede that currently too many pages are full-protected that could just as easily be semi-protected (for example, a large number of infobox templates are unecessarily protected). But other than those pages, full protection in article space usually accompanies particularly severe edit wars, which is actually the kind of circumstance adminship was created to handle. The only other issue is main page context, for which requests for changes are generally responded to very quickly. Chick Bowen 19:52, 29 October 2012 (UTC)[reply]

Blatant OH MY *#@()$* GOD oppose What the hell is Wikipedia becoming? Wikipedia was founded on the absolutely insane principle that random people coming together to a common purpose could build something extraordinary. Not anymore. Now every new comer is a *()#$ idiot who can't tie their own shoelaces much less be trusted with editing something. Wikipedia editorship is declining, and you want to create yet another class of users to protect the project? Look at the damn main page. It says "the free encyclopedia that anyone can edit." Either hold to that and reduce the sheer overload of protected pages to those actively needing protection against active threats or change the damn introduction to "The sort of free encyclopedia that only trusted users can edit". Insanity is what this is. Sheer, bald faced insanity; barking at the moon with a cat stuck in your hair insanity. --Hammersoft (talk) 02:40, 30 October 2012 (UTC)[reply]
Huh? The proposal is not about how many or which pages are protected. The proposal is about allowing trusted users, instead of just admins, to have the ability to edit protected pages. Don't trip on those shoelaces. - Floydian ^τ _¢ 05:20, 30 October 2012 (UTC)[reply]
Huh indeed. My point remains. This is advocating yet another class of editors to further disenfranchise newcomers to the site in the name of protecting the project. Absolutely insanity. There wouldn't BE a project if we didn't trust newcomers. --Hammersoft (talk) 12:27, 30 October 2012 (UTC)[reply]

Oppose. a) As Kusma says above, anyone who can be trusted with this right can be trusted as an admin. b) The collection of special rights is far too complicated already. c) Correct me if I am wrong but: full page protection is very much contrary to Wikipedia principles and is only applied in extreme cases and for short periods or to pages that nobody should be editing anyway, such as uncontroversial redirects where there have been edit wars. Someone please point me to the list of fully protected pages. — RHaworth (talk · contribs) 09:38, 30 October 2012 (UTC)[reply]
It's also applied to high-risk templates. Here is a list of fully protected pages. Graham87 11:27, 30 October 2012 (UTC)[reply]

Oppose I'm sure there are lots of good technical reasons listed above. Personally, having seen the way some admins on certain partisan issues abuse their privileges, even working together in subtle manners, I easily can imagine this being used to block certain more NPOV editors from some articles and allow partisan ones to be "protected page editors" and thus impose their POV on the article and leave it that way for as long as they can. CarolMooreDC 16:11, 30 October 2012 (UTC)[reply]
Seeing the 2/1 margin, I don't know if it will pass. But the page explaining it better have a clear and easy process for removing editors who abuse this privilege. CarolMooreDC 21:29, 5 November 2012 (UTC)[reply]

There are X amount of Admins here. Some have open minds and actually discuss an issue when you and he/she are in disagreement.
Then there are the Admins that are here strickly for "EGO". We all know such Admins, and thankfully their numbers are limited; and we've learned who to contact when we need honest advice or help. This proposal is a "nightmare"; as So Many of our so called "trustworthy" editors/users are "Ego Maniacs". Think of the repercussions. OPPOSE. Pocketthis (talk) 19:26, 30 October 2012 (UTC)[reply]

Weak oppose I don't have any major problems with the userright itself. One of my main concerns are that userrights can be given too liberally. Sure we have the phrase "easy come, easy go", but IMO, this shouldn't be a factor in judging whether or not a user can be trusted with a userright. The reviewer right is similar in way and for me, the reviewer right was given out like candy. IMO, there were too many instances were reviewers just accepted an edit just because it looked good even though the edit was vandalism. For me to support this userright, a stronger qualification than "oh you already have X userright, you are qualified for Y userright." is needed. Elockid ^(Talk) 19:41, 30 October 2012 (UTC)[reply]
Interesting logic. Oppose because we can't trust sysops to hand out the right correctly. The same sysops who do have the right to edit protected pages currently. And I notice I am responding all to sysops in this section. Should we start bringing up the word recuse here? Churn and change (talk) 02:32, 31 October 2012 (UTC)[reply]
The ease of obtaining rights is a problem, yes. But I don't think that the current unbundled rights have the same capacity as causing widespread disruption as what this userright does. IMHO, they have don't really have a big potential to cause massive disruption. Scripts can even cause bigger disruption. Editing fully protected pages does have a big potential for causing large scale disruption. For example, template vandalism. We already had great difficulty in finding the source of unprotected template vandalism. Vandalized highly transcribed templates would be a nightmare. There is a good reason why we have a communal discussion when handing out admin privileges. It is to prevent this kind of disruption from happening. In cases where potential massive disruption is possible, communal discussion is much better than leaving the decision to just one person. Elockid ^(Talk) 15:13, 31 October 2012 (UTC)[reply]

Oppose Why invent a new user right for something that PC level 2 could solve with no modifications? Or do we plan on giving out the "reviewer" right willy-nilly?—Kww(talk) 20:54, 30 October 2012 (UTC)[reply]
Since you have already voted, I assume you are sure PC level 2 is approved and ready. Is there a link you can share on how it works? Churn and change (talk) 02:27, 31 October 2012 (UTC)[reply]
Don't know where the description has gone during the transition from the trial, but it has been tested, and does work. Only editors with the "Reviewer" right can make a change that becomes active. Anyone else's changes need to be approved by a reviewer. I assume that anyone that we would trust editing templates would have the reviewer right and a vice versa. Semi-protect it at the same time, and you get a level where only autoconfirmed editors can even try.—Kww(talk) 03:55, 31 October 2012 (UTC)[reply]
Kww, please note that PC2 has been killed for the time being.—cyberpower _{Limited Access}^{Trick or Treat} 12:46, 31 October 2012 (UTC)[reply]
There's nothing preventing its use technically. The code is still active right now. It's just against policy for an admin to actually use it.—Kww(talk) 15:15, 31 October 2012 (UTC)[reply]

Oppose Creating a new class of editor with the editprotected bit will only stratify users more and justify more page protection. Broadly speaking, we don't want to protect pages and we shouldn't be protecting them long term. Certainly, we shouldn't be creating a new tier of user who is happy to have pages protected because they can edit them and bedamned anyone else. This is the encyclopaedia that anyone can edit - unlock the page before considering who granting the editprotected bit. --RA (talk) 01:30, 31 October 2012 (UTC)[reply]
"We shouldn't be creating a new tier of user who is happy to have pages protected because they can edit them." Are auto-confirmed users currently forcing semi-protection just so only they can edit pages? It is easy enough to do actually for anybody who knows how to reset a modem. That doesn't happen because most who edit here believe in that ethos of Wikipedia you so well articulate. Why do you suggest the edit-protected group would be different? Churn and change (talk) 02:15, 31 October 2012 (UTC)[reply]

Oppose Unless clarified and revamped. We don't need / this shouldn't be "admin -lite". It hints at what we really need, a separate track to roles of well-proven empowered individuals separate from having the mop/toolbelt. North8000 (talk) 11:42, 31 October 2012 (UTC)[reply]

oppose I see no big backlog of protected pages needing edited, and we don't need another bunch of folk thinking that they are allowed to edit protected pages when other users can't.--Scott Mac 00:47, 1 November 2012 (UTC)[reply]
You mean just your bunch of folks allowed to edit protected pages is good enough? If such statements with a COI form a significant-enough mass, it may be time to get sysops to recuse themselves from discussions on unbundling rights. Churn and change (talk) 15:42, 1 November 2012 (UTC)[reply]
The idea that there is a "your bunch of folks" is exactly what is wrong with this proposal. Wikipedia was created based on the idea that those allowed to do more than others are not special - while this proposal enforces the opposite idea, i.e. that we need more different groups of editors when we actually need less. Regards So Why 16:05, 1 November 2012 (UTC)[reply]
Those who are allowed to do more than others are special. They can do more than others. Saying they are not special makes no sense. These opposes now smack of: "I have special powers but I am not special, and I don't want others to have special powers unless they join my club." I will never file an RFA (it is reachable for me with sufficient time as my Afd log/RFC closures/RSN&RX contributions etc show). I don't want to say "I will block and ban and page-protect" (not saying those are unnecessary; those just aren't things I want to be doing), but I do want the ability to edit untrammeled as long as my edit-history reflects sufficiently positive contributions to Wikipedia. Unbundling gives me that; I suspect the yes votes reflect the same need. Those who already have the bundled bit are not unbiased judges of unbundling. Churn and change (talk) 16:48, 1 November 2012 (UTC)[reply]
Just being allowed to do more does not make you special. It does not make your opinions worth more or changes the rules for you. To quote the page linked above: Stated simply, while the correct use of the tools and appropriate conduct should be considered important, merely "being an administrator" should not be. And just because Scott or me or any other admin opposes this proposal does not mean we do it because we are admins (for example you will often see Scott and me disagreeing on something even though we are both admins) - we do it because we believe it the wrong solution and/or a solution in search of a problem (all other userrights were created to address a real problem, like backlogs or lack of admins doing a task). Because admins (having the "bundled bit") know that any editor can become an admin themselves they are imho actually less biased; on the other hand, someone who believes they can get the right if this proposal is successful might be more inclined to support this proposal. Generally, I'd advise against assuming and/or implying that those opposing a proposal do it to keep others from having something (while there might be users who think like that, the vast majority usually doesn't). Regards So Why 18:41, 1 November 2012 (UTC)[reply]

These opposes now smack of: "I have special powers but I am not special, and I don't want others to have special powers unless they join my club."
We don't want to prevent trustworthy editors from gaining useful tools. We want them to become administrators. It isn't a "club" for "special" users, and your perception to the contrary is symptomatic of a problem that the proposed change would exacerbate.
I will never file an RFA (it is reachable for me with sufficient time as my Afd log/RFC closures/RSN&RX contributions etc show). I don't want to say "I will block and ban and page-protect" (not saying those are unnecessary; those just aren't things I want to be doing),
And you're playing into the fallacious belief that administrators are required to use all of their tools. That misconception is a major factor in RfA's current dysfunction, and proposals like this one seemingly validate it. —David Levy 20:34, 1 November 2012 (UTC)[reply]
HAH! When I applied at my last RfA, before my "take no crap" attitude came up, about 5 to 10 opposes were given as "wishy washy reasoning for wanting the mop". You know what I want the bloody mop for? To edit protected pages. That my friends, is your lame and exclusive club of special people. - Floydian ^τ _¢ 16:42, 4 November 2012 (UTC)[reply]

Oppose The last thing we need right now is a means for further dividing users. Go Phightins! 02:53, 1 November 2012 (UTC) I am now neutral; I hadn't thought that this could be used for templates as well as articles. I will have to give this some more thought, but for now I'm going to remain neutral. Go Phightins! 03:04, 2 November 2012 (UTC)[reply]

This is just silly, because there is a pre-existing process for getting additional user rights already, and more administrative bureaucracy is certainly not needed nor wanted. --Jack Phoenix _(Contact) 11:45, 1 November 2012 (UTC)[reply]

Oppose this makes it easier for some to work their way to favoritism to abuse privileges or cause vandalism. Some old users like to shoot down genuine contributions, yet they have no constructive edits. There is a better way to do to this: the user does the work, then the admin and or community checks it off to put it in effect. Sidelight12 ^Talk 16:57, 1 November 2012 (UTC)[reply]

Oppose This can be as sensitive as anything else an admin does. DGG ( talk ) 18:37, 1 November 2012 (UTC)[reply]
Editing a protected page requires editing prowess and understanding what is uncontroversial in an editing context. Admins are not vetted for editing ability or experience. Consequently most currently avoid editing protected pages (by and large) though policy provides that latitude. Edit-protect editors will, or should be, checked for editing experience, not project-space expertise. Churn and change (talk) 20:23, 1 November 2012 (UTC)[reply]
Admins are not vetted for editing ability or experience. What? WP:RFA exists for a reason. Legoktm (talk) 20:25, 1 November 2012 (UTC)[reply]
Oh, it does all right. Not this reason though. Quality editing is not a requirement for adminship, and the reason is that admins are trusted with policy decisions, not editing ones. Today few admins edit a protected page other than to pull requests in. That is as it should be. Granting the edit-protected bit is a different kind of a trust; these editors make no policy decisions other than those required for editing per-se.

Oppose. Per Sandstein. I just don't feel this is necessary and/or won't actually be helpful. -- Lord Roem (talk) 05:50, 2 November 2012 (UTC)[reply]

Oppose Wikipedia is already too complex. Apuldram (talk) 10:43, 3 November 2012 (UTC)[reply]

Oppose per David. Samsara (FA • FP) 20:42, 3 November 2012 (UTC)[reply]

Oppose - Simply not necessary. Not even a little bit. This seems like such a bizarre, arbitrary "right" to hand out that it seems like it's being proposed just for the sake of handing out yet another flag. The difference here is that not only is it unnecessary, but I don't even see how it would benefit the project at all. Swarm ^X 20:55, 4 November 2012 (UTC)[reply]

Oppose Spent the last hour looking about. Like Swarm, I see no need. The lists of protected titles and protected pages are huge but the list of edit requests had only 22; 8 require MediaWiki action leaving only 14 requests for our English Wikipedia. Seven of those ask for changes to templates used throughout the encyclopedia and two deal with JavaScript tools. Four of the article space blocks will expire in less than a week leaving just a few permanent blocks including Bitcoin (sound familiar?). We can already take care of semi-protected edit requests. I took care of a couple during my look-about. How about popping over there and taking care of one for a new or IP editor? I don't think approval of this proposal will benefit the English Wikipedia. DocTree (ʞlɐʇ · cont) Join WER 00:19, 5 November 2012 (UTC)[reply]

Oppose as per wctaiwan. DS (talk) 12:25, 5 November 2012 (UTC)[reply]

Oppose. Articles are already protected too easily. This would make it worse. Edit warring should lead to faster, short block, punishing the warrior, not everybody. It also needlessly further complicates the hierarchy. Anyone with this need and who is trustworthy should get full adminship. --SmokeyJoe (talk) 13:29, 5 November 2012 (UTC)[reply]

Oppose Don't like the thought of certain individuals having the power to prevent others from editing wikipedia, this would be abused for sure, although in certain cases might be useful but probably better they get admin rights if so.♦ Dr. ☠ Blofeld 17:10, 5 November 2012 (UTC)[reply]
How will this right give the editors the power to prevent others from editing?—cyberpower ^Chat_{Limited Access} 17:21, 5 November 2012 (UTC)[reply]

Oppose I'd prefer pending changes. Even if pending changes is not implemented for the time being, I am still against unbundling the rights, especially one which is key in protecting the encyclopeida. Page protection is one of our most used and strongest protections against vandalism and out-of-control edit wars, and should not be treated, IMO, in the same way as rollback. Someone who can break page protection needs to be trusted by more than one admin, and RfA, as broken as it may be, is still a better indicator of project-wide trust. -- Avi (talk) 21:06, 5 November 2012 (UTC)[reply]
The encyclopedia is protected by the good faith, motivation and beliefs of its editors; by the ones who revert vandalism and cajole, coerce, or convince those who scribble here for a lark to stop and desist; by those who contribute good content, make articles readable and usable, and generate a good will among the public that protects its ways; by those who patrol the biography pages and revert fast what could damage us for good; by those who script and code and clean and care. Do not assume bits and their bite protect it. Churn and change (talk) 03:15, 7 November 2012 (UTC)[reply]

PC2 has been killed and that's the only protection level similar to full protection and only works in article namespace and nothing else. That means full protection will still persist.—cyberpower ^Chat_{Limited Access} 13:57, 7 November 2012 (UTC)[reply]

Oppose. I would very much like to unbundle edit-protected for use in the mainspace, but I cannot support handing out the ability to edit the MediaWiki namespace. If they can't be trusted with the mop, I don't trust them with the ability to vandalize every page simultaneously. Someguy1221 (talk) 05:29, 7 November 2012 (UTC)[reply]
Sorry if I reply to you only (you're at the bottom at the moment ..), there may be others higher up with the same remark. I dare to say that about 99% of the RfA candidates of the last 3-5 years have never ever edited more than 5 times a talk-page of the MediaWiki namespace. Many, many of those have zero experience with it, have no clue what it does or can do. Still, it has hardly ever been a criterion for RfA-candidacy. I sometime ago asked some candidates about editing the MediaWiki namespace (specifically, the Spam Blacklist), and besides that most said that they would stay away from there because they had not business there (or, the wise answer, ask other, experienced admins to do it for them), I even got remarks from other editors (admins?) that I should not ask such questions since the candidates were not intending to edit there at all and that the questions were inappropriate. If the far majority of our current Admin corps is hardly ever editing there, I don't see the risk that non-admins would abuse their bit to create havoc there. I can however bring up an example of a highly trusted admin who asked another admin to edit the MediaWiki namespace (which was performed), resulting in returning problems ... --Beetstra (public) (Dirk Beetstra^{T C} on public computers) 05:47, 7 November 2012 (UTC)[reply]
In addition, as noted below, the editinterface right is not included in this proposal, so people with this right would not be able to edit the MediaWiki namespace anyway. Graham87 13:53, 7 November 2012 (UTC)[reply]

Oppose - I'm perfectly fine with editors having different tools, but different editing rights is a different animal altogether, flying in the face of the concept of "an encyclopedia everyone can edit". I know editors have recourse of discussing proposed changes to put in full-protected articles, but the process is cumbersome and inefficient enough that it's hardly the same. Kansan (talk) 15:50, 7 November 2012 (UTC)[reply]

Oppose - Honestly, to have a separate 'editprotected' right seems a little arbitrary, and unnecessary. Given the low number of full-protected pages, it doesn't seem necessary. As has been said before, editprotected requests are usually answered in a reasonable amount of time, so I don't see a need to add more users to the list of people who can answer them. I won't comment on Pending Changes at this time, given the last experience I had with that ending in a total failure, but I'm willing to take another look at it. But that's not why we're here, now is it?--Unionhawk ^Talk ^E-mail 23:22, 7 November 2012 (UTC)[reply]

Oppose I feel that it would only serve to add another layer of complexity to a system that is already too bureaucratic and overburdened. Best, Mifter (talk) 00:18, 8 November 2012 (UTC)[reply]
Oppose nonsense. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 01:27, 9 November 2012 (UTC)[reply]

Oppose. The guidelines for how this would be granted seem vague and arbitrary. St Anselm (talk) 22:06, 9 November 2012 (UTC)[reply]
New user right proposal - Discussion
I don't see the issue with editinterface, maybe an explanation may help me understand, but i'm towards supporting this idea for editprotected. Also, what does tboverride does? — ΛΧΣ21™ 15:39, 12 October 2012 (UTC)[reply]
It overrides the title blacklist and let's you create pages that are on the blacklist. My bot could use that feature when it maintains the bad image task.—cyberpower ^Chat_{Limited Access} 15:42, 12 October 2012 (UTC)[reply]
Oh okay. And editinterface? (Excuse me if I'm asking too much) — ΛΧΣ21™ 15:46, 12 October 2012 (UTC)[reply]
Allows editors to edit interface pages such as the watchlist details or the Twinkle gadget.—cyberpower ^Chat_{Limited Access} 15:49, 12 October 2012 (UTC)[reply]
...and change the sitewide CSS/JS files and wreak considerable havoc across all of our millions of pages at the click of a button. That's a bit too much for me. T. Canens (talk) 16:20, 12 October 2012 (UTC)[reply]
Yes; true. Cyberpower, you should consider removing editinterface from the package, as it is too much to be handles to anyone. — ΛΧΣ21™

i have removed the editinterface right from the package.—cyberpower ^Chat_{Limited Access} 17:45, 12 October 2012 (UTC)[reply]
Thank you Cyber for removing that so that this idea has a chance at success. For those that think that the world will come to an end if Editinterface is allowed though I submit to you that suggestion is mere hogwash. This isn't going to be granted to every Joe, dick and Harry but to users who have displayed good judgement and the necessary knowledge required. I would also add that to say that an editor who should have this access should be able to make it through RFA is also nonsense. Its not just about making it through RFA, the RFA has such a bad reputation that many editors refuse to even go through it. Some who do, sigma recently and even myself have a history of good judgement and the knowledge necessary to get this access but may not be suitable or desire to be a full blown administrator. Personally I think that the "Admin" role be scrapped and users just apply and be granted to the tools they need and use and have shown a pattern of trust and knowledge about rather than a whole toolbox full of stuff so they can edit protected pages and never use anything else. With that said and as much as I support this I doun't this will pass. The admins are in power and they want to keep it that way so they will find a way and justification to scuttle it just as they have done in the past. Kumioko (talk) 18:00, 12 October 2012 (UTC)[reply]
It's true that a few admins will feel that the power if this goes through but there admins out there who feel this to be productive change to Wikipedia to allow non admins to assist in fully protected areas. I am willing to WP:AGF that they will truly choose what is best for the 'pedia. I do understand their concerns and even asked myself why I added that right to the package. I believe that only admins should edit pages that have site wide changes.—cyberpower ^Chat_Offline 18:08, 12 October 2012 (UTC)[reply]
Sorry I still don't agree and here's why. If I can be trusted with editing protected templates like Template:WikiProject Biography thats on a couple million articles then the other should also be no big deal. Let's remember that a change made to one of these is going to be noticed fast and would probably be reverted in seconds followed swiftly by a revocation of that users right to edit protected stuff. Will it happen, sure, but no more often than one of the Admins doing it and another reverting it and slapping them with a trout. Kumioko (talk) 18:14, 12 October 2012 (UTC)[reply]

And there are admins (myself included) who are disgusted by the absurd hoops through which current candidates are expected to jump. Proposals such as this one attempt to address a very real problem, but they do so by sidestepping it (and unintentionally exacerbating it) instead of repairing it.

If someone can be trusted to not abuse the ability to edit protected pages, he/she can be trusted to not abuse the other administrative tools. That he/she might not need all of the tools is immaterial; he/she can be trusted to simply not use unneeded tools.

The solution to the RfA problem is to return to the longstanding standards that served Wikipedia well, not to validate the onerous demands that have given the process "such a bad reputation". —David Levy 18:44, 12 October 2012 (UTC)[reply]
For the most part I agree with you however having seen no less than a dozen attempts to correct and revamp the RFA process and even participating in many of the discsussions myself, all to no avail, I realize that to continue to do is unrealistical in coming to any kind of consensus. I said as much so on Jimbo's page earlier this week. This leads me to the very realistic and inevitable solution to not use the RFA process. If this causes the RFA process to be circumvented and abandoned because its too painful and easier to get the tools we need without going through it then that's the cost of doing business. Using my RFA as an example, it was a crushing disappointment and many editors said I couldn't be trusted which I still feel is complete BS. I have never in my 6+ years and 400, 000 edits vandalized a page or intentionally did harm (other than a few snide comments from time to time). So to tell me I can't be trusted to wield the mop because I got pissed off and came back (because I believe in the project) is ridiculous and amounts to spitting in my face and many, many, many other productive and reliable editors have had the same fate. Many stopped editing and some just said the hell with it and became the vandals and untrustworthy sorts they were blamed for being. Many more simply refuse to go through the RFA process. Now we are left with a continually dwindling RFA process that every year promotes half the number of admins the year before. In 2007 we promoted around 400 admins. This year we are look at roughly 20-25 at most. Next year if the pace continues it will be 10-15. We simply cannot hope to survive by keeping things as status quo. Wikipedia is on the verge of an editorial and administrative bankruptcy if we don't change things. This proposal is a step in the right direction with or without the includsion of Editinterface. Kumioko (talk) 18:58, 12 October 2012 (UTC)[reply]
I view it as a step in the wrong direction. Unbundling the ability to edit protected pages would provide yet another excuse to oppose trustworthy candidates at RfA. ("You can just become a protected page editor instead.")

You've suggested that the RfA process be abandoned (and presumably replaced with separate requests for each of the tools). I strongly disagree that this would solve the problem. It would force editors who need multiple tools to go through multiple processes, with no reason to assume that they'd be any less painful than RfA currently is. (In response to a recent proposal, a Wikimedia Foundation representative stated that certain tools must be granted via "exactly the same process" employed at RfA, "using the same criteria" and "operating on the same page".)

Instead of a single process through which trustworthy editors are given the tools (i.e. the manner in which RfA is intended to operate), they'd be forced to justify the need for each tool individually, likely with a level of stress similar to that of RfA.

You noted that attempts at RfA reform have been made. I can't say that I'm familiar with all of them, but those that I've encountered have entailed dramatic alterations to the process — essentially replacing RfA with something else entirely. This amounts to throwing out the baby with the bathwater. The underlying RfA process is sound and needn't be overhauled. The problems stem from the attitudes exhibited by certain segments of the community, which no amount of process tinkering will change.

I don't believe that restoring RfA's former atmosphere will be easy, but I believe that it's the only viable course of action (and one to which proposals such as this one run counter). —David Levy 19:39, 12 October 2012 (UTC)[reply]
Well as I mentioned above this proposal will likely be squashed like so many in the past and the RFA process will continue to degrade. I'm sorry I don't have your optimism that the RFA process can be turned around at this point. Too much stigma has been ingrained into it and too much time has been wasted talking about it with no actionable result. IMO the RFA process either needs to be scrapped completely for something new or someone in the foundation needs to step up and take charge of changing it. We as editors have failed to get a concensus to change it because we are too busy bickering about how the changes will be the end. Unfortunately we have all failed the system and now drastic steps in the form of this proposal or some other are now needed if we hope for it to survive at all. We simply cannot afford to continue promiting such small numbers of admins as more and more content gets protected (IMO largely unncessarily) and more and more things require admin intervention. I'm going to stop debating it at this point because I can see that nothing I say is going to change your mind and few editors have any respect for what I say or think anymore anyway, largely due to bad admin decisions against me in the past. So you'll excuse me if my attitude towards the general admin culture (no disrespect intended towards you or any number of other good admins I have encountered) isn't very high. Kumioko (talk) 19:50, 12 October 2012 (UTC)[reply]
No offense taken. And to be clear, I respect your views and share many of your concerns.

I wouldn't describe myself as "optimistic" that RfA's original atmosphere can be restored. But I remain hopeful, mainly because I believe that the alternatives suggested thus far would make matters worse.

At this point, WMF intervention might not be a bad idea. I'm generally one of the last people to advocate such a thing, but when the community fails to come up with a viable solution on its own, something must be done. —David Levy 20:19, 12 October 2012 (UTC)[reply]
Hear, hear. — Hex (❝?!❞) 07:39, 15 October 2012 (UTC)[reply]
Frankly, I think WMF intervention is probably the only thing that can fix RfA/admin. The community can't do it, because "management by community" is the problem, and there are too many factions with diametrically opposed views for any consensus to emerge - witness the (literally) years of attempts at WT:RfA to do something but which have so far achieved precisely nothing. -- Boing! said Zebedee (talk) 08:44, 15 October 2012 (UTC)[reply]
I agree and given that the WMF has stated that there are legal concerns with granting certain admin tools to just any user without an RFA type process I think it would be entirely appropriate for someone or a group of someones at the WMF to determine who will and won't be admins. Unfortunately I think we as editors and as a community have failed the process and have proven they we cannot fairly and adequetly choose good admins. Or at least do so in a respectful and civil manner. The WMF already has the deciding vote on certain roles like checkuser and I believe a Beauracrat but I see it being appropriate that they could also be able to select editors for promotion or at least decide on who will or will not be when submitted. I would think this to be a much more friendly and efficient process in fact. Although realistically I can't see the WMF stepping up either. They enjoy a fair amount of separation from the process now and I doubt they would get involved unless drastic steps (like no promotions for a long period of time) were needed. Kumioko (talk) 14:38, 15 October 2012 (UTC)[reply]
I don't believe that the WMF should select our administrators directly (and agree that such intervention is highly unlikely to occur).

More realistically, the WMF could hand down specific criteria for bureaucrats to follow when gauging consensus at RfA (i.e. what input to consider, how much weight it should carry, what evidence is required, and what concerns should simply be set aside).

In my view, comments along the lines of "Oppose. This editor seems competent but doesn't need all of the admin tools." or "Oppose. This editor fails my admin candidate checklist because he has fewer than 500 XfD edits and hasn't written any featured articles." should be disregarded. —David Levy 15:56, 15 October 2012 (UTC)[reply]
Agreed, a lot of that going in the current RFA. If there is no policy or requirements in RFA then they shouldn't be held against the editor applying. Of course there is nothing forcing anyone to vote in either direction and we certainly wouldn't want to make things so hard that no one voted but IMO if there is no requirement, then we shouldn't be opposing for X reason. That's no different to me than saying they must be a parent, with a master's degree or higher and drive a porsche. Kumioko (talk) 16:51, 15 October 2012 (UTC)[reply]

But then as the closing bureaucrat, aren't you expected to judge the community consensus and not apply your own judgment? Let's look at a stellar example in the recent past: Wikipedia:Requests for adminship/Σ. First of all, there are more than double the number of supports as opposes (~140 to ~65), yet this was closed as no consensus? Huh... Let's look at some of those opposes, which must be very convincing, right?

Immaturity: diff of Wikipedia:Requests for adminship/Drmies. It was stricken, but was never funny. - Br'er Rabbit

Single incident 1 year and 4 months before the RfA in which the candidate jokingly mocked the RfA process.

Oppose Personal intuition. — ChedZILLA

Good one!

Oppose per Leaky_caldron. I have a bad feeling his username won't make much sense. Why would he choose the symbol for a summation in statistics named for Leonhard Euler? TruPepitoM Talk To Me

Better add "A normal username" to the RfA requirements. This was also the reasoning for BrownHairedGirl opposing.
After this point, the opposes start addressing the real concerns that would actually have merit in an oppose rationale. However, these three opposes are great examples of how the current system is borked. I'm sure if I went through two or thee past failures I could pull out a smorgasbord of poor rationales. - Floydian ^τ _¢ 15:30, 16 October 2012 (UTC)[reply]
What problem is meant to be solved here?--Tznkai (talk) 19:07, 23 October 2012 (UTC)[reply]
Actually this idea was meant to lift a burden off of the admins. With the admin count dropping, it gets more and more difficult for them to be able to keep up with every "admin" thing. By removing a not so contentious user right from the admins only toolset and making it a new right, admins can then do other more contentious things. There are just about 20 unanswered edit request out there that need to be answered.—cyberpower _Offline^{Trick or Treat} 20:05, 23 October 2012 (UTC)[reply]
Is that a high back log? Do you know what the average is? How many editprotect non-admins do you imagine there being?--Tznkai (talk) 20:14, 23 October 2012 (UTC)[reply]
Considering how long it took for my edit request to be answered for a protected page, yes.—cyberpower _Online^{Trick or Treat} 21:16, 23 October 2012 (UTC)[reply]
The editprotected template could also be updated to split the log into templates and other pages, so that the technical people can keep on top of those, make sure the world won't implode when the changes are implemented. - Floydian ^τ _¢ 17:51, 24 October 2012 (UTC)[reply]

If you're referring to the watchlist notice request, the delay is a normal part of the process (intended to provide an opportunity for editors to discuss the proposed message). I saw your request when you posted it, but I refrained from commenting because I'd already opposed the proposal. —David Levy 18:17, 24 October 2012 (UTC)[reply]

I honestly think the creation of Wikipedia:Requests for permissions/Protected Page Editor (no mention of its creation here?) is pre-mature. Specially since there has been no approval of this proposal yet nor discussion of which the userright should be called other than what the proposer suggested (correct me if I am wrong on both things.) One of other reasons I think the creation is pre-mature is because it should have been created by the Wikimedia Foundation or an admin/b'crat who is familiar with request for permissions who would most likely notice that all the other permission pages are properly capitalized (i.e "Account creator" and "File mover" not "Protected Page Editor"). With all respect :). -- Cheers, Riley Huntley 04:23, 25 October 2012 (UTC) [reply]

The way to address the problem of admin attrition is to address the core issues of the RfA process, and not by unbundling the tools. I've been doing a lot of work over the past few weeks at Requests for Page Protection and have not encountered any backlogs that are a cause for concern. Depending on how such a new user right would be administered, I see in fact a possible increase in admin load; firstly by according the right, and secondly by responding to the claims of unnecessary protection. If ever this proposal passes, there must be a further RfA to decide on its implementation, and I would suggest a trial. Kudpung กุดผึ้ง (talk) 04:46, 25 October 2012 (UTC)[reply]
I think that a universal right to edit protected pages is dangerous. However, I have in the past needed to edit some of these pages, and I am in general too lazy to ask an admin to help. What I would prefer is a way for an admin to grant permission to a specific editor to edit a specific protected page. I do not want permission to edit all protected pages, but I would really like the abiltiy to edit certain pages that are non-controversial and that I created in the first place. My example is Template:Worldcat id. This page clearly must remain protected, but there is no need to hassle an admin if I need to change it. But if you give me a universal right, I might be tempted to edit controversial mainspace pages. -Arch dude (talk) 21:33, 27 October 2012 (UTC)[reply]
Section break for discussion on trial period [new user right proposal]
I am proposing that if this proposal succeeds it is put on a trial period of 90-120 days. Afterwards, there should be an RfC to determine its fate. As I have stated, my concerns are that a majority of editors do not understand what is necessary to edit a protected page or template. They assume that having the technical ability gives them the ability to make edits without needing to get consensus first. This is not true. I may be wrong and all of the editors who receive the userright will use it correctly, but I'd like to ensure that the issue is re-analyzed in a future RfC. Ryan Vesey 20:21, 23 October 2012 (UTC)[reply]
I don't think there has been much discussion of the point on what the policy is on editing protected pages, since, obviously, few know or care right now. The wording says uncontroversial changes are allowed. I would say any wording that isn't reverted once should be assumed uncontroversial. The other option is to ask editors to post on the talk page what they intend to add (even if not the exact diff current guidelines require, since a third-party has to pull it in), and if there is no objection to go ahead and add it. I prefer the first option as more workable. If all the right gives is an ability to pull other people's consensus-based requests into the article, I suspect many will see this as just a stepping-stone to an RFA. Churn and change (talk) 03:09, 25 October 2012 (UTC)[reply]
Concurring with Ryan and Churn and change, if this proposal passes, it should be subjected to a trial, and IMO of at least 6 months duration. I am also concerned with the possibility of more opportunities for hat-collecting - this is a real phenomenon as the admins who work at PERM are well aware. Kudpung กุดผึ้ง (talk) 04:53, 25 October 2012 (UTC)[reply]
You must not have been around for the Pending Changes clusterfuck. No trials unless there is a tool to automatically disable the tool at the end of the trial period. The pending changes trial became a vehicle for PC supporters to permanently enable the feature because they claimed that the phrase "two month trial" didn't mean that the trial would be over in two months, just that they would talk about it again in two months.—Kww(talk) 17:12, 2 November 2012 (UTC)[reply]
Bots? [new user right proposal]
I read above that the point of this proposal was for someone's bot. If that's the case, why not make this the proposal (that bots gain the ability to tboverride and/or to editprotected)? I personally don't think the editprotected has a chance in either case, but I think that tboverride to be added to the bots user-right package might have a chance. - jc37 23:04, 19 October 2012 (UTC)[reply]
There's almost twice as many supports than opposes for this proposal. Either way, to gain a toolbit for a bot would require the owner to have access to it as well. Anyways this proposal is primarily geared towards allowing users to edit fully protected pages such as highly visible templates that are highly complex rather than just constantly making edit requests. There is a reason why tboverride doesn't come with the bot package. It can allow for abuse.—cyberpower _Online^{Trick or Treat} 14:03, 20 October 2012 (UTC)[reply]
The only right a bot gets that an operator might not have is the ipblock-exempt which came about IIRC because of collateral damage when blocking a toolserver bot. Legoktm (talk) 14:11, 20 October 2012 (UTC)[reply]
Actually, the bot user-group very much does have user-rights that an autoconfirmed editor does not. See: Special:ListGroupRights.

And as bot approval has a MUCH more stringent process than something like rollbacker, I was thinking that this might have a better chance of passing if it was only for bots.

Also, if you want to demonstrate to the devs that this really does have consensus, you will likely need a much broader cross-section of the community than has commented here. You might want to consider a watchlist notice at some point. - jc37 18:46, 20 October 2012 (UTC)[reply]
I've already posted an edit request there but has been ignored so far.—cyberpower _Offline^{Trick or Treat} 03:18, 21 October 2012 (UTC)[reply]
Your request wasn't ignored. The delay is a normal part of the process (intended to provide an opportunity for editors to discuss the proposed message). I saw your request when you posted it, but I refrained from commenting because I'd already opposed the proposal. —David Levy 18:17, 24 October 2012 (UTC)[reply]
As a bot operator, I believe that we should err on the safe side that if a bot doesn't explicitly need a user-right, it shouldn't get it. There are a few times here or there when a bot is stopped from doing it's work because a page is fully-protected but most of the time it's not a big deal and gets fixed after protection is lifted. Legoktm (talk) 14:11, 20 October 2012 (UTC)[reply]
I came up with this proposal to add productivity to Wikipedia. I thought of my bot after launching the RfC. My bot manages the bad image list and some of those images it tags requires tboverride and editprotected. But since they are open for abuse to any bot op with a bot flag, I believe these should not be inherited in the bot group.—cyberpower _Online^{Trick or Treat} 14:58, 20 October 2012 (UTC)[reply]
I believe that since bots should never do any potentially controversial edits, and since clearly non-controversial edits will be done on request, that we do give bots this right. I would add that if we do, then users without this right who run bots need to be alllowed to rollback the edit comletely while logged in to the bot account, to allow for self-fixing of problems caused by a bot with a small bug. עוד מישהו Od Mishehu 06:22, 31 October 2012 (UTC)[reply]
I disagree, bots do make potentially controversial edits while conducting what is normally routine maintenance. While its true that a bot should generally not be making edits that are expected to be controversial, there are plenty of times where a routine task becomes controversial as applied to a certain situation that the bot owner likely did not anticipate. This would also encourage the protection of pages that "only a bot should be editing", making it much harder for editors to fix things when a bot messes up. While there may be a compelling case for a particular bot getting the right, I think that in almost all cases a bot should not have it. Monty ₈₄₅ 17:56, 2 November 2012 (UTC)[reply]
More refined proposal [new user right proposal]
How about, if technically possible, we create the option that admins can let certain non-admin users edit certain otherwise protected pages or all protected pages in certain namespaces (i.e., the template problem noted above). It's more complicated to (ahem) administer but it seems to me that it would address the problem more specifically. Daniel Case (talk) 03:46, 24 October 2012 (UTC)[reply]
The only technically-feasible options to implement this at this time are to either create a new protection level or (in the case of interface pages) create unprotected templates that are the real content of the interface pages (by transclusion).--Jasper Deng (talk) 19:29, 24 October 2012 (UTC)[reply]
I'm for the new protection level, then. Daniel Case (talk) 18:54, 26 October 2012 (UTC)[reply]

I haven't examined the main proposal enough to comment on it, but whatever it is, it shouldn't apply to user javascript, for obvious security reasons. 67.119.3.105 (talk) 00:41, 28 October 2012 (UTC)[reply]
It won't, those rights are given with edituserjs and editusercss. Legoktm (talk) 17:18, 28 October 2012 (UTC)[reply]
I left those out for obvious reasons.—cyberpower _Online^{Trick or Treat} 17:28, 28 October 2012 (UTC)[reply]
Main Page?
Would having the editprotected right enable this proposed user group to edit the Main Page and all the templates it transcludes (like TFA, DYK, and ITN)? Because if so, I am going to oppose this, as I think giving a non-admin the ability to edit the Main Page would be too much of a risk. David1217 ^{What I've done} 16:54, 28 October 2012 (UTC)[reply]
~~With the current technical implementation of the proposal, yes. Legoktm (talk) 17:09, 28 October 2012 (UTC)~~[reply]
Actually, no. editprotected does not give permission to edit cascade-protected pages, because that would allow back-door protection other pages by transcluding them into the cascade-protected page. Anomie ⚔ 18:04, 28 October 2012 (UTC)[reply]
Thanks for correcting me, you learn something new everyday. Legoktm (talk) 18:11, 28 October 2012 (UTC)[reply]

Okay, that makes sense. Thanks Anomie! David1217 ^{What I've done} 03:52, 30 October 2012 (UTC)[reply]
It should be noted that 'editprotected' is not a real userright. There is only 'protect' which is both editing protected pages and adding page protection.--Jasper Deng (talk) 20:15, 28 October 2012 (UTC)[reply]
Not true. That just happens to be the way Wikipedia currently operates, but editprotected and protect are two completely separate Mediawiki rights. Mogism (talk) 20:22, 28 October 2012 (UTC)[reply]
Although the "editprotected" right is rather strange. Because "sysop"-level protection actually checks for the "protect" right, MediaWiki has this odd "editprotected" right that lets someone bypass the normal protection check just so it is possible to give out the ability to edit protected pages without also giving the ability to protect/unprotect. Anomie ⚔ 21:01, 28 October 2012 (UTC)[reply]
The "editprotected" right was created specifically for bots. See bugzilla:13137. Ruslik_Zero 19:34, 29 October 2012 (UTC)[reply]
Pending Changes level 2 already does this
Before people rush off and change the Wikimedia core software again, why not just use Pending Changes level 2? The motivation here is for us to be able to protect a set of templates and other high risk files without giving access to every autoconfirmed editor, and that's exactly what PC2 is for. The code is already written. It already works. It's just a matter of formulating a policy to make use of it.—Kww(talk) 15:20, 31 October 2012 (UTC)[reply]
I went hunting for this. I see the RFC on it closed as "no consensus" on September 14, 2012. I see you voted support on September 12. So when you say "it's just a matter of formulating a policy to make use of it" are you saying we ignore all the other objections expressed in that RFC and captured in its summation? Or are you saying we reopen the RFC just one-and-a-half months after the last one closed? I oppose the suggestions in toto. Churn and change (talk) 15:47, 31 October 2012 (UTC)[reply]

The problem with that is that the reviewer userright is given out like free candy to virtually everybody. Ryan Vesey 15:51, 31 October 2012 (UTC)[reply]
True to that and I can think of a few admins that do that.—cyberpower _{Limited Access}^{Trick or Treat} 15:58, 31 October 2012 (UTC)[reply]

The RfC closed as no consensus which automatically defaulted to not being allowed to use such a protection level, unfortunately. I supported its use, too.—cyberpower _{Limited Access}^{Trick or Treat} 15:58, 31 October 2012 (UTC)[reply]
The RFC was in reference to using PC2 to protect articles, and most of the objections were based on the idea of it causing widespread POV problems. I think an RFC targeted at a narrow use of it for high-risk templates would stand an excellent chance of gaining consensus.—Kww(talk) 17:44, 31 October 2012 (UTC)[reply]
No it wasn't. It was for using PC2 protection in general.—cyberpower _Offline^{Trick or Treat} 18:07, 31 October 2012 (UTC)[reply]
Quoting from the proposal: "This RfC is on one of the less controversial questions – the role (if any) of Pending Changes Level Two . . ." The answer was, quoting from the summation: "no consensus, which would default to not using PC level 2 for the time being". And I don't believe most of the "yes" votes here are referring to the ability to edit high-risk templates. Churn and change (talk) 18:28, 31 October 2012 (UTC)[reply]
I'm really mystified by how this part of the discussion is going. Everyone seems to be focused on an RFC that came to no consensus. Here, we have an RFC that is coming close to consensus (not there by any means, but close), but the problem is that it will take the better part of a year to get it implemented. PC2 would solve 90% of the problem and could be rolled out in a matter of weeks following a discussion of precisely how to do it. As for the issue of it being on high risk templates, I hate to disillusion people: high-risk templates are the only fully protected articles that have any kind of frequent editing. It's extremely rare that there is an emergency need to repair a fully protected article before the protection expires. Editors that used it to do so would frequently find this new privilege revoked.—Kww(talk) 18:39, 31 October 2012 (UTC)[reply]
Well, to roll out PC2 we need a consensus from editors we don't have. As to editing, edits which are non-controversial are allowed to FP pages even today (obviously by admins). Policy doesn't say an editor has to demonstrate an "emergency need." The protection policy says "Pages that are protected because of content disputes should not be edited except to make changes which are uncontroversial or for which there is clear consensus." Things such as copy-edits and citation fixups fall into that category. As to implementation, there is an edit-protected right today, separate from page-protection right, used for bots. Churn and change (talk) 19:01, 31 October 2012 (UTC)[reply]

Pending changes will not work because currently they are enabled only in the main and wikipedia namespaces. Even if PC were enabled in the template namespace, using them to protect high risk templates would probably require other configuration changes. Ruslik_Zero 19:08, 31 October 2012 (UTC)[reply]
I somehow wasn't even aware of the PC2 RFC. How did it get only ~60 editors involved when the earlier RFCs had hundreds? Was it poorly advertised or did I just miss it? Someguy1221 (talk) 10:26, 7 November 2012 (UTC)[reply]
Testing validity of oppose arguments

OK, I'm prepared to put myself, as an example, in the firing line. I'd be interested if all the people who opposed, above, could be able to tell me what specific reason they'd have for opposing me, personally, if I were to apply for the userright. And I'm never going to do the RfA thing, so don't waste time telling me I should go for the whole package, instead! ;P Let fly, guys. Pesky (talk) 08:04, 4 November 2012 (UTC)[reply]

Adding: Fing is, fing is ... it seems to me that the vast majority of the oppose arguments here could just as well be applied to the hypothetical situation that we didn't have rollbacker as a userright, and were suggesting it. There's very little in the way of argument which wouldn't also apply to that hypothetical discussion – and yet having rollbacker as a userright hasn't caused those problems, has it? No major upheavals? That's why I'd be really interested to see any arguments to oppose an editor such as myself for PPE userright. Pesky (talk) 08:15, 4 November 2012 (UTC)[reply]
Rollback doesn't permit anything that couldn't otherwise be accomplished. It's just the equivalent of hitting "undo" a few times. My main worry about this is kind of an underlying tone of the discussion. As an admin for 30 months now, I think I've edited through full protection in article space perhaps twice. In article space, it's an extremely rare thing to do, as full protection is usually applied for very short periods of time, and the risk of being perceived as using my tools to further a POV is extremely high. In template space, it's a more common need: the protection is due to the widespread impact of vandalism, and, with some exceptions, POV isn't much of a problem. When I look over the "support" arguments here, I see a crew of people that are ready and willing to go edit articles and most not seeming to understand that the only normal application of this is templates. Editing a fully-protected article is generally a really bad idea, no matter how noble the intention, and the idea of expanding the group of people able to do it when the motivation seems unsound bothers me.—Kww(talk) 20:23, 4 November 2012 (UTC)[reply]
I think I've only used rollback two or possibly three times, but that wasn't quite my point. I was interested to find out what reasons people might have to oppose me, personally, having the ability. Partly because there are a lot of other editors like myself to whom it would also be likely to apply. So, if people can come up with ideas as to why I, personally, would be opposed, then we might get a better understanding of what the oppose reasons might be for quite a variety of similar editors. And, if there aren't any ... then what would be the problem in an editor such as myself having this userright? I'm looking for really valid oppose reasons which could apply to people such as myself, rather than "a solution in search of a problem" reasons, or "what an awful idea (no reason specified against editors in good standing, trustworthy to use the tool sensibly)" answers. Pesky (talk) 09:45, 5 November 2012 (UTC)[reply]
Pesky, you have a talent for coming up with interesting twists in these discussions. Sometimes they are very insightful and helpful. This time, not so much. I would encourage everyone not to engage on this topic. The proposal is not "should Pesky have this userright" and trying to make it about that is a strawman argument. Beeblebrox (talk) 19:30, 5 November 2012 (UTC)[reply]
Beeblebrox, dear heart, I shall choose to take that as a compliment! However, my real point is that if nobody could come up with any reason to oppose me, then there would be no reason to oppose any number of other similar editors either! Of course there are going to be many people who wouldn't, maybe, be trustworthy enough. Just as there are many who wouldn't be trustworthy enough to be an admin. But hopefully nobody would be considering giving this to one of those. What are the objections to giving it to someone who would be trustworthy enough? Pesky (talk) 21:52, 5 November 2012 (UTC)[reply]
Actually, it's pretty simple: if you say "I want this bit because I want to edit protected articles", I would turn you down on principle. If someone went for adminship and his stated goal was that he wanted to edit protected articles, I'd have to see a lot of template work in his background, or I'd oppose on principle. In your case, I don't see that you edit templates frequently (with the exception of one small burst in August, 2011), and don't make requests in template talk pages to get edits to protected templates made. Since you have no apparent use for the bit, I wouldn't give it to you.—Kww(talk) 01:42, 6 November 2012 (UTC)[reply]
That's a very sound answer. I don't, as a rule, have any need for something like this. The only times I've found the absence of it frustrating is on the few occasions where I've seen a need for some minor copy-editing, typo-fixing, etc., when reading a protected page (I do tend to do a few quick fixes of that kind on anything which I'm reading), and sadly apathy rules when the page is protected, and I just can't be bothered to go and request an edit, etc. So I just leave the page unimproved, and move on. Pesky (talk) 06:53, 6 November 2012 (UTC)[reply]
Templates is one issue, but TFA blurbs is another. I often see TFA blurbs that really ought to be cleaned up, and like Pesky I usually can't be arsed to ask one of my superiors to make the necessary changes. But nothing will change here, so no point in discussing it further. Malleus Fatuorum 07:35, 6 November 2012 (UTC)[reply]
Question: I'm a bit hazy about how the decision to grant this would be made. The proposal says, The evaluating admin will judge the editor based on how previous edit requests were handled, and the validity of their own edit requests and how many times it gets approved or not, as well as if the trust in the editor is there or not. Is there an admin tool to check on all the previous edit requests from any given user? St Anselm (talk) 00:54, 8 November 2012 (UTC)[reply]
Get rid of the NFCC enforcement drama

DECLINED BY COMMUNITY

Closed per WP:SNOW. It's been two weeks since this RfC started and absolutely no support was given to this proposal.—cyberpower ^Chat_Online 18:11, 3 November 2012 (UTC)[reply]

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

WP:NFCC has probably caused more drama than most other policies on Wikipedia. WP:NFCC functions as the Exemption Doctrine Policy (EDP) of the English Wikipedia. This policy requires ANY non-free media to comply with ALL 10 non-free content criteria. Furthermore the policy says at WP:NFCCE that media without a valid rationale can be removed from the articles where it lacks a rationale and that "it is the duty of users seeking to include or retain content to provide a valid rationale". Per WP:3RRNO content that unquestionably violates WP:NFCC is exempted from 3RR.
I hereby propose to get rid of the requirement for any non-free media to comply with all 10 criteria and to get rid of NFCC#10c. Instead I propose the following, which will require further tweaking and reformulating:

Remove point 10 c. from WP:NFCC#Policy

Abandon Wikipedia:Non-free use rationale guideline

Replace it with the following:

For any non-free media, a confirmation at WP:NFCR is needed that it satisfies WP:NFCC. A wikilink on the media description page to the discussion at NFCR where a consensus was reached that the use of the media in a specific article is acceptable under fair use and that an omission of the media from the article would harm a readers understanding of the article serves as confirmation that it was determined via consensus that a specific use of the media on Wikipedia is acceptable.

For any additional use, a new consensus at NFCR is needed.

If the media is used on any page for which no consensus was reached on NFCR, the media shall be removed from that page with the following exeption:

If the media was uploaded by a new user where it can be reasonably expected that he or she is not aware of the non-free content policy, the media should not be removed. Instead a discussion at NFCR should take place and the new user given a welcoming invitation to join that discussion.

There are probably many other points which need to be considered and discussed, but this is a rough overview of what I have in mind. -- Toshio Yamaguchi (tlk−ctb) 07:49, 20 October 2012 (UTC)[reply]

Absolutely not. It is a non-solution to a problem that doesn't exist. Yes, there are users that may be unfamiliar with NFCC, but it's very easy to link them to it. But NFCC meets the basic requirements of the Foundation and thus changing it may cause it to fail. Furthermore the suggestion of having every non-free image checked through NFCR is excessive red tape and will be bogged down. --MASEM (t) 07:55, 20 October 2012 (UTC)[reply]
A requirement of demonstrated prior consensus might be a nice thing for certain categories of problematic files, such as historic photographs or movie screenshots, but as long as we'd have to include the huge volume of "routine" cases (cover art, logos and such), such a blanket requirement has no chance in practice. Fut.Perf. ☼ 08:06, 20 October 2012 (UTC)[reply]

Reply to Masem The suggestion of having every non-free image checked through NFCR is not in any form excessive, as this would have to happen only once for any non-free image. Also I disagree that it is not a solution to a non-existing problem. The policy clearly says that non-free content needs to satisfy the non-free content criteria, including 10c and there are many files violating that and this proposal tries to address that issue without militarization of NFCC enforcement. I don't see what the Foundation has to do with that, as the formulation of the EDP is entirely a matter of the English Wikipedia community. -- Toshio Yamaguchi (tlk−ctb) 08:12, 20 October 2012 (UTC)[reply]
Uh, no, per your own proposal every use (not file) would need NFCR review. Also we can't get rid of the rationale factor per the Resolution: As of March 23, 2007, all new media uploaded under unacceptable licenses (as defined above) and lacking an exemption rationale should be deleted,. The Foundation expects us to be stricter on NFC (as they expect us on BLP) so this feel-good approach is an utter failure of that. --MASEM (t) 08:30, 20 October 2012 (UTC)[reply]
If every use needs review, this also means every file used somewhere needs review, so the requirement to review any use includes reviewing any file. -- Toshio Yamaguchi (tlk−ctb) 08:56, 20 October 2012 (UTC)[reply]
But you just said this would have to happen only once for any non-free image. You probably meant "happen at least once for any non-free image". It is still an excessive burden. --MASEM (t) 09:02, 20 October 2012 (UTC)[reply]
No, I meant only once, which of course for any non-free file used somewhere also means at least once. -- Toshio Yamaguchi (tlk−ctb) 09:07, 20 October 2012 (UTC)[reply]

Absolutely not. (Not trying to be copy-cat but it's true). I just spent a good 30 minutes of my time in #wikipedia-en-help working with a new user on a non-free image. Yet it took only about 5 minutes to explain NFCC #1, and another 25 minutes on information on how to freely license the image and make sure they knew what they were agreeing to. I don't see how NFCC is a problem here. (And for what its worth, any copyright issue is and should be exempt from 3RR.)

On the other side, my bot is currently undertaking the task of tagging nearly every single non-free image with a |image has rationale=yes (see this), which is over 400k images. Checking every single non-free image by hand is a pure waste of time and better done by automation (which we have bots doing, IIRC). I agree that this is merely a solution looking for a problem. I haven't heard of any recent NFCC issues and don't think its really that big of a deal. Legoktm (talk) 08:27, 20 October 2012 (UTC)[reply]

I am not in favour of the proposed change. One of the purposes of fair-use rationales is to enable re-users (who may not have expertise in the article's subject) to assess the importance of non-free images to the article. Not too long ago, I was just such a re-user and greatly relied upon the FURs to decide whether I could cut the non-free content and still have a usable article. As a side note, when you absolutely cannot include any NFC when re-using you quickly discover just how dubious many NFCC 8 claims are. And don't get me started on boilerplate rationales...... CIreland (talk) 11:31, 20 October 2012 (UTC)[reply]

This is an unworkable solution to a nonexistent problem. T. Canens (talk) 14:19, 20 October 2012 (UTC)[reply]

Oppose 10c is not and never has been the primary issue, or even a major issue, with the NFCC. The issue has always been competing views on the boundaries set by criteria 8. As to the issue at hand, honestly, most non-free files are used once, a few rare ones are used twice, almost never is a non-free image used more than that. If it is, chances are it's being misused in the first place. Getting rid of 10c seems like it's just a way to cut back on the amount of work people need to do to get a non-free image hosted. That's not something I see as a good move. Sven Manguard Wha? 15:02, 20 October 2012 (UTC)[reply]

10c is of course not the primary issue (a viewpoint with which I 100% agree), but it is the only issue (apart from NFCC#9 of course) that can be reasonably decided upon by a single editor in most cases. -- Toshio Yamaguchi (tlk−ctb) 15:52, 20 October 2012 (UTC)[reply]

Oppose The solution to people being confused about a valid rule is not to merely throw up our hands and abandon the rule. I see no problems with continuing to educate users on the IUP at Wikipedia, including NFCC, and I am confused as to the rationale for this rule change. It feels like "well, let's just give up." That's a bad way to make policy. --Jayron32 04:16, 21 October 2012 (UTC)[reply]
FWIW, I will point to this post that Hammersoft made on his talk page, who has argued for dismissing NFC despite being a staunch NFCC supporter before. This might help to understand where this proposal came from. (There is frustration involve, but I total agree that the solution is not to cut off NFCC at the knees). --MASEM (t) 04:28, 21 October 2012 (UTC)[reply]

Comment Perhaps this is really a poor thought out proposal. -- Toshio Yamaguchi (tlk−ctb) 12:50, 21 October 2012 (UTC)[reply]

Oppose: If the rule is confusing people it may need to be rewritten for clarity, but there's no justification for eliminating it. — SMcCandlish Talk⇒ ɖ∘¿¤þ Contrib. 20:01, 28 October 2012 (UTC)[reply]

Oppose: First of all, this seems to smack of an assumption of bad faith on image uploaders by giving the impression that their contributions may not be appropriate, thus discouraging further image uploads. Second, this will not reduce "drama" around NFCC enforcement, but increase by several factors as editors now have to argue over every non-free image, thus giving non-free content warriors a battleground on which to wage their petty campaigns over fair-use. Third, this makes the routine inclusion of non-free images for the identification of books, albums, films, etc. far more bureaucratic using a democratic process that doesn't benefit the encyclopedia. And finally, WP:NFCC#10 is already stupidly easy to adhere to. There is no need to replace a straight forward requirement with one that that is far more complex and arbitrary. If an editor comes across an image that lacks a rationale or whose rationale doesn't match the use in the article, then fix it by adding or correcting the rationale. There are a number of templates that cover the most common uses of non-free media. WP:NFCR should be left to when there is a dispute between editors over whether an image's fair-use rationale meets WP:NFCC#8. Only then do you actually need to involve the community in order to establish a consensus. —Farix (t | c) 14:34, 29 October 2012 (UTC)[reply]

Oppose. Sorry to pile on, but there are compelling reasons for files hosted locally to pass all of the criteria. I do recognize that there's a learning curve, and users unfamiliar with the underlying logic sometimes do go through a lot of drama as they learn, but I'll shamelessly plug WP:AAFFD as a tool to learn about that underlying logic. --Tryptofish (talk) 21:16, 1 November 2012 (UTC)[reply]

Oppose. The only way to eliminate the drama caused by NFCC is to stop allowing nonfree content here altogether, something I would wholeheartedly support and that would vastly improve the quality of the encyclopedia. Unfortunately, there's no consensus for it. Angr (talk) 00:14, 3 November 2012 (UTC)[reply]

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

Edit summary label

LEAVE AS IS

Community in favor of number 1, our current design.—cyberpower ^Chat_Online 18:14, 3 November 2012 (UTC)[reply]

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

I'm not entirely satisfied with the outcome of this previous discussion, and would like to seek wider input. So all of you kindly pick one of the following. Thanks. -— Isarra ༆ 01:38, 23 October 2012 (UTC)[reply]
To clarify, the issue with the current was that it forces the box itself onto a new line, taking up space and moving all the buttons even further down than they were already. Shortening that by moving the explanation into the tooltip would put it all on one line, making the interface easier on anyone using a smaller screen. -— Isarra ༆ 06:33, 23 October 2012 (UTC)[reply]

Label variants

1.

Edit summary (Briefly describe the changes you have made)

2.
Summary of changes:

3.
Edit summary

4.
Edit summary

5.

Edit summary

6.

Edit summary:

Number 1, which is the current state. This offers the most lucid description, as it tells the reader immediately in plain words what is requested. Those who need more guidance can click the wikilink that leads to an elaborate help page. I don't see any need to fix this, as it is not particularly broken. --Mareklug ^talk 01:44, 23 October 2012 (UTC)[reply]

I agree with Mareklug. The blurb explains what an edit summary is, which is plenty for most people. Forcing people to jump away from the edit page to learn about an edit summary breaks the workflow of saving the page. David1217 ^{What I've done} 04:05, 23 October 2012 (UTC)[reply]

Number 1 is my preferred label. There's no reason to hide a pretty straight-forward blurb away from the viewer. Total agreement with Mareklug that this is a "if it ain't broke, don't fix it" type of situation. EVula // talk // ☯ // 05:02, 23 October 2012 (UTC)[reply]

Number 1, same as I said on IRC -- I think that clearly explaining what on earth an edit summary is is quite important... not just leaving a link which would theoretically take readers away from actually being able to save their edits (not that it doesn't already do that... but at least the explanation keeps some people from clicking, whereas now every new editor would be clicking.) Alright, that was a ramble. Theopolisme 10:56, 23 October 2012 (UTC)[reply]

Number 1, but increase the font of "(Briefly describe the changes you have made)" There is a lot of space wasted above the entry box and there seems to be room for both Edit summary and the description of what to do to be of the same size as the label inside the edit box. I see the insertion help is back, not sure where or why it had disappeared to for a while, but I simply went back to typing in <ref by hand in the meantime. Apteva (talk) 12:51, 23 October 2012 (UTC)[reply]

Number 1, as it's the most clear and direct. I do not think that having the full statement there adds clutter or is particularly cumbersome in terms of the interface. I, Jethrobot ^{drop me a line} (note: not a bot!) 13:26, 23 October 2012 (UTC)[reply]

Number 1. Tooltips are notorious for not popping up - especially on slower connections.Kudpung กุดผึ้ง (talk) 22:29, 24 October 2012 (UTC)[reply]
This is not implemented in js as some tooltips are, but merely uses the html title attribute. It would not be affected by connection speed unless the entire section of the page has neglected to load, at which point it would be rather moot anyway. -— Isarra ༆ 23:41, 24 October 2012 (UTC)[reply]
And the editors using textual browsers such as lynx, w3m, links and elinks? What tooltip-equivalent do they get? As, I believe, and please correct me if I am mistaken, they get no tooltips. --Mareklug ^talk 23:48, 24 October 2012 (UTC) P.s "Tooltips don't appear on mobile operating system, since there is no cursor." says our article Tooltip. --Mareklug ^talk 23:59, 24 October 2012 (UTC)[reply]
Textual browsers get the tooltip instead of the image, and mobile ones are neglected and get a link. -— Isarra ༆ 20:31, 27 October 2012 (UTC)[reply]

Number 1, it's the most friendly to all types of users (newcomers, users on slow computers, mobile users, users using textual browsers, blind users using screen readers, etc) I can't imagine any user getting the edit screen and not seeing the explanation. עוד מישהו Od Mishehu 09:22, 30 October 2012 (UTC)[reply]

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

Make alternative language version more prominent for some users
Over on Commons, there's a script (gadget? can't remember now) which looks at a user's language preferences (from browser details if not logged in, I think), and recommends changing interface language. Based on two feedback comments I've just seen (one here), maybe this tech could be used to make language versions for some cases more prominent. Examples:
Spanish version for Latin American people

German version for German topics

that sort of thing.
Basically, where there's a clear native language for a topic other than English, and the user appears to want that language, make a link to that language version of the article more prominent if such an article exists. (How to display and how to specify the "native version"(s) is less important at this stage than the principle.) Oh, and of course for logged-in users, allow the behaviour to be turned off... (though it shouldn't really be made so obtrusive that many would want to). Rd232 ^talk 21:35, 23 October 2012 (UTC)[reply]
Oh come on, not one single comment, question, or request for clarification? Rd232 ^talk 22:52, 27 October 2012 (UTC)[reply]
I'm just indulging you a bit. Your comment made me laugh. It's much like a teacher posing a question to a classroom full of students yet noone neither responds nor expresses that they don't understand the question.
While I'm not sure how your proposal would work I see it as too trivial. Whenever you view an article the available article in other languages is already easily accessible. What I think could be proposed is a script which informs the user that the article is available in their native language. Thus, once a user clicks on an article in English the script is generated and shown on-screen for a few seconds. The user would then have the option of scrolling down to the article in his/her preferred language. Even this alternative I don't think is worth the effort. The language preferences are already easily located so this seems like an unnecessary encumbrance.EagerToddler39 (talk) 06:31, 28 October 2012 (UTC)[reply]
Thank you for engaging! The languages versions are indeed readily accessible if you know where they are (there's nothing obvious about the sidebar location and there's a current discussion about renaming its heading to make it clearer what they are); language preferences relate to user interface and are anyway only available to logged-in users (most readers are not logged in). The two feedback comments which prompted this idea (on the same article!) demonstrate that there is a real problem here, not just me thinking out loud. So the script you describe is the sort of thing I have in mind, and because the tech should be readily adaptable from existing ones I think it's worth the effort. Rd232 ^talk 06:41, 28 October 2012 (UTC)[reply]

Technically, I suppose this is possible; you can ascertain someone's nationality based on their IP address (and it can be done anonymously, so it's not really a privacy violation). You could probably cross-reference the location with a language map (like you said, if the IP resolves to a German location, then place the emphasis on the de: interwiki). However, it's way beyond my skills to come up with something like this. What did you have in mind as the emphasis? EVula // talk // ☯ // 07:34, 28 October 2012 (UTC)[reply]
The technical problem doesn't need solving, I think, because AFAIK the Commons tech which automatically recommends changing user interface language can be repurposed with probably not much effort. The harder problem might be deciding when to recommend the user's probably-preferred language version; the easiest solution is to simply always recommend it, rather than try some kind of per-article thing that takes into account when the other language version is likely to be superior to the English one. NB I can't find the Commons code that does it now, but someone like User:Rillke would know. PS Not sure how to do the highlighting, but to be effective it needs to make the language link appear much more prominent - near the top of the page, maybe the way Commons does the user interface language recommending. Otherwise it's not going to make much difference - the idea is aimed at users who don't know/notice the sidebar language links. Rd232 ^talk 22:14, 29 October 2012 (UTC)[reply]
In MacOSX, there is a system settings where you can pick your preferred languages, and I think Windows has the same thing. Could Wikipedia read this information and suggest a person's preferred language on the top of the screen? Ego White Tray (talk) 02:06, 3 November 2012 (UTC)[reply]
Pakistan
As some will be aware, Pakistan articles are amongst the worst on wikipedia. Town and clan articles especially. Thousands of really "famous" people and places [1] I was wondering if you'd support me in a mass cleanup thing and greatly reduce the number of articles and leave only notable sourced settlements and those put on watchlists. The ones not up to scratch can be incubated or something. Its far more problematic having many of the articles than not, they attract some of the worst possible spam edits. I think we need to treat Pakistan as a special case, India too really given the large number of people with computer access and poor english but Pakistan for starters. I think the articles need strict regulation and reduced to a manageable amount which go on people's watchlists and then built up gradually with a standard of quality. It's of no use to English readers having these articles and them being plagued with crap. I'm considering organizing a mass AFD of Pakistan articles and then clean up of the more notable ones. The benefit of having Chak 68EB Dogaranwala and Trikhni with the "very famous people" and sheer "beauty" of the villages for instance, more problematic than its worth.There's too many articles to clean them all up. I think we need to strictly monitor Pakistan articles and wipe the slate clean.♦ Dr. ☠ Blofeld 16:23, 24 October 2012 (UTC)[reply]
~~I am not sure if Village Pump is the best place for you to gather support for this. Try Contacting Wikipedia:WikiProject Pakistan. But be careful.~~ I take back my statement after seeing what you have done to Pakistan articles and discourage you from doing so. --Anbu121 (talk me) 17:13, 24 October 2012 (UTC)[reply]
"Seeing what I have done to Pakistan articles". Good or bad? If you call removal of unsourced poorly written info and lists of schools and "famous" local taxi drivers bad editing. Information which is poorly written and unsourced is much better being removed from wikipedia and the articles remaining as stubs, I'm sure a lot would agree with me. Decent English editors don't want to read the crap written by somebody with a poor command of English plagued with POV. I had a conversation with the 1-2 man team responsible for running WP:Pakistan a few years back and they agreed that the scope was too big for them to maintain some level of quality. Seriously, the content in most articles for India and Pakistan makes me want to leave the project, the quality is so poor. Most of them are better wiped and started again from scratch. ♦ Dr. ☠ Blofeld 20:05, 24 October 2012 (UTC)[reply]
I hope you don't mind that I kind of cleaned up Trikhni, so you need a new example . Dr. Blofeld, do you have a list of potentially problematic articles that can be tackled? Or is this more of a go through Category:Pakistan recursively and clean it up? Legoktm (talk) 20:12, 24 October 2012 (UTC)[reply]

I agree that articles on Indian and Pakistani villages contain many samples which belong to the worst of Wikipedia, but I think the proper way would be (along with removing obviously non-notable stuff like lists of taxi drivers) to start requesting sources. In a couple of months everything which remains unsourced can go to AfD, in small portions, so that users have a chance to source and save the articles. Many of these villages are in fact parts of some greater municipalities and can not be sourced (I nominated couple of such cases for AfD).--Ymblanter (talk) 20:12, 24 October 2012 (UTC)[reply]
I believe the unsourced articles on Pakistani and Indians towns are far more of an embarrassment to the project than if they were missing. I think Pakistan and Indian need tighter regulation on wikipedia given the high web access and poor command of English and what is appropriate for an encyclopedia. The problem is massive. Browse through any of the sub categories of Category:Populated places in India and Category:Populated places in Pakistan. First example I found for Indian at random Kulgam. All unsourced, poorly written, only source to falling rain, a website known for containing false data which still hasn't been blacklisted for whatever reason. The slate needs wiping and writing with sources. How much of a loss would it be to have it removed from the mainspace? Anybody who has known me long enough on wikipedia would know that ideally I'd love to see GA quality articles on every village in both countries, but they are also serious crud magnets and few of our regulars here have Indian or Pakistan articles on their watchlists, most of the articles are off the radar. I believe all unsourced/poorly written Pakistan articles should be incubated and only restored once a fluent English regular on here has read and sourced it. its more damaging having many of the articles than not to wikipedia as a resource. You see what I mean and have a browse anybody, you'll be shaking your head in disbelief at the quality and wonder why you bother to edit wikipedia if it has such standards. oh and count how many times the words "famous", "beautiful" and "very" and lists of schools, "famous" local personalities, CAPITAL LETTERS and even email addresses appear in the articles.♦ Dr. ☠ Blofeld 20:22, 24 October 2012 (UTC)[reply]
I just ran through the first 100 articles in Category:Populated places in Pakistan, and searched for the string "famous" and came up with this short-list: User:Legoktm/Pakistan/Famous. I can generate more/longer lists like this if it is helpful. Legoktm (talk) 20:41, 24 October 2012 (UTC)[reply]
"Famous" is probably the best of the problems. Do we really want articles like Jayya? How much damage would it do to nuke it?.♦ Dr. ☠ Blofeld 20:54, 24 October 2012 (UTC)[reply]
I honestly think that zapping a few thousand of these would be helpful; there's no doubt in my mind that a blank page would be supremely more helpful than the piece of trash that is Milkyar, for instance. I don't think it'd work because too many people at AfD will reflexively state that "all towns are notable", but in these cases it's much better to start with nothing than, to borrow from Kongzi, trying to make a wall out of dung. Someone will need to give me a very good reason not to delete Jayya or Milkyar soon, because I'm perfectly ready to. The Blade of the Northern Lights (話して下さい) 20:56, 24 October 2012 (UTC)[reply]
Nobody is watching 90% of the articles which look like this. You know me, I'm super keen to improve coverage but really the problem is so huge and awful we are better off nuking them and starting with sources and put on watchlists. The reason is even if wiped clean and just left as xx is a village some poor English speaking local is going to turn up at some point and readd "famous village", literacy best in Pakistan, Mohammed Fahadabad, very famous governor. Unless every Indian and Pakistan article can go on a watchlist I believe we'd be better off deleting them and making a list of deleted/incubated articles and restarted with sources and put on watchlists. Saleh Khana is "the most beautiful village in the world", "the kidney beans of Javed is are famous in the UK" (yes, everybody here knows them like the back of our hands!) and see the end note! They don't just need a cleanup they need some germ blasting powerful chemical agent on them and a fresh start.♦ Dr. ☠ Blofeld 21:00, 24 October 2012 (UTC)[reply]
I am afraid just nuking them would not solve the problem. There are always people ready to fill in the red link and to create an article saying that xxx is a village 15 km west of another village, it has a school, a mosque and a carpet shop run by a respectable man. Unless we salt them of course. What we could do instead, possibly with the help of corresponding Wikiprojects, is to find the results of the census, and to create articles on the places mentioned in the census, referencing them to the results. This guarantees at least that the places exist. After that, everything else should go.--Ymblanter (talk) 21:17, 24 October 2012 (UTC)[reply]
New content of course could be strictly regulated in regards to India/Pakistan. Might scare potential editors away but generally that's probably a good thing, given what the average IP or newbie from these places produces.Sadly we need thousands of quality Indian and Pakistani editors but they really are one in a million on wikipedia. ♦ Dr. ☠ Blofeld 21:29, 24 October 2012 (UTC)[reply]
Oppose any special ghettoization or purge of Pakistan or India related topics. Much of the unsourced information, even the irrelevant stuff, is harmless. They are at the far end of the earth, physically and culturally, from most of us, and we won't do a better job than they can. Destroying their efforts is not progress. Even in rare cases where we find a sourced publication in the library, what does that really mean? It means that some researcher went to Pakistan for a summer, talked to the same people posting the stuff here, compared their accounts to get a consensus the same way as the occasional novice editors do when they log on here - only real difference is they slap a $79 price tag and a glossy clay paper cover on their work so we can cite it, and get a university job. Essentially, there are still remote places in the world where it is still 2001 on Wikipedia. Accept that - and accept that the answer for them is not to abandon the project, but to keep things and improve on them when they can. It might take five years, or even ten, or maybe a small revolution and a bill of rights before they're citing their own literature - so what? We can wait. You people should quit worrying about looking bad - the question is only whether we are bad, and whether we're trying to do something about it. Wnt (talk) 22:01, 24 October 2012 (UTC)[reply]
"Much of the unsourced information, even the irrelevant stuff, is harmless". Harmless? Here we are trying to build an encyclopedia of the highest quality, factually accurate and verifiable and it doesn't even remotely concern you that thousands of articles contain unsourced atrociously written text, full of POV, mistruths, adverts and inappropriate lists? Everybody else agree its harmless? I've had enough for today.♦ Dr. ☠ Blofeld 22:25, 24 October 2012 (UTC)[reply]
Oppose I have more than 2000 Indian articles in my watchlist. The problem is not with unsourced village articles, which hardly has one or two page visits per day. The major problem is with BLPs and caste articles. --Anbu121 (talk me) 22:29, 24 October 2012 (UTC)[reply]

Support to a point. (I really hate how everything has become a vote now). I think that stubbing is much more effective than simply deletion. Each one of these edits probably took no more than two minutes: [2][3][4][5]. I think once an article has been deleted, it makes it just a bit harder to re-start an article, whereas simply stubbing them down is much easier, plus it leaves it wide-open for improvement. Legoktm (talk) 22:50, 24 October 2012 (UTC)[reply]

Oppose. - Per Wnt. Deleting articles because they aren't high enough quality in wrong. If we started doing this, then our 4 million articles would quickly turn into 100,000 (or less). The Pakistan articles should be improved, not deleted. ~ GabeMc ^{(talk|contribs)} 00:02, 25 October 2012 (UTC)[reply]
Come back to us when you've cleaned a few up and tell me how it goes. You'll also note that nowhere in the voluminous instructions on article creation does it say "Dump a heaping pile of shit on us so a few severely overworked people can clean up after you". The Blade of the Northern Lights (話して下さい) 02:01, 25 October 2012 (UTC)[reply]
Question. - People have accused me of this, and I want to know, since I'm really trying to learn to correct the behaviour, is BNL's comment above a decent example of badgering an oppose? ~ GabeMc ^{(talk|contribs)} 02:20, 25 October 2012 (UTC)[reply]
Also, if you consider yourself a "severely overworked" unpaid volunteer dealing with "heaping piles of shit", then perhaps you should consider cutting back or taking a break. It's strange, some admins want to whine and complain about being so terribly overworked, but the same admins rarely want to unbundle the bit so that non-admins can help, or make RfA less hostile (read less like a hazing) and nit-picky so as to give more candidates a chance to help, Kafka-esque is quite appropriate. ~ GabeMc ^{(talk|contribs)} 02:54, 25 October 2012 (UTC)[reply]
No its not really badgering since this really isn't a vote/!vote/whatever. Dr. Blofeld brought up an idea that he had after noticing a certain group of articles were in horrible condition. If you want to help, great! If not, thats fine.

What Blade said had nothing to do with being an admin. Just take a look at Category:Wikipedia backlog, pick something and get to work. 98% of those don't require any advanced toolset and could be done by an IP if they wanted to help. We're all overworked since the backlog is growing with no end in sight. Legoktm (talk) 03:02, 25 October 2012 (UTC)[reply]
(ec) I repeat: As an unpaid volunteer, if you feel stressed and overworked then you should at least consider cutting back or taking a break. Or maybe just ignore those things that bother you instead of displaying a hostile and frustrated presence in discussions about the topic. When you're singling out the Pakistani articles as "heaping piles of shit", just maybe you should ignore them if they bother you that much, they will develop over time. ~ GabeMc ^{(talk|contribs)} 03:28, 25 October 2012 (UTC)[reply]
Oppose any special ghettoization or purge of Pakistan or India related topics...just as editor Wnt said above.
Interesting to me is how Indian and Pakistani usage of English languate is different than British/American. For example, I noticed that families advertise their daughters for marriage in newspaper personal ads describing them as "homely", which in Br/Am usage means ugly, but there seems to mean a cross between "comely" (cute) and "good home-maker". Looking at some of the wikipedia articles using "famous", i suspect that the term means "notable". I myself use "notable" adjective fairly freely sometimes in assertions to throw off deletion-minded editors who can't see the implicit notability of less obvious assertions. Looks like saying a family is "famous" within a village is a way of saying they are notable, that the mention is worth saying.
A few commenters here, 20,000 miles away, have little to contribute in the development of these articles. Like Wnt said, it is wikipedia-as-of-2001 in these areas: let them develop. --do ncr am 03:26, 25 October 2012 (UTC)[reply]
I think you have misunderstood the point of this task. The point is to clean up most articles, and if there are ones that aren't to put those up for deletion via the normal processes. No one is proposing to delete hundreds of thousands of articles.

Your interpretation of the language differences is interesting. I do agree with your assessment on the word "famous" meaning "notability". However, it's important to realize that just because they claim notability, does not mean they are so. If you see what I did in this edit, I was able to remove obvious WP:NPOV/WP:V violations, while still leaving a stub behind.

PS: Fun fact, I live in the USA, and according to wolframalpha, I'm only ~8.2k miles away. Please don't make up such ludicrous exaggerations. Legoktm (talk) 06:51, 25 October 2012 (UTC)[reply]
Exactly Blade, in response to "The Pakistan articles should be improved, not deleted". You go through any one of the categories Gabe, the problem is MASSIVE. The sheer state of the articles and being prone to shoddy edit if wiped clean would make it more beneficial to delete and restart with sources. Yes, we are a work in progress but c'mon the state is generally dreadfully poor and far below even the minimum of quality standards. We are supposed to be an encyclopedia.if some minimum quality can't be maintained and the article is barely legible and off watchlists we'd be better off having them removed, unless a mass cale cleanup operation can be done and all articles put on watchlists.
"perhaps you should consider cutting back or taking a break. It's strange, some admins want to whine and complain about being so terribly overworked," We care about building a half decent encyclopedia Gabe and we find what obviously amounts to thousands upon thousands of bog standard articles completely neglected and vulnerable to continuous quality degradation. As virtually nobody from India and Pakistan projects are actively working through cleaning them all up we have a huge problem which needs to be eradicated. The problem is massive and we simply cannot be expected to clean all of them up with just 2 or 3 of us. Not that we need a "wiki break" but we want a decent encyclopedia.♦ Dr. ☠ Blofeld 09:45, 25 October 2012 (UTC) ♦ Dr. ☠ Blofeld 09:34, 25 October 2012 (UTC)[reply]
Like Wnt said above, its really no different then Wikipedia in 2001-2005 for some of these projects. In 2009, The Telegraph named the Beatles article one of the top three most visited Wikipedia pages. Well take a look at the Beatles article in 2002 at one year old, no cites, 100% unsourced, same at two years, three years and four years (2005). I assume all the Beatles related articles went equally neglected in that regard during that time, but they were eventually cleaned-up and properly sourced. ~ GabeMc ^{(talk|contribs)} 10:13, 25 October 2012 (UTC)[reply]
Comparing the Beatles to some village in Pakistan, seriously.... Want to clean up User:Legoktm/Pakistan/Famous then? I've done 3 and already have a headache. ♦ Dr. ☠ Blofeld 10:25, 25 October 2012 (UTC)[reply]
I really didn't think I needed to add that qualifer but okay: No, I'm not comparing the Beatles to some village in Pakistan. Ridiculous! The point is that the article went 4+ years without a single citation, now look at it, its one of the top visited FAs. Like I said, maybe a good case could be made for deleting all articles (with no sources) about villages under a certain population, say 100, or whatever. All I meant was, I don't think we should be singling out Pakistan related articles as being unsourced, as there are unsourced articles in every project. Look at Come from the Shadows, Songbook (Chris Cornell album), Story Untold, Kevin Toth, XHTML Modularization, From Ritual to Romance etcetera. One could argue that for every unsourced Pakastani village article there are one or two equally uncited articles from other projects. ~ GabeMc ^{(talk|contribs)} 21:13, 25 October 2012 (UTC)[reply]
The problem is we have absolutely no idea which of the villages have the population below 100, since the creators do not bother to add the population data, and most likely do not have these data. In fact, for most of the villages we are not even sure they exist. If there were some solid data available like a populated census listing all census designated places it would be already much easier. We just do not have this problem with Europe, for example. If you ever find an article on a Russian village in such state, please let me know, I will take care of it (and Russia does not even have the population data split into villages, so it is rather on the bad side).--Ymblanter (talk) 21:21, 25 October 2012 (UTC)[reply]
I Support Blofeld's idea of clean up of Pakistan related articles and appreciate that this neglected topic area is getting attention. I suggest a list of these articles should be made so other editors willing to contribute can help. --SMS ^Talk 16:57, 25 October 2012 (UTC)[reply]
I'm not sure how I feel about nuking stuff like this, but to add to the cleanup pile: [6] ("beautiful"/"nice"/etc towns and villages in India/Pakistan), [7] india/pakistan articles containing many hyperbolic words, [8] "hard-working" castes, [9] "most ___ village"s in india/pakistan.... (these searches could be improved by combining with wikipedia's category tree, but this is a rough idea of some problem areas.) this list could go on and on. Calliopejen1 (talk) 19:45, 25 October 2012 (UTC)[reply]
Oppose I really don't think outright deletion (or "nuking" as they say) is the correct method of dealing with this. While I am aware that this problem is inherent in hundreds of articles, since I regularly surf back and forth across Pakistani village/town/settlement articles every now and then, and pretty much agree with most of Dr. Blofeld's views on the poor standards of English on these articles (this is coming from a Pakistani editor btw), I strongly believe that a massive-cleanup (in which articles are left to one-liner stubs or something) would be more productive than deletion, which is a bit of an extreme measure. As far as the English language is concerned, I think pretty much everyone here should be aware that a person who speaks Pakistani English at a basic level will never quite be as proficient as someone who speaks American English or British English at a native level. A cursory glance at List of countries by English-speaking population and the position of Pakistan on that table very aptly demonstrates the cultural differences that you will face in an English encylopedia that is open to editing for all, and where a Westerner will obviously have a much different way of spoken English than say, a Pakistani. These differences are unfortunately bound to always arise, the most you can do is just try to reduce them. Going back to the topic, a one or two-liner village stub (that has been cleaned-up) with a reference in hand is better than not having an article on the village at all. Perhaps we could generate some sort of list of all these bogus-filled articles and work through them/perform a cleanup one-by-one, and watchlist them as we go by. If this process will take months or years or whatever, so be it - I am quite convinced that deleting articles and recreating them again is not going to be any quicker. So, to summarise what I'm saying: Yes to massive article cleanup, no to nuking. Mar4d (talk) 02:48, 26 October 2012 (UTC)[reply]
I quite agree, but the task is enormous and massive cleanup is unlikely. Of course I'd like to keep the articles with sourced content put on watchlists. Wish I could clone you dearest Mar4d x 1000!!! ♦ Dr. ☠ Blofeld 14:47, 26 October 2012 (UTC)[reply]
Actually every article needs to be dealt differently, some of them may need to be nuked, (For example an article like Jandala (princely state) (AfD) definitely needs to be deleted.) while some can be left as redirects to respective districts or may be left as one or two line article if there are enough info and sources for further expansion. --SMS ^Talk 07:17, 26 October 2012 (UTC)[reply]
I understand. But one of my main concerns in a mass-deletion campaign is that many notable towns may end up being deleted from Wikipedia just because their articles are not quite up to notch. This is something that is not exactly a desirable outcome. That is why I am still insistent that performing a general clean-up on articles than deletion is the way to go. Mar4d (talk) 08:35, 26 October 2012 (UTC)[reply]
I think you're a bit confused. Think of this as a mass-improvement campaign. Our goal is to improve Wikipedia as a whole. If an article has POV/unsourced fluff in it, but still notable, we can get rid of that and replace it with a basic stub. If it isn't notable, it gets sent to AfD. The only difference is that we're specifically focusing on a group of articles we know are bad, so it may seem a bit deletion-ist, even though our overall goal is to improve the encyclopedia. Legoktm (talk) 08:55, 26 October 2012 (UTC)[reply]
Oppose deletion. Redirected "mohala" to expand term: These articles can be saved, perhaps listed 100 per month for other WP:GOCE editors to fix. As typical for articles on other emerging subjects, for a Pakistan town there was the word "mohala" which Google suggested, "Did you mean: mohalla?" and so I created a redirect. As with the Sikh place of worship, "gurdwara", last year, some cultural terms are revealed to be major words once the meaning is better understood. Please note, the lack of quality text is not just in village articles, but occurs in many areas, depending on the level of expertise, where experts in a subject have been just as appalled about missing details (in "Duns Scotus" or "Abelard"), as compared to casual readers appalled that village articles contain sparse data. Consider the terms "carriage bolt" (in article "screw") or "unit testing" or "simoom" (was a stub for years), which were once hollow topics, with limited details during the first 5 years of Wikipedia. Check again, in another 5 years, for the level of details about the Pakistan towns. The more readable those articles become, the more likely they will be expanded, just like those articles from 2005. -Wikid77 (talk) 22:02, 26 October 2012 (UTC)[reply]
Support deletion. I have been through some of those articles and have to agree with Dr. Blofeld's description of the situation. This is an embarrassment to WP, and this many poor articles, with no realistic hope of them becoming sourced, put a serious question mark on WP's commitment to verifiability. Verifiability policy should be applied ruthlessly.OrangesRyellow (talk) 09:01, 28 October 2012 (UTC)[reply]
Support nuking. Prepare a list of all articles to be deleted, and have a bot send across a message to all the editors of those articles to salvage as many of them as they want to. All those articles whose deletion is opposed that go through AfD, while the rest shall be dumped after the regulated time period [a month shall be enough]. Stricter provisions for new articles should also slow them a bit. Also, the same must be done for people too. There are way too many 'famous' people here than we can handle. TheOriginalSoni (talk) 20:28, 28 October 2012 (UTC)[reply]

Oppose I probably rewrote dozens of these, so I know that you are speaking about incomprehensible pieces of shit that should never have been on the web or Wikipedia to begin with--no illusions. However, Wikipedia has a serious anti-Pakistan bias, and I think this will look bad coupled with that existing bias. Maybe it would make Wikipedians pay attention to the small, but dedicated, group of editors entering serious anti-Pakistani bias into Wikipedia articles, quietly picking and choosing the worst of every source to shine upon Pakistan, a group of editors that are largely ignored by most Wikipedians, but I think it would simply appear as an ugly, bigger version of the pernicious anti-Pakistani bias that is Wikipedia (and so soon upon the interesting AN/I thread Wikilawyering the stain out of "Pakistan only invents terror plots"). Note, just to forestall accusations that I am accusing Dr. Blofeld of anti-Pakistan bias: the articles are pure crap, Dr. Blofeld is an excellent editor and community member, and anti-Pakistani bias is the worst of Wikipedia. -Fjozk (talk) 16:25, 31 October 2012 (UTC)[reply]
Shockingly, my experience says that WP may have a strong pro-Pakistan bias...OrangesRyellow (talk) 01:03, 1 November 2012 (UTC)[reply]
There is the usual, but no other country seems to have such a successful and dedicated group of editors using marginal sources and culling only the bad information from more mainstream sources to make Pakistan look like a terrorist state. That AN/I conversation about Pakistan would not have run that way about any other country. The bias is there; it's been going on for a long time, and it crops up all the time at AN/I, but, for some reason, probably the friend packs of one of the major perps, it is entrenched and permanent on Wikipedia. Also, because of the reason these articles were created, so few editors participate in creating articles about Pakistan. -Fjozk (talk) 01:50, 1 November 2012 (UTC)[reply]
If there is no pro-Pakistan bias, please explain why we have kept so much poor quality material for so long, material-- which you yourself aacknowledge to be "pure crap" ? Why do we need material which is "pure crap", except to pander to Pakistani sentsitivities?OrangesRyellow (talk) 02:56, 1 November 2012 (UTC)[reply]
The pro-Pakistan posse is creating hundred of illegible, incomprehensible articles because a pile of crap shows their national pride? Sure, you're the expert. -Fjozk (talk) 03:42, 1 November 2012 (UTC)[reply]
Who created what is usually among the least of my concerns. Word acrobatics and bias accusations apart, I am yet to see a good reason to continue to host "pure crap" and "hundred of illegible, incomprehensible articles " (your wordings). If there is any good reason to continue hosting such material, please enlighten me.OrangesRyellow (talk) 06:23, 1 November 2012 (UTC)[reply]
I think Fjozk's point is mass deletion won't solve the problem, or at least that part of the problem the editor refers to. The same editors, per Fjozk, will put the same stuff back in unless there is more oversight from the WP community as a whole, which this proposal does nothing to achieve. The samples of the articles posted here, however, reveal other problems: the articles on villages seemingly are on non-notable topics (since they only have a line or two, I am not sure how WP:TNT applies); the promotional articles are put in by the subjects themselves and salting would be required to stop that. Fjozk needs to post examples of the NPOV-breaking anti-Pakistan stuff to see whether it is obvious on a cursory examination; if so, I guess editors (I included) can probably just watchlist the page and revert. If it requires some deeper knowledge, I guess we are stuck. Churn and change (talk) 20:14, 1 November 2012 (UTC)[reply]
Unfortunately it not only requires deeper knowledge, it requires a community willing and able to discern facts: a newspaper has an article about Pakistan, it gives 10 good points and 1 bad point, adding that one bad point to an article about Pakistan without any of the good points is usually bias, systematically and repeatedly doing so in hundreds of articles is bias. I have repeatedly pointed this out; one of the editors who does this has been blocked numerous times, but, because he is the right age and gender and techno-time-on-line to be comfortable on Wikipedia, all that ever results in dozens of Wiki-buddies come in and defend his right to do whatever he wants on Wikipedia. I gave up long ago, but I will keep mentioning it, so that when it comes back and bites Wikipedia's ass, fewer editors can say they were cluelss. But, you are right, there are much bigger problems in the area of Pakistan articles, and this mass deletion will create bad will without addressing any of the problems. If these villages exist, then Wikipedia should have an article on them, as Pakistan censuses and governments generally call even the smallest villages as notably "legally recognized, populated places." To start mass deleting notable places is not a proper use of time resources. I suggest creating a subpage of the project, adding a link to it at the project page and talk page, and maintaining a list of the worst of these articles that need clean up. -Fjozk (talk) 06:58, 2 November 2012 (UTC)[reply]

Dr. BLOFELD edits with bad English: "and then built up with standard of quality," "there's too many articles," "information ... is much better being removed"; bad references; and bad writing. Wish the serious ones had a better editor speaking for them. 130.65.109.102 (talk) 00:12, 2 November 2012 (UTC)[reply]
I would support a cleanup campaign - whether removing crappy content from articles, or deleting articles altogether. There are thousands of articles in a disgraceful state, which reflects very badly on en.wikipedia and does readers a disservice. Some articles are OK, of course; we don't have to nuke those. I don't want any conflict with the good Dr Blofeld but I do have to point out that these articles got into such a state due to insufficient watchlisting by competent editors, which is a consequence of the mass production of many thousands of settlement-stubs, rather than letting settlement articles get built (and cared for) the same way as other articles. bobrayner (talk) 23:28, 4 November 2012 (UTC)[reply]

Oppose categorical deletion, because we should have an entry for valid locations. But I totally support thorough clean-ups as was done for Jayya. As was already mentioned, the problem is even more serious for biographies. Most are either vanity or tribute articles. In that case, I would support total deletion. -- P 1 9 9 ✉ 15:09, 9 November 2012 (UTC)[reply]
Reduce Edit conflicts
I suspect that we all know that edit conflicts suck. I've lost hours of work due to edit conflicts, and that's despite me being fairly adept at copying and pasting to resolve them. I think that the system could handle edit conflicts much better, and that this site would be a nicer more productive place if we had better ways to minimise edit conflicts and recover from them afterwards. If anyone could measure the proportion of newbies who'd had an edit conflict in their first ten edits I bet A it would be high and B it would be a good predictor of people who go away because Wikipedia bit them. I've raised a bugzilla request including several possible minor improvements, such as defaulting all new pages created in mainspace to include

==references==
and
{{reflist}}
OK you'd be deleting those lines each time you created a redirect or dab page, but deleting them is quicker than typing them, it might prompt some newbies to actually add references, and it will prevent edit conflicts between people categorising new articles and others adding sentences.
Another easy fix would be to disable the edit button for very busy articles. Experienced editors already know that if a page is going to be busy you edit a section and you don't try to edit the whole article. So to reduce edit conflicts on "trending articles" and very busy pages such as Jimbo's talkpage, the system needs to automatically notice which articles are busy and when anyone clicks the big edit button at the top of a busy page render: "Sorry, but this page is currently very busy, so to reduce edit conflicts you can only edit one section at a time. Please pick the section you want to edit", then give them a choice of sections.
In an ideal world we'd can things like the article feedback clutter thing and focus some serious development on this. I'd like to see a whizzy system where when I had an edit conflict it showed me the result of my edit and the intervening one and gave me an option to save the consequent combined edit. However I don't know the capabilities of the system well enough to spec that. But there are several small and hopefully uncontentious changes could be easily coded and which in combination would greatly reduce edit conflicts. Ϣere SpielChequers 16:54, 25 October 2012 (UTC)[reply]
Note that disabling the edit button for very busy articles would do exactly nothing: when you submit an edit to a section, MediaWiki takes the revision that you started editing, replaces the one section, and then proceeds as if you had edited the entire page and just happened to make changes only to the one section.

Similarly, there is not really any way for MediaWiki to show you what the consequent combined edit would look like. If MediaWiki is able to combine the edits, it already automatically does so and saves the combined edit without ever bothering to tell you. An edit conflict happens when MediaWiki cannot figure out the combined edit because your edit and the other person's edit changed the same area of the page, so it would have to basically throw away one or the other. Now it's possible that the merging could be made smarter somehow (I haven't looked too closely, but at a glance it looks like it just uses diff3); that's probably your best bet for improvement. Anomie ⚔ 18:42, 25 October 2012 (UTC)[reply]
I should clarify one thing: there are a few other situations that might cause an "emergency edit conflict", e.g. if two edits come in at almost the exact same time such that one gets saved in between the other doing the check for edit conflicts and it actually writing to the database. But that won't be helped by anything besides shortening the time between the first check and the final save. Anomie ⚔ 18:49, 25 October 2012 (UTC)[reply]

If you try to edit three sections of a busy page as three separate edits you are much less likely to get an edit conflict than if you edit the whole page and try to save an edit that involves changes in multiple sections. So yes directing people to individual sections will make a difference, maybe not for the people who just want to change one or two words, but then they don't lose so much when they get an edit conflict. If there is already a bit of smart merging taking place then that's great, but we need more of that and smarter. For example the software should be able to recognise that one person adding a template and a link in a see also section and another adding a category are not incompatible merges, we just need to improve Mediawiki to handle more edit conflicts without losing edits. This is important, when did you last get an edit conflict in Facebook? Ϣere SpielChequers 21:19, 25 October 2012 (UTC)[reply]
Facebook doesn't have anything that could conflict. I would suggest Google Docs though.—cyberpower _Online^{Trick or Treat} 23:08, 25 October 2012 (UTC)[reply]
I believe the team with Oliver Keyes (Ironholds) is thinking about working on a better edit conflict mechanism. See the MediaWiki Micro Design Improvements page. David1217 ^{What I've done} 17:07, 26 October 2012 (UTC)[reply]
Apart from a vague commitment to improving the workflow, their main approach is still to tell people that an article is being edited. This is better than the thankfully abandoned proposal they made during newpage patrol to allow anyone to stop others editing an article simply by opening it in an edit window. But I don't believe that there would be much benefit, and there could be various disbenefits including greater complexity to the editing interface, an easy opportunity for trolls to cause edit conflicts by doing quick minor edits to articles they knew to be being edited, or alternatively if they went back to their previous idea of "reserving" articles, the spammers would quickly learn to create and immediately reopen it for editing so as to keep their spam up longer, even goodfaith editors would be tempted by the idea that you no longer need to edit just one section if you can reserve the whole article to yourself, and consequently some of our most heavily edited articles would suddenly become much harder to edit. As for my proposals, feedback I've had so far on Bugzilla includes that simply having the software recognise each thread starting with a hash as a separate paragraph would be easily done and would greatly reduce edit conflicts on talkpages. I'd like to get much more change than that, Ϣere SpielChequers 22:51, 26 October 2012 (UTC)[reply]
Support first part: Adding "References" and reflist in all new articles is a good idea! Most probably I saw a post somewhere else where it was suggested to appoint a bot to do the task! Nut, new users (some users) may not understand that they need to delete those if they are creating a dabpage and redirect! So, a note too? Or it'll be too complex? --Tito Dutta (talk) 05:04, 5 November 2012 (UTC) typo correction not → note signed --Tito Dutta (talk) 05:10, 5 November 2012 (UTC)[reply]
To avoid edit-conflict, re-edit+merge+save
See essay: "wp:Avoiding edit-conflicts" (wp:AEC)
After years of few improvements, I finally deduced the solution, for an experienced editor: proofread changes separately (2nd window), then re-edit, merge and save. It is just that simple, as if an editor could edit, write, and save all within 15 seconds. Now, the recent exception has been a bug that causes a "ghost edit-conflict" when no other editors are actually there. However, remember this simple 4-step fix:
STEP 1: Edit a section to prepare/proofread the updated text for merge.

STEP 2: Re-edit the section (if gone, review the whole page).

STEP 3: Merge the proofread text into the re-edit window (quickly).

STEP 4: Save as rapidly as safe, for your level of confidence.
It might be difficult to believe that years, of endless edit-conflicts, can be solved simply by re-edit & merge, but the reality is that a 15-second re-edit timeframe is often enough to avoid the conflict. I wish you Happy editing in the future. -Wikid77 (talk) 00:53/02:00, 27 October 2012 (UTC)[reply]
Good idea. -Fjozk (talk) 16:29, 31 October 2012 (UTC)[reply]
Complicated articles
Most articles in wikipedia, especially the important ones, are far too long and too complex to be understood by the average and below-average readers, who constitute a more than substantial portion of our readers. Adding an infobox at the top of the article linking it to the corresponding 'Simple English' articles [for only those Simple English articles which are rated 'Good' or above] will help a majority of the readers to understand the topic in simple words. {If required, they can always refer back to the original article to go in-depth} Inamos (talk) 19:07, 27 October 2012 (UTC)[reply]
Infoboxes are a good thing, at least in my opinion. I am worried about linking to Simple, however, as the project is largely dead. Sven Manguard Wha? 21:12, 27 October 2012 (UTC)[reply]
The implication that the majority of readers here can't handle regular English seems uncredible. I would want to see some sources before accepting that.

To the extent that "Simple English" is the 850-word vocabulary and restricted grammar of Basic English I don't see how it reduces these alleged problems of length and complexity. It may be fine for teaching English at a beginning level, but many topics require a fuller command of the language. If you try to explain complex concepts simply, using only "simple" words, you necessarily make the text longer, so there's a trade-off. If an article really is too convoluted, then that should be fixed, regardless of the size of the vocabulary used.
Simple does not necessarily mean longer. Take a look at a random important article - Violin and its simple version Violin. Which one do you think gives the information in a shorter way to a reader who has heard about a something called Violin for the first time? Some complex articles may be non-simplifiable, but those will only constitute a section of them. Even for articles requiring complex words, you can have an understandable simple version. Look how well Jupiter has done

And for the record, I said substantial, not majority. 30% is also substantial, while only 50+% will be a majority. Inamos (talk) 20:02, 28 October 2012 (UTC)[reply]

That some articles can be adapted for the use of those with limited vocabularies is fine, and I think a link like any other language would be quite satisfactory. ~ J. Johnson (JJ) (talk) 21:36, 27 October 2012 (UTC)[reply]
You'll already find interlingual links under "languages" on the left-hand column. Simple English is one of those languages. I don't know why we'd need more than that. --Philosopher ^{Let us reason together.} 22:42, 27 October 2012 (UTC)[reply]
Strong support I was planning to ask about it. We are not giving any consideration for Simple English. It is treated just like another language. Please give this Simple English some emphasis.

...the project is largely dead.: Actually this is going to be good for whole of the WMF including enwp. enwp is visited by a very large number of potential editors who falls out because they have got nothing to edit. Seeing the Simple allows them to contribute into it. (For an outsider, the only way to expand Wikipedia is by adding more info and correcting visible problems - which can be done easily in Simple). just after having a number of edits and days, they will learn more about this and hence become a part of the wikimedia community. After all, there are no side-effects for enwp. So IMHO, what should be discussed here is the way we should give the emphasis to Simple Discuss for the best way possible.

... why we'd need more than that: All of the languages given in the language box except the Simple are only useful to a very few part of the readers. But Simple English is helpful to all the people coming here in enwp (even to the BE 1500 people as they too can read it if they want to have a simpler version.) And no one, unfamiliar with WP, would expect a Simple English Wikipedia under the language box···Vanischenu^「m/_Talk」 23:36, 27 October 2012 (UTC)[reply]
This proposal is being made under the mistaken assumption that a general encyclopedia should be accessible to someone who isn't that proficiant in English. That's not the case. The majority of articles ARE fine in this respect, and the majority of articles that aren't are in depth technical topics anyway. As for 'emphasizing Simple English WP', well while I agree that it perhaps should be better known, strewing it all over EN-WP would just cause huge backlash from people. And probably look ugly. ♫ Melodia Chaconne ♫ (talk) 00:12, 28 October 2012 (UTC)[reply]
I think the infobox can be presented in a way that looks good with articles. In any case, all the articles we will be adding them to for now will be the most important ones, implying that they are already heavily crammed on the top. I kindof like the way Uncyclopedia presents the link to Wikipedia articles Inamos (talk) 20:02, 28 October 2012 (UTC)[reply]

One thing that could possibly be done is list Simple English first, instead of alphabetically. That does not require anything but doing that. One article buries it here:
Afrikaans Alemannisch العربية Aragonés ܐܪܡܝܐ Asturianu Avañe'ẽ Aymar aru Azərbaycanca Bamanankan বাংলা Bân-lâm-gú Башҡортса Беларуская Беларуская (тарашкевіца)‎ Български Bosanski Brezhoneg Català Чӑвашла Česky ChiShona Cymraeg Dansk Deitsch Deutsch Eesti Ελληνικά Español Esperanto Euskara فارسی Français Gaeilge Gaelg Galego 贛語 한국어 Հայերեն Hrvatski Ido Bahasa Indonesia Interlingua Interlingue ᐃᓄᒃᑎᑐᑦ/inuktitut Ирон IsiXhosa Íslenska Italiano עברית Basa Jawa ქართული Қазақша Kinyarwanda Kiswahili Коми Kreyòl ayisyen Kurdî Лезги Latina Latviešu Lëtzebuergesch Lietuvių Lingála Lumbaart Magyar Malagasy മലയാളം मराठी مصرى Bahasa Melayu Mirandés Монгол မြန်မာဘာသာ Nāhuatl Nederlands Nedersaksisch नेपाली नेपाल भाषा 日本語 Nnapulitano Norsk (bokmål)‎ Norsk (nynorsk)‎ Occitan Oʻzbekcha पाळि پنجابی Tok Pisin Plattdüütsch Polski Português Ripoarisch Română Runa Simi Русиньскый Русский Саха тыла Scots Shqip Sicilianu Simple English SiSwati Slovenčina Slovenščina Soomaaliga Српски / srpski Srpskohrvatski / српскохрватски Basa Sunda Suomi Svenska Tagalog தமிழ் Taqbaylit Татарча/tatarça తెలుగు ไทย Тоҷикӣ ᏣᎳᎩ Türkçe Українська اردو Tiếng Việt Walon Winaray ייִדיש Yorùbá 粵語 Žemaitėška 中文 Apteva (talk) 02:52, 28 October 2012 (UTC)[reply]
By the way, encyclopedias are not written for second graders. There is a point around the 4th or 6th grade where they become useful. Not sure where exactly. Apteva (talk) 03:01, 28 October 2012 (UTC)[reply]
Yes. And a good part of their usefulness is in leading the reader — of all ages — beyond what they already know. ~ J. Johnson (JJ) (talk) 19:52, 28 October 2012 (UTC)[reply]
Your perception of what an encyclopedia should constitute does not actually make it the rule-of-thumb for encyclopedias. An encyclopedia serves as a source of information for people, and its main objective shoudl be to state all the facts as well as to ensure readiblity. Compromising understandablity on the premise of 'leading the readers' is not what an encyclopedia should be doing. Inamos (talk) 15:52, 31 October 2012 (UTC)[reply]

I'd support having the simple: interwiki listed at the top of the languages listing, but outside of that, I don't think we should be going out of our way to push readers over there; yes, perhaps some people don't understand it, but I'd like to actually see some justification that "more than substantial portion of our readers" are below-average readers. Sometimes we're just going to be too complex for the reader; I have an excellent grasp of English (in no small part due to it being my native tongue), and I'd be hard pressed to say that I completely understand quantum mechanics; that's not the fault of the project. EVula // talk // ☯ // 17:32, 28 October 2012 (UTC)[reply]
Some articles, especially science related ones, will only be able to be simplified that much. But for most articles, there will be a lot more simplified way that the article could have been presented. Inamos (talk) 19:44, 28 October 2012 (UTC)[reply]
I totally agree to Vanischenu on the 'dead project' front. That is exactly how I got there in the first place Inamos (talk) 19:44, 28 October 2012 (UTC)[reply]

As for concerns on the 'Below-Average' readers front, I would like to draw your attention to the new 'Reader Feedback' for Wikipedia pages. [This was why I thought of this proposal in the first place].

Chess - As you can see, most of those reviews have sub standard English, implying that having a simpler article will benefit. More importantly, see these comments - 1 2 3. All three ask for simpler words, but they did not know where to get it [The Simple wiki]. Also, see these- 4 5 6 7 8 9 10. All of them ask for some detail or the other which is more than sufficiently covered in the article itself, or its connected articles [all of which are accessible IMO]. This obviously implies that the jargon has caused an inability to get the actual information out of the article.

Jupiter - Same logic as above. Information already present problem - 1 2 3 4 5 6 7 8 9 10 11 12 13. Asking for simplicity problem - 1 2 3 4 5 6
[I have not tried to specifically verify if all the information asked for is present or not, but certainly almost all of it is. In any case, the general case is clear. Quite a handful of our readers find wikipedia hard to cope with. I am positive other reader feedbacks should also throw up similar results] Inamos (talk) 19:44, 28 October 2012 (UTC)[reply]
~~[offtopic] Aren't we supposed to vote here? Support Inamos (talk) 19:44, 28 October 2012 (UTC)~~[reply]
Your perception of a possible problem not an adequate basis for proposing a fix, and lacking any verification it is not clear that such a problem is general. I am sure that some readers do find Wikipedia "hard to cope with". But in failing to show how big of a problem that is, or even if it's a matter of "too many words", I do not see that your proposal would be of any use. ~ J. Johnson (JJ) (talk) 23:08, 28 October 2012 (UTC)[reply]
We vote when there's something to vote on, Inamos. You have presented a topic for discussion, which is why there's discussion. As your "proposal" stands currently, nobody is going to vote "for" it, based on the fact that you've inadequately established that there's a problem that needs to be solved. EVula // talk // ☯ // 23:40, 28 October 2012 (UTC)[reply]
My bad. Must have misunderstood it or something. ^^ I think i did show that it was a case of people finding the wiki too complicated.Inamos (talk) 23:50, 28 October 2012 (UTC)[reply]
Some of that feedback is irrelevant. If people want it written so children can understand it better, then they don't want Wikipedia in the first place. If they want to know stuff that's in child articles, then they are too lazy to care to find the quite obvious links to child articles at the top of the section. In the case of Jupiter, some of the comments ask "who discovered it", yet right in the lead it states "The planet was known by astronomers of ancient times" -- anyone who fails to understand that simple sentence needs something else besides Wikipedia to get their info. I'm not trying to be harsh here, but really, the problem isn't with the Wikipedia, it's with people expecting the wrong thing. Wikipedia is an Encyclopedia. ♫ Melodia Chaconne ♫ (talk) 02:31, 29 October 2012 (UTC)[reply]
It isn't a question of removing the completeness of an article to be replaced by an oversimplified version. There are two ways to deal with the issue that is being noted here:
For long articles or large topics, they can be covered with "Overview" or "Introduction" articles, for example Introduction to quantum mechanics exists and yet no one had to remove the more technical Quantum mechanics.

For shorter articles or more narrowly focused topics, Wikipedia could greatly benefit from additional text which explains the topic for someone without the technical expertise to understand it. Magnetic monopole does a pretty good job of this, as it includes straight-forward, easy to understand text for the casual reader, and also has the dense mathematical language for the more technically-minded reader.

Many Wikipedia articles in the technical fields, however, don't have a good balance. In general, they are written by the expert, for the expert, and usually for a very specific kind of expert, you can have a pretty good knowledge of Physics, for example, and still be lost in many of our esoteric Physics articles. --Jayron32 03:42, 29 October 2012 (UTC)[reply]

Some of that feedback may be irrelevant, but to think that most of it is would be plain callousness. Its understandable that Wikipedia is an encyclopedia, and hence has its own standards, which may or may not match with the reading abilities of the people. But at the same time, it is by the people and for the people. If a good number of people find it hard to follow, then there ought to be something that can be done about it. Amazingly, we already have a mechanism to push that sort of balance - Allowing the outsider to Wikipedia understand articles in the same light as a Wikipedian would do for a normal article - The Simple English wiki [Personally, I do feel wikipedia as a community is way too restrictive to allow newcomers, and is inherently discouraging to any new reader/writer.] Inamos (talk) 07:25, 29 October 2012 (UTC)[reply]
If. It is not yet shown that "a good number of people find it hard to follow", let alone why that might be. Where someone's reading comprehension falls short I am fine with trying to enourage them to get better. However, the solution is not to restrict articles to a vocabulary of 850 words, but to promote interesting, well-written articles. ~ J. Johnson (JJ) (talk) 21:43, 29 October 2012 (UTC)[reply]
I believe I already showed that a good number of people find it hard to follow. Unless anybody comments on/follows up on/disputes with my 'proof' that a good number of people do not understand it, and that its mainly because of complicated articles, I doubt there is any reason to treat that It is not yet shown that "a good number of people find it hard to follow". [If there is any rule on wikipedia which says that a justifiable claim is untrue just because nobody has checked up on that, please let me know].

There is nothing that is being done to the existing articles, so I doubt we are restricting them in any way. All that I suggest is to link to a simpler version of the article, for those who find the present well-written version hard to comprehend. What is well written may not necessarily be easy to understand, especially not for an encyclopedia. Inamos (talk) 15:52, 31 October 2012 (UTC)[reply]
If all you wanted is a link to a simpler version of the article: fine, use a language link. But what you were asking for is an infobox. And you have not shown that this alleged problem warrants action, nor that Simple English even addresses the alleged problem of complexity and length. As there are some grounds to believe your claims are invalid, it is really up to you to show us otherwise. As that seems unlikely, why not settle for a language link? ~ J. Johnson (JJ) (talk) 20:41, 31 October 2012 (UTC)[reply]
My error. My intention was to say 'infobox', I ended up saying link.

I do not understand what more can be done to show that this problem warrants action, other than showing that this problem exists [If there are any such avenues, please point them out and I shall try to do the necessary.] Regarding the problem of complexity and length, I think I did say about it in my comment on 20:02, 28 October 2012 (UTC). So I believe the status quo stands as that there has been shown that there is a problem [whether or not that claim is true has not been discussed, so its incorrect to assume anything on that front] and that there is nothing said which shows that there are some grounds to believe my claims are invalid [If I may have missed any arguments, do point them out. I do not read minds, so if it isn't something which hasnt yet been written (but is obvious), I failed to understand that. My apologies].

As for the language link, if it so happens that Simple English is the first link that appears among all the languages, then it is something to consider. [An infobox will be a much more preferred option though for the simple reason that it provides the much needed highlight for readers who wish to work on articles (Pretty much similar to why we have DYK on the main page) while showing them, at the same time, that there is a simpler version which they can consult should they be unable to understand the complex vocabulary of some of the English wikipedia articles.] Inamos (talk) 10:30, 1 November 2012 (UTC)[reply]
I believe you have not been persuasive here. If there is no more that you can do, then it is probably a waste of time to spin your wheels, and I would suggest that you might be more satisfied letting this go and working on some other issue (or article). ~ J. Johnson (JJ) (talk) 01:51, 7 November 2012 (UTC)[reply]
Your belief on whether or not I have been persuasive is irrelevant. What is important is whether or not the statements are correct, and whether or not the community agrees to it. I doubt I shall agree to a premature decision based on what you think.

And since you have failed to respond to my point, i believe it is now safe to assume that there does exist a 'complicated articles' problem on wikipedia that needs to be looked into. [If i m wrong, plz do tell me] Inamos (talk) 15:33, 8 November 2012 (UTC)[reply]
Sure: you are wrong to assume that there is a problem. And I did respond to your point (here). My belief that you have been unpersuasive is based on the observation that you have not presented a persuasive case, and that (with one exception) the others here appear unpersuaded. You have not been persuasive in demonstrating the validity of your premises, or that Simple English versions would be less complicated (in my first response to you I argued that they could be longer). And even if you were correct in all these regards, you have not shown why an info box is needed to help people find Simple English versions. If you are not convinced, then ask for a poll on whether there is a "complicated articles problem that needs to be looked into." If there is a strong "no" you should consider that you are just spinning your wheels. ~ J. Johnson (JJ) (talk) 21:39, 9 November 2012 (UTC)[reply]
Add noticeboards for the article categories listed on Request For Comments
The proposal is to add noticeboards for the 9 article categories listed on Request for Comments (Wikipedia:RFC/A) similar to the Biographies of Living Persons noticeboard. The 9 categories would be Biographies; Economy, trade, and companies; History and geography; Language and linguistics; Maths, science, and technology; Art, architecture, literature, and media; Politics, government, and law; Religion and philosophy; and Society, sports, and culture. This would be to help improve decision-making on content. Part of the reason for this would be that many low-traffic pages don't get much editor input, even from RFC's, and bringing content disputes to a board on the article's general category might bring greater involvement by other editors in resolving content disputes, including editors knowledgeable in the subject. Psalm84 (talk) 02:40, 31 October 2012 (UTC)[reply]
Do you know how many threads can be expected to be active at any given time on one of the boards? That is a real question, not a rhetorical one. Churn and change (talk) 02:48, 31 October 2012 (UTC)[reply]
Well, first I'd say that a dispute is encouraged to be worked out on the Talk page first. This wouldn't be to replace them. But this would be an alternative for RFCs, especially for pages that don't get a lot of traffic, like pages such as the Presidential election do. So there might be similar numbers to what's on the RFC page now. Some disputes might also be taken to these boards rather than Dispute Resolution too. Psalm84 (talk) 02:55, 31 October 2012 (UTC)[reply]
Okay, so that seems ten or so for the more disputed categories. Looks manageable. I take it your suggestion is to have the actual discussion on the noticeboard, and transclude it on the article's talk page? One issue I see is that some pages such as the MOS talk page are better quarantined from any common noticeboard. This recent RFC on Wikipedia_talk:Manual_of_Style/Archive_131#RfC:_Internal_consistency_versus_consistency_across_articles generated 31,000 words, not including further debates on the RFC procedure itself. I would say editors should be given leeway to kick a discussion back to the article's talk page if it is dominating the page; the purpose should be to give more visibility to the disputes in the more obscure corners. Churn and change (talk) 03:28, 31 October 2012 (UTC)[reply]
Yes, that would be the purpose, to give more visibility, and the discussion would be on the noticeboard. Length would be a concern probably in some cases but options for those cases could be discussed, including the one you mention to move the discussion back to the talk page. Psalm84 (talk) 03:56, 31 October 2012 (UTC)[reply]
Okay, and thanks for rephrasing the "kicking out" as "moving discussion back." One other issue is cross-posting to multiple boards. I think we should allow RFCs to be posted on one particular board to be cross-linked from others (that is, with wikilinks to the discussion posted at other boards). Also, looks like transclusion to the article talk page won't work; only an entire page can be transcluded, not a part of it, but posting a link to the discussion on the article's talk page should be sufficient. Churn and change (talk) 15:56, 31 October 2012 (UTC)[reply]

No, I don't think transclusion would work, but as you say, a link on the talk page should be sufficient. I'm not quite sure if I followed what you said on the cross-linking, though. What other boards should have wikilinks? Do you mean for the different types of article boards, like History (etc.) and Math (etc.), or just for discussions within a topic, like within History? Psalm84 (talk) 05:40, 1 November 2012 (UTC)[reply]
Tranclusion would require that each discussion occur in a sub-page, the problem with a transclusion based solution is that it makes watchlisting a pain, as you wont see comments in your watchlist just because you have the talk page or noticeboard watchlisted, you would only see the one time transclusion of the subpage. This could result in concerned editors being blindsided when a consensus is reached on a topic they are interested in, and they missed the one watchlist change that signified it starting. More generally, the mechanics pose a couple problems, first it would make it harder to start an RFC, you will no longer be able to just throw on an RFC tag, but will need to set up multiple transclusions and the sub page.

Yet a non-transclusion approach has even bigger problems. Say I want to hold an discussion about something in the article Ben Bernanke, who falls into at least bio, econ and politics. Which noticeboard gets the discussion? I can imagine there being disputes over venue, turf wars, or gaming to try and get the discussion to the noticeboard deemed most favorable. The whole thing seems like a giant can of worms, and I'm not convinced the goal, getting more discussion for obscure topics, would have any more luck at a notice board then via the current RFC system. Monty ₈₄₅ 05:54, 1 November 2012 (UTC)[reply]
I agree about the transclusion approach. I don't suggest that. On gaming and turf wars happening, no offense, but don't they happen already? To some extent that just seems impossible to avoid with anything. On what board to put a topic like Ben Bernanke, with only 10 boards, there could be a way to put a notice of something that might be of interest on the other boards besides the one chosen, for example, or to cross-post them. What the dispute is about, too, might help, like if it's more about economic policy, or more something about Bernanke's personal life. But cross-listing or cross-posting probably wouldn't involve too many categories, and in some cases if it brought editors from a few categories that actually seemed involved in the matter, that could be beneficial. There also aren't really that many RFCs, too, and this isn't to replace the talk page, as I said, so that would seem to keep it simpler than if there would be hundreds or even thousands of discussions going on these boards. That would be very confusing. Psalm84 (talk) 06:19, 1 November 2012 (UTC)[reply]
I too withdrew the transclusion suggestion, so that is off the table. I don't think cross-listing, which was what I was referring to earlier, is much of a problem. Editors can just pick a "host" board, and cross-link from other boards they think should be involved. That is no worse than the current situation where the "host" board is the article talk page and all RFC boards have just links. If editors can't agree on a "host" board, they could default to existing behavior: host on a neutral (say article's talk) page and cross-link from everywhere else. Based on my experience of editing far more in article space than in project or talk space, I would say scenarios where article editors can't even agree which the primary board for an RFC should be are rare. Churn and change (talk) 15:27, 1 November 2012 (UTC)[reply]
What I'm wondering about is what to do next about this proposal. Is it best to just keep taking more comments about this here, or should this be posted elsewhere? Psalm84 (talk) 04:17, 2 November 2012 (UTC)[reply]
I think you should leave it here for a while and then take it to WT:RFC. Since RFCs are neither policy nor guideline, what you are asking for is basically to change the text in WP:RFC and so that article's talk page seems the best bet. Churn and change (talk) 04:31, 2 November 2012 (UTC)[reply]
Okay, I'll do that. Thanks. Psalm84 (talk) 04:32, 3 November 2012 (UTC)[reply]
Shrinkable articles
Many articles (especially the most important ones) are terribly, overwhelmingly long, and you can't separate the wheat from the chaff without wasting several hours to read all details you are not interested in. Why can't we add a scroll bar, which will allow to adjust the size of the article to the user's needs? Let say, it has 5 positions, with 1 corresponding to a brief overview of ~300 words, 2 to ~1000 words, 3 to ~3000 words, 4 to ~10000, and 5 corresponding to a dedicated article of ~30000 words (for small articles only the first one or two positions are available.) All these 5 articles can be stored separately under different names (let say, Article_name, Article_name_2, ..., Article_name_5), can be edited separately, can be separately nominated for good and featured articles etc, though probably in most cases article of the kind n will be written as an abridged version of article n+1. Of course, it'll be a big effort to write such shortened versions, but if we succeed to do it for at least 10000 most important articles, it'll substantially improve the efficiency of Wikipedia for most users. This doesn't even need any new features to be programmed (the scroll bar is a fairly plain template), only the political will to allow and standardize creation of such articles. Oleksiy.golubov (talk) 20:27, 1 November 2012 (UTC)[reply]
Are you volunteering to write the 40,000 additional articles that "succeeding to do it for at least 10000" would entail, not to mention coordinating the four additional rewrites that would be required every time any of the five versions was changed? People seem much keener to think of solutions than to volunteer to put them into practice.

If you want "edited highlights" versions of Wikipedia articles, Qwiki is probably what you're looking for. Mogism (talk) 20:32, 1 November 2012 (UTC)[reply]
The point is that if we don't have this feature for most articles, it's not a problem at all, the users will just read the full versions. But if we have the feature for some articles, it's already useful. So I'm just suggesting to allow this feature. Of course, I'm volunteering to write 20 or 50 shortened articles on the topics I'm working on, as I think many other specialists will volunteer to do for their topics if we give them such an opportunity. I mostly write articles in Russian Wikipedia, but I decided first to discuss this idea here, as English Wikipedia is usually the first to implement innovations. I know English Wikipedia rather as a reader, than as an author. But sometimes when reading English Wikipedia (especially on USA-related topics) I have to switch to other languages, where the articles are shorter. Oleksiy.golubov (talk) 20:59, 1 November 2012 (UTC)[reply]
Scroll-bars are variable, implying a continuous range, not just four or five or even fifty pre-set sizes. The only practical way of implementing that is some process that dynamically scales articles. Which likely requires kinds of linguistic processing not yet attained. Alternately, if for some number of articles you wanted a shorter version, well, perhaps there could be some sort of name-space suffix (like "~1"?) that could be used to distinguish alternate versions of otherwise identical names. Then there could be a "Shorter version" info box that connects to the next version. And then all that is needed is ten- or twenty-thousand rewrites. ~ J. Johnson (JJ) (talk) 21:29, 1 November 2012 (UTC)[reply]
No, it's too complex. Maybe, you were mislead by the term "scroll-bar". I should better have said "a Wikipedia template slightly resembling a scroll-bar and having 5 positions". I think 5 sizes with the step factor of 3 are enough, but this must be discussed further. Oleksiy.golubov (talk) 21:41, 1 November 2012 (UTC)[reply]
Have you looked at the simple English wiki for corresponding articles? Not belittling your clearly good command of English, but my impression is that those articles tend also to be shorter. That is only one alternative but might either be enough or serve as an introduction to the :en: article. --Mirokado (talk) 21:58, 1 November 2012 (UTC)[reply]
Well, it's possible to go to simple English or Russian, or if I want an even shorter introduction to go to Ukrainian. But I'm proposing to do it more systematic and flexible. Am I really the only one who reads Wikipedia several hours per week, but has never finished reading any featured article because they are too detailed? And who, when supplementing articles, thinks: "Well, what I'm adding is very interesting for a real geek, but it'll only distract a non-specialist. So what should I do?" Oleksiy.golubov (talk) 22:15, 1 November 2012 (UTC)[reply]
If you're dealing with articles at Featured Article level - which seems to be your suggestion - the lead section is a summary of the article, so if you only want an overview just stop when you reach the Table of Contents. Aside from a very, very few highly technical topics where a "layman's version" makes sense, your proposal would literally make Wikipedia five times more difficult to maintain, since what you appear to suggest is manually writing five separate versions for every one of our 6,919,403 articles. Mogism (talk) 22:24, 1 November 2012 (UTC)[reply]
Yes, a level 1 article roughly corresponds to the Introduction section of a level 5 article, but there's a huge uncovered space in between. The experience of "layman's versions" is really very valuable, and I'm just proposing to use it more extensively. I think that using simple English or patching the worst gaps with "layman's versions" is just a partial solution of the problem, and it's time to do the next step. Most articles are short, so I don't expect that my suggestion could touch more than 3% of all articles, and such shortening is indispensable for much less than 1% of all articles. Of course, even they will require much effort to be re-written. And I think these are editors who must decide whether an article should be abridged or not, and thus vote with their work for or against my proposal. I'm just proposing to give them a possibility to decide. Oleksiy.golubov (talk) 23:04, 1 November 2012 (UTC)[reply]
If a version suffix is used: the main version should be the unsuffixed form of the name ("<name>"). I would expect this to be the fullest, most complete treatment of the topic. Alternate versions, whether only one, or five, start at "suffix 1" (e.g.: <name>-1), the first version being the least different from the main version. If direction of the numbering (increasing) seem wrong, just consider it as proportional not to size, but to increasing shrinkage. ~ J. Johnson (JJ) (talk) 00:40, 2 November 2012 (UTC)[reply]
We can develop some naming standards, with the suffix number depending on the article size but independent of the total number of versions. E.g. there can be "<name>-1" and "<name>-3", without "<name>-2" which may or may not be created later. The "scroll-bar template" in the top of each version will show what other versions are available. The article "<name>" can be replaced by a redirect to one of the versions (additional recommendations are needed to specify which one). But the majority of articles will probably stay forever as a unique version called "<name>", without any counterparts or redirects. Oleksiy.golubov (talk) 01:27, 2 November 2012 (UTC)[reply]
Featured articles often also have a summary article that is used either on a portal or on the main page. It is possible that some sort of link to that summary (or to those summaries, but there really only needs to be one) could be created. Compare Portal:History/Featured article/13 with Wikipedia:Today's featured article/October 8, 2009 and Plymouth Colony. Apteva (talk) 23:29, 1 November 2012 (UTC)[reply]
Ha, I've never thought about that. But even more important are longer versions (intermediate between the abstract of a featured article and the whole article), and a simple interface to show to the reader that these versions are there. Oleksiy.golubov (talk) 23:47, 1 November 2012 (UTC)[reply]
Isn't this what the lede is for? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:25, 3 November 2012 (UTC)[reply]
Yes, the lead is for this, but for many purposes it's not enough. Sometimes you want a brief definition two phrases long, "a lead of the lead", but instead you are made to read a big overdetailed lead 3 paragraphs long. Sometimes you want some more details than are given by the lead, and would like to read something 5 times longer than the lead but 5 times shorter than the whole article, and you don't have this possibility either. Oleksiy.golubov (talk) 14:01, 3 November 2012 (UTC)[reply]
I support this idea. I often go to Simple English when I want a quick idea of something, since the introduction sections frequently don't give me what I want -- yet sometimes SE does. So, yes, for some articles this is a good start, but Oleksiy is correct that for some of our monster articles there is a mid-level (or levels) that are missing. Many's the time I have looked for general information beyond the absolute basics that amount to little more than a definition, and have simply given up on Wik/en and gone to Spanish or German or simply left Wik altogether and found my answer through Google or Britannica. I had never heard of Layman's versions. I went to the link but then when I went to the relevant regular article (I chose the first one, on algorithms), there was no readily visible indication of a layman's version existing. Of course, how to bell the cat is an issue, but I don't think we should throw out the baby just because it will be a big project: there are a lot of "who"s out there. Maybe we could add a tick-box to the set present on some Wik articles about the quality of the article. The tick-box could ask if the reader felt the need for an intermediate version (or versions). The articles so ticked (either at all or a certain number or percentage of times) could go to a lisst that we could look at just like the lists for speedy deletion and recent new articles.Kdammers (talk) 05:56, 5 November 2012 (UTC)[reply]
I'd propose a more straightforward program. 1) If the idea finds some support here, it can be put to request for comment. 2) If the idea is approved and elaborated there, we can start a project, which will aim at re-writing several hundreds articles, where this re-writing is the most necessary (~300 countries and states, ~300 cities, ~300 persons, ~100 historic events, ~20 planets and satellites). 3) As these are simultaneously the most visited articles, soon (after just a few such articles are re-written) everyone in Wikipedia will know about the feature; and if the society likes the idea, we can expect that many authors would like to invest some amount of their work in re-writing their favourite articles, both the ones mentioned in the project and the ones which are not as long and not as frequently visited. There are many "if"s, but even if the project has only a partial success, it'll still be useful. Oleksiy.golubov (talk) 14:19, 6 November 2012 (UTC)[reply]
This is a bad idea. This has the potential for serious contradictions and conflicts between the versions. It would require far too much extra work and coordination between them. I see no problem with long articles, in fact, most topics have far too little info. If you have a problem finding info you are looking for, it may be better to organize the info within an article better and add more subheadings. -- P 1 9 9 ✉ 15:03, 9 November 2012 (UTC)[reply]
I concur. ~ J. Johnson (JJ) (talk) 20:59, 9 November 2012 (UTC)[reply]
Spoiler Alerts should be posted on certain articles
I would like to suggest that "Spoiler" Alerts be posted at the heading of articles which summarize the plot of newly released films. I am a producer of "Skyfall" a film that was recently released in Europe but will not be released in the USA and other places until November9th. The entire plot of the film is set out in the Wikipedia article on the film. Even though the film has been seen and reviewed by hundreds of journalists none have disclosed certain elements of the story so as not to spoil the audience's enjoyment of the file.
My suggestion is that an notice be posted at the head of the article on Skyfall alerting the reader that the text includes spoilers. Michael Wilson — Preceding unsigned comment added by Mike90290 (talk • contribs) 08:21, 2 November 2012 (UTC)[reply]
Duplicate posting removed. --Philosopher ^{Let us reason together.} 08:24, 2 November 2012 (UTC)[reply]
Thank you for your comment. You might be interested in Wikipedia:Spoiler, which details why we don't have spoiler warnings on Wikipedia. If you would still like to propose that Wikipedia include spoiler warnings, it would be best to address the issues discussed there. --Philosopher ^{Let us reason together.} 08:30, 2 November 2012 (UTC) revised post[reply]
Looking at http://en.wikipedia.org/enwiki/w/index.php?title=Template:Spoiler&action=history it shows the talk page was kept at Wikipedia_talk:Spoiler/old_template_talk. Looking at the header of that page becomes clear that there was an RfC leading to the deletion, a subsequent DRV sustained the decision.LeadSongDog come howl! 13:33, 2 November 2012 (UTC)[reply]
Right, there's been (correctly, imo) a fairly solid consensus since the end of 2007 that spoiler warnings should not be used on Wikipedia. Which is why I pointed him to the Spoiler essay: If he wants to try to change that consensus, he's going to directly address those points. --Philosopher ^{Let us reason together.} 14:42, 2 November 2012 (UTC)[reply]
If someone doesn't want to be spoiled by the plot of a movie...then they shouldn't read the section called "plot". ♫ Melodia Chaconne ♫ (talk) 13:33, 2 November 2012 (UTC)[reply]
That is the thing. People who read the plot summaries are LOOKING for spoilers. A "spoiler warning" isn't going to do anything to stop them from reading the plod details and it is just a feel good CYA measure on the part of those GIVING the warnings. And let's not get started on the problem that labeling plot details as spoilers has with Wikipedia's core policies. —Farix (t | c) 14:21, 2 November 2012 (UTC)[reply]
Well, if someone doesn't want the plot of a movie spoiled, they can't read any part of the article. Spoilers are not found only in "Plot" sections. Angr (talk) 00:19, 3 November 2012 (UTC)[reply]
Maybe we can do the spoilers on a pay per view base. Send a dollar via PayPal to the WMF and you get the full text. Mindy Dirt (talk) 00:21, 3 November 2012 (UTC)[reply]
Is this sarcasm? If you're going to be sarcastic on the internet, you need to make it clear. Ryan Vesey 00:30, 3 November 2012 (UTC)[reply]
No one likes it when a 19-year old tells them what to do. Mindy Dirt (talk) 14:12, 3 November 2012 (UTC)[reply]

It seemed like a great fundraising suggestion. I was recently amused to see at the end of an old black and white movie the request to all patrons to not reveal the details of the plot to anyone - this is a movie that came out what over 50 years ago now? There are some movies, that not knowing a plot twist severely changes the viewing experience, but those are very few. Apteva (talk) 00:38, 3 November 2012 (UTC)[reply]
Apteva, what film was that? Does it have a Wikipedia article? Narutolovehinata5 ^tccsdnew 11:03, 3 November 2012 (UTC)[reply]
We do have an article for the movie - Witness for the Prosecution (1957 film). It ends with the voice over during the credits at the end - "The management of this theater suggests that for the greater entertainment of your friends who have not yet seen the picture, you will not divulge to anyone the secret of the ending of Witness for the Prosecution." Apteva (talk) 14:38, 3 November 2012 (UTC)[reply]

Absolutely not. We should not be censoring Wikipedia as a scheme to raise funds. —Farix (t | c) 09:54, 3 November 2012 (UTC)[reply]
Might have been The Mousetrap. There was coverage in the news over how Wikipedia gave away the answer. Legoktm (talk) 10:55, 3 November 2012 (UTC)[reply]
I doubt that it's The Mousetrap. To my knowledge it's never been adapted into a film, possibly because of its notorious ending. Narutolovehinata5 ^tccsdnew 11:03, 3 November 2012 (UTC)[reply]
Sounds like Witness for the Prosecution (also based on an Agatha Christie story).Nigel Ish (talk) 11:56, 3 November 2012 (UTC)[reply]
Good call. Apteva (talk) 17:18, 3 November 2012 (UTC)[reply]

So basically, no. We won't bring back spoiler warnings, and that's for the best. Apart from the fact that Wikipedia is not censored, there is an encyclopedic benefit for those who have not seen the work but want to know the plot. Say, for example, I want to know the plot of a movie that I will probably never watch. I can just look up its Wiki page's plot section. If you don't want to know a film's plot before seeing it, then stay clear of the section titled "plot". Or better yet, don't read anything about the work in the first place. I'm surprised that people complain about seeing spoilers on Wikipedia when it was they who decided to look up the work in the first place. It's not our fault that they were spoiled since it was their decision to read the Wikipedia article. Narutolovehinata5 ^tccsdnew 10:28, 3 November 2012 (UTC)[reply]
Will you be having spoiler warnings added to Ian Fleming's books? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:13, 3 November 2012 (UTC)[reply]
This is all very interesting, but if no journalist has published the details of the plot, how can Wikipedia do so without using WP:OR? --R'n'B (call me Russ) 02:05, 4 November 2012 (UTC)[reply]
When a film is released to the public, it is affectively published. —Farix (t | c) 02:11, 4 November 2012 (UTC)[reply]
RnB has a good point. The movie is a primary source, but not verifiable other than by paying to see the film. I would guess that most of our plot spoilers could be deleted as lacking a reliable source. Witness for the Prosecution offers not a single reference for the plot section, or for the voice over in the disclaimer section. Once a film is released, it is published, but normally our articles should be based on published reviews, and not on the personal experiences of editors who have watched the film. For books, the plot summary of Gone with the Wind (rated C class) is annotated with the page numbers where each appears, using the book as the reference. To Kill a Mockingbird, an FA, offers no page references for the plot section. I would actually think that page numbers could change from one printing to another, though. All of the Ian Fleming books I checked are GA, and none use references in the plot or synopsis section. Some older books are available online, either from Wikisource or from project Gutenberg, and are easier to verify. Apteva (talk) 21:03, 4 November 2012 (UTC)[reply]
IMO if the owner of the book, movie etc [The writer or the producer, in this case] chooses not to reveal the plot of the entire movie, he or she has a right to preserve the plot in any way they deem satisfactory [or by someone else in accordance with their wishes]. Although Wikipedia no longer allows spoilers, this can also been done in a number of other ways, like page blanking [or simply removing the plot portion] (for a specified period of time, in this case) or to say the entire plot but let the twist not be given, and be worded as 'The story ends in a twist of plot' along with any other necessary phrases. It should also be protected or semi-protected, as necessary, to preserve the sanctity of the article as is. TheOriginalSoni (talk) 15:56, 4 November 2012 (UTC)[reply]
"he or she has a right to preserve the plot in any way they deem satisfactory"... up until the movie is publicly released at which point that "right" is gone; the cat's out of the bag. --MASEM (t) 16:08, 4 November 2012 (UTC)[reply]
I agree, when the piece of media (book,play,film) becomes publicly released I believe that any privacy or secrecy rights to the ending are long since lost. I also don't agree with the OR claim since basic analysis of a work of fiction is permitted and unless complex or subjective analysis is necessary we don't need a source to say how the film ends. Regarding subjective analysis, we would not be able to say that the ending of a film is a representation of the battle between good and evil in the human soul without either a secondary source making that analysis or someone involved in the film (directer, producer, etc) stating that was their intention with the ending. We can, however, describe the noninterpretative events (who said what, who did what etc) and would not need a secondary source to cover that. For a more concrete example, using the Mousetrap's twist ending mentioned earlier, at the end of the play the murderer directly identifies themselves as such so it would not be OR to state that they are the murderer since it was directly confirmed by the character and not a subjective opinion of a person watching the play.--174.93.171.10 (talk) 21:02, 4 November 2012 (UTC)[reply]
I don't buy this (although this is getting off-topic, which is my own fault). You can't write a plot summary without making judgments as to which elements of the plot are the most significant and which are incidental. Should the plot summary mention what color shirt Bond was wearing in the pivotal scene? You might say that's not important, but that is a judgment call that seems to me to be pure WP:OR, or at least WP:SYNTH. --R'n'B (call me Russ) 21:23, 4 November 2012 (UTC)[reply]
I don't agree with that. WP:OR specifically says A primary source may only be used on Wikipedia to make straightforward, descriptive statements of facts that can be verified by any educated person with access to the source but without further, specialized knowledge. For example, an article about a novel may cite passages to describe the plot, but any interpretation needs a secondary source. Using the mousetrap for example, stating that the person was the murderer when they specifically said that they were would be something obvious to anyone with basic English comprehension and knowledge of what the term murderer meant. That would not even be remotely close to specialized knowledge. WP:SYNTH calls for not combining multiple sources to make a conclusion not made by either source so I don't see that would even be relevant here. You can bring this up at WT:OR though I believe that the view that basic plot summaries go against WP:OR will likely be strongly rejected.--174.93.171.10 (talk) 21:55, 4 November 2012 (UTC)[reply]

I prefer citations to third-party sources for plot summaries myself, but I have been shot down time after time. A good example of this problem is a hypothetical plot summary of The Wizard of Oz:"Young Kansas girl is transported to a land where, after killing the first person she encounters, she teams up with three misfits to stalk and kill again". Absolutely accurate, but completely misses the point. That said, general consensus is that the plot of a work can be sourced to the work itself, so long as the description is straightforward and lacking in value judgements.—Kww(talk) 22:00, 4 November 2012 (UTC)[reply]
Sound for people and places articles
Add a voice button option to the editing of peoples and places articles just for having a voice saying correctly the name of the person or place in the in the relevant accent of specific country this name came. This simple feature will help Wikipedia's users recognize and link more easily when a topic on which they had read in Wikipedia comes out in a talk, a lecture, TV and so on.
Good luck, Adam. — Preceding unsigned comment added by 89.139.148.255 (talk) 10:01, 3 November 2012 (UTC)[reply]
Yes, this is done in the first sentence of Paris and many other articles. Perhaps someone should vigorously promote the practice. Jim.henderson (talk) 10:17, 3 November 2012 (UTC)[reply]
See this relevant blog post by Andy Mabbett. Graham87 12:05, 3 November 2012 (UTC)[reply]
Bugzilla report added for syntax highlighting based on RfC

Tracked in Phabricator
Task T43770
Hey folks. Many of you here participated in this discussion, so I thought I might give you an update. Given the wide consensus for the implementation of some syntax highlighting by default (per the Village Pump discussion and RfC), I have submitted a report to bugzilla to see if it can be done. You may be interested in participating in or watching the outcome of that discussion here. Thanks, I, Jethrobot ^{drop me a line} (note: not a bot!) 18:40, 4 November 2012 (UTC)[reply]
Closed as "WONTFIX" - says that this can be done by any local admin - Wikipedia:Gadget#Default_gadgets Apteva (talk) 21:09, 4 November 2012 (UTC)[reply]
Dismiss/Close/Hide New Message Banner
Greetings, it must have been suggested already since I don't think I am the only one looking for this option! Is it possible to add a Dismiss/Close/Hide link in "You've new messages" banner? I personally get talk page new message notification through Google Talk (email notification → new email pop up). I don't need the banner very often. The worst part is it does not go until you see the message and thus it forces you to see the new message! --Tito Dutta (talk) 05:20, 5 November 2012 (UTC)[reply]
about pronounciation
hey guys, i have used wiki for a while now and love it. i wanted to let you guys know, in case you do not, the "pronunciations" on pages need to be auditory. in other words, if i browse a page and do not know how to pronounce whatever it is, I count on Wiki. i see the speaker symbol, and "pronunciation", after the subject name but have never encountered audio. this leaves me having to consult a second source. ONE STOP SHOP thanks guys — Preceding unsigned comment added by 166.147.72.145 (talk) 06:01, 5 November 2012 (UTC)[reply]
If you see the speaker symbol, like in the article Paris, you should be able to click on it and hear the pronunciation, assuming that your browser allows that. If you do not see the speaker symbol, like in the article Aikido, then the IPA pronunciation is available but no audio. Apteva (talk) 20:55, 5 November 2012 (UTC)[reply]
That's effective for the 0.01% of readers who know IPA. (Disclaimer: I learned IPA in college. And then promptly forgot it.) Angryapathy (talk) 14:52, 8 November 2012 (UTC)[reply]
Citation microformat
I propose that we add microformat-style HTML class names to citation templates, to improve their machine readability; please see Proposal: citation microformat and discuss there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 5 November 2012 (UTC)[reply]
Editor recruitment with TAFI
From User talk:Jimbo Wales:
We should use the Main Page for editor recruitment. There were only 12,633 new English Wikipedia editor registrations in September 2012, the least since 2005.
Jimbo, this went to the archives before you weighed in on it: Will you please support an experiment to place {{Today's article for improvement}} on the Main Page temporarily in order to judge the extent to which it may be an effective tool for editor recruitment? Please see WP:TAFI for more information. Paum89 (talk) 17:56, 2 November 2012 (UTC)[reply]
I support this experiment. I'm back at work full-time on Monday, so I'll try to get involved a bit.--Jimbo Wales (talk) 21:00, 3 November 2012 (UTC)[reply]

Paum89... why don't you propose this at a relevant village pump and see if there is community support for such an addition? Reso lute 19:13, 4 November 2012 (UTC)[reply]
Done. Paum89 (talk) 05:01, 6 November 2012 (UTC)[reply]
Comment The articles would have to be of fair quality already. We already have our best articles showcased, and you propose we add our worst. Pokajanje|Talk 00:50, 8 November 2012 (UTC)[reply]
~~Agreed~~; please see the history and nomination and voting for WP:TAFI nominees while it's been in the Community Portal. Paum89 (talk) 19:19, 8 November 2012 (UTC)[reply]

Not the very worst, by the way, just something well-suited for improvement by the median new editor. Paum89 (talk) 01:07, 9 November 2012 (UTC)[reply]
Average size of the articles of a Wikipedia?
Usually the size of a Wikipedia is considered to be its number of articles.
But if you compare Wikipedias you'll see that they differ not only in how many articles they have but also how detailed their articles are.
Typically articles in the big languages are several times longer than those in smaller languages.
So the relevant, the real size of a Wikipedia is not so much its number of articles as much as (number of articles) X (average size of articles).
Can the average size of the articles of a Wikipedia be easily computed?
I would then propose to add a column to the table in
http://meta.wikimedia.org/wiki/List_of_Wikipedias
to also display the parameter (number of articles) X (average size of articles) for the list of Wikipedias
Basemetal00 (talk) 19:27, 6 November 2012 (UTC)[reply]
I've posted a copy of this on the talk page for http://meta.wikimedia.org/wiki/List_of_Wikipedias. Maybe a discussion of this could more appropriately go there. Basemetal00 (talk) 22:30, 7 November 2012 (UTC)[reply]
The specifc proposal here has several implicit assumptions, including how "size" is to be measured, and that "size" in some form is "good" in some form. Consider: if two wikis had the same number of articles and words of text, and the same average size of articles, but one wiki had the text distributed fairly evenly across all articles, and the other had a preponderance of the text in a small number of articles, would they be equally good? I think not, the numerical equality of the metrics not withstanding. In such a case one might also consider the different kinds of "averages" (mean, median, modal), but all this still misses a key point: the overall quality and trustworthiness of an encyclopedia.

To the extent that the distribution of article sizes is important, there are some ways this might be measured. But this would be a rather deep discussion perhaps better done in a different venue. ~ J. Johnson (JJ) (talk) 22:53, 7 November 2012 (UTC)[reply]
"The community-written encyclopedia"
I'd like to propose changing the every-page tagline "Wikipedia, the free encyclopedia" to "Wikipedia, the community-written encyclopedia". The word "free" has lost much of its meaning nowadays, but "community-written" would give people who land on articles via Google searches a much better clue about what Wikipedia IS, without going as far as saying "anyone can edit" on every article (saying "anyone can edit" might be more inviting of vandalism as well as detracting from aesthetics, but I don't think "community-written" has these problems). Silas S. Brown (talk) 09:00, 7 November 2012 (UTC)[reply]
I agree wholeheartedly. I've always thought that "free encyclopedia" only adds to the notion of "this is a service that has been provided by the magic pixies who do their work deep below the surface of the earth, far removed from reality". The feedback feature has only strengthened these views. It's always whinging: "why won't you do this? why are you so shit? why wont you fix this article? i hate you!". The real question is, why wont you.... We have GOT to end this stupid dichotomy. It is not editors and readers. We are one in the same (something that i like to dub "edi-readers"). And as such Wikipedia should not present itself as "this is how cool we are and this is our best work and ooo looky at all the stuff we've done. read and be in awe". We should always try to reinforce the fact that we are all part of a community, working together to achieve something great. One of the few things ever that every single person in the world can participate in. How freaking awesome is that?!?!!! The main page must turn into something more suited to newbies. This is the top editing tip of the day. This is the article collaboration of the day. This is the wikipedian of the day telling you their story and what inspires them to continue. This i the sort of stuff we should be stuffing our main page with... i honestly can't see why everyone has such a hard time getting that. Traditions were meant to adapt and evolve people!!!!!!!!
*stands down from the soapbox*
..sorry about that... i just get very passionate about this sometimes... Now going back to your original point, yes, i think that is exactly what we need to help us on this transformation to a much more poeplefriendly wikipedia, rather than a free service from a mysterious entity that works behind the scenes, known (the legend says) as.......... THE WIKIPEDIANS.--Coin945 (talk) 09:31, 7 November 2012 (UTC)[reply]
"Community-written" (like "free") has a distinct problem of definition: of the many ways that people take this, which one is meant? Many people will not even consider the question, but simply presume how ever they conceive of it.

The request here is to change the tag-line, but that is derived from our conception of Wikipedia. (I.e., the slogan.) My preference is "the collaborative encyclopedia", emphasizing the working together ("co-labor"), without implying that anything goes or that everyone has some right to edit. ~ J. Johnson (JJ) (talk) 22:57, 7 November 2012 (UTC)[reply]
Wrong forum. The tagline "The Free Encyclopedia" is used on all of the Wikipedias and is part of our branding. Since it is cross-wiki, such a discussion should occur at Meta:. Personally, I suspect it would require the approval of the Foundation and would not expect them to approve such a change. --Philosopher ^{Let us reason together.} 09:35, 8 November 2012 (UTC)[reply]
I don't know how to start a discussion on Meta. There doesn't seem to be a "Wikimedia village pump" anywhere. Silas S. Brown (talk) 21:57, 8 November 2012 (UTC)[reply]
that would be m:Wikimedia Forum. Rd232 ^talk 22:28, 8 November 2012 (UTC)[reply]
IMO it's not important who writes it, but the access to it. "Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge. That’s what we're doing.". It's not important that it's a community who's writing it (well it is, but that's different), but who has the ability to access it. Legoktm (talk) 10:30, 8 November 2012 (UTC)[reply]
The word "community" should imply free access, so that wouldn't be lost. But "free" might just mean "our company wants to get more traffic so we put this up". We're missing an opportunity to help people understand at a glance what's really happening. Silas S. Brown (talk) 21:57, 8 November 2012 (UTC)[reply]
How does "community" imply "free"? A community can be closed if it wanted to be. I see your point about free, but I don't follow the continuation of it. I think you're just following down a slippery slope. Legoktm (talk) 22:07, 8 November 2012 (UTC)[reply]
This may be an interesting and even fun discussion (how about "the open encyclopedia", in the sense of open source?), but it's mind-bogglingly unlikely to lead to any change in the slogan. Rd232 ^talk 22:28, 8 November 2012 (UTC)[reply]
To the extent the tag-line reflects the Wikipedia slogan, a change implies changing the slogan. And, yes, this is the wrong forum. Perhaps this discussion should be reconvened at Meta: ~ J. Johnson (JJ) (talk) 23:27, 8 November 2012 (UTC)[reply]
RFC regarding ticker symbols in article leads
Hi. I've started an RFC regarding ticker symbols in article leads: Wikipedia:Requests for comment/Ticker symbols in article leads. Please weigh in! --MZMcBride (talk) 15:16, 9 November 2012 (UTC)[reply]
This can help in quickly understanding linked topics or peoples in articles!
Hello, I was reading an article and realized that I didn't remember what Theocracy meant and it was a link in the article, so I clicked it to go to the article on Theocracy to better my understanding of the article I was originally on. Well instead of switching to a new article or in a new tab leading to thousands of tabs, for things we need a quick definition or understanding of why not have a quick on mouse over description?
I've made this example from a screenshot to help out: http://imgur.com/2DMoh
With regards, guesshurley / Brad.— Preceding unsigned comment added by 68.147.222.123 (talk • contribs)
I don't know what it would technically take to do that, but that's a pretty good idea. I like your mockup as well. --Jayron32 02:53, 10 November 2012 (UTC)[reply]

It's a brilliant idea. It's done all over the web. It might get some better control over opening sentences, too, if the rollover text were simply from the opening sentence. I'm surprised en.wiki doesn't do it already. -Fjozk (talk) 02:57, 10 November 2012 (UTC)[reply]