Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
• Proposed policy changes belong at Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.
• Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

Deindexing talk pages

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.

---

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, 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. For these two main reasons, I started this RfC. Aasim 17:29, 19 August 2020 (UTC)

Should we deindex talk pages?

• Strong oppose - Wikipedia's search tool sucks 99% of the time for specific discussion search. Googling for discussion pages is often far easier and more flexible than MediaWiki's built-in search and accepting this proposal will result in it being much harder for myself and many other editors who use Google and other search engines to find talk pages or other discussions, especially as many might not even be aware of the indexing change. Ed talk! 18:44, 19 August 2020 (UTC)

  Ed6767, I understand that Wikipedia's search may be a little unintuitive to use for searching for a specific discussion. I just voted on an MfD and learned that the page nominated for deletion, before the MfD, was showing up on search results when searching for the subject. See [1]. I do not think this is something that we want readers to see. Aasim 20:43, 19 August 2020 (UTC)

  @Awesome Aasim: To clarify, do you mean (i) that Paul A. Bonacci was showing at Google; (ii) that Talk:Paul A. Bonacci was showing; (iii) that Wikipedia:Miscellany for deletion/Talk:Paul A. Bonacci was showing? --Redrose64 🌹 (talk) 18:33, 20 August 2020 (UTC)

  Redrose64, I just did a search with Google, and sure enough, there is the talk page. Aasim 18:37, 20 August 2020 (UTC)

  @Redrose64: (ii). Regards, Newyorkbrad (talk) 18:43, 20 August 2020 (UTC)

  Per Template:NOINDEX#Warnings, major search engines should respect the {{NOINDEX}} tag, but it may take days or even weeks for content already indexed to be removed from them. In this case, the tag was added less than 24 hours ago. Ideally, that talk page should have been tagged with {{WikiProject Biography|living=yes}} several years ago. --Redrose64 🌹 (talk) 19:48, 20 August 2020 (UTC)

• I disagree with the assertion that talk pages provide no help to readers whatsoever (emphasis in original). Stricken following clarification that talk pages provide no help to readers seeking information on a topic via external search engines. 22:03, 19 August 2020 (UTC) As a reader, I'll typically check an article's talk page if I see certain maintenance tags, principally NPOV. And before I started editing, I would sometimes go to the talk page to ask questions as an ip to seek clarity on confusing language, for example. I'm not sure if that second use case disqualifies my experience as the question I asked would technically make me an editor rather than a reader, but I've definitely found benefit in checking out prior discussions about a topic I'm unfamiliar with, even if I have no intention of ever editing the page.

No comment on the proposal itself, but User:Awesome Aasim do you think you could courtesy ping the other ten editors involved in the prior discussion you started on this page archived less than a month ago? I may be mistaken but I believe that's standard practice for RFC proposers. <3 Folly Mox (talk) 20:22, 19 August 2020 (UTC)

Folly Mox, Okay. @Ed6767, Rmhermen, Þjarkur, TheDJ, Teratix, Orangemike, GenQuest, John M Wolfson, DGG, Phil Bridger, and Schazjmd: courtesy ping. Aasim 20:31, 19 August 2020 (UTC)

Folly Mox, to clarify about the "no help" part: talk pages are really only beneficial to editors seeking to improve the article. Many readers do not seek out talk pages for sources of information. They are not going to help readers searching for a topic. I should have made that clearer in the context of the RfC. Aasim 20:33, 19 August 2020 (UTC)

I added that clarification in the "context". Aasim 20:54, 19 August 2020 (UTC)

• Concur - the garbage content on talk pages is much higher, and stuff we would never allow to remain in an article can just lie there on a talk page, like the proverbial "t**d in a punchbowl", ready to be stumbled on by an unsophisticated seeker of information. --Orange Mike | Talk 21:08, 19 August 2020 (UTC)
• ? Awesome Aasim the "Talk:" namespace is pretty easy to identify in your proposal, but as far as "other discussion" - how are you defining these? For example are you also proposing that the entire village pump not be indexable? — xaosflux ^Talk 22:47, 19 August 2020 (UTC)

Xaosflux Hmmm... for now, let's just do talk pages I guess. I'll update the header and question to clarify that. Aasim 23:26, 19 August 2020 (UTC)

Xaosflux Aasim 23:27, 19 August 2020 (UTC)

• Support not appropriate for Google, and I think the assertion that the internal system is "too hard", etc., is nonsense; many discussion venues (such as the Village Pumps and Administrators' noticeboards, etc.) have an archive search tool, and for the rest there's Special:PrefixIndex. Anyone who unfortunately falls through those cracks can, ultimately, just "deal with it", to be blunt. – John M Wolfson (talk • contribs) 23:01, 19 August 2020 (UTC)
• Support for talk pages per previous discussion. Oppose anything beyond that for now. — Wug·a·po·des​ 23:09, 19 August 2020 (UTC)
• Support honestly astonished that those were indexed to begin with. Headbomb {t · c · p · b} 23:14, 19 August 2020 (UTC)
• Support, also for all *_talk: namespaces. I'm also surprised that these pages are indexed. Although publicly available, they correspond to behind-the-scenes discussions which most websites would keep private and which retain material that we would quickly purge from articles. Readers almost always seek an article and don't want to be diverted to discussion on how it was made. Certes (talk) 00:43, 20 August 2020 (UTC)
• Support - somehow thought this was the case already. I know userspace isn't indexed, but in general I don't think there's a need to index talk namespaces by default (but there might be a good case for exceptions on a case-by-case basis). — Rhododendrites ^talk \\ 01:32, 20 August 2020 (UTC)
• Oppose (from previous discussion): I think the negative effects of indexing talk pages are too slight to justify changing the usual practice ... I would expect users who come across talk pages in their search results will grasp their nature as discussion hubs, given the clear prefix in their titles, and adjust expectations of their content accordingly. The problem is when search engines present talk pages' content misleadingly, as in Aasim's Bing search. Bing, unlike Google, does not give an image's domain without a mouseover, and even then it ambiguously gives the chart's source as "Wikipedia" (you have to click through to see it's from a talk page). That is their responsibility to fix, not ours. If the chart's source was presented unambiguously, there wouldn't be a problem. – Teratix ₵ 03:14, 20 August 2020 (UTC)

Another issue was the potentially negative impact on users who dislike MediaWiki's search engine and prefer to browse discussion archives through external engines, which, as Ed6767's comment suggests, is not an uncommon practice. – Teratix ₵ 03:19, 20 August 2020 (UTC)

Teratix it will not do to say that [it is Bing's] responsibility to fix, not ours. That something might not be our responsibility does not make it any less our problem, especially if Bing does nothing about it. We can't control what Bing does but we can control what we do. Your other arguments are sound (even if I don't agree with them, see above), but I just wanted to note and rebut that particular point. – John M Wolfson (talk • contribs) 03:57, 20 August 2020 (UTC)

Do we know for sure that Bing won't do anything about the problem if someone asked? – Teratix ₵ 02:10, 21 August 2020 (UTC)

They may or may not, but that's beside the point that we shouldn't reject an otherwise good proposal based solely or even partially on what other websites "should" or "should not" do with our pages (unless, of course, it entails a legal responsibility on their part, but I digress). – John M Wolfson (talk • contribs) 03:08, 21 August 2020 (UTC)

I don't believe it is an "otherwise good proposal"; it would have serious negative impacts on editors who prefer to use external search engines to browse discussions, as several have attested. – Teratix ₵ 03:20, 21 August 2020 (UTC)

• Oppose People searching on Google should be aware of the context in which information is present. As noted under the technical notes section, talk pages of BLPs are already noindexed. Also, most internal pages that we don't want to be indexed such as all deletion discussions, copyright investigations, etc are already being noindexed. There's no need to apply a blanket noindexing on all talk. Google is a much more sophisticated search engine than what we have internally - if you remember someone having said something on a discussion page but can't recall the exact wording, Google search is more likely to yield the correct result than internal search. The internal search is good only for exact strings. SD0001 (talk) 03:25, 20 August 2020 (UTC)

  SD0001, I just did a check on Bing to see if Donald Trump's talk page is indexed. I discovered that only the talk page of Donald Trump is deindexed; all of the archives are indexed, which still poses a problem regarding BLPs as potentially defamatory content should not show up on any search engine rank. Something that deindexing pages in the Talk: namespace could fix. Aasim 07:24, 20 August 2020 (UTC)

  The solution to that would be to have the archiving bots apply noindexing when creating archives of a noindexed talk page. SD0001 (talk) 07:52, 20 August 2020 (UTC)

  That would kinda work if we did not have 1000000+ BLPs (and many more archives). If we had fewer archives, this would definitely be a practical solution. Adding __NOINDEX__ to the millions of archives we had (or to {{talkarchive}}) would unnecessarily waste a lot of server resources, and it would take time for the search engines to stop deindexing the millions of archives. Plus, like I mentioned above, we have libelous content on talk pages of non-BLPs and it would be impractical to try and suppress each of this libelous content. Turning off talk page indexing makes this content part of the deep and dark web. I know it may inconvenience us editors trying to find archives, but this is really just the less than 1% of all readers that go through archives. For editors it may be something to get used to, but readers could probably care less as many of them don't look at talk pages anyway. (I did not learn about the various namespaces and maintenance pages until I just happened to stumble on pages in each of those namespaces.) Aasim 15:09, 27 August 2020 (UTC)

  Adding __NOINDEX__ to the millions of archives

  There aren't millions of archives. The vaast majority of the million+ BLP articles don't have any talk archives at all.

  ... would unnecessarily waste a lot of server resources, and it would take time for the search engines to stop deindexing the millions of archives

  It would take the same time for search engines to stop indexing regardless of what method we use. As for server resources, that isn't much of a concern for us. The WMF gets millions of dollars in donations and have enough resources -- it's silly to employ a poorer solution at our end just for the sake of server resources.

  Plus, like I mentioned above, we have libelous content on talk pages of non-BLPs and it would be impractical to try and [[WP:OVER|suppress]] each of this libelous content.

  Why suppress? Simply removing will cause noindexing. It the material is that libelous, it has to be revdeled/suppressed anyway, regardless of whether the page is indexed. SD0001 (talk) 08:29, 29 August 2020 (UTC)

  Ran some numbers: turns out there exist just 13494 talk archives of BLPs. That's pretty trivial to noindex using a bot. SD0001 (talk) 16:04, 30 August 2020 (UTC)

• Support per above. Also surprised this wasn't already the case. I can imagine your average Joe reader reacting with either disinterest or frustration when the contents of the page they were expecting to see does not match up with the contents of the page they're actually seeing. Net negative at best. -FASTILY 07:45, 20 August 2020 (UTC)
• Strong oppose our talk pages are a valuable part of what makes Wikipedia unique. We should not be hiding it. —TheDJ (talk • contribs) 08:00, 20 August 2020 (UTC)
• Support contra what TheDJ says above, our talk pages are too often at best embarassing and at time verging on the libelous, with doxing and sometimes unacceptable insults. I can point to at least one talk page which consists only of insults and rants. Our internal engine does work. Leaving defamatory content open to the public is IMHO unacceptable. Doug Weller talk 08:53, 20 August 2020 (UTC)
• Strong oppose - I don't agree that talk pages aren't useful as a search result, both for readers and editors. Benjamin (talk) 09:55, 20 August 2020 (UTC)
• Oppose When a reader lands on a talk page by accident, they will quickly see that it's not a normal Wikipedia article, as posts are signed, there are people replying to each other, &c. I think we can trust the reader to understand that it's a discussion page. If they were just looking for the article, there's a link at the top, which I think they will quickly find. Furthermore, as xaosflux pointed out, the template "BLP" contains __NOINDEX__, so libel is not really a concern. Talk page discussions can be pretty interesting, so I do think reader value would be lost if we deindex the entire Talk: namespace. PJvanMill)talk( 11:26, 20 August 2020 (UTC)
• Oppose Search engines already employ sophisticated algorithms to help their users find what they want. Our talk pages are public and open to all, rather than being private and privileged. It may be that they are exactly what the searcher is looking for. We should leave such decisions to searchers and the providers rather than second-guessing them and pre-emptively censoring everything. If there's a problem, it's that our talk pages are too little understood and used. This proposal would make matters worse. Andrew🐉(talk) 13:50, 20 August 2020 (UTC)
• Support Talk pages may be interesting but they are not the Wikipedia Content. The articles are the content, all the rest exists to support the process of making the content. — GhostInTheMachine ^{talk to me} 15:17, 20 August 2020 (UTC)
• Oppose Talk pages are hidden enough, but are a fundamental part of Wikipedia. I don't think they should be hidden further, it's better just to remove problematic content as you see it then to implement this blanket proposal. Thanks. Mike Peel (talk) 16:09, 20 August 2020 (UTC)
• Support While I get the "our search is insufficient" arguments (though I don't necessarily agree with them), I think about the number of BLP violations brought to talk pages in order to demean article subjects and then the idea of them showing up in search results? That makes my skin crawl.--Jorm (talk) 18:38, 20 August 2020 (UTC)
• Comment - Special:PermaLink/862856598#Prevent new users from allowing search engine indexing of user pages caused spam in userspace to halve overnight. I am not aware of any systematic spamming in the talk namespace. MER-C 19:08, 20 August 2020 (UTC)
• Oppose until such time that the MediaWiki search engine is significantly improved. 207.161.86.162 (talk) 22:36, 20 August 2020 (UTC)
• Support Talk pages could confuse readers. Depending on a user's search, the search engine might pull up a talk page (no search engine is perfect). P,TO 19104 (talk) (contribs) 23:03, 20 August 2020 (UTC)
• Strategic support, with my actual !vote being an abstention because I'm not an expert on search engine results and thus feel WP:UNQUALIFIED to weigh in on the all the potential ramifications of this. But from the !votes above, I'm concerned that some editors are prioritizing their own desire to be able to search for pages on Google rather than putting the WP:READER first, so that pushes me into a strategic support to counterbalance. I find the support arguments above that talk pages are not part of the encyclopedia proper (as ill-defined a concept as that is at WP) and thus should not generally be appearing in Google search results persuasive. {{u|Sdkb}} ^talk 02:39, 21 August 2020 (UTC)

How does talk page indexing hurt the reader, and why should only pages part of the "encyclopedia proper" be indexed? – Teratix ₵ 03:20, 21 August 2020 (UTC)

Teratix, plenty of the support !votes here have made arguments as to why that would be, and why we wouldn't want internal pages appearing in Google results. I expand on my views about reader-facing vs. non-reader facing parts of Wikipedia here—part of what it boils down to is that we need to be able to distinguish between the product we work to create (an encyclopedia) and the efforts that go into creating that product. Going back to WP:Reader, the view I hold most strongly here is just that it's not appropriate to be !voting taking into account only or primarily our own desires to be able to find the internal pages that heavily concern us but don't 99% of Wikipedia's users, since we're not making Wikipedia just for ourselves but for the world. At least some people above very clearly seem to be centering their own needs rather than readers', thus my !vote. {{u|Sdkb}} ^talk 00:24, 22 August 2020 (UTC)

From what I've seen so far, supporting arguments boil down to vaguely waving at the possibility of reader confusion and the possible presentation of libel and misleading information. However, they have not presented any evidence that this is a significant problem, beyond a couple of isolated instances. The "reader-facing" and "non-reader facing" distinction is an interesting point (though I would dispute that talk pages would be non-reader facing), but merely invites another question – why should non-reader facing pages be deindexed? Finally, it's a bit disingenuous to assume opposers are only taking into account their own experiences. Perhaps they have merely found that whether or not talk pages are indexed has little impact on readers' experiences, and so have not included this consideration in their comments. – Teratix ₵ 02:06, 23 August 2020 (UTC)

I don't think the BLP concerns here are insignificant or restricted to isolated instances. We routinely have discussions on BLP talk pages over whether to include or exclude sensitive information that may affect privacy. We are a top ten website in the world, so anything we publish here, even on our talk pages, has the potential to expose the content to significantly more people than if we hadn't published it. Take Talk:2020 Twitter bitcoin scam#Premptive caution, which is a discussion that happened just a few weeks ago over whether we should name a 17-year-old who has been accused of committing a notable cybercrime. In the discussion right now, someone has pasted a link to the website of an obscure state county court with instructions on how to access court records. Yes, the information is technically public, but we have increased the exposure of the information by including it here (and it would be a violation of WP:BLPPRIMARY to depend on court records as the sole source for any BLP content). In other words, we are too lenient about what we tolerate on talk pages in routine discussions to make it a good idea for talk pages to be indexed. Mz7 (talk) 06:17, 23 August 2020 (UTC)

Since the link was posted on 1 August, the article has been viewed about 30,000 times, but the talk page has been only viewed 181 times. I'd say not everyone who viewed the talk page actually clicked the link (quite a few viewers are likely just there for editing purposes); the number of people who visited the talk page, scrolled to the bottom, clicked the link, actually searched for the record and would not have otherwise had the desire and ability to find it would be few to none. (And the amount who found it because the talk page was listed in search results would be even smaller) – Teratix ₵ 04:54, 24 August 2020 (UTC)

• Support, and I'm also surprised this isn't the status quo. We are quite a bit more lenient with the kind of information we allow to stay on talk pages versus in the mainspace, particularly with respect to WP:BLP content. For example, we might use the talk page to discuss whether certain borderline information constitutes a BLP violation (e.g. victim names, crime allegations, full names and dates of birth, etc.), and even if the consensus is to omit the content from the article, in general the content remains visible on the talk page, which is problematic if readers can happen upon it via a Google search. The alternative would have to be to more liberally apply courtesy blanking to such discussions, which isn't routinely done today. I find the argument about MediaWiki's search function unconvincing; we can certainly live without Google search for talk page archives, especially at the benefit of reducing the probability that a reader will stumble across content that is not intended to be reader-facing. Mz7 (talk) 05:32, 21 August 2020 (UTC)
• Support: Talk pages are internal discussions for the intended public-facing article namespace. There's an awful lot of inappropriate content contained in Talk space that has no need for beingindexed on external search engines. One also can't expect all users of search engines to understand how Wikipedia works and that the Talk pages can contain user-generated nonsense that would otherwise violate Wikipedia policies in articles. — MarkH₂₁^talk 06:21, 21 August 2020 (UTC)
• Support: Wikipedia:Administration..." administrative namespaces are used to assist the building of content and should be seen to be mutually exclusive of content pages, except for cases where a linkage is required. In other words, administration pages should be in the background and not visible to the reader."--Moxy 🍁 10:11, 21 August 2020 (UTC)
• Oppose, because talk pages are a very important part of our processes and shed light on our content. Everyone gets dumber if they get ignored. Nemo 11:08, 21 August 2020 (UTC)
• Oppose I can't speak for other users, however I use a search engine (Google, in my case) to find talk pages. The search engine is just much more effective than Wikipedia's search bar, and I would have a lot of difficulty finding discussions if they weren't indexed. However, I recognize that this discussion is about the WP:READERs, not the users. As far as that is concerned, I don't really see the harm of keeping them indexed. Anyone is free to view the behind the scenes work that goes into each article, and I think it gives Wikipedia more credibility when people are exposed to the endless discussions that have helped build and maintain the articles that they read. The OP mentioned that readers may be confused by the talk pages that they encounter in search engine results. This may be true (and I'm not convinced that it is), but it is irrelevant. Not knowing what the talk page is doesn't make it any more difficult to read articles that they encounter. It just means that they'll click the link, see it isn't a regular article, and leave. It doesn't hinder the experience of someone that went straight to an article from the search engine results. --Puzzledvegetable^{Is it teatime already?} 13:29, 21 August 2020 (UTC)
• Support. I agree that the internal search engine is terrible. But Wikipedia is in the real world. The targets of libel don't care about our ability to find old talk page discussions. Yes, most BLP talk pages are noindexed, but the archives aren't, and libel can occur on non-BLP talk pages, too. Suffusion of Yellow (talk) 20:41, 21 August 2020 (UTC)
• Support I think many people here assume too much of the casual reader. When people look up Paul A. Bonacci and click on the link (as two thousand have done in the last 30 days) and find as the first sentence is "This is a real case. Paul is a real person. This case needs to he heard, it is the 1st pizzagate. If you find yourself here, don't stop...keep digging, it's all there" Wikipedia itself is essentially spreading misinformation; our reputation as a trusted source is hurt every time this happens even though a select few readers may accurately surmise the purpose of the page. Our goal is give the public access to the world's knowledge, not to give editors a marginally more convenient searching tool for the talk namespace, and most certainly not to actively mislead them by linking to pages that are not part of the encyclopedia with content that is presented in a somewhat similar format to an article that violates all of Wikipedia's pillars. For the reader's sake, talk pages should not show up on google. Zoozaz1 (talk) 03:39, 22 August 2020 (UTC)
• Oppose. Andrew Davidson hits the nail on the head with: If there's a problem, it's that our talk pages are too little understood and used. I'm not convinced like some of the opposers that a reader stumbling across a talk page will immediately understand what they're looking at. Our methods of discussion threading are now 20 years behind the times. But it should be easier and more common for a reader to find themselves on pages that are not articles. Someone finding a talk page could be a gateway to them learning more about what Wikipedia is and how it works. Readers should not believe that they are looking at a website of factual content that magically appears or has existed for all time, but an unfinished, imperfect work with a provenance that is constructed over time by collaboration and communication. Every editor is already a reader, but every reader should be an editor (if only in the sense that they know how to correct a typo or remove vandalism or falsehoods if they see it). — Bilorv (talk) 20:02, 22 August 2020 (UTC)
  • Bilorv, I agree that we are kind of behind in terms of talk pages and usability. I also agree that a reader that wants to know how Wikipedia works can view talk pages. It is important to remember that no page on Wikipedia is entirely private; we do have a few private wikis and the MediaWiki software does allow for hiding of pages, but none of those features are enabled on the English Wikipedia. Readers can still view discussion pages by clicking on the "Talk" or "Discussion" links at the top of every page. But even then, most readers are not super interested in how Wikipedia runs. And if they are, they can view our policies, guidelines, etc. and our tutorials themselves and/or try to make edits themselves (and get guidance). But most readers searching for topics on Google or Bing are not looking for talk pages, though. Aasim 08:53, 23 August 2020 (UTC)
• Support The mainspace itself has its fair share of defamatory bias and POV commentary, but talkpages have even less control. And there are millions of them. Junkyards have a fence for a reason. --Pudeo (talk) 23:44, 22 August 2020 (UTC)
• Support I remember once reporting a BLP concern and one reason (there were others) not to remove it was that it was on the talk page. We let more slide in this space than on others. If an editor is looking up an article on google they are looking for the article on google, not the behind the scenes process that led to that article being made. While we should not hide how we make the sausage, we don't need to send people looking for a butcher into the meat works. AIRcorn (talk) 02:22, 23 August 2020 (UTC)
• Strong SUPPORT: The reader doesn't need to see how the sausage is made. Active editors know how to find the "talk" info they seek. GenQuest ^{"Talk to Me"} 16:59, 24 August 2020 (UTC)
• Support' The process of how articles are improved is internal to the project, and, while public, should not be advertised to search engines more than necessary. Strangely enough, I can't remember having received talk page hits searching Google until recently, so I was living under the impression this would be the default already. --Matthiaspaul (talk) 18:45, 24 August 2020 (UTC)
• Strong oppose - it is better to find things than to hide things. EllenCT (talk) 01:37, 25 August 2020 (UTC)
• Oppose They're already not ranked very highly, and it's useful for people who want to be able to search them in particular with a better search engine than ours. Jackmcbarn (talk) 05:58, 26 August 2020 (UTC)
• Mostly ambivalent, but on balance oppose per Jack. Really the argument in support is that talk pages are not helpful to readers and may contain completely false content (which is true), but indeed, they're not indexed very highly and the typical reader is unlikely to stumble across them by accident. There is a reason to keep them indexed, however, and that is (to be frank): MediaWiki's search can suck. ProcrastinatingReader (talk) 20:36, 26 August 2020 (UTC)
• I'd support this if there was a reliable alternative way to find talk page consensuses, but there isn't so I've got to oppose it.—S Marshall T/C 13:01, 27 August 2020 (UTC)
• Support If people want to see why we put something, then the talk page isn't difficult to find. However, I don't want server resources to be heavily wasted on this; I don't know much about computing but if it possible to set a limit on how much RAM(?) it is using to not slow down the website, that would be optimal. ping me when responding, gràcies! TheKaloo talk 23:35, 27 August 2020 (UTC)
• Oppose per others above who have pointed out that external search engines are often critical for editors trying to identify old discussions. --Paul_012 (talk) 09:43, 28 August 2020 (UTC)
• Oppose I think our readers are quite interested in the process of how articles are written. Comments on Talk:Kamala Harris made the news just two weeks ago, and that's only one of many articles on how Wikipedia handles current events which extensively cites talk page discussions (see [2] [3] [4] for a few more recent examples]). xkcd has done multiple comics satirizing talk pages. Making it harder to find talk page discussions and see how an article's content was formed makes Wikipedia less transparent and does our readers a disservice. TheCatalyst31 ^{Reaction•Creation} 15:20, 29 August 2020 (UTC)

  I disagree. It is still possible to find talk page discussions by clicking on "Talk". Those that want to find talk pages can still use the extremely rudimentary "MediaWiki" search, which is pretty dated compared to modern search engines, but still usable. And as mentioned above, Talk:Kamala Harris is already deindexed. That means that major news publications like The Atlantic had to use MediaWiki's search anyway. Aasim 19:24, 29 August 2020 (UTC)

• Support Talk pages are part of the internal discussion process, which is not, I believe, what readers are looking for. They are also more prone to abuse. While patrolling recently created talk pages without an associated article, I have seen several talk pages being used to create spam and attack pages to avoid detection, sometimes after the associated article got deleted and salted. These pages were then, as expected, still ranked highly in search results. - Flori4nK ^{t • c} 22:00, 29 August 2020 (UTC)
• Support Talk pages are part of Wikipedia's internal discussion process and hence it would be better if they are deindexed.Pharaoh of the Wizards (talk) 04:03, 1 September 2020 (UTC)
• Oppose On balance, moving in the direction of less transparency seems bad to me. Running a bot to add a NOINDEX to all BLP Talk pages and their archives sounds pretty trivial, and that would adequately cover the privacy/libel concerns, in my view. Old archives slipping through and remaining indexed, an incident mentioned above, is a reason to tag more thoroughly, not to de-index the whole space. XOR'easter (talk) 18:47, 1 September 2020 (UTC)
• Opposes general deindexing. Support BLP deindexing as a compromise. Complete deindexing reduces usability for editors, as the media wiki search is very poor. pburka (talk) 20:04, 1 September 2020 (UTC)
• Support as content in talk pages could include false information, copyright violations, and all kinds of other content that is part of the sausage making of an open encyclopedia, but not the vetted content itself. People certainly can still find this information via WP's interface, but we don't need to promote it externally. --ZimZalaBim ^talk 00:27, 3 September 2020 (UTC)
• Support, content in talk pages is not usable to search engine visitors, as described above. We should be trying to keep random people away from talk pages as a matter of privacy. Swordman97 ^{talk to me} 05:35, 3 September 2020 (UTC)

As a sidenote, deindexing talk pages will not lead to "less transparency". Talk pages are one of the first things you learn about when you become an editor, so it isn't that hard to find them at all. Swordman97 ^{talk to me} 05:40, 3 September 2020 (UTC)

• Support. Users who are interested in the discussion are going to find the talk pages. The content of talk pages is for internal consumption and does not need to show up in search results. And the OP's comment on the sort of harmful content that might appear on talk pages is significant. If the problem is that the internal search engine is crap, then we should improve the internal search engine. Kahastok talk 20:40, 3 September 2020 (UTC)
• Oppose Wikipedia's search function is fairly terrible for "fuzzy" searches, and makes searching anything other than articles onerous and unintuitive. I have often had to use Google to find a talk page discussion that I couldn't find with Wikipedia's search tools. --Ahecht (TALK
  PAGE) 14:17, 4 September 2020 (UTC)
• Oppose, we should keep as much searchable as possible. While MediaWiki search has improved a lot in the past 10 years, there is too little gain from this proposal for the inconvenience to editors that it adds. If necessary, use targeted deindexing. —Kusma (t·c) 09:54, 8 September 2020 (UTC)
• Support – Talk pages contain many serious violations of BLP that are left unchecked and unverified. Allowing a page like Talk:Ilhan Omar to be indexed is irresponsible on our part. All talk spaces should be deindexed. This issue is not limited to pages that are themselves BLP. All talk pages are vulnerable to this BL issue and COPYVIO issues. --- C&C (Coffeeandcrumbs) 05:43, 10 September 2020 (UTC)
  • @Coffeeandcrumbs: In fact, Talk:Ilhan Omar was already noindexed in the first revision of August 2016. If it shows up somewhere it is because a search engine is not respecting noindex, or it is mirrored on a site that does not noindex. --Dirk Beetstra ^{T C} 14:07, 10 September 2020 (UTC)
• Oppose - the material needs to be searchable. That there are serious violations on the talkpages of BLPs, copyright violations, or other harmful content is a red herring: it is there anyway, whether or not people find it on Google. If it is a problem it simply needs to be removed and possibly even revdelled/oversighted. --Dirk Beetstra ^{T C} 13:55, 10 September 2020 (UTC)
• Oppose as a solution looking for a problem per Beetstra. OhKayeSierra (talk) 12:51, 11 September 2020 (UTC)
• Oppose for reasons expressed elsewhere by Andrew Davidson, Jackmcbarn, Nemo, and especially ProcrastinatingReader - namely, that the reality is that talk pages are already ranked pretty low in the vast majority of search results, and you often need to be deliberately looking for them in order to show up at all. The question of which page to direct searchers to is one for the search engines, who have pretty sophisticated methods for determining this, not us simply because we don't feel it's our best work. Many here are comparing the talk pages to an outdated, niche forum, which isn't entirely inaccurate. But the reality is that there are plenty of times when I've been using a search engine and wanted to find information others have posted on forums. Search engines don't exist just to point users to articlespace-quality results, and we should let the decision of what to look for lie with the users and the search engines, rather than decide for them. They're generally doing a fine job not giving too much prominence to talkspace anyway. (This discussion has served to bring up a good concern about BLP archives however, which I would support using a bot to automatically noindex given the additional special considerations there.) MarginalCost (talk) 04:20, 17 September 2020 (UTC)

Discussion (Deindexing talk pages)

For one thing, I see that those that support deindexing talk pages seem to suggest that the Talk: namespace is not part of the encyclopedia proper and is often littered with inaccurate, defamatory material. For another thing, those that oppose seem to suggest that the MediaWiki search engine is poor compared to Google and Bing. Is there a way where we can figure out a solution that keeps talk pages hidden for readers but visible to those who are looking for them? Aasim 03:53, 9 September 2020 (UTC)

Is there a way someone could find it only if they use site-specific searching? Meaning that they write site:en.wikipedia.org as part of the search. El Millo (talk) 04:03, 9 September 2020 (UTC)

That is what I am wondering. If there is a way to make talk pages hidden when doing a generic search (like "cars") and visible when doing a specific search (like "site:en.wikipedia.org cars"), that would be great. Aasim 04:16, 9 September 2020 (UTC)

That's already what happens in practice. The main namespace has most pagerank etc. The fact that you can find a page in an external search engine when looking carefully for it doesn't mean that it would be normally displayed in search results. Deindexing seems to be a solution in search of a problem, until someone shows statistics of the real impressions and clicks of said pages in search engines. Nemo 18:40, 9 September 2020 (UTC)

I found Bing's search result removal policy: [5] According to them they will remove search results either from legal requests or through content control systems. Maybe read the page; do talk pages contain any of the following: copyright infringement, spam, sensitive personal information? The answer: it can have any of three at once.

Google says that it would be best to Contact the owner of the website to have personal information or copyright violations removed from the site. Basically, Google is putting the onus on us to make sure that our pages do not have bad content. Just putting the information out there. I am not sure about how likely this RFC is going to pass because there does not seem to be any consensus for or against. But hopefully we can work out a compromise that works for both readers and editors alike. Aasim 19:44, 15 September 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.

Succession boxes for US Presidents

Following on from the discussion started here:

Talk:Donald Trump#What happened to the succession boxes?

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:

1. The succession boxes should be included in all U.S. presidents' BLPs.
2. The succession boxes should be omitted from all U.S. presidents' BLPs.
3. One size does not fit all. Cross-article consistency is less important than flexibility. Decide on a case-by-case basis at article level.

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)

• 2 - The information therein is somewhat redundant with the Preceded by and Succeeded by fields of {{Infobox officeholder}}, while far less visible and accessible being at the bottom of the article. What little anecdotal evidence we have (from editors who used to be only readers) suggests that readers rarely or never use the succession boxes. At Donald Trump, the boxes were removed after brief discussion in December 2018, and the only arguments in opposition to that have been that U.S. presidents' BLPs must be consistent. No one has even attempted to make the case that the boxes actually benefit readers enough to justify the space required, and I feel that would be a very difficult case to make. Ok, so let's make U.S. presidents' BLPs consistent. ―Mandruss ☎ 09:26, 1 September 2020 (UTC)
• 2 - succession boxes are such an outdated navigation tool on en.wiki. We have as Mandruss pointed above, the relevant fields in the infobox, but also navigation templates such as {{US Presidents}} which already show the entire list. Succession boxes just add clutter as they are much more larger and offer no additional value. --Gonnym (talk) 10:28, 1 September 2020 (UTC)
• 1 or 2 - but this should include all the US presidential & vice presidential nominees bios. GoodDay (talk) 14:16, 1 September 2020 (UTC)
• 2 seem pretty redundant/useless now. We show the same information in better ways in articles. Showing succession for the Nobel Peace Prize (ref Obama) is not helpful. Succession for major office posts is already shown in infobox. I support broader removal from all such articles. Also noting that cobaltcigs's mockup below is a significant improvement, and in any case the boxes should be updated to that if kept. ProcrastinatingReader (talk) 13:50, 6 September 2020 (UTC)
• 2 I think succession boxes in general have had their day. The infobox is much more useful, because it puts the short summary of the individaul write at the top of the article. If an individaul has a lot of offices that wouldd make the infobox too long, it's always possible to put some of the offices in a collapsed format, as is done with the infobox for John A. Macdonald. --Mr Serjeant Buzfuz (talk) 17:32, 7 September 2020 (UTC)
• 1 – Succession boxes remain useful for cases where the inclusion of an office in the infobox of a given article wouldn't meet MOS:INFOBOXPURPOSE. For example, in the Canadian context, it's not uncommon for there to be "secondary" ministerial titles that are typically held alongside a more significant portfolio, such as Minister responsible for La Francophonie. Despite being a significant office, it simply wouldn't be important enough to include in the infobox in most cases. 207.161.86.162 (talk) 05:38, 15 September 2020 (UTC)
• 1 Not sure where you're getting "anecdotal evidence" from. I use them all the time for navigation. Perhaps among the most useful things on a page, particularly if a person has held multiple offices or secondary titles over their lifetime. The infobox at the top is not always the clearest nor complete, and sometimes troublesome to scroll all the way back up there if you're already at the bottom. Walrasiad (talk) 07:41, 17 September 2020 (UTC)
• 1 I've found them very useful for navigating articles. PaleAqua (talk) 18:08, 5 October 2020 (UTC)

Flatten your succession boxes and/or abs

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:

Ideally the template would also read each row's data (names, order, dates, annotations, whatever) by looking up {{PAGENAME}} on centralized lists (titled e.g. Module:Succession/President of the United States) and format the lookup results accordingly. So the calling syntax might be reduced to something like this (with various shorthand abbreviations allowed):

{{succession navbox|Illinois Senate|United States Senate|President of the United States}}

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. There is no reason to believe that this would be more needed or used than the existing boxes. ―Mandruss ☎ 12:38, 1 September 2020 (UTC) (Strike after subsequent discussion.) ―Mandruss ☎ 13:35, 1 September 2020 (UTC)

Perhaps User:Gonnym would clarify Succession boxes just add clutter as they are much more larger in light of the fact that they are collapsed, but my reference to the space required was about other types of space: File size, post-expand include size, space in the edit window, and even the screen space required for the collapse bar. If the boxes are rarely used, even those relatively minor things are unjustified. Massive unnecessary clutter is usually a gradual accumulation of relatively minor things just like this – "hey, one more collapse bar won't hurt" – and we can only address them one at a time. ―Mandruss ☎ 13:03, 1 September 2020 (UTC)

A template shouldn't be huge even when expended if it doesn't need to. Compare the size of the succession section (Offices and distinctions) to Template:Barack Obama. Look at how much link data the navbox has compared to the succession one and yet the succession one is much larger and duplicates information presented elsewhere in the article, including right next to it with {{US Presidents}}. --Gonnym (talk) 13:17, 1 September 2020 (UTC)

@Gonnym: In that case, cobaltcigs's proposal would appear to address at least some of your concerns. Would you support it as a solution, then? ―Mandruss ☎ 13:23, 1 September 2020 (UTC)

No, not really. It is better than the current succession templates, but it's still not needed as it's still duplicating data right next to it. Using the above example, it's duplicating {{US Presidents}} and {{United States senators from Illinois}} with the 13th District seat seemingly not being important enough to warrant a navigation template. And again, all 3 are the first pieces of information right after his image in the infobox. --Gonnym (talk) 13:30, 1 September 2020 (UTC)

Fair enough - I am still learning the ropes here. ScottishNardualElf (talk) 22:25, 1 September 2020 (UTC)

@ScottishNardualElf: You might get more attention on this topic, if you make this discussion an RFC. GoodDay (talk) 15:33, 3 September 2020 (UTC)

So this proposal was actually intended as a compromise between the status quo and my (unpopular, I thought) personal opinion that totally getting rid of succession boxes would be better. Support for the latter seems higher than predicted, which is good. As long as we whack the {{portal bar}}s next. ―cobaltcigs 22:18, 10 September 2020 (UTC)

@Cobaltcigs: If you support option 2, feel free to indicate same in the preceding section, for clarity. ―Mandruss ☎ 15:14, 11 September 2020 (UTC)

• I think the idea of flattenning the boxes is the best idea--and possibly not just for US presidents but in general. They're a rather primitive visual element, reminiscent of the earliest years of html. The basic information they give is useful--the prominence in the appearance of the article dadds nothing to that. DGG ( talk ) 00:55, 19 September 2020 (UTC)
• Broadly support flattening but the sample doesn't work well without some kind of separator in a wide window (and particularly as the number of offices rises). If the middle column could be made relatively narrow, and the left and right columns were right and left aligned respectively it would keep things visually connected ^~Hydronium^~Hydroxide^~(Talk)~ 02:28, 19 September 2020 (UTC)

Expansion of scope: succession boxes

This question should be expanded to include all the US presidential & vice presidential candidate bios. GoodDay (talk) 14:13, 1 September 2020 (UTC)

Sure, but why stop there? What about use of the same boxes in the BLPs for other U.S. officeholders? What about non-U.S. officeholders? If you're expanding scope at all, the only logical place to stop expanding would be to include all uses of the boxes anywhere in the encyclopedia. That's a far larger question, and before you know it you have a months-long discussion, very possibly all wasted time due to a no-consensus outcome. I say we can take this on in smaller pieces without undue harm to the encyclopedia, but any consensus here would be a factor in future discussions about other pieces. If we reach a consensus for option 1, there probably won't be any future discussions anyway. ―Mandruss ☎ 14:44, 1 September 2020 (UTC)

It wasn't my decision to delete the succession boxes at Donald Trump, thus putting that article out-of-sync with the others. GoodDay (talk) 15:38, 1 September 2020 (UTC)

That again??! You're right, it wasn't your decision. It was a local consensus not precluded by a community consensus, as explained to you more than once. The cross-article consistency factor was argued, and it was not enough to sway consensus toward keep. Please cease making me keep explaining to you how Wikipedia works, you have been around far too long for that. You are becoming disruptive. ―Mandruss ☎ 15:49, 1 September 2020 (UTC)

I'm not interested in getting into personal insults with you, so let's not go down that path. GoodDay (talk) 16:13, 1 September 2020 (UTC)

Log out second chance

Tracked in Phabricator
Task T217914

Isn't it about time Wikipedia had a "safety valve" on the "Log out" icon? I have accidentally logged out many times because I clicked the icon by mistake, and then I had to log in all over again. It should be a simple matter to modify the software so when an editor clicks the icon, a message appears, asking, "Are you sure you want to log out? Yes, No."—Anita5192 (talk) 18:16, 27 September 2020 (UTC)

Agree . {{u|Sdkb}} ^talk 18:24, 27 September 2020 (UTC)

Only to succumb to the documented "unconscious me always press Yes so I'll press Yes this time oh oops conscious me didn't mean to press Yes". Yeah, no. --Izno (talk) 18:33, 27 September 2020 (UTC)

@Izno: That has never happened to me. I think it is very common for a visitor to any web-site to make the first mistake, but extremely uncommon to make the second mistake. When I accidentally click "Log out," I mean to click something else, and I don't automatically click "Yes."—Anita5192 (talk) 19:34, 27 September 2020 (UTC)

I am glad you are so conscientious (see also anecdotal evidence). Most people are not. That said, there is discussion at phab:T217914 about the issue on mobile. --Izno (talk) 20:17, 27 September 2020 (UTC)

phab:T217914 has a discussion on this. A personal user script (see FlightTime's User:FlightTime/confirm-logout.js) can be used to add this for your own account if you want. — xaosflux ^Talk 20:20, 27 September 2020 (UTC)

I edit Wikipedia from my laptop computer only, using Google Chrome. I noticed on the phab:T217914 page that someone wrote, "It's not a mobile-only problem; I've clicked log out accidentally on desktop using a mouse." However, I did not see a response to that post on the page. I loaded the JavaScript code at User:FlightTime/confirm-logout.js into my common.js page and bypassed my cache, but it doesn't seem to do anything.—Anita5192 (talk) 21:59, 28 September 2020 (UTC)

Agree in a lightweight way if possible. That is, not changing MediaWiki itself but building it into a skin, user preferences or Javascript. I have often hit the logout accidentally at the top of the screen, and many times in the middle of teaching Wikipedia editing in front of dozens of people. As the Phabricator discussion mentioned, it is currently the only "destructive" action in that bar of links, so having a safety net to warn about logging out would be consistent with the user interface. -- Fuzheado | Talk 14:30, 29 September 2020 (UTC)

Agree, I've done it often enough to comment here, a few times a year. For me it occurs when I want to check my contributions for something and the uploaded page has a slight hesitation and then slides left as I click. The second-chance would save some of the time involved to log back in. Randy Kryn (talk) 14:38, 29 September 2020 (UTC)

I have also done it when I meant either to check my contributions or to click one of the Chrome icons.—Anita5192 (talk) 15:57, 29 September 2020 (UTC)

Agree and please do this. Otherwise it sucks. ❯❯❯   S A H A 11:00, 1 October 2020 (UTC)

Agree not a feature I'm personally looking for, but seems to be useful. However, if the logout button is ever removed as a stand-alone button and placed inside a menu,(like gmail for example) a further confirmation would be unnecessary. In other words, the actions necessary to logout should be two-clicks at most. $\langle$ Forbes₇₂ | Talk $\rangle$ 17:56, 1 October 2020 (UTC)

• There might be a preference but it is likely that the default would remain as it is now to avoid the problem of a hasty exit from a shared computer. A typical scenario is that someone logs in at a university or similar public place. Later, they notice they are half an hour late, and click "log out" while running away. They never see the "are you sure?" and they stay logged in. Johnuniq (talk) 00:40, 2 October 2020 (UTC)

Agree I like Fuzheado's idea of having it in user preferences. Personally, it discourages 2FA a bit because it takes a while to log in (might have to find the phone too, which can be a challenge). Ovinus (talk) 07:44, 6 October 2020 (UTC)

• Agree , a very nice proposal. Enjoyer of World^💬 02:53, 13 October 2020 (UTC)
• Agree. A good proposal, seems like a no-brainer to me. Herbfur (talk) 17:02, 14 October 2020 (UTC)
• Agree , I didn't see this thread when I posted the same thing farther down at WP:Village_pump_(proposals)#Double-click_option. On a mobile phone's small screen, "Contributions" and "Log out" are a millimeter apart and it's so frustrating to accidentally log out. Roll-back should also require a double-click, rather than a gadget that sometimes works and sometimes not.  JGHowes  ^talk 17:33, 16 October 2020 (UTC)
• I'm agree with JGHowes about rollback. There should be a pop-up asking the rollbacker to confirm the rollback. I had made several accidental rollbacks in another wiki. Enjoyer of World^💬 23:40, 19 October 2020 (UTC)

  @JGHowes: and @Enjoyer of World: there is an option in Special:Preferences#mw-prefsection-rendering titled Show a confirmation prompt when clicking on a rollback link - have you tried that? — xaosflux ^Talk 00:55, 20 October 2020 (UTC)

  Xaosflux Had not seen that "Show a confirmation prompt" Prefs option for Rollback — is that a recent enhancement? Indeed, it works! Thanks for that, no more inadvertent rollbacks, yeah!  JGHowes  ^talk 02:15, 20 October 2020 (UTC)

  @JGHowes: came out last year (phab:T215020). — xaosflux ^Talk 02:21, 20 October 2020 (UTC)

  Same for me, it works! Thanks Xaosflux. Enjoyer of World^💬 04:52, 20 October 2020 (UTC)

• Oh, please, please, please do this. See the above cited phab ticket for details, but this is particularly bad because not only do you accidentally log yourself out, you log yourself out of ALL devices current login sessions (which seems particularly stupid). And it especially sucks if you use 2FA and you happen not to have your token generator with you. I forget who told me this, but a workaround is to hide the logout link entirely in CSS so you can't click it by accident. See User:RoySmith/common.css for an example of how to do that (it's the #pt-logout rule). -- RoySmith (talk) 01:34, 20 October 2020 (UTC)

Proposals for ending the Infobox wars

Infobox wars
WP:ALLROADSLEADTOINFOBOXES
Date 2013–present Location English Wikipedia Status Possibly petered out due to exhaustion
Belligerents
radical infobox inclusionists	radical infobox exclusionists
Casualties and losses
bystanders' sanity

The infobox wars have now been raging for longer than the duration of World War II. Despite 2 ArbCom cases and ArbCom's request for community discussions, nothing's really changed since the opening salvos were fired back in 2013. Personally, I'm tired of seeing the same people show up en masse to talk page after talk page to debate over and over and over again whether or not an infobox should be in an article, especially since all such discussions quickly degenerate into back and forth name-calling. To take just one example, Mary Shelley has had 4 infobox proposals in the past 3 years. With this in mind, here are some ideas for ending (or at least reducing) the infobox wars. Feel free to add more ideas.

• Proposal A - No one may propose adding or removing an infobox to an article if there has already been such a discussion within the past 2 years.
• Proposal B - No one may propose adding or removing an infobox to an article unless they are one of the top 10 contributors to that article (as judged by the Xtools authorship tool).

-- Kaldari (talk) 00:00, 29 September 2020 (UTC)

• User:RexxS/Infobox_factors is good reading. --Izno (talk) 00:09, 29 September 2020 (UTC)
• Radical idea and one I know will be met with contention, but another idea would be an RFC to discuss whether all articles where it is feasible that an infobox should be present, though editors are not required to use all fields present even if there is data to fill those fields (knowing for example the concerns those at Kubrick have of that). 95% of the issue of infoboxes are people coming here expecting to find "structured" data that 99% of all other articles have. I know the past discussions in this, including ArbCom have been to leave this to a page-by-page consensus, but that is clearly not working, and things have changed since (the introduction of Wikidata, Google/Bing's presentation of search results, etc.). Again, this would be an RFC to discuss this possibility, which I know certain editors will refuse adamantly, but this is a consensus thing. --Masem (t) 00:22, 29 September 2020 (UTC)
  • Is there a WP:RS for any of those numbers. Having been through over 110,000 of the 'pedia's articles in my own editing I can guarantee that the number that have infoboxes is nowhere near 99%. It is also interesting how everyone talks about what readers expect to see without ever having performed a scientific survey to validate their statements. MarnetteD|Talk 00:35, 29 September 2020 (UTC)
    • I should add there are types of articles that we have no canned infobox for that we can make the topic conform into, and so in such cases, this would be reasonable where an infobox could be omitted. These are usually for more abstract terms that lack any type of hierarchical data. (This is what I meant by "where it is feasible".
      And as a rough test, I used Category:American women by occupation with Petscan, adding in a number of known infoboxes common for this group. Of the 9790 entries, I got to about 3000 pages without the most common infoboxes, and spotchecking those (to find any other infoboxes) the ones that were missing it were all observed to be stub, not well developed articles. Nothing of the type like Kubrick or other pages that have been fully developed and where consensus presently has been to leave an infobox out. This is far from scientific, but I would definitely say that for well-developed (non-stub, non-start articles), the number that lack infoboxes is far fewer then 5% based on this very unscientific study. --Masem (t) 01:32, 29 September 2020 (UTC)
  • I think that is about right. I am not sure the restrictions above are the path forward. More we need a discussion on making them standard and if so in what capacity. PackMecEng (talk) 00:37, 29 September 2020 (UTC)
• Both A and B are awful proposals and completely biased in their presentation. --Gonnym (talk) 00:56, 29 September 2020 (UTC)
  • You're going to have to explain what you could possibly mean. Both proposals look to be completely neutral - they take absolutely no inherent side in disputes other than stability - and while you can certainly disagree with them on any number of grounds, e.g. proposal B is unacceptably inimical to WP:OWN (my opinion), your comment neither adds to collective understanding nor actually advocates for your position in a meaningful way. VanIsaac_WS^cont 01:11, 29 September 2020 (UTC)
• If it came up at an RfC I would support proposal A. For no other reason it streamlines what has become a sort of drag on the community. -- GreenC 01:54, 29 September 2020 (UTC)

To add.. Option A is recommended, but it does not "solve" this problem because like water erosion there is no solution rather you redirect, slow down and so on. "A" is a way to reduce the disruption, which is the main issue, the particulars about infoboxes is almost a side issue to the larger problem of disruption. -- GreenC 05:35, 30 September 2020 (UTC)

• I have never encountered a contentious infobox discussion. If the problem is a cabal of editors going from page to page starting infobox discussions, we should just topic ban those editors. If that is not possible, we should develop project-wide guidance similar to Masem's suggestion. — Wug·a·po·des​ 01:57, 29 September 2020 (UTC)

  Have a quick look at Talk:Frank Sinatra. The argument goes back forever and has been re-launched zillions of times. — GhostInTheMachine ^{talk to me} 08:38, 29 September 2020 (UTC)

  Lucky you! One of the editors in Talk:Frank Sinatra opposing infobox change also deep-sixed my infobox request on Talk:Michael Tilson Thomas — Germsteel ^(talk) 09:58, 23 October 2020 (UTC)

• Proposal B codifies article ownership into policy and should be a nonstarter. – Teratix ₵ 06:50, 29 September 2020 (UTC)
• I've added {{Infobox war}} to this discussion since it seems apropos. Please feel free to fill in more parameters. EEng 09:39, 29 September 2020 (UTC)
• Mleh- I am indifferent to infoboxes, except when they're used to try and make substub non-articles look deceptively like articles. I oppose both options: the first one strikes me as "Thou shalt not talk. Thou shalt not think" and the second one amounts to assigning ownership of articles to prominent editors. Reyk _YO! 10:25, 29 September 2020 (UTC)
• Argh, is this still going on? Good grief. Personally I have never encountered a contentious infobox discussion in my own editing, but maybe I have just been lucky. I may be wrong, but my impression right now is that these "infobox wars" are limited to a small number of highly opinionated editors arguing over and over between themselves on a relatively small number of articles. If that is the case, then a better solution would be to issue a bunch of community topic bans to them for 2-3 years and then have some peace. If the problem goes deeper, then something like what Masem suggest makes sense to me. An RfC proposal to formalize the existence and structure of infoboxes along the lines that Masem mentioned seems likely to me to gain broad consensus. On the other hand, proposals A and B suggested above seem both extreme an unnecessary. Nsk92 (talk) 10:45, 29 September 2020 (UTC)
  • This is pretty much my read of the situation: there's probably a few dozen, very senior editors that have been very vocal on not wanting infoboxes on certain articles for multiple reasons. Most of us experienced editors know not to touch that. Newer editors - who see nearly every other developed page with infoboxes and have no knowledge of the infobox ARBCOM cases or the like - add infoboxes or ask valid questions of why no infoboxes, and that will never be a cycle that we can get out of beause there will always be new editors. So either we're going to have these going on forever (and as others point out, the two suggested RFC questions don't solve this), or we actually readdress the consensus around infoboxes, because if we're catering to a few dozen editors when hundreds more want it a different way (if that is what consensus is), then there's a problem. But best I can recall we have not had an RFC on how mandatory or optional infoboxes are for at least 5 years so I don't know that read: I know they're expected, but that's different. --Masem (t) 14:09, 29 September 2020 (UTC)
• I would reject both. B has problems, but it's also a strength of Wikipedia, and this kind of 'ownership' seems incompatible with the purpose. A does not exactly fix the issue -- the Sinatra RfC was brewing for 2 years. Masem's proposal probably doesn't help either - infoboxes are, indeed, not required on all articles. Particularly it'd look silly on short ones, and it's likely to annoy some editors who focus on their writing and don't like IBs. Further, their values are likely to get bloated so there will still be arguments on what labels to keep/remove. It's a difficult problem to solve from a central level, if pushing down a single rule, seemingly. I think what is more likely to be effective is prescribing actual guidelines which will help determine whether an infobox should be on an article (an expansion of MOS:INFOBOXUSE).
  One route to a solution is just making the infoboxes more palatable. Maybe modifications to infoboxes will help, too. People are opposed to too many fields, so maybe trimmed down 'wrappers' of contentious infoboxes with only support for some fields will be a sustainable middleground. Kaldari maybe WMF design input could be helpful? mw:Streamlined Infoboxes seems interesting. ProcrastinatingReader (talk) 18:14, 1 October 2020 (UTC)
• I would reject both, B just seems both against our ethos to an unacceptable level but also a potential source of its own aggravations and gaming. Articles can change a simply staggering amount in 2 years, so don't think that's wise. But perhaps some process to enable more targeted 1 year moratoria at specific troublesome pages. Nosebagbear (talk) 13:28, 29 September 2020 (UTC)

  The moratoria can already be applied to specific troublesome pages under the existing Infobox DS. I don’t think it’s working. We need a broad solution to the issue. And the issue is targeting behaviour and conduct on individual pages doesn’t work when the underlying issue is a fundamental content dispute. The issue can only be resolved by addressing the content issue.

  In usual cases, a clear MOS guideline etc would be sufficient clarification to put the matter to rest if it’s just individuals acting out (or just enact topic bans), but since the community is unable to agree on a standard I don’t think the conduct (which is a symptom) is the root of the issue here. Thus sanctions and topic bans likely not the appropriate way to address legitimate content concerns, however expressed. Banning the vocal opponents may dim the issue, but doesn’t seem to be the correct way to proceed. If their concerns were without merit, the community would have no objection passing an update to guidelines to say so. ProcrastinatingReader (talk) 14:18, 29 September 2020 (UTC)

• Can someone link to one of these specific contentious infobox discussions, preferably a recent one? Like many other people here have commented, I've never seen one ever, contentious or otherwise, other than meta-discussions like this one about how bad the problem is and what to do about it. Ivanvector (^Talk/_Edits) 14:20, 29 September 2020 (UTC)
  • Check the Cary Grant talk page, aye, where many a dusty hill has been held under heavy fire (someone should write an epic poem). Randy Kryn (talk) 14:41, 29 September 2020 (UTC)
  • The Arbcom case over this is here Wikipedia:Arbitration/Requests/Case/Civility in infobox discussions. Other pages I know that have been a hot bed have included Talk:Stanley Kubrick and Talk:Frank Sinatra but you likely need to look through archives of those to find the discussions. --Masem (t) 14:53, 29 September 2020 (UTC)

• An editor deep-sixed my infobox request on Talk:Michael Tilson Thomas — Germsteel (talk) 10:27, 23 October 2020 (UTC)

• Two editors heavily involved in this dispute (Cassianto and SchroCat)—they're the primary participants in all the discussions cited here so far—have recently left the project. Maybe we should wait to see if that changes things before considering a fresh round of sanctions? – Joe (talk) 15:06, 29 September 2020 (UTC)
• It's my sense that this imbroglio is largely in some biography article areas, so maybe start whatever proposed new "rule" there is with biographies, and see how that goes. (In that biography realm, it is something to observe, because that debate (or war) in effect regularly centers around not whether there will be something in a box in the top right corner, but whether it will be limited to a picture-box, or contain more). -- Alanscottwalker (talk) 16:48, 29 September 2020 (UTC)
  • There is a idea I've had for some specific types of bios - mostly creative people with a widely varied career - that most of the typical {{infobox person}} or its variants just don't work well and thus can be argued that an infobox doesn't help that much or if used will draw people to add the "missing" information that was purposely omitted because it can't easily be summarized in an infobox (Kubrick's fits this idea well). But at the same time, there is basic structured data like birth date + date, death place + date, broad profession list, and notable spouses and the like that can still be documented in an infobox that is the type of information that I see being asked for by the new editors that are the ones asking for infoboxes. This would need to be a discussion under my suggested RFC about the nature of infoboxes altogether. --Masem (t) 17:29, 29 September 2020 (UTC)
• Oppose B for WP:OWN per User:Teratix and others. RudolfRed (talk) 17:32, 29 September 2020 (UTC)
• Oppose both. Just add an infobox to every article (preferably from Wikidata), job done. Thanks. Mike Peel (talk) 17:47, 29 September 2020 (UTC)

Seeing as this seems to be cropping up as a bone of contention in biographies, where I'm sure much of the heat comes from the question of the choice of infobox, I would suggest that at the very least the generic {{Infobox person}} should be a default whenever you have an article about a non-fictional person. I edit in too many esoteric parts of Wikipedia to be able to say that every article has an appropriate infobox available, e.g. Perkins Brailler. VanIsaac_WS^cont 07:38, 30 September 2020 (UTC)

If the Perkins Brailer absolutely needed an infobox then I think {{Infobox keyboard}} could be made to fit: since it only has four uses already, I'm sure it could be adapted somewhat. But you're right, adding an infobox to every article does pose a challenge when it's not immediately obvious what type of thing a thing is. I would suggest that some things (persons, buildings, countries, songs, books, animals) can't really get away without having them but applying to every article ever, especially newer ones, would be too much. --Paul Carpenter (talk) 13:34, 30 September 2020 (UTC)

Vanisaac, you could also use Template:Infobox product for that article. WhatamIdoing (talk) 03:00, 14 October 2020 (UTC)

• I don't see why option B is perceived to go against WP:OWN. The question of whether to have an infobox in a particular article has little relevance to the function and encyclopedicity of that article, and Wikipedia's core policies have no bearing either. It's largely a stylistic choice, and for stylistic choices it is only common sense – in infoboxes or elsewhere – to accord greater weight to the preferences of the people who have put in the most work. A somewhat similar principle operates in MOS:RETAIN, which guides the choice of British or American spelling. – Uanfala (talk) 14:54, 30 September 2020 (UTC)

WP:RETAIN is absolutely nothing like option B above. It simply identifies a default consensus for an English variant based on the history of a page. It privileges absolutely no editors, and that default consensus is only used as a stability policy in the absence of an established consensus. Option B, on the other hand, privileges certain editors, allowing their opinion to veto consensus. It is not a stability policy, as those privileged editors can impose a decision no matter how entrenched another choice might have been. Option B is the epitome of WP:OWN, where certain editors are elevated as the masters of a page in regard to infoboxes, no matter the consensus or stability. VanIsaac_WS^cont 21:55, 30 September 2020 (UTC)

I agree with Vanisaac. Proposal B is a pure form of WP:OWN. Completely unacceptable and goes against the fundamental editing principles of Wikipedia. The proposal offers a cure that is a hundred times worse that the desease. Not only would it create a group of privileged editors for each article with veto powers over certain decisions, it would also encourage gaming and trickery in running the edit count in order the become one of those top 10 editors. Really, it would have been hard to concieve of a worse idea than Proposal B. Nsk92 (talk) 22:31, 30 September 2020 (UTC)

• Oppose both, especially oppose B for all the reasons above and zero good reasons in favor. Natureium (talk) 01:50, 2 October 2020 (UTC)
• Oppose both If a specific infobox, or lack thereof, proves to be a constant issue, a moratorium on bringing it up on the talk page can be agreed to on that talk page. This should really be decided by local consensus. ~ HAL333([6]) 03:50, 5 October 2020 (UTC)
• Oppose Both "B" per WP:OWN. For "A" 2 years is too long. PaleAqua (talk) 18:54, 5 October 2020 (UTC)

  "Two years" is simpler than what we'd probably want, which is an escalating length. "Infobox change, discussion 2" should be at least a few months after the first; if it fails, then "Infobox change, discussion 3" should probably be at least six months (maybe a year) later; "Infobox change, attempt 4" should probably be even later than that. WhatamIdoing (talk) 03:02, 14 October 2020 (UTC)

No real need as very very few articles have this problem. Its a small group of editors involved and getting smaller all the time.--Moxy 🍁 01:50, 20 October 2020 (UTC)

• Oppose both. I put an infobox requested on Talk:Michael Tilson Thomas and an editor took out the request. As it stands now most people would not even know there had been a request. That editor may not agree with the request but they should not erase it. They should see if somebody provides one or doesn't. And its not like they have contributed anything else to that page. Cheers. Germsteel (talk) 09:30, 23 October 2020 (UTC)
• Oppose both. (A) A request to "back off and calm down" for a "reasonable" interval is reasonable, but an outright ban for a fixed time is excessive. (B) is WP:OWN-ish and limits the debate to those who have already been too involved. It also is a block on new editors, wise uninvolved third-parties or anybody who is "just passing" but has a valid view. — GhostInTheMachine ^{talk to me} 10:23, 23 October 2020 (UTC)

L'infobox infernale
Opera semiseria in 25 acts by John Smith
The final scene
Translation	The Hellish Infobox
Librettist	Jane Doe
Language	Italian
Premiere	23 December 2005 (2005-12-23) Wikipedia
Website	Infobox wars

• Oppose both. What infobox wars? Did they even exist? If yes I believe they ended long ago, as a wise voice said back in 2018. Some - very few! - editors don't like infoboxes, and I won't stress them. It's so easy. Do you remember WP:ARBINFOBOX? The infobox on the side is taken from there, 2013. The case was requested because of troubles about the introduction of {{infobox opera}}, vs. operatic side navboxes. Successful, finally. - Try to treat infoboxes like other article feature (images, tables), and observe WP:BRD, - that's all it takes to end the rumor that these wars exist. --Gerda Arendt (talk) 10:29, 23 October 2020 (UTC)

Adding IMDb, Rotten Tomatoes, and Metacritic to external links (wherever possible)

Before !voting, please review Wikipedia:Village pump (proposals)#Adding IMDb & Rotten Tomatoes ratings to article infobox (wherever possible). Many of the same arguments apply.

Survey: IMDb, Rotten Tomatoes, and Metacritic in external links

Should IMDb, Rotten Tomatoes, Metacritic, or any similar sites be mass-added to the external links section of the Wikipedia pages for the films they review? --Guy Macon (talk) 22:55, 30 September 2020 (UTC)

• No to all.

The result of the previous RfC was:

"Consensus to not use critic review aggregations in the infobox, including but not limited to Rotten Tomatoes and Metacritic. There is consensus that such aggregations are not factual content of the sort suitable for an infobox. Concerns have been raised that any individual aggregator methodology is not appropriate when presented in an infobox without further context."

...and...

"Consensus to not use IMDb in the infobox. No-one but the proposer is in support. Prior to this discussion, there was recent consensus (WP:RSP#IMDb) that IMDb is not reliable for ratings as they are user-generated. There is no consensus here to overturn this decision, or to include such content in the infobox."

In my opinion, the exact same arguments apply in the external links section. I have no opinion about using these as sources in the body, and have purposely not asked that question here. --Guy Macon (talk) 22:55, 30 September 2020 (UTC)

• No to all IDMB should be avoided period. RT and MC are appropriate in reception sections as refs so should not be in the EL section. --Masem (t) 23:07, 30 September 2020 (UTC)
• No to all these websites rarely if ever make a helpful EL, as pointed out above. I would be infavor of mass removal of IMDB links. (t · c) buidhe 23:24, 30 September 2020 (UTC)

• The question is whether they should be "mass-added". In that sense this almost seems like a bot request. There is no question here about whether such links can or should be in the external links section. If the intention is to find consensus along those lines, the question will need to ask that explicitly (and should be both an RfC and posted to CENT, once the question is direct, given the thousands of articles it would affect). On the general topic, I will say that I don't often edit film articles but I am usually glad for these links at the bottom. In fact, I dare say that one of the most common things I use Wikipedia for as a reader is for film articles (often including clicking these links, and sometimes visiting Wikipedia specifically to use its ready array of these links). Obviously they shouldn't be used as sources apart from e.g. the Rotten Tomatoes percentage itself, but EL sections aren't for sources. — Rhododendrites ^talk \\ 23:26, 30 September 2020 (UTC)
  • Sorry for being unclear. I copied the wording from the recent infobox RfC. While I certainly wouldn't want a bot mass adding these sort of links, I wouldn't want a bot mass-removing them either. If an editor decidesd that an external link to IMDB is needed on one or two movies, I am inclined to let it be and assume that they had a good reason. But what I am seeing is editors who are adding a external links to IMDB, Rotten Tomatoes, etc. to every movie. An editor adding external links to thousands of pages by hand is still "mass adding" them. --Guy Macon (talk) 21:11, 1 October 2020 (UTC)
• I'd say no to both Rotten Tomatoes and Metacritic, because they'll most likely already be used as references in the Reception section. However, IMDb is considered both an unreliable source for references and a very useful link for both readers and editors, so I'd say yes to IMDb being added to External links, given that it would never be used for references. Rhododendrites is right in that this discussion should be advertised to as wide an audience as possible. El Millo (talk) 23:52, 30 September 2020 (UTC)
• No mass adding or mass removing. The Rotten Tomatoes and Metacritic links can be removed if they are already in the references but they are in a lot of articles that have no reception section so are useful for editors who wish to use them for expanding the article and also as a quick test of the notability of the film. IMDb is not permitted as a reference but is a useful external link for minor cast listings and so forth, imv Atlantic306 (talk) 00:14, 1 October 2020 (UTC)
  • Mass removing that undoes mass adding is OK, right? If an editor decided that an external link to IMDB is needed on one or two movies, that's one thing. But I am seeing editors who are adding an external link to IMDB to every movie. --Guy Macon (talk) 21:03, 1 October 2020 (UTC)
    • I think if you are going to remove Rotten Tomatoes links from pages without review sections / Rotten Tomatoes citations you should just add them there and then remove them from External Links afterwards. (talk) 08:38, 1 October 2020 (UTC)
• They should generally be present, but not mass added. To put it simply, they're useful to readers: Metacritic and Rotten Tomatoes provide a directory of critic reviews, and IMDB provides non-encyclopedic but useful information like a parents guide. To put it in the context of the external links guideline, Metacritic and Rotten Tomatoes fall under WP:ELYES criterion 3, which includes Sites that contain neutral and accurate material that is relevant to an encyclopedic understanding of the subject and cannot be integrated into the Wikipedia article due to...amount of detail...or other reasons, and IMDB falls under the "links to be considered" criterion 4, Sites that fail to meet criteria for reliable sources yet still contain information about the subject of the article from knowledgeable sources. We aren't talking about deeming them reliable sources here; we need to have some basic trust that our readers are smart enough to know that they're not impeachably fact checked yet still make use of them.

Regarding having them as both a reference and an external link, I reviewed WP:ELDUP, and I don't really see what the problem would be. They can be useful both as a citation for a critic consensus and as an external link for further reading beyond Wikipedia's level of detail; those are separate purposes that can co-exist.

Regarding mass-adding, I don't support that, since there will be exceptions, such as films with no or few reviews, or films where the IMDB page has perhaps been brigaded or corrupted or something. {{u|Sdkb}} ^talk 00:56, 1 October 2020 (UTC)

• No to all. I agree that IMDB and others do generally add 'additional information', but there is certainly not a blanket. I do have the feeling that a lot of IMDB is now being added because it is IMDB and that IMDB is marked as 'generally yes' instead of critical evaluation whether it actually merits addition. IMDB often has more extensive lists, but not always and one can ask sometimes whether that is information that is really an expansion on the material in Wikipedia. It can also overlap with what is available already on the (generally linked) official website of the subject or other, more reliable, websites. Being user generated one can also ask whether they are always correct. Also, a lot of information on IMDB can be incorporated into our articles, it is mainly on the extensive lists that it may be of an addition use. Other reviews are often used as a reference already, or should be used as a reference. WP:ELDUP should generally be followed, but there are exceptions where either IMDB or a review has really much more information.
  But. I strongly disagree with making an ==External links== section a dumping ground for material that 'maybe sometime in the future' can be used to write something in the article: a) then just write it in the article, it takes just a minute more to write '=== Reviews ===<newline>Metacritic evaluated .....<ref>paste metacritic url</ref>' as that it takes to write '* [<paste metacritic url> metacritic review]' in the external links section; b) you can just dump it on the talkpage just as well as in an external links section. Unfortunately, having first reviews there does tend to invite more (sometimes non-notable) reviews to be added.
  These links really need to be added on a case-by-case basis, using the guidance of WP:EL and common sense. --Dirk Beetstra ^{T C} 07:13, 1 October 2020 (UTC)
• No to all (first preference), and certainly No to Metacritic and Rotten Tomatoes. All contain a mix of usable content that should be available elsewhere (e.g. notable critics' reviews) and user-generated content. Even when it's not UGC, it's promotional. Example: IMDB entry for Plandemic is Documentary series about the COVID-19 pandemic that shows the major conflicts of interest between the key medical organizations, the media and their decision makers. Guy (help! - typo?) 09:50, 1 October 2020 (UTC)
• Migrate to {{Authority control}} and use that on all applicable articles. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:21, 1 October 2020 (UTC)
  • Oppose moving to authority control. The same arguments against putting in an external link or infobox link apply to adding the same site to authority control; these movie review sources are dodgy, change often, are easily manipulated, and some of them are user generated. --Guy Macon (talk) 20:58, 1 October 2020 (UTC)

    I'd still rather have them in a small template than filling the ==External links== section. Something like Template:Medical resources would be nice. I asked at BOTREQ, and they said it was possible for a bot to take the current lists of links (whatever's already in the article, without adding anything) and stuff it into a little narrow template if we'd rather have it displayed compactly (and, optionally, not at all on mobile). WhatamIdoing (talk) 03:06, 14 October 2020 (UTC)

• No to all (this includes No to adding them to Authority Control, which should not include even more links and certainly not even more lower quality content: I know that "authority control" isn't supposed to mean "high quality content", but it makes no sense to add links to lower quality content automatically on enwiki, no matter if the link is wanted or useful on Wikidata). In general, the number of ELs (including Authority Control) should be vastly reduced, not increased. (Anyone proposing a bot to get rid of all findagrave and genealogy links to ancestry and the like has my support). Fram (talk) 16:29, 1 October 2020 (UTC)
• No to all - In general, these rankings are too ephemeral to be of any encyclopedic use. The exception is when specific rankings have become noteworthy (such as when there was a significant disparity between rankings by critics vs regular people - enough that the media commented on the disparity) ... but in those cases the specific noteworthy rankings should be mentioned in the body text and cited to third party sources. There is never a reason to link to the ranking site itself. Blueboar (talk) 20:24, 1 October 2020 (UTC)
• No to mass adding all - If IMdB is relevant to direct readers too, it should be added, but definitely not mass added to articles not currently using it. RT and MC will generally exist as inline references so per WP:ELNO, those should then not be duplicated as external links. - Favre1fan93 (talk) 21:16, 1 October 2020 (UTC)

  @Favre1fan93: Which point in WP:ELNO are you referencing? If it's #15, note the explanatory footnote This guideline does not restrict linking to websites that are being used as sources to provide content in articles, which makes pretty clear that the "rule" some editors here seem to want to follow does not actually exist. (If you actually meant WP:ELDUP, please read the above.) {{u|Sdkb}} ^talk 00:21, 2 October 2020 (UTC)

• Yes to IMDb, an explanation concerning Rotten Tomatoes - IMDb first and foremost (despite having the explicitly professional version IMDb Pro) is a database. It provides much much more complete cast and crew lists for basically any movie ever made than wikipedia or any other website provides alongside better release date information and film locations, etc. All but the very largest movies will lack relevant information that IMDb provides. The official website for a film (if it exists) and IMDb I think are explicitly good external links that any notably film should include. As for Rotten Tomatoes I should point out that I am the person that Guy Macon is referring to who "mass added" (i.e. meticulous added by hand over the span of 5 years or so) Rotten Tomatoes links to probably on the order of 5-10 thousand film pages (I would guess, nearly all my edits to wikipedia are either adding or fixing Rotten Tomatoes links). I did it because lacking reception sections on the majority of film pages left no place for readers to go to check the reception to the film, and often the reception section is more of a "reception at the time" and thus either didn't update or had to be updated as more reviews are added over time. I also believe I did my very best to adhere to the policies set forth by Wikipedia over the last five years. All that being said, I understand if maintainers want to change the policy to strictly limit what is allowed in the External Links section of films, some of them are unwieldy to say the least. And Rotten Tomatoes is, I think, much more of a for profit brand than a database, and so I get that my activity could be construed as endorsement. I would argue that conflating Metacritic and Rotten Tomatoes is incorrect though. Much like Box Office Mojo, Metacritic is accessible via any IMDb page (since they share the same parent company, Amazon) and so adding those links alongside IMDb links is somewhat redundant, whereas there isn't (as far as I know) a free service that allows a user to connect IMDb links and Rotten Tomatoes links. It is unclear what changes are specifically being proposed here, but I'll obviously adhere to any policy changes regarding wikipedia external links on film pages. -- LudaChrisKlein (talk) 09:20, 2 October 2020 (UTC)
• I am opposed to mass anything. I would be opposed to rapid, non-editorial (i.e. without regard for the narrative text such reviews were being used to support) adding of these websites to Wikipedia as a semi-automated process. However, I would also be equally opposed to any rapid removal of such links without regard for whether or not they were being used appropriately. I would be also, however, be against enshrining anything in Wikipedia policy or guidance that encourages "mass editing" behavior of any sort. --Jayron32 15:52, 2 October 2020 (UTC)
  • If the link was added to the external links section with no associated text, then there is no "narrative text such reviews were being used to support". And if one editor adds Rotten Tomatoes links to the external links section of a couple of thousand pages, even if they do it by hand, that's certainly "mass adding". So how, exactly, am I supposed to avoid "rapid removal of such links without regard for whether or not the external links to Rotten Tomatoes were being used appropriately"? There is nothing there to "regard" except the external link. --Guy Macon (talk) 16:45, 2 October 2020 (UTC)

• No to all, and should be fine to remove en masse. These are basically spam links. --K.e.coffman (talk) 03:27, 3 October 2020 (UTC)

• No to mass adding, but yes to having them present in the ELs. I'm a little uncomfortable with mass adding anything, but I don't think that we really need to remove the presence of IMDb in the EL sections as a whole. It is useful to have there, as others have stated, and honestly... I've gone to Wikipedia before just to click on the IMDb link for a film, rather than wade through a Google search, since it's not always the top result. I'd wager that I'm not the only one who does that. I don't think it's absolutely necessary to have it in every film article, but if it does eventually get added to almost every article in the EL section that's not necessarily an awful thing as long as it's not used as a source. ReaderofthePack(formerly Tokyogirl79) (｡◕‿◕｡) 05:44, 3 October 2020 (UTC)
• No mass removal I don't think we should mass add them either. ~ HAL333([7]) 03:52, 5 October 2020 (UTC)
  • Would that include a prohibition on reverting a previous mass-addition or mass removal without changing any other pages? --Guy Macon (talk) 06:56, 5 October 2020 (UTC)
    • I think you really need to talk to people more involved in the film part of Wikipedia about this. Not least of which because in the manual of style (https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Film) it specifically says "For example, Rotten Tomatoes and Metacritic can provide listings of more reviews than sampled in the article body. They can be included as external links instead of links to individual reviews." So I think this is much more of a actual policy change than some sort of "reverting a past wrong." --LudaChrisKlein 14:16, 5 October 2020 (UTC)
      • Except that nearly all film pages include RT and MC as part of a reception section (for new films, as a standard part, for older films, predating when RT/MC started, usually as a "contemporary reception" section as well). I've not seen a "well developed" film page that does not use RT or MC in this fashion. --Masem (t) 14:27, 5 October 2020 (UTC)
        • Looking through a small sample (1000 film pages) only about 20% of pages with Rotten Tomatoes links (which is about 90% of film pages) have them as a reference. About 60% have them as external links. The other 20% have them in both places. Those 20% certainly can have the link removed from the external links. The other 60% with links only in external links sections I'm less sure about. If you go to the talk page for that Manual of Style even the presence of Reception sections seems to be a point of some consternation (merely providing RT/MC links being much less maintenance for editors seems to be the gist of the argument against Reception sections in general). --LudaChrisKlein 08:53, 7 October 2020 (UTC)
• No to keep and No to remove. As usual, editorial decisions should be left to editors, not to robots. When watching the series Queen Insoo, the IMDb review is amusing. They are saying that Hahm Eun-Jung (23 yo) appears there during the 60 episodes, as well as Chae Shi-ra (43 yo). The former is playing Insu before 1457, the later is playing Insu afterwards. How could they both appear in each and every episode ? Moreover the review "three women struggle with one another as each vies for power in the royal court", piously reproduced here, at en:wp, is rather misleading. The whole series is a romanced account of a 50 years clash between the hungu and the sarim factions, and revolves around the seizure of power by King Sejo (1417-1455-1468). This series involves more than 250 actors named in the credits and gives a detailed depiction of more than 150 people, a majority of them belonging to real life History. Missing that gives rather the impression that none of both reviewers watched the series. But this is not a plea for a mass removal, since this doesn't prove that other IMDb reviews are pityful to the same level. Pldx1 (talk) 10:13, 5 October 2020 (UTC)
• No Mass Adds This is a terrible proposal which is quickening the heartbeats of spammers everywhere. GenQuest ^{"Talk to Me"} 14:27, 5 October 2020 (UTC)
• Add ELs only when applicable because per WP:EL, we should only include external links when they provide unique resources "beyond what the article would contain if it became a featured article". We should separate consideration of IMDb from consideration of RT and MC. IMDb, while not reliable for citing, has numerous sub-pages of different kind of resources that usually meets the unique-resource criteria. As for RT and MC, it is only happenstance that the inline citation for the aggregate score and the external link for the directory of reviews (which is a unique resource) are the same link. The ELs for RT and MC can more specifically point to the sub-page listing full reviews. But RT and MC do not need to be used if there are no reviews, or if the reviews on either website can be fully sampled in the Wikipedia article body. For example, if a film has only eight or nine reviews on RT/MC, then these can be sampled in the reception section, and no EL is needed. I think other editors need to be more nuanced beyond just saying that because RT/MC is used as an inline citation, it shouldn't be used as an EL either. The ELs exist to provide access to more reviews. Erik (talk | contrib) ^{(ping me)} 16:40, 5 October 2020 (UTC)

  Very well put. {{u|Sdkb}} ^talk 17:14, 5 October 2020 (UTC)

• No to all These websites are infamous for being biased --♦/\/\/\TheGeometryDashFan/\/\/\♦ (talk) 18:03, 8 October 2020 (UTC)

  There's no evidence of a bias in either of these websites. El Millo (talk) 18:11, 8 October 2020 (UTC)

  Note: GeometryDashFan12 originally (I presume accidentally) inserted their !vote above my reply to Erik, giving the false impression that I was praising their !vote, not his. I have restored the correct ordering and urge you to be more cautious in the future. {{u|Sdkb}} ^talk 18:24, 11 October 2020 (UTC)

• No to all per Masem - IMDB shouldn't be added and MC and RT should be used as cites. –Davey2010^Talk 13:38, 9 October 2020 (UTC)
• No We already have an overreliance on these websites, and a lot of newbies think they are reliable when they clearly aren't. We should not be furthering that perception, nor do we need to be providing SEO for these websites. If folks want it, they can google it themselves. External links should be for relevant yet somewhat hard to find links of interest. CaptainEek ^{Edits Ho Cap'n!}⚓ 21:23, 23 October 2020 (UTC)

Things I am finding alongside IMDB and Rotten Tomatoes

There are some other external links that I am finding alongside the movie review website external links discussed above. What should I do if I run into the following? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

YouTube of the entire film? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

This seems like a clear copyvio, and I have removed them when I found them. --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

Keep in mind some short films may be uploaded by the owner of the work, which would be valid. But you need to cross check and confirm the account owner, they hold the rights, etc. If this all checks out, this would be okay, it would be akin to linking to the music video uploaded by the copyright owner (legit) on the WP page about that song. But 999 times out of 1000, for film works, the upload of the full work is likely a copyvio of some means or another.

Films/works confirmed to be in the PD should be kept, though ideally we should go to a source like Archive.org where these are better preserved. For example [8] for Manos: The Hands of Fate rather than any YT version. --Masem (t) 16:55, 2 October 2020 (UTC)

YouTube of a scene from the film? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

Nope, unless the scene is extremely well-known to the point that the film is primarily known for the specific scene, and the YouTube license is clear. {{u|Sdkb}} ^talk 08:56, 2 October 2020 (UTC)

Any scene from a film (non-PD) that is a subject of discussion should be used as a non-free media file encoded and trimmed per our NFC policies and used as a File: directly. --Masem (t) 16:57, 2 October 2020 (UTC)

And of course if it is only found in a link in the external links section, it isn't a subject of discussion.

Public domain movies are something I didn't mention above. What about an external link to a YouTube copy of a scene or even an entire film from 1913? At first blush this seems OK, but I think it should be disallowed for the following reasons: [A] any YouTube video can be taken down at any time. [B] many of these old public domain silent films have been released on DVDs with added music or maybe just an introduction that is copyrighted. [C] Many YouTube videos have ads inserted in the in the middle of the content. Besides being undesirable just because they are ads, the ads are not PD. [D] Someone is making money off of that YouTube video, and if we link to it we are encouraging spamming more of the same to make more money. None of these problems apply to a file without any added copyrighted material that we host on commons. --Guy Macon (talk) 17:47, 2 October 2020 (UTC)

Which I all agree with. Its better to use a commons version or Archive.org version than YouTube which may remain questionable. --Masem (t) 21:39, 2 October 2020 (UTC)

[A] is true for all web pages, and may even be less true for public domain materials on YouTube than average. [C] is not a problem for YouTube, because Wikipedia:External links permits a reasonable amount of advertising. [D] is irrelevant because Wikipedia:We don't care what happens to your website. Somehow encouraging people to provide appropriate external links is not actually a real problem. WhatamIdoing (talk) 03:15, 14 October 2020 (UTC)

YouTube of a trailer for the film? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

Not so sure about this. Doesn't the copyright holder want as many people to see the trailer as possible? --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

Hmm, perhaps. Seems a reasonable enough EL. {{u|Sdkb}} ^talk 08:56, 2 October 2020 (UTC)

Perhaps it should be restricted to "official" trailers if possible, just to mitigate the risk that the YouTube link will break in the future if the video is taken down (this is a particular problem on TMDb I encounter on occasion). But I tend to agree that a trailer is a good EL that can't really go into the body of the article as a reference.--LudaChrisKlein (talk) 09:39, 2 October 2020 (UTC)

I would not include this normally. If the trailer is the subject of discussion beyond just when it was released , we have {{external media}} that can be used to embed a box to direct people to see that near where it is discussed. (eg not a movie but this is used in Untitled Goose Game where the trailer is discussed related to how its popularity and music impacted its development). --Masem (t) 16:15, 2 October 2020 (UTC)

Trailers are ads and ads are not encyclopedic, thus they violate WP:ELNO and shouldn't be included. (This is different to a discussion about a trailer, but then that would be reliably sourced with secondary sources.) —  HELLKNOWZ   ▎TALK 16:24, 2 October 2020 (UTC)

Agree with HK 100%. GenQuest ^{"Talk to Me"} 15:31, 5 October 2020 (UTC)

OK, unless someone gives me a compelling argument to the contrary, I will remove external links to movie trailers on YouTube when I run across them per Masem and Hellknowz. --Guy Macon (talk) 16:36, 2 October 2020 (UTC)

Facebook page? Twitter account? (Example: Whole Lotta Sole#External links) --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

My big question here is whether I would have to research to see if the account was official. --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

I think you would. Facebook accounts are at least sometimes official especially for smaller films. I do think you'd want to confirm that they aren't official before removing them. --LudaChrisKlein 08:49, 2 October 2020 (UTC)

Way easier said than done. There are probably hundreds of thousands of such accounts, how do you get editors to check each one before changing? You don't, because ain't nobody got time for dat! We should not be using FB or Twitter in any capacity on Wikipedia in my opinion, or only in very rare instances where they may actually be the article subject. GenQuest ^{"Talk to Me"} 15:31, 5 October 2020 (UTC)

If there's an official website, that's sufficient; no need for the Facebook and Twitter. {{u|Sdkb}} ^talk 08:56, 2 October 2020 (UTC)

Sorry if I was unclear, I agree. But the issue is that you can't just remove all Facebook links because some of them will be the official site. If there is another official site in the external links then yes, I think you can remove the facebook link without checking. But whether Guy will have to "research if the account was official" I think the answer is generally yes. In my experience facebook accounts are not typically included in External Links sections, and so when they are (and no other official website is listed) I think you'll definitely have to check to make sure it isn't the official website for the film. --LudaChrisKlein (talk) 09:24, 2 October 2020 (UTC)

Link to Getty Images or any other image hosing site? (Example: Whole Lotta Sole#External links) --Guy Macon (talk) 22:37, 1 October 2020 (UTC)

I would just consider the official website and the IMDb page to be somewhat-essential as part of External links. El Millo (talk) 22:51, 1 October 2020 (UTC)

Official website, yes; Imdb, not always. Can someone tell me why we locked into IMDb and not some other publicly edited movie site. I think they all should probably go in most cases. At the least these EL entries should be limited to just one per article. GenQuest ^{"Talk to Me"} 15:31, 5 October 2020 (UTC)

Can we get an example of an image hosting site in the external links section? I can't really think why something like that would belong in external links, but maybe in some cases. --LudaChrisKlein (talk) 08:51, 2 October 2020 (UTC)

I'm confused as to why this would be present, same as Luda. {{u|Sdkb}} ^talk 08:56, 2 October 2020 (UTC)

Grant Crabtree#External links and Women's American Basketball Association#External links have links to photobucket. Both photobucket pages have been taken down, so I assume that they were not official pages. If somebody put links to now-deleted photobucket pages in the external links to those two articles, I am pretty sure that an exhaustive search would turn up some examples of external links to pages from photobucket or other image hosting sites that haven't been taken down yet. --Guy Macon (talk) 16:10, 2 October 2020 (UTC)

@LudaChrisKlein, you might want an Instagram account for a photographer. WhatamIdoing (talk) 03:17, 14 October 2020 (UTC)

@WhatamIdoing: but those are generally already linked from the official website of the photographer already. --Dirk Beetstra ^{T C} 06:14, 14 October 2020 (UTC)

I was thinking of cases when the Instagram account is the official website. WhatamIdoing (talk) 06:43, 14 October 2020 (UTC)

Guy Macon, many movies have an official page on the company website (https://frozen.disney.com/??), and I can hardly imagine that any commercial movie will not have such a page somewhere. Per WP:ELMINOFFICIAL, we link only one (original bolding) official site, twitters, facebooks, youtube-trailers, etc. etc. are then hardly useful. Only for old movies that do not have an official website (anymore) I would consider to add youtube uploads of their out-of-copyright movies, and even official movies that have been uploaded by the owner are generally linked from (if not embedded in) the official website of the owner (and I then find it hard to imagine that any facebook or twitter is 'the official <social media>' of the subject). Beyond ELMINOFFICIAL, I do think that we should generally minimize the number of links, and an official website generally links to most of the rest of the material. --Dirk Beetstra ^{T C} 06:14, 14 October 2020 (UTC)

Template:cite web: New keyword(s) for url-access / New parameter(s)

Library Card access

In template:cite web, under Subscription or registration required, the url-access parameter should support indicating that access is permitted via the The Wikipedia Library Card Platform.

I realize that there are some considerations regarding this approach:

• Access is not universal, but rather depends on the ongoing accomplishments, and in some cases the successful application, of the individual editor.
• Access to a database may shift, as it can withdraw its participation.
• Access to a database might be limited to a specified number of editors.
• An editor might attempt to game the access requirement by making many trivial edits.

However, there is also a potentially positive aspect: potential users of the Library Card might be incentivized to be more productive in their Wikipedia efforts. Larry Koenigsberg (talk) 20:45, 2 October 2020 (UTC)

Oppose per WP:READER. {{u|Sdkb}} ^talk 21:14, 2 October 2020 (UTC)

I think I would oppose because there is very little guarantee that TWL will always have the same access to the various databases it currently enjoys. --Izno (talk) 21:17, 2 October 2020 (UTC)

Oppose The content of pages in article space should be useful to readers, but anything about The Wikipedia Library is only useful to editors. Jackmcbarn (talk) 21:01, 4 October 2020 (UTC)

Comment is knowing that content could potentially be accessed without paying really not useful for readers? If someone really wanted to learn more but didn't have the financial means, giving them a viable alternative sounds useful to me. --Paul Carpenter (talk) 01:17, 10 October 2020 (UTC)

Oppose per above. BUT it would be nice if there was a way like how we have Special:BookSources for when we link ISBN's , that we could do the same for DOIs and other academic papers so that a reader and/or editor can determine if they have access quickly. But this would be outside the template's ability. --Masem (t) 15:37, 5 October 2020 (UTC)

Comment From a Wikipedia Library perspective, I just want to echo the above comments and say that I also don't think this is the best way to go about this. That said, I do think it would be great to be in a place where the links between citations on Wikipedia and access through the Library Card was more direct for editors - the underlying problem here is very reasonable. You could imagine a world in which editors could, for example, turn on a preference which automatically redirected links from Wikipedia through The Wikipedia Library's proxy if the user is eligible for access at that time. The database lists and authorization would then be kept up to date and always contextually accurate, you wouldn't need to take multiple steps to access the source, and it wouldn't bother readers. Would that solve the underlying issue identified here? To be clear this is just an idea, not something we plan or have capacity to work on in the short term :) Samwalton9 (WMF) (talk) 10:37, 13 October 2020 (UTC)

Samwalton9 (WMF), having a gadget that did that sort of redirect would be fantastic! {{u|Sdkb}} ^talk 20:57, 24 October 2020 (UTC)

Geographical Restrictions (inc GDPR)

An innocent European has been locked out from a world news source.

Many news websites have, since GDPR, stopped serving content visitors in the European Union. This is often pitched as a temporary measure, but I doubt the ones that are still doing this are going to change any time soon. It's not hard to get around, but it does limit verifiability for the casual reader. I don't know if there are other common geographical restrictions but I'd guess there are some.

The url-access= field in citations doesn't have an option to cover this. There is the option limited but this gives the alt text "Free access subject to limited trial, subscription normally required" so it's not exactly descriptive. My proposal is that there be a keyword allowed for geo-restricted that would look give a image instead of a padlock and alt text saying: "Can only be accessed from certain countries". --Paul Carpenter (talk) 00:56, 10 October 2020 (UTC)

@Paul Carpenter: Sounds good. In the template code, {{{url-access|{{Geoblock check|url={{{url}}}}}}}} can be used (see {{Geoblock check}}) to automatically mark all the domains from data.verifiedjoseph as geo-restricted. Perhaps it would be better to have geo-restriction as a separate parameter though. — Alexis Jazz (talk or ping me) 15:12, 10 October 2020 (UTC)

@Paul Carpenter: Some YouTube videos are geo-restricted as well. — Alexis Jazz (talk or ping me) 15:20, 10 October 2020 (UTC)

Yes I was wondering if having a separate parameter might be better, after all something could be geo-restricted and limited access once you get there. I'd hope that if/when this is implemented, it should be pretty easy for a bot to add it to all offending citations. And good point about the Youtube videos, that's definitely worth highlighting. --Paul Carpenter (talk) 15:23, 10 October 2020 (UTC)

@Paul Carpenter: Such a bot would have to run continuously and also go after any changes to the list so that things get updated when a site is added to or removed from the list. So I wouldn't call it "pretty easy". — Alexis Jazz (talk or ping me) 23:57, 10 October 2020 (UTC)

I mean to say, easy for a bot to do once, rather than to monitor it, which would obviously be a lot harder. -Paul ❬talk❭ 07:14, 11 October 2020 (UTC)

Thoughts Trappist the monk? ProcrastinatingReader (talk) 15:28, 10 October 2020 (UTC)

Adding different keywords and tool-tip text for the already existing access icons is simple so not hard to do this: |url-access=geo-blocked → . I'm not at all enthusiastic about the pink globe. Too many words were spent and an rfc required before we could settle on the three access icons we have now. I'd rather avoid that sort of bikeshedding.

—Trappist the monk (talk) 21:30, 10 October 2020 (UTC)

I support the idea of indicating geo-restricted sources, I'm not particularly interested in bickering over what icon to use. So I'm with you on that. — Alexis Jazz (talk or ping me) 23:57, 10 October 2020 (UTC)

I imagined the icon would need to be distinct from the ones currently in use, but I can't say I hold a strong opinion about what the icon should be. -Paul ❬talk❭ 07:14, 11 October 2020 (UTC)

I would not support indicating this. Support for worldwide access will come and go, and there are ways to work around it besides. On an aside, this has come up before; please review the WT:CS1 archives. --Izno (talk) 03:35, 11 October 2020 (UTC)

Part of the problem here is that the editor adding the reference would not know that the content was geographically restricted - it's only people who can't get at the content who would know this.Nigel Ish (talk) 10:51, 13 October 2020 (UTC)

This would be very useful for European readers. Just as it is helpful to know that an article requires registration or subscription and I shouldn't waste my time clicking the link (or I should use the archive link instead) the same applies to GEO-blocked links, and we don't expect the person adding the reference to include those either.

Much as I would like this to happen I do think it would need to be quite specific, and not a too generic because there are readers from many other countries (many websites blocked in China for example) that are blocked in a less predictable or consistent way than the groups that block Europeans readers over GDPR.

A picture is worth a thousand words: please don't use a picture, use a few well chosen specific words instead, tooltips as Trappist the monk suggested sounds pretty good too. -- 109.76.205.197 (talk) 00:04, 23 October 2020 (UTC)

References

Move good/featured article topicons next to article name

Firstly, apologies if this has been brought up before, I couldn't find it in a search of the archives.

My suggestion is pretty simple: move the topicons indicating good or featured status from the top-right corner to after the article name, as is done on other language projects, such as here on the Danish Wikipedia. They are much more visible this way without being more obtrusive.

Why? Because I think the current icons are too well-hidden for the average visitor to notice, tucked away in the corner - I've been using Wikipedia for years and I barely ever notice the little gold star as my eyes jump to scanning through the content below. In my extensive, highly accurate survey of a couple of non-editor friends, they didn't know there's a recognised difference in quality between a long C-class article (say, Operation Market Garden) and a shorter featured article, because they didn't know good & featured articles existed.

Both have a standardised peer review process (the only subsection of Wikipedia's content that goes through this process) and have been around for a long time. Making this clearly visible is valuable for exactly the same reasons we undertake good & featured reviews: informing readers that the article is considered to meet a higher standard than average Wikipedia content; promoting greater trust in the content (vs. other Wikipedia content); increasing transparency of Wikipedia's processes (i.e. some sections of content have been peer-reviewed, others haven't); etc.

The objections I can see are that it could encourage people to think that the visible version of the page is mistake-free, to which I would respond that 1) the icons are already there, it's just that people aren't noticing them and 2) Wikipedia has been around for long enough for most people to know it's not a reliable source, and icons don't guarantee accuracy. I look forward to hearing others' thoughts on this. Cheers, Jr8825 • Talk 13:38, 6 October 2020 (UTC)

Support Seems like an improvement to have the icon right next to the article title to make the meaning more clear. Having review icons next to names is becoming more common recently,(e.g. Twitter and Youtube verified accounts) so it makes sense to evoke some of that design language, since GA/FA also involves a kind of external review. Without knowledge of what a GA/FA is, it's not obvious from the current context what the function of the icons is. Seems like a clear improvement for WP:READER who isn't familiar with Wikipedia's internal article review process. 〈 Forbes₇₂ | Talk 〉 15:06, 6 October 2020 (UTC)

• Support increased prominence for GA/FA icons, per the nom's excellent rationale. I'll need to think/research/hear out others a bit more before committing to this specific remedy, but we certainly ought to do something. {{u|Sdkb}} ^talk 16:36, 6 October 2020 (UTC)

  Clicking through to Danish Wikipedia, the icon there looks fantastic, so I'm moving to full Support unless anyone comes up with a better idea for how to display the icons to give them more prominence. {{u|Sdkb}} ^talk 00:42, 7 October 2020 (UTC)

• For some reason, it doesn't show when using the Timeless skin. If that can be solved, I'd consider supporting. Isabelle ^🔔 22:39, 6 October 2020 (UTC)
• Oppose I'm sympathetic to the arguments provided, and I do agree with most of the rationale, but I'm opposing because I think the current way of doing it is more aesthetically pleasing. I think that putting it right next to the article title does look a bit obtrusive. As a side-note, regulars of the FAC and GA processes should probably have been notified of this discussion here and here. Ichthyovenator (talk) 22:54, 6 October 2020 (UTC)

  Ichthyovenator, I notified WikiProject Usability, which is probably the most relevant WikiProject, even though it's not super active. The GA and FA folks have now been notified as well.

  Regarding your opposition, do you have any ideas about alternative ways we might emphasize FAs/GAs? {{u|Sdkb}} ^talk 23:04, 6 October 2020 (UTC)

Sdkb I personally really like how it is handled now but I do see how someone not familiar with Wikipedia and the FA/GA process would miss the icons. What I'm fearing is that putting big icons next to the article titles will make it look cluttered. I can see that I'm clearly in the minority here; maybe i just need to see some concrete design suggestions, it is probably possible to move the icons as per your suggestion without making it look cluttered or obtrusive. Ichthyovenator (talk) 10:22, 7 October 2020 (UTC)

• Support. Including GA articles. Current icons are not really visible, especially on the mobile site. T8612 (talk) 23:00, 6 October 2020 (UTC)
• Support You are right. The icons remains unnoticed by the common readers. I noticed that, here, in India, most Wikipedia readers don't know what the GA and FA are. --Gazal world (talk) 23:02, 6 October 2020 (UTC)
• Support placing alongside article title in mobile view. I think the current arrangement for desktop is ok though. Peacemaker67 (click to talk to me) 23:09, 6 October 2020 (UTC)

  @Peacemaker67: Sdkb has pointed out this is currently a technical limitation on mobile. My issue with desktop is I don't feel that reader's eyes naturally go to the top-right corner when they open and read an article, particularly if they're doing so quickly. Jr8825 • Talk 00:44, 7 October 2020 (UTC)

  I've commented there. I'm not sure I like the idea of sitting the star next to the article title in desktop though, mainly from an aesthetic/professional appearance perspective. Peacemaker67 (click to talk to me) 00:55, 7 October 2020 (UTC)

• Support - I like this idea. — Rhododendrites ^talk \\ 23:13, 6 October 2020 (UTC)
• Weak support I think it's probably better for the reader, but I don't like it as an editor. Full support for placing alongside title in mobile view. Seems like a pretty simple thing to do, happy to expand on my rationale if wanted. Eddie891 ^Talk _Work 23:31, 6 October 2020 (UTC)
• I don't agree with the premise. I don't think additional prominence is required for the good article/featured article icons. Readers are very good at judging the quality of articles on their own, without needing more intrusive cues. isaacl (talk) 23:54, 6 October 2020 (UTC)

  I'm not saying that readers can't judge the quality of an article (although I would probably disagree with you about how easy it is to do this as a reader), it's that I suspect many people are unaware that featured/GA content exists and that this means most of the text will have been peer-reviewed and undergone some methodical scrutiny, unlike the majority of articles. It also tells readers what to expect, rather than requiring them to pick up through their reading whether an article is accurate or not. Jr8825 • Talk 00:05, 7 October 2020 (UTC)

  My personal view is that most readers give their own personal judgment greater weight than an internally assigned icon, and thus the icon doesn't need additional prominence. isaacl (talk) 00:18, 7 October 2020 (UTC)

  @Isaacl: I'm with Jr8825 here; I strongly disagree that readers are sufficiently aware of the GA/FA system. Ask a non-Wikipedian in your life how the website indicates its highest-quality articles, and I suspect most people will be stumped. Similarly, ask them whether it's better for an article to have a bronze star or a circled green plus sign, and most won't have a clue. There's more than a little tragic irony when you think about it: we put a massive amount of effort into identifying which articles are worthy of being designated with our quality markers, yet because our user interface is so terrible, the 50% of readers on mobile don't see them at all and most of the desktop readers miss their meaning. {{u|Sdkb}} ^talk 00:39, 7 October 2020 (UTC)

  My assumption is the icon isn't visible enough to some readers to notice/process it, so it's not being factored in to their judgements at all. And my other presumption is that encouraging readers to be aware of and consider FA/GA status when they decide how much they trust what they're reading is generally a good thing. Jr8825 • Talk 00:46, 7 October 2020 (UTC)

  I agree that in all probability, many readers are unaware of what a bronze star or circled green plus icon means (that would be another worthwhile discussion: are there better icons or some other indicators that can be used?). In my view, though, I think readers place more importance on their own judgment than the evaluation of a pseudonymous set of persons within the Wikipedia community, and so giving the icons more prominence is unwarranted. isaacl (talk) 00:47, 7 October 2020 (UTC)

  On that tangent, to communicate article quality to readers, a familiar paradigm (1-star, 2-star, 3-star, 4-star) would be most recognizable and more easily understood than abstract icons. Use 1 for stub/start/nonrated, 2 for B/C, 3 for GA, 4 for FA. Schazjmd (talk) 00:58, 7 October 2020 (UTC)

  In such a scheme, I maintain that the distinction between B, C and GA is indistinguishable; they are all adequate at best, dangerous at worst. SandyGeorgia (Talk) 01:29, 7 October 2020 (UTC)

  I've been thinking about launching an initiative to redesign the GA/FA topicons for a while. You've inspired me to kick it off at the graphics lab: see Wikipedia:Graphics Lab/Illustration workshop#Good article and featured article topicon redesign. {{u|Sdkb}} ^talk 05:14, 7 October 2020 (UTC)

• I would support for mobile view (though note the subsection below) and am neutral on desktop view - other suggestions for prominence per Jr's rationale may be a better idea, unless the icon is put before the title to maintain a standard alignment. Kingsif (talk) 00:29, 7 October 2020 (UTC)

• Strong oppose: this is a well intentioned but very bad idea because it will mislead our readers even further. (As a regular FA participant, who also edits medical FAs, this potential misleading of readers would be critical wrt our medical content, most of which is not up to FA standards. See User:SandyGeorgia/sandbox2#Medical FAs.) We will be sending a more prominent signal to readers that the articles with some sort of icon next to their name have been checked, vetted, reviewed, or are somehow better than other articles on Wikipedia, but those readers won't necessarily have the skills or knowledge of Wikipedia to understand in what circumstances those icons are (or mostly, are not) still valid. Average readers probably don't know how to check the article milestones to discover when the article passed content review, whether the original authors are still actively engaged, whether the article has changed substantially since it passed content review, and whether the pass was a good one even when it occurred. With months-long efforts at WP:FAC and WP:FAR to get editors to actively engage in reviewing our out of compliance and very old FAs at Featured article review, we still have a considerable backlog of unreviewed older FAs (many more than those for which talk page notice has been given), and basically, no one is interested in engaging at FAR to deal with them. The situation with GA is even worse, as they start out as one person's opinion, and ... I can't even remember how long ago the last GA sweeps were. The situation now is obscure; the average reader probably doesn't know how an article is rated. But telling them more prominently that an article is well-rated when at least one-third of our FAs are not, and GAs were never more than one person's opinion, would mislead them even further. Article assessment is an internal matter that experienced editors know how to interpret: we can go to the talk page, look up the history, and say, "Oh, that article was passed ten years ago on only three supports, it has grown to twice the size since then, and the original editors are no longer watching, so the article has taken on lots of inaccurate cruft". The average reader might not be able to do that. We should keep assessments as an internal matter, that experienced Wikipedians know how to interpret. That the average reader doesn't know what the icon in the upper right hand corner means is just fine; let's not make a more prominent, and misleading, statement about the quality of our pool of GAs or FAs.
  Oh, and please go and nominate some articles, and review some articles, at WP:FAR. The pool of FAs is only as good as the worst of them. SandyGeorgia (Talk) 00:50, 7 October 2020 (UTC)

  I completely understand where you're coming from, the reason I feel differently is that I feel making FA/GA content more visible may encourage readers to understand how Wikipedia works better, particularly if they're encouraged to click on the icon and read more about how featured content works (see the example on the Danish Wikipedia, which has a tooltip saying This is a featured article. Click here for more information). Then all that's needed is a better explanation of what featured content is at WP:FA, as the current text just makes it sound like it's perfect. Honestly, I can imagine this being a great way to spread awareness to readers about how Wikipedia really works - i.e. any revision can be good or bad. Ed: And to me, it seems pointless putting in all the effort of ensuring FA articles meet FA quality, if readers are completely oblivious to their existence. Jr8825 • Talk 00:54, 7 October 2020 (UTC)

  I also can't see why such a tooltip couldn't say 'A version of this article was assessed as Featured in January 2010. Click here for more information'. Jr8825 • Talk 01:01, 7 October 2020 (UTC)

  That won’t work either. That would send our readers to a dated 2006 version for Tourette syndrome, which I have constantly maintained and overhauled. And, for a GA example, it would send our readers to the embarassing GA pass which misidentified a well know historical figure, Douglas MacArthur. I can provide worse examples of GA issues; I have already provided a list of medical FAs with issues. SandyGeorgia (Talk) 01:24, 7 October 2020 (UTC)

  Sorry, just to clarify, I didn't mean that the icon should send them to an old revision, just that the tooltip could also indicate when the assessment was made while encouraging viewers to click through (linking to WP:FA as it currently does). Jr8825 • Talk 01:27, 7 October 2020 (UTC)

  Same, regardless. Tourette’s passing in 2006 might imply it is no longer at standard. Which is misleading. SandyGeorgia (Talk) 01:32, 7 October 2020 (UTC)

  Perhaps 'This article reached Featured status in January 2010. Click here for more information'. (The German Wiki uses similar text.) Although I'm not sure whether it's a bad thing to say that a previous version was judged as standard, after all it's the most accurate statement and helps shows how much Wikipedia's quality varies with revisions. Jr8825 • Talk 01:35, 7 October 2020 (UTC)

  I think this is a perfectly reasonable concern about FAs, but it goes way beyond the scope of this discussion. What you seem to be proposing is that FAs/GAs have become so unreliable that they should not be considered reader-facing. Perhaps that's true, but that's a much larger discussion that would entail removing the topicons entirely and eliminating links to reader-facing pages like WP:Featured contents. For better or worse, the system we have right now is one that commits to making featured designation visible to readers, and so long as that's the case, we should make it work well enough that readers are aware of it as intended. If you want to change the fundamental purpose of the featured content system, you'll need to start a separate discussion about that. {{u|Sdkb}} ^talk 02:13, 7 October 2020 (UTC)

  I don’t believe I have typed what you are reading. SandyGeorgia (Talk) 02:39, 7 October 2020 (UTC)

  Finishing the thought. It is not a "concern about FAs"; it is a statement of fact about GAs and FAs, and a reminder that our processes only work if people use them. Participation has fallen off at FAC and FAR, while GAR is practically unheard of, relative to the numbers of old GAs. IIRC, GAs were last re-evaluated ten years ago. Wikipedia does not regularly re-assess articles at any level, and shouldn't pretend to our readers that we do (but on that score, FA does a better job than GA).

  Reading Wikipedia:Wikipedia Signpost/2008-06-23/Dispatches (How Wikipedia's 1.0 assessment scale has evolved) may help you understand that assessments are, and always were, internal processes, best understood to experienced Wikipedians, and unlikely to be understood by others.

  Sticking a link to WP:FA or WP:GA next to an article title is not going to increase reader knowledge about the pros and cons of those processes, or help them understand how to interpret them. Experienced Wikikpedians can look at a GA pass and say "that was a good pass" or "those were bad passes". Or that was passed so long ago, and the article has changed so much, it's no longer relevant. We are to serve the reader; giving them a link to something meaningless to them—while potentially misleading them about quality—does not serve the reader. And the only difference between B-class and GA-class is exactly one editor's opinion.

  As to how to best use this page, it might have been more productive to first get feedback and ideas at WT:FAC or WT:GAN before proposing something here. SandyGeorgia (Talk) 13:22, 7 October 2020 (UTC)

  You bring up some valid concerns here, but the discussions about the lack of participation in GA/FA, or whether GA/FA icons should be reader-facing at all are separate questions altogether. I appreciate your efforts to address broader issues with the review system, but this proposal just a narrow question about the location of icons on a page. The question is whether the upper right or next to the article name is a more clear location. You're right that there are other issues with the review process that need addressing, so I hope eventually we can address those other problems as well. 〈 Forbes₇₂ | Talk 〉 17:58, 7 October 2020 (UTC)

• I realize our icons our different, but the Danish example above reminds me a lot of blue checkmarks on Twitter (I'm not saying it's a bad thing, just a thing). As an alternative, we could put the icons to the left of the title but still right next to it. -- Calidum 02:28, 7 October 2020 (UTC)

  They have an extra tier below good article ("promising"), my first example wasn't the best as it's from that category. You can see a GA here. Jr8825 • Talk 02:33, 7 October 2020 (UTC)

• Oppose Rearranging icons is not helpful. We should assume that readers are interested in article content, not how attractively the icons appear. It won't help a general reader to see that a particular article is GA or FA or other, and the icons raise questions that distract from the content. Also, positioning the icons requires Javascript that seem unnecessary. Johnuniq (talk) 04:07, 7 October 2020 (UTC)

  My point is not about attractiveness. It's about whether a GA/FA icon is of any use to a reader (it seems I disagree with you, as I think it is helpful for the general reader) and whether it should be more visible. Jr8825 • Talk 04:30, 7 October 2020 (UTC)

• Just a note on the point of ~"non-Wikipedians don't care." In talking with hundreds of academics about Wikipedia over the years, including a whole lot of instructors who want to learn in order to help students learn about a site they use every day, they are almost invariably surprised to learn about GAs/FAs. They value these little symbols because it's one more tool in the information literacy toolbox that allows people to understand the content they're reading. It's not the only tool by any means, or even the primary tool, but the sheer volume of people who say (a) I never noticed that, and (b) that's very useful tells me changing the position may help.

On the subject of whether it would make any difference: Rather than just speculating that this would be helpful, though, maybe we should test it out. Wikipedia doesn't use cookies like other sites, but we can experiment in other ways. For example, display a topicon that links not to WP:GA but to a dedicated subpage of the article it's displayed on with similar information. Check the pageviews after a month, move it closer, check pageviews after a month. Something like that? — Rhododendrites ^talk \\ 13:22, 7 October 2020 (UTC)

• I agree with you generally, having also encountered this issue. But I view it not as a problem, rather as a good thing-- that the average reader is not misled into believing that every GA or FA they access is somehow recently vetted and approved. How about if someone were to run a bot and determine the dates on all of our GA passes; I wonder what that would reveal relative to the GA sweeps of a decade ago. I don't see it as helpful to mislead our readers into thinking that when they access a GA, they are necessarily accessing a dependable, reliable article. Also, I'm not sure what would be on this subpage your suggest? As in the examples I give above about Tourette syndrome ... we could at best show at 2006 FA pass, which doesn't address that the article is constantly overhauled and updated, compared to some 2010 to 2013 medical FAs that are now outdated. What would say on this subpage that would be digestible and understandable to a reader who doesn't understand the vagaries of a project that "anyone can edit", and where editors who once labored over the quality of an article move one, and the article goes to crap? SandyGeorgia (Talk) 15:33, 7 October 2020 (UTC)

• It seems like there are a few different things here. It would be good to have a process of reviewing promoted articles on a set basis, but as I think you were getting at above, we don't have the volunteer resources to keep up with the current backlog of initial reviews to begin with, nevermind re-reviewing. It's probably something best handled on a project basis, since there are a lot of historical articles, articles about books/media, etc. that don't really change much in 10 years while medicine, political figures, etc. certainly may. But on the next question of what could go on the subpage: I think it would be useful to explain what GA means, what it doesn't mean, and, along these lines, set expectations accordingly. A bot should be able to automatically create these fairly easily I imagine, including different blocks of text depending on how long ago the review was. Maybe even a faded icon if, say, 10 years have gone by. Maybe a link to the version that was reviewed and a link to the review itself. Of course that stuff is already on the talk page, but I think people would be far more likely to click a shiny icon next to the title than to find it in a sea of banners on the talk page. And the way we present it on the talk page doesn't provide much context. We can't really expect readers to click more than one additional link IMO... (I'm spitballing, in case it's unclear). — Rhododendrites ^talk \\ 16:24, 7 October 2020 (UTC)

• Oppose. While our FA process is helpful editorially, the tag necessarily ends up being applied unevenly. So many great articles are not FAs, and some that are, are not really that great. Making the FA tag more conspicuous will mislead our readers into thinking it has been uniformly applied, when in fact it hasn't. Paul August ☎ 15:12, 7 October 2020 (UTC)

It's fair to point out that a featured article isn't necessarily better written than any other article, it's just an article that has passed review. Ideally, I think we all wish that FA and GA status was a more reliable measure of relative article quality. However, even when that is not true, passing a review is represents the article has at least a certain level of absolute quality. We can work improving throughput for the FA/GA review, but let's not wait for a perfect process if the current one is already a net positive. 〈 Forbes₇₂ | Talk 〉 17:20, 7 October 2020 (UTC)

The process is good enough for its intended purpose, i.e. to motivate editors to improve an article. But not good enough (and never could be) for our readers to use as a reliable way to evaluate the quality of an article. But this is precisely what most readers will assume if we do this. Paul August ☎ 17:37, 9 October 2020 (UTC)

Why wouldn't it be a "reliable way to evaluate the quality of an article"? Reading the criticism about GA/FA that some users make here, I'm wondering why we even bother with assessements and reviews. T8612 (talk) 21:28, 9 October 2020 (UTC)

As I've tried to explain above, it's unreliable because of the fact that the process is not applied uniformly. Most article's are never reviewed, and lack of review is not a measure of quality. And the quality of reviews that are done are uneven. Both of these problems are intrinsic to the bottom-up nature of our project. But, that doesn't mean that the reviews don't serve a useful purpose, because they do! They help improve articles ;-) Paul August ☎ 12:16, 11 October 2020 (UTC)

But, precisely, we lack reviews because most users don't know about GA/FA. If we displayed icons more prominently we could expect more people to engage in the reviews. I discovered about the review process on an user's talk page. T8612 (talk) 15:44, 11 October 2020 (UTC)

The main reason we lack reviews is because the costs are high and the rewards are low. No matter how well publicized the review process is, only a tiny fraction of our articles will ever undergo that process. So while making the FA/GA icons more conspicuous might increase that tiny fraction by another tiny fraction—it will do so at the cost of misleading our readers. Paul August ☎ 20:50, 11 October 2020 (UTC)

• Do not use icons at all. The above comment from Rhododendrites is anecdotal evidence that readers often do not "notice" the icons at all. Label a Featured Article with the text "Featured Article" and a good article with the text "Good Article". Extend these labels to give the date when the status was awarded and have the status "fade" over time. — GhostInTheMachine ^{talk to me} 15:24, 7 October 2020 (UTC)
• Oppose. Admittedly, I'm a little biased in that I have the gadget that changes the header color to match the assessment, but leaving aside that I share some similar concerns as Sandy. I think the comparison made upthread about "verified" badges and similar is a solid one, but my concern dovetails with that connection—FAs are generally quality work, but literally putting the star or plus side right next to them implies a level of official certification that is writing a check we can't back up. Der Wohltemperierte Fuchs ^talk 23:11, 7 October 2020 (UTC)
• Support A/B testing the idea per Rhododendrites. These icons help with advancing information literacy by alerting readers to the state of our content in the same way that all of our cleanup-banners do. There is a very real possibility that this could actually improve not only reader engagement, but create a greater incentive for editors to use the content review processes. We should be able to test it out on a few pages to see if the change causes the effects we want. We could create Wikipedia:Good article topicon placement test control and Wikipedia:Good article topicon placement test manipulation as a redirects to Wikipedia:Good articles. For pages in the control group, the topicon would be in the usual place, and for those in the manipulation group, the topicon would be closer to the title. If changing the location is actually effective, we should see more page-views in the manipulation group than the control after a few months (normalized by daily page-views probably since some people will click on things just because it's new). We could even do second round tests where one of the redirects is turned into a reader-facing info page on our quality review processes, or add links to the article's review page so readers can easily audit our review processes and come to their own decisions about the reliability of the quality rating. We should come up with a testing plan before doing this, but I think this is an interesting enough idea to try it out for a bit. — Wug·a·po·des​ 01:01, 8 October 2020 (UTC)

  Wugapodes, sounds good to me. To be clear, WP:GA and WP:FC are already supposed to be reader-facing pages (the latter was linked from the left sidebar until a few months ago). To the extent that they've drifted from that intended state, that's been because of unwanted creep. {{u|Sdkb}} ^talk 06:02, 10 October 2020 (UTC)

• Support A/B testing the idea per Wugapodes. I personally don't like the idea aesthetically, but we should focus on function over form, and testing the idea a bit seems entirely reasonable. On a separate note, I maintain* the "metadata gadget" that retrieves article ratings and highlights them in the tagline and title, and highlighting article ratings in an icon or icon-like format beside the title was a proposal that MGalloway made while employed at the WMF, with the idea that it would help colourblind users. I rejected the idea at the time: icons requiring a hover interaction would be strictly worse than the current text-focused approach of "put all the info as text in the tagline and provide 'bonus' colouring in the title". However, she mocked up some ideas that are to date still unarchived at MediaWiki talk:Gadget-metadata.js, which might be relevant here for design purposes. (*I haven't done much recent maintenance at all, in part because I haven't picked up the interface admin right I'd now need to edit it directly, but that's a different story.) {{Nihiltres |talk |edits}} 17:41, 8 October 2020 (UTC)

• Oppose a strong reason hasn't been given --Guerillero | Parlez Moi 03:20, 9 October 2020 (UTC)

• Oppose per Paul, I don't participate in the GA/FA area however if what Paul says is correct then these shouldn't be used next to titles and shouldn't further mislead our readers. –Davey2010^Talk 13:26, 9 October 2020 (UTC)
• Oppose per SandyGeorgia and, especially, Fuchs. Avis11 (talk) 15:34, 9 October 2020 (UTC)
• Support Somewhat tentatively as good points are raised regarding quality control. However I feel this should be an all or nothing case. If we are hiding the icon away because we don't trust the process then we should not even be displaying it. I think an advantage in making it more visible is that editors unfamiliar with GAs and FAs might become aware of them and choose to partake (even if it is just to point put an article is not up to standard). We lack volunteers for reviewing and even more so for reassessing these articles, so to my mind we need to be encouraging editors to get involved any way possible. It might even lead to better quality control. AIRcorn (talk) 21:35, 9 October 2020 (UTC)

• Oppose per SandyGeorgia and Fuchs. I think this proposal had good intentions. I have also talked to non-editor friends and family members about Wikipedia, and none of them knew about the content assessment systems, but I think the benefits are outweighed by the concerns brought up by SandyGeorgia and Fuchs. It is nice though to see an active discussion about this. Aoba47 (talk) 21:38, 9 October 2020 (UTC)
• Support on testing - the GA/FA icons are unnoticeable to the casual user, and obviously in mobile too. If the icons are displayed more prominently, it may encourage more users to participate in these content assessment processes. There's a huge backlog in GA/FA, so the more users who take an interest, the better. What is the point of GA/FA then - why would editors spend so much time improving articles, only for them not to be noticed? I understand there are many poor quality GAs/FAs, and we don't want to mislead readers, but perhaps one solution is to display a disclaimer of some sort - that Wikipedia doesn't guarantee the accuracy of these articles even though it's a GA/FA. (I would hope that the average reader with a bit of common sense and intelligence knows that Wikipedia is editable by anyone!) For me though, it is about making these review processes more accessible and transparent to the casual reader. It doesn't give us, editors, much confidence in Wikipedia, or our processes for that matter, if we keep the GA/FAs obscured from readers! L150 18:23, 10 October 2020 (UTC)

• Oppose (a) on aesthetic grounds, (b) because, per SandyGeorgia, it would elevate these often very inconsistent reviews to a misleading status, and (c) because it's completely unnecessary - the small coloured icons at the top right are quite eyecatching in any case and I very much doubt they are missed by readers - they are usually the first thing I notice when I open an article page and I doubt it's different for others. All the other icons are displayed in the top righthand corner and for consistency that's where they should stay. Gatoclass (talk) 15:38, 11 October 2020 (UTC)

• Oppose per Gatoclass Asartea ^{Talk | Contribs} 15:45, 11 October 2020 (UTC)
• Support a test/trial, per Wug et al. ProcrastinatingReader (talk) 22:48, 11 October 2020 (UTC)

• Oppose. Gatoclass has summed up my opinion perfectly: (a) it's ugly (b) it elevates a misleading metric, and (c) it's already eyecatching. — Goszei (talk) 07:04, 16 October 2020 (UTC)
• Oppose - I do get the reasoning, but I feel it radically stresses its status and looks visually cluttered. Having FA status stressed isn't that big of an issue to me, but it's perhaps more of a concern with GAs - we know what is involved in a GAR, but others do not. They do also seem fairly eye-catching to me, but I'm willing to accept that I don't know what a general reader's view is on that. The desktop/mobile split isn't ultra clear, so I would say that I am support for this on mobile, if you can get it to work. Nosebagbear (talk) 09:40, 19 October 2020 (UTC)
• Remove icons altogether. The majority of our best articles don't go thru the FA process because our best writers rarely waste their time with the GA/FA process. I am sure most will agree that FA GA criteria does not necessarily mean a good article years after the fact. All that rant said.... the proposed icons do look better and placement wouldn't change prominence in my opinion...thus Support ....someone should suggest vital articles have more prominence over GA articles that no longer meet the criteria.--Moxy 🍁 00:42, 22 October 2020 (UTC)

Mobile display

Tracked in Phabricator
Task T75299

@Eddie891 and Peacemaker67: You both mentioned mobile view in your !votes. There currently isn't any way to display topicons in mobile—see Wikipedia:Village pump (technical)/Archive 183#Featured/GA topicons for mobile—so GAs/FAs aren't currently being identified. There's a phabricator ticket for the issue but it has not yet been resolved. I suggest we stick to discussing desktop display above and discuss mobile here. {{u|Sdkb}} ^talk 00:26, 7 October 2020 (UTC)

• OK. The lack of mobile topicons on mobile is highly problematic. Readers need to be easily able to see what the quality of the article they are reading is. I don't use the mobile version often, but am aware that many readers do. This should be a high priority in terms of development, as article quality is at the centre of what we do on WP. Peacemaker67 (click to talk to me) 00:51, 7 October 2020 (UTC)

  Agreed. I commented on the phabricator ticket, but I've never quite figured out how to boost a development task's priority; it seems to be mainly up to the whims of the WMF folks. {{u|Sdkb}} ^talk 01:57, 7 October 2020 (UTC)

  Most developers are volunteers like you, not WMF employees, so the best way to increase a task's priority is to volunteer to fix it. Creating a phab task is like placing a cleanup template on an article: unless you plan to fix it yourself, the request will probably just languish until someone cares enough to get around to it. Unlike cleanup tags, there's far fewer hands on deck to fix non-critical phab tasks. — Wug·a·po·des​ 01:10, 8 October 2020 (UTC)

  Add it to the {{Short description}} like this. It will appear in the search but, like the short description, it will not appear at the top of the page. Or you could have another template that could use "FA", "GA", "Polar bear liver", etc and explain what the ratings mean. CambridgeBayWeather, Uqaqtuq (talk), Huliva 14:40, 8 October 2020 (UTC)

  I see what you mean, but please do not add other semantics to the short description — it should be a description only. If the FA/GA status is output as text then the mobile display would also show it.

  (Depending on how the short description is edited, it may also be pushed into Wikidata, which means that the FA/GA tag may incorrectly show up in article for other other WPs.) — GhostInTheMachine ^{talk to me} 18:01, 8 October 2020 (UTC)

  I didn't intend to do it but the Wikidata short description is no longer imported to the English Wikipedia. All short descriptions are here. CambridgeBayWeather, Uqaqtuq (talk), Huliva 03:49, 9 October 2020 (UTC)

  Wugapodes, many times a WMF team needs to sign off on it, though. In this case, technically enabling it on mobile is not difficult (it's a few lines of code, I've done it on my local install). The issue is that the design team needs to sign off on it and decide where to place it. That's where the task is currently jammed. ProcrastinatingReader (talk) 15:38, 10 October 2020 (UTC)

Discussion

I would find it sad if this proposal ends up at no consensus→default to no action. As I've discovered through experience, making design changes to Wikipedia is hard, even in situations where change is clearly warranted, since not only does the consensus system favor the status quo by default, but editors' human tendency to prefer the familiar can also make it seem like proposals aren't as desirable as they'd seem if everyone was forced to live with them for a week before !voting on them. If this doesn't win outright support, I'd hope it'd be possible to at least try out the A/B testing, which is a much less disruptive action and should therefore require a somewhat lower bar to activate. The point is not to throw caution to the wind, but I do think we need to be less afraid of a little more design experimentation. As a result of the above factors, Wikipedia's design is notoriously outdated compared to other major websites, so there's a lot of room for improvement. Trying out a new position for the star icon won't bring about the apocalypse. {{u|Sdkb}} ^talk 05:44, 10 October 2020 (UTC)

It's why I said I disagreed with the premise. In order to do A/B testing, there needs to be an agreement on success criteria, and for that, there has to be an agreement on a problem statement. isaacl (talk) 07:09, 10 October 2020 (UTC)

My opposition, along with others, has nothing to do with "favoring the status quo", nor from a "fear of design experimentation". Rather it has to do with the fact that this change will mislead our readers. Paul August ☎ 16:38, 10 October 2020 (UTC)

Besides what Paul August says (that I agree with), I see several other issues here. First, it can be less hard to make design changes if you first consult the groups of editors most involved in or affected by what will be changed. You did not discuss this before with either GAN or FAC, where you might have heard the problems with your proposal. I doubt that many FA or GA participants are unaware of the shortcomings, pros and cons of those processes. Second, there were attempts to stifle the discussion here by several parties, indicating a lack of understanding about how consensus is formed. We don't just "yea or nay"; we explain our reasoning and discuss. And yet, two different editors discounted my reasoning, saying to take it elsewhere, this isn't the page ... although I was only explaining my reasoning for opposing. They didn't seem to understand that one SHOULD explain their reasoning. Third, you then went on to another proposal, about redesigning the icons, again without consulting with the involved pages or seeming to understand that the A,B,C, start, stub are WP assessments, GA is one-person, and FA is a community-wide process. If you will take the time to consult-- and listen-- you might find a lower number of failed proposals at design changes. SandyGeorgia (Talk) 22:44, 10 October 2020 (UTC)

@SandyGeorgia: I don't feel your characterisation of my suggestion as being naive or attempting to exclude regulars is fair. The village pump seemed to be the obvious place to make this suggestion, I wasn't at all attempting to bypass FA/GA participants and I'm very glad that others more familiar than myself with the bureaucracy notified the relevant talk pages. It didn't occur to me to bring up my suggestion at these places because I wasn't aware of their existence (also, a site-wide visual change seems out of the scope of those venues). I explicitly asked for feedback on my original statement and while it's shame we don't all see eye-to-eye I actually thought the discussion above was very valuable. Personally, I didn't think Sdkb and Forbes72 intended to stifle the discussion or discount your argument, both acknowledged you raised an important point and I thought they were trying to explain why they disagreed in this context. Ultimately this is a straw man, as it detracts from the main reasons you disagree with the suggestion, particularly that there's a risk of making readers feel the reliability of what they're reading is guaranteed.

I agree that this is the biggest issue, and I acknowledged this when I outlined my rationale. The discussion above has definitely reiterated the current FA/GA system's flaws, and this may, on balance, mean that my suggestion is unpalatable to the majority of editors here, which I would understand. I explained why I myself think the change could be beneficial overall at the start of the discussion: the layout could encourage readers to click to find out more about FA/GA, and this could increase awareness among readers and editors of how Wikipedia's internal processes work; it will more effectively promote the best work we have; if more readers were aware of FA/GA, it might produce greater scepticism towards other long articles that look well-written but have failed or not gone through peer reviews; most readers are already aware that Wikipedia is unreliable. The next thing that occurs to me is to only trial moving the featured star, as only featured content should be "featured" because only it has gone through a group peer review, rather than an individual one. Jr8825 • Talk 01:21, 11 October 2020 (UTC)

@SandyGeorgia: I raised the objection that your concern (which I actually agree with—I brought a page to WP:FAR not long ago that survived as a FA for way too long; you're clearly a passionate crusader for the issue and I'd be happy to see it discussed more elsewhere) was out of scope of the present discussion. I stand by that concern. You are arguing that FA/GA designations are unreliable, and there are only two ways to apply that to this discussion. The first would be to say that they're so unreliable that FA/GA designations should not be reader-facing, which is what I responded to above. That's a change that would overturn a longstanding consensus, and would require its own discussion; I expect that the closer will ignore !votes like GhostInTheMachine's (for not displaying stars) that are clearly speaking to that discussion, not this one. The second would be to say that they're reliable enough to be presented to readers but not reliable enough to be presented to readers in a way that they're likely to actually notice. That's a nonsensical way to parse things: either it's good for readers to know the FA status of an article or it's bad, and we need to stand by whatever we decide.

Regarding your attempt to pull rank based on your more active GA/FA participation, that's not how Wikipedia works. We value expertise, and the relevant projects have been appropriately invited to this discussion, but we also value input from a broad range of editors, including those less in the trenches who can often bring outsider's insights. (And if you want to get into qualifications, you may want to figure out who the most active and successful design/usability editors are.) {{u|Sdkb}} ^talk 03:18, 11 October 2020 (UTC)

Can the rhetoric be ramped down a bit? I don't think it's necessary to describe reasoning other than a good or bad interpretation to be nonsensical. And I don't think it is necessary to tell people who are engaging in discussion to consult and listen. I appreciate that it is disquieting for discussions to follow different paths than one might feel is optimal. For better or worse, there are always going to be slipups in communications. I trust we can overlook them and seek out common ground. isaacl (talk) 04:04, 11 October 2020 (UTC)

This seems wise. @SandyGeorgia: Admittedly, it's been a while since I've done anything with GA reviews, so maybe it would be a good time for me to help with the backlog. There's obviously some disagreement above, but we're all on the same team here. 〈 Forbes₇₂ | Talk 〉 04:34, 11 October 2020 (UTC)

How aware are readers of GA/FA?

There's an empirical factual question here that seems to be influencing many !votes: To what extent are non-editing readers noticing the icons and aware of their significance?

On one side, JR8825 offers that in their survey of a couple of non-editor friends, none knew about it. Rhododendrites asserts In talking with hundreds of academics about Wikipedia over the years, including a whole lot of instructors who want to learn in order to help students learn about a site they use every day, they are almost invariably surprised to learn about GAs/FAs. Aoba47 concurs: I have also talked to non-editor friends and family members about Wikipedia, and none of them knew about the content assessment systems.

On the other side, we have Gatoclass's assertion, bolstered by subsequent "per" !votes, that the small coloured icons at the top right are quite eyecatching in any case and I very much doubt they are missed by readers - they are usually the first thing I notice when I open an article page and I doubt it's different for others. Guerillero argues a strong reason hasn't been given for a change, likewise dismissing that there is any problem.

Since this is a factual question, whichever side is incorrect should be appropriately discounted by the closer. What I notice is that everyone so far who has actually asked non-Wikipedians has found them unaware, whereas those arguing they are surely aware have provided nothing except speculation. This comes across to me as a classic example of the difficulty of putting ourselves in readers' shoes (a problem CJK09 has written eloquently about): yes, of course the GA/FA icons stand out to us, since we all already know about GAs/FAs; that doesn't mean they will to our grandparents. It would be ideal if we could uncover some formal research into the question, but in the absence of that, all the evidence so far seems to point to readers being largely unaware. {{u|Sdkb}} ^talk 22:33, 21 October 2020 (UTC)

(Yes, I'm aware some portion of the !votes/discussion above focused more on the question of how aware readers should be than the one of how aware they are. I am posing solely the are question here, since the should question has already been considered at length above.) {{u|Sdkb}} ^talk 22:33, 21 October 2020 (UTC)

Redundant templates on biographies

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.

---

According to their documentation, {{COI}} and {{autobiography}} are mutually exclusive. Consider:

{{COI}}

This tag is not generally used to notify readers that an article appears to be partially or wholly autobiographical. If this is the case, please use the more-specific {{autobiography}} tag. An exception to using the autobiography tag is when such use would reveal the identity of a Wikipedia editor.

{{autobiography}}

This tag is more specific than the widely-used {{COI}} template. It should be used preferentially to that template when the article in question is not only affected by a conflict of interest but when that conflict is specifically autobiographical in nature.

and yet according to this search, there are currently 206 articles that have both.

I propose requesting a bot to remedy this; can we agree that in each case, {{COI}}, being the less-specific, is the one that should be removed? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:22, 9 October 2020 (UTC)

Pigsonthewing, Sounds like a solution in search of a problem. S Philbrick(Talk) 21:34, 9 October 2020 (UTC)

You're in luck - I already found the problem: 206 articles that have two cleanup templates where they should only have one. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:43, 10 October 2020 (UTC)

• Sounds good. I'd suggest just bringing this up at WP:BOTREQ directly; no need to go through the pump, since BOTREQ is a discussion forum itself. I disagree with Sphilbrick above; having too many banners on a page is clearly a problem. {{u|Sdkb}} ^talk 22:35, 10 October 2020 (UTC)

  Pigsonthewing, I'm going to guess that it'd be faster to manually remove the tags than to get the bot approved. WhatamIdoing (talk) 04:53, 14 October 2020 (UTC)

Redundant source needed templates

Similar to the above, we have many articles with both {{More citations needed}} (aka {{Refimprove}}) and {{One source}}; can we remove the former in such cases?

We'd need to avoid cases where a template is used on a single section, such as Pretoria#Jacaranda city. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:35, 9 October 2020 (UTC)

{{Refimprove}} is explicitly about WP:V, but {{One source}} may also imply a WP:POV issue.

But on a similar note, {{Refimprove}} and {{More footnotes}} are redundant. – Finnusertop (talk ⋅ contribs) 01:15, 10 October 2020 (UTC)

On your former point, what impact would removing {{Refimprove}}, as proposed, have? I agree with your latter point; there are 5,539 such articles. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:45, 10 October 2020 (UTC)

This is a bit more difficult, because some of them (example) use the {{one source}} tag only for a specific section.

Also, many of these are outdated and should just be removed outright. The example I linked is for a section containing more than one source. WhatamIdoing (talk) 04:56, 14 October 2020 (UTC)

As I wrote above, "We'd need to avoid cases where a template is used on a single section". I agree that many instances are outdated and should be removed (something that applies to all of our cleanup tag, and is something we're very bad at dealing with), but that's orthogonal to this issue. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:09, 14 October 2020 (UTC)

Request submitted

See Wikipedia:Bot requests#‎Redundant template pairs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:58, 21 October 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.

Double-click option

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'd like to propose that Rollback and Logout actions require a double-click to confirm (e.g., "are you sure"?), either by default or as an option available at User Prefs. Currently, especially on small-screen mobile phones, it is all too easy to mistakenly click these buttons unintentionally. Although some js gadgets work for Rollback, depending on os, it's not completely effective.  JGHowes  ^talk 18:44, 11 October 2020 (UTC)

It's already an option for rollback under gadgets, though perhaps that's what you are referring to. 331dot (talk) 19:05, 11 October 2020 (UTC)

331dot I think the gadget is broken. ProcrastinatingReader (talk) 22:51, 11 October 2020 (UTC)

@ProcrastinatingReader: for log out, please see the above section: Wikipedia:Village_pump_(proposals)#Log_out_second_chance. For rollback, please see Confirmation prompt for rollback action workboard for the related tasks. Having these capabilities invented in a non-gadget method will require those development tasks to complete - at that point we may have some choices about opt-in vs opt-out for certain combinations (e.g. logged in status / browser type / mobile app). Is there any thing else specific you want to cover in this thread? — xaosflux ^Talk 13:46, 16 October 2020 (UTC)

Thanks, Xaosflux. I didn't see the above section and have now commented there re the desirability of double-click for Log out (and Rollback too, imo).  JGHowes  ^talk 17:48, 16 October 2020 (UTC)

Xaosflux I think you meant to ping JGHowes? (I was just replying to 331dot re the rollback gadget suggestion, as I believe the gadget, at least the mobile one, is broken). I suppose the core software functionality is tracked by T219781, which probably won't get far anytime soon, but it'd be nice to fix our local gadget if we can figure out what's wrong with it. ProcrastinatingReader (talk) 16:40, 16 October 2020 (UTC)

Oops, yup :D Also opened a thread at MediaWiki talk:Gadget-confirmationRollback-mobile.js. — xaosflux ^Talk 16:54, 16 October 2020 (UTC)

• I'm closing this section - for rollback, it is a core feature now, see Special:Preferences#mw-prefsection-rendering, "Show a confirmation prompt when clicking on a rollback link". For logout - see the section above. — xaosflux ^Talk 02:24, 20 October 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.

Service awards

Service award eligibility is currently based on "the number of contributions that the editor has made to Wikipedia and the length of time registered". I believe that a user's average edit size (which can be seen on https://xtools.wmflabs.org/) is at least as important as these criteria. If a person contributes a great deal but have made a fairly small number of large edits, while another person contributes a very good deal but each edit is very small, the latter may end up with a higher rank even when they are somewhat less responsible for the site being as strong an information source as it is. It's not a massive problem, but I feel that the sort of change recommended would result in the service awards system better reflecting which people are the most significant contributors to Wikipedia. There are various reasons why not all of them would be among the most prolific. AndrewOne (talk) 19:43, 11 October 2020 (UTC)

I agree. Using the number of contributions alone could encourage bad behaviour of making multiple small edits instead of bigger ones. I think the number of Good/Featured articles should be taken into account. T8612 (talk) 20:21, 11 October 2020 (UTC)

Ah yes, yet another form of WP:Editcountitis. --Izno (talk) 20:37, 11 October 2020 (UTC)

My average edit size is -122.5 bytes. I am not sure how this represents anything useful. Not to sound too dismissive of your attempt to improve these "awards". But I feel like this is a pointless solution, because the idea that service awards have any solution is a flawed premise. It's a metric applied to a subjective measure, so you can never use it to judge anything objectively. All you would be doing is just adding more rules and factors to it. Here's another extreme hypothetical: what about someone who reviewed and tagged a thousand speedy deletion candidates versus someone who added "lol penis" to an article and got reverted and banned. The latter editor is still higher rank, because all the former editor's edits are deleted but the latter one has +9 content addition. —  HELLKNOWZ   ▎TALK 20:55, 11 October 2020 (UTC)

I can't get an average; I only get: User has made too many edits! BD2412 T 21:04, 11 October 2020 (UTC)

Wow! 1640315 edits since: 2005-02-20, is that a record? Doug Weller talk 08:42, 17 October 2020 (UTC)

Yeah, that's a problem. People are making too many edits on Wikipedia. Including me, obviously. --A D Monroe III^(talk) 21:17, 11 October 2020 (UTC)

Edit count is and always has been a very crude measurement. We could try to adjust for edit size, semi-automated vs. manual edits, etc., but it's a Sisyphean task. The only realistic thing we can do is de-emphasize edit count and inform people about its limitations as a metric.

Personally, I find it useful mainly for new editors. 5 edits is different from 50 is different from 500, but after a few thousand, I just lump everyone into the same "experienced editor" category. {{u|Sdkb}} ^talk 22:21, 11 October 2020 (UTC)

User badges are all self-assigned, so feel free to devise any ranking system that pleases you. isaacl (talk) 22:29, 11 October 2020 (UTC)

The service awards carry no official weight and mean less than nothing. They time it has taken you to type your initial post and read these responses is more energy than you should have expended on the issue of qualifications for them. --Jayron32 17:48, 12 October 2020 (UTC)

• Does any one think that basing service awards on the number of edits an editor has made could encourage Wikipedia: Editcountitis? Vorbee (talk) 10:40, 15 October 2020 (UTC)

Yes, I've said it above. T8612 (talk) 10:43, 15 October 2020 (UTC)

Many factors tend to make edit counts useless. For someone like me who couldn’t give a rats about them, I have discovered that editing on an iPad will frequently result in loss of entered text when opening a reference or an information screen and then returning to the edit screen. Thus my edit count when using this method is typically 5 or more times that on a computer for a small article with a small number of references and lookups. Downsize43 (talk) 23:48, 15 October 2020 (UTC)

They are just for fun. As has been pointed out, there is no solution, and no one should care if people do acceptable edits to get an award, and if they are bad edits, well that's what blocks are for. Doug Weller talk 08:42, 17 October 2020 (UTC)

Wikipedia - Not a Newspaper - 2020 Nagorno-Karabakh conflict Article

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'd like to make a proposal regarding inclusion of "breaking news" in Wikipedia articles, specifically the 2020 Nagorno-Karabakh Conflict article. If you look at the timeline section of that article, there is a lot of reporting from official/government outlets about attacks and denials of attacks. As we all know, Wikipedia is not a newspaper. I suggest we put a hold of at least 24-48hr on adding ongoing news, to give time for them to be consolidated, and to secondary sources to verify the claims and the neutrality of the claims to be established. With the current arrangement, there is a risk that a Wikipedia reader will get a one sided view of what is happening on the ground. This is also necessitating extra work to bring in secondary sources to verify these claims, which may not need to be in the article in the first place, again given that Wikipedia is not a newspaper --Sataralynd (talk) 16:30, 17 October 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.

Evaluating vandalism allegations and a vandalTraceBot?

In the last four days, @Suffusion of Yellow: reverted three very similar edits to the Wikipedia article on "political corruption" that were obvious vandalism, all three written as if the current US presidential election was over, and the recent revelations in the Biden-Ukraine scandal "ended Corrupt Joe's chances of being elected President," and he lost the November 3 election by a landslide, in the first two cases, and "the Democrat pedophile candidate lost by huge margins on November 3" in the third. These three cases of obvious vandalism were by User:Grayindie, User:Indanon, and User:Joscack.

Does the Wikimedia Foundation currently have anything like a "vandalTraceBot" that could do something like the following:

1. Once invoked, the "vandalTraceBot" could identify other recent changes by a suspect user and present them for manual evaluation by a human in reverse chronological order.
2. The evaluator would be asked to rate each edit on some scale with levels like "good substantive edit", "minor, not vandalism", "edit farming", "questionable and without a reference", "blatant vandalism", "questionable edit citing an apparently irrelevant source", and "substantive distortion of a cited reference" (scale ranging from positive to evil to destructive editing that is difficult to detect).
3. After an evaluation had been recorded, the user would then be informed of whether the edit had been reverted, shown the current status of the article and passage in question, and invited to modify it themselves or helped in posting a request on the Talk page asking two or three users with reasonable edit records active in that article to review a selected passage that sounds a bit strange to the reviewer.
4. The "vandalTraceBot" could also optionally look for other other users using the same IP address and other similar IP addresses and anonymous edits from any of those IP addresses and possibly related IP addresses. Lists of likely sockpuppets could also be consulted and included in the evaluation. (What percent of identified sockpuppet groups use the same or similar IP addresses?)
5. The tracing effort of each potential vandal and IP address would be scored, so it's easy to identify users and IP addresses that actively work against the mission of the Wikimedia Foundation.
6. A record of each such trace would saved for review by a Wikimedia administrator and / or a committee of users, who volunteer to do this kind of work. The most blatant perpetrators of vandalism can be blocked, possibly after a more careful review of their recent edits that were not marked as vandalism or substantively biased editing.
7. To help document the impartiality of this audit process, this evaluation should follow a standard blinded experiment protocol: People who volunteer to be evaluators would be asked to evaluate other users in pairs, one having been reported and one other selected at random, presented in a random order. This data analysis could also help estimate the rate of undetected vandalism as well as evaluate the reliability of reports of vandalism while also helping improve the quality of Wikipedia.

If a capability like this currently exists, how can I learn more about it? If you don't know of any such capability, what do you think about creating such?

I recently asked @Muboshgu: about something like this, who replied, "I think such a tool could be incredibly useful and have no idea how one would go about creating it. There are pages for bot requests or you could discuss it at the Village pump."

User:Suffusion of Yellow wrote, "FYI that user has been going at it for a while. See WP:Sockpuppet investigations/Fishguyen. Any help in stopping them is appreciated."

Thanks, DavidMCEddy (talk) 12:39, 19 October 2020 (UTC)

I mean, blatant perpetrators of vandalism are already blocked, to the tune of dozens every day and thousands every year. I can't see them ever reaching a step of review of high-vandalism rates, since they'd already be blocked Nosebagbear (talk) 19:23, 19 October 2020 (UTC)

I agree that Wikipedia does not have a huge problem with blatant repeat violators, like User:Grayindie, User:Indanon, and User:Joscack, all of whom may be sockpuppets of Fishguyen, if I understand correctly the comment from @Suffusion of Yellow:.

Wikipedia has bigger problems with more subtle "substantive distortions of cited references", which I mentioned.

Permit me to suggest another use case and a modification of the above to deal with that: User:X accuses User:Y of edit warring or stalking.

It should be possible to compile data on the time between an edit by User:X and a subsequent one by User:Y and vice versa, also keeping track of the cases where X or Y made edits without one being followed by the other. Blatant stalking should become obvious from this kind of analysis.

Edit warring is more subtle. We could do statistical evaluations similar to those for stalking but then supplement those with human evaluations, as described above.

For that we'd need two evaluators: One would be asked to compare User:X with a control. The other would be asked to User:Y with a control. Evaluators would then also be asked if they perceived that either the case or the control was involved in an edit war, and if yes, the extent to which each side was handling the conflict inappropriately.

It's certain that Wikipedia has a problem with paid editors trying to burnish the image of their employers and attack their employers' opponents. This evaluation methodology using something like a vandalTraceBot would produce data on (a) the level of such activity among users chosen as controls, (b) how often users misjudge others, inferring motives that don't seem to be there when evaluated by a third party, and (c) how often users complain about others when they seem to be a major contributor or even the primary instigator of edit wars.

Thanks for questioning the need. We shouldn't develop an expensive methodology to solve a problem that is handled more easily, cheaply and adequately by currently procedures. DavidMCEddy (talk) 20:05, 19 October 2020 (UTC)

@DavidMCEddy: No, I meant I hadn't really read the proposal, and was just filling you in on that one vandal since you pinged me. :-) Reading it now, it looks like you're suggesting flagging (privately to CheckUsers) IPs that have been used repeatedly for vandalism from multiple registered accounts? This sounds like Wikipedia:Village pump (proposals)/Archive 169#Proposed: a massive automated invasion of privacy for the greater good. Except, instead of reporting everyone, you'd just report users that trusted users think are vandals. That's much saner than the original proposal, which would have basically overturned WP:NOTFISHING.

But, I'm not sure we'd need an elaborate scoring system. Just have a bot that looks for indef blocks with "vandalism" or "spam" in the summary, and if more than N in a 90 day window have the same underlying IP, contact CUs somehow. The idea of a CU-enabled bot makes me twitch though. Security is hard. Suffusion of Yellow (talk) 22:12, 19 October 2020 (UTC)

Another edit to "political corruption" with essentially the same message in different words was just made by user:WokyBond and reverted 60 seconds later by user:Greyjoy. I don't have tools to confirm that this is a sockpuppet, but it looks like one to me.

I agree that this is not a big enough problem to justify any substantive effort just for this. However, Wikipedia has more serious problems with biased editing, and something like that could help characterize the magnitude of those problems. DavidMCEddy (talk) 05:50, 21 October 2020 (UTC)

List Actual Articles Rather than Talk Pages in Category:Articles_by_quality

When searching for articles by quality, the articles shown and linked as examples of the searched quality are listed as the Talk pages rather than the actual article. Ex: Category:FA-Class aviation articles.

This is confusing because of implication that the talk pages themselves are the examples of FA, GA, C, or other quality standards. And when you click, the link still takes you to the Talk page rather than the article.

Ex: To find out that the 509th_Composite_Group is an FA article, need to click through: A) Category:FA-Class articles (no obvious sign that these link the Talk page), then B) Category:FA-Class aviation articles (suddenly all Talk pages?), then C) the Talk page itself Talk:509th_Composite_Group (does note that 509th Composite Group is an FA article, might still be confusing), before you finally land on D) the actual 509th_Composite_Group and see the tiny star in the upper right corner.

(Also, minor note: is there a reason Category lists can't be linked by a variation of the [[Category:Category_Name]] format rather than {{Cl|Category_Name}}? Most other pages in a group on Wikipedia such as Talk can be linked simply by cut-pasting the browser bar.)

Suggestion: List the articles themselves rather than the talk pages. Araesmojo (talk) 21:23, 19 October 2020 (UTC)

Araesmojo, see Wikipedia:Village_pump_(proposals)/Archive_169#Allowing_pages_to_be_categorised_by_tags_on_their_talk_page, and courtesy ping Naypta. {{u|Sdkb}} ^talk 05:50, 20 October 2020 (UTC)

That is a significant wall of text. Is the connection because Naypta's proposal {{#pageCat:The category you want}} may have affected or might affect this change, or because the user knows more about this topic than many? Either way courtesy ping @Naypta: and thank you for the response. Araesmojo (talk) 19:17, 20 October 2020 (UTC)

@Araesmojo: To answer your second question, you can link directly to categories with [[:Category:Category name]] (which is all {{Cl}} does). The reason [[Category:Category name]] doesn't work is that this syntax is used for putting pages in categories. This colon trick can be used with links to any namespace that would ordinarily have a special effect: categories, files, interwiki links, etc. – Joe (talk) 11:35, 20 October 2020 (UTC)

@Joe Roe:Thank you Joe, much simpler and didn't realize that functionality existed. Araesmojo (talk) 16:58, 20 October 2020 (UTC)

Category:Featured articles and Category:Good articles both exist (hiddenly) and directly contain articles rather than their talk pages. So the short answer is you probably want to browse those categories instead.

Membership in these categories is emitted by the little FA/GA "top icon" templates. These don't exist for lower quality assessment levels, but maybe they should.

I'm not a fan of talk page banners at all. If an article's talk page has not received any discussion, I'd prefer it to remain a red link indefinitely. But no, create a stub about pretty much anything and within a day the talk page will have banners saying which five different wikiprojects have claimed it and assigned mutually redundant "stub-class, low-importance" ratings. I don't know why this is necessary or how many people even read it.

In conclusion, I'd support:

• Merging the FA/GA icon templates into a unified "quality icon" template that goes all the way down to stub class and emits a hidden category (of articles) at every setting, to aid in navigation for users who care about such things, such as the OP.
  • I'm not opposed to also hiding the lower-quality icons by default using CSS, so that the visual experience remains unchanged for users who don't log in and opt in (to seeing graphical representations of "C-class" or "start-class" or whatever, which we assume casual readers don't care about).
• Taking a flamethrower to any other assessmentcruft that can't (or shouldn't) be expressed as a compact icon on the article itself. If that means uninventing the "importance" scale, I'm fine with it.
• Deleting, in the "Talk:" namespace, every page where zero signed comments exist in its entire history.

―cobaltcigs 10:33, 23 October 2020 (UTC)

Listings of Articles by Both Quality and Importance with Quick Links

I'm in a mode of trying to find worthy candidates for editing, so second proposal. Currently, well sorted Category lists appear to exist for articles ranked by Quality Category:Articles by quality and separately by Importance Category:Wikipedia articles by importance. There is also a listing for Category:Articles by quality and importance, however, it does not appear to be nearly as complete and looks almost compiled by hand. A natural connection for these groups appears to be the table shown below from the article on Wikipedia:Content_assessment.

All rated articles by quality and importance Quality Importance Top High Mid Low ??? Total FA 1,573 2,486 2,407 1,935 179 8,580 FL 180 678 769 699 100 2,426 A 364 683 789 580 91 2,507 GA 3,214 7,309 14,722 19,475 1,740 46,460 B 16,911 32,781 54,237 68,606 23,346 195,881 C 16,876 53,973 134,960 308,104 91,459 605,372 Start 18,510 92,340 415,478 1,615,170 410,204 2,551,702 Stub 4,285 31,495 278,366 2,800,091 764,271 3,878,508 List 4,861 17,137 53,844 193,376 68,884 338,102 Assessed 66,774 238,882 955,572 5,008,036 1,360,274 7,629,538 Unassessed 121 469 1,238 17,388 411,516 430,732 Total 66,895 239,351 956,810 5,025,424 1,771,790 8,060,270 About this table

Suggestion: Adding links to this table so that if I want to find a Stub article with High importance to Wikipedia, I can simply click on the correct box. Being able to immediately find those articles seems like it would be valuable for potential editors. Araesmojo (talk) 22:13, 19 October 2020 (UTC)

@Araesmojo: That sounds fine to me. To make it happen, you don't really need to come here; just find the underlying template that's generating the tables like the one above, edit its sandbox to introduce the functionality you're describing, and then make an edit request to implement the change.

As a side note, if you're looking for articles needing improvement, check out WP:TAFI or the WP:Vital articles lists. {{u|Sdkb}} ^talk 05:57, 20 October 2020 (UTC)

@Sdkb:Thank you for the answer Sdkb. I didn't want to undertake a change that seemed so significant without at least checking here. Modifying anything related to ratings seemed like it might set off a firestorm. I will try implementing the change later today. Araesmojo (talk) 16:17, 20 October 2020 (UTC)

@Sdkb:Making a larger second response because I looked into the situation and it is non-trivial to say the least.

This table has been created by WP_1.0_bot, perhaps one of the most prolific bots on Wikipedia. Including @Audiodude: and @Kelson: because they appear to be the current owners. The bot is in its 3rd generation. Originally written by Oleg_Alexandrov with a 1st gen until 2010, transitioned to Theopolisme with a 2nd gen until ~2019, and now is in its 3rd gen developed primarily by audiodude. Its source code currently appears to be primarily Python / SQL with small portions of Javascript frameworks related to Wikipedia. It has a github source code page at WP1.0 Bot Source with approximately 1 MB of uncompressed source files after download.

The 3rd gen WP1.0 Bot actually generates tables very similar to those I requested on a project by project basis such as User:WP_1.0_bot/Tables/Project/Catholicism or those shown at User:WP_1.0_bot/Tables. It is run off of Toolforge with a tool account. It can be used to summarize or update individual projects using Wikipedia 1.0 Server. The WP1.0 Bot has had a difficult history of both crash issues and unusually high numbers of logins ~13k / day because of the extremely complex compilation task it has and the large number of pages it needs to touch.

Because of these versions (1st, 2nd, 3rd) and issues where for a significant time it wasn't even clear who the WP1.0 Bot's owner was, there is some chance there may be a separate issue that the table I linked may actually be woefully out of date. Its possible it hasn't been updated since 1st gen. That's all the info I currently have and perhaps the authors will be able to add further. Araesmojo (talk) 20:37, 20 October 2020 (UTC)

Hi @Araesmojo: That's a pretty good history of the WP 1.0 bot! You are correct that it's on its third generation, and I am the primary maintainer with help from Kelson. You are correct about the location of the bot's source code. One thing to note is that while the 2nd gen ran on toolforge, and there is still a redirect there from the old web frontend to the new one, the 3rd generation runs primarily on Wikimedia Cloud VPS. The table you linked actually transcludes this page which was updated on October 12 (though it's supposed to be updated every day, I'll file a bug for that in the project's Github page). So it is pretty up to date.

Anyways, as you've noticed, there is a web frontend that allows you to browse individual WikiProjects, which make up the entirety of what is included in the "master" table. This allows you to browse articles in specific categories, with links back to Wikipedia, much like you were suggesting, except that it's limited in scope to the specific WikiProject. I would recommend this as a great place to look for articles that need improvement, in an area where you might have expertise. The only reason that we don't have the overall articles table in the web frontend is that it deals with so many millions of articles that it would be very slow to generate for the user and difficult to browse. Hope this helps, audiodude (talk) 22:12, 20 October 2020 (UTC)

@Audiodude:Thank you for the reply and clarification audiodude. The distinction about the Wikimedia Cloud VPS was not clear from the bot's landing page. I can comprehend the lack of including the overall article table, as a user generatable table requiring looking at all of Wikipedia to create it would be quite complex. Would it be possibly to simply have the master table generated purely by the bot and not an option for normal users? Then it could be effectively static from their perspective and point to links such as the third item in my original post Category:Articles by quality and importance that seems to be out of date "last generated 28 August 2019‎" and with only 95 categories.

Ex: If I want to find Category:C-Class Computer Security articles of High-importance I would click on the pre-made table in the box for C-Class, High Importance, it would then take me to a listing of Category:C-Class articles of High-importance (doesn't exist), then the previously mentioned Category:C-Class Computer Security articles of High-importance listing, and then perhaps Botnet if it struck my interest since we're on the topic of bots. Some of these pages seem to already exist, they're just not rolled into the new generation bot. Thank you for your work maintaining what looks like a rather complex bot. Araesmojo (talk) 23:31, 20 October 2020 (UTC)

@Araesmojo: That sounds like a lot of work, with also writing a lot of pages to Wikipedia, for questionable benefit. Like I mentioned, you can already browse listings for WikiProjects such as Computer Security here and here is the listing for High Importance, Stub quality. audiodude (talk) 19:29, 23 October 2020 (UTC)

@Audiodude: That's fine. You're the owner and maintainer of the WP 1.0 bot not me. Purely a suggestion. I'm already progressing in the direction of just looking for links and articles. Araesmojo (talk) 19:33, 23 October 2020 (UTC)

Home page needs login information

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.

---

In my humble opinion, I believe it is a bit of a hindrance to search for a random article first and then select my watchlist to access it. Most people would bookmark their own Watchlist but it seems counter-intuitive to not have the option readily available. Is it possible to add personal account information such as talk page, sandbox, preferences, Watchlist, and Log out/Log in button?Blue Pumpkin Pie ^{Chat Contribs} 17:11, 20 October 2020 (UTC)

I'm afraid I'm not following — are you saying that, to log in, you search for a random page and try to watchlist it to get the login prompt to come up? There should already be a button for logging in in the upper right corner on vector desktop. {{u|Sdkb}} ^talk 18:17, 20 October 2020 (UTC)

@Blue Pumpkin Pie: what client and skin are you using? There is a prominent link to most of those things right on the top of every screen normally. — xaosflux ^Talk 18:18, 20 October 2020 (UTC)

Sdkb and Xaosflux I'm just using the standard skin and I use google chrome. When I mean the "Home page". I'm literally referring to the first page when you go to https://www.wikipedia.org/ not https://en.wikipedia.org/wiki/Main_Page . There is no option to select "Main Page". There is no method to log in or to go to your account. The first page just has the option to search for a random article. To get to anything you need to access as an editor, you have to search for an article or just search for a blank option.Blue Pumpkin Pie ^{Chat Contribs} 18:25, 20 October 2020 (UTC)

@Blue Pumpkin Pie: Ah OK. Our main page is https://en.wikipedia.org - so just use that, that other page is not part of the English Wikipedia, so there isn't anything for us to specifically do about it. It also isn't a wiki, and having a link to something like "watchlist" there wouldn't know where to go anyway - maybe you want to read the German Wikipedia, or the Spanish Wikipedia for example - there would be no way for that page to know. — xaosflux ^Talk 18:32, 20 October 2020 (UTC)

I understand.Blue Pumpkin Pie ^{Chat Contribs} 19:06, 20 October 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.

CentralNotice banner for Wikipedia Asian Month 2020

Dear colleagues, please comment on CentralNotice banner proposal for Wikipedia Asian Month 2020 (1st November to 30st November, 2020). Thank you! --KOKUYO (talk) 19:09, 22 October 2020 (UTC)

A new category :-)

Hi, how are you, hope you're great. I was reading about the First World War and I came across Frank Buckles, last American survivor. I read he was a National Rifle Association member and I added the category "American gun rights activists", and I had an idea, what if I create the category "NRA members"?, or "NRA people"?, do you think it complies policies?. Well, I anxiously look forward to advice. Sweet greeting. –Iván– CoryGlee (talk) 23:07, 23 October 2020 (UTC)

Category:National Rifle Association is small enough that members don't need their own sub-category. Presidents already have one. davidwr/(talk)/(contribs) 23:57, 23 October 2020 (UTC)

Redesigning the good article and featured article topicons

• 
  Current good article icon
• 
  Current featured content icon

This proposal seeks to establish consensus for a mandate to redesign the icons that appear in the upper right corner of good articles (GAs) and featured content (FC) pages to mark their status.

Background: The current symbols for GAs and FC have been used since those systems were introduced way back in Wikipedia's early days. They have significant problems. The featured content icon is too skeuomorphic, giving it an outdated look, and its excessive detail causes it to render poorly at small scale. The good article icon, meanwhile, has been adopted throughout much of the rest of Wikimedia (and in some places on Wikipedia) as the "support vote" icon, leading to conflicting usage. More concerning than either of their individual issues is the lack of any shared visual language between them (the GA icon uses the norro style, and the FC icon is not part of any larger style system). When compounded by their overall lack of prominence (a separate issue under discussion above), this has led to the unfortunate situation where many (perhaps most) non-editing readers could not tell you whether a star or a green badge is a higher distinction, greatly diminishing the impact of the work editors put into the GA/FC systems.

Proposed process: This proposal does not put forward any specific redesign ideas, but rather seeks to assess whether there is general consensus for a change. If a mandate is established, editors at the graphics lab (where a version of this proposal is currently on hold) will have the opportunity to create designs, which will then be !voted on in a process perhaps similar to the one MediaWiki is using to redesign their logo, with the eventual winner adopted. Design proposals will likely incorporate changes to related icons such as those for good article candidates or former featured articles.

Cheers, {{u|Sdkb}} ^talk 20:23, 24 October 2020 (UTC)

Notified: Wikipedia talk:Featured content, Wikipedia talk:Featured articles, Wikipedia talk:Good articles, Wikipedia talk:WikiProject Usability. {{u|Sdkb}} ^talk 20:23, 24 October 2020 (UTC)

Survey

Should we redesign the GA and FC topicons?

• Support as proposer. This is a feasible task, and would have clear and significant benefits for readers across tens of thousands of pages. {{u|Sdkb}} ^talk 20:23, 24 October 2020 (UTC)
• Support. Would be lovely to have the new icons in the mobile version then as well. Femke Nijsse (talk) 16:18, 25 October 2020 (UTC)

Design discussion

What would you like to see in new topicons if they are redesigned? The discussion in this section will be used as guidance for designers if the proposal is successful.

• General comment: Consider color blindness (esp. red-green): In data visualization circles, there is increasing awareness of how graphics should be crafted to allow color blind individuals to distinguish through shading, what normally sighted individuals distinguish directly through color perception. (One can test shading in Photoshop etc by removing saturation.) It's my understanding that red-green color blindness is a common type, though not the only type of color blindness. Some color scales are better than others: see Scientific American. —RCraig09 (talk) 22:53, 17 October 2020 (UTC)

General discussion

• Waste of time proposal. Make some icons then we can talk about some icons. WP:BOLD. --Izno (talk) 21:40, 24 October 2020 (UTC)

  @Izno: I'm launching this based on feedback from the Graphics Lab, where editors asked for us to establish a mandate for new icons before they commit a bunch of time to designing them (graphics work is absolutely not quick and easy). The process is open to discussion, but dismissiveness is not constructive. {{u|Sdkb}} ^talk 00:58, 25 October 2020 (UTC)

  They can be just as BOLD. I'm not a fan of proposals which are just a lot of process, and this is one. If they think they can put together some good icons they should Just Do It. Our lock icon worker of yesteryear--that came to the village pump basically out of the blue. It's a collective waste of every user's time to respond to this RFC if we have nothing to discuss, and at the end of the day that's probably just as "absolutely not quick" for the hours the community will waste arguing about whether it's a good idea to change it. --Izno (talk) 01:31, 25 October 2020 (UTC)

• No icon at all Icons are not large enough for their meaning to be clear, so just use text. Currently an article has "From Wikipedia, the free encyclopedia" displayed below the title. This is redundant as "Wikipedia, the free encyclopedia" is also displayed at the top of the left sidebar. Re-use this space to display "Featured article (from 2019-04-01)" etc. — GhostInTheMachine ^{talk to me} 17:19, 25 October 2020 (UTC)
• What's wrong with being outdated? By the time anything is implemented fashions will have changed and maybe skeuomorphic icons will be all the rage again. By following trends several years after they have happened we simply make ourselves look like dad dancers (which I was happy to be at my daughter's wedding). We should put ourselves above issues of trendiness. Phil Bridger (talk) 17:34, 25 October 2020 (UTC)

  @Phil Bridger: There are some underlying reasons for the shift from skeuomorphism to flat design, beyond just fashions. My understanding is that the main one is that, in the earlier days of the internet, people weren't as comfortable with online navigation, so it was necessary to make icons more lifelike to help signal their meaning as clearly as possible, but as people have gotten more used to the internet, the cleaner look of flat design has won out.

  You're right, though, that trends may shift again in the future. There will be nothing preventing us from changing the icons again, though, especially once we've broken out of the "this is the way it's always been and always will be" mindset. I think the main problem with looking outdated is that it's a very small cognitive jump from "this website has an outdated look" to "this website has outdated content". {{u|Sdkb}} ^talk 19:24, 25 October 2020 (UTC)

  The increasing number of people using small screens on their phones to browse the web also resulted in simplification of iconography, both for legibility and to make more compact use of space. This has led to simpler, flatter designs. isaacl (talk) 21:37, 25 October 2020 (UTC)

Cosmetic Bot Day (CBD)

Caution: bots temporarily improving Wikipedia

• The proposal is a periodic (monthly) 1-day (24hr GMT) relaxing of WP:COSMETICBOT assuming there is otherwise consensus for the bot

Cosmetic edits are generally disallowed by bots because they continually light up watchlist for changes that are not substantive impeding work flow. This is good. However, as a result many changes that could easily be done by bot never get done, and the community is left to fix simple issues by hand, assuming they ever get done at all.

This proposal is to have 1 day a month or year etc.. that is exempt ie. "Cosmetic Bot Day". Any such bot would require approval though WP:BRFA as normal, bot ops can't do whatever you want, but the bot on that day would not be under Cosmetic regulation, assuming there is otherwise consensus for the bot task. It's a trade-off between allowing bots to fix some problems that are plainly cosmetic while not lighting up watchlists on a daily basis.

It is true WP:COSMETICBOT already says "Consensus can, as always, create exceptions for particular cosmetic edits", however in practice these "exceptions" rarely happen because the bots are running continuously thus the bar is set high. This proposal would allow a temporary relaxation of COSMETICBOT.

For example the period might be once a month (the first day). If there is concern about too many edits, it might be limited to 1 CBD request per month ie. only 1 bot can claim the CBD spot each month. There could be a simple list where bot owners can add their name and date and link to the BRFA discussion, it would need minimal overhead and be nearly self-regulating.

If the bot is doing questionable things (eg. moving the placement of every instance of |url= before |title=) this proposal does not give blanket or even tacit permission. The bot task must have consensus first. The proposal would free up editors time to focus on more substantive work.

-- GreenC 15:41, 25 October 2020 (UTC)

Could we have an example or two of the sorts of edits that would be done on this day? I think an annual day would be an easier sell, as far as disrupting watchlists goes, than a monthly one. {{u|Sdkb}} ^talk 16:06, 25 October 2020 (UTC)

Examples might be adjusting spacing of infobox parameters and their values (to make them line up in edit view); replacing template redirects with their canonical names; adjusting spacing within and above/below headers in a way that does not change the rendered view but standardizes them; or many of AWB's general fixes, like some of those listed in the FixSyntax section. Although it might be annoying one day per month, getting millions of articles looking more similar in edit mode may be helpful. – Jonesey95 (talk) 16:40, 25 October 2020 (UTC)

Another example would be users like NicoV and others might be able to clear out the entirety of WP:CWERRORS if we had enough bots working on it. Primefac (talk) 17:33, 25 October 2020 (UTC)

Thanks Primefac for the notification. I already have some tasks approved for cosmetic edits alongside other edits (T6, T8, T9, T11), maybe some of them could be approved to run if the CBD proposal was accepted. I'm sure there are also other tasks related to other WP:WCW errors that could be added (I never spent the time required for BRFA for other errors that would only be cosmetic edits). --NicoV ^{(Talk on frwiki)} 19:33, 25 October 2020 (UTC)

I would be in support of something like this. I think the idea of a cosmetic bot day of the month/half month would be the best. Year seems to far apart if this is actually needed. Week might be too often if the task is purely cosmetic.

I think that these tasks should only be allowed on this proposed day if the task has been approved by a BRFA for running on that day. This could be that the BRFA has to state that on the "cosmetic day" the bot will do X, Y and Z cosmetic changes. This will ensure that the bot will have explicit approval to run on that day in particular.

Perhaps limiting the number of cosmetic tasks that can be run on that day might be needed, but I wouldn't want a limit unless it is needed. I think a list of what tasks will run on each cosmetic day would be good, regardless of whether limits exist to ensure that it is all transparently logged and prevent any misunderstandings. Dreamy Jazz ^{talk to me | my contributions} 16:15, 25 October 2020 (UTC)

• Comment: This is an interesting idea. I agree with Dreamy Jazz that any such tasks would have to specifically be approved as "Cosmetic Day" tasks, and probably advertised more widely than the usual BRFAs. There may a significant group of editors who simply oppose a certain cosmetic task, like adjusting spacing of infobox parameters, and we need to hear from them before a bot makes 50,000 edits. Bot tasks of this type could go through a normal trial period of 100 or so edits, then an extended trial on Cosmetic Day of 1,000 edits to ensure that the community does not object, before being approved for mass edits on subsequent Cosmetic Days. – Jonesey95 (talk) 16:40, 25 October 2020 (UTC)
• I always thought of something like that, although probably not as often as once a month (maybe three months/six months would be better) for infobox normalization (see User:Headbomb/sandbox), talk page general fixes, etc. I would certainly oppose moving url before titles in citation templates, especially since many of 'my' articles deliberately put URLs after titles. But the general idea of a cosmetic day has some merit. Not sure if I'm for the idea, but I'd consider it, with fairly heavy BAG and community oversight. If it passes, I would suggest the days with the lowest editor activity to minimize annoyance. Headbomb {t · c · p · b} 16:53, 25 October 2020 (UTC)
• Question: why? What benefit is there to the encyclopedia of making cosmetic changes? Jonesey95 mentions "getting millions of articles looking more similar in edit mode", but I don't see why that's helpful or desirable or necessary. What am I missing? Schazjmd (talk) 17:01, 25 October 2020 (UTC)

  One reason is for things like WP:WCW; formatting or stylistic issues that can cause tracking/category errors and/or output issues. Primefac (talk) 17:33, 25 October 2020 (UTC)

• Another reason is that for us with a "copy-edit, gnomish" bent, it is quicker and easier to edit when there is consistency in the edit-mode view of pages. This would also stop the undeclared hidden-space-wars (eg: white space additions/removals in infoboxes, line returns between headers and sub-headers, and other stuff). Regards, GenQuest ^{"Talk to Me"} 20:03, 25 October 2020 (UTC)

• WP:BOTDICT#editor-hostile/newbie-hostile wikitext also comes to mind. See my infobox example above. Headbomb {t · c · p · b} 19:41, 25 October 2020 (UTC)

• Oppose. If a task is cosmetic then there is no benefit to doing it on mass absent other changes to the page. If there is benefit to doing the task en mass independently of other edits then it isn't cosmetic and/or the specific task will gain consensus at BRFA in the normal manner. Thryduulf (talk) 18:45, 25 October 2020 (UTC)
• Support per the above. Would prefer a 'first day of every quarter' or 'every-other quarter' type system rather than monthly, though. even or odd months only would work too. Thanks. GenQuest ^{"Talk to Me"} 20:07, 25 October 2020 (UTC)
• Oppose It's a bad idea technically to concentrate such high-volume edits of a similar nature – likely to cause edit conflicts and performance issues. I've already noticed Wikipedia running slowly in recent weeks. As these edits are already agreed to be unnecessary, there's no good reason to do this. And having lots of unnecessary edits doesn't just affect watchlists. They also clutter the edit histories for articles, making them more difficult to trace and analyse. Andrew🐉(talk) 20:18, 25 October 2020 (UTC)

That's not quite true. There's some edits that would make things things a lot more editor-friendly, even if they are technically cosmetic. There's certainly a threshold, but there's a subset of them that would be useful. Edit conflicts and 'performance issues' are overblown as issues. Watchlist flooding could be minimized by choose days with lower editor activity, and edit history clutter can also be minimized by focusing on higher-value tasks, and by performing them only once per every few months. It's not anything that technically couldn't already be handled via normal bot approval though. Headbomb {t · c · p · b} 02:20, 26 October 2020 (UTC)

• Oppose. The edits are at minimum unnecessary and sometimes undesirable (adjusting spacing, and so on) and cause watchlist problems and pointless discussion. SarahSV ^(talk) 02:41, 26 October 2020 (UTC)