Wikipedia:Village pump (proposals)

This is an old revision of this page, as edited by at 18:13, 5 September 2020 . The present address (URL) is a permanent link to this revision, which may differ significantly from the .

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)

Some editors have brought forward the argument that our citation styles are difficult to grasp for new editors and that they should not be discouraged from editing because we need new editors, and therefore they should use whatever style they are used to. That's fine with me to a certain degree, however, there is also an argument to be made about existing editors (not) being discouraged from contributing to articles using (distracting to read and non-functional) parenthetical citations:
WP is so well noted for a confusing style of citation and writing, and an obsolete appearance and awkward layout, that anything simple and clear looks like it isn't WP.
It's arguable whether the parenthetical style is "simple and clear" for anyone other than academics. It comes back to the question of whether we write WP for the experts or for the lay readers. Subject experts would probably prefer to see parenthetical referencing. But I'd reckon the majority of readers aren't academics, and haven't come across this style except from a few college papers written all those years ago.
Remember also that deprecation does not mean that it is not allowed, but rather that it is acceptable to change to another citation style. I don't buy that it will make it harder for newcomers to contribute, as newcomer often just use whatever they like, e.g. bare urls or parenthesis. In fact, I think it parenthethical citations make it harder for newcomers to contribute to such articles, because the editor's citation system automatically creates footnotes.
After two leading American researchers claimed to have found independently that water is not actually wet (Jones 1996, García 1997), several Canadians soon responded[fn multiple sources] ... Pérouse (1998) was especially vociferous...
Does that license banning all parenthetical references, or would that be a bit like banning wine from dinner nationwide because a tiny percentage of the population are given to guzzling large amounts of “liquor” at any time? Does the extreme case of Actuary justify banning all parentheticals?
Kent G. Budge, In general, I agree that we should enable readers to consume our content in whatever way is most useful to them. And, indeed, our HTML markup is sufficiently structured that hiding the references is probably one line of added CSS.
And yet, the printed encyclopedias I grew up with did not have footnotes at all. They'd simply identify the contributor for each article, and there was a separate contributors page listing the credentials of each.
This doesn't work for Wikipedia because Wikipedia requires no credentials of its authors. Instead, it requires reliable sources of its authors. I think it follows that the citations are primarily there for authors and editors, not for the reading public. Though I acknowledge it is a truism that serious researchers do not come to Wikipedia for information; they come to it for its lists of sources.
This RfC might be a valid straw poll or consensus-building of what reference style Wikipedia editors prefer, but determining what the readers prefer is a different story. An RfC about citation styles is bound to suffer from large selection bias towards editors who care about such things, therefore, who already have a much higher familiarity with references than the average editor let alone reader.
My understanding of the average Wikipedia reader, based on IRL interactions, is that they do not care about citations and would only check them if a claim looked outlandish. If my sampling was representative, the best solution in terms of readability for the audience would be to hide references from readers, or maybe have a button to toogle them on or off (with default off), and probably let editors use whatever they want in the backstage.
Most people have encountered parenthetical citation styles at some point in their lives.
For instance, many supporters say that Wikipedia footnotes are good usability, or at least better usability than parenthetical. That is how I personally feel as well but is it really the case for the average reader? The only evidence is see, which is highly circumstancial, is that few if any modern websites use linked footnotes, in particular news websites, whose income depends on how readable they are (and whose average reader is probably similar to Wikipedia's). This suggests that footnotes in websites are poor design for some reason. Does the reason apply to Wikipedia though?
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.
Even if "35% of faculty think students have moderate practice using a standard CS" implied "35% of students have moderate practice using a standard CS", that in turn means neither that the majority (51%) of students have practiced a standard CS, nor that said standard was (author, year). My remark about faculty perceptions was intended as a concession that things might be better than faculty perceives (because faculty might expect higher standards of students than what would suffice).
As to the country viewing stats, I admit I am somewhat surprised, but my main point was that even if US page views were 90% of all traffic it would not warrant aligning Wikipedia practices on US practices.
as a new editor who is an academic specialist accustomed to inline parenthetical citations
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.."

Question: what happens to a new editor now who is adding good content on a page using a different citation style than what is in use on a page? --Dirk Beetstra T C 11:31, 3 September 2020 (UTC)

Once again, many thanks to the participants here for your well-considered thoughts and exemplary conduct in this discussion. Seraphimblade Talk to me 18:13, 5 September 2020 (UTC)

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)

I object to the nature of these questions. Each one muddles a principle:
I would like to emphasize that despite the fact that I was invited to this discussion, it didn't influence me. I already had unfinished replies laying around in my drafts folder for more than a week and was just lacking the time to finalize them.
As a general remark I would like to see much more constructive and solution-oriented thinking, assumptions of good faith, and less wikilawyering. It's not good for our communication culture and not for the project.

1. Should the titles in citations be linked, and if so, to what (in other words, what should be in |url=)?

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., |doi=)?

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

Should a bot synchronise short descriptions and Wikidata descriptions? Mike Peel (talk) 21:34, 6 August 2020 (UTC)

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)

It's important to connect this to the bigger picture here. The success of the Wikimedia movement is fundamentally predicated on having enough people to do the work. That's the main reason we delete non-notable pages. Whenever we choose to fork, that literally doubles the amount of work to be done, which when you multiply by 6 million, comes out to a gargantuan cost in editor effort. Thus, preventing forks needs to be one of our highest priorities. Worse, once a fork has been made, re-integrating becomes harder and harder over time. I recognize that there are a lot of challenges to doing so here, both because of the initial reasons for the fork and because of the hurdles from the divergence so far, but at a fundamental level, that is the path we need to be on.
Since they are considered content on Wikpedia, the proper place for them is on Wikipedia, where they can be created and maintained by Wikipedians. If there is no point in duplication, then transclude them to Wikidata. Then they also cannot be vandalised on Wikidata (2 problems solved - not duplicating and more eyes on the content.)

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)

There is a discussion ongoing about migrating some sports team color data from a local Lua module to Wikidata: . –IagoQnsi (talk) 07:35, 11 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)

so your refactoring the subheaders to add the word "infobox" is just confusing the issue.Auto-minimize Draft tags for Visual Editor like we do with cleanup/AfD tags

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)

What needs to take place to make this happen? Gleeanon409 (talk) 12:46, 24 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 (noindex,follow) in $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.

I welcome other editors' opinions on this; thanks for your time! DonIago (talk) 14:31, 25 August 2020 (UTC)

I have edited wikiHow, a separate wiki, and they do just that. But the reason why they can do that is because their community is small enough that it is easy to revert vandals. But on Wikipedia, we have 10-40 edits per second. If all of those edits had to be reviewed before hand, then it would create an unnecessary burden on editors.
I agree that implementing the cleanup template without requiring clarification was a misstep. That said, I don't think the reasons why one might find themselves wanting to use this tag can be easily pigeonholed into existing or possibly new templates; if they could be, I'd be advocating for the creation of a new template right now. :)
As an arbitrary example - I'm reviewing my watchlist, and I see a film article listed on it. The diff shows that an editor has restructured some existing text addressing the film's reception, and added information regarding how great (or terrible!) several well-known film directors considered the film to be. Is this information appropriate for addition to the article? Yes, because they're well-known film directors and their opinions matter. No, because they aren't known for being film critics and their opinions don't deserve more weight than others. Maybe, because it is multiple film directors weighing in on a classic film. I'd like to dig through this, but one of those life circumstances comes up that requires I step away for an unknown duration. There isn't time for me to start a cogent Talk page discussion, and there isn't really an appropriate template that immediately comes to mind. If I can flag the edit, then even if nobody else gets to it anytime soon, it will still be outstanding, and perhaps I myself will see it.
There is some potential for abuse, so we should allow this only for logged in users beyond some threshold, but the threshold should be reasonably low so that many users could use it. It could also be useful to select if the review-tag should be publicly visible or only for personal use, listed in a special internal list for later review (when time allows).
The alternative today is to improve on an edit (ideal, but often not possible due to lack of time), revert it or open a talk page thread, but the later two options often create unnecessary stress and drama for issues that could be solved in much more subtle, relaxed and friendly ways given enough time and man-power to look at an edit.
I imagine adding a predefined list would make this more technically complex, but I'm not sure whether it would be significantly more complex. I'm not sure about a visible comment, as at that point you could pretty much make a dummy edit. Agreed on limiting it to logged-in users. As newer editors are perhaps more likely to rely on this functionality were it available, I concur that a low threshold would be nice as well.
My feeling is that a review-tag should be publicly visible so that other editors can review as well and possibly address the issue...or if they feel there's no issue, untag the edit.

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?

Hey Paul 012, I actually asked a question about this just after I joined Wikipedia! It was at the Teahouse, and the replier directed me to (had to be an external link as I don't know how to make links to category pages). I had a look at it just now, and it was mostly just empty categories. I haven't the faintest clue which category Nina Simone fits into, because I don't suppose she had much to do with military history

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)

Notification of a discussion at Wikipedia talk:Editnotice proposing maintenance cleanup of expired editnotices by blanking, here. ProcrastinatingReader (talk) 14:08, 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)

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.

(BTW, I'm not sure if this should be an RfC or just a straw poll, if anyone thinks it should be a RfC then feel free to add the tags.) Thanks. Mike Peel (talk) 18:17, 30 August 2020 (UTC)

The use of this module is prototyped at Template:Commons/sandbox, with test cases at Template:Commons/testcases

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.

What do other editors think of this? — hike395 (talk) 19:44, 30 August 2020 (UTC)

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)

Considering that the existing boxes are collapsed, I don't think this is really relevant to this discussion (and it feels like a bit of a distracting hijack, to be honest). From what I've seen, the arguments against the boxes are not that they occupy too much screen real estate when temporarily expanded by a reader.(Strike after subsequent discussion.) ―Mandruss  13:35, 1 September 2020 (UTC)

This question should be expanded to include all the US presidential & vice presidential candidate bios. GoodDay (talk) 14:13, 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)

Thank you for your kind and helpful comments. I see this issue is already discussed at Wikipedia: Perennial proposals, under Section 3.4. Vorbee (talk) 07:48, 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: