Jump to content

Wikipedia:Village pump (proposals)/Archive 95

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 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, 215

FYI: RFC on research participant recruitment policy

An RFC was just opened on the talk page for Wikipedia:Recruitment policy. The policy describes a process by which scholarly researchers would use the RFC system to obtain consensus for their activities before sending recruitment requests to editors to participate their studies. The process is designed to allow editors to vet recruitment plans in order to minimize potential disruption. This proposal was put together through a collaboration between meta:Research:Committee members and some academic researchers who went through the RCom's old vetting process. Please share your comments. --EpochFail(talk|work) 20:58, 23 October 2012 (UTC)

Proposal: The Wikipedia Breakroom

Collapse un-incubated half-baked idea
The following discussion has been closed. Please do not modify it.

IME, admins spend a good deal of their precious time going around to various discussions/disagreements telling editors to "shut-up and get back to work improving the encyclopedia". Well, perhaps Wikipedia should have one talk page where admins cannot tell anyone what to do, what to say, or when to let an issue go (with a few caveats). Interactions that occur at the "Breakroom" would be virtually immune from Wikipedia policies, and sanctions at other venues in a way similar to mediation privilege. Editors would be free to speak their mind there without fear of admin sanctions. A safe place to blow-off steam may well positively affect editor retention/satisfaction long-term, and it may well improve/expedite dissolution of grudges and bad-blood.

Rules. - I suggest a short set of rules/guidelines be drafted, starting with: 1) No threats or personal attacks of any kind (legal, physical or emotional). 2) No bigotry of any kind (sexism, racism, religious or national intolerance). 3) No comments about editors not actively participating in the specific "Breakroom" discussion thread. 4) No threats of admin sanctions based on comments made in the "Breakroom" unless in direct defense of "Breakroom" rules 1, 2 and/or 3.

Virtually everything else would be fair-game there (amongst willing parties), e.g. swearing (as long as it does not violate rule #2), heated debate, comments about about editor behaviour. A "Breakroom" would allow frustrated editors a controlled environment for release of that frustration that does not involve the ominously daunting and excruciatingly tedious AN/I, DRN, RfCU, mediation or arbitration, nor would interactions there directly disrupt the project. This may well reduce the workload at DRN based pages, and hopefully some wise and knowledgeable Wikipedians would volunteer to act as de facto mediators (oracles?) at the "Breakroom", helping to guide conflicts that do not seem to be resolving. Participation is of course voluntary, so any editors who dislike the way a thread is going can simply ignore it and leave the "Breakroom", with the expectation that editors who remain, refrain from commenting on an editor who bailed on the thread. Perhaps said editor would need to explicitly indicate they are "officially" disengaging from a specific BR thread, to clarify they aren't just taking a few days away: a point for further discussion.

Why?. - Many times disputes/conflicts on Wikipedia are shut-down prematurely by admins who at times rightly fear the disruption will bleed into article space, or into an article's talk page, disrupting the improvement of the project. Also, admins will often suggest that a given disagreement is taking place at "the wrong venue", but what is the "right" venue? Sometimes editors need to verbally "duke it out" in order to reach some satisfaction, if not an outright resolution. The trouble is, anytime an editor or two "go at it", an admin will invariably come storming into the thread telling everyone to "shut-up, stop acting childish and go back to work". Well, we are all unpaid volunteers here, so this can at times be an extremely off-putting sentiment. So while I fully agree that excessive argumentation at talk pages can indeed disrupt the project, I also think that at times editors need to work-out their disagreements without "Big Brother" deciding who, when, where, and how much discussion is appropriate, and who was "right" and who was "wrong". In short, it would be the one place where editors can go to air grievances and speak freely without fear of admin sanctions. Any thoughts? ~ GabeMc (talk|contribs) 23:33, 23 October 2012 (UTC)

Breakroom proposal - Support
  1. As proposer. ~ GabeMc (talk|contribs) 23:35, 23 October 2012 (UTC)
Breakroom proposal - Oppose
  1. Oppose I have no desire to verbally duke it out with anybody and would have no intention of frequenting the break room. I cannot support any proposal that allows another editor to say whatever they want about me onwiki with no place for me to go for recourse. Ryan Vesey 23:48, 23 October 2012 (UTC)
  2. Ah, but this already exists... right here. Theopolisme 00:14, 24 October 2012 (UTC)
  3. Serves absolutely no constructive purpose whatsoever. Resolute 00:47, 24 October 2012 (UTC)
  4. Oppose. The catharsis theory has long been discredited in psychology. May be that is why real breakrooms aren't like this. Churn and change (talk) 05:25, 24 October 2012 (UTC)
  5. Oppose. A well intentioned proposal, but I see too many problems with it. Overall I believe a place where editors (does that include IPs btw?) can troll like they want will in the long run not have any positive effect on the encyclopedia. If you are frustrated, log out and do something else than editing Wikipedia for a while. I agree that we need to do something to retain experienced editors and long-term contributors, but I believe this is not the way to go (don't know about newbies, most won't know that place exists and many might release their frustration on some other page anyway). -- Toshio Yamaguchi (tlk−ctb) 07:57, 24 October 2012 (UTC)
  6. Oppose. Disputes will not be solved by unmoderated "breakroom" like that. If you (generalized) need to a place to ignore rules, swear, namecall, etc. you are doing this wrong and should take a break. —  HELLKNOWZ  ▎TALK 08:10, 24 October 2012 (UTC)
  7. Oppose – While I understand the idea, this seems like it would just create a hyper-drama board that would rapidly supersede our usual drama boards like ANI. In fact, I'm pretty sure this would go to plaid. —Torchiest talkedits 12:33, 24 October 2012 (UTC)
  8. Oppose – Why do we need a virtual room on Wikipedia to vent off steam, when we can easily just log out of Wikipedia and visit another website or switch off our computers and go to the pub etc to vent off steam whenever something on here frustrates us. In my seriously honest opinion, this idea is a waste of time, although I appreciate where the proposer is coming from in regards to their idea. Speaking of pub, anyone want a drink, my round! Wesley♦Mouse 12:44, 24 October 2012 (UTC)
  9. Oppose – Would fuel drama, not help get rid of it. Jasonfward (talk) 13:44, 24 October 2012 (UTC)
  10. Weak Oppose, while it's a good idea in principle, I have to worry about its potential consequences. For example, what if you don't want to participate in the Break Room, but someone there is continuously attacking you? You either have to join in (and be subject to more direct attacks) or try to ignore it while your name gets smeared. Kaldari (talk) 20:48, 24 October 2012 (UTC)
    Apparently slamming people who aren't there would be prohibited. Kaldari (talk) 01:11, 25 October 2012 (UTC)
  11. Oppose. This would only serve to exacerbate disputes, not mediate them. All it would do is get people worked more into a frenzy rather than calming them, which would cause even more drama and disruption. Not to mention that this directly conflicts with Wikipedia's fourth pillar, one of the foundational principles of the site. elektrikSHOOS (talk) 23:25, 24 October 2012 (UTC)
  12. God no. We should be discouraging this sort of behaviour, not enable it. If there are editors here that would use such a place just to yell and swear at each other, then frankly I am not sure if they belong here. Steven Zhang Help resolve disputes! 23:28, 24 October 2012 (UTC)
  13. Oppose. This seems to be based on some interpretations of Wikipedia interactions that I can't agree with at all, and it's hard to see the interpersonal theory it's based on working effectively in this setting. —chaos5023 (talk) 03:03, 25 October 2012 (UTC)

Breakroom proposal - Discussion

@ Ryan Vesey, perhaps my wording leaves something to be desired. The intent would be that the parties would agree, not that they could go there and smear you without your participation. You would have to agree to the "Breakroom" chat, and should you decide to withdraw from a BR chat in progress, then the remaining parties would be expected to refrain from commenting about you. Anyway, people smear others at User:talk all the time, with virtually no recourse except in the most extreme cases. A "Breakroom" could clear talk pages of this clutter, and newer, or even experienced editors more adverse to conflict would find them easier to avoid. As you said, you wouldn't go there, that's great, but if you ever did find yourself in a heated dispute you might be asked to "take it to the Breakroom", versus "shut-up and get back to work you pathetic child!" ~ GabeMc (talk|contribs) 23:54, 23 October 2012 (UTC)

@ Theopolisme, but is IRC really intended for dispute resolution? I thought IRC is the social networking area of Wikipedia. Also, IRC is in real-time, the BR would be as a talk page, so that editors could respond to comments made several days, if not weeks ago, so I don't see IRC as equivalent to a Breakroom. ~ GabeMc (talk|contribs) 00:17, 24 October 2012 (UTC)

(edit conflict) two cents IRC is a ... well, let's call it a complete free-for-all that happens to attempt to get things done once in a while. :) And that really is what this breakroom seems like it would turn out to be -- a cursing, spitting, screaming free-for-all... I'm not criticizing you, Gabe -- rather, I don't think that Wikipedia -- at least the majority of folks who go to DR (low-level stuff) -- are capable of handing a free-for-all. They need the structure... which I don't think the breakroom would be able to provide. Theopolisme 00:40, 24 October 2012 (UTC)
Editors who want excess structure and the possibility of admin sanctions go to AN or DRN. Editors who just want to have a heated discussion without the imminent fear of admin reprisals could go to the Breakroom. The main point being, nowhere except formal mediation are editors free from admins deciding when and how to end conversations and/or block an editor for disruption/incivility. A Breakroom would/could reduce the amount of blocks given for disruption originating from editor disputes, or just blocks to complaining editors. No admin can swoop in and play Wikicop in the BR (with a few exceptions), demanding that you immediately cease and desist or face an arbitrary block. Nowhere on Wikipedia are editors safe from this possibility to my knowledge, at the Breakroom they would be, that's why this adds something "new". A case in point. ~ GabeMc (talk|contribs) 00:54, 24 October 2012 (UTC)
What is the benefit of endorsing rampant heated discussion? It's... Rampant. I just have yet to see how this would... work out. Theopolisme 01:35, 24 October 2012 (UTC)
Good question. As someone with extensive counseling experience, I can say that sometimes people just need to "vent", complain, "whine" or whatever, and there isn't always a finite solution to be found other than meeting that need, to vent frustration. IME, admins typically demand either an immediate solution (shut-up), a sanction (block), or a labourious process such as AN/I, RfCU, MedCom, or similar. At the BR, editors could call each other nasty names, complain about their behaviour, and generally air grievances until, hopefully, the animosity fades (I've seen this with my own eyes a thousand times), leading to an overall decrease in editor tention, theoretically improving editor retention. I've watched this process of "therapeutic complaining" turn violent people who once considered each other arch enemies into confidants. Sure, there are several bugs that would come up, but I don't see how a trial period should be considered too risky an endeavor when Wikipedia stands to gain so much, should the proposal prove therapeutic long-term. Of course, the BR could easily be closed if this didn't work as planned. Also, to clarify, the heated discussion at the BR would not always be Rampant, nor should it be. The point here is that it could be, without the fear of some admin blocking an editor before the dispute is resolved, it fizzels out, or reaches a stalemate. ~ GabeMc (talk|contribs) 01:46, 24 October 2012 (UTC)

So you think editors would be comfortable ranting/raving at a public on-wiki page? Rather than a private, off-wiki, off-record IRC chat? Theopolisme 02:18, 24 October 2012 (UTC)

You are using loaded language to prove your point, e.g. "ranting/raving". I would say that editors currently rant/rave at a public on-wiki page daily (see many talk pages, both user and article). Why would a centralised location for drama be any different in that regard? The BR would be a pre-AN place, and admins may even require that editors attempt to resolve issues themselves at the BR, before involving admin resources at AN. At any rate, it would be nice to have one safe place from admin sanctions, and that in and of itself seems worth a trial period. ~ GabeMc (talk|contribs) 20:51, 24 October 2012 (UTC)
Guilty as charged. However, as you just said: "I would say that editors currently rant/rave at a public on-wiki page daily"... then why should we encourage doing so even more if it already happens? I think I have to concur with other opposes/comments above and below... this just doesn't seem (to me) to be a net benefit to the project. Theopolisme 21:51, 24 October 2012 (UTC)
Who is encouraging negativity? At the BR users would be expected to attempt to work out their differences without the drama spreading around the project and sending a negative impression to new users while burning out experienced ones. Also, this would be a bit of an experiment to see if we could reduce the admin workload at AN. Wouldn't it be nice if editors could once in a while work out their problems without needing an admin? As I said above, there is already mucho drama at Wikipedia, a BR could help centralise it so as to minimise the collateral damage to the project. I've seen it a hundred times where a talk page thread extends to ludicrous lengths because two editors are having a heated discussion between them, pushing out other voices by dominating the discussion. To say that the BR would encourage negativity is an assumption. IME, issues don't magically disappear just because an admin demanded the discussion cease. The problem remains, festers even, until an AN/I report is filed, a user is blocked or quits. What harm could a trial period do? ~ GabeMc (talk|contribs) 22:25, 24 October 2012 (UTC)

@Resolute, Per: "Serves absolutely no constructive purpose whatsoever", an assumption that could not possibly be proven without first being tested. There are/were several heated debates I would like to have with editors that are invariably "shut-down" by annoyed admins wanting editors to "be productive" or to "get back to work and stop wasting time". Well, no one could be accused of time wasting at the BR. This likely seems unneeded to you, since you regularly "vent" at Jimbo's page, but not all of us are afforded that luxury, and some of us have been straight-up denied that privilege. ~ GabeMc (talk|contribs) 01:20, 24 October 2012 (UTC)

Gabe, nobody could be accused of anything but time wasting at such a forum. If you want to vent about something at Wikipeida, go print off an 8x10 copy of Jimbo's picture and yell at it. Resolute 14:09, 24 October 2012 (UTC)
  • Comment: No decision one way or the other whether this is a good or bad thing or not, but for historical purposes, Wikipedia:Esperanza bears bringing up during these discussions. Toodles. --Jayron32 11:23, 24 October 2012 (UTC)
    I thought of Esperanza as well, but that was more of a cult than a fight club. Resolute 14:03, 24 October 2012 (UTC)
    Fight Club wasn't a cult? I'm pretty sure that is exactly what it was... --Jayron32 18:21, 24 October 2012 (UTC)
    Nah, Fight Club was an underground boxing ring. Project Mayhem, now that was a cult. —chaos5023 (talk) 21:48, 24 October 2012 (UTC)
  • Comment. - It seems many are assuming this would create or drum-up drama, well, like it or not, the drama is already here. Its just spread evenly around talk pages where new users can see it, and old users can get sick of it. A BR would give drama a place where nothing is "off-topic" and a BR would be a focal-point for drama, but I fail to see how a safe place to go and have a heated discussion would cause drama. Anytime someone wants to call you out, or you want to call someone else out, but you would rather it not be on your talk page: this could be used. The trouble with AN/I is that all behaviours are under scrutiny, and both parties become subject to admin sanctions for just going there. This would not replace AN except for those cases where no admin action is required, which seems like about 1/3 of all AN cases, which are closed as "wrong forum" or "no admin action required". These would be issues that editors could discuss at the BR, without fear that an admin will come in and arbitrarlily stop the discussion because they have judged the situation either resolved, or too dispruptive to Wikipedia. Arguments/disputes/heated discussion would not disrupt Wikipedia if they occurred at a central location. This could also be a place where "interventions" could occur, perhaps preventing a few indeffs that happen at AN. ~ GabeMc (talk|contribs) 20:33, 24 October 2012 (UTC)
  • Comment. - There is currently no place on Wikipedia where a non-admin can tell an admin to "fu---off" without fear of a block. Would it really be that bad to have one place where all Wikipedian's could speak freely without fear of reprisals, regardless of their user status? ~ GabeMc (talk|contribs) 20:44, 24 October 2012 (UTC)
  • GabeMc, you indicate it's your IRL counseling experience that leads you to consider this a good idea. I think it's worth asking, though, whether that experience is portable to this medium. Have you seen the venting-reconciliation cycle work in a text-based, pseudonymous environment where participants have neither tone of voice nor body language available as components of their communication? —chaos5023 (talk) 21:18, 24 October 2012 (UTC)
My RL experience is only one part of why I think this may help here at Wikipedia. Three years on Wikipedia is the primary experience that makes me think this could work here. As far as your question about Wikipedia's "pseudonymous environment", well no, I havn't seen this work in that condition, but then, why would trying something new be worse than what we currently do, which is to attempt to resolve disputes in a "pseudonymous environment"? The difference here is that community members would attempt to resolve disagreements without running to an admin for help. Seems like admins would appreciate that. ~ GabeMc (talk|contribs) 21:28, 24 October 2012 (UTC)
Well, opportunity cost is why, basically. The question is whether we can reasonably anticipate whatever cost/benefit mix this course of action brought to be better than avoiding it. If one considers it most likely to generate extra drama that sucks up editor time and energy that might have otherwise gone to things like content creation, then one would naturally consider "just trying it" a bad idea. —chaos5023 (talk) 21:37, 24 October 2012 (UTC)
I think the attitude that pushing users to edit and improve articles at all times or face sanctions drives editor loss. Why is there not one place at Wiki where an editor is safe from a random admin demanding they immediately "shut-up and get back to work"? This is why real jobs have a breakroom, so workers (editors) can take a break, complain about the boss, BS about an off-topic TV show etcetera. There is no open forum that I am aware of on Wikipedia. If you are not improving an article you are assumed to be wasting time with off-topic discussion. Why do you think an open forum on Wikipedia is a bad idea per se? Your "opportunity cost" argument against lacks empirical evidence. How much time is wasted at AN daily? If the BR could save any time there, then it may balance out the perceived negativity, which again, is already here, its just not being dealt with in a way that doesn't involve admin sanctions, which typically only punish editors, and rarely prevent anything, except perhaps editors continuing to contribute to Wikipedia. ~ GabeMc (talk|contribs) 21:48, 24 October 2012 (UTC)
I'm really more just trying to communicate why people are probably not insane to not want to try your proposal. I'm not actually convinced it's a bad idea. Your argument is kinda scattershot, though. Wikipedia (WP:NOTWIKI, by the way) isn't very analogous to a workplace because you're a volunteer and can walk away from it whenever you like and vent about it to whomever you like. And it's really hard to construct admins as bosses; I've had adverse interactions with administrators, but certainly never one where I felt like I was being told to get back to work. (If anything, I feel like that role is filled by trigger-happy AfD nominators using the threat of content destruction to extract labor from volunteers.) And you seem to be conflating the idea of the breakroom as a "time off" venue with the "two parties working out their differences" counseling / dispute resolution idea, which I'm not familiar with having anything to do with a workplace breakroom. —chaos5023 (talk) 21:55, 24 October 2012 (UTC)
I've resolved, and been involved in the resolution of numerous workplace disputes in an employee breakroom, and I've been told multiple times by admins to get back to work. If admins aren't bosses, then what are they? Managers? If an admin can block you (fire/lay-off) then they are acting as a boss IMO. Don't you think Wikipedia could have one page where admins cannot decide when conversations need to end, and who needs to shut-up? A BR could reduce editor repression of frustration. You say just walk away, but how does that improve editor retention? Wikipedia's current attitude of "if you don't like it then leave", is costing us editors, and unless I am under a false assumption, I thought the recent editor die-off is an issue of serious concern for the project. ~ GabeMc (talk|contribs) 22:02, 24 October 2012 (UTC)
  • Kaldari, per your comment: "You either have to join in (and be subject to more direct attacks) or try to ignore it while your name gets smeared." If you re-read the proposal (rules) I think you'll see that "slamming" editors not volutarily participating in a discussion would be prohibited at the BR. ~ GabeMc (talk|contribs) 21:34, 24 October 2012 (UTC)
  • @Steven Zhang, are you of the school that laws that decriminalise marijuana also encourage its use? You seem to be our resident dispute resolution guru so I certainly respect your opinion. I suggest that not every dispute needs an admin censoring and dominating the parties. Why not give Wikipedian's an opportunity to demonstrate that they can resolve differences without admin intervention, and without a strict adherrence to mainspace guidelines intended to protect Wikipedia content, not reduce editor frustration. ~ GabeMc (talk|contribs) 00:08, 25 October 2012 (UTC)
    I understand what you're trying to say, but I disagree with your opinion. In my experience in dispute resolution, I've found that civilised, collaborative discussions are very effective, and I feel that the creation of a forum where slinging mud at each other is OK, is contrary to our standards and actually creates more ill-will. A survey of former contributors found 25% left Wikipedia due to unpleasant interactions with others. Now, I appreciate that the community is divided on the civility policy, but I disagree that creating one place where "anything goes" is a bad idea, and that encouraging people to work out their differences in a civilised way would make Wikipedia a better place. Regards, Steven Zhang Help resolve disputes! 00:34, 25 October 2012 (UTC)
Admittedly, this proposal leaves much to be desired (its my first ever on Wikipedia). There seems to be an assumption that the BR would always be a free-for-all with all hell breaking loose. That's not really the point. The point is that should all hell break loose, editors at the BR are safe from admin sanctions. Currently, the only way an editor can enjoy that luxury is at a formal mediation, where civility is strickly enforced. I support civility, but overcivility can at times lead to the suppression of anger. Forget "the catharsis hypothesis", do you think it might be helpful to have one safe place where editors can speak freely without any fear of admin sanction? If not, why not? ~ GabeMc (talk|contribs) 00:58, 25 October 2012 (UTC)
The privelige of formal mediation is exactly that, a privelige. It's there to allow open communication, not abuse. The policy explicitly states "..f a party engages in disruptive or bad-faith conduct during mediation, and that conduct later becomes the subject of disciplinary proceedings, the Mediation Committee will decline to protect the privileged nature of the party's communications.". It's not a right, if abused, it can be withdrawn. I don't feel there should be any location where we encourage people to go if they want to be uncivil to each other. It's just giving the wrong message. Tempers flare occasionally, and that's OK. But let's not create somewhere where anything goes. Steven Zhang Help resolve disputes! 02:39, 25 October 2012 (UTC)
Looking at the study you cited, it would appear that more than 1/2 (419) of the people who cited "bad terms" as a reason for leaving named "complexity" as an issue, while 372 cited an issue with another editor. Further, of the "community" critics, the report states that the issue had more to do with content reversions, deletions and the general stubborness of editors versus open hostility or rudeness. ~ GabeMc (talk|contribs) 01:09, 25 October 2012 (UTC)
Further, it would appear that of the 372 who cited issues with another editor, around 12% left because of admin warnings/threats of sanctions, 50% left due to their work being undone, and 44% due to difficult editors. Well, if 1 out of 10 people who leave Wikipedia due to conflicts with editors cite the warnings of admin sanctions, than it would appear that admins shutting down discussion and threatening sanctions contribute to about 5% of all editor loss. ~ GabeMc (talk|contribs) 01:23, 25 October 2012 (UTC)
The stats about admin warnings/threats of sanctions (or actual sanctions) would apply to editors that also left because they were blocked for things like vandalism or edit warring. The requirements for the survey was 20-99 lifetime edits, left within 3 months of the survey, and last editing being in 2009, so while we definitely need to take this into account, I feel that the 32% who left because editors were rude to themselves or their peers, is a more significant figure and we should work on making this place a more collegial one. Steven Zhang Help resolve disputes! 02:39, 25 October 2012 (UTC)
Right, so is it your assertion that Wikipedia's primary concern regarding editor retention should be that the fourth pillar is not being properly enforced/encouraged? ~ GabeMc (talk|contribs) 02:43, 25 October 2012 (UTC)
I didn't say that, please don't make assumptions on my opinions. I'm a strong believer in data. My personal feelings are of little relevance, it's the collective view of those surveyed that is important. Usability of Wikipedia seems to be one of the larger barriers for the retention of casual contributors. I'm just saying that I don't think we should encourage people to call each other names, anywhere on Wikipedia. Steven Zhang Help resolve disputes! 03:21, 25 October 2012 (UTC)
I agree. I should have incubated the idea first, and perhaps its just not right for Wikipedia, but FTR I do agree that namecalling should not be allowed anywhere on the project. ~ GabeMc (talk|contribs) 04:00, 25 October 2012 (UTC)

Freedom of speech = New WikiProject

I've recently gone ahead and created WP:WikiProject Freedom of speech. If you're interested, here are some easy things you can do:

  1. List yourself as a participant in the WikiProject, by adding your username here: Wikipedia:WikiProject_Freedom_of_speech#Participants.
  2. Add userbox {{User Freedom of speech}} to your userpage, which lists you as a member of the WikiProject.
  3. Tag relevant talk pages of articles and other relevant pages using {{WikiProject Freedom of speech}}.
  4. Join in discussion at Wikipedia talk:WikiProject Freedom of speech.
  5. Notify others you think might be interested in Freedom of speech to join the WikiProject.

Thank you for your interest in Freedom of speech, — Cirt (talk) 22:38, 25 October 2012 (UTC)

Move articles that are 'PROD' instead of deleting them

DECLINED BY COMMUNITY
discussion has died off and absolutely no consensus for support

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.

Hi,

For too many times it happened to me that I occasionally tried to find something on wikipedia, what used to be here (typically about some artist), but was removed for some, trivial reasons (not notable, style) etc. I definitely agree that this stuff shouldn't be in encyclopedia as reliable article. But do we really need to "delete" this material? Why we can't just move it to a special space reserved for similar articles? For example Articles for Creation is full of non notable articles which aren't going to be deleted. Why we just don't move these articles to some "article incubator" for later improvement rather than deleting them? Why all people can't benefit from being able to see these articles just as admins do? These articles may contain information some people are looking for but can't read them because someone marked them for deletion, and even if it was justified they still may contain useful information readers were looking for. I propose all articles marked as PROD to be moved without redirect to some special space (to be discussed) for example Articles for Creation so that we can preserve this information for all people who would be looking for it in day that subject become notable enough. It's clear some articles aren't supposed to be in main space, but some of these deleted articles still contain some knowledge that can be interesting for someone. (I am not talking about vandalism and such, which is speedy deleted). I know that you can ask some admin to send you content, but that's over complicated, we could just move them by default with some template explaining that it's not a reliable article and with reason why it was deleted. What you think? Petrb (talk) 10:02, 18 October 2012 (UTC)

You're under a serious misapprehension if you think something not being notable is a "trivial" reason for deletion. It's the foundation stone of everything we should be doing here. See WP:V. --Dweller (talk) 10:16, 18 October 2012 (UTC)
Not really. It's a requirement for article (wikipedia article), but definitely not a requirement for every page on wikipedia. Petrb (talk) 11:07, 18 October 2012 (UTC)
You're suggesting we move non notable articles from article space into some other space, instead of deleting them. Why would we want to do that for inherently non-notable topics? We are already happy to userfy articles with prospects so they can be worked on, but someone's article about their non-notable dog, their local pub darts team or their opinions on stained glass windows in Chichester are not encyclopedic and therefore have no place in an encyclopedia. See WP:NOTFREEWEBHOST. --Dweller (talk) 11:16, 18 October 2012 (UTC)
I think you need to read it again. I answered all questions. Why would we want to do that for inherently non-notable topics? Because if some people are looking for them, they are probably useful at some point. We are already happy to userfy articles with prospects so they can be worked on that is very complicated and long process. Imagine I type a key to wikipedia searching for specific stuff. The page is deleted. I contact admin to restore it so I can check it. They restore it and I find out it's some nonsense I wasn't looking for. If the original page was somewhere it would save me a lot of time. (Substitute regular wikipedia reader to "me"). We already have a lot of non-notable dog's in AfC space, why we shouldn't put the rest there as well? WP:NOTFREEWEBHOST is completely irrelevant for this case Petrb (talk) 14:17, 18 October 2012 (UTC)
Anyone can make the case that "because someone might be looking for this info, it is probably useful", and so it is inescapable that the end result of your proposal is that we do, in fact, become a free web host. Your OTHERSTUFFEXISTS argument with respect to AfC is just that: an OTHERSTUFFEXISTS argument. Better by far to manage the AfC lifecycle so that we do not retain indefinately proposed articles which are not going to make it to article space. --Tagishsimon (talk) 15:05, 18 October 2012 (UTC)
The percentage of really useful information is bad enough already. Apteva (talk) 15:32, 18 October 2012 (UTC)
"It's useful" is not a valid keep rationale. And yes, NOTWEBHOST is relevant, because if an article doesn't belong in main space, it doesn't belong anywhere else on Wikipedia. Also, it is a curious argument that we should keep worthless nonsense around simply so that you can verify it is, in fact, worthless nonsense. Your own arguments explain why this stuff is removed. Resolute 16:28, 18 October 2012 (UTC)
Userfication might be an appropriate solution for non-biography articles in those cases where the user is not an anonymous contributor. I think that userfication has fallen into disuse over the past couple of years as people have tried hard to purge-with-extreme-prejudice content which is marginally encyclopedic. I've been guilty of this as well in PROD patrolling several years ago. --User:Ceyockey (talk to me) 00:52, 26 October 2012 (UTC)


Oppose. Notability is hardly a trivial reason, it is the core reason. I won't go into detail re every point, because this basic premise is left aside -- Wikipedia is an encyclopedia, not an indiscriminate collection of material. That's why we have inclusion criteria developed over a long time by the community. —  HELLKNOWZ  ▎TALK 16:21, 18 October 2012 (UTC)
Random comment: The reasons for deletion are not always so black and white. "Lack of notability" often goes hand in hand with other problems with the content itself - for instance, an article about a non-notable band which can only be based on one source - a glowing review in a local newspaper - and invariably written by somebody who likes the band, will have an almost insoluble neutrality problem. Or, consider an article about an obscure fringe idea which mainstream researchers haven't bothered debunking - needless to say that article will have WP:FRINGE problems which can't be resolved without getting more and better sources. An article about a run-of-the-mill school may often be dominated by anonymous editors adding crap (or even BLP violations). So, "notability" may be the headline reason for deletion, but in practice there may often be other good reasons on top of that. bobrayner (talk) 11:29, 22 October 2012 (UTC)
Oppose. Absolutely not. We are trying to build an encyclopedia, not a collection of non-notable information and unverifiable facts. The rest of the web is already full of it, we don't need it here as well. -- Toshio Yamaguchi (tlk−ctb) 08:08, 24 October 2012 (UTC)
Oppose. Completely unnecessary. Challenged prods are undeleted automatically under WP:UNPROD policy. SpinningSpark 14:55, 25 October 2012 (UTC)
Oppose. As user:Hellknowz says: "Notability is hardly a trivial reason, it is the core reason". No way. -- Alexf(talk) 19:48, 25 October 2012 (UTC)
Oppose this defeats the purpose of the prod process, which is to lighten the load on AfD of articles that would normally receive unanimous or near unanimous support for deletion. If, however, you think a particular article was wrongly deleted or could have been improved to meet Wikipedia's content criteria, then you have WP:REFUND. The article incubator is for subjects that were nominated for deletion, but have potential to meet Wikipedia's content criteria. Articles for Creation are for IP editors who cannot create an article normally to create a draft for other editors to review. (I don't know if there is a TTL there for drafts, but there should.) Let me also add that the lack of notability is not a trivial reason for deleting an article. Notability is one of the conditions of Wikipedia's content criteria. An article that was previously prodded for lacking notability will find itself at AfD if the prod is contested. —Farix (t | c) 23:46, 25 October 2012 (UTC)
Oppose. No compelling reason to change the current policy/process. PRODs are cheap and I don't see any serious backlogs with requests for refunds. Many PRODed articles are the creations of SPA who can't be bothered to return to the article and address the issues. Most PRODS are probably due to lack of notability, In any case, most of these deletion issues would be resolved if Wikipedia has a proper landing page for newly registered accounts, or at least one for registered users who are about to create/save their first new article in mainspace. All technically possible and promised by the Foundation over a year ago. Kudpung กุดผึ้ง (talk) 02:58, 26 October 2012 (UTC)
Oppose. We userfy articles which may, some day, be reasonable articles which show the notability of their subject. Among other things, this requires that some specific user says that (s)he intends to write such an article. We don't userfy articles (or otherwise move them out of the mainspace) unless a user says that they are willing to. עוד מישהו Od Mishehu 11:43, 29 October 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Avoidance of edit conflicts

Prompted by the "discussion" at Wikipedia talk:New pages patrol#Aggressive new page patrol edit-conflicts, I was wondering if it at all feasible for the software to detect whenever anyone has an article in "edit mode" rather than "reading mode", and put a some form of flag or notice on it, to warn other editors that someone else out there may already be editing the same page. Other software such as text chat programs, often have a "the person you are chatting with is writing a message" type of detection, so it probably is possible. Obviously you'll get some "false positives" when people click on edit, but never click save (ie to read/copy the code), but I'm not suggesting that we prevent editing, just notify the 2nd editor that maybe they should wait a while. Maybe it only has to be done through the NPP or page curation gadget at first, but anything that reduces the chances of edit conflicts should be a good thing. The-Pope (talk) 05:50, 21 October 2012 (UTC)

I see several problems. Vandals can disable the feature by keeping an edit window open. We would then need policies on how to deal with this, more rules for warnings, more rules for blocks and so on. Distinguishing between good-faith mistakes and intentional ones will be hard. Second, because of various time lags, conflicts will still happen. What if somebody else puts in an edit just after I receive the all clear but before I click the edit button? This can be handled (mutual exclusion and critical section handling), but is usually tricky because a software bug could end up locking out all editing. The issue seems to be mainly for talk pages and noticeboards such as WP:AIV. For AIV, the edits are small but frequent. Usually most software supporting concurrent editing either provide better merge tools, or allow branching of versions. We don't want branching; we could have better merge tools, but Wikipedia cannot afford a battalion of developers, and our edit interface will reflect that reality. Churn and change (talk) 16:00, 21 October 2012 (UTC)
And what about editors like me who click edit and come back to it a week later after I find a reference or decide on wording? I have noticed two things, first the merging is better, I often find someone else has added something else and oddly no ec was generated, and secondly if I make an identical edit as someone, the software says I made the edit but the history gives credit to someone else, who made it first. The only suggestion I would make is improving the merging - when someone clicks on a section to create a new section it kicks in an ec when there is no conflict. Apteva (talk) 22:15, 21 October 2012 (UTC)
You click edit, and come back a week later? -- :- ) Don 23:03, 21 October 2012 (UTC)
Sometimes - but then again maybe 26 browser windows/tabs is too many too. Apteva (talk) 21:16, 22 October 2012 (UTC)
  • Comment. - I find {{in use|section}} tags helpful when it comes to avoiding ECs. ~ GabeMc (talk|contribs) 23:05, 21 October 2012 (UTC)
  • Maybe I should have used minimising the chance of edit conflicts not avoidance. I did say that it should not lock out editings, just notify you that someone else may be editing it too. Thinking about it some more, it should also tell when there definitely will be an edit conflict, because someone has already saved an edit. Basically I would like to know how feasible it is to expand the edit conflict detection to be more predictive, dynamic and live in real time, not just on hitting save. The current EC system can remain for when you do hit save, but an improved detection system might help you decide whether to hit refresh first, wait a while or just carry on. Incorporating it into the new page curation tool might be the best first step, to assist in delaying non-vital edits that could otherwise annoy new editors who can't handle edit conflicts. The-Pope (talk) 04:48, 22 October 2012 (UTC)

What if a user in another language has a problem?

Sometimes I see requests on the Help Desk from people who are having problems in another language's Wikipedia, thinking that English Wikipedia is the place to appeal when all other attempts have failed. Is there a possible way to allow such appeals?— Vchimpanzee · talk · contributions · 20:44, 26 October 2012 (UTC)

No. Send'em to meta:. Choyoołʼįįhí:Seb az86556 > haneʼ 21:21, 26 October 2012 (UTC)
That's actually what I was looking for. Thanks.— Vchimpanzee · talk · contributions · 21:36, 26 October 2012 (UTC)
I started a topic here. We'll see if that goes anywhere.— Vchimpanzee · talk · contributions · 22:21, 30 October 2012 (UTC)
As an FYI, you can link to Meta by putting meta: in front of your link, so [[meta:Help Forum]] goes to meta:Help Forum. --Philosopher Let us reason together. 23:41, 30 October 2012 (UTC)
Thanks. I'm not optimistic because the second-to-last question had been asked in June and got no responses. The last question was asked early in October, and no responses there either.— Vchimpanzee · talk · contributions · 14:41, 31 October 2012 (UTC)
Yeah, certain areas of Meta are always active, but many can go dead for a while. You can always leave a note with a Meta admin if your request goes too long without being responded to, though. --Philosopher Let us reason together. 06:15, 1 November 2012 (UTC)

Move translate templates to ref section

I would like to see the Expand by language Wikipedia templates moved to the reference section. They are too imposing when added to the top of the article. See Guarulhos for example and see Dokka Umarov as an example of two of them in use. I cannot think of any policy or guidelines that would prevent this from being done. I put in a request at WP:BTR but it was suggested that I get consensus here first. -- Alan Liefting (talk - contribs) 05:23, 27 October 2012 (UTC)

They now take up less real-estate at the top of the articles then they use to. Not sure if that is a recent change, but I don't see how moving them off the top of the article help will help the articles. The reason those cleanup templates are at the top is so that they will be noticed more and hopefully encourage editors to "fix it". —Farix (t | c) 01:51, 28 October 2012 (UTC)
I oppose moving these to the reference section. They're not references for the article, and no other cleanup templates go in the reference section. Calliopejen1 (talk) 18:32, 31 October 2012 (UTC)

Linking to wiki page

When I copy a url straight to put as a link, I paste it onto the link popup. The problem is that it will only convert my url into short format if I ask it to convert into external, and in the corresponding popup, i click on internal. Things would have been a lot simpler had it straightaway converted to short if i clicked internal.

What I am forced to do [cumbersome if I got to do it 20+ times]

What I want -

What I could do [Again hectic] -

  • I paste Main_Page to popup and have 'Convert to internal'.
  • Link works

Inamos (talk) 20:07, 28 October 2012 (UTC)

I didn't know the feature you refer to but I see it's in the enhanced editing toolbar which has a chain icon above the edit box. I guess the feature is intended to "catch" people who try to use external link syntax instead of an internal wikilink. It's not a recommended way to make a wikilink. It has problems with conversions between encoded url's and page titles. The normal way to make a wikilink is to write or copy-paste the page title seen at top of a rendered page. Main Page hides the title so that's a poor example. Consider Help:Link instead. You can copy-paste "Help:Link" from the top of the page and make it a wikilink by placing double square brackets around it: [[Help:Link]]. Personally I nearly always type [[]] manually instead of going for the mouse. PrimeHunter (talk) 01:33, 31 October 2012 (UTC)
The thing is that I had to quickly copy many links, and for that, the most convenient way would have been to double click and copy the url. If you give an internal link in full (en.wikipedia.org/...), it asks you if you want to convert it to an internal link. If you click yes, it will then autoconvert my long url to internal wiki version. But if i paste a url, and select 'Internal link' from the two radio buttons, then it will not autoconvert it (as it previously did). Rather, it will just give the link as is, making it a dead link. I consider it to be a lot more convenient if the autoconversion [which was there in the previous case] was made implicit; so every time I click 'internal', it checks if the link i give is a full url; and autoconverts it to an internal version, if reqd. Inamos (talk) 15:21, 31 October 2012 (UTC)

Collaboration between WMF and WebCite

I don't know whether this is really the best way to go about this proposal or whether I should propose it on Meta instead. However I propose it as an editor of the English Wikipedia, so let's start here. I have been pointing out for a long time that linkrot is a serious problem for Wikipedia (at least I believe it is). In many cases I used WebCite to archive references in order to ensure a sources availability in the long term. However, WebCite currently seems to be down and I was unable to retrieve previously archived references or archive new ones.

I thought about a closer collaboration between the Wikimedia Foundation and WebCite. Now why should the WMF collaborate with a project which isn't even functioning properly right now? I guess WebCite already has a large collection of cached sources. I used it myself many times and I think some of the sources I archived have already vanished, so (re)gaining access to those sources would definitely be in the interest of Wikipedia. If WebCite could be better integrated into existing Wikimedia projects, a part of WMF funds could perhaps be used to improve WebCite. Of course WebCite should perhaps in return ensure that the service will be available for Wikipedia purposes and can be used by its contributors (an interface for using WebCite here at Wikipedia would be nice). -- Toshio Yamaguchi (tlk−ctb) 08:12, 30 October 2012 (UTC)

Myself and Σ have been working on something somewhat related (see Wikipedia:Bots/Requests for approval/Lowercase sigmabot III), but our main problem has been a lack of response from the WebCite team. We've only heard back from them once, and our follow up emails don't have a response yet. We do know that they are interesting in collaborating with Wikipedia (one of their employees put a bounty up for it). Legoktm (talk) 18:38, 30 October 2012 (UTC)

WP:COI RfC

Of interest: An RfC on our COI guideline for editors with an "intractable" conflict of interest. -- Ocaasi t | c 18:02, 31 October 2012 (UTC)

Delete all indefblock and ban templates

NOT GOING TO HAPPEN
Need I say it...? — Hex (❝?!❞) 09:14, 1 November 2012 (UTC)

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

All templates that say "so and so has been blocked indefinitely" and "so and so has been banned" should be deleted. Using them is gravedancing, therefore they are redundant and inflammatory. - Balph Eubank ✉ 18:20, 30 October 2012 (UTC)

They're not redundant; they inform users that the user is blocked. Whether or not they're "gravedancing", whatever that is, is besides the point. --Tagishsimon (talk) 18:43, 30 October 2012 (UTC)
To dance on someone's grave is a colloquialism that means celebrating someone's death, typically your opponent (in this case, celebrating that the user was blocked). Some folks feel that these templates are meant as an insult to the blocked user. — The Hand That Feeds You:Bite 15:55, 31 October 2012 (UTC)
You forget the point of any template: to explain an issue to the editor and outline their next steps. Deleting the template would only force the blocking admin to handcraft a post explaining this. And then, for convenience sake, someone will put that message in a template. So they are a necessary aspect of blocking. Or, in other words, "I don't like them" is not a compelling argument for deletion. Resolute 18:56, 30 October 2012 (UTC)
I don't mind gravedancing. --Golbez (talk) 18:56, 30 October 2012 (UTC)
They even have their own union! Resolute 19:01, 30 October 2012 (UTC)
They serve a purpose to inform users they've been blocked, especially IPs that bounce around. This proposal is dead-on-arrival. Shadowjams (talk) 18:58, 30 October 2012 (UTC)
See Template talk:Civility. The user is simply upset that he hasn't been able to edit-war his pet essay into the template, hence this disruptive proposal. Joefromrandb (talk) 21:07, 30 October 2012 (UTC)
Kudos to the OP for starting a response on Template talk:Civility with What a bunch of crap. No dissonance there. --Tagishsimon (talk) 21:39, 30 October 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia Radio Streaming

What do you think ?

Can be useful for editors ? For coordination ? --CortexA9 (talk) 04:52, 1 November 2012 (UTC)

Can you please be a little more specific? We generally use IRC to coordinate real-time, and try to not be a social network.--Jasper Deng (talk) 04:59, 1 November 2012 (UTC)

Yes I know it. I mean a wikipedia radio streaming.

Example: I want to improve an article with other editors. I think is useful to listen other editors. --CortexA9 (talk) 05:03, 1 November 2012 (UTC)

The foundation probably cannot commit the resources, so if you want to do this you will have to organize it yourself and get the necessary equipment. I don't see the need.--Jasper Deng (talk) 05:05, 1 November 2012 (UTC)
Or just inform of other changes about Wikipedia. --CortexA9 (talk) 05:08, 1 November 2012 (UTC)
That isn't really streaming is it? I don't think there is even a podcast, or enough material to run new spoken words regularly. --LauraHale (talk) 05:12, 1 November 2012 (UTC)
Yes but a podcast is a different thing than a streaming. --CortexA9 (talk) 05:17, 1 November 2012 (UTC)
I don't understand how it would be particularly useful to have a radio stream in this context, one DJ/Anchor/Whatever talking about improving an article to multiple editors who cannot respond back and only listen just seems weird. Are you thinking of a collaborative voice chat over something like mumble or skype rather then a radio stream? Monty845 05:28, 1 November 2012 (UTC)
I make a wrong example. Sorry, but if we can use the stream for inform downtime, or status of wikipedia ? --CortexA9 (talk) 05:32, 1 November 2012 (UTC)
We have [1] for stats.--Jasper Deng (talk) 05:34, 1 November 2012 (UTC)
Cool. --CortexA9 (talk) 05:38, 1 November 2012 (UTC)
FWIW, there is/was WP:MUMBLE. Don't know how active it is, or if it's even still up. Legoktm (talk) 11:42, 1 November 2012 (UTC)
The online program firetalk originated as a way of allowing multiplayer game players to talk to each other. The speech algorithm used was incredibly good and quickly became firetalk, a stand alone speech platform, but was so good that it became most popular as a way of singing, either acapella or as kareoke over the Internet. They never developed a revenue model and went out of business and users gravitated to other talk over the Internet platforms, such as Paltalk, which eventually bought Firetalk, but long after no one was left there. The excellence of the algorithms used in firetalk, as far as I have seen, has not been replicated, and certainly does not exist in Paltalk. Is that the sort of mechanism that was being suggested? Live audio chat? So that heated arguments can be both audio and visual? Apteva (talk) 15:17, 1 November 2012 (UTC)

Blocklist interface

Hello, i have a proposal regarding the blocklist. Every time I read the blocklist, the whole page is filled with ProcseeBot's blocks and autoblocks, making it next to impossible to find actual users that were blocked. I suggest that there should be a tickbox at the top of the page that, when checked, excludes all the aforementioned types of blocks. Passengerpigeon (talk) 08:43, 1 November 2012 (UTC)

See bugzilla:19322. Legoktm (talk) 11:40, 1 November 2012 (UTC)

Ok, thanks. Passengerpigeon (talk) 22:36, 1 November 2012 (UTC)

You have a new message from another user

The above heading is the one given whenever my talk page is edited. But since its mainly edited only by the RFCBot, thats kind of misleading; as I only wish to check the RFCBot messages at some of the times. I suggest - 1) Have two templates, one for bots, and the other for users, so it clears it up, as well as gives me a way to view them separately. 2) Or removing the ambiguous words 'from another user' from there. TheOriginalSoni (talk) 11:01, 1 November 2012 (UTC)

The way bots work is that if they mark the edit as minor, you aren't notified of their edit. However with newsletterbots, and other notification bots (like DPL bot, RFCBot), the intention is to notify the user. If you get too many notifications by RFCBot, you should probably change your frequency or find a different way to be alerted of RfCs. Legoktm (talk) 11:38, 1 November 2012 (UTC)

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:

  1. Spanish version for Latin American people
  2. German version for German topics
  3. 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)

Oh come on, not one single comment, question, or request for clarification? Rd232 talk 22:52, 27 October 2012 (UTC)
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)

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)
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)
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)

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)

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)

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)
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)
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)
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)
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)

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)

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. Monty845 05:54, 1 November 2012 (UTC)
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)
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)
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)
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)
Okay, I'll do that. Thanks. Psalm84 (talk) 04:32, 3 November 2012 (UTC)

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 ChatOnline 18:11, 3 November 2012 (UTC)

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

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:

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)

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)
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 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)
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)
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)
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)
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)
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)
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)
  • This is an unworkable solution to a nonexistent problem. T. Canens (talk) 14:19, 20 October 2012 (UTC)
  • 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)
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)
  • 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)
    • 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)
  • Comment Perhaps this is really a poor thought out proposal. -- Toshio Yamaguchi (tlk−ctb) 12:50, 21 October 2012 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
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 ChatOnline 18:14, 3 November 2012 (UTC)

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

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)

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)

Label variants
1.

Edit summary (Briefly describe the changes you have made)

2.

Summary of changes:

3.

Edit summary Enter a short summary describing the changes you have made

4.

Edit summary Enter a short summary describing the changes you have made

5.
Edit summary Enter a short summary describing the changes you have made
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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • Number 1. Tooltips are notorious for not popping up - especially on slower connections.Kudpung กุดผึ้ง (talk) 22:29, 24 October 2012 (UTC)
    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)
    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)
    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)
  • 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)
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.

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)

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)
See this relevant blog post by Andy Mabbett. Graham87 12:05, 3 November 2012 (UTC)

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. ϢereSpielChequers 16:54, 25 October 2012 (UTC)

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)
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)
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? ϢereSpielChequers 21:19, 25 October 2012 (UTC)
Facebook doesn't have anything that could conflict. I would suggest Google Docs though.—cyberpower OnlineTrick or Treat 23:08, 25 October 2012 (UTC)

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)

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, ϢereSpielChequers 22:51, 26 October 2012 (UTC)
  • 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)

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)

Good idea. -Fjozk (talk) 16:29, 31 October 2012 (UTC)

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)

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
Looking at http://en.wikipedia.org/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)
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)
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)
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)
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)
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)
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)
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)
Apteva, what film was that? Does it have a Wikipedia article? Narutolovehinata5 tccsdnew 11:03, 3 November 2012 (UTC)
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)
Absolutely not. We should not be censoring Wikipedia as a scheme to raise funds. —Farix (t | c) 09:54, 3 November 2012 (UTC)
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)
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)
Sounds like Witness for the Prosecution (also based on an Agatha Christie story).Nigel Ish (talk) 11:56, 3 November 2012 (UTC)
Good call. Apteva (talk) 17:18, 3 November 2012 (UTC)
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)
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)
When a film is released to the public, it is affectively published. —Farix (t | c) 02:11, 4 November 2012 (UTC)
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)
  • 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)
"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)
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)
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)
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)
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)

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)

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)

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)

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)

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)

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)
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)
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)
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)
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)
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)
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,929,751 articles. Mogism (talk) 22:24, 1 November 2012 (UTC)
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)
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)
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)

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)

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)

Isn't this what the lede is for? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:25, 3 November 2012 (UTC)

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)
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)
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)

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)

I concur. ~ J. Johnson (JJ) (talk) 20:59, 9 November 2012 (UTC)
If the differences between the versions are non-essential, but the articles are organized differently, have different illustrations etc., then it's not a problem at all. If instead the differences are more fundamental, then it's better to have two contradicting versions and to know beforehand that we must doubt them both, than to have only one version and to rely on it, without knowing that all possible biases are still there. So creation of shorter versions of articles can't make any new problems beyond the problems of objectiveness and truthfulness, which are still there in Wikipedia anyway. Contradictions between the abstract and the body of an article are also possible, as well as contradictions between different chapters of an article, but it's not an argument to avoid chaptering articles at all. Oleksiy.golubov (talk) 21:23, 10 November 2012 (UTC)

Average size of the articles of a Wikipedia? (Moved to Idea lab)

I moved this discussion to "Idea lab". Please go there if you want to continue the discussion.Basemetal (talk) 18:15, 10 November 2012 (UTC)

Okay, but could we have link? ~ J. Johnson (JJ) (talk) 00:17, 11 November 2012 (UTC)

New user right proposal.

NO CONSENSUS REACHED BY COMMUNITY
There is a lack of overwhelming support for unbundling most of the admin tools. Users who wish to use them are free to request adminship at WP:RfA. Of the three permissions proposed, editinterface had little support, and tboverride the most support, but failed to reach the threshold of overwhelming support. (I had been working on the close but wanted to wait for a potential answer to the final question.) Apteva (talk) 23:31, 12 November 2012 (UTC)

Admin closure:

I was also working on a close, but Apteva has essentially said what I expected to say. There is almost, but not quite a consensus at this time. Perhaps after a few months of Pending Changes, it can be revisited with a full draft of policy, as it does seem to have majority support, although not a consensus. Dennis Brown - 2¢ © Join WER 19:26, 12 November 2012 (UTC)

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

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 ChatOnline 14:50, 12 October 2012 (UTC)

New user right proposal - Support

  1. As proposer.—cyberpower ChatOnline 14:53, 12 October 2012 (UTC)
  2. 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)
  3. I agree, we need to modularize these tools so that more people can help. Kumioko (talk) 16:32, 12 October 2012 (UTC)
  4. 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)
    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)
    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)
    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)
    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)
    ...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)
    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)
    You appear to have overlooked the "once upon a time" part. —David Levy 02:49, 13 October 2012 (UTC)
    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)
    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)
    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)
    There shouldn't be. That's my point. —David Levy 03:44, 13 October 2012 (UTC)
    "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)
    Methinks that maybe this argument is getting a bit too heated. ⁓ Hello71 22:01, 1 November 2012 (UTC)
  5. 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 talkedits 18:32, 12 October 2012 (UTC)
  6. Good idea, will help trusted non-admins contribute more. Mark Arsten (talk) 18:51, 12 October 2012 (UTC)
  7. Now support -- WOSlinker (talk) 21:14, 12 October 2012 (UTC)
  8. 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)
  9. 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)
  10. 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)
  11. As long as editinterface stays out. Anomie⚔ 02:39, 13 October 2012 (UTC)
  12. Support, as long as "editinterface" stays out of the proposal. Lord Sjones23 (talk - contributions) 02:49, 13 October 2012 (UTC)
  13. 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)
    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)
    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)
  14. Support, seemingly a good idea to unbundle this bit minus editinterface. Regards, — Moe ε 07:56, 14 October 2012 (UTC)
  15. All right, I can get behind this, iff editinterface is out of the proposal. --Rschen7754 08:02, 14 October 2012 (UTC)
  16. 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)
    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)
    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 ChatOnline 11:02, 16 October 2012 (UTC)
    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)
  17. Support, with the same editinterface caveat that others have expressed. Evanh2008 (talk|contribs) 03:54, 16 October 2012 (UTC)
  18. Support. If it's technically feasible, I don't see any problems with this proposal. Tijfo098 (talk) 13:25, 16 October 2012 (UTC)
  19. 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)
  20. 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)
  21. Support - and more user groups in future would be perfect (suppress-redirect and such) Petrb (talk) 12:14, 23 October 2012 (UTC)
    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 OnlineTrick or Treat 12:17, 23 October 2012 (UTC)
  22. Support - This can get more work done. -- FutureTrillionaire (talk) 16:10, 23 October 2012 (UTC)
  23. Support - We're willing and able to help. --Funandtrvl (talk) 16:20, 23 October 2012 (UTC)
  24. 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)
  25. Support yeepsi (Time for a chat?) 16:30, 23 October 2012 (UTC)
  26. 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)
  27. 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)
  28. Support, - needs to be a highish bar, but i support this.Blethering Scot 20:08, 23 October 2012 (UTC)
  29. Support, I trust the people handing it out won't hand it out inappropriately. Gigs (talk) 20:28, 23 October 2012 (UTC)
    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
  30. 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)
  31. Support: Vatican II, baby. Kiefer.Wolfowitz 21:12, 23 October 2012 (UTC)
  32. Support - I can support this.--Amadscientist (talk) 21:21, 23 October 2012 (UTC)
  33. 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)
  34. Support: Good option for non-admins! --Tito Dutta (talk) 21:51, 23 October 2012 (UTC)
  35. 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)
  36. Support - I've no objections. --ceradon talkcontribs 01:51, 24 October 2012 (UTC)
  37. 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)
  38. 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)
  39. 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)
  40. 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)
  41. Support Can't really see any drawbacks.--EchetusXe 09:03, 24 October 2012 (UTC)
  42. 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)
    I find that highly insulting. I ask you please scratch that last sentence.—cyberpower OfflineTrick or Treat 11:20, 24 October 2012 (UTC)
    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)
    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 AccessTrick or Treat 12:42, 24 October 2012 (UTC)
    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)
    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)
    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 AccessTrick or Treat 15:46, 31 October 2012 (UTC)
  43. 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™ ¬_¬™
  44. 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)
  45. 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)
  46. 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)
  47. 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)
  48. 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)
  49. 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)
  50. 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)
  51. 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)
  52. 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)
  53. 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)
  54. 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)
  55. 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)
  56. Support—this makes a lot of sense. Tony (talk) 14:24, 25 October 2012 (UTC)
  57. 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)
  58. 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)
  59. 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)
  60. 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)
  61. 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)
  62. Support - no problem, could be a benefit to the Project. Bearian (talk) 17:22, 25 October 2012 (UTC)
  63. 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)
  64. 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)
  65. 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)
  66. 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)
  67. 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)
  68. 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)
    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)
    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)
    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)
    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)
  69. 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)
  70. 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)
  71. Support – Necessary for people who are not admins, but know a lot about technology.. --Stryn (talk) 19:27, 26 October 2012 (UTC)
  72. Support useful for non admins who know a lot of certain articles Redalert2fan (talk) 20:03, 26 October 2012 (UTC)
  73. 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)
  74. Support. An excellent and sensible idea that should have been proposed years ago. WikiPuppies bark dig 21:24, 26 October 2012 (UTC)
  75. Support - This would be actually quite useful for the project. --WhiteWriterspeaks 22:36, 26 October 2012 (UTC)
  76. 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)
  77. 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)
  78. 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). TruPepitoMTalk To Me 10:24, 28 October 2012 (UTC)
    Sideline Should this reach a consensus? TruPepitoMTalk To Me 10:24, 28 October 2012 (UTC)
  79. 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)
  80. 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)
  81. Support but with caution over who the edit rights are given to. Inamos (talk) 21:04, 28 October 2012 (UTC)
  82. 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)
  83. 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)
  84. Support, a most sensible, rational, and logical proposal. — Cirt (talk) 03:26, 30 October 2012 (UTC)
  85. Support. Archaios (talk) 11:52, 30 October 2012 (UTC)
  86. 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)
  87. 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)
  88. 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)
  89. 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)
  90. Support Probably one of the more useful admin only features that I could use while editing. AIRcorn (talk) 03:21, 31 October 2012 (UTC)
  91. 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)
  92. 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)
  93. Support Ziko (talk) 20:05, 31 October 2012 (UTC)
  94. Support Good option for people who aren't Admins! Davey2010 Talk 00:19, 1 November 2012 (UTC)
  95. 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)
  96. Support with the caveat expressed by others regarding editinterface, and the condition proposed by Rrius (#40).--JayJasper (talk) 05:15, 1 November 2012 (UTC)
  97. Support I think that it's a good idea.--Nust2k11 (talk) 11:45, 01 November 2012
  98. 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)
  99. 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)
  100. 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)
  101. Support Byelf2007 (talk) 2 November 2012
  102. Support Anything that increases editing efficiency is good. -- talk
  103. 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. --Ekabhishektalk 09:53, 2 November 2012 (UTC)
  104. 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)
    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)
    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 ChatLimited Access 17:31, 2 November 2012 (UTC)
    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)
    (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)
  105. 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. Monty845 17:50, 2 November 2012 (UTC)
  106. 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)
    What about calling it "vetted"? Then we can talk about autovetting.. Cesiumfrog (talk) 00:58, 5 November 2012 (UTC)
    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)
  107. 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)
  108. 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)
  109. Support - as RfA is basially failing, let's just unbundle. Claritas § 09:12, 3 November 2012 (UTC)
  110. 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)
  111. Support -- Good idea. Reyk YO! 10:48, 3 November 2012 (UTC)
  112. Support — very much agreed! -- Infestor  T • C 01:09, 4 November 2012 (UTC)
  113. 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" pbp 05:11, 4 November 2012 (UTC)
    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)
    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 pbp 16:31, 4 November 2012 (UTC)
  114. Support I must say old boy, this is a splendid idea. - John Galt ✉ 07:25, 4 November 2012 (UTC)
  115. Support An idea whose time has come. Sasata (talk) 17:31, 4 November 2012 (UTC)
  116. Support. A good and useful proposition. bd2412 T 17:40, 4 November 2012 (UTC)
  117. Support. I think this would take some of the workload off of the admins shoulders. --bender235 (talk) 19:11, 4 November 2012 (UTC)
  118. 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)
  119. 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)
  120. 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)
  121. 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)
  122. 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)
  123. 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)
  124. 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 BeetstraT C on public computers) 05:37, 7 November 2012 (UTC)
  125. 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)
  126. 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)
  127. Yes— Preceding unsigned comment added by Risingrain (talk • contribs)
  128. Support After reading the proposal it seems like a good idea. §h₳un 9∞76 01:13, 9 November 2012 (UTC)
  129. Support –sumone10154(talk) 08:38, 9 November 2012 (UTC)
  130. Support --Ashashyou (talk) 09:06, 10 November 2012 (UTC)
  131. Support editprotected/tboverride, but
    oppose editinterface -- needless and might prove to be counter-productive as Guy Macon said. Mr T(Talk?) (New thread?) 09:37, 10 November 2012 (UTC)
  132. Support, there are many reasons beyond the obvious that would make this user right useful. Non-admins that like to program complex templates, for example, often find themselves locked out of their code once the template becomes popular enough to require protection. This would let them update their code themselves, rather than having to rely on an admin who may not grasp exactly what the code does and might clumsily introduce errors trying to fulfill the edit request. —Scott5114↗ [EXACT CHANGE ONLY] 11:42, 10 November 2012 (UTC)
  133. Support per RobinHood70: this will allow people with no interest in blocking vandals or protecting pages—I'm one of those people—to contribute to the improvement and maintenance of locked pages. Waltham, The Duke of 18:01, 10 November 2012 (UTC)
  134. Support this will be very useful for template maintainers. — Ganeshk (talk) 22:50, 10 November 2012 (UTC)

New user right proposal - Oppose

Not with editinterface rights. -- WOSlinker (talk) 15:16, 12 October 2012 (UTC)

Would you support if edit interface wasn't in there?—cyberpower ChatLimited Access 15:31, 12 October 2012 (UTC)
The edit interface has been removed from the package. I can see where you guys are coming from though.—cyberpower ChatLimited Access 17:40, 12 October 2012 (UTC)
Yes, without editinterface, would support. -- WOSlinker (talk) 19:59, 12 October 2012 (UTC)
He removed the editinterface a little earlier. Kumioko (talk) 20:05, 12 October 2012 (UTC)
Ok, moved to support. -- WOSlinker (talk) 21:14, 12 October 2012 (UTC)

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)

"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)
The edit interface has been removed from the package. I can see where you guys are coming from though.—cyberpower ChatLimited Access 17:40, 12 October 2012 (UTC)
Editinterface opens too much opportunity for mischief. I would support a package with editprotected and tboverride only. Anomie⚔ 17:26, 12 October 2012 (UTC)
The edit interface has been removed from the package. I can see where you guys are coming from though.—cyberpower ChatLimited Access 17:40, 12 October 2012 (UTC)
Moving to support now. BTW, is is really necessary for your signature to include two linebreaks? Anomie⚔ 02:39, 13 October 2012 (UTC)
  1. 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)
    That's clearly nonsense. No wonder things go from bad to worse here. Malleus Fatuorum 17:36, 12 October 2012 (UTC)
    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)
    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)
    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)
    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)
    Agreed. And this type of unbundling would firmly cement it as such. —David Levy 18:12, 12 October 2012 (UTC)
    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)
    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)
    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)
    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)
    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)
    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)
    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)
  2. 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)
    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 ChatLimited Access 17:44, 12 October 2012 (UTC)
    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)
    I'll discuss on your talk because it'd be inappropriate here as you mentioned.—cyberpower ChatOffline 18:11, 12 October 2012 (UTC)
  3. Sorry, but anybody trusted to edit the interface should be trusted to pass RfA first. PeterSymonds (talk) 17:46, 12 October 2012 (UTC)
    The edit interface has been removed from the package.—cyberpower ChatLimited Access 17:48, 12 October 2012 (UTC)
  4. 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)
    PC level 2 (full protection to most) has been outlawed via RfC. What about title blacklists?—cyberpower ChatOffline 18:20, 12 October 2012 (UTC)
    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)
  5. 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)
    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)
    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)
    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)
    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)
    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)
    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)
  6. Oppose Waiting for PC is a better idea. Choyoołʼįįhí:Seb az86556 > haneʼ 03:54, 13 October 2012 (UTC)
    Whats PC? Kumioko (talk) 03:57, 13 October 2012 (UTC)
    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)
    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)
  7. 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)
    The edit interface right has been removed from the bundle. This user group would not allow access to the interface pages.—cyberpower ChatOffline 04:18, 13 October 2012 (UTC)
    (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)
  8. 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)
  9. 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)
    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)
  10. 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)
    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 ChatLimited Access 12:48, 15 October 2012 (UTC)
  11. Oppose - doesn't address the issue, which is over protection of pages. Nobody Ent 15:27, 23 October 2012 (UTC)
    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)
  12. 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)
  13. Oppose per Malleus and Ryan, as seen above. TBrandley 20:20, 23 October 2012 (UTC)
    You realize you are citing a sarcastic oppose-that-wasn't-really-oppose right? Gigs (talk) 20:26, 23 October 2012 (UTC)
  14. 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)
  15. 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 SoWhy 21:25, 23 October 2012 (UTC)
    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)
  16. 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)
    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)
    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)
  17. Oppose - I don't see a need for another stratum of user permissions. --EEMIV (talk) 15:37, 24 October 2012 (UTC)
  18. 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)
    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)
    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)
  19. 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)
    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)
  20. 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)
    Your oppose rationale makes no sense.—cyberpower OnlineTrick or Treat 00:06, 25 October 2012 (UTC)
  21. 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)
  22. 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)
    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)
  23. 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)
    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)
  24. 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)
    • 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)
  25. 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)
  26. 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)
  27. 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)
  28. 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)
  29. 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)
  30. Oppose. Unnecessary added layer of complexity.--Bbb23 (talk) 18:19, 26 October 2012 (UTC)
  31. 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)
    And what about complicated templates protected automatically under WP:HRT? - Floydian τ ¢ 05:34, 30 October 2012 (UTC)
  32. 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. Deryck C. 17:03, 27 October 2012 (UTC)
  33. 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)
  34. Oppose WP:RFA. One problem at a time, please. Ajraddatz (Talk) 21:21, 27 October 2012 (UTC)
    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)

    Actually, we started talking seriously about RFA reform more than four years ago. —Kusma (t·c) 19:00, 28 October 2012 (UTC)
  35. 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)
    Articles aren't the only thing that receive full protection.—cyberpower OnlineTrick or Treat 00:58, 28 October 2012 (UTC)
    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)
  36. Oppose - I agree with User:Deryck Chan. Tony the Marine (talk) 01:33, 28 October 2012 (UTC)
  37. 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)
    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)
    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)
    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)
    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)
    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)
    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)
    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)
  38. Oppose Creates more hierarchy without significant benefit. wctaiwan (talk) 16:11, 28 October 2012 (UTC)
  39. Oppose, everyone who can be trusted with editprotected can be trusted with adminship. —Kusma (t·c) 19:00, 28 October 2012 (UTC)
  40. 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)
    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 OnlineTrick or Treat 13:03, 31 October 2012 (UTC)
  41. Oppose Fix RFA if it's broken. Don't implement this simply as a workaround. --Shanes (talk) 15:22, 29 October 2012 (UTC)
    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 OnlineTrick or Treat 13:03, 31 October 2012 (UTC)
  42. '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)
  43. 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)
    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)
    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)
    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)
    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)
  44. 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)
  45. 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)
    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)
    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)
  46. 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)
    It's also applied to high-risk templates. Here is a list of fully protected pages. Graham87 11:27, 30 October 2012 (UTC)
  47. 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)
    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)
  48. 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)
  49. 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)
    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)
    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)
  50. 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)
    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)
    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)
    Kww, please note that PC2 has been killed for the time being.—cyberpower Limited AccessTrick or Treat 12:46, 31 October 2012 (UTC)
    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)
  51. 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)
    "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)
  52. 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)
  53. 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)
    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)
    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 SoWhy 16:05, 1 November 2012 (UTC)
    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)
    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 SoWhy 18:41, 1 November 2012 (UTC)
    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)
    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)
    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)
  54. 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)
  55. 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)
  56. Oppose This can be as sensitive as anything else an admin does. DGG ( talk ) 18:37, 1 November 2012 (UTC)
    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)
    Admins are not vetted for editing ability or experience. What? WP:RFA exists for a reason. Legoktm (talk) 20:25, 1 November 2012 (UTC)
    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.
  57. 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)
  58. Oppose Wikipedia is already too complex. Apuldram (talk) 10:43, 3 November 2012 (UTC)
  59. Oppose per David. Samsara (FA • FP) 20:42, 3 November 2012 (UTC)
  60. 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)
  61. 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)
  62. Oppose as per wctaiwan. DS (talk) 12:25, 5 November 2012 (UTC)
  63. 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)
  64. 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)
    How will this right give the editors the power to prevent others from editing?—cyberpower ChatLimited Access 17:21, 5 November 2012 (UTC)
  65. 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)
    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)
    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 ChatLimited Access 13:57, 7 November 2012 (UTC)
  66. 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)
    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 BeetstraT C on public computers) 05:47, 7 November 2012 (UTC)
    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)
  67. 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)
    No editor has the right to edit as they please on a fully protected page – this proposal changes nothing on that front. Any editor who uses their tools in such a way should have said tools removed, whether that be these tools, adminship or founder status. —WFC— FL wishlist 19:18, 10 November 2012 (UTC)
  68. 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)
  69. 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)
    Oppose nonsense. Choyoołʼįįhí:Seb az86556 > haneʼ 01:27, 9 November 2012 (UTC)
  70. Oppose. The guidelines for how this would be granted seem vague and arbitrary. StAnselm (talk) 22:06, 9 November 2012 (UTC)
  71. Strong Oppose. Not needed. Harsh (talk) 11:48, 10 November 2012 (UTC)
  72. Oppose. apart from adding complexity to level of editors, full protection is added for good reasons and editing fully protected pages should be carried out only by those that know exactly what they are doing. Such rights should not be handed out lightly without the corresponding responsibilities.GraemeLeggett (talk) 14:55, 10 November 2012 (UTC)
  73. Oppose the potential for damage on editinterface is veeeery high, as seen recently on other wikis and fully protected pages should not be edited *period*, save rare occasions. Snowolf How can I help? 18:23, 10 November 2012 (UTC)
    Editinterface is not included in the proposal. Churn and change (talk) 18:55, 10 November 2012 (UTC)
  74. Oppose: Given the way Rollbacker is almost never revoked, even when privilege holders have been blocked multiple times for edit warring, I see this as another class of editors that will likely be similarly difficult to patrol abusers. What we have for page protection today works fine, unlike rollbacker. Toddst1 (talk) 19:00, 10 November 2012 (UTC)
    The crux of your argument is a lack of admin numbers (to have time to deal with known problematic rollbackers), or a lack of admin competence (knowingly leaving rollback in the hands of people with a long history of edit-warring) amounts to a good reason for retaining the status quo. —WFC— FL wishlist 19:18, 10 November 2012 (UTC)
    More or less yes, but the problem is more social than numerical. If someone has enough experience to get the rollback bit, they almost always have folks that think highly of them. I've seen a number of situations where even though a rollbacker was clearly edit warring (and even blocked in many cases), the edit-warrior brought the admin who removed the rollbacker bit to ANI where the ochlocracy that ensued pilloried the dutiful admin. See WP:NOTNAS#There_really_is_a_double_standard. Toddst1 (talk) 23:25, 10 November 2012 (UTC)
  75. Strong Oppose: Not needed and creates more hierarchy without significant benefit. I also agree with Toddst1. ʈucoxn\talk 22:19, 10 November 2012 (UTC)

New user right proposal - Discussion

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)
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 ChatOffline 18:08, 12 October 2012 (UTC)
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)
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)
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)
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)
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)
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)
Hear, hear. — Hex (❝?!❞) 07:39, 15 October 2012 (UTC)
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)
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)
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)
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)
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.
Good one!
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)

What problem is meant to be solved here?--Tznkai (talk) 19:07, 23 October 2012 (UTC)

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 OfflineTrick or Treat 20:05, 23 October 2012 (UTC)
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)
Considering how long it took for my edit request to be answered for a protected page, yes.—cyberpower OnlineTrick or Treat 21:16, 23 October 2012 (UTC)
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)
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)
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)
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)

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)

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)

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)
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)

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)

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)

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 OnlineTrick or Treat 14:03, 20 October 2012 (UTC)
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)
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)
I've already posted an edit request there but has been ignored so far.—cyberpower OfflineTrick or Treat 03:18, 21 October 2012 (UTC)
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)
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)
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 OnlineTrick or Treat 14:58, 20 October 2012 (UTC)
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)
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. Monty845 17:56, 2 November 2012 (UTC)

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)

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)
I'm for the new protection level, then. Daniel Case (talk) 18:54, 26 October 2012 (UTC)
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)
It won't, those rights are given with edituserjs and editusercss. Legoktm (talk) 17:18, 28 October 2012 (UTC)
I left those out for obvious reasons.—cyberpower OnlineTrick or Treat 17:28, 28 October 2012 (UTC)

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)

With the current technical implementation of the proposal, yes. Legoktm (talk) 17:09, 28 October 2012 (UTC)
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)
Thanks for correcting me, you learn something new everyday. Legoktm (talk) 18:11, 28 October 2012 (UTC)
Okay, that makes sense. Thanks Anomie! David1217 What I've done 03:52, 30 October 2012 (UTC)
  • 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)
    • 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)
      • 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)
        The "editprotected" right was created specifically for bots. See bugzilla:13137. Ruslik_Zero 19:34, 29 October 2012 (UTC)

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)

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)
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)
True to that and I can think of a few admins that do that.—cyberpower Limited AccessTrick or Treat 15:58, 31 October 2012 (UTC)
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 AccessTrick or Treat 15:58, 31 October 2012 (UTC)

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)

No it wasn't. It was for using PC2 protection in general.—cyberpower OfflineTrick or Treat 18:07, 31 October 2012 (UTC)
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)

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)

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)
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)
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)

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)

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)

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)
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)
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)
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)
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)
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)
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)
  • 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? StAnselm (talk) 00:54, 8 November 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_95&oldid=1147965788"