Wikipedia:Village pump (proposals)
I know this is a bold proposal, and is likely to be controversial, but stub tags aren't useful. They don't get people to edit stub articles, which is their stated purpose. They do have a number of negatives: They often remain in articles long after they has been brought up to Start-class and higher. They conflict with the classes stated on talk page banners, which are often more up-to-date. They add a useless image and clutter to the articles. It's time to begin to think about eliminating them. For those people who might be feeling reticent, perhaps an experiment should be run where stub tags are removed from a random subset of articles, then they are compared in, say, one year's time, to a subset of similar articles and measured for levels of (destubifying) improvements. Any thoughts? Abductive (reasoning) 00:35, 21 June 2020 (UTC)
Considering I've run contests with over 1000 articles destubbed directly from stub categories like WP:The African Destubathon and Wikipedia:The Great Britain/Ireland Destubathon and am running Wikipedia:The 50,000 Challenge which directly feeds off stub tags this is one of the dumbest, most ignorant proposals I've seen for some time and that's saying something!! There is an issue with updating the project tags once an article is no longer a stub and stub tags remaining in articles not stubs but that's hardly a reason to get rid of them entirely. Rosiestep and myself proposed a bot to sort that out but the Wikipedia community being the divided way they are wouldn't get us the consensus we need to sort it out.† Encyclopædius 08:19, 22 June 2020 (UTC)
I propose that we formally deprecate the inline parenthetical citation style.
Wikipedia has long valued different styles of citation, and we do formally protect a wide range of citation styles. There was even a 2006 ArbCom case that ruled on the issue. However that was 14 years ago, and a lot has changed since then. As Wikipedia moves forward, and our style grows more standardized and formal, I question the utility of the rarely used parenthetical citation style. This style exists because it is used in scientific papers and college essays. However, papers and essays do not have the benefit of being online; thus they cannot have expandable footnotes with fancy coding. Parenthetical citations also clutter the text and make reading more difficult. See for example Actuary, which is one the bare handful of FAs with parenthetical citation style. It includes sentences like which is cluttered, and unnecessarily long because of the citations. At the end of the day, our goal is to serve the WP:READER. The best way we can do that is to provide easy to read articles, free from inline clutter. CaptainEek Edits Ho Cap'n!⚓ 20:38, 5 August 2020 (UTC)
In various studies, being an actuary was ranked number one or two multiple times since 2010 (Thomas 2012, Weber 2013, CareerCast 2015) and in the top 20 for most of the past decade (CareerCast 2014, CareerCast 2016, CNN Money 2017, CareerCast 2019).The most recent arbitrary break is the following: #Arbitrary break 4 (citations).
This implementation proposal seeks a middle way between very hard implementation ideas (e.g., deprecate outright and/or enforce by bot) and softer implementation ideas (e.g. only deprecate for new pages), both directions already being elaborated in the survey area below. --Francis Schonken (talk) 09:13, 2 September 2020 (UTC)
Most people have encountered parenthetical citation styles at some point in their lives.
about a third of science faculty think students have had at least moderate practice (...) using a standard citation style (35%)
The presence and completeness of citations in the reference page at the end of the report was evaluated using the rubric in Table 2If the list of references at the end of a paper is numbered, obviously the in-text cite marks are numbers rather than author-year. (Having author-year cite marks and giving the ref list as a numbered list by order of appearance would make no sense.) The table examples are numbered at the two locations where multiple refs are given, but I agree it does not prove conclusively that authors intended to demonstrate a numbered ref scheme.
The Riverside Garage Girls are the sharpest prog electro rock band in the north city (Janssens 2020, p. 169).
" I cannot express how strongly I am against the idea that only documents which are online are valid citations, which appears to be the logic behind one of the arguments of some supporters.."
Many of you will note that the erstwhile User:Citation bot was blocked about two months ago. After copious discussion, the block has revealed some underlying issues about how we deal with citations, that seem to lack community consensus. The initial block was over Citation bot unlinking sources in reference titles if it was already linked to something like a DOI, or other unique identifier. I thank User:Levivich for the wording of the questions, whose text I snatched verbatim from WP:BOTN :) CaptainEek Edits Ho Cap'n!⚓ 20:39, 5 August 2020 (UTC)
1. Should the titles in citations be linked, and if so, to what (in other words, what should be in
2. Should the titles in citations be linked if that link is a duplicate of an identifier (DOI, PMC, PMID, etc.) (in other words, should we have
|url= even when it is duplicative of, e.g.,
3. Under what circumstances should a title link be removed from a citation, by human or by bot (in other words, when should
|url= be blanked)?
Hi all. Enwp recently gained 'short descriptions', which is "a concise explanation of the scope of the page" (for the background, see the links at Wikipedia:Short_description#History). These are currently a local override for the English language descriptions from Wikidata for 2.3 million articles (1/3 of the articles here), but this may change soon so that only the local descriptions are used (removing them from 2/3 of articles). I think that it is important that the short descriptions and the Wikidata descriptions are kept in sync as much as possible. That is both because the descriptions are most visible on enwp, but also because the English Wikidata descriptions are used in many other places, in particular (from my point of view) in the infoboxes in Wikimedia Commons categories. As such, I am proposing four options for bot tasks to synchronise them, namely:
I started a discussion on Wikidata about the first two, which you're welcome to participate in. There are also discussions on both bot proposal pages. I initially started a thread here at , but discussions on Wikidata led to the bot proposal here, and discussion there in turn suggested an RfC. I assert that these descriptions are too short to be eligible for copyright (which could be an issue since we use CC-BY-SA here but CC-0 on Wikidata) - I've emailed WMF legal to confirm this.
I know that this is a controversial discussion: this thread, and the thread I started on Wikidata, are aimed at starting discussions about how we keep things in sync. I am open coding to up other cross-wiki bot scripts if needed. I think it is in the best interests of both projects to work together. What do you think? Thanks. Mike Peel (talk) 21:34, 6 August 2020 (UTC)
I cannot see the proposals above getting acceptance, but part of the problem that they are intended to resolve is real. We need a lot more short descriptions, and sooner is better than later. They do not have to be perfect, just good enough, as they can be improved at any time. I throw these in to stimulate thought and discussion, including better proposals.· · · Peter Southwood (talk): 08:18, 8 August 2020 (UTC)
I'd like to call attention to a recently created user script that might be helpful in this discussion: . I requested this script and SD0001 was kind enough to write it. In addition to aiding in editing short descriptions, I think it may have value in getting a general sense of the quality of local and Wikidata SDs. I would suggest trying it out on some categories you are familiar with.--agr (talk) 23:26, 31 August 2020 (UTC)
In the main namespace, there are no subpages, so / is just a character in an article name like any other. Pages in the Draft namespace are generally supposed to have the same name as they would in the main namespace once accepted, so it doesn't make sense to have subpages there either. For example, Draft:Andreas Hedlund (arranger/orchestrator) shouldn't be considered a subpage of Draft:Andreas Hedlund (arranger, and Draft:9/11 Review Commission shouldn't be considered a subpage of Draft:9. And to my knowledge, there's no legitimate, intentional subpages in use in the Draft namespace. As such, I propose that we have the Draft namespace be removed from $wgNamespacesWithSubpages. Jackmcbarn (talk) 04:12, 10 August 2020 (UTC)Adding IMDb & Rotten Tomatoes ratings to article infobox (wherever possible)
Currently, no (or very few) articles about films, short-films, web-series, etc. on Wikipedia contains ratings provided by prominent sources like IMDb & Rotten Tomatoes at the Infobox of the article. Many people visit Wikipedia to get all the possible information about the Film including about its Critical Reception. Most articles written about any website contains its Alexa rank. If such articles can contain Alexa rank, then I believe that articles on movies must contain their IMDb & Rotten Tomatoes ratings. Soukarya (talk) 18:11, 17 August 2020 (UTC)
If we decide above to include a critic review aggregation, which service should we include?
Please note that policies and guidelines for this already exist. See Wikipedia:Manual of Style/Film#Critical response and MOS:TVRECEPTION as well as this essay Wikipedia:Review aggregators. The OP may not be aware that a large percentage of the film articles include RT ratings. IMDb should not be included as they are simply a fan poll and of no critical or scholarly value. MarnetteD|Talk 19:16, 17 August 2020 (UTC)
I’ve had bad user experiences (UX) while looking at Draft articles through the Visual Editor, which I use almost exclusively.
Instead of seeing the article itself, they’ll have massive templates that have to be scrolled through every time you want to see—let alone edit—the article.
In contrast, when I look at an article in main space that has a cleanup or AfD tag, it’s unobtrusive and minimized, and expands when you click on it. I think the various Draft tags should be likewise automatically minimized until they are clicked on. I think newer users especially would feel more comfortable continuing to improve the article if there wasn’t massive rejection tags atop them that have to be traversed every instance. Gleeanon409 (talk) 13:19, 18 August 2020 (UTC)
Should we deindex all talk pages on Wikipedia from search engines? This comes about a month after a similar (not-RfC) discussion about the potential benefits and drawbacks of deindexing some non-content namespaces. Aasim 17:23, 19 August 2020 (UTC)
To give some context: One day I was browsing my search engine of choice and ended up finding an image that was only included on a talk page. The reason why I am making this proposal is (1) we do not want inaccurate (and potentially libelous) information about a subject (be it person, company, organization, or medical topics) showing up in search results and (2) talk pages provide no help to readers whatsoever [clarification: what I mean is they do not help readers searching for a topic on Google or Bing]. I would see them as causing more confusion (even with the disclaimer) as, and I am going to quote myself here, For these two main reasons, I started this RfC. Aasim 17:29, 19 August 2020 (UTC)
people that check the source of [images on talk pages] will be confused that they see what looks like a weird kind of forum that only some people can comment on instead of the traditional Wikipedia article.
As this is now just targeting namespace:1 ("Talk:") the technical implementation would be by setting
$wgNamespaceRobotPolicies. This can be done with a phabricator request such as in phab:T104797, such a request should include a permanent link to a successful, closed community discussion. — xaosflux Talk 23:27, 19 August 2020 (UTC)
A secondary decision that can be made is if the use of
__INDEX__ should be allowed to purposefully allow indexing on a page-by-page basis (this is an update for
$wmgExemptFromUserRobotsControlExtra) - by default manually tagging for indexing would be allowed, but it can also be forbidden if necessary. Pages manually tagged for indexing will appear in Category:Indexed pages for tracking and review. — xaosflux Talk 23:27, 19 August 2020 (UTC)
On a related note, currently most talk pages of BLP's are noindexed by way of having a template that inlcudes the NOINDEX directive, as can be seen in Category:Noindexed pages. — xaosflux Talk 23:30, 19 August 2020 (UTC)
most talk pages of BLP's are noindexed by way of having a template that inlcudes the NOINDEX directive@Ed6767, Rmhermen, Þjarkur, TheDJ, Teratix, Orangemike, GenQuest, John M Wolfson, DGG, Phil Bridger, and Schazjmd:
impact on users who dislike MediaWiki's search engine and prefer to browse discussion archives through external engines(unless, of course, it entails a legal responsibility on their part, but I digress)
Discussed a bit at where I was encouraged to bring my idea here to see whether there might be community consensus. My idea is that we establish, similar to the thanks functionality, the ability to flag edits for review by other editors. This could be useful in cases where an editor sees a problematic edit but doesn't have the time to address the problem properly, or when an editor sees an edit that they feel is potentially problematic, but they don't have the experience or confidence to know for certain and don't wish to stick their foot in it with an inappropriate revert. Flagged edits could be highlighted in watchlists, and perhaps captured for review in other manners as well. There could also be a mechanism whereby editors could unflag edits that they believed to be comfortably unproblematic.
Beyond tagging other editors' edits for review, this functionality might more easily allow editors to ask others to review their work. I'm unsure how much this might actually be used in such a capacity, but it doesn't seem like a bad idea. As an example, I've sometimes tried to edit tables but haven't been able to get them looking the way I intended. Flagging my edit would be a quick way to get the attention of other editors.
It was suggested at the linked discussion that this could be technically accomplished without significant difficulty thusly: "extend the changetags right to more users (admins + rollbackers?) and create a new tag named "flagged for review"(?)".
There are some obvious potentials for problems here, which were also discussed at the idea lab: for instance, it might be easy enough to harass another editor by flagging their edits, and enabling this functionality might make editors less likely to "push the button" themselves. In the end though, I'm not sure there's a good way to establish whether this enhancement would be abused enough to be a concern without making it available and seeing how it goes.
The display of these topicons is inconsistent--before I entered into an interesting discussion with J Milburn, and the had it on beside their Good Article topicons, while A-classers without the topicon included the one for the Atomic bombings of Hiroshima and Nagasaki.
J Milburn, who is a broom (REBESTALIC IS A TOADY ALERT), mentioned that he was 'not aware of any policy or guideline recommending their inclusion'. Perhaps now would be the time to make such a policy?
As a result of the Wikipedia Pages Wanting Photos campaign running on Meta since July and ending this 31 August, there have been a lot of poor-quality edits by editors who are unfamiliar with the image use policy/MOS and/or just don't care about quality. Some had incorrect image placement, some introduced bad captions, some inserted totally irrelevant images, and some completely broke infoboxes and other templates. Since a lot of the affected articles are of obscure unwatched topics, a coordinated clean-up effort might be needed. Maybe a centralised noticeboard to identify problematic editors and check their contributions? There was earlier discussion at AN but it didn't seem to reach any conclusion. --Paul_012 (talk) 09:27, 28 August 2020 (UTC)
As the name suggests, it would be very beneficial to add the game's rating to the right side information panel.
This could also have the added advantage of linking back to the ratings page (because CERO A, B, C, etc to me is very confusing unless you look at their meanings/age range).
As there are many systems around the world, maybe either a regional setting based on site translation (like UK only seeing PEGI, Germany only seeing USK, etc), and having the .com article contain the main release areas (usually Japan, North America, and Europe). --2600:1702:260:9100:C184:A0D6:6368:8E56 (talk) 05:27, 29 August 2020 (UTC)
In case you do not know, US transactions with TikTok and WeChat will be banned soon. I just watched a video by Vox about how such a ban poses a threat to the open Internet. I was wondering should we black out Wikipedia on the day the site gets banned? We did this in 2012 when Congress was considering SOPA and PIPA. I think raising awareness of this issue may help raise issues about the current threats in the United States to the open Internet.
"But it is Chinese apps getting banned, not Wikipedia!" - firstly, this is in the United States, a country that has for a long time embraced the open Internet and secondly, the Internet landscape across all countries is changing rapidly to embrace censorship and block freedom of speech. If we decide to black out Wikipedia for a second time, how long should we do it, what pages should be blocked (if any), and when should we stop the blackout? We want a free and open Internet. Sure not everyone likes TikTok, but if TikTok is banned in the US, who will be next? Google? Wikipedia? We do not know. And while it may be two Chinese apps, this will have long-lasting effects on how we view the Internet.
I am not making this proposal lightly, I recognize the amount of disruption it may cause to readers, editors, and the like. If this gets turned down, I will completely understand. After all, we are not supposed to promote a cause first, but I think given that we have done so before in 2012 means we could do so again. This may be a case of WP:IAR that we can invoke just this once.
If we were to black out Wikipedia a second time, I would suggest it be blacked out from 16 September to 18 September affecting all mainspace and portal pages except pages related to censorship and the threat the open Internet has. I recognize it may cause a lot of disruption to people accessing online resources, but it gives us what us Wikipedians want: a free and open Internet where we can access content freely and safely. We do not want websites blocked because people use them to or to get revenge for COVID-19; by blocking content, it greatly impacts Freedom of Information.
I do not want this to sound super political, but an open Internet is what us Wikipedians have been fighting for for the past 19 years. We do not want paywalls or government censorship of Internet content; we want the ability to freely access and communicate information when needed. Aasim 09:30, 30 August 2020 (UTC)
I believe that Module:Commons link fulfills most of the goals of the proposal by Mike, while being automatically up-to-date when Commons sitelinks (e.g.) change.
How does the community feel about succession boxes and their inclusion in the articles about US Presidents specifically? The following three options were presented on the talk page above:
I genuinely believe they help navigation between articles, though they could often be trimmed down to avoid trivial items, and if they are too large, they can be collapsed into the Offices and distinctions box. That way if you are looking for them, they are there, but if not they are not taking up a lot of space at the bottom of the article. ScottishNardualElf (talk) 08:55, 1 September 2020 (UTC)
So I've suggested this before but here is my initial visual mock-up. What we know today as "succession boxes" should be flattened out to look roughly like this:
Unrecognized positions such as
Community Organizer (Chicago) would be ignored and impossible for noobs to casually add. Such a system would greatly reduce screen waste, allow tighter control over accuracy, and protect against the random crap that existing succession boxes universally attract. I could probably create it within a few days, if there is interest. ―cobaltcigs 12:11, 1 September 2020 (UTC)
There's a gadget (Special:Preferences#mw-prefsection-gadgets / Appearance / Strike out usernames that have been blocked) which strikes usernames if they've been blocked. It seems (obvious) to me it should do the same for globally locked users. Has this been discussed before? Is there some reason it doesn't, other than it hasn't been implemented yet? -- RoySmith (talk) 13:22, 1 September 2020 (UTC)
On the talk pages of articles, it is often said "The talk page is for discussion of the article in Wikipedia, not for general discussion of the subject". However, if one reads what is said in talk pages, quite often the talk gets to be on the subject more than the article. Apart from abolishing talk pages altogether, which would be quite a radical proposal, should we allow discussion of the subject? Vorbee (talk) 06:05, 4 September 2020 (UTC)
Some users with a conflict of interest or being paid to edit struggle to properly format edit requests. The WP:Edit Request Wizard handles the formatting automatically, and is supposed to encourage proper wording of requests. Should this tool be mentioned in policy and information pages regarding WP:Conflict of interest and paid editing? Specifically, I propose linking to it in these pages: