It keeps bugging me that we're not being newcomer-friendly enough when we first block them for bad username, then force them to grok templates to requests an unblock (easy as it may sound to us oldies, I see a lot of people experiencing problems even with simple ((unblock-un|new username|reason here))). Then when we unblock we have no other option than make them go to WP:CHU to file a request (more templates, yay!), being passive-aggressive about blocking them again if they don't do so. How many potential contributors are we losing along the way? To remedy this, I propose to allow admins to rename user accounts so that they could rename such users themselves when unblocking. Of course, this means that we would drastically increase the number of people who can perform potentially large-scale changes, so I propose that we technically limit admins to renaming new users (with less than 100 edits) only. If this proposal passes, I volunteer to implement the coding part myself. Max Semenik (talk) 12:55, 28 December 2015 (UTC)

Reading WP:CHU, don't you just mean you want all enwiki admins to also be m:Global renamers? Bazj (talk) 13:03, 28 December 2015 (UTC)

This should be speedily closed. Rename permissions are global only, and based on the meta:Global rename policy. Only a request for comment on meta(meta:Requests for comment) can change global policy.--Müdigkeit (talk) 13:18, 28 December 2015 (UTC)

• Per Müdigkeit.Renaming permissions are now global based on meta:Global rename policy as it is a now a Single Unified Login for all Projects . Only a request for comment on meta(meta:Requests for comment)is needed as it now involves global policy. Pharaoh of the Wizards (talk) 14:04, 28 December 2015 (UTC)

I can't go to Meta before making sure that we as a community want this. This is a problem mostly of our Wikipedia and maybe 2-3 other large wikis, as others just don't have the scale. Max Semenik (talk) 15:42, 28 December 2015 (UTC)

• This is a non-starter, but admins who deal with username issues a lot should feel free to apply for global renamer. We even have a non-admin here who has the permissions. –xeno^talk 16:16, 28 December 2015 (UTC)
• Hello, I'm the first non-admin global renamer (to my knowledge, at least), and thanks Xeno for pinging me. I don't think this proposal will go very far, because as others have said, renames are now done globally by global renamers and stewards, and they require knowledge in how global accounts work (something that some non-bureaucrat admins here don't actually know much about!). I would, however, suggest that admins be allowed to at least view (but not process) requests on m:Special:GlobalRenameQueue, which are made at Special:GlobalRenameRequest, the non-template way of requesting a username change. This has happened to me once before (see User_talk:C.Fred/Archive_17#Comments_on_User_talk:BETAKAPPAGAMMA), where an admin got confused when the blocked user claimed to have filed a rename request, but they did it at Special:GlobalRenameRequest and not WP:CHUS as the admin was expecting. Since requests made at GlobalRenameRequest are only visible to global renamers and stewards, the administrators that actually do the blocking/unblocking have no idea what's going on. In other words, there is a communication barrier between the administrators that block and unblock user accounts with inappropriate usernames, and the renamers that do the actual renaming to stop an account from being reblocked. —k6ka 🍁 (Talk · Contributions) 17:02, 28 December 2015 (UTC)
• Is this even technically feasible with SUL (short of allowing local admins to rename globally, which seems like a non-starter)? wctaiwan (talk) 21:34, 28 December 2015 (UTC)

• I agree with what's being said here: it would be nice if such a thing were practical, and I would support the proposal were that the case, but I don't believe that it's possible to do without a massive amount of work. Nyttend (talk) 22:11, 28 December 2015 (UTC)

• It's would not be a lot of work from a technical perspective (perhaps to add the restrictions MaxSem had originally envisioned), but because renamers are now always 'global renamers' (except in case of Stewards, who can still access the local rename facility for very limited purposes and reasons), it is required that anyone who wants to use the global rename facility apply through meta so that users from all projects can comment on the suitability of the request since they will now be acting at some times, on all projects simultaneously. –xeno^talk 23:51, 28 December 2015 (UTC)

• All accounts nowadays are global and a rename would be for all 800+ projects. Adminship on one project does not mean you understand all other projects. Furthermore, giving such an ability to 1000+ unexperienced people is not a good idea. For example renaming someone with alot of edits wrongly could down the website, which is why it is only done under supervision of one of 2 sysadmins. This should not be done by 1000+ people, because with big numbers, if it can go wrong, it will go wrong. If admins want to be more helpfull, make it so admins fill in the rename request themselves and post a link to the user's request. Maybe make an admin tool for this. This way the user does not have to go anywhere outside their own talk page and admins can ask for renames. Sincerely, Taketa (talk) 14:55, 29 December 2015 (UTC)

I have worked up a proposed change to Wikipedia (it is here Zedshort (talk) 19:35, 13 January 2016 (UTC)), wherein a person would be able to easily ask a question about a subject (article) and receive answers from people who volunteer to assist with answering questions about the subject. It is a bit long, so at present I have it on my talk page. Is this page or my talk page the appropriate place for a discussion of that proposal; perhaps I should post it here? I understand that there is a Reference Desk, but that strikes me a less dynamic and convenient then my proposal. Zedshort (talk) 15:35, 13 January 2016 (UTC)

There are many Q&A sites on the web. Some of them (e.g. Stack Overflow and its sisters) are very good. Wikipedia would not do a good job of it. Relentlessly (talk) 16:00, 13 January 2016 (UTC)

There are many very, very mediocre Q&A sites and Wikipedia can do something more than they can. If there are other sites it does not follow that Wikipedia should not try to improve itself, and I am certain that this proposed change would do just that. Have you read my proposal? Please try to critique the proposal rather than to react. Zedshort (talk) 17:40, 13 January 2016 (UTC)

Sorry, I don't mean to be brusque. I think your proposal is a very good one, and it would be a very good start if it were a good idea in principle. I think it's fundamentally a bad idea, however. Like the Unix principle of having small discrete items of software to do discrete tasks, websites shouldn't try to do everything for everyone. Questions and answers are very hard to do well and I don't see that we need to duplicate that here, when there is so much to be done in terms of building an encyclopaedia. Fundamentally, your proposal is contrary to one of the major pillars of Wikipedia. Relentlessly (talk) 19:41, 13 January 2016 (UTC)

I just noticed that you said that this idea is "your proposal is contrary to one of the major pillars of Wikipedia." I just glanced at the Pillars and did not see how that is true. Could you expand and be very specific as to how this proposal is fundamentally in opposition to WP Pillars? Zedshort (talk) 20:49, 13 January 2016 (UTC)

"Wikipedia is an encyclopedia". It has a purpose and everything else should be directed towards that goal. See also WP:NOTFORUM. Your proposal would be taking effort and attention away from building an encyclopedia and putting it into a difficult medium to get right – Q&A. There are sites that already do that well. Relentlessly (talk) 21:01, 13 January 2016 (UTC)

You are expressing your personal opinion as if it is enshrined in WP Pillars, but that is a grotesque stretch. Also, having a simple question and answer feature is certainly not a violation of WP:NOTFORUM by any stretch of the imagination. Please try to respond in a constructive manner with respect to this proposal. That doesn't mean you have to agree with me just don't throw up the blue flags in a random manner. If you intend to blindly oppose all changes to WP I suspect you should not be commenting on anything like this. Zedshort (talk) 21:42, 13 January 2016 (UTC)

It seems fairly simple to me. Wikipedia is an encyclopedia. Question and answer is something very different from an encyclopedia. Not totally unrelated, but very different. It's also something that's very hard to implement in a good way, as many, many websites have proven over the last two decades. I've clearly offended you and I'm sorry about that. Relentlessly (talk) 22:14, 13 January 2016 (UTC)

You haven't offended me. I have been on WP for seven years and have developed a very thick hide and solid and tough kernel; believe me, there is nothing anyone could say that will offend me as I have heard it all. I am bothered when people act in a disingenuous fashion and throw up the blue flags of Wikipedia in a seemingly random manner. No one can have a discussion when you have people doing what amounts to running interference on an idea. Zedshort (talk) 23:58, 13 January 2016 (UTC)

RD may be less dynamic and convenient (and many don't even know it exists), but it gives fairly good answers (or assistance in finding good answers elsewhere) considering their price (0). I can't see devoting developer time, and adding complexity to an already-too-complex environment, for something that would divert resources from Wikipedia's main mission as an encyclopedia. Please try to critique the proposal rather than to react. I know it's painful, but anyone bringing any proposal must be prepared to accept "sorry, I think it's a bad idea" as a response. ―Mandruss ☎ 18:09, 13 January 2016 (UTC)

I fully expect critiques of the proposal, but statements such as "It has already been done" are just plain silly. What is Wikipedia but another encyclopedia, many of which existed prior to Wikipedia? If the critique that "It has already been done" was sufficient, nothing anywhere would change. As for the argument about resources goes, I honestly don't know how many resources are available. If you know and can use that data to provide a critique that has some solidity to it I would appreciate your effort. Share the data with me so I can respond, but as it stands that argument is simply groundless. I agree that the system seems complicated, but much of the complexity is the result of a poorly thought out interface. A change that actually enhances the education value of Wikipedia would be a plus. Zedshort (talk) 18:32, 13 January 2016 (UTC)

Sorry, no hard data. It's intuitive to me that few people would come to Wikipedia just to answer questions. That means that, for the most part, any time spent answering questions would be time not learning policy/guideline and contributing to article content. That's what I meant by diversion of resources.
The complexity I refer to has more to do with the mind-boggling morass of overlapping, unnecessarily complex, confusing, overly verbose, and often contradictory policies and guidelines created by a cast of thousands with no central coordination or control, and it's all part of what new editors are faced with. Every new feature adds a degree of complexity to that landscape, adds new elements (words, links, icons) to a page that the user sees, whether they use them or not. In my opinion, that complexity, and the community's failure to require people to behave like adults or leave, are the two main things that drive potentially good editors away. ―Mandruss ☎ 19:00, 13 January 2016 (UTC)

Thanks for a more solid response, I really do appreciate it and I am in alignment with you on most of that, and in particular the idea that "the community's failure to require people to behave like adults or leave, are the two main things that drive potentially good editors away"." I have been here for seven years and have the distinct impression (of which I am certain) that the nasties have in fact driven away many good and gentle people. As far as the diversion of human resources, I disagree. I suspect that those who are attracted to education will come here to assist with that function but stay to improve Wikipedia when they see a need. In addition, I suspect that the new crew this proposal will attract just might be the type of people needed to improve the population of editors. In summary, what Wikipedia needs (in addition to this proposal) are many more adults to watch the kids. Simply having more adults around, I suspect, will prompt the kids to behave. Thanks for considering the proposal. Zedshort (talk) 19:18, 13 January 2016 (UTC)

Off topic, but there are far more adults behaving like kids than kids. You can tell by what they know and how they write. ―Mandruss ☎ 19:25, 13 January 2016 (UTC)

That is what I meant. Zedshort (talk) 19:37, 13 January 2016 (UTC)

If there is a relevant Wikiproject then they can ask their questions there or in the talkpage of the related article. For your idea, how are people going to get notified of such a question and how will the reader know if there is an editor out there that considers themselves an expert on the subject? And to be honest, its a relatively small proposal. Its not something that would really improve Wikipedia because we already have Wikiprojects and talkpages. Its not "silly" its just not that intuitive.

If you could explain why we need this over Reference Desk/Wikiproject/talkpages? However, this sparked an idea where people can review articles and ask questions based on any particular "gaps" that could work well for a "ask a question". Something that if someone was looking into improving an article, they can look at the questions that the article brought up and see if it can improve sort of like something that pre-peer review/GAR. Lucia Black (talk) 19:09, 13 January 2016 (UTC)

I have posted the proposal on my Talk Page as I was uncertain as to where to post it. Is this the appropriate place? I don't know how to respond to the point that "Reference Desk already exists." Is the Reference Desk heavily used? Is it convenient? The idea that people asking questions would point out "gaps" in the article is very true. Personally, if I was reading an article and found something lacking or had a question I would prefer to follow the simplest path to an answer via a button on that article. I have enough experience that I am comfortable with the "Talk" page but very few people who come here to simply read are. The editor used fro that purpose is intimidating. As for introducing redundancy, as a structures engineer I believe, "Roses are red, violets are blue, redundancy is good for you." If we didn't believe redundancy was of use why would people buy books, they would simply use the library or if encyclopedias existed before this, then why Wikipedia? Zedshort (talk) 19:29, 13 January 2016 (UTC)

I don't think all that should copied to this page. This discussion serves as your proposal, the contents of your talk page is reference information. A user subpage would probably be better suited to the purpose than your talk page, however. Eventually this discussion will be archived and it should point to the reference information indefinitely.
In my opinion, most of the solutions that justify increased complexity have already been implemented. In the software world, this is called a mature system. This is why I tend to oppose most new features that add complexity for most or all users. Feature creep is just as bad as instruction creep, if not worse, so to my mind a new feature has to be more than "nice to have". Given that RD already provides ~75% of this benefit, and given that both are outside the scope of Wikipedia's main mission, I consider your proposed feature a "nice to have".
In engineering, as I understand it, redundancy is good because it increases reliability. That is not the case here. To the contrary, redundancy here increases complexity with insufficient benefit in return.
Why Wikipedia? AFAIK, Wikipedia was the first crowd-sourced encyclopedia, or the first one that gained any popularity. ―Mandruss ☎ 20:14, 13 January 2016 (UTC)

Sorry I used the structures analogy. I should have pointed out that there are bottle-necks in the education system that people have been attempting to widen for decades but to little effect. One solution to a bottle-neck is to build a path around it. Wikipedia is one alternate path to education. A feature that enhances the ability of Wikipedia to educate is a positive thing. Your blind opposition to any proposal that would increase WP's "complexity" is seems almost like a knee-jerk reaction, that would apply to any and all proposals. At which point you come across in a totally negative manner. Are you seriously thinking about this proposal or some other vaguely expressed idea floating about in your mind to the effect: "It is complicated." I would prefer to respond to critiques that are somehow backed up with real data. Zedshort (talk) 20:35, 13 January 2016 (UTC)

That's entirely unfair. I brought as much real data as you did (none). The burden is on the proposer. I'm done. ―Mandruss ☎ 20:55, 13 January 2016 (UTC)

Comment Got to agree with @Relentlessly: and @Mandruss: here. This is an encyclopedia project, not a Q&A site. You should go ahaead and crowd-source and build the thing you're proposing. This just isn't the place. Regards, GenQuest ^{"Talk to Me"} 23:23, 13 January 2016 (UTC)

Why is this not a "question and answer place"? Has there been some discussion about that that has resulted in a solid consensus and a guideline (a temporary rule waiting to be broken)? It seems that in order to get a real discussion of a proposed change, I must first run a gauntlet of knee-jerk reactionaries that are opposed to any and all change. I am very willing to do that.

Wikipedia is an encyclopedia that is destined to grow into something more dynamic and not just a repository of factoids. Central to the idea of an encyclopedia is to present knowledge so that others can self-educate themselves. I am convinced that only a very small fraction of the population is able to self-educate, in particular young people. We need to open this up just a bit wider to make Wikipedia a real success. We have a compilation of facts, now it is time to breath some life into the project. Otherwise it might slowly die. Zedshort (talk) 23:46, 13 January 2016 (UTC)

Despite all the discussions in Wikipedia, there hasn't been a discussion and consensus developed around every possible idea and procedure. And there never will be—it'd be a colossal waste of effort. People have built-in preprocessing filters to avoid that. So please, just a proposal, no advocacy. If you don't like the first half dozen responses, don't take it personally—consider it as the product of evolution. You pitched an idea—it didn't gain traction. Figure out why not, try again... later... in a different venue, if necessary. — Neonorange (talk) 01:20, 14 January 2016 (UTC)

I am puzzled. What do you think I should be doing here? Am I simply to throw out some idea only to see the people who have apparently decided that no proposed idea should be considered due to reasons such as "it's too complicated" when they don't explain what that means; or "It's too expensive," but they fail to explain what that means; or "It has already been done here as Reference Desk," when Reference desk is little used. Believe me, I don't take this personally, but the proposal has been offered for all of one day and attacked by people who cannot articulate what they mean. That is a bit disturbing.

What does this mean: "Despite all the discussions in Wikipedia, there hasn't been a discussion and consensus developed around every possible idea and procedure. And there never will be—it'd be a colossal waste of effort." Yes, true, and how does that relate to this proposal? "People have built-in preprocessing filters to avoid that." Agreed, but what is your point? "So please, just a proposal, no advocacy." Are you suggesting that I should not respond to insipid and pointless responses? "Figure out why not, try again... later... in a different venue"? I have figured out that there are some very negative people lurking here, it has been one day, and what other venue are you suggesting? Is Village Pump not the place for such a proposal? I am puzzled. Zedshort (talk) 01:56, 14 January 2016 (UTC)

What do my points mean? In a nutshell, you have to do the work to get other people interested. No one is going to sell it for you. "Are you suggesting that I should not insip and pointless responses?" Yes. There are questions you must answer. Work until you are not puzzled, make another try. No one is evidently going to do it for you. You can't force people to see your project as you do. — Neonorange (talk) 05:54, 14 January 2016 (UTC)

Good grief! Sorry, Zedshort, but I have to agree with everyone other than yourself here. There's more than enough for Wikipedia editors to try to do without adding what would be a phenomenal amount of extra work. It would detract from the work that needs to be done on Wikipedia itself and furthermore could never be done as well as Wiki editors would like. I'm sorry, nice idea, if we were in a perfect world....but. In my opinion, this suggestion should be filed in the Wiki equivalent of that part of the filing system which no-one ever gets to look at again. Zedshort, be realistic. If your proposal was ever to get off the ground you would have had to have had someone agreeing with you by now. No-one has. I reckon you should just drop it, my friend. Boscaswell (talk) 17:29, 15 January 2016 (UTC)

If one views an old revision, there is a functional "Edit" link at the top. If they edit the revision, it reverts all edits made after the time of that revision. I've done this unintentionally once; I decided to edit the article and simply forgot I was looking at an old revision. I've also seen this done once by another editor. In that case, it probably would have gone undetected had I not noticed the problem three days after the fact. I happened to view the diff and noticed that the edit reverted recent edits that had nothing to do with the edit summary provided. After three days, the edit was un-undoable and somewhat difficult to fix.
When this happens, there is no indication in the page history that an old revision was restored, only the edit summary as entered by the user. Thus, it can easily go undetected unless the diff is closely examined and compared to other recent edits.
While the edit session gives a red warning about this at the top, it is easily missed. Clearly, it was not enough to prevent the error in the two cases cited. We should be idiot-proof wherever possible.
There are other ways to restore an old revision, and they create edit summaries that explicitly indicate that an old revision was restored. While those "other ways" may require one to enable a tool such as WP:Twinkle, doing so is well within the ability of an editor who has enough experience and competence to consider restoring old revisions.
While it might be possible to pre-fill the edit summary field with something meaningful, I doubt we could prevent the editor from removing that before saving.
PROPOSAL: I feel this Edit link offers more potential for unintentional harm than for good, and it should be changed to view the source in a read-only mode, with the text "View source" or something similar. ―Mandruss ☎ 04:39, 20 January 2016 (UTC)

• Support as proposer. ―Mandruss ☎ 04:39, 20 January 2016 (UTC)
• Oppose being able to edit an old version is also a good way to bring forward partial fixes for older vandalism that can't simply be undone. IE click edit on old version copy the text to be restored out. Click edit on current version paste the text back in place. I've also used in reverse as well to reapply good edits that happen in the midst of vandalism. I would support autotagging such edits however. PaleAqua (talk) 04:54, 20 January 2016 (UTC)
• Oppose per PaleAqua. DH85868993 (talk) 04:56, 20 January 2016 (UTC)
• Oppose. It's an efficient way to revert to an old reversion. Steel1943 (talk) 05:16, 20 January 2016 (UTC)
• Oppose Utterly unnecessary. The minuscule number of times this could happen is no reason to alter the way edit function works. For one thing you can always revert to the version before the mistake and start again. MarnetteD|Talk 05:22, 20 January 2016 (UTC)
• Oppose PaleAqua is correct - this is an extremely useful facility. - Sitush (talk) 05:49, 20 January 2016 (UTC)
• Oppose per PaleAqua and Steel11943. --Dirk Beetstra ^{T C} 05:54, 20 January 2016 (UTC)
• Oppose - I appear to be using the "edit" link for restoring revisions. Much easier than having to copy all of the source code (which itself has issues too, such as having to remove excessive numbers of dashes and spaces). Qwertyxp2000 (talk | contribs) 08:56, 20 January 2016 (UTC)

By the way, agreeing per PaleAqua and Steel1943. Qwertyxp2000 (talk | contribs) 08:57, 20 January 2016 (UTC)

• Oppose removal per above, but I think we could do more to idiot-proof this: in the edit link you refer to, it is easy to overlook the warning that one is editing an old revision, as it is the middle one of three red boxes, and the semi-protection one is more prominent. How can we improve the interface in this situation? —Kusma (t·c) 11:59, 20 January 2016 (UTC)
  • We could change the colour, perhaps. FWIW the notice is located at MediaWiki:Editingold. Sam Walton (talk) 12:04, 20 January 2016 (UTC)
    • EditInGold .. it must be good then. --Dirk Beetstra ^{T C} 12:51, 20 January 2016 (UTC)
• Per Steel1943, oppose. It's going to be snowing on the East coast soon... --Izno (talk) 12:54, 20 January 2016 (UTC)
• Oppose It is a 'feature not a bug'. I do agree that auto-tagging such edits would be a good idea per all above. Jbh^Talk 13:07, 20 January 2016 (UTC)
• Oppose - I think such incidents are very rare. A solution looking for a problem. Kudpung กุดผึ้ง (talk) 13:31, 20 January 2016 (UTC)
• Oppose - Sorry to pile on but I occasionally use the edit function on prev revisions to remove vandalism .... No need to remove the feature IMHO. –Davey2010^Talk 13:55, 20 January 2016 (UTC)
• Pile-on oppose. I can imagine the mistake being done, but forcing me to (View Source, copy/paste it into the edit window, and save) is a real waste of time, and it would be unhelpful in the numerous situations that reverting several edits is necessary. Nyttend (talk) 14:06, 20 January 2016 (UTC)
• Comment - Re relative emphasis of the warning message, it appears the message already has the highest level of emphasis supported by the template that produces it, ((fmbox)). Some of the other red messages around it could be de-emphasized, which might help a little. Any other color change would require a change to ((fmbox)). These partial solutions and autotagging are outside the scope of this proposal, however. Closing. ―Mandruss ☎ 21:26, 20 January 2016 (UTC)

IMHO, categorizing should be gotten rid of, on Wikipedia. Categorizing can be an area of dispute on this project. GoodDay (talk) 15:02, 12 December 2015 (UTC)

Articles can be disputed too, so let's get rid of those. Seriously though, does this originate with the issue that categories don't need to be sourced to reliable sources? Maybe disputed categories could be required to be sourced, on the talk page and/or commented out in the article. Fences&Windows 15:33, 12 December 2015 (UTC)

I just feel that if categorizing was eliminated, then we wouldn't have concerns like these, brought up. GoodDay (talk) 15:39, 12 December 2015 (UTC)

Yes, the scope of categories can be ambiguous too. I feel that categories are useful for navigation and sorting, both for readers and editors, but there are weaknesses especially related to bios and any area affected by strong and conflicting agendas. Fences&Windows 16:26, 12 December 2015 (UTC)

Agreed. List articles give more information and nuance to article subjects than categories ever can. Categories are a huge waste of time. I personally don't bother with them anymore, and would not be sad to see them eliminated. GenQuest ^{"Talk to Me"} 15:50, 12 December 2015 (UTC)

• If you are seriously proposing this, a post here is not the way to go about it. This would be a major change and would require broad input in a formal WP:RFC, probably on it's own dedicated subpage is it would probably be a very widely attended discussion (or get shut down per WP:SNOW ina few hours). If you really want to do this, I would suggest you review my essay on the subject as I've done a number of major policy RFCs over the years. Beeblebrox (talk) 18:42, 12 December 2015 (UTC)

  I'll see how things go here, before going the Rfc route. If the idea is rejected here, then I won't push it any further. GoodDay (talk) 02:47, 13 December 2015 (UTC)

Oppose - categorization is frequently useful. The fact that many categories are disputed doesn't make them a bad idea. Categories help users find topics they're interested in, and they help associate articles on similar topics. If some category is too ambiguous to be useful, it can either be renamed/rescoped to a less ambiguous name, or it can be deleted - and in either case, it would be done at CFD. עוד מישהו Od Mishehu 19:43, 13 December 2015 (UTC)

• Oppose Categorizing is vital for navigation. Having said that, articles can be over-categorized: having dozens of categories on an article can be time consuming for those who need to add them, as well as a distraction from the wider content within articles. Rubbish computer (Merry Christmas!: ...And a Happy New Year!) 00:48, 14 December 2015 (UTC)
• Oppose - for now Static content categories need to be replaced with properties and dynamic list pages. I don't see this as imminent. All the best: Rich Farmbrough, 13:13, 16 December 2015 (UTC).
  
• Oppose Like 'List of xxx' pages, Categories are indexing - or possibly are thesaurus-like (not the same but nearish). Search looks for fairly close matches for a word/phrase. Lists and categories group things that may not be close in name, but have a relation in subject. Peridon (talk) 12:12, 17 December 2015 (UTC)
• Comment: In terms of information efficiency, the category system may benefit from a reduction in branch depth. Branches that are almost never used should be pruned back (merged upward). Praemonitus (talk) 18:52, 22 December 2015 (UTC)
• There are a few categories that are vital to the project's maintenance. A few that come to mind are Category:Candidates for speedy deletion, Category:Pending AfC submissions, Category:Proposed deletion. I'm assuming that this proposal, if it were to pass, would not affect these categories. Mz7 (talk) 18:00, 28 December 2015 (UTC)
• Strong oppose, because categories are an absolutely simple method of organising our articles. Yes, they're often used in a problematic way, but that's not a reason to throw out the baby with the bathwater. If there were a fundamental problem with the idea, the Library of Congress and lots of other information professionals wouldn't be using a similar system in libraries worldwide. Nyttend (talk) 22:13, 28 December 2015 (UTC)
• Oppose Don't throw the baby out with the bathwater. The problem I find is that people rarely use the category talk page to discuss which articles are appropriate for a category (and instead use the article talk page about its categories). Both should be used ideally but the category talk page would allow for a little better coordination and routine as to individual articles in a category. That's said I hate the whole people convicted of crimes category structure as a giant pointless mess but that's a minority opinion. -- Ricky81682 (talk) 08:55, 29 December 2015 (UTC)

  @Ricky81682: You said people rarely use the category talk page to discuss which articles are appropriate for a category and I agree. In my experience editors rarely discuss ANYTHING on cat-talk-pages. The problem is that the few who do are harshly "punished" by category-patrolling-ADMINs who are the only editors around. See for example

  • Category talk:American law by year
  • Category talk:Founders of companies of the United States. Ottawahitech (talk) 13:22, 3 January 2016 (UTC)please ping me

  • Those are discussions about the names of the category not about the categorizing. It could be done on each page with a mention on the cat talk pages. -- Ricky81682 (talk) 20:43, 3 January 2016 (UTC)

• Weak Oppose It is very frustrating there is still not a dynamic Wikipedia:Category intersection process in place to avoid much of the tangle of the category hierarchy. I don't really favor outright deletion, but a Noah's Flood to wash away the Biography categories so we can start fresh certainly seems attractive. RevelationDirect (talk) 01:15, 5 January 2016 (UTC)
• Oppose Categories made it so much easier for me to organize and add content. Categories is how I patrol content associated with the articles I create. I see no benefit to eliminating cats. Paleorthid (talk) 23:34, 10 January 2016 (UTC)
• Oppose - they are an important way of exploring the 5 million articles. Keyword search should never be the only option. --NaBUru38 (talk) 22:08, 12 January 2016 (UTC)
• Oppose various wikignome projects that I have worked on are far easier to proceed with by using categories rather than list articles. MarnetteD|Talk 01:13, 15 January 2016 (UTC)
• Oppose I think this is a case of 'I've never used it- can't see what the point is.' For ten years I never searched on one, then while training I was asked questions about an unfamiliar area and I dived into the tree. Still can't think of another approach for that situation. Clem Rutter (talk) 16:06, 19 January 2016 (UTC)
• Oppose and I hope no-one will try, in any serious way, to remove them. Proposals like this rely on knowledge by readers which they do not have - especially when accessing a wikipedia that is not in their own native tongue. S a g a C i t y (talk) 21:44, 20 January 2016 (UTC)
• Comment The example linked looks to me like a case where some people were discussing what the scope of a given category should be. I don't know if it should be a paradigm (no obvious consensus seems to have emerged), but it looks like things are working the way they're supposed to, more or less. Wabbott9 Tell me about it.... 20:05, 21 January 2016 (UTC)
• Oppose If you don't like categories then ignore them. But they can be very helpful for finding related articles.Rathfelder (talk) 12:33, 24 January 2016 (UTC)

Background

I know that this policy subject is a Perennial policy suggestion, however I feel like these editors (User:128.61.20.111 and User:153.107.193.208) are perfect examples of why users should not be able to delete their user talk pages. Both of these users had received numerous warnings for unconstructive edits within the last 3 days. If all of the notices were displayed on the user's talk page, they would have been blocked a lot sooner. Three warnings were left on on day for 128.61.20.111 [1] [2] [3]. After they were erased, it was as if the user was never warned. I understand it is the user's responsibility to check the user talk page log, but it is a tedious task that is rarely ever done by editors. One of of the warnings that was left was an Administrator (@Materialscientist: I'd like to get your opinion on this, as well.), who also left a level one warning template when the IP editor vandalized Wikipedia previously in the day. Being able to remove warning templates allows vandals to stay 'under the radar', so to speak. This editor was also given a wrong level warning[4] by User:Eat me, I'm an azuki, having previously vandalized numerous articles[5][6][7][8][9]. Had no-one checked, which editors tend not to do, this vandal could have sunk back into the shadows, both evading a necessary block, and an opportunity to vandalize Wikipedia continually. People that are clever could pick up on this quick, and abuse it until it is dealt with.

Thus is why I am suggesting

• a change in the policy concerning editing one's own talk page, and deletion of warning templates.
• Removal of warning templates (of any type) for the last month are prohibited from being removed (including User:ClueBot NG).

I'm not very good at suggesting these sort of things, and putting them together, so any suggestions would be very helpful. Cheers! :) Boomer Vial^Holla 09:15, 28 January 2016 (UTC)

Discussion

No vandal can stay under the radar if they are reported at WP:AIV. AIV is the radar. The person doing the reporting can mention that the user deletes warnings, but I don't think that's really necessary. Any admin handling AIV reports very likely knows enough to check the talk page history. If it's disruptive editing, not vandalism, the place is WP:ANI but the same applies there (and you're expected to provide diffs of the disruption there). In any case, how likely is it that a vandal is going to observe a Wikipedia policy about non-removal of warnings from their talk page? Are we going to create a new template for warnings about deleting warnings? ―Mandruss ☎ 09:24, 28 January 2016 (UTC)

I personally agree. It makes a lot clearer. Krett12 (talk) 09:30, 28 January 2016 (UTC)

I see what you mean, User:Mandruss, however, it just seems like an unnecessary step that can be prevented if users are prohibited from removing any sort of warning template from their talk page. The user that used as an example above honestly should've been blocked already considering the amount of warnings left on their talk page. The only reason it hasn't happened yet is because the editor removed all warning templates from their talk page. I was even fooled by this[10], leaving only a level 2 blanking warning. Cluebot NG was also fooled by this on a few occasions, leaving the same level warning template[11][12]. It just seems like a problem that could be easily rectified with a simple policy change. Boomer Vial^Holla 09:38, 28 January 2016 (UTC)

Was that user reported at AIV? If so, when and what was the result? ―Mandruss ☎ 09:39, 28 January 2016 (UTC)

I just reported him to AIV, and am currently awaiting a result. You also make a good point about who is going to watch to make sure that warning templates stay on user talk pages, and creating a new warning template. For the first point, I don't have an answer, but I'm hoping another editor that can think of a compromise will come out of the woodwork. As for the second point, we could always edit the misuse of warning templates template to include erasing of templates. Just a suggestion. I tend to give editors the benefit of the doubt, and start off with a level one warning, in the case where a level four warning was left, and it has rolled into a new month. Having all of the warning templates for the last month visible would make problem editors, and vandals a lot more obvious. Boomer Vial^Holla 09:43, 28 January 2016 (UTC)

I'm not going to remove the RfC template, but I'd suggest that you do so. This page gets enough attention from experienced editors, so this is not RfC-worthy. Good luck. ―Mandruss ☎ 09:47, 28 January 2016 (UTC)

Ok, I no problem. I removed it. Thanks. Boomer Vial^Holla 09:49, 28 January 2016 (UTC)

Btw your vandal has been blocked for 31 hours despite removing warnings, see how easy that is? If they come back and start again after the block expires, repeat. The next block should be longer than 31 hours, maybe 3 days or a week. And so on. ―Mandruss ☎ 09:51, 28 January 2016 (UTC)

Yes, I just checked it out before I noticed you posted this. Thanks for the heads-up, though. Also, I'm looking for other opinions, whether for, or against. So don't be afraid to chime in. :) Boomer Vial^Holla 09:55, 28 January 2016 (UTC)

It's not only the talk page history that the admins look at - they are interested in contributions and always looking for any talk page edits to see the user's response/justification. Previously, when removing warnings wasn't allowed, we had lots of users blocked for only removing warnings from their talk pages. Such a policy results in numerous completely lame edit wars, drives away otherwise productive editors, wastes admin time, and creates long term resentment. I would venture to say that beyond a recent warning, which always can be readily seen, admins are not that fussed about the number of warnings on a talk page. -- zzuuzz ^(talk) 21:02, 30 January 2016 (UTC)

I'm worried, mainly, about how long these cantankerous editors can fly under the radar until their contribution history until administrators find, and take care of them. - I don't understand how you could still have that concern after reading this thread, and in particular the first two sentences I wrote. If any vandal is "under the radar", it's because others are failing to report them. If no capable editor is aware of what the vandal is doing, no change to warnings will make any difference. ―Mandruss ☎ 04:50, 31 January 2016 (UTC)

The reason other editors are failing to report vandals is because they see no warnings on the vandals talk page, leave a level 1 warning, and move on their way. If the vandal is smart, they'll remove the warning, and make no edits for a few days before making another unconstructive edit. Their doing this is dependent on the fact that basically only Administrators check their contributions, and talk page edits. Maybe another solution to this is to make sure users are checking those two things by outlining them in WP:CUV. Boomer Vial^Holla 14:14, 31 January 2016 (UTC)

As a side topic, it's removing the "shared IP" templates that concerns me. They're easily missed and it's useful to know if an IP is from a school, etc. And not all Admins check for that. Doug Weller talk 17:27, 1 February 2016 (UTC)

• Really? This again? There is still no compelling reason to force users to maintain warnings for any length of time. The warning does not exist for the benefit of anyone except the user being warned. If they have read it, they have read it and don't need to keep it. If it is a shared or dynamic IP, and it wasn't intended for them, it doesn't need to be kept either. There is no conceivable reason why a user should be forced to wear a scarlet letter for any reason. --Jayron32 21:19, 1 February 2016 (UTC)

Really? This again? - I did find Wikipedia talk:Centralized discussion/Removing warnings in about five minutes via this page's archives. Things are rarely that easy to find in my experience, due to various factors such as the limitations of our search engine (Google it ain't) and the fact that a given issue can usually be in any of multiple venues (how many archives can one be expected to comb through before they start their thread?). ―Mandruss ☎ 12:47, 2 February 2016 (UTC)

WP:PEREN is good reading. Every item on there has been brought up literally dozens of times in multiple fora for a decade. The community has rarely budged on any of them. I know that not every newish user would have been involved in these discussions. I apologize for my exasperation; but this makes the rounds every few months. The answer has always been "no", for the reasons I outlined. --Jayron32 16:19, 4 February 2016 (UTC)

My question is, what good does this do? If a vandal doesn't heed the warning to cease vandalizing pages, why would we expect that they would respect the warning against removing the warning? And if they do quit it, I don't care if they remove the warning or not; at that point it's served its purpose. Seraphimblade ^{Talk to me} 20:00, 2 February 2016 (UTC)

Well, seeing as it's suggested so often, I withdraw this suggestion. Boomer Vial^Holla 15:47, 8 February 2016 (UTC)

I would like to talk about Wikipedia:Flow again because I can't accept the proposal is failed. In my opinion, I support users can enable the Flow beta function. I think WMF should change the policy on Flow. My suggestion is, the Flow beta can skipped community consensus and allow for users to enable in some days (in major language versions). If the feedback's result is OK, the Flow beta function can still exist. So I would like to restart to talk about Flow function. Please define your opinion, thank you.--Shwangtianyuan (talk) 04:02, 6 February 2016 (UTC)

You posted at WT:Flow a couple of days ago but might not have noticed the mood there: there are plenty of websites where people can chat, and Wikipedia need not provide another. The suggestion that people use one set of procedures for editing an article (the reason we're here), and a different set of procedures for discussing edits in articles is very peculiar. I can't see any advice at WP:SIG about political statements in signatures, but I don't think it's a good idea, however worthy the cause. Johnuniq (talk) 05:18, 6 February 2016 (UTC)

• @Shwangtianyuan:I certainly like the idea of Flow, but there are serious problems with the actual implementation, that I don't think will ever be resolved (even with full support from Wikimedia that it doesn't have anymore). Flow is not like Visual Editor - it's either on or off and an editor that doesn't like it will be forced to use it if you change your user talk page over (which is one of Flow's fatal flaws). The solution is to implement the one-page-per-topic structure of Flow on our current talk pages and then to create a talk page visual editor. That way, anyone can opt out simply by not using it. Oiyarbepsy (talk) 06:13, 6 February 2016 (UTC)
  • I would like to cite the Chinese aphorism: Lagging behind leaves one vulnerable to attacks (落后就要挨打). The English Wikipedia is the largest language version, so English Wikipedia should to enable Flow beta function, as same as Chinese version.--Shwangtianyuan Happy Chinese New Year to everyone 06:19, 6 February 2016 (UTC)
    • @Shizhao and AddisWang: What do you think?--Shwangtianyuan Happy Chinese New Year to everyone 06:22, 6 February 2016 (UTC)

There's a Draft Flow RfC if anyone wants to look it over or make suggestions. I'm tempted to just post it as a followup to this thread, but there's no rush and I think it may be better not to hit the WMF with multiple negative RFCs at the same time. From what I've seen Community Feedback on Flow has generally been very negative. I expect the consensus will be that we don't want Flow. Alsee (talk) 11:50, 6 February 2016 (UTC)

I would prefer to hold off a Flow RfC for the moment. I wouldn't object to an RfC being based on my text but in that case I would withdraw myself as a proposer. Let's see what happens with Gather. BethNaught (talk) 12:00, 6 February 2016 (UTC)

The RFC is ended.--Shwangtianyuan Happy Chinese New Year to everyone 07:39, 8 February 2016 (UTC)

It never started. I hatted the discussion section to prevent a premature beginning. That's why it was titled "draft". BethNaught (talk) 07:48, 8 February 2016 (UTC)

Comment If Flow beta function still unable in English Wikipedia, I would like to call WMF to change the policy. My suggestion is, the Flow beta can skipped community consensus and allow for users to enable in some days (in major language versions). If the feedback's result is OK, the Flow beta function can still exist. I think The WMF's policy on Flow is stupid. If I am the executive of the WMF, I already changed.--Shwangtianyuan Happy Chinese New Year to everyone 04:38, 9 February 2016 (UTC)

Hello! You are correct: the WMF's policy on Flow is stupid. Flow was a bad idea and they have stopped working on it. In its current state it is completely unusable. It will take a lot of work to repair the damage that Flow has caused. The Quixotic Potato (talk) 12:26, 9 February 2016 (UTC)

But I think Flow is a good idea. The problem's opinions are differ greatly on Flow for now. I think this is very good.--Shwangtianyuan Happy Chinese New Year to everyone 07:15, 10 February 2016 (UTC)

A majority dislikes Flow. The WMF is no longer trying to fix it, and Flow is currently a buggy mess. There are many phabricator tickets related to Flow, bugs that will never be fixed. What we need now are tools to convert Flow pages back to normal talk pages. I do not understand why the WMF has wasted so much time and money on Flow. The Quixotic Potato (talk) 14:06, 10 February 2016 (UTC)

The Wiki Education Foundation would like to run a Valentine's Day themed CentralNotice banner on February 12–14, geo-targeted to the United States and Canada, to feature Wiki Playlist, a tool that enables readers to share their favorite Wikipedia articles. Our organization is focused on improving Wikipedia's content, and we believe that Wikipedia's 15th anniversary is a great opportunity to raise the public's awareness of how much has already been achieved in this area. We see this new tool as a way of paying tribute to the longtime effort of Wikipedia contributors (including our program participants) who continuously increase content quality. We hope this social media campaign will also remind people that the world of Wikimedia is not all about drama, but about how we all enjoy improving articles, uploading images, and curating content. We'll be launching this tool in the context of the Year of Science, a targeted campaign to improve the quality of science-related content on the English Wikipedia.

You can see the beta version of the tool at http://playlist.wiki.

You might now be thinking, "Wait, is this Gather?" — let me assure you, it's not! In fact, my only knowledge of Gather until I came to this page to post this proposal and discovered the discussion and RfC was a vague recollection that WMF had created some article collection tool in their app that I had never used and thought had been disabled (clearly it hadn't!). In reading through the discussion earlier on this page, I see many people supportive of the idea of socially sharing a list of Wikipedia articles, which is good because that's what our tool does too! But Wiki Playlist has key differences that mean it should not affect the Wikipedia community in the same problematic ways of Gather. Specifically:

1. To dispel any WMF concerns starting off, Wiki Ed is an independent nonprofit organization — we aren't affiliated with the Wikimedia Foundation, and we're independently funded. We believe that Wikipedia's content should be at the core of what we're all focused on. That's why we run programs to bridge the gap between Wikipedia and academia in the US and Canada, and our ultimate goal is to improve Wikipedia's quality. We're building this tool as a way to highlight on social media some of the great content developed by Wikipedia volunteers, including our program participants. More than half of us on staff are content contributors to the projects outside of our jobs, and we all care deeply about the quality and integrity of Wikipedia.
2. Playlist.wiki makes no edits to Wikipedia. It is not integrated into MediaWiki. You don't even need a Wikimedia account to use it (although you can log in with your Wikimedia account to create a Playlist). This is a reader-focused, social media sharing tool only. Playlists are not saved on Wikipedia at all, and thus will not add a burden to the normal Wikipedia curatorial processes.
3. Playlists are not findable unless the creator shares them on social media, and then they're only findable if you click through from that person's social media post. The home page of playlist.wiki is a hand-curated list picked by Wiki Ed staff; otherwise the only way to find others' playlists is by looking for them on social media sites. This significantly reduces the reach and visibility of problematic Playlists, although we do have a Wiki Ed staff person who will review any Playlist flagged to us as inappropriate or otherwise in violation of our terms of service.
4. We provide credit and license links for the images displayed on playlist.wiki.

While the tool is reader-focused, editors are obviously readers, too, so I encourage you to create a Playlist and see what you think. Do let me know (either here on on my talk page) if you have any questions about the Wiki Playlist tool.

To get back to what I'm actually proposing: Wiki Ed developed the Wiki Playlist in context of our Year of Science campaign this year, and we're working on getting high-profile scientists and science institutions in the U.S. and Canada to create and share Playlists of scientific articles (see, for example, Lawrence M. Krauss's Playlist), but we'd also like the general public to share articles. Since we're launching the Wiki Playlist next week, I thought a Valentine's Day banner of "What Wikipedia articles do you love?," with a prompt to create a Playlist to share on social media, could bring some positive attention to Wikipedia's content. We'd like to target the banner to English Wikipedia in the US and Canada, and only from February 12 to 14 to capitalize on the love theme. I see this as a low-visibility banner — show it no more than 5 times, and to only a certain percentage of users. My understanding from reading through the CentralNotice guidelines on Meta is I should bring it up here, so: I would like to propose this Valentine's Day themed banner run for 3 days on English Wikipedia geo-targeted to the US and Canada, promoting readers to create Playlists of their favorite Wikipedia articles. --LiAnna (Wiki Ed) (talk) 19:24, 7 February 2016 (UTC)

hmm technical note you want Sitenotice not CentralNotice for something on a single wiki. Also you are asking for a banner ad on one of the highest traffic websites going. How much server capacity do you have?

Copyright wise you are going to need something that automatically detects and strips out fair use images.

Yes or no on the banner? Not sure its not something we've really considered before.©Geni (talk) 08:55, 8 February 2016 (UTC)

We're set up to handle plenty of traffic with this; we've have some auto-scaling infrastructure in place for it. The potential for this to go viral is something designed for.--Sage (Wiki Ed) (talk) 17:30, 8 February 2016 (UTC)

About the fair use images — unlike Gather, Playlists aren't on Wikipedia, so they're not subject to WP:NFCC. They're displayed on Wiki Ed's website, which is subject to U.S. copyright law, and displayed under fair use.

About Sitenotice — my understanding is Sitenotice can't be geotargeted, so I had to use CentralNotice for that, but if I've misread something, I'm fine asking for a Sitenotice instead. --LiAnna (Wiki Ed) (talk) 18:37, 8 February 2016 (UTC)

Wow, this does indeed look like Gather done right. Some questions/thoughts:

1. The fair-use issue, of course. All the images I saw came directly from Commons instead of en.wp, so this may already have been solved.
2. Valentine's Day is also celebrated in many European countries and even further abroad (Valentine's Day#Celebration and status worldwide), so why restrict this to North America?

Otherwise, I see little reason not to support this initiative. —Ruud 12:18, 8 February 2016 (UTC)

Just responded to the fair use question above. About the geography, Wiki Ed operates only in the U.S. and Canada, which is why that was my geographic request, but if community members in other locations would like to use the tool too, I'm happy to expand the reach. --LiAnna (Wiki Ed) (talk) 18:40, 8 February 2016 (UTC)

I think that if we are going to actively promote such a tool on en.wp, then it should still comply with WP:NFCC, regardless of where it's hosted. —Ruud 10:40, 9 February 2016 (UTC)

Can someone confirm if I have this right?

• The WMF created Wiki Education Foundation.
• The WMF gave it grant money.
• And The WMF paid for the creation of essentially the same Gather/Playlist software, TWICE?

Alsee (talk) 12:40, 8 February 2016 (UTC)

Hi Alsee, you're correct on the first one — we spun off from the Wikimedia Foundation to an independent nonprofit in 2013. We had a small starter grant from WMF to get us going, but once we got external funding, we returned the rest of the unspent money from our starter grant, so we haven't used WMF money since March 2014. The funding for this particular tool was a grant we received from the Simons Foundation in support of the Year of Science. --LiAnna (Wiki Ed) (talk) 18:47, 8 February 2016 (UTC)

• Oppose. The CentralNotice is extremely overused. Having a giant banner over the entire site for three days just to promote this tool is not worth it. Also, the proposed time overlaps with the banner for the Steward elections. --Yair rand (talk) 12:55, 8 February 2016 (UTC)
• The highest-impact promotion for this tool would probably be to import all the public Gather lists and notify each user of the move. As long as the code is made free software, we can treat this tool like any other. Nemo 18:27, 8 February 2016 (UTC)
• Oppose I don't think we routinely promote projects/extensions etc in this manner. While I have a limited degree of sympathy with a desire to do so, conflating it with Valentine's Day is plain old dumbing down. There doesn't seem to be any logical connection between 14 February and the purpose of the notification, however it is done. What next? Promo banners for St St Patrick's Day or any other saint to which some form of whimsicality is attached? We are an encyclopaedia, not an arm of Hallmark Cards. - Sitush (talk) 19:04, 8 February 2016 (UTC)

• Oppose Bad idea and bad execution. I do not understand how creating a Playlist of 3-5 Wikipedia articles and sharing it on social media leads to our goal: "a world in which every single person on the planet is given free access to the sum of all human knowledge". I hate CentralNotice and SiteNotice banners, banners in general & Valentine's day too. The proposal doesn't take into account that it would annoy loads of people and result in only a tiny amount of traffic. Only a tiny percentage of the people who would get spammed would be interested in using something like that. The money and developer time could've been spent on creating something useful for the community, like fixing phabricator tickets, but instead it was wasted on what seems to be a vanity project. My browser has had the ability to bookmark pages since day one. Normally people create things to fix a problem. This playlist (bad name) doesn't fix any problems and it isn't an improvement over other ways to share a list of wikiarticles. It isn't even an improvement over a list of URLs, because there are many browserplugins that allow you to quickly load and save such lists. "Build it and they will come" no longer works on the internet. You actually got to offer people something useful, otherwise they will leave your website in seconds. Unfortunately I am unable to see the statistics but I am certain that more than 90% of the visitors of that page do NOT click on the awkwardly placed Create a Playlist-button. If you look at succesful websites you will notice that they spend a lot of time and money optimizing their calls to action. Banners to advertise your service are useless if you do not offer anything of value to the visitor. Prediction: a huge amount of people will be spammed, a small percentage of those will click, a handful will actually create a list, and only a couple of people will be return visitors. Don't take my word for it, go ask your local expert, this is how the internet works. The Quixotic Potato (talk) 12:35, 9 February 2016 (UTC)

• Oppose. While the website is Gather done correctly, we don't do these kinds of promotions per Sitush. I would suggest getting in touch with the Reading Team to migrate the existing collections over and work with them and us to find more appropriate ways of integrating this. MER-C 13:25, 9 February 2016 (UTC)

  We have run such banners before (e.g. for Wiki Loves Monuments and after the launch of Wikivoyage), but this arguably makes more sense in the context of a larger publicity initialize. (And this proposal seems to have a deadline that is way too close to get proper consensus...) —Ruud 14:16, 9 February 2016 (UTC)

• Looks pretty cool, althoug how to have the site notice reflect the third party data collection may require some thought. On first hit, the following are accessed by a browser: CloudFlare, Amazon, Google, New Relic, Twitter, and Facebook. On first playlist click, wikiedu.org's stats server is also hit. The Wiki Education privacy policy seems to have a differently defined scope. Incidentally, the Wiki Education privacy policy, served through an IP hosted by Athenix, gets some JS and uses a tracking pixel on wp.com subdomains.
• This looks nice (I especially like that, unlike Gather, this tool attributes images, so it can be used to help advertise Free Content). I think we could help advertise this, but I feel the sitenotice (which should be used sparingly) is a too prominent place for this. We should not advertise any non-WMF issues there. Linking to it on suitable pages should be fine, though. —Kusma (t·c) 18:01, 9 February 2016 (UTC)
• Oppose sitenotice I reviewed sitenotice history and looks like we haven't done anything like that in the last decade. The few times external sites were put on sitenotice more than a decade ago it looks like consensus was that it should not have happened. In this case it would raise particular confusion, making the 3rd-party Playlists look like part of Wikipedia. Alsee (talk) 20:32, 9 February 2016 (UTC)

• Oppose per The Quixotic Potato. Boomer Vial^Holla 04:03, 10 February 2016 (UTC)
• Oppose This would essentially be a free ad for a non-WMF website. That's not a road we should go down. Beeblebrox (talk) 20:12, 10 February 2016 (UTC)
• Pile-on oppose. Hosting non-WMF related ads is a route we shouldn't even consider going down. If we're going to start hosting ads like this on the grounds that the product somehow relates to the use of Wikipedia, why shouldn't Wikiwand (for instance), or even Wikipediocracy, get the same opportunities? As others have commented, I also fail to see how this relates to Valentine's Day in any way. ‑ Iridescent 20:24, 10 February 2016 (UTC)

As the proposer, I’ll withdraw the proposal — it’s not worth continuing to draw volunteer attention away from other higher priority items for something that’s clearly heading toward consensus to oppose. Thanks everyone for your consideration and for the feedback on the tool itself — it’s much appreciated. --LiAnna (Wiki Ed) (talk) 23:35, 10 February 2016 (UTC)

A few months ago, the Arbitration Committee has decided that some pages subject to intractable disputes, like Gamergate controversy, be forbidden from being edited by users who don't have 30 days of registration and 500 edits. To enforce this, an edit filter was created to disallow edits on some of these pages: Special:AbuseFilter/698, or when not covered by it, these edits can be reverted by other users. Although this system might somewhat reduce the disruption in those areas, it has some significant drawbacks:

1. Using the edit filter affects performance and is user-unfriendly since the edit button still appears^[1]
2. Users who don't strictly meet the criteria but who, based on their history, are expected to contribute positively in these areas cannot

   Sometimes even the page creator can no longer edit it^[2]

3. Sockpuppets of banned users use this as a justification for reverting^[3]
4. Users who are known, based on their history, to contribute negatively to these areas cannot be prevented from editing them, short of blocking

To resolve these issues, it is proposed to create a usergroup that is autopromoted after 30 days and 500 edits, and a new protection level, so that only users in the new usergroup can edit pages subject to this new protection level. In addition:

1. Users who don't (yet) meet the autopromotion criteria can be manually promoted by admins when based on their history, they are expected to contribute positively to these areas and no evidence of sockpuppetry exists
2. Users who meet the autopromotion criteria and were therefore automatically added to the usergroup may be manually removed as an arbitration enforcement action
3. Pages may be protected by admins with the new level only when a decision of the arbitration committee mandates it (note that standard discretionary sanctions do not include it)

Although this was inspired by ArbCom, this is strictly a community proposal and community consensus is required for these configuration changes. Moreover, the community has repeatedly showed interest in such a system, see for example this recent meta Wishlist Survey. Should it get consensus, I believe that the ArbCom will agree that this system is better than the current one and incorporate it in its rulings. Cenarium (talk) 00:19, 10 January 2016 (UTC)

Also, we can give the userright to edit these pages to bots and sysops, and prevent them from being given automatically the new group which would then be redundant (using APCOND_INGROUPS). We'll have to find a name for the usergroup, and the protection level (maybe 'restricted' ?). For example of configs with autopromoted groups, search $wmgAutopromoteOnceonEdit in InitialiseSettings.php. Cenarium (talk) 10:55, 10 January 2016 (UTC)

Sysops obviously would qualify (aside from a few exceptions), but as many bots wouldn't, we shouldn't manually include them in the group: it would be a big waste of time. Instead, just add it to their rights packages. The bot access level includes such rights as bot, noratelimit, etc., so if someone creates a new 30-500 userright (or whatever it's called), such a right could easily be added to the bot access level. Nyttend (talk) 00:38, 11 January 2016 (UTC)

That's what I meant by 'giving' the userright to them: adding it to their userright package. Cenarium (talk) 06:17, 12 January 2016 (UTC)

• For the record, the ArbCom decision in question is WP:ARBPIA3#500/30. Mz7 (talk) 02:51, 11 January 2016 (UTC)

Support - as to bots, I think that any bot without enough edits/time to qualify will be added on request by the operator should there be any potential need for the bot to edit these pages; this would probably be relatively few bots. עוד מישהו Od Mishehu 18:42, 11 January 2016 (UTC)

• Support again. Point of clarification: does "a decision of the arbitration committee mandates it" cover the recent decision in ARBPIA linked above? Ivanvector 🍁 (talk) 19:42, 11 January 2016 (UTC)
  • Protecting an article in the area of dispute would be valid arbitration enforcement. Cenarium (talk) 06:17, 12 January 2016 (UTC)
• Support superior to the edit filter solution. But I would not support making more and more groups as it would just get confusing. Graeme Bartlett (talk) 22:38, 11 January 2016 (UTC)
• Support seems like it would be an improvement over the current system. Happy Squirrel (talk) 22:51, 11 January 2016 (UTC)
• Support - As long as the only pages to receive the 30-500 protection are explicitly specified by ArbCom, this seems superior to the current edit filters. I do not presently support automatically adding this usergroup, perhaps called autotrusted, to the bot usergroup, though I do support adding it to sysop. I would also support a way to add the usergroup upon request in a similar fashion as WP:RFP/C. — Jkudlick ^tc_s 02:06, 12 January 2016 (UTC)
• Questions - Just curious, should this proposal (which appears to be proposing a form of protection/edit restriction which is higher than semi-protection but lower than full protection) be accepted and implemented, how will its implementation be done? For example: could articles be put under this for long-term periods or indefinitely, similar to semi-protection of articles, or is such an action going to be discouraged, similar to full protection? Can such requests be made at RFPP, or can they only be done via decisions (i.e. ArbCom decisions)? Narutolovehinata5 ^tccsdnew 05:12, 12 January 2016 (UTC)
  • This can only be done as arbitration enforcement (which has its own requests page), so it must be supported by an ArbCom decision specifically authorizing the "30-500" restriction. Standard discretionary sanctions are not enough, since they only authorize semi, full or move protection. These are likely to be long term or indefinite, as disputes that reach ArbCom are some of the most persistent. Cenarium (talk) 06:17, 12 January 2016 (UTC)
    • Sure, TODAY, but it would not be impossible to adjust the protection policy to allow another step between SPP and FP; nor would it be unheard of to deploy in exceptional situations via WP:IAR, just as PC2 is rarely used. — xaosflux ^Talk 01:45, 16 January 2016 (UTC)
• Support. Basically, the idea of having a protection level between semi-protection and full protection is needed to deter sock puppetry, amongst other issues related to new auto confirmed accounts. That, and since pending changes level 2 was not a community-accepted option, this is the next best thing. Steel1943 (talk) 06:57, 12 January 2016 (UTC)
• Support – Sounds like that would work a lot better than using the edit filter. Graham (talk) 07:35, 12 January 2016 (UTC)
• Oppose per WP:CREEP. 500 edits seems to be a poor measure of anything and seems trivial to game. So, such use of edit count as a measure should not be encouraged. There seem to be plenty of technical tools already for managing problem pages. Andrew D. (talk) 08:42, 12 January 2016 (UTC)
• Oppose as the autopromote feature currently appears to be broken, from the last attempt to implement a similar request to this. Mdann52 (talk) 09:38, 12 January 2016 (UTC)

  The autopromote feature is not broken, autoconfirmed works just fine right here on enwiki. Autopromoteonce works just as good on plenty of wikis, e.g. on dewiki. phab:T46587 is a configuration issue, the conditions are way too restrictive. A user was autopromoted on 14 August 2014. Cenarium (talk) 01:02, 15 January 2016 (UTC)

• Oppose Rather than create a new user group patterning after an edit filter created on an ad hoc basis, let's implement PC2! There is consensus for PC2 to exist but not how to implement. I think this situation is what PC2 envisions. Chris Troutman (talk) 12:10, 12 January 2016 (UTC)
  • Given that the I-P and GG topic areas are populated mainly by entrenched people who have a strong COI on the subject that edit such pages relatively rapidly (which contraindicates PC1, let alone PC2) how the hell would PC2 help? —Jeremy v^_^v ^Bori! 20:40, 12 January 2016 (UTC)
    • @Jéské Couriano: It doesn't and neither does this proposal. That so many "entrenched people" can't be constrained without ARBCOM intervention is a good thing. This proposal (and my preference for PC2) is meant to limit the sockpuppets and straphangers that coalesce around these discussions. Chris Troutman (talk) 13:22, 16 January 2016 (UTC)
• Support because "Using the edit filter affects performance and is user-unfriendly since the edit button still appears", assuming it is technically possible to do this given the Phabricator link posted by Mdann52 that I am unable to understand. — Bilorv_(talk)^(c)(e) 16:19, 12 January 2016 (UTC)
  • @Bilorv: This was the last attempt to use the auto-promote feature, and no users were autopromoted by it, seemingly because it was broken nowadays as opposed to misconfiguration. Mdann52 (talk) 12:48, 14 January 2016 (UTC
    • @Mdann52: thanks for the explanation. I had assumed that the autoconfirmed group invoked the same code that this new 30/500 group would, and as far as I knew, autoconfirmed still works fine. Is autoconfirmed handled by something different, or is it functional because it was configured before the problem with autopromotion began, or is there some other key difference? — Bilorv_(talk)^(c)(e) 16:29, 14 January 2016 (UTC)
      • @Bilorv: I believe this is hard-coded into the software using different code - mw:Manual:Autoconfirmed users seems to suggest this too. Mdann52 (talk) 16:55, 14 January 2016 (UTC)
        • Thanks for the reply. I've struck my support based on this. — Bilorv_(talk)^(c)(e) 18:51, 14 January 2016 (UTC)
          • @Mdann52: Both Autopromote (used by autoconfirmed) and Autopromoteonce (what we'll use) use the function recCheckCondition of the Autopromote class. The same checks would be done. @Bilorv: The phabricator task linked by Mdann52 is a configuration issue (see more details above), the underlying core Autopromoteonce mechanism works perfectly. Cenarium (talk) 01:02, 15 January 2016 (UTC)
            • I've unstruck my support. — Bilorv_(talk)^(c)(e) 12:24, 16 January 2016 (UTC)
• Oppose I want something else first. When a page is protected to prevent autoconfirmed users from editing, they ought to still get instant encouragement to do something. Right now, page protection leads people to a splash page for reading, but not action. The action that is recommended is clicking a button that brings users to a page where they can read about edit requests. This still is not an action. From there, the user is supposed to copy the "edit request" template, go back to the article they want to edit, click "talk", scroll to the bottom, then make their post. This is a burdensome chain of requirements. Instead, if someone is blocked they should get an option to make a suggestion with just one additional click. Until and unless we have better infrastructure for seeking contributions from those who do not pass protection, I do not want more people blocked. It is a Wikipedia ideal that everyone can edit, and I want some kind of allowance made to encourage more useful contributions. I would rather subject people to lots of reverts and rollbacks rather than prohibit them outright from doing anything. That said - if it were easier for people to post suggestions on the talk page, then I would support this proposal. It is a reasonable proposal for a new kind of page protection based around a new userright. Blue Rasberry (talk) 20:15, 12 January 2016 (UTC)
• Support All of the opposes seem to be saying that we shouldn't protect pages in this way, but we already are via the edit filter. This just improves the existing process. Jackmcbarn (talk) 20:45, 12 January 2016 (UTC)
• Support the idea, with the obvious caveat as to whether this is technically possible. Questions as to whether this kind of protection is a good idea aren't relevant to the question of whether we should do this, as that decision has been made by other processes. Hut 8.5 22:54, 12 January 2016 (UTC)
• Support as a big improvement to the existing process. APerson (talk!) 02:32, 13 January 2016 (UTC)
• Support The 500/30 restriction has already been applied to WP:ARBGG and WP:ARBPIA topics and it has very successful at reducing disruption. One problem is that editors are authorized to engage in silly edit wars and can repeatedly revert edits which don't satisfy 500/30. It would be much better for the software to be enhanced to avoid that turmoil, and to avoid klunky edit filters. Johnuniq (talk) 04:56, 13 January 2016 (UTC)
• Comment, this seems like it might be better done by upping the rules for autoconfirmed. What requires it to be separate? Adam Cuerden ^(talk) 14:09, 14 January 2016 (UTC)

  500/30 is only approved for very limited use in areas of extreme and persistent disruption. Simply upping the bar for autoconfirmed would require expanding 500/30 to the entire project. That hasn't been suggested, but considering how difficult it was to gain consensus to use 500/30 even in the most toxic areas, I doubt the community is ready for such a discussion. Ivanvector 🍁 (talk) 19:29, 14 January 2016 (UTC)

• Support provided that this is technically possible and on condition that the new protection level only be used for arbitration enforcement. BethNaught (talk) 16:32, 14 January 2016 (UTC)

  Qualified support: per Mike V, admins should not be able to add users to this group manually as they would still be banned from 30/500 protected articles by the ArbCom ruling. BethNaught (talk) 20:46, 15 January 2016 (UTC)

  Certainly we could request amendments on those ArbCom cases to change the topic bans exclude this entire group, regardless of how the membership was gained. — xaosflux ^Talk 01:25, 16 January 2016 (UTC)

  Yes, we should make such a request if it passes. Cenarium (talk) 09:26, 16 January 2016 (UTC)

• Support I wholeheartedly agree. If we are to go this route, a new user group is naturally the best approach. Edit filters can work without much concern of performance (see 747, 748 and ((pp-30-500))), but the edit button still being visible is quite editor-unfriendly. The filters are still available as a temporary implementation, should we wish to consider that (full disclosure, I helped implement them :) — MusikAnimal ^talk 18:03, 14 January 2016 (UTC)
• Support a straightforward way to deal with this problem. Good idea--Tom (LT) (talk) 08:53, 15 January 2016 (UTC)
• Oppose on one point. I disagree with admins being able to promote a user based upon their own discretion. You either meet the restrictions imposed by the arbitration committee or you don't. The community isn't able to make exceptions to this rule. Mike V • Talk 20:37, 15 January 2016 (UTC)

One possible scenario I see for this is a very clearly declared and WP:SOCK#LEGIT alternative account of an established user, the number of edits of which happens to fall short of the requirements. Mz7 (alt) (talk) 01:21, 16 January 2016 (UTC)

What's being proposed is broader than that, though. Users who don't (yet) meet the autopromotion criteria can be manually promoted by admins when based on their history, they are expected to contribute positively to these areas and no evidence of sockpuppetry exists. As it's written, it allows admins to grant this right to whomever on the basis that they're "good contributors". The criteria of being a good contributor is subjective amongst admins. I don't feel comfortable with this part in place. As for alternate accounts, is it necessary? From my experience, not very many users use alternate accounts and this would only apply to a subset of editors who edit restricted pages and whose alternate accounts don't meet the requirements. Even then, is the editing so crucial that it can't wait until they return from their travels, get home from work, leave the library, etc. and just edit from their main account? Mike V • Talk 19:55, 16 January 2016 (UTC)

• ArbCom recently clarified that authorized editors could redo edits by unauthorized editors, taking ownership of them, see Wikipedia:Arbitration/Requests/Clarification and Amendment#Palestine-Israel articles_3_.283.29: Arbitrator views and discussion. So Arbcom is sensible to the fact that some good editors are prevented from editing by this ruling. Based on this and other comments, I believe ArbCom would have no objection to amend their rulings to also allow edits by manually promoted users (subject to the policy I stated in my original post). Cenarium (talk) 09:26, 16 January 2016 (UTC)

I still think we need the committee as a whole to make an amendment to their findings before we allow administrator discretion. If they do choose to amend it, it would be worth asking if it's easier to just revert the problematic edits of those who don't meet the requirements rather than having to green-light the users deemed responsible. Mike V • Talk 19:55, 16 January 2016 (UTC)

• Oppose I understand the motivations behind this proposal, but I cannot support adding to Wikipedia's policy creep. I have a feeling that the easier it becomes to restrict users from editing an article, the more this restriction will be used (and misused) to "break the back of a dispute". If this proposal passes, which looks very likely, I urge the community to draft a lucid and strict policy regarding this tool. 500/30 should only be used as a last resort, but without strong guidelines policing its use, I predict it will inevitably become part of the standard dispute resolution toolkit. Altamel (talk) 23:41, 15 January 2016 (UTC)
  • The proposal is nothing to do with changing policy, and is not creep. The proposal concerns the method that should be used to implement procedures that are already in place for WP:ARBGG and WP:ARBPIA topics. Currently, it's a free-for-all with the rather silly situation that an edit that contravenes the 500/30 restriction can be reverted without limit. This proposal is suggesting that more sophisticated technical procedures should be implemented to reduce uncertainty and edit warring, and to provide more efficiency than an edit filter. Johnuniq (talk) 02:40, 17 January 2016 (UTC)
• Support This is something we need for fair enforcement. If arb com wants to use this sanction they will do so. If they do, this is the only effective fair way of enforcing this. (as a personal guess, Arb com would not decide whether or not to use it again, until a suitable case came up. Nor do I know what we would do about manual promotions until someone should ask--I personally would support them) DGG ( talk ) 19:33, 16 January 2016 (UTC)
• Qualified support. I'm not sure if I see the need for an arbitrary 30/500 level, but given that this is something ArbCom has decided it wants to do anyways, better to implement it properly than use an edit filter. -- King of ♥ ♦ ♣ ♠ 20:24, 16 January 2016 (UTC)
• Support – will make Arbcom enforcement much easier, and nothing else is likely to come of this new usergroup. --IJBall (contribs • talk) 23:47, 17 January 2016 (UTC)
• Support with the understanding that this would strictly be a means to more easily and fairly enforce relevant arbitration decisions, and not a new form of protection that any administrator could enact on any page. However, per Mike V, allowing administrators to discretionarily promote any account that doesn't meet the requirements would run contrary to the ArbCom's decision. However, I can still see a use for manually promoting accounts that are declared, legitimate alternative accounts of established users who do meet the requirements. Mz7 (alt) (talk) 01:01, 18 January 2016 (UTC)
• Support with the condition that the protection level may only be added to page as the result of community consensus or by the Arbitration Committee as it has been to the Arab-Israeli conflict (it should not be able to be added by an admin on their own cognisance whether AE or not). Callanecc (talk • contribs • logs) 07:45, 18 January 2016 (UTC)
• Support an edit protection level 'between' semi and full, e.g. where only editors can edit with a 'given' right can edit (including a sensible new right that allows then for that). At the same, I would advocate that we have the possibility to remove the 'autoconfirmed' from editors who have shown that they can not be trusted .. yet. It is fine that it is used for Arbitration sanctions, but I would also support it if it would be used outside of that restriction. --Dirk Beetstra ^{T C} 09:24, 18 January 2016 (UTC)
• Support - the more automated the better and per Callanecc above,  Roger Davies ^talk 10:12, 18 January 2016 (UTC)
• Qualified support - I strongly oppose a new protection level, and support this proposal only as a more user-friendly way than the edit filter to implement ArbCom's decisions. Accordingly, it must be made immensely clear that this protection level can only be imposed by ArbCom decision. A2soup (talk) 02:36, 19 January 2016 (UTC)
• Support — it's simply the right technical answer in this instance, regardless of one's opinion on whether a 30-500 "tier" is ideal. I had actually started looking into dealing with implementing some edit filters related to the 30/500 ARBPIA sanction last month (when I had more time) and came to the conclusion that while it was possible to do without a new usergroup, it would be a kludge that would have required either explicitly listing all pages covered by a topic (e.g., the gamergate filter) or dealing with magic templates/categories that can only be added or removed by admins. Neither are the right technical answer, because we shouldn't be bending over backwards when there's already a clear, simple answer built into the software. Of course, from a policy standpoint, it's probably a good idea, as Callanecc and others mention, to restrict its use to an otherwise-case-by-case-consensus basis (and, as is obviously the case with ARBPIA, existing ARB directive). --slakr^\ talk / 07:53, 20 January 2016 (UTC)

  ...however in contrast to Callanecc, I feel that it actually should be up to an admin to add it on their own cognisance so long as it's within those specific topic areas (or otherwise has clear consensus) and it's not done in bulk (i.e., it should be in response to an issue that's arisen on a page). I mainly say this because when one inevitably pops up on WP:AN3 that's ideally solvable with this form of protection, I'm almost certainly not going to jump through the hoops of extra consensus-building and request-filing; either I can quickly add protection, log the remedy, and move on to the next report, or I'm simply going to keep scrolling and/or use something less effective and let someone else deal with it if they really want. :P Granted, this is just me talking, but I have a feeling that the sentiment will be similarly shared by other admins strapped for time who otherwise avoid ARB venues like the plague. --slakr^\ talk / 08:17, 20 January 2016 (UTC)

• Comment As far as I know, any potential edit by anyone (including IPs) can always be taken to the talk page before being made to the article. Without this proposal, it would be simple enough for an editor who could not edit an article directly under this provision to just go to the talk page, say, "I'm not at the "30-500" level yet but I found this interesting, encyclopedic, neutral, and well-sourced fact about this page. Can someone else add it in?" followed by the proposed edit. Typos, grammar issues, and the like can be done the same way. The talk pages of protected articles have lots of this stuff. The main thing would be making it clear when someone is stopped from editing it what is happening, but something parallel to one of the current protection schemes should work. This isn't so much "support" as Not Opposed. Wabbott9 Tell me about it.... 20:15, 21 January 2016 (UTC)
• Support creating a new userright and assigning it to a new usergroup (plus sysop and bot if needed) and a new protection level corresponding to the new userright to enforce a 30-500 editing restriction. It is far better than using the non-editor-friendly edit filter to enforce this. $wgAutopromoteOnce should be used to add users to this new group. sysop should be given the technical ability to promote and demote users from this group. Policy should require that admins only promote legitimate alternative accounts of users already in this group to this group. (A user's editing history should not be used as justification for promotion when the user does not meet the requirements.) In addition, since use of the new protection level must be mandated by ArbCom, only ArbCom decision and WP:AE should result in demotion from this group. For those that are demoted, there should be a defined method of being promoted again. — JJMC89 (T·C) 02:52, 25 January 2016 (UTC)
• Conditional support if as mentioned by others "that the protection level may only be added to a page as the result of community consensus or by the Arbitration Committee". Also would be nice to have an "suggest button" that brings people to the talk page with an explanation on how they can suggest changes as mentioned by BlueRasberry. Doc James (talk · contribs · email) 16:25, 25 January 2016 (UTC)
• Oppose for now. The thresholds being used for these restrictions are essentially arbitrary, and we don't have a strong evidence base yet that they are well-chosen. Implementing this as an edit filter is a kludge, but it has the advantage of being obviously so; it's a desperate measure taken as a limited-deployment experiment. Doing this at the software level artificially ossifies these choices before we've actually finished and evaluated the experiment. In any future userright implementation, I'm not too fussed about admins adding the right to legit alts and such, but I would strongly prefer that the right cannot be removed by individual admins - unbundling has already resulted in the routine wiki-activities of many users becoming much more exposed than it used to be to the vicissitudes of "admin discretion", and this would be way too much of a drama magnet. Opabinia regalis (talk) 23:37, 25 January 2016 (UTC)
• Support but prefer PC2. Stifle (talk) 16:51, 26 January 2016 (UTC)
• Support this and PC2 for areas with lots of minor disruption. 96.237.20.21 (talk) 20:52, 3 February 2016 (UTC)
• Oppose it is the right technical answer, but a bad precedent and it doesn't solve much of anything. See the verse on my user page for an explanation of my concerns. I think this will put us yet further on the path to shrinking the number of editors as this "you must be this tall to edit" set of restrictions creeps outward over the years. Hobit (talk) 03:19, 5 February 2016 (UTC)
• Support from a technical perspective; if we're going to do this, this is obviously the right way to do it. I think that some of the concerns people have raised above about potentially using this sort of restriction too frequently are well-founded, but we are using it in several places already, and it seems silly to do it in a confusing, technically-inefficient way. This discussion isn't really the place to focus on whether or not using the 30-500 restriction itself is a good thing. --Aquillion (talk) 05:43, 5 February 2016 (UTC)

I beg to differ. This discussion is exactly the place to discuss it: A technical solution to implement the 30-500 restriction will encourage ArbCom to impose it in other cases as well, ignoring the long-term adverse effects. New users being forced to edit topics they aren't interested in will abandon the project, unless they are strongly motivated (POV pushers in other words). It's the opposite of WP:AGF.

If we want to provide technical solutions to implement ArbCom restrictions, let's first discuss which kind of restrictions we want ArbCom to impose. I would support a system where admins can impose bans of fixed duration for specific topic areas. Let ArbCom decide the topic areas available, and allow admins wide discretion in its use (one questionable edit by a new user for example). Not sure if it is technically possible to implement, it would require a usergroup for each topic area, storing a list of banned users with the topic area and the end date of the ban, and running an agent to change the group membership when the date is reached. Prevalence (talk) 03:52, 9 February 2016 (UTC)

• Reluctant support because I can't vote to enable PC2 instead. If people want to limit it to Arbcom or community sanctions, that's fine. It would perhaps quiet the fears of some editors that it would be overused. NinjaRobotPirate (talk) 20:45, 8 February 2016 (UTC)
• Support I'll give-in to a little instruction creep to fight the more frequent editing disruptions anyday. GenQuest ^{"Talk to Me"} 20:58, 8 February 2016 (UTC)