Wikipedia:Village pump (proposals)/Archive 129

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

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

Allow admins to rename users?

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.

---

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)

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.

idea to improve wikipedia

dear wikipedia organisation,

as a regular user of your webpage I have a suggetsion to add to the articles.

I, and im sure many other reader as well, would be thankful if there was a automatic readers voice that could read the article to the user.

>this would help ppl who want to learn the language (I myself regularly use wikipeda to practise languages im not fluent in by reading the articles in both the foreighn and my native language) and are struggling with pronouncing certain words. >it would help blind or old people who cant read (well) >it would help ppl with a low concentration capacity to not always get lost in the articles and get distracted.

i hope you take my suggestion into concideration and i hope ii send this to the right department. I simply couldnt find another place to submit it — Preceding unsigned comment added by 178.189.196.12 (talk • contribs) 11:06, 30 December 2015‎ (UTC)

This already exists for a few articles, such as Minecraft (though that's not the best example as it's outdated). It's not possible to provide it for all articles, as Wikipedia is edited by volunteers in their spare time. Text-to-speech software could be used, but that's not always reliable, and Wikipedia doesn't need to provide that, as most operating systems already do. nyuszika7h (talk) 11:47, 30 December 2015 (UTC)

Conservapedia

I have just become aware of the existence of this site - so of course I went to the wikipedia article on Conservapedia - excellent. I am surprised though that wikipedia are not more proactive in destroying this gross misrepresentation of wikipedia - open knowledge. To ignore Conservapedia is to ignore creeping detestablity - 1933 et al. Just as we are proactive in ridding wikipedia of sockpuppets, vandals and such, I believe we should be equally proactive in identifying and isolating such perversions as conservapedia. Perhaps we could demand a right of reply on their site. Mark^Dask 01:15, 29 December 2015 (UTC)

Plenty of people and organizations complain about Wikipedia. I can think of many that are far more consequential than Conservapedia. Most people don't even know it exists, so I think the best response is to maintain scrupulous neutrality in our article about it and otherwise ignore it. Seraphimblade ^{Talk to me} 01:32, 29 December 2015 (UTC)

Plus there's already an entire wiki dedicated to refuting Conservaedia: RationalWiki. NinjaRobotPirate (talk) 01:37, 29 December 2015 (UTC)

To respond to Conservapedia gives them more credit than it deserves. -- Ricky81682 (talk) 08:43, 29 December 2015 (UTC)

Conservapedia is one of thousands of independent wikis and millions of websites. They are not a "misrepresentation of wikipedia", and to "demand a right of reply on their site" is not how the Internet works,. We sure as hell aren't letting Conservapedia get a right to include their point of view in our articles. Free speech means you have to accept speech from people you disagree with. As far as I know, they aren't doing anything illegal. Anyway, our Alexa rank is 7 and theirs is 95,147. You should probably be more concerned about Fox News or whatever popular information sources you disagree with. PrimeHunter (talk) 03:09, 31 December 2015 (UTC)

Wikipedia:Main Page (2015 redesign)

Hi. We need more heads here. Things are getting pretty quiet... Rehman 01:11, 2 January 2016 (UTC)

Allow some double redirects redux

More than a year ago, a consensus on allowing some double redirects was established, but the corresponding MediaWiki feature has not been enabled, because it still has a bug. Shouldn't we try to increase the bug's priority? Petr Matas 13:48, 2 January 2016 (UTC)

I don't think it's a matter of changing priorities as much as providing a Gerrit patch to have the code changed, as well as to get the questions raised addressed.Jo-Jo Eumerus (talk, contributions) 14:02, 2 January 2016 (UTC)

To editor Jo-Jo Eumerus: Just for clarification: Do you mean that I have to provide the patch? And which questions are you referring to? Petr Matas 14:38, 2 January 2016 (UTC)

No, you don't have to provide a patch yourself, but it makes things go faster if there is one.Jo-Jo Eumerus (talk, contributions) 14:40, 2 January 2016 (UTC)

Allow registered users to be globally blocked

Tracked in Phabricator
Task T17294

Registered users should be allowed to be globally blocked, not just IP addresses. GeoffreyT2000 (talk) 15:16, 4 January 2016 (UTC)

Globally meaning across all projects? That is something that would have to be proposed at Meta. We couldn't do that here. Resolute 15:17, 4 January 2016 (UTC)

There is global locking, though, which can be asked for here. Global blocking of accounts has been a long term wishlist items with a Phabricator ticket.Jo-Jo Eumerus (talk, contributions) 15:51, 4 January 2016 (UTC)

Addendum: Locked accounts cannot login to Wikimedia and are served with an error message MediaWiki:Centralauth-login-error-locked instead.Jo-Jo Eumerus (talk, contributions) 19:33, 4 January 2016 (UTC)

A rule to help reducing arbitrary lists relating to fiction

Currently there are odd arbitrary lists out there regarding fiction such as List of fictional rodents, List of fictional location types, List of fictional ungulates. Although WP:LISTCRUFT is an essay, i do believe it has the potential of becoming a policy.

I propose we make a rule that any arbitrary list regarding media, fictional elements, or anything similar to that needs to be accompanied by a full-length article covering the notability of the subject. For example: There is currently a List of fictional Jews and the new rule would demand a Portrayal of Jews in fiction article, in order to support the notability of it. And the stand-alone article would need to be strongly supported. Of course this makes these lists that much less arbitrary. Lucia Black (talk) 15:38, 2 January 2016 (UTC)

This subject is already covered by WP:LISTN. Having one article support the notability of another does not appear to be an improvement upon the GNG criteria. Praemonitus (talk) 14:35, 4 January 2016 (UTC)

Unfortunately, not many follow this. And i'm covering arbitrary lists. There's lists about almost everything now. the internet has been subject of arbitrary lists, but that doesn't mean that all lists are 'notable'. Having an article to support the notability actually does strengthen the GNG because it means we'll have less non-notable arbitrary lists, while other lists that are notable will be strengthen and not challenged. Lucia Black (talk) 11:20, 7 January 2016 (UTC)

Bot-creating a bunch of redirects: two separate proposals

If you have opinions on both proposals, please comment separately on each one. Nyttend (talk) 23:05, 30 December 2015 (UTC)

One specific situation

I left a request at WP:BOTR for a bot to create a large group of redirects: after obtaining a complete list of pages with Dungeons & Dragons in the title, I removed items that had a corresponding Dungeons and Dragons redirect, and I then requested that a bot create and redirects to all the remaining & titles. The full list (including several items manually created since I made the request) is below:

Hasteur responded with what I inferred to be a willingness to help, but he refused to do anything without a community discussion first, because people are wont to make complaints at bot operators for unilaterally fulfilling even simple requests like this. Of course I understand Hasteur's situation as a bot operator and don't want him to get complaints, but seeing no good reason to need consensus from the community to perform this action, I hereby request community consensus for Hasteur to be able to tell such people to go suck an egg, because this is a simple enough situation that the community doesn't need to grant permission. Final note — all this is separate from WP:BRFA; of course I understand that the bot approval process is necessary, and I'm not trying to get around that. Nyttend (talk) 23:05, 30 December 2015 (UTC)

• Make the redirects. These are good ones. Tag the, as {{R from mod}}, which indicates that it's a minor punctuation difference or some other minor difference. Oiyarbepsy (talk) 04:18, 31 December 2015 (UTC)
• Support. I agree with the changes, but keeping in mind several previous editors who went through creating many redirects in such a way that it was precieved as bot created/bulk creation, I wanted to hear a positive consensus to do this. Hasteur (talk) 13:37, 31 December 2015 (UTC)
• Support, because <sarcasm>I'm sure no one will take "go suck an egg" to be a personal attack.</sarcasm> No, really, I agree with your proposal, there should be no need to get consensus twice to use a bot to create a bunch of non-controversial redirects like this. ~ ONUnicorn^{(Talk|Contribs)}problem solving 17:08, 31 December 2015 (UTC)

General issue

This is the second time I've come to VP/Pr to request consensus for bot-creating a bunch of simple redirects; the first was Wikipedia:Village pump (proposals)/Archive 91#Create a lot of unpunctuated redirects, requested because Legoktm feared getting a pile of complaints from the same people who would be complaining at Hasteur. The proposal passed easily, with several people saying "this is such a simple situation that we didn't need to come to VP/Pr".

With that in mind, the proposal: a bot operator need not establish community consensus before filing a WP:BRFA to create a batch of unprintworthy redirects of any type. Of course, if someone leaves objections at BRFA, community consensus would need to be obtained before the BRFA is approved, but because the creation of unprintworthy redirects (e.g. redirects from modifications, which includes the & and and proposal above) is generally an obvious housekeeping matter, we need not go through the bureaucracy of filing a discussion for situations like this one. Nyttend (talk) 23:05, 30 December 2015 (UTC)

• Support I endorse this generic category, however suggest that this proposal be advertised to groups outside the regular VP/Pr community (specificly WP:BOTN/WP:AN) to help establish a broad consensus for this so that the proposal has more strength if and when someone complains about the creations. BRFA is such a dusty corner of wikipedia that it is more likely than not that the request will have already been through creation/discussion/approval before someone who is affected by this complains and screams "WP:FAIT violation" to get sanctions applied. I'm exceedingly gun shy about items that have the potential of being controversial because of previous interactions/complaints from vexatious disputants. Hasteur (talk) 13:46, 31 December 2015 (UTC)
• Support as long as the non-printworthy reason is an established housekeeping reason, such as above mentioned "&" -> "and". If in doubt, discuss. I would reword it though to say that the bot operator doesn't need to seek additional consensus for BRFA. "need not establish community consensus" sounds as if there isn't consensus for the redirects at all. —  HELLKNOWZ  ▎TALK 14:46, 31 December 2015 (UTC)
• Support per above. nyuszika7h (talk) 15:34, 31 December 2015 (UTC)
• Support Per everyone else. ~ ONUnicorn^{(Talk|Contribs)}problem solving 17:09, 31 December 2015 (UTC)
• Explanatory note If everyone exactly agreed with me, the following situation would be explicitly permitted: you're a bot operator, and suddenly you observe a group of articles that largely lack a group of related-title redirects (in this situation, and instead of &), so you just write up a bot to create these redirects, submit the bot to BRFA, and (assuming it's approved) your bot goes ahead and creates them. Consider the rules for WP:AWB — a potentially controversial set of changes needs to get community consensus from some sort of discussion, but with simple fixes, there's no need to have a discussion, so (to pick the first example from Special:Recentchanges) nobody's going to complain at WereSpielChequers for fixing spelling without getting approval first, because it's a simple fix, and nobody disagrees with ordinary spellchecking. In the same way, when it's practical to use a bot to perform ordinary housekeeping, you shouldn't need approval before going through BRFA. Nyttend (talk) 03:05, 2 January 2016 (UTC)
• Support as a sensible idea and per above. APerson (talk!) 17:00, 7 January 2016 (UTC)

Tweak autoconfirmed threshold

The current autoconfirmed threshold for most users is 10 edits and a 4-day-old account.

This allows trolls to create a bunch of accounts and not use them until they need them, then make 10 back-to-back edits right before they use them for abusive purposes.

I propose that this be changed so you must have 4 edits, each of which is at least 24 hours after the last "edit that counted."

This would force trolls to actually edit with their sleeper accounts on at least 3 different days before they could use them, making it easier to spot a sock-puppet-master's sockpuppets in an investigation and make it easier to find sleepers that have only edited enough to be autoconfirmed but which haven't been "put to use" yet by the troll.

By making it harder on the trolls, fewer articles would need to be fully-protected as semi-protection would be good enough.

Comments? davidwr/(talk)/(contribs) 21:19, 2 January 2016 (UTC)

• Don't like it, as using more spp also discourages anonymous good faith editors. However, looks like a new class of editor "500edits and 30days" (e.g. {{ARBPIA}}, Gamergate) is being created by the arbitration committee - if this is really acceptable just call it editor and start rolling out a new editor-protected set of pages. Then accounts could be autopromoted twice. — xaosflux ^Talk 16:58, 3 January 2016 (UTC)

  Truthfully, I'm opposed to this as well - but if it is going to happen anyway it should be clear. — xaosflux ^Talk 16:58, 3 January 2016 (UTC)

  The proposal is not about making unprotected articles semi-protected (is this what you meant by spp?), but about making fully-protected articles semi-protected, so it has no influence on anonymous editors. Anyway, I don't like double autopromotion either. Petr Matas 17:35, 3 January 2016 (UTC)

  Full protection is not meant to protect against things spp is (such as vandalism) - if you want to qualify editors, make it clear - but making more protected pages that are harder to edit is not the goal of the project. — xaosflux ^Talk 18:12, 3 January 2016 (UTC)

  The primary goal of the proposal is to eliminate sock puppetry (which sometimes leads to pages being fully-protected). The possibility to lower (not raise) the protection level of some pages is just a (welcome) side effect. Petr Matas 21:50, 3 January 2016 (UTC)

• Sounds reasonable to me, I think it is a question of the security gained being worth the developers' work. I would just reword the criterion to "you must have 4 unreverted main-space edits separated by 24 hours from each other." (In both cases, the autopromotion will occur immediately after the fourth edit, i.e. before anyone being able to revert it, but that is not a problem.) Petr Matas 17:35, 3 January 2016 (UTC)
  • Maybe a good idea, technically impossible with the current MediaWiki setup - this would require and extension or edit filter. The former is a lot of work for little gain - the latter there is no consensus to use, and would be very very expensive and unsustainable. Mdann52 (talk) 19:07, 3 January 2016 (UTC)
• Against, less because it's unworkable and because this is further restriction for no gain. The best sockpuppets are those who act like legitimate users before doing their damage; this would make it easier to do so. —Jeremy v^_^v ^Bori! 03:01, 4 January 2016 (UTC)
• In principal, a good idea, but technically challenging. The Mediawiki software doesn't actually have a user group called autoconfirmed; instead, it checks with every edit if the user has the 10 edits and 4 days. Making the criteria more complex would likely slow down the editing process too much. As a result, the software would need to be rewritten to use an entirely different concept for granting the autoconfirmed right. Probably by adding a user to the confirmed group when they hit that magic edit, so it only has to check for the user right and not the actual criteria. Oiyarbepsy (talk) 03:45, 4 January 2016 (UTC)
• While it is certainly possible for trolls/vandals/griefers/harrassers to create multiple accounts, age them, and abuse in the in the manner described, how often is this actually an issue? In my experience, the number of banned editors who create, use, and manage large "sock drawers" is pretty small.

Further, how well does this solve the (somewhat ill-defined) problem? Again speaking from my experience, it strikes me that the most pernicious block/ban evaders will just move their most obnoxious behavior to pages not under full- or semi-protection.

Finally, it's not actually necessary for an individual to make any edits for a checkuser to identify multiple accounts created by the same individual (subject to the usual magic-pixie-dust caveats of checkuser). Short- to medium-term sleeper accounts which have stayed clear of trouble areas are no easier to detect under the proposed scheme.

In other words, absent a much more evidence-driven case – which also addresses and balances the negative effects on legitimate, good-faith new users – I am not persuaded this would be a useful or beneficial development. TenOfAllTrades(talk) 04:21, 4 January 2016 (UTC)

• While I understand and appreciate the intention here, I don't think it will have the desired effect. This would stop impatient schoolboy vandals, who are mostly stopped by the current low threshold. If the target is disruptive trolls and WP:LTA headcases, it won't stop them. I've dealt with these folks a lot. They are more than obsessive enough to jump through the hoops and game a requirement like this. Given that it could discourage good-faith new users without having the desired deterrent effect I just can't support it. Beeblebrox (talk) 21:17, 4 January 2016 (UTC)
• Will it discourage the trolls? Or otherwise will it discourage good faith newcomers? It seems, at a first glance, like the metaphor "putting one policeman officer stood on all corners". E. Feld ^talk 01:53, 8 January 2016 (UTC)

Oppose with the proposal of 24 hour gap as it would stop new good faith editors.

Auto confirmed

Any registered user can create pages which is right, as they contribute to this project, but I think only auto-confirmed users must be allowed to create stub articles (unsourced). When a new user creates unsourced auto-biographies as: "Hi, I am Ravi" and "Mohan Kumar is a 12 year old student from Patna" :: an automated filter will stop the creation of such stub articles, if the account is not auto-confirmed. As "unsourced stub articles" can have notability, only autoconfirmed users can create stub articles.

Let's knock out pages with 4+ disambiguation links today.

As of the moment, we are down to only 95 articles containing four or more disambiguation links. If nineteen Wikipedians would grab five of these each, we could knock this list out in minutes. Cheers! bd2412 T 19:53, 7 January 2016 (UTC)

In theory we could, but not in practice. I've had some fun fixing several links (it's a handy tool), but many of the DABs require either an expert or perhaps even the original author to understand what was meant. And, in many cases, there is no appropriate article to link to (yet) so the fix would require extensive writing. Still, every bit helps, I guess. I wasn't aware of that page and I thank you for the pointer. If I'm reading the list correctly, we're now at 42, but many of those have also been fixed up (but not refreshed on the list yet). Matt Deres (talk) 13:44, 9 January 2016 (UTC)

In practice, if the community as a whole focused on it for a few minutes, all of those questions could be resolved. With respect to articles not yet existing, it is perfectly appropriate to change a disambiguation link into a red link pointing to the title that should be occupied. Doing so informs others who see the page that this article needs writing. Cheers! bd2412 T 03:02, 10 January 2016 (UTC)

Commons categories and Wikidata

There have been battles between proponents and opponents of Wikidata on whether we should use directly their data in the template. One strong objections, which I do not necessarily agree with, is that requirements for reliable sources in Wikidata is currently weaker than our requirements, and many data are unsourced. Without really wishing to discuss this, I would like to note that there are some things which do not need to be sourced (in the sense of WP:RS) since they come from our projects. One example is {{commonscat}} where we do not require sourcing by any means. If the template is there, anybody can check whether the category is available on Commons and whether it corresponds to the content of the article. Note that {{commonscat}}, if left without a parameter, shows the Commons category which is reads from Wikidata. ({{commonscat-inline}} apparently does not, it shows the category derived from the name of the article, but I hope it should be easy to fix).

As the first step to the adoption of Wikidata, I propose the following:

A. That we recognize that it is advantageous to read the information about the Commons category on Wikidata rather than to keep it locally - meaning removing the category name parameter from {{commonscat}} (in the situation Wikidata has the info) would not be considered as disruptive and can be, in principle, carried out by bot on a large scale. (I do not intend to do it myself).

B. If we agree on A, there are two ways to visualize the information (note that they are not mutually exclusive):

B1. To continue doing what we are already doing, i.e. using {{commonscat}}, {{commonscat-inline}}, and having the dedicated field in some specialized templates (for example, it is included in {{Infobox Russian district}}, see Rzhevsky District for an example of an application).

B2. To keep the link to the category on Commons on the left panel, similarly to how it is used in Wikivoyage and some other Wikipedias, see voy:Fontainebleau for an example).

PS. I am not aware of any previous discussions of this topic; I will appreciate links if appropriate. PPS. I in principle intend to advertise this as RfC, however, I would like to wait for a day for comments before adding the template - possibly the issue has been discussed already, or some good ideas will be forthcoming.--Ymblanter (talk) 11:51, 4 January 2016 (UTC)

• Quite a lot of discussion on Template talk:Commons category. I wasn't aware of the inline version or I would have made the same changes there. I thought that User:Avicennasis was going to help transfer this data over but that didn't get off the ground. I agree with A but don't really understand the implications of B1 or B2. Cheers — Martin (MSGJ · talk) 11:59, 4 January 2016 (UTC)
• I like A with B2 B1, but as our dependence on Wikidata increases, editors will need an efficient way to watch the data which are relevant to them: Currently, if you enable Wikidata in the Wikipedia watchlist, it will be cluttered with label/description/alias/sitelink/multilanguage_string edits for languages irrelevant to the editor. These should be filtered away to show only the languages that the editor is interested in. Petr Matas 12:18, 4 January 2016 (UTC)

  Changed opinion per Keith D: Multiple commonscats linked from one article would make the left panel too complicated. Petr Matas 12:46, 11 January 2016 (UTC)

• I am busy at work until Friday afternoon, but still remember about the issue.--Ymblanter (talk) 21:56, 6 January 2016 (UTC)

  Read the discussions at the talk page now, and I think we should indeed start an RfC. Will do it now.--Ymblanter (talk) 11:38, 10 January 2016 (UTC)

  Left a notification at Template talk:Commons category; not sure whom else would it be good to notify.--Ymblanter (talk) 11:49, 10 January 2016 (UTC)

General comments

• Numerous articles have more than one link to Commons using different targets so removing the information from the article should not be done globally. Several categories on Commons do not exactly map to articles here and so the wikidata entry does not map to the article or to Commons correctly. Keith D (talk) 15:07, 10 January 2016 (UTC)

  Keith D, do you think it is ok to remove this info when it is unambiguous (only one commons category around, which completely matches)?--Ymblanter (talk) 16:07, 10 January 2016 (UTC)

  Personally I would not remove any from here as a general move and leave it to individual article maintainers to decide what should be done. After looking at the differences for a couple of years my confidence in the wikidata is very low and needs to be looked at closely before it can be used with any sort of confidence. Keith D (talk) 19:55, 10 January 2016 (UTC)

Non-confirmed editors can still create Wikipedia talk:Articles for creation subpages?

This proposal has been withdrawn by its proposer. Steel1943 (talk) 16:25, 11 January 2016 (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.

---

Now that the "Draft:" namespace has been implemented in full over the course of the past couple of years, there seems to no longer be a reason why non-confirmed editors should be able to create Wikipedia talk:Articles for creation subpages. This was the "namespace" previously designated for non-confirmed editors to create drafts, but that has since been replaced by the "Draft:" namespace. However, I just found out that non-confirmed editors can still create subpages of "Wikipedia talk:Articles for creation/" as shown here. I believe that the ability for non-confirmed editors to create the aforementioned subpages should be disabled. In fact, at this point, the only major reason why the aforementioned subpages should be created is if s draft needs to be recovered via the WP:REFUND process, and even then the page is moved to the "Draft:" namespace afterwards anyways. Steel1943 (talk) 15:42, 11 January 2016 (UTC)

(Pinging some draft and refund regulars I can think of for possible input: Anne Delong, DGG, Tokyogirl79, Graeme Bartlett. Steel1943 (talk) 15:46, 11 January 2016 (UTC))

Talk pages anywhere can be created by anyone. If someone recently created a subpage of WT:AFC, it might be because some old project page still references WT:AFC and should be updated. You may add a warning about WT:AFC being deprecated in the group editnotice, at Template:Editnotices/Group/Wikipedia talk:Articles_for_creation. Forcefully preventing their creation using an edit filter seems overkill at this point. Cenarium (talk) 16:20, 11 January 2016 (UTC)

• @Cenarium: Yup, I forgot that talk pages can be created by anyone. I'm going to close this. Steel1943 (talk) 16:24, 11 January 2016 (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.

Sortable Wikipedia history page

Tracked in Phabricator
Task T122779

The versions of an article on the history page should be sortable by the amount of text in each version.108.84.28.198 (talk) 05:46, 1 January 2016 (UTC)

• That's actually a brilliant idea. The use of this option isn't obvious to me, but the use for this kind of thing is never obvious at first, and later becomes essential. Oiyarbepsy (talk) 07:03, 1 January 2016 (UTC)
• I strongly agree — being able to sort the history, whether by page revision size or by some other criterion, would be quite helpful. Imagine that several different criteria were sortable: you'd be able to sort it by editor to get all the edits on the page that you'd made (particularly useful when you're viewing 500 revisions, when it's not quick to find all the appearances of your name), or you could sort it alphabetically by edit summary (presumably this would sort by section name first, hugely useful for organizing all the edits to a certain section, as well as tracking when a section name got changed), or perhaps even by the amount of text added or subtracted in each version, so you could see which edits caused the biggest changes. We'll need a Phabricator request to accomplish this, and I definitely hope that we get enough support here to make such a request appear worthwhile to the developers. Nyttend (talk) 03:11, 2 January 2016 (UTC)
• If we are going to add sorting, I would also appreciate sorting on editor contribution (number of edits, not bytes). I support this idea. --MASEM (t) 03:23, 2 January 2016 (UTC)

• Not quite sure what you mean. A button that, when clicked, causes all the edits by the most frequent editor to appear at the top, then all the edits by the second-most-frequent editor, etc.? A mere alphabetical order/numerical order sort, if applied to multiple columns, would have the same effect of congregating each editor's edits together, allowing you to observe quite rapidly who was the most active editor of the page. Nyttend (talk) 06:27, 2 January 2016 (UTC)

• This request is basically phab:T120732 i.e. "make history pages better". --Izno (talk) 22:21, 2 January 2016 (UTC)

  That proposal doesn't specifically state that article revisions should be sorted.2602:306:C541:CC60:F49E:5952:739F:1AF6 (talk) 22:36, 2 January 2016 (UTC)

• No it's not. I opened one at phab:T122779. Oiyarbepsy (talk) 03:42, 4 January 2016 (UTC)
• Support being able to choose from as many criteria as possible. Petr Matas 12:57, 11 January 2016 (UTC)
• I'd also like article sorting in search, categories and "what links here". By first edit, last edit, article size, name, etc. --NaBUru38 (talk) 22:10, 12 January 2016 (UTC)

Extra rights for Administrators in English Wikipedia

Many school kids/non-notable people upload selfies in commons and come here to create their auto-biography. The page is deleted but in most cases the picture remains in commons. Administrators can have the right to delete the picture uploaded in Wikimedia commons, even if they are not administrator in commons. --223.176.11.199 (talk) 09:23, 9 January 2016 (UTC)

This proposal is impossible as Commons is not within our jurisdiction. Everyone is however free to submit a deletion request at Commons, where selfies by random people are generally out of scope. BethNaught (talk) 09:28, 9 January 2016 (UTC)

Is there any new picture patrol in commons? They are not efficient like en wiki.

For additional information on patrolling at Commons you may want to view commons:Commons:Patrol — xaosflux ^Talk 17:20, 9 January 2016 (UTC)

While it does seem the specifics of the proposal are unworkable, the idea behind it seems sound. Maybe there's a way to address that in some language to be added somewhere? For example, maybe some boilerplate text added to {{db-person}} or to {{afd2}} for articles that have been designated under cat=B? Something like:

If prior to deletion the article contained a photograph that was uploaded to the Commons by the creator (e.g., a "selfie"), consider nominating it for deletion there as "outside of project scope".--Fuhghettaboutit (talk) 17:42, 9 January 2016 (UTC)

Commons users check new files but it isn't possible to mark them patrolled like new pages. It will change very soon: probably next week it'll be possible to patrol files on Commons and at enwiki (both new files and reuploads). It will be possible to show only unpatrolled files at special:newfiles, enabling a more efficient patrolling. See gerrit:251795. Cenarium (talk) 22:26, 9 January 2016 (UTC)

It might also be possible to create a noticeboard, here, where problematic files from commons can be listed. Editors who are interested could then take the next step and make the nomination there. That said, it would take a dedicated community to keep the page from becoming so backlogged that nobody wants to tackle it. Also, while a "selfie" may be outside of scope on commons, the uploader may be able to justify its inclusion there on some other grounds (e.g. "This image demonstrates traditional clothing and hairstyle of people living in such-and-such") which, if argued correctly, could be an educational justification for the image, and may keep the image in-scope for commons. Etamni | ✉ | ✓  22:55, 12 January 2016 (UTC)

multiple watchlists or watchlist categories or filter watchlist by wiki-category

3 ways of slicing the same problem : I want to be able to view subsets of my watchlist by topic areas. Either having multiple lists, or being able to apply tags to items in the list, or being able to select a category, and view only items that are in that category (including subcats!) would be a most excellent addition. Gaijin42 (talk) 19:46, 11 January 2016 (UTC)

• I believe the only solution currently available is to create a page (in your userspace) with links to the relevant pages; then use the "Related changes" link at the side. עוד מישהו Od Mishehu 22:00, 11 January 2016 (UTC)
  • It would be very useful to have watchlists of subcategories. --NaBUru38 (talk) 22:14, 12 January 2016 (UTC)
  • Agreed - Being able to access or filter through watchlist categories and subcategories would be beneficial and save users time. Meatsgains (talk) 02:35, 13 January 2016 (UTC)
  • Javascript could be used to generate or conveniently modify the pseudo-watchlist pages in userspace. The problem is that watchlists should be secret, but userspace pages are not, so I believe that the tags are the way to take. Petr Matas 06:55, 13 January 2016 (UTC)

    The first step: In your pseudo-watchlist, you can specify pages by Page ID, which does not change when the page is moved: [[{{Pageid to title|8786}}]] → David Bowie. Petr Matas 06:55, 13 January 2016 (UTC)

    Alas! Related changes show all revisions, not only the most recent one. Petr Matas 07:04, 13 January 2016 (UTC)

• Another possible workaround: You can view and edit your watchlist as a raw text. You can "switch" watchlists by saving your current watchlist to a text file in your computer and replacing it by contents of a different text file from your computer. Petr Matas 23:12, 14 January 2016 (UTC)
• IIRC, User:UncleDouggie/smart watchlist.js could do some of this. It hasn't been maintained, so I don't know if it still works, though. --Yair rand (talk) 23:27, 14 January 2016 (UTC)

Talk header for TimedText talk namespace

On Wikipedia talk:Non-free content#Next Steps, it has been proposed to make a talk header template for the TimedText talk namespace to deal with the following issues:

1. The namespace TimedText is generally poorly documented in its purpose, and because of technical restrictions documentation can only be put on TimedText talk pages.
2. Some of the TimedText namespace content is non-free content but there is no marking at all about this, or any practice to put Non-free use rationales or such things. Again, any such markings can only be put on the TimedText talk namespace. Discussion on whether having non-free TimedText is desirable or legal is currently happening on the abovelinked talk page.
3. TimedText pages can easily become orphaned if the corresponding filepage is deleted/moved; there is no warning to deleting administrators or filemovers that there is a TimedText page.

Thus, I've developed a draft template to provide for this template, but I'd like input on the template scope and functionality from the broader community. Thanks!Jo-Jo Eumerus (talk, contributions) 15:14, 9 January 2016 (UTC)

A different solution with long deployment time (/doc subpages)

Just in case you haven't, consider using the /doc or talk:.../doc subpage, like the Module namespace does, see Module:Automarkup for an example. Petr Matas 21:53, 9 January 2016 (UTC) Already done.Jo-Jo Eumerus (talk, contributions) 22:04, 9 January 2016 (UTC) That's a documentation to your template, but I meant a different thing: Like in the TimedText namespace, it is not possible to transclude anything to be displayed at Module:Automarkup from the module source code. Yet you see the documentation from Module:Automarkup/doc displayed at the Module:Automarkup page. It must be something in the configuration of the namespace that shows the documentation from the /doc subpage there. Petr Matas 22:20, 9 January 2016 (UTC) Yes, there is a function that transcludes /doc subpages in the Module namespace, but I know of no such thing working in TemplateTalk.Jo-Jo Eumerus (talk, contributions) 22:33, 9 January 2016 (UTC) Why Template talk? I thought the best would be if the doc was displayed at the TimedText page. Petr Matas 22:47, 9 January 2016 (UTC) Sorry, wrong word. I wanted to say "TimedText talk".Jo-Jo Eumerus (talk, contributions) 23:03, 9 January 2016 (UTC) Ok, but still, why "talk"? Why not see the doc directly at the TimedText page above or below the subtitle source code? Look, I can transclude TimedText:Like I'm Gonna Lose You.ogg.en.srt/doc here: TimedText:Like I'm Gonna Lose You.ogg.en.srt/doc Petr Matas 00:01, 10 January 2016 (UTC) Because, as far as I know, you cannot transclude stuff on TimedText pages without breaking them.Jo-Jo Eumerus (talk, contributions) 00:09, 10 January 2016 (UTC) If you mean adding {{/doc}} to the subtitle text, then you are right, that cannot work (and neither it does for Modules). The transclusion has to be done by the namespace handler. It's a bit complicated, but I think it's doable, see WP:VPT#How does Module doc work? Just consider it as an option. Petr Matas 04:27, 10 January 2016 (UTC) Doesn't seem like it will work barring a tech change. In the meantime, the function I assembled in the template will have to serve.Jo-Jo Eumerus (talk, contributions) 20:05, 10 January 2016 (UTC) I agree. Petr Matas 22:26, 10 January 2016 (UTC)

It's possible to add warnings about an associated TimedText when moving or deleting files. As for adding a doc to TimedText, it would indeed require code changes, but there doesn't seem to be a phabricator request for this. We should probably open one as this would alleviate copyright concerns. As for using the talk pages in the mean time, it seems appropriate and commons already does that. Cenarium (talk) 10:23, 11 January 2016 (UTC)

I've added warnings at MediaWiki:Confirmdeletetext and MediaWiki:Movepagetext. Also, it looks like phabricator is down for now. Cenarium (talk) 13:54, 11 January 2016 (UTC)

Phab works on my end. Your warning on the Movepage and Deletepage MediaWiki pages won't catch all TimedText pages, though - not all TimedText pages have the same language, TimedText:After_School_-_Shampoo_sample.ogg.de.srt for example is German. Can't speak of whether that is appropriate, though.Jo-Jo Eumerus (talk, contributions) 14:01, 11 January 2016 (UTC)

It works for me too now, so I've made a bug requesting a doc page for TimedText: phab:T123232. As for the warnings, I've transcluded Special:Prefixindex of TimedText:PAGENAME, so all languages will appear now. Cenarium (talk) 15:00, 11 January 2016 (UTC)

So, anyone else support using this template as a talk page template for the namespace?Jo-Jo Eumerus (talk, contributions) 14:03, 15 January 2016 (UTC)

Proposed change to Wikipedia: asking a question, receiving an answer

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

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.

Known Issues

Thsi proposal is very vague, to the point of being opaque, and the user who advanced it is now blocked. No prejudice against re-submitting a more coherent proposal along these lines in the future. Beeblebrox (talk) 18:03, 15 January 2016 (UTC)

I propose a new section for Village Pump called "Known Issues" where people report anything (non technical) that anyone feels needs attention to but doesn't know how to solve it. The most common issue will be placed above in a new box (similar to FAQs) in the idea lab. The purpose of this is so that editors could help focus on the right areas of improving Wikipedia by thinking of ideas that people feel need to be addressed. Lucia Black (talk) 00:00, 14 January 2016 (UTC) Example issue? ―Mandruss ☎ 00:08, 14 January 2016 (UTC) this may seem minor, but if put the example of what I believe is an issue, is having dead or not so strong wikiproject to key articles people visit often. I've been attempting to work on WP:Comics but not gaining any traction due to less than supportive (but clearly existent) community. But I don't know how I can fix it. And I don't think I can come up with a good idea. But this is too specific. It can fall under a category. There could be plenty of issues people have but don't know how to fix it. Since there isn't a place to highlight issues, we can't really follow up with them. Lucia Black (talk) 00:21, 14 January 2016 (UTC) There is no shortage of help resources at Wikipedia, for all kinds of problems and questions. We have WP:Teahouse, WP:Help desk, WP:Village pump (policy), WP:Village pump (technical), WP:Village pump (miscellaneous), a talk page for every template, numerous WP:Noticeboards, and probably more that don't come to mind at the moment. If you're not sure where to go with a problem or question, you can get direction at the Teahouse or Help desk; they will either answer your question or point you in the right direction. I don't see a need for yet another help resource, sorry. ―Mandruss ☎ 00:48, 14 January 2016 (UTC) The idea isn't exactly a "help resource" but a place to make issues "known" in order for that help to get reached more effectively. There's a reason why i suggested a new section for Village Pump. Although it is closer to a noticeboard, this is a place to cover broad, general issues that encompass "all" of wikipedia. I only mentioned that one specific example, but that was to show a bigger more critical issue that involves the entire Wikipedia space. Just like WP:Village/Proposal and WP:Village/idea aren't for small single-wikiprojects, but for the grander scope of Wikipedia. This works well with idea lab especially for reoccuring ideas involving the same subject. WP:VILLAGE policy and miscellaneous are not exactly "help resources". Help desk and WP:Noticeboard are aimed for smaller scopes. Lucia Black (talk) 01:19, 14 January 2016 (UTC) Is what you're suggesting basically WP:PERENNIAL? --Izno (talk) 12:40, 14 January 2016 (UTC) not exactly. Those are not-issues. Which could benefit a link to as a reminder for the proposal I'm coming up with. Lucia Black (talk) 15:23, 14 January 2016 (UTC) An example of the proposal is Wikipedia:Perennial proposals, which is linked from Wikipedia:Village pump (proposals). --NaBUru38 (talk) 19:01, 18 January 2016 (UTC)

2016 WMF Strategy consultation

Hello, all.

The Wikimedia Foundation (WMF) has launched a consultation to help create and prioritize WMF strategy beginning July 2016 and for the 12 to 24 months thereafter. This consultation will be open, on Meta, from 18 January to 26 February, after which the Foundation will also use these ideas to help inform its Annual Plan. (More on our timeline can be found on that Meta page.)

Your input is welcome (and greatly desired) at the Meta discussion, 2016 Strategy/Community consultation.

Apologies for English, where this is posted on a non-English project. We thought it was more important to get the consultation translated as much as possible, and good headway has been made there in some languages. There is still much to do, however! We created m:2016 Strategy/Translations to try to help coordinate what needs translation and what progress is being made. :)

If you have questions, please reach out to me on my talk page or on the strategy consultation's talk page or by email to mdennis@wikimedia.org.

I hope you'll join us! Maggie Dennis via MediaWiki message delivery (talk) 19:06, 18 January 2016 (UTC)

• Moved from WP:VP/T by Patrick Earley (WMF) (talk) 19:28, 18 January 2016 (UTC)

Arbitration case names

Earlier arbitration cases typically took the form of Wikipedia:Requests for arbitration/Casename in their pagenames (e.g. Wikipedia:Requests for arbitration/Skyring), but some time ago, the naming convention got changed to Wikipedia:Arbitration/Requests/Case/Casename (e.g. Wikipedia:Arbitration/Requests/Case/GamerGate) for new cases only. No problem with the new convention, but why are all the old pages still at their original names? When Wikipedia:Votes for deletion got moved to Wikipedia:Articles for deletion, bots moved all the old VFD pages that they could find, as you can see in the page history of Wikipedia:Articles for deletion/2000s music groups, and humans have cleaned up afterward, as seen in the page history of Wikipedia:Articles for deletion/3000. Why can't we do the same thing here?

See Wikipedia:Arbitration/Index/Cases/All#Alphabetical for an example of this situation's problems; the links all refer to real cases, but lots of them are red because of mistakes I made when compiling the list, due largely to the conflicting naming conventions. And like in any other situation, the enforcement of a single naming convention makes it easier to navigate from one case to another: if you're at the Whatever case page, at Wikipedia:Arbitration/Requests/Case/Whatever, you know that the Something Else case will be at Wikipedia:Arbitration/Requests/Case/Something Else; you don't have to go searching for Wikipedia:Requests for arbitration/Something Else or otherwise confuse yourself over the different naming styles.

So the proposal: a bot be written to move all cases following the old naming convention to titles matching the current naming convention, and human editors encouraged to help if they feel like it. Nyttend (talk) 16:08, 17 January 2016 (UTC)

Sounds useful. Can you estimate the total number of cases to be moved, and the total number of incoming links to be fixed? Will you proceed to change links that occur in the body of Arbcom cases, or in the ANI archives? Will you leave links in the old case locations? Some of the Arbcom clerks might be using automation or scripts that could be affected by this change. EdJohnston (talk) 16:42, 17 January 2016 (UTC)

About 1611 pages have to be moved according to [this]. Assuming that the bot doesn't need to move redirects as well.Jo-Jo Eumerus (talk, contributions) 17:02, 17 January 2016 (UTC)

There's no reason to change links or to make any other modifications to pages other than through Special:MovePage; pages moved from VFD to AFD still have links to the VFD titles. And I don't imagine any automation or other script-related work being affected, since they changed the naming convention 6½ years ago; it's not like people are routinely making title-dependent automated or scripted edits to pages from 6½-or-more years ago. I did leave a note at the clerks' noticeboard, however, so they'll be aware of this. Nyttend (talk) 23:21, 17 January 2016 (UTC)

PS, I'm reminded that many Arbcom cases have redirects, e.g. WP:ARBPIA. Of course they'll need to be changed to avoid double redirects, but I don't imagine any reasons to be editing the contents of non-redirects. Nyttend (talk) 02:13, 19 January 2016 (UTC)

Recursive Reference Tooltips

Currently if a tooltip is displayed for a reference, which contains a link to another (nested) reference, it will not be possible to display the nested reference by hovering on the link in the tooltip. Is there a support for being able to display the references recursively by just hovering on the links? (Pinging Yair rand.) Petr Matas 12:30, 14 January 2016 (UTC)

So, I actually wrote the code necessary for that back in September 2012, but I never got around to pushing it to the gadget. I'll see if I can merge some changes in now... --Yair rand (talk) 22:28, 14 January 2016 (UTC)

@Petr Matas: Done. --Yair rand (talk) 23:50, 17 January 2016 (UTC)

Thanks! Petr Matas 20:11, 19 January 2016 (UTC)

Eliminate "Edit" link for old revisions

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.

---

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)

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.

Should notability criteria of Sportsmen, soldiers and politicians be tougher ?

Many articles about sports biopic, created by @Lugnuts: is single sourced from espncricinfo or other websites. Most of these Cricketers don't have much notability. Wikipedia is not a sports database that every player must be listed. However every article created by Lugnuts is not poorly sourced.

There is another editor Zee money who creates one after another unsourced biographies of deceased soldiers and politicians.

As nobody has complained or nominated their articles for deletion, I feel they have not violated any policies by creating these: Sergei Zhurikov, Takaji Muranaka, Lu Dachang, Yuan Guoping, Zhou Zikun, Aslam Sattar, Abdul Ameer, Zeeshan Butt, Rajat Dey, and many many more.

The BLP policies of actors/directors/actress/musicians is very tough and actors with two films have their article redirected or deleted. But when it comes to sportstars Wikipedians are a bit lenient!--223.176.1.183 (talk) 15:37, 19 January 2016 (UTC)

I create missing biographies of notable people in line with WP:NCRIC (which in itself has recently been revised and tightened). If you'd like to discuss this further, then the Cricket Project is the place to raise your concerns. Thanks. Lugnuts ^{Dick Laurent is dead} 19:14, 19 January 2016 (UTC)

The WP:WikiProject Military history/Notability guide offers some guidance for suitability of inclusion for soldiers. Remember that they may be notable for a reason other than their military service. However, it appears that some of the soldiers you've listed do not meet these notability guidelines and their articles could be nominated for deletion. It looks like a number of the articles created by Zee money are devoid of references and are of dubious notability at best. Mojoworker (talk) 21:29, 19 January 2016 (UTC)

And the fact that there's not been any complaints or deletion nominations proves nothing about policy whatsoever. With over 5 million articles here, sometimes stuff that is questionable doesn't draw attention for months or years. The IP editor has obviously noticed and if he is concerned he should feel free to create an account and do the things he says are not being done. Otherwise, someone will get around to it eventually, there is no deadline. Regards, TransporterMan (TALK) 21:43, 19 January 2016 (UTC)

Note that I haven't listed every non-notable article created by Zee money. Zee money creates article about deceased soldiers and politicians almost everyday. New page patrollers ignore as they are dead. They also assume that non-English sources might be available. There must be 200 articles created by Zee money which is non-encyclopaedic. Are we going to create articles about every major, corporal, general who took part in some war. Are we going to create article about every politician, union leaders who took part in some protests and revolution. Zee money will continue creating such articles. Then editors from other countries will also create articles of every deceased soldier from their country and they will might say if Zee money can create, we too can. I feel nominating them for deletion won't work as people might vote keep. That's why I asked that Wikipedia must have a strict rule about biography articles of sportsmen, soldiers and politicians. And biographies of living persons as created by Lugnuts shouldn't be single sourced. Every player linked in espncricinfo can't be notable as every actor with IMDB page is not notable.223.176.14.89 (talk) 03:35, 20 January 2016 (UTC)

Mojoworker, I'm confused how Zee money fits in. Nyttend (talk) 14:18, 20 January 2016 (UTC)

@Nyttend, Zee money is the creator of the articles linked in the OP. ‑ Iridescent 15:16, 20 January 2016 (UTC)

Thanks Iridescent. Sorry, I should've been more clear. @Nyttend, yes, I was referring to the Chinese soldier biography articles linked in the OP (as well as Zee money's other such contributions). Mojoworker (talk) 20:41, 20 January 2016 (UTC)

@Nyttend:Who is this 119 Ip who removed my comment against Zee money two times first, second and sadly nobody noticed it. And the Ip is creating multiple talk pages. Are we going to allow Wikipedia become a politicians directory and Soldier database? Every deceased soldier of high rank can't have an article. 223.176.11.79 (talk) 17:26, 20 January 2016 (UTC)

What other accounts do you edit with, IP 223.176.11.79? Lugnuts ^{Dick Laurent is dead} 19:05, 20 January 2016 (UTC)

@Lugnuts do you have any reason to believe 223.176 is socking, or editing while logged out to evade scrutiny? If so file an SPI, but he has a valid point – at least where Zee money is concerned. Some of those articles don't appear to meet the current MILHIST notability standards. As to Cricket articles, see WP:NCRIC and WP:CRIN for Cricket notability guidelines. I haven't examined Lugnuts' Cricket article creations in depth, but the couple I looked at from the OP's links above seem to meet the notability criteria. As for 119.118.221.0, based on the similarity of edits (creating talk pages tagged with WikiProjects at almost Bot-like speed) it appears to be Zee money editing while logged out. And the removal of other editors' comments is troubling. 223.176, I don't know if your proposal here is going to get much traction, but you may want to move this to ANI to have the behaviour of Zee money examined if you think administrator action is required (if no admin takes action here). Mojoworker (talk) 20:41, 20 January 2016 (UTC)

A "new" editor who's first edit is to question long-standing notability guidelines by forum shopping on this messageboard? No, why would that raise any suspicions?! And my articles don't "...seem to meet the notability criteria" they DO meet the notability criteria. Every single one of them. Again, if anyone has issues over any notability criteria, I suggest they raise them at the relevant project's talkpage, rather than fishing here. I make no secret of the articles I've created - they can all be found from links on my userpage. Here are all the cricketers I've created, if anyone wants to check them vs. the notability criteria for cricketers. Have fun! Lugnuts ^{Dick Laurent is dead} 20:56, 20 January 2016 (UTC)

Lugnuts, I have no doubt that the articles you created meet the notability guidelines – as I said previously, the two I checked certainly seem to be fine. And I believe your assertion that they all are notable. If you look at what I've posted above, I've never questioned the notability of your articles. But, do you also also think all of Zee money's articles are notable? I realize you may be pissed off that you were the editor named in the original post when you've been following the guidelines all along. I'd probably feel the same. But 223.176 has raised a legitimate problem with some of Zee money's edits, which do indeed appear to be problematic – especially the removal of another editor's comments. Mojoworker (talk) 01:04, 21 January 2016 (UTC)

Those who have dynamic IP, their latest IPs won't show every edit history. I am the same editor in 1, 2, 3. 223.176.12.95 (talk) 01:42, 21 January 2016 (UTC)

The articles created by the other user don't look notable to me, but then again, I don't know anything about the notability requirements of the Military history project. The main issue is that most of them have no sources whatsoever. They all could be notable, but it's something that needs raising with WP:MH and then possibly AfD. Thanks. Lugnuts ^{Dick Laurent is dead} 07:44, 21 January 2016 (UTC)

When editing a section, please could references be displayed on preview?

Although I've been editing Wikipedia for four years or so, a thousand or two edits on I still make syntax errors from time to time when typing in references. More often than I care to mention, to be honest. Let's face it, references are always the hardest part to get right. If I was editing a full article, then any error of that kind would be evident immediately on preview, as the references would be shown below the text of the article. But if I am editing a section, they aren't. Now I consider myself to be an editor "with some experience", yet I still make syntax errors. So imagine how it is for inexperienced editors? I remember that when I was starting out, reference syntax was by far the greatest challenge. Therefore, my proposal is that on preview of a section edit, there be a preview of the references following the preview of the text of the section itself. I'm guessing that this wouldn't be all that hard a change to make, but believe me, it would make Wikipedia editing life a whole lot easier. It would also make Wikipedia editing a more accessible activity for newbies. Boscaswell (talk) 16:21, 15 January 2016 (UTC)

Speaking of syntax, or maybe it's semantics, do you maybe mean "references" as opposed to just internal links, which should render in a page preview? Beeblebrox (talk) 18:07, 15 January 2016 (UTC)

Haha! Yes, of course! I've edited my initial proposal. Please feel free to delete as you see fit, including these two lines of mine. Thanks! Boscaswell (talk) 20:06, 15 January 2016 (UTC)

If you just type <references /> at the bottom of your section edit and hit preview, it should work? — xaosflux ^Talk 21:01, 15 January 2016 (UTC)

Yes, that method works, or using {{reflist}}. Then hit preview, review your references, and then be sure to remove the reflist code before you actually save. That's how I've done it for years. Ivanvector 🍁 (talk) 21:03, 15 January 2016 (UTC)

Tracked in Phabricator
Task T7984

There are some interesting corner cases for actually getting this feature, but at least some implementation of it has been in a backlog of patches for many months now. Maybe MW devs should do a code-sprint on clearing all that out before pusing ahead with so many new initiatives? DMacks (talk) 21:20, 15 January 2016 (UTC)

I use Anomie's AjaxPreview script, which is brilliant. It's superior in almost every way to normal page preview, even forgetting the references issue. I used to put <references/> at the bottom of my edits, but I kept forgetting to remove it afterwards and it didn't support named references from other sections. The script sorts that all out for you. Relentlessly (talk) 21:21, 15 January 2016 (UTC)

Thanks for the suggestions, guys. I had no idea of those methods. Similarly, few relatively-inexperienced editors will, and of course no newbies will, either. Which makes, DMacks, your consideration that MW devs should prioritise this (among other things) before pushing ahead with new initiatives really rather important. In my opinion. Could that be done, please? Thanks! Boscaswell (talk) 07:55, 16 January 2016 (UTC)

Pending dev work, we could include interface directions if it would help, perhaps in MediaWiki:Previewnote. To see an example preview an edit to testwiki:User:Xaosflux/sandbox. — xaosflux ^Talk 16:22, 16 January 2016 (UTC)

An interesting option is to use {{reflistp}}. (Reflist for Previews.) That will show you the refs in preview mode and only in preview mode. If you accidentally save the page without removing {{reflistp}}, it deactivates itself so it doesn't screw up the normal page view. The page also gets added to hidden category Category:Pages_with_a_transclusion_of_Template:Reflistp_that_should_be_removed, and someone will come along to clean up the forgotten {{reflistp}}. Alsee (talk) 04:58, 17 January 2016 (UTC)

Folks above have pointed out some useful workarounds here – thanks. Thanks also to User:Fat&Happy for {{reflistp}} which I didn't know of, and looks useful ... but it's still a workaround.
I support Boscaswell's call for development work. From the UI point of view, it seems very simple to me: a section preview should behave just as any whole page (preview or saved) now helpfully does: if there's no explicit reflist, an implicit reflist is at the end of the displayed content. I'm sure making MW do that with a section preview isn't as simple as I describe it, but IMHO it's obvious that that's how it should be. Stanning (talk) 09:25, 17 January 2016 (UTC)

• FYI, you've been lucky, this should be fixed in about a week from now! Cenarium (talk) 08:42, 20 January 2016 (UTC)

Three cheers! Thank you, Cenarium. Boscaswell (talk) 08:09, 21 January 2016 (UTC)

Submitting someone else's CHU request

Since becoming an admin eight years ago, I've periodically seen requests for unblock-to-change-username, almost always left by people unfamiliar with the system, and always thought that the post-unblock part of the system was clunky: this person's new, and yet we require him to post his own request for username change with a demand that he'll be reblocked if he doesn't submit the username change request pretty soon? Proposal: when a user is blocked for a username problem but submits an acceptable unblock-to-change-name request, the unblocking admin should submit the name-change request. (My wording is tweakable, of course) I understand the system pretty well, unlike the new person who's trying to figure out how to participate at this website after such a rocky start, and the new person's already submitted a good request for a new username. Shouldn't I go ahead and help the guy? And perhaps alternately, once the user's unblocked, any other user may submit the request. What if the unblocking admin forgets, for example? Aside from a typo, there's no chance of submitting the wrong username, and as long as a diff is provided, we shouldn't need to worry about someone faking someone else's request. Nyttend (talk) 14:16, 20 January 2016 (UTC)

PS, this grew out of a short discussion at WP:ANI#Global rename please, where someone's justifiably gotten upset that he's having to wait a long while for his new username. Three people commented there (I haven't), so I'm notifying them all here. Nyttend (talk) 14:21, 20 January 2016 (UTC)

Regarding that particular ANI topic, I've notified one global renamer of this.Jo-Jo Eumerus (talk, contributions) 14:33, 20 January 2016 (UTC)

It's fine to submit a request on behalf. You could also direct the user to special:GlobalRenameRequest, assuming they have email address set. This can even be done while blocked. I've actioned this request. –xeno^talk 14:35, 20 January 2016 (UTC)

• Support. Sounds sensible to me. If the request is put in with a link to the unblock, it should indeed be safe enough. The ideal would be for the unblocking admin to make the request - I just never have done before as I've always assumed they have to do it themselves (as that's what the default unblock template says). Boing! said Zebedee (talk) 14:35, 20 January 2016 (UTC)

  Someone should update that template to point also to Special:GlobalRenameRequest, which is much, much easier to use than CHUS. –xeno^talk 14:38, 20 January 2016 (UTC) P.S. I would encourage admins who routinely patrol unblock requests to apply for the global renamer privilege at m:SRGP

  Good idea, yes. I've applied for global rename, so we'll see if they think I'm suitable. Boing! said Zebedee (talk) 15:33, 20 January 2016 (UTC)

• Support, and thank you, all who helped with the problem I took to ANI. I got about as confused as the new user there. Bishonen | talk 15:06, 20 January 2016 (UTC).
• Support, I see no reason not to do this. Seraphimblade ^{Talk to me} 15:10, 20 January 2016 (UTC)
• Support - Wikipedia is not a bureaucracy; if any user makes a rename request, in any public location on Wikipedia, such that it is clear that the user really means it, as well as the intended user name and the reason, it should be forwarded. The user being blocked is irrelevant in this case, since we do want the user to have his/her username changed. עוד מישהו Od Mishehu 21:46, 20 January 2016 (UTC)
• Support: Of course. --Tito Dutta (talk) 22:43, 22 January 2016 (UTC)
• Support Yeah, I've seen a lot of these requests and I assumed we weren't allowed to make requests for username changes by proxy. I think this kind of procedure is sensible and makes it more likely folks will stick around. I, JethroBT ^{drop me a line} 02:25, 24 January 2016 (UTC)

Categorizing

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.

---

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)

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.

Proposal to change the status of an essay to guidance or policy.

The essay WP:Rhetoric (which I have not contributed to) seems to me to offer very good advice on maintaining a WP:NPOV. I would like to see its status raised to avout the increasing way that some groups are using rhetoric to subtly promote their causes. Martin Hogbin (talk) 17:58, 28 January 2016 (UTC)

Isn't the image size preferences coded in exactly the wrong way?

Currently, the preferences allows you to set a default pixel size for images, but keeps all other images the same size as the coding, unless an undocumented hack is used involving "upright".

Instead of encouraging the undocumented hack, shouldn't we instead propose a change to how the image size preferences work, where, instead of choosing a pixel size for the default, you choose a scale factor to apply to all images? There may need to be a hard-coded maximum above which an image won't be upscaled, and a hard-coded minimum below which they aren't downscaled, but that's edge cases.

Let's stop trying to hack the software using a parameter, "upright" with a default setting of .75 when a sensible default setting for the undocumented use would be 1, and instead ask our coders for a sensible solution. Adam Cuerden ^(talk) 07:44, 27 January 2016 (UTC)

Upright has been documented since before I arrived almost three years ago, at WP:IMGSIZE, WP:EIS, and probably other places too. Here is what each looked like a year ago: WP:IMGSIZE permalink, WP:EIS permalink. So I'm at a loss to understand where this "undocumented" is coming from.
Your use of "hack" appears to be a pejorative shorthand for "the wrong solution to the problem in my opinion". I won't quibble over those semantics.
Upright is the victim of an evolution in technology and in the community's thinking about image sizes. I haven't been involved in a lot of it, but there has been a ton of debate about image sizing (and our software support for it) over the years. The status quo reflects the current consensus, or inability to reach a new consensus, and there is a lot of politics involved. My perception is that the issue is tabled for the time being, but feel free to try to untable it. ―Mandruss ☎ 11:31, 28 January 2016 (UTC)

Remember we have British and American English readers - the term "table" has the opposite meaning to those two groups--S Philbrick(Talk) 13:18, 28 January 2016 (UTC)

Can't remember something I never knew! Thanks. My definition, from m-w.com: "to decide not to discuss (something) until a later time". ―Mandruss ☎ 13:32, 28 January 2016 (UTC)

Note that this is also a concern with developers. Basically, we added scaling functionality to upright as a value to that paramater, but that was 'incorrect' in hindsight, likely it should have been two paramaters like "upright" and "scale". We've been talking about how to fix that for a while already, but it's a difficult thing to change in hindsight. There is a more expansive discussion about these and a few more related image thumb nailing issues in phab:T351. Unfortunately much of that stalled, after we made 'another' mistake on that front. —TheDJ (talk • contribs) 18:22, 28 January 2016 (UTC)

Model release - medical photos and more - legal review - WMF grant proposal

This is more of a concern for Wikimedia Commons, but it would affect English Wikipedia too. I am seeking comments and hopefully endorsements on a draft request to the Wikimedia Foundation for grant funds. Opposition and statements of doubt are also useful. If you like, please comment at meta:Grants:PEG/Wikimedia New York City/Legal review and templates for model release.

For some time I have been collecting examples in Wikimedia projects in which there is some disagreement about whether an image violates personality rights and would require a model release to host in Wikimedia Commons. See examples in the discussion sections at meta:Grants_talk:PEG/Wikimedia_New_York_City/Development_of_a_model_release_process_for_photos_and_video.

Thanks. Blue Rasberry (talk) 19:46, 29 January 2016 (UTC)

Recent additions

Wiktionary has a feature wherein each new entry to a category shows on the category page. Can wikipedia enable a similar feature to appear on its categories? 92.10.224.67 (talk) 16:34, 1 February 2016 (UTC)

Does it allow the new entries to be sent as watchlist notifications? Praemonitus (talk) 18:42, 1 February 2016 (UTC)

Wiktionary uses DynamicPageList for that, which I don't think is enabled here. --Yair rand (talk) 21:40, 1 February 2016 (UTC)

Simple proposal on "editing old version" editbox

When comparing old versions of an article via page history, it would be quite useful to be able to directly edit the current version of a page (e.g., in order to restore something which has been inadvertently removed from a page several edits ago). Yet if you click edit, you are presented with an edit box for the difference you are currently looking at (e.g., here), which does have its practical advantages. Surely it would be possible to add a link to this "old version" editbox which would take you to an editbox for the article as it currently is. All that would be needed would be to change to text in the pink box from:

You are editing an old revision of this page. If you save it, any changes made since then will be removed.

to:

You are editing an old revision of this page. If you save it, any changes made since then will be removed. Click here to edit the current version.

Is that do-able, or are there practical or technical reasons why it's a bad idea? Grutness...wha? 00:49, 2 February 2016 (UTC)

• Support I would also support auto-tagging of edits made from an old version per this earlier discussion. The notice is located at MediaWiki:Editingold. Wikipedia:Village pump (technical) would probably be a better place to ask about if it was possible, though assuming the notices work similar to templates my guess is magic words along with possibly {{Edit}} could create the necessary link. PaleAqua (talk) 03:24, 2 February 2016 (UTC)
• The phrasing "Click here" is typically considered bad practice, I think. Perhaps the link could be just "Edit the current revision". --Yair rand (talk) 03:59, 2 February 2016 (UTC)

• There is no technical issue with that, if I'm reading this right, the additional text would just go to the same target as pressing the EDIT tab at the top of the page, is that your intent? If so please work up what you want it to say and propose at MediaWiki talk:Editingold, slap an edit request template in there when ready to go live if no objections. — xaosflux ^Talk 04:45, 2 February 2016 (UTC)

Can't say I care for the idea of implementing any old little thing that somebody dreams up, as long as there are no objections on a page with such limited exposure. The page has 31 watchers and we all know that doesn't mean 31 active watchers. ―Mandruss ☎ 12:21, 2 February 2016 (UTC)

• Support -- Not because I would use it or have ever felt the need for it, but because the rationale makes sense to me, I recognize that not all editors are the same nor should be, its feature creep factor seems minimal, it doesn't look like a big developer effort, and PaleAqua supports it. The proposer may wish to return the favor in § Darker section titles in page history.
  Re Yair rand's suggestion, I usually try to imagine the link text without a link; does it still seem appropriate? Without a link, "Edit the current revision" looks like an instruction, an imperative. Suggest the alternative: "You may wish to edit the current revision instead." ―Mandruss ☎ 11:55, 2 February 2016 (UTC)

Thanks everyone - yes, Xaosflux, that was exactly my intention as far as what I hope it will do. I will propose it at Editingold with Mandruss's correction. Cheers, Grutness...wha? 22:32, 2 February 2016 (UTC)

Oh, and it does look simple: edit this page. There may be even easier ways to do it I'm not aware of. Grutness...wha? 22:41, 2 February 2016 (UTC)

The following line should do it better:

You may wish to {{edit|{{FULLPAGENAME}}|edit the current revision}} instead.

This produces:

You may wish to instead.

עוד מישהו Od Mishehu 10:52, 3 February 2016 (UTC)

Darker section titles in page history

Tracked in Phabricator
Task T125657

Granted, I could use a new glasses prescription, but these titles are always a bit hard to read. A minor thing to many (especially those whose glasses prescriptions are just fine), but it's an easy fix too.

PROPOSAL: Make the section titles in page history darker, while remaining distinguishable from the remainder of the edit summary.

• Current: all text italic, section title #808080
  (→‎Submitting someone else's CHU request: Origin of this request)
• Option 1: all text italic, section title #707070
  (→‎Submitting someone else's CHU request: Origin of this request)
• Option 2: all text italic, section title #606060
  (→‎Submitting someone else's CHU request: Origin of this request)
• Option 4: all text italic, section title #585858
  (→‎Submitting someone else's CHU request: Origin of this request)
• Option 3: all text italic, section title #505050
  (→‎Submitting someone else's CHU request: Origin of this request)
• Option 5: section title italic #585858, comment roman
  (→‎Submitting someone else's CHU request: Origin of this request)
• Option 6: section title: light, comment italic
  (→Submitting someone else's CHU request: Origin of this request)
• Option 7: section title: roman #585858, comment: italic
  (→Submitting someone else's CHU request: Origin of this request)

Option 4 was added later by another editor, and is halfway between 2 and 3 in darkness. Options 1–4 are shown in ascending darkness sequence.

―Mandruss ☎ 08:44, 24 January 2016 (UTC)

I added option 6 and switched everything to use html code closer to what actually shows up in history list and added comments describing the options. PaleAqua (talk) 20:51, 31 January 2016 (UTC)

• NOTE - I found that the differences are more noticeable if you (1) apply a user CSS change from the collapsed table below and (2) look at actual page history pages. I recommend doing that and trying the change in actual use for awhile. ―Mandruss ☎ 11:01, 25 January 2016 (UTC)

CSS for testing

CSS to be added to your common.css to test each option (remember to remove when finished with testing). If you do not already have a common.css, simply create it. Option CSS 1 .autocomment { color: #707070; } 2 .autocomment { color: #606060; } 3 .autocomment { color: #505050; } 4 .autocomment { color: #585858; } 5 span.comment { font-style: inherit; } .autocomment { color: #585858; font-style: italic; } 6 .autocomment { color: inherit; font-weight: lighter; font-style: normal; } 7 .autocomment { color: #585858; font-style: normal; }

• Support 2 Support 1 Support 5 Support 6 Support 7 as proposer. Consider it an accessibility issue. ―Mandruss ☎ 08:44, 24 January 2016 (UTC)
• Any particular color that you think would contrast well with the black of the edit summary-proper? --Izno (talk) 18:43, 24 January 2016 (UTC)

  @Izno: If someone could tell me the hex triplets for the existing two colors, I could play with it and make the proposal more specific, with color samples—if it hasn't snowed before then. ―Mandruss ☎ 01:36, 25 January 2016 (UTC)

  The grey is currently #808080 and the dark grey is #252525, according to my console (user error may apply). --Izno (talk) 01:46, 25 January 2016 (UTC)

  I made the proposal more specific. ―Mandruss ☎ 02:28, 25 January 2016 (UTC)

  Hi Mandruss, Maybe it has been asked and answered but whey are one to five in italics but 6 is regular? And, I see 6 as being a speck darker now that the sun is going down. Cheers! {{u|Checkingfax}} {Talk} 23:48, 31 January 2016 (UTC)

  @Checkingfax: It was proposed below (quite rightly in my opinion) that a switch in font, between italic and roman (regular), is at least as noticeable as a difference in darkness, so new options were added for that. Both 5 and 6 include such a switch. And there's a possibility of a 7 that would be the same as 6 but with a lighter (less dark) section title. The third line of my current css, User:Mandruss/common.css, shows how to test such an Option 7. ―Mandruss ☎ 23:56, 31 January 2016 (UTC)

• Comment Note that the class of the element is autocomment. So if you edited your common.css style sheet you could change the color for your account. For example:.autocomment { color: #606060; } would change it to your choice 2 above. PaleAqua (talk) 05:27, 25 January 2016 (UTC)

  Tell ya what ... if this proposal fails, I'll assume I'm the only one who has the problem or ever will, and I'll try your suggestion. For now I'm assuming I'm not so unique, and I'm interested in the overall welfare of the project, not just myself. I've found many people have trouble grasping that concept, but I can't help it. I also hope this, while providing some benefit for some people, is so inconsequential as to stand a chance of passing, so I can experience that joy just once in my Wikipedia career. ―Mandruss ☎ 05:37, 25 January 2016 (UTC)

  I actually think this has a good chance. 808080 is kinda light for accessibility as Earwig points out below. But it's nice to be able to test out different values as well as pick a personal setting if those end up different. It also may be some time before anything changes so if it's an improvement for you now why wait? While I supported a higher contrast grey below its likely that I would personally use a lighter color for my own CSS. I heavily tweak the appearance of the watchlist and history to make it easier for me to history drive. PaleAqua (talk) 13:51, 25 January 2016 (UTC)

  PaleAqua, I don't see the autocomment in my User:Checkingfax/common.css file; there is nothing even close to that. Please advise. Cheers! {{u|Checkingfax}} {Talk} 23:33, 31 January 2016 (UTC)

  Wouldn't be there if you hadn't added it yet. common.css is for overriding the default Wikipedia appearance. PaleAqua (talk) 00:18, 1 February 2016 (UTC)

• This is actually more supported by policy than you might have realized... WP:COLOR (part of WP:ACCESSIBILITY) requires a minimum contrast ratio between text foreground and background colors. The existing combination is actually not compliant; it doesn't even reach the minimum of AA. A good compromise that reaches the recommended AAA level is #585858, which is exactly halfway between #2 and #3 above, so I'll add it below as #4 and support it. If not, any of 1–3 are at least AA-compliant. — Earwig ^talk 07:34, 25 January 2016 (UTC)
• While I couldn't see any difference between the different options until I zoomed in, Earwig makes a good argument for changing the colour for accessibility reasons. If this is indeed the case, however, I'd have thought that this should be a central change rather than simply changing it locally. Regardless, I support a change that's WP:COLOR compliant, however it's done. Sam Walton (talk) 08:09, 25 January 2016 (UTC)
• Comment - All other displays of edit summaries appear to use the same class "autocomment", so I assume this would automatically extend to them as well. This includes contribs and watchlist. This is probably a desirable thing, but it should be stated since I didn't do it in the opening. ―Mandruss ☎ 09:20, 25 January 2016 (UTC)
• Comment - See my new NOTE above. ―Mandruss ☎ 11:01, 25 January 2016 (UTC)
• Support preference towards #4#5#6 (edit switched to #7) but anything that increases the contrast enough should work. PaleAqua (talk) 13:51, 25 January 2016 (UTC)
  • Switched to #7. Would prefer #6 but that doesn't seem to work in all cases. If there was a way to use just lighter ( inheriting #252525 ) in browsers that supported it and fallback to #585858 in other browsers that would be my ultimate choice. But again I support anything that meets accessibility requirements and keeps a visual distinction between the section text and the rest of the comment. PaleAqua (talk) 00:21, 1 February 2016 (UTC)
• Support 4, per Earwig and SamWalton. Rehman 14:33, 25 January 2016 (UTC)
• Comment - I urge anyone !voting 3 or 4 to try it in actual use for awhile. Does it always provide enough contrast between the section title and the rest of the editsum? Or do you sometimes have a little trouble seeing where one ends and the other begins? I don't wish to solve one problem and create another. ―Mandruss ☎ 00:34, 26 January 2016 (UTC)

  Trying the setting out on my alt account which I use for UI checks as it doesn't have any other setting / UI tweaks from the default. FWIW, seems to work well enough at least with my glasses and monitor. Note that in addition to the brightness difference the autocomment text is obliqued / italicized compared roman for the rest of the comment. PaleAqua (talk) 01:38, 26 January 2016 (UTC)

  @PaleAqua: I'm seeing italics for the whole thing, and always have. ―Mandruss ☎ 01:43, 26 January 2016 (UTC)

  You're right. The letters are slightly oblique on my alt account—sans-serif maps to Helvetica on this computer. Probably best to have at least two differences between the text segments. shade/tone is one difference. Changing the hue, face, font size or thickness might be another. I'd actually prefer if both text were black and it was just a font weight difference as that is the effect that the lighter text is emulating. color (#585858) (→‎Submitting someone else's CHU request: Origin of this request) vs weight (lighter) (→‎Submitting someone else's CHU request: Origin of this request). Doesn't look like weight renders properly which doesn't surprise me as it requires a font with a thin or ultra-thin weight. Edit: Works if I specify the font family (Helvetica, Arial, sans-serif) which is similar to what Wikipedia uses: color (#585858) (→‎Submitting someone else's CHU request: Origin of this request) vs weight (lighter) (→‎Submitting someone else's CHU request: Origin of this request) But not sure how reliable that would be still. PaleAqua (talk) 02:18, 26 January 2016 (UTC)

  @PaleAqua: #585858 with switch to roman: (→‎Submitting someone else's CHU request: Origin of this request) - A very noticeable difference that makes #585858 more acceptable. But there doesn't appear to be an easy way to test that, I can't readily see how that change would be implemented from looking at the HTML, and in any case I'm not sure what to do at this point with respect to the proposal. In hindsight, this probably should have been at WP:VPI first, although that page doesn't get much attention. ―Mandruss ☎ 02:31, 26 January 2016 (UTC)

  I very much appreciate the switch from italics to straight letters, above. To extract a bit more of the HTML, <span class="comment">(<a href="#FOO">→</a>‎<span dir="auto"><span class="autocomment">BAR: </span> FOOBAR</span>)</span>. I think there probably is a way for CSS to take care of this, since FOOBAR is outside the span for italics. #comment should inherit rather than italicize, while #autocomment should italicize. @Edokter: Do you think that would work re specificity (I suppose that's a case of checking the core css?). --Izno (talk) 12:43, 29 January 2016 (UTC)

  Izno, it will work so long you match the original selectors: span.comment {font-style: inherit;} and .autocomment {font-style: italic;}. But I do believe the core issue should be fixed in MediaWiki instead. -- [[User:Edokter]] {{talk}} 21:57, 30 January 2016 (UTC)

  Agreed, but it's usually good to drum up consensus (however small) prior. --Izno (talk) 23:46, 30 January 2016 (UTC)

  Added Option 5. Updating common.css with those two statements and .autocomment { color: #585858; } appears to produce Option 5. The change is fairly dramatic, but I guess that's the point. I changed my !vote. ―Mandruss ☎ 13:45, 31 January 2016 (UTC)

• I will support option 5 per my comments above. @PaleAqua, Rehman, and The Earwig: Do you still support option 4? --Izno (talk) 16:19, 31 January 2016 (UTC)

  Fix ping @Samwalton9:. --Izno (talk) 16:21, 31 January 2016 (UTC)

  I'm not convinced I understand what's changed for option 5, but per my previous comment I support any change that's agreed to be an accessibility improvement. Sam Walton (talk) 16:36, 31 January 2016 (UTC)

  Right, you didn't actually pick an option in your original opinion. Woops. --Izno (talk) 16:51, 31 January 2016 (UTC)

  Updated support especially as I commented above that having two differences makes the distinction clearer. Having played around a bit with "font-weight: lighter;" I'm more of the opinion that it would be a better choice then using a shade of grey. The problem I had with testing earlier seems mostly to be due to the fact that I had customized my body text to a font that doesn't support lighter. The lighter text doesn't look as blurry as the grey text does—consider the impact of using grey on sub pixel rendering etc—and still has a similar contrast to the rest of the comment. With the change of font styles also even for computers that don't render lighter the difference should be clear. PaleAqua (talk) 17:04, 31 January 2016 (UTC)

  Hm, I'm not so sure about that. I definitely see what you're going for, but AFAICT the italics are not an accessibility issue. Is it only so the autocomment remains clearly differentiated? I'm not in love with the look of roman text for edit summaries, but I can live with it if that's what people decide on. — Earwig ^talk 19:31, 31 January 2016 (UTC)

  To really get into the bike shed I think I might have the section link be roman and the rest of the comments remain italics. Means the comment the the editor wrote is the only thing in italics... everything else including the name of the section which might have been named by other editor is is roman. It also means that there would be no change to history entries that didn't have section links. PaleAqua (talk) 20:26, 31 January 2016 (UTC) (edit conflict) Edit: added option #6 to explain what I'm thinking and switched my !vote to that. PaleAqua (talk) 20:51, 31 January 2016 (UTC)

  Not bikeshed at all. I'm for doing the absolute best we can, even if it means ten options or starting over with a fresh proposal. Most editors look at this so much that seemingly insignificant improvements add up to something very substantial. ―Mandruss ☎ 20:42, 31 January 2016 (UTC)

  Was more worried that I was getting close to bike shedding myself. Does the font-weight: lighter work for you? Seems to work on all my browsers once I switched the class of the text to more like what would be on a history page instead of inheriting body text customizations. PaleAqua (talk) 20:56, 31 January 2016 (UTC)

  Was more worried that I was getting close to bike shedding myself. - So I took it, and I'm saying you're not.
  Does the font-weight: lighter work for you? - Um I guess so, I don't see a difference between first half of 6 and last half of 5. They both look like this here text to me. Firefox 44 with Vector. ―Mandruss ☎ 21:08, 31 January 2016 (UTC)

  This ( or this logged out without my CSS styles) is what I'm seeing. PaleAqua (talk) 21:24, 31 January 2016 (UTC)

  I'm seeing something close to your second example, but I can't see that weight difference on this page no matter how hard I look at it. Care to do me a favor and update User:Mandruss/common.css for Option 6? Can't figure that out. ―Mandruss ☎ 21:38, 31 January 2016 (UTC)

  (edit conflict) I can't update your css file ( user css and js files are protected from other editors ), but you can try something like:.autocomment { font-weight: lighter; font-style: normal;} in place of the 3 lines you currently have at the end of your config. You can switch lighter to normal and back to see the effect that it makes. PaleAqua (talk) 21:49, 31 January 2016 (UTC)

  No detectable difference between lighter and normal, and I put the two in separate tabs and toggled between them. And I added color 585858, since I feel we still need some color difference between the two halves. The more I look at that (see User:Mandruss/common.css if you're thoroughly confused by now), the more I like it. Option 7? ―Mandruss ☎ 22:15, 31 January 2016 (UTC)

  I forgot to do include an override of the color in that css bit... should have been: .autocomment { color: #252525; font-weight: lighter; font-style: normal;} but it sounds like lighter isn't working for you which is what I was afraid off. The difference between lighter and normal, should sort of be the difference between normal and bold. For example the lighter and #585858 options on this page look almost identical to me, but the version using 585858 has blurrier letters. But I'm guessing that normal and lighter look the same in your browser. Guessing Arial Light and/or Helvetica Light are not standard across all computers. I would support such an option 7, added above. PaleAqua (talk) 00:18, 1 February 2016 (UTC)

• Oppose – any change because it makes absolutely zero difference on any of my computers. I tried full zoom, a magnifying glass, and I got zip, no hay nada. Cheers! {{u|Checkingfax}} {Talk} 21:46, 31 January 2016 (UTC)

  Why would one oppose a change that has no effect on them? ―Mandruss ☎ 21:47, 31 January 2016 (UTC)

  Because the implementers have tasks on their plates already that have been on their plates for four years and still need to get cleared out first. That is why. Cheers! {{u|Checkingfax}} {Talk} 23:37, 31 January 2016 (UTC)

  This task would take about 10 minutes to implement, not the hours or days most tasks take. --Izno (talk) 23:38, 31 January 2016 (UTC)

  I might be wrong, but I believe this change can be made locally, for all accounts, by any admin willing to edit MediaWiki:common.css. User:PrimeHunter, User:Cenarium, User:Harej, and of course User:Edokter would all be reasonable people to talk to about this. WhatamIdoing (talk) 18:48, 2 February 2016 (UTC)

  You are correct. However, Edokter above said, and I agreed with him on the point, that this change should be made in core rather than locally, since the accessibility problems impact all wikis and not just our own. --Izno (talk) 19:15, 2 February 2016 (UTC)

  Core means WMF? ―Mandruss ☎ 19:19, 2 February 2016 (UTC)

  Core means "MediaWiki software" rather than "en.wp style sheets". --Izno (talk) 21:10, 2 February 2016 (UTC)

  Core means a dev; there are more volunteer devs than WMF devs, but the WMF devs are likely to be involved (at least in approving the change). Also, doing it in core means that all future MediaWiki wikis would benefit (e.g., private wikis, too). WhatamIdoing (talk) 06:52, 3 February 2016 (UTC)

  Yeah, just wondering about political ramifications. Other wikis saying, we agree there's an accessibility issue, but we weren't involved in choosing the best solution to it and we don't appreciate having the choice forced down our throat, yada yada yada, ten people astutely offer ten better solutions, which have to be debated until the whole thing really does become a case of bikeshed, and a simple change mutates into Flow Jr. But I'll defer to y'all's vastly superior experience. ―Mandruss ☎ 06:58, 3 February 2016 (UTC)

• Support options 4 or 5. When working on a laptop in bright light, option six is very difficult to read, and option seven is indistinguishable from the plain black text. Five is also pretty close to black in those conditions, but at least the italics separate it. Grutness...wha? 22:27, 2 February 2016 (UTC)

  @Grutness: Thanks for returning the favor! See my NOTE near the top. I really think folks should try out some options in actual use for awhile before !voting (unless they want to agree with my !vote (7), in which case that's less important ;). The samples at the top are NOT good predictors of the actual experience. By "awhile" I mean like a day or two of heavy use, since a lot seems to depend on the many variations in edit summaries. ―Mandruss ☎ 07:14, 3 February 2016 (UTC)

• I started a collapsed table of the required CSS near the top. PaleAqua, Izno (or anyone), I'm not sure of the CSS for 5 and 6, could you add them? ―Mandruss ☎ 07:43, 3 February 2016 (UTC)

  Thanks, Izno. I cleaned it up a bit (I think). Isn't span.comment { font-style: italic; } superfluous in 6?
  Also the CSS editor gives an error, Element (span.comment) is overqualified. ―Mandruss ☎ 13:16, 3 February 2016 (UTC)

  That just means you can safely remove the "span" from the "span.comment". "Over-qualification" means you have made the selector too specific, which down the road can cause minor issues when you go to override the CSS through some other means. --Izno (talk) 13:41, 3 February 2016 (UTC)

  Sounds like we're better off without it than with it, then, and I'm removing the "span". Revert me if you disagree. ―Mandruss ☎ 13:44, 3 February 2016 (UTC)

  Reinstated. Your CSS editor has no clue what it is overriding; without the 'span.' the rule has no effect. -- [[User:Edokter]] {{talk}} 17:01, 3 February 2016 (UTC)

• Comment: I've filed a task at T125657 on phabricator regarding a change to core. --Izno (talk) 13:41, 3 February 2016 (UTC)

GOCEreviewed template change

An example such as {{GOCEreviewed|user=Dthomsen8|date=January 2016|issues=awaiting deletion decision}} should be made sortable by user, date, and especially issues. Some of the articles not copyedited some time ago because they were considered for deletion and then kept should be tagged for copyedit and the GOCEreviewed template should be removed. I am proposing that the GOCEreviewed template be changed to show the user, date, and issues parameters. --DThomsen8 (talk) 22:05, 5 February 2016 (UTC)

Editing one's own talk page/removal of warning templates

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.

---

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)

Ah, a good point indeed. 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 also just realized, also, that it would be a lot of work going through every warning template so "Please do not remove this template for one month after warning date", would be a lot of work. I would have no problem in helping with this, if it became the case. I stand by my suggestion, as I'm sure there is a solution that can benefit everybody. Boomer Vial^Holla 23:04, 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)

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.

Sharing content with certain users or specific usergroup

Hi. As an example, lets assume that I would like to share my mobile number (or anything for that matter) on my userpage or a specific user subpage. And, I would like to either:

• Allow access to that page's content to only to User:A, User:C, and User:F. Or,
• Allow access to any registered user, but the system should alert me on who is accessing that page (via alert bar?). Or,
• Allow access to a specific usergroup (i.e. Autoconfirmed users, admins, etc). Or,
• Allow access to a specific class of users (i.e. Users who have over 1000 edits, or any other stats-based criteria).

Is any of this possible? Or do we have anything close to something like this? Thanks in advance! Rehman 22:38, 29 January 2016 (UTC)

I know of nothing like that. Other than certain special pages, all undeleted pages can be viewed and read by everyone, including IPs, as can every non-hidden and non-oversighted revision in the history of any existing page back to its start. We are very much about transparency. Best regards--Fuhghettaboutit (talk) 22:47, 29 January 2016 (UTC)

While mediawiki can support most of this, the English Wikipedia is not likely to adopt any sort of READ permissions; it is contrary to our standard licensing model and open-content philosophy. — xaosflux ^Talk 23:07, 29 January 2016 (UTC)

• You can make a page accessible only to administrators by making it, and then asking an administrator to delete it, using {{db-u1}}. Admins and (mostly) no one else can see the deleted page. Oiyarbepsy (talk) 07:28, 4 February 2016 (UTC)

• Per the above, whether the software supports such an ability or not, the way it has always been here is that a page is either live and public, or deleted. You may find it helpful in the future to explain why an idea would be helpful to the encyclopedia if you want it to be seriously considered. Beeblebrox (talk) 20:05, 10 February 2016 (UTC)

Talk about Flow again

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

Proposing Valentine's Day themed banner on English Wikipedia in US and Canada for Wiki Playlist

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.

---

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)

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.

New usergroup with autopromotion to implement arbitration "30-500" bans as a page protection

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.

---

Tracked in Phabricator
Task T126607

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

3. Sockpuppets of banned users use this as a justification for reverting
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)

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.

Association of Members' Advocates redux

I and some other people are interested in reviving the Association_of_Members%27_Advocates. It has been ten years since it was discontinued. Wikipedia is a much different place now and perhaps it is time to give it another try. Comments are welcome, as well as suggestions on how to proceed. How exactly does one revive a historical Wikiproject, for instance? Here is a Wikipediocracy thread on the matter. Kingsindian ♝ ♚ 16:05, 2 February 2016 (UTC)

• One of the contradictions of Wikipedia, to insert a bit of Marxist jargon, is the dilemma of a person brought before ArbCom — a pseudo-legalistic Discipline Committee. Multiple people pile on with diffs indicating the bad behavior of the "accused." Point-by-point refutation of these charges can start a fast downward spiral of acrimony, tainting the "judges-jury-and-executioners" against the person attempting to defend themself. The only truly viable defense strategy is for third parties to argue the case for the accused. What we have now is a pseudo-legal process in which the defendant has the right to remain silent or to be condemned for engaging in self-defense. This overstates the matter only slightly, as any longtime observer of the ArbCom process will acknowledge.

For myself, I have acted as an informal advocate in a big ArbCom case and in two or three subsequent "clarification" hearings. I feel that there was positive benefit to the project through my participation, that in all likelihood a prolific content contributor was saved for the project at least in part through my actions, and I look forward to participating in a revitalized AMA. Carrite (talk) 17:21, 2 February 2016 (UTC)

• How about a name whose acronym is not a match for that of the American Medical Association? (No offense intended to the numerous other organizations having the same acronym, including three other medical associations.) Since Wikipedia has users, not members, perhaps Association of Users' Advocates, AUA, in which case your biggest competition is the American Urological Association (better joke potential there, too).
  I assume that all communication between advocate and advocee would be in the open rather than e-mail or other off-wiki, and that this would be an explicitly stated rule. ―Mandruss ☎ 17:36, 2 February 2016 (UTC)
• However, reading some of the Wikipediocracy thread, it appears I may have assumed incorrectly as to communication. At some point, I would like to hear the justification for such secrecy in the process. ―Mandruss ☎ 18:01, 2 February 2016 (UTC)

My impression is that when AMA was active, most of the discussion was on-wiki, though some of it was by email (I have only a vague idea). I imagine this would be true in the new version as well. I think the idea was to use the email communication to provide a sympathetic hearing (I am just guessing here). One of the unofficial rules on the AMA page was that the advocate would make clear their role as an advocate in the discussion. So I don't think this would mislead the discussion in any way. Kingsindian ♝ ♚ 19:36, 2 February 2016 (UTC)

Because saying things, even making rhetorical points, can be adduced as additional evidence by an ill disposed arbitrator. Even comments made in error and self-reverted have been used thus. The purity of an all-open all on-wiki editing community is attractive, but in reality a lot goes on (and has for a long time) in semi-public, on IRC (no public logging allowed) and mailing lists and in semi-private - meet-ups and restircted mailing lists, and in total privacy. All the best: Rich Farmbrough, 20:14, 12 February 2016 (UTC).

• Why not Association of Contributors' Advocates? If the majority of ARBCOM cases involve contributors, it makes more sense. Intothatdarkness 19:49, 2 February 2016 (UTC)

I hope we would not be thought of as an association which tries to overhaul the Wikipedia healthcare system. Just kidding. Perhaps it is best to start a new Wikiproject with a new name, rather than use the older one. Since I have little idea of the details of the old one anyway. ACA seems as good a name as any. Kingsindian ♝ ♚ 07:30, 3 February 2016 (UTC)

Yeah, if the old AMA has any political baggage, a change would probably make a meaningful symbolic statement. Might as well throw in Association of Editors' Advocates for consideration. ―Mandruss ☎ 08:19, 3 February 2016 (UTC)

Unless they are committing vandalism, every editor is making a contribution so AEA would be more inclusive. Liz ^{Read! Talk!} 20:54, 4 February 2016 (UTC)

More to the point would be an actual requirement that "arbitrators" show completion of at least one college-level course in "arbitration" so that their "kill them all" solutions would be seen as the egregious violation of logic that they are, and that they would properly weigh what passes for "evidence". Too much to ask? Collect (talk) 21:17, 4 February 2016 (UTC)

Would support. All the best: Rich Farmbrough, 20:16, 12 February 2016 (UTC).

New disambiguation templates

Right now, there are thirty-one disambiguation templates: a few are generic ones such as the basic {{Disambiguation}}, while others are much more specific, e.g. {{Species Latin name abbreviation disambiguation}}. However, there are far more categories of disambiguation pages, ranging from the parent category all the way down to Category:Minnesota township disambiguation pages. Most of these categories are added manually, and the retention of the disambiguation template causes those pages to be in both parent and child categories; for example, Lee Township, Minnesota transcludes {{geodis}} and bears the code [[Category:Minnesota township disambiguation pages]], putting it into that category and into the parent Category:Place name disambiguation pages. I'm proposing that we expand the system of disambiguation templates so that we officially approve a template for each category, in a manner somewhat comparable to stub categories and templates. The point? It should be easier to maintain pages when a single piece of code transcludes both template and category, and it will get rid of having lots of pages in both parent and child categories. Nyttend (talk) 13:44, 9 February 2016 (UTC)

Good idea. Please ping some template editors, I am unable to help you. The Quixotic Potato (talk) 13:50, 9 February 2016 (UTC)

1. Are you sure it's easier?
2. How many thousand templates, and how will we remember them all?
3. Is there an alternative: e.g. {{Disambiguation|category=Minnesota towns}}
   1. This saves keystrokes, but is it really clearer?

All the best: Rich Farmbrough, 20:22, 12 February 2016 (UTC).