Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
Shortcuts:

New ideas and proposals are discussed here. Before submitting:
« Older discussions, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129
Centralized discussion
Proposals: policy other Discussions Ideas
Note: inactive discussions, closed or not, should be archived.

Categorizing[edit]

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

Sortable Wikipedia history page[edit]

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)

Commons categories and Wikidata[edit]

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)

A (advantageous to read the information about the Commons category on Wikidata)[edit]

B (how to visualize the information)[edit]

General comments[edit]

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

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

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)

Extra rights for Administrators in English Wikipedia[edit]

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)

Talk header for TimedText talk namespace[edit]

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)

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)

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

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

  1. Using the edit filter affects performance and is user-unfriendly since the edit button still appears[1]
  2. Users who don't strictly meet the criteria but who, based on their history, are expected to contribute positively in these areas cannot
    Sometimes even the page creator can no longer edit it[2]
  3. Sockpuppets of banned users use this as a justification for reverting[3]
  4. Users who are known, based on their history, to contribute negatively to these areas cannot be prevented from editing them, short of blocking

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

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

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

  1. ^ VPT discussion
  2. ^ example
  3. ^ cf Arb clarification request
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)
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 tcs 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)
  • 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)
  • 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)
  • 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)
  • 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)

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

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.

multiple watchlists or watchlist categories or filter watchlist by wiki-category[edit]

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)

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

WP:SNOWBALL CLOSED:

This proposal to turn Wikipedia from an encyclopdia into a Q&A site has clearly been strongly rejected. Closing to avoid pile-on and further pointless bickering. Beeblebrox (talk) 17:53, 15 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.

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[edit]

Recursive Reference Tooltips[edit]

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)

When editing a section, please could links be displayed on preview?[edit]

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 links. More often than I care to mention, to be honest. Let's face it, links 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 links 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, link syntax was by far the greatest challenge. Therefore, my proposal is that on preview of a section edit, there be a preview of the links 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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=699989793"