Wikipedia:Village pump (all)

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

(to see recent changes on Village pump subpages)

Village pump sections

Policy

post, watch, search
Discuss existing and proposed policies

Technical

post, watch, search
Discuss technical issues about Wikipedia

Proposals

post, watch, search
Discuss new proposals that are not policy-related

Idea lab

post, watch, search
Incubate new ideas before formally proposing them

WMF

post, watch, search
Discuss issues involving the Wikimedia Foundation

Miscellaneous

post, watch, search
Post messages that do not fit into any other category

View all village pump sections at once

Other help and discussion locations

I want...	Then go to...
...help using or editing Wikipedia	Teahouse (for newer users) or Help desk (for experienced users)
...to find my way around Wikipedia	Department directory
...specific facts (e.g. Who was the first pope?)	Reference desk
...constructive criticism from others for a specific article	Peer review
...help resolving a specific article edit dispute	Requests for comment
...to comment on a specific article	Article's talk page
...to view and discuss other Wikimedia projects	Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography	Citing Wikipedia
...to report sites that copy Wikipedia content	Mirrors and forks
...to ask questions or make comments	Questions

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Copy paste plagiarism from out of copyright materials.

Hi, I was just wondering what the correct template is for signalling articles which have copypasted text from an out of copyright source. This article is a word for word copy from this source, and I'm pretty sure that's not ok, so we must have a template. Boynamedsue (talk) 16:45, 7 May 2024 (UTC)

It is ok, since the source is in the public domain and the text is properly attributed. There are many templates used to attribute the sources being copied, and that article uses one of them (Template:DNB). Firefangledfeathers (talk / contribs) 16:49, 7 May 2024 (UTC)

In the early days, it was considered a good thing to copy articles from the 1911 Encyclopedia Brittanica to fill in the gaps. Donald Albury 17:02, 7 May 2024 (UTC)

Many people (not the OP) don't seem to understand the difference between copyright violation and plagiarism. Copyright violation is the copying of copyrighted text with or without attribution against the terms of the copyright licence (with an allowance for "fair use" in nearly all jurisdictions). Plagiarism is the passing off of someone else's work as one's own, whether the work is copyrighted or not. This is not copyright violation, because it is out of copyright, and not plagiarism, because it is properly attributed. Phil Bridger (talk) 17:47, 7 May 2024 (UTC)

So, let me get this straight, are users saying that it is ok to copypaste text from an out of copyright text as long as that text is attributed? This feels very wrong, which wikipolicies allow this?Boynamedsue (talk) 22:19, 7 May 2024 (UTC)

See the content guideline at Wikipedia:Plagiarism. While at least some editors would prefer that such material be rewritten by an editor, there is no prohibition on copying verbatim from free sources; it is allowed as long as proper attribution to the original source is given. Donald Albury 22:39, 7 May 2024 (UTC)

I think it needs to be done with considerable caution if at all, and it just seems like a less ideal option in almost every case, save for particular passages that are just too hard to rewrite to the same effect. But I think the consensus is that it is allowed. Remsense诉 01:20, 8 May 2024 (UTC)

Copyright has a limited term (though these days, in many countries, a very long one) precisely to allow the work of the past to be built upon to generate new creative works. isaacl (talk) 01:48, 8 May 2024 (UTC)

Nothing new is generated when you copy something verbatim. Traumnovelle (talk) 08:43, 12 May 2024 (UTC)

Remixing from sampled works is increasingly common. Imitating other people's work is done to learn new styles. Jazz music specifically has a tradition of incorporating past standards into new performances. Critical analysis can be more easily placed in context as annotations. And from an educational standpoint, more people can learn about/read/watch/perform works when the barrier to disseminating them is lessened. What's in copyright today is the source of new widely-spread traditional works in the future. isaacl (talk) 14:44, 12 May 2024 (UTC)

Aye, every time you read a poem it's a new translation. If this were Wikiversity, I think there'd actually be a lot of room for interesting experiments remixing\ PD material. Remsense诉 14:46, 12 May 2024 (UTC)

You wrote a lot but none of it actually addresses what I've said. Traumnovelle (talk) 15:33, 12 May 2024 (UTC)

I gave examples of new creative works that have copied past work verbatim. isaacl (talk) 04:11, 13 May 2024 (UTC)

Actually, comparing the two, and looking at the edit history, it is not at all true that "...This article is a word for word copy from this source." Much has been changed or rewritten (and many of the spicy bits removed). This is fairly typical for this sort of biography, I would say. Johnbod (talk) 02:48, 8 May 2024 (UTC)

Yes, I was a bit imprecise there, it is the first three to four paragraphs of the life section that are directly lifted word for word. I'm just a little shocked at this as anywhere other than wikipedia this would be classified as gross plagiarism.Boynamedsue (talk) 05:21, 8 May 2024 (UTC)

If it's clearly noted as an excerpt (and not just a reference) I wouldn't feel able to say that. However like I've said above, the number of cases where this would be the best option editorially is vanishingly few for an excerpt of that length. Remsense诉 05:22, 8 May 2024 (UTC)

(As such, I've explicated the attribution in the footnote itself, not just the list of works.) Remsense诉 05:37, 8 May 2024 (UTC)

• Collecting, copying or reproducing high quality, classic writings on a topic is quite common in publishing. See anthology, for example. Andrew🐉(talk) 20:54, 8 May 2024 (UTC)

That is true, but publishing big chunks of it unchanged as part of a new book under a new name, without specifically stating that this text was written by someone else is not. If you cite someone else, you have to use different language, unless you make it clear you are making a direct quotationBoynamedsue (talk) 21:01, 8 May 2024 (UTC)

But the article does (and did) specifically state that it was written by someone else. Phil Bridger (talk) 21:31, 8 May 2024 (UTC)

It didn't. It cited a source, that is not the same as stating the text was a direct quotation from that source. It now states: "This article incorporates text from this source, which is in the public domain" which is an improvement but does not differentiate between which parts are direct quotes and which use the source properly.Boynamedsue (talk) 21:40, 8 May 2024 (UTC)

That seems very unneeded, as no one is claiming specific authorship of this article, and as the material used for derivation has long been linked to so that one can see what that version said. -- Nat Gertler (talk) 21:50, 8 May 2024 (UTC)

Anywhere but wikipedia, passing off someone else's words as your own is plagiarism. The kind of thing that people are rightly sacked, kicked out of universities or dropped by publishers for. This includes situations where a paper is cited but text is copy-pasted without being attributed as a quote.

I'm more than a little shocked by this situation, but if so many experienced editors think that it's ok, there's not much I can do about it.Boynamedsue (talk) 22:00, 8 May 2024 (UTC)

That's because we aren't trying to impress the teacher with our sooper riting skilz. We're providing information to the WP:READER, who isn't supposed to care who wrote what. This is fundamentally a collective effort. Note the tagline is "From Wikipedia, the free encyclopedia" not "By Wikipedia, the free encyclopedia". There exist WP:FORKS of Wikipedia where 99.9% of the content is unchanged. Are they plagiarizing us?

An analogy that might help is the stone soup. If you grew the carrots yourself, great! But if you legally gleaned them instead, so what? The soup is still tastier. Suffusion of Yellow (talk) 22:27, 8 May 2024 (UTC)

Yeah, wiki-mirrors are clearly plagiarising wikipedia, even though they are breaking no law. Wikipedia is a collective effort of consenting wikipedians, it is not supposed to be a repository of texts stolen from the dead. That's wikisource's job.Boynamedsue (talk) 22:34, 8 May 2024 (UTC)

A Wikipedia article doesn't proport to be your work. They are a collaborative effort by multiple people. The fact that some of these people are long dead before this text shows up here is irrelevant. If copying from a PD source, you certainly should make it clear where the text is from, but it's not an absolute requirement. Additionally, if a statement of the source wasn't done by the revsion author, it can be done subsequently by anyone else (assuming no blocks or bans forbid this particular person from editing this particular article). Animal lover |666| 15:28, 9 May 2024 (UTC)

I don't see why it would be acceptable for it not to be made clear. Once more, there's a distinction between copyvio and plagiarism—the fault with the latter for our purposes broadly being that readers are not adequately made aware of where what they are reading came from. The obvious default assumption of any reader is that they are reading something a Wikipedia editor wrote. Tucked away as it is, there is an edit history that lists each contributing editor. This is not superfluous context to me, it's about maintaining a sane relationship between editors and audience. Even if there's potentially nothing wrong with it divorced from social context, in terms of pure claims and copyright law—we don't live in a media environment divorced from social context, there's no use operating as if we don't meaningfully exist as authors and editors. Remsense诉 15:34, 9 May 2024 (UTC)

By the way, plagiarizing Wikipedia would be a copyright violation, since Wikipedia texts are released under a license that requires attribution. Same can't be said for PD texts. Animal lover |666| 18:43, 9 May 2024 (UTC)

When EB1911 was published, copyright in the United Kingdom expired seven years after the author's death, so "the dead" would probably just be surprised that it took so long for their work to be reprinted. Wikipedia exists to provide free content, the defining feature of which is that it can be reused by anyone for any purpose (in our case, with attribution). So it shouldn't really be surprising that experienced editors here are generally positive about reusing stuff. – Joe (talk) 19:18, 9 May 2024 (UTC)

The stuff you are claiming is "plagiarized" is getting far better attribution than most of the writing in Wikipedia. Most of the contributing writers get no credit on the page itself, it is all in the edit history. I'm not sure whose writing you think we're passing this off as. -- Nat Gertler (talk) 15:19, 9 May 2024 (UTC)

I think simply being stated at the bottom is pretty much exactly the level of credit editors get—for me to feel comfortable with it it should be stated inline, which is what I added after the issue was raised. Remsense诉 15:21, 9 May 2024 (UTC)

To be fair I think the only reason these things tend to be noted with a template at the bottom of the article is that the vast majority of public domain content was imported in the project's early days, as a way of seeding content, and back then inline citations were barely used. – Joe (talk) 19:23, 9 May 2024 (UTC)

Uh, what are we going to do, dock their pay? jp×g🗯️ 07:42, 10 May 2024 (UTC)

Was thinking more along the lines of tagging the text or reverting, a talkpage message and possibly blocks for recidivists. But like I said earlier, it appears that the consensus is that things are fine how they are. World's gone mad, but what am I off to do about it? Nowt. Boynamedsue (talk) 08:14, 10 May 2024 (UTC)

The text you're worried about was added twelve years ago by a user who that has been blocked for the last eleven years (for, wait for it... improper use of copyrighted content). I think that ship has sailed. – Joe (talk) 08:24, 10 May 2024 (UTC)

There you go, gateway drug.Boynamedsue (talk) 08:27, 10 May 2024 (UTC)

I don't think that hypothesis is replicable. Alpha3031 (t • c) 09:58, 10 May 2024 (UTC)

• There does appear to be a consensus that such works need to be attributed somehow, and despite whatever disagreement there is, the disagreement in substance appears to be how that is done. What we are doing in these instances is republication (which is a perfectly ordinary thing to do), and yes we should let the reader know that is being done, but I'm not seeing a suggestion for changing how we do that. Alanscottwalker (talk) 14:53, 12 May 2024 (UTC)

  It seems to me that the OP asked a question and got an answer, and discussion since has been extracurricular. Remsense诉 14:57, 12 May 2024 (UTC)

  Sure, but the OP does have a point that the more the use of the work looks like our work and not someone else's work, the more it looks like plagiarism. For example, putting a unique sentence in from another's work, and just dropping a footnote, like all the other sentences in our article, is not enough, in that instance you should likely use quotation marks and even in line attribution. Alanscottwalker (talk) 15:19, 12 May 2024 (UTC)

  I think, as with most things, it depends on the situation. Plagiarism is not just the use of words without attribution, but ideas. An idea that has general acceptance might get attributed inline once in an article if it is associated strongly with a specific person or set of persons. But every mention of DNA's double helix doesn't have to be accompanied with an attribution to Watson and Crick. If some info about a person is written up by a reporter in a now public-domain source, for many cases it's probably not too essential to have inline attribution when including that info in an article. If it's something that reporter was known for breaking to the public, then it would be relevant. isaacl (talk) 15:43, 12 May 2024 (UTC)

  But that was not the situation being discussed, it was word for word, copying the work. Alanscottwalker (talk) 15:48, 12 May 2024 (UTC)

  Sure; just underscoring that if the concern is plagiarism, it applies more broadly to the restatement of ideas. Rewording a sentence doesn't prevent it from being plagiarism. Even with a sentence being copied, I feel the importance of an inline attribution depends on the situation, as I described. isaacl (talk) 15:55, 12 May 2024 (UTC)

  Sure, but that is similar a simple phrase alone, like 'He was born.' cannot be copyrighted nor the subject of plagiarism. Now if you use the simple phrase 'He was born.' in a larger poem and someone baldly copies your poem in large part with the phrase, the copyist violated your copyright, if still in force, and they did plagiarize. Alanscottwalker (talk) 16:19, 12 May 2024 (UTC)

  Yes, copying a poem likely warrants inline attribution, so... it depends on the situation. isaacl (talk) 16:24, 12 May 2024 (UTC)

  And that's the issue raised, regarding republication on wiki, is it currently enough to address plagiarism. Alanscottwalker (talk) 16:35, 12 May 2024 (UTC)

  I think the need for inline attribution depends in the same way as for content still under copyright. The original question only discussed the copyright status as a criterion. I don't think this by itself can be used to determine if inline attribution is needed. isaacl (talk) 16:43, 12 May 2024 (UTC)

  As plagiarism and copyright are two different, if sometimes related, inquiries. -- Alanscottwalker (talk) 17:08, 12 May 2024 (UTC)

  >If some info about a person is written up by a reporter in a now public-domain source, for many cases it's probably not too essential to have inline attribution

  It absolutely is essential per WP:V. Traumnovelle (talk) 15:49, 12 May 2024 (UTC)

  Attribution is required. Inline attribution is not (that is, stating the source within the prose). isaacl (talk) 15:58, 12 May 2024 (UTC)

  It still requires sourcing. Traumnovelle (talk) 16:06, 12 May 2024 (UTC)

  Yes, attribution is sourcing. isaacl (talk) 16:15, 12 May 2024 (UTC)

  I think, better to distinguish the two. Attribution is explicitly letting the reader know these words, this idea, this structure came from someone else, whereas sourcing is letting the reader know you can find the gist or basis for the information in my words, there. Alanscottwalker (talk) 18:16, 12 May 2024 (UTC)

  My apologies for being unclear. I was responding to the statement that inline attribution absolutely is essential. Providing a reference for the source of content is necessary. Providing this information within the prose, as opposed to a footnote, is not. isaacl (talk) 19:57, 12 May 2024 (UTC)

  Certainly, it is possible to put explicit attribution in the footnote parenthetical or in an efn note. (I think your response to this might be , 'it depends' :))Alanscottwalker (talk) Alanscottwalker (talk) 20:18, 12 May 2024 (UTC)

  I think you might be talking past each other. isaacl is simply stating that WP:V requires attribution, it does not require any particular method of attribution. What method of attribution is preferable in a given place is not a matter for WP:V. Thryduulf (talk) 23:55, 12 May 2024 (UTC)

  Should be be providing in-line attribution for every sentence on Wikipedia to let the reader know which editor wrote which part of it? Wikipedia isn't an academic paper, as long as we can verify that there are no copyright issues with the content (such as an attribution-required license), attribution doesn't matter. --Ahecht (TALK
  PAGE) 19:32, 13 May 2024 (UTC)

  Surely there's some reasonable position between "attribution doesn't matter" and "attribute every sentence inline". Remsense诉 09:06, 14 May 2024 (UTC)

  Yah, sorry those two extremes certainly don't follow from each other (Nor does the comment you are responding to discuss inline). The guideline is WP:Plagiarism and it does not go to those extremes on either end. (Also, Wikipedia does publically attribute each edit to an editor, and it does not need to be in the article, it is appendixed to the article.) -- Alanscottwalker (talk) 10:51, 14 May 2024 (UTC)

• Around 2006, I reworked a copy-pasted EB1911 biography about a 16th century person, it took me about a week. It has stood the test of time, and remains to this day a pretty good article despite having the same structure and modified sentences. The lead section is entirely new, and there are new sources and section breaks and pictures etc.. but the bulk of it is still that EB1911 article (reworded). I do not see the problem with this. Disney reworked Grimms tales. Hollywood redoes old stories. Sometimes old things are classics that stand the test of time, with modern updates. -- GreenC 16:44, 12 May 2024 (UTC)

I think everybody is fine with articles which are largely based on a single source when they are reworded. It's not the platonic ideal, but it is a good start. The problem we are discussing is when people don't bother to reword. Well, I say problem, I have been told it's not one, so there's nothing left to say really.--Boynamedsue (talk) 20:06, 12 May 2024 (UTC)

If you actually just reword a source like 1911, you should still use the 1911 template, and no, the thing you have not explained is why the template is not enough. Alanscottwalker (talk) 20:29, 12 May 2024 (UTC)

• Oppose. This proposal is WP:GREATWRONGS. The article John Leslie, 1st Duke of Rothes is perfectly fine. It does not violate any policy, guideline or consensus. There is nothing objectionable about that article. The proposal to rewrite the article would not improve the article and would result only in disruption. The proposal to put a template on the article solely to disparage the inclusion of public domain content in the article would result only in disruption. It would be disruptive to discuss this proposal further, because this proposal is disruptive, because this proposal is WP:GREATWRONGS. James500 (talk) 18:50, 12 May 2024 (UTC)

  Huh? There is no proposal. Also, there has long been a template used on the article. Your attempt to shut down discussion is also way, way off, (and your RGW claim is risible). Alanscottwalker (talk) 20:12, 12 May 2024 (UTC)

  I propose all WP:GREATWRONGS should be righted immediately.Boynamedsue (talk) 20:06, 12 May 2024 (UTC)

  WP:IAR! Alanscottwalker (talk) 20:12, 12 May 2024 (UTC)

  Amongst other things, the OP said that copying public domain text, with the correct attribution, "feels very wrong". James500 (talk) 20:49, 12 May 2024 (UTC)

So, WP:GREATWRONGS is applicable whenever anyone uses the word "wrong"?Boynamedsue (talk) 20:59, 12 May 2024 (UTC)

Only when great. -- GreenC 15:44, 13 May 2024 (UTC)

• Oppose any change to the practice of incorporating public domain content. Wikipedia is not an experiment in creative writing. It is an encyclopedia. It's sole and entire purpose is to convey information to readers. If readers can be informed through the conveyance of text that has entered the public domain, then this should not only be permissible, it should be applauded. BD2412 T 20:52, 12 May 2024 (UTC)

  Again, there is no proposal to do something different. The OP apparently forgot about things like anthologies and republication of out of copyright (like eg. all of Jane Austin's work, etc), but than when such matter was brought to his attention, retrenched to whether attribution was explicit (which we already do) enough, but has never explained what enough, is proposed. Alanscottwalker (talk) 22:24, 12 May 2024 (UTC)

  The proposal was to create a maintenance template that encourages editors to delete all text copied from public domain sources from all Wikipedia articles, even if that text is correctly attributed, simply because it is copied from a public domain source. He actually tried to tag the article with Template:Copypaste (alleging copyright infringement), despite the fact that the content is public domain and was correctly attributed at the time, with the Template:DNB attribution template. James500 (talk) 23:49, 12 May 2024 (UTC)

  That's not a proposal, he asked what template is appropriate, and he was given the list of templates at Template:DNB. Alanscottwalker (talk) 00:49, 13 May 2024 (UTC)

• oppose the existence of a proposal: I would like to clarify, wherever people think they are seeing a proposal, there isn't one. I asked a question about what tag to use when people plagiarise out of copyright texts. I got an answer I think is stupid and expressed incredulity for a couple of posts. Then, when I realised that people were indeed understanding what I was talking about, said if so many experienced editors think that it's ok, there's not much I can do about it. WP:NOVOTE has never been more literally true, there is nothing to vote on here...Boynamedsue (talk) 04:07, 13 May 2024 (UTC)

  Support not adding any more bold-face votes. Suffusion of Yellow (talk) 04:19, 13 May 2024 (UTC)

Alanscottwalker says above that the more the use of the work looks like our work and not someone else's work, the more it looks like plagiarism.

Animal lover says above that A Wikipedia article doesn't proport to be your work. They are a collaborative effort by multiple people. The fact that some of these people are long dead before this text shows up here is irrelevant.

I think this is a difference in how people implicitly view it. The first view says "A Wikipedia article is written by people who type the content directly into the editing window. If your username isn't in the article's history page, then your words shouldn't be in the article. Article content should come exclusively from Wikipedia editors. If it doesn't, it's not really a Wikipedia article. This is our implicit promise: Wikipedia is original content, originally from Wikipedia editors. If it's not original content, it should have a notice to the reader on it to say that we didn't write it ourselves. Otherwise, we are taking credit for work done by someone who is them and not-us in an us–them dichotomy".

The second view says "A Wikipedia article is a collection of text from different people and different places. Where it came from is unimportant. We never promised that the contents of any article came from someone who directly edited the articles themselves. It's silly to say that we need to spam an article with statements that bits and pieces were pasted in from public domain sources. We wouldn't countenance 'written by a random person on the internet' in the middle of article text, so why should we countenance a disclaimer that something was 'previously published by a reliable source'? I don't feel like I'm taking credit for any other editor's article contributions, so why would you think that I'm claiming credit for something copied from a public domain source?"

If you the first resonates strongly with you, then it's shocking to see {{PD-USGov}} and {{EB1911}} content casually and legally inserted into articles without telling the reader that those sentences had previously been published some place else. OTOH, if you hold the opposite view, then the first probably seems quite strange. As this is a matter of people's intuitive feelings about what Wikipedia means, I do not see any likelihood of editors developing a unified stance. WhatamIdoing (talk) 06:56, 13 May 2024 (UTC)

This is a reasonable summary of the issue. I think many of those who hold the first view work in or have close ties to fields where plagiarism is considered a very bad thing indeed. Academic and publishing definitions of plagiarism include using the direct words of another writer, even when attributed, unless it is explicitly made clear that the copied text is a direct quotation. For people who hold that view outside of wikipedia, the existence of large quantities of plagiarised text would detract seriously from its credibility and validity as a project.Boynamedsue (talk) 07:07, 13 May 2024 (UTC)

I work in publishing, and there is plenty of space there where such specificities are not generally called for. If one is doing an abridged edition, children's edition, or updated version of a book, one credits the work which one is reworking but does not separate out phrase by phrase of what is from that source. Much the same goes, of course, for film adaptations, music sampling, and so on. -- Nat Gertler (talk) 16:28, 13 May 2024 (UTC)

I think the difference there is that you are giving primary credit to the original author, and your work is voluntarily subsumed into theirs (while of course correctly stating that it is a Children's version or an abridged edition, giving editor credits etc.). In wikipedia, we are taking other people's work and subsuming it into ours.--Boynamedsue (talk) 16:37, 13 May 2024 (UTC)

I think the dichotomy is useful but I doubt anyone can subscribe to the pure form of either position. If I had to guess, I would assume most editors would agree with most of the sentences in both statements when presented in isolation. Remsense诉 07:13, 13 May 2024 (UTC)

No. Your characterization is too gross to be useful and your made up dichotomy is just silly. We have those templates precisely because we try to give credit where credit is due, per WP:PLAGIARISM, so there is nothing shocking at all about {{PD-USGov}} and {{EB1911}} content. Sure, there are other ways to do it, than those templates, even so. Plagiarism is not a law, so your reference to the law makes no sense. But what is the law is, Wikipedia has to be written by persons, who can legally licence what they put on our pages, and if you did not write it you can't release it, nor purport to release it nor make it appear you are releasing under your licence, when you can't and you aren't. And Wikipedia does not warrant we offer good information either, in fact Wikipedia disclaims it in our disclaimer, that does not mean Wikipedian's don't care about good information. -- Alanscottwalker (talk) 10:23, 13 May 2024 (UTC)

Wikipedia is written by people who freely license their contributions by the act of editing. But, public domain material is already free, does not need to be licensed, and so can be freely added to Wikipedia. Material that has been released under a free license can also be freely added to Wikipedia, subject to the conditions of the license, such as attribution (although we cannot copy material under a license that does not allow commercial use, but that has nothing to do with this discussion). There is no policy, rule, or law that Wikipedia has to be written by persons (although the community currently is rejecting material written by LLMs). Reliable content is reliable whether is written by Wikipedia editors based on reliable sources, or copied from reliable sources that are in the public domain or licensed under terms compatible with usage in Wikipedia. I believe that we should be explicitly citing everything that is in articles, even if I know that will not be happening any time soon. We should, however, be explicitly citing all public domain and freely-licensed content that is copied into Wikipedia, being clear that the content is copied. One of the existing templates or a specific indication in a footnote or in-line citation is sufficient, in my opinion. Donald Albury 14:43, 13 May 2024 (UTC)

Yes, you cannot present it as if you are licencing it (and indeed requiring attribution to you!) which is what you do if just copy the words into an article and don't say, in effect, 'this is not under my licence this is public domain, that other person wrote it.' (Your discussion of LLM's and what not, is just beside the point, you, a person, are copying, not someone else.) And your last point, we are in radical agreement certainly (about letting the reader know its public domain that other person wrote it, and that's what the templates try to do) we are not in a dichotomy, at all. -- Alanscottwalker (talk) 15:28, 13 May 2024 (UTC)

Alan, I think your response makes me more certain that my two polar ends are real. You're working from the viewpoint that if it's on the page, and does not contain words like "According to EB1911" outside of a little blue clicky number and outside of the history page, then the editor who put that text there is "purporting" that the text was written by that editor.

There's nothing in the license that requires is to let the reader know that it's public domain or that another person wrote it. You know that a quick edit summary is 100% sufficient for the license requirements, even if nothing in the text or footnotes mentions the source. The story you present sounds like this to me:

• The license doesn't require attribution for public domain content.
• Even if it did, it wouldn't require anything more visible than an edit summary saying "Copied from EB1911".
• So (you assert) there has to be in-text attribution ("According to EB1911, a wedding cake...") or a plain-text statement at the end of the article ("This article incorporates text from EB1911") to the public domain, so the casual, non-reusing reader knows that it wasn't written by whichever editor posted it on the page.

This doesn't logically follow. I suspect that what you've written so far doesn't really explain your view fully. WhatamIdoing (talk) 16:44, 13 May 2024 (UTC)

No. Your false dichotomy has already been shown to be of no value. Now you add to your baseless assumptions about clicky numbers and what not. I think that editors add content to Wikipedia under the license (otherwise we would have no license), yet I also think we need to tell the reader that the matter comes from somewhere else, when it comes from somewhere else. None of that should be hard to understand for anyone. (And besides, article histories are not secrets, they are public and publicly tied to text available to the reader and anyone else.) It's just bizarre that you would imagine an unbridgeable void, when basically everyone is saying that a disclosure should be made, and they are only really discussing degrees and forms of disclosure. -- Alanscottwalker (talk) 17:13, 13 May 2024 (UTC)

Yes, a disclosure should be made, and it was made. Phil Bridger (talk) 18:51, 13 May 2024 (UTC)

Yes, indeed, and that is why the discussion is about form. Alanscottwalker (talk) 19:14, 13 May 2024 (UTC)

Alan, I don't agree that the spectrum I describe is a false dichotomy, or that anyone has even attempted to show whether it has value, though I gather that you happen to disagree with it.

I don't agree that the CC-BY-SA license requires disclosure of the source of public domain material. I think that's a question for a bunch of lawyers to really settle, but based on my own understanding, it does not. I think that Wikipedia should have such requirements (e.g, in Wikipedia:Public domain, which notably does not mention the CC-BY-SA license as a reason to do so; instead, it says only that this is important for Wikipedia's reliability), but I don't think we have any reason to believe that the license does. This distinction may seem a little like hairsplitting, but if we propose to change our rules about how to handle these things, we should be accurate about what's required for which reasons. WhatamIdoing (talk) 17:00, 15 May 2024 (UTC)

It should not take a lawyer to tell you that to grant a licence you first have to have a right, and that you should not be misrepresenting that you have right when you don't. A lawyer can't give you the ability to be honest. You're not proposing to change rules, and indeed there is no proposal here, so that proposal talk of yours is irrelevant at best. (As for your false dichotomy, it is just a figment of your imagination, a useless piece of rhetoric, where you pretend you know what others think.) Alanscottwalker (talk) 21:37, 15 May 2024 (UTC)

I agree that to grant a license, you first have to have a right.

However, AIUI, the point of public domain content is that everyone already has the right to use it. Adding a CC-BY-SA 4.0 license to public domain material does not add restrictions to the material. The Creative Commons folks say this: "Creators may also apply Creative Commons licenses to material they create that are adapted from public domain works, or to remixed material, databases, or collections that include work in the public domain."

As far as I'm concerned, they might as well write "Yeah, you can put public domain material straight into a Wikipedia article", as our articles are practically the definition of "remixed material". WhatamIdoing (talk) 01:41, 25 May 2024 (UTC)

How dishonest your statement is, no you don't have a copyright in the public domain, and the first sentence of that article says "CC licenses should not be applied to works in the worldwide public domain." It further advises to "mark public domain material, so that others know they are also free to use this material without legal restriction." Again, no one can give you the ability to be honest. Alanscottwalker (talk) 00:54, 26 May 2024 (UTC)

I never said that you have a copyright in the public domain. I said "everyone already has the right to use it [public domain material]".

The context of the sentence you quote is that adding restrictions when the entire work is public domain is legally ineffective. For example:

• EB1911 is public domain.
• I put the whole thing on a website with a CC-BY-SA license.
• Result I can't enforce my claimed rights, because EB1911 is still public domain.

However:

• EB1911 is public domain.
• I put one paragraph in the middle of whole page that is not public domain but has a CC-BY-SA license.
• Result: The page is partially remixed work, and it's legal. The non-public domain parts are still CC-BY-SA, and the one paragraph is still public domain.

You seem to have only a partial quotation of a relevant sentence. The full sentence is "We strongly encourage you to mark the public domain material, so that others know they are also free to use this material without legal restriction." We strongly encourage == not a requirement for the license. WhatamIdoing (talk) 19:54, 26 May 2024 (UTC)

Would you stop the misdirection, that the CC license should not be applied to public domain work and should be marked as still public when used, so that people are not misled that it has legal restriction, was my point, which you then totally wigged out about. The point is not to be dishonest with readers, that they are misled when you don't let them know its public domain, even when you used it and asserted your licence, as the license is only needed because of your copyright. Alanscottwalker (talk) 13:34, 27 May 2024 (UTC)

I disagree with your claim that "people" are misled by having a paragraph from EB1911 in the middle of a Wikipedia article, because almost nobody has any idea how the licenses work or how Wikipedia articles get written.

The ones who do know tend to be Wikipedia:Mirrors and forks, and they don't care if there's a public domain paragraph in the middle, because they want the whole thing, not a single paragraph, and they want it automated, which means not looking at the contents line by line.

I disagree with your claim that we need to "let them know its public domain". Also, nothing proposed here, or in any example I've ever seen in discussions on this subject would "let them know its public domain". Spamming "According to the EB1911 entry..." into the middle of an article does not "let them know its public domain". That merely "lets them know that it's a quotation from a different publication". WhatamIdoing (talk) 15:38, 27 May 2024 (UTC)

Stop it. No one has suggested putting anything on the middle of the article. You're clearly wrong, the CC people say so. And your clearly wrong about not telling the reader, Wikipedia does it with templates already. Unless your trying to be dishonest, there is no reason not to tell. Alanscottwalker (talk) 00:09, 28 May 2024 (UTC)

You're clearly wrong, the CC people say so. The quotes from CC posted and linked here clearly prove that WAID is not wrong. In a discussion about honesty it is not a good look to repeatedly accuse someone of being dishonest when they are not being so. Tone down the rhetoric and start reading what other people are writing. Thryduulf (talk) 00:44, 28 May 2024 (UTC)

No, the CC people say "mark the public domain material, so that others know they are also free to use this material without legal restriction" when you use the CC license, and the Wikipedia guidelines agree that you should do so and even refers you to templates for that purpose, so WAID is wrong and yes it's a form of dishonesty not to give disclosure when you copy. Alanscottwalker (talk) 00:52, 28 May 2024 (UTC)

As has been pointed out to you already, that is only a partial quote and is misleading. The full quote, from [1] is Creators may also apply Creative Commons licenses to material they create that are adapted from public domain works, or to remixed material, databases, or collections that include work in the public domain. However, in each of these instances, the license does not affect parts of the work that are unrestricted by copyright or similar rights. We strongly encourage you to mark the public domain material, so that others know they are also free to use this material without legal restriction.

"We strongly encourage you to mark..." is not a requirement, but a recommendation.

Further, the CC website states {{tpq|CC licenses have a flexible attribution requirement, so there is not necessarily one correct way to provide attribution. The proper method for giving credit will depend on the medium and means you are using, and may be implemented in any reasonable manner. Additionally, you may satisfy the attribution requirement by providing a link to a place where the attribution information may be found.[2]

The templates you refer to in your 00:09 comment do not identify which content is available in the public domain, merely that some material was incorporated into the article in some way. It may or may not (still) be present in a form that is public domain. Thryduulf (talk) 01:50, 28 May 2024 (UTC)

There is nothing misleading about it, the CC still say "mark the public domain" material when you use the license and it says why, to let the reader know. And the templates still mark it as public domain material. Alanscottwalker (talk) 02:00, 28 May 2024 (UTC)

When someone presents evidence of you misleadingly selectively quoting, and you double down on the misleading selective quoting, twice, it is very difficult to continue assuming good faith. Thryduulf (talk) 02:05, 28 May 2024 (UTC)

You presented no such evidence, you proved what I said is true, the CC people are the ones who say when you use the license mark the public domain, indeed you admitted they said it, when you said it's their recommendation. -- Alanscottwalker (talk) 02:11, 28 May 2024 (UTC)

"Mark it" sounds like the Imperative mood. What they actually said is "We strongly encourage you to mark", which is not the imperative mood. "We strongly encourage you to" means "but it's optional, and you don't have to". WhatamIdoing (talk) 04:56, 28 May 2024 (UTC)

That's irrelevant. The salient point is the same, marking is still something one should do, indeed they feel strongly about it. And as Wikipedia agrees in its guidance, its what Wikipedia indeed does and tries to do. Doubtful that's just coincidence, it is how responsible actors, act in this regard of good practice with CC licenses, strongly so. Alanscottwalker (talk) 09:43, 28 May 2024 (UTC)

But we don't do what they recommend. They want something like:

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Editors here are saying that they want either "According to EB1911..." at the start of the sentence (which doesn't tell the re-user anything about the material being public domain) or they want {{EB1911}} at the end of the page (which doesn't tell the re-user which material is public domain). Neither of our standard practices actually follow the CC lawyer's optional recommendation. WhatamIdoing (talk) 04:20, 2 June 2024 (UTC)

No, the CC people don't actually advise on how to mark, and again irrelevant, even if they did say there was another way to mark, we do do then what they recommend at least in spirit, because we are in accord with them that's it is something one should do. (And whomever these other editors are you wish to respond to, you should take up with them). -- Alanscottwalker (talk) 11:21, 4 June 2024 (UTC)

The CC FAQ page says We strongly encourage you to mark the public domain material. It does not say "We strongly encourage you to mark that some unidentified portion of the licensed work contains public domain material". WhatamIdoing (talk) 17:47, 4 June 2024 (UTC)

The CC FAQ page says there is flexibility in the how of all attribution, and that's not advice on how because they don't know what you are writing. Alanscottwalker (talk) 20:13, 4 June 2024 (UTC)

CC says marking public domain parts of a work is encouraged but not required.

CC says attribution methods can be flexible.

Alanscottwalker says just dropping a footnote, like all the other sentences in our article, is not enough

Alanscottwalker says if you did not write it you can't release it, nor purport to release it nor make it appear you are releasing under your licence

Alanscottwalker says you cannot present it as if you are licencing it

Alanscottwalker says the CC license should not be applied to public domain work and should be marked as still public when used, so that people are not misled that it has legal restriction

One of These Things (Is Not Like the Others)? WhatamIdoing (talk) 22:07, 5 June 2024 (UTC)

1) WhatamIdoing takes that out of context, and all of what I said in that full remark is usual and unsurprising, eg., the use of quotation marks for quotes is common, don't you know, that's why quotation marks basically exist. Besides, when we correctly use the PD footnote template that is more than a usual footnote.

2) WhatamIdoing already agrees you can't release what you do not own, which is a thing that is universally acknowledged by everyone. It naturally follows, in honesty you should tell them it is PD, not your license.

3 and 4) That's why you mark it PD, per Wikipedia guidelines and CC advice, there are different ways to mark it PD, including in using the footnote template and the endnote template but sure there are other ways (and anodyne exploring various ways was what the conversation could have been until WhatamIdoing derailed it with a false dichotomy of an unbridgeable gap, and got overwrought when one said telling them it is PD is what you should do in CC situations) . -- Alanscottwalker (talk) 21:18, 6 June 2024 (UTC)

• Wikipedia:Attribution seems very clear that all material that is knowing used from another source should be attributed, though how that attribution is done varies by scenario. That would mean knowing pulling from PD material in whole without providing attribution to the PD source is a violation. This doesn't mean we cannot wholesale use content from PD sources as if it were a whole article but that source should be named somewhere - that could be a talk page header, it could be a statement in an edit summary, it doesn't necessarily need to be a footnote on the mainspace article page. --Masem (t) 13:52, 27 May 2024 (UTC)

  That's fair as far as that page goes but the particular guideline is WP:FREECOPY, which is somewhat more emphatic -- Alanscottwalker (talk) 14:40, 27 May 2024 (UTC)

  I wonder whether Wikipedia:Plagiarism#Copying material from free sources should be in Wikipedia:Plagiarism at all. Marking the copyright status of a paragraph has nothing to do with plagiarism. WhatamIdoing (talk) 15:41, 27 May 2024 (UTC)

  Sure it does, as with not doing plagiarism, its handling material honestly, and handling is telling the reader. Alanscottwalker (talk) 00:17, 28 May 2024 (UTC)

  I'm wondering whether the sections about copyright information should be in Wikipedia:Copyrights. For example, the Wikipedia:Plagiarism#Copying within Wikipedia section might fit better in Wikipedia:Copyrights#Re-use of text; Wikipedia:Copyrights#Re-use of text could go in Wikipedia:Copyrights#Using copyrighted work from others.

  I don't think that copyright is primarily a matter of honesty; it is a matter of legality. WhatamIdoing (talk) 05:01, 28 May 2024 (UTC)

  Fits fine where it is, various ways, and use cases of telling the reader where the words they are reading are coming from, and is about being upfront with the reader, not taking unearned credit, not misleading the reader. So yes, honesty. Alanscottwalker (talk) 10:03, 28 May 2024 (UTC)

  It is kind of a fantasy to think that, to the average reader, "credit" is being considered at all. Yes, we maintain the edit history of every article, but the typical reader is here to learn something about a subject, not to look for claims of who wrote what part of it. Taken to the extreme, of course, a requirement to provide attribution for everything in the public domain would mean that we would not be able to use any individual word in the English language without noting where that word was coined. BD2412 T 21:55, 10 June 2024 (UTC)

  I can see cases when the material presents subjective or questionable claims, or if we started to present out of copyright fiction as fact. I could numerous issues if we took a piece of medical journalism from the 19th century and present it as an encyclopedic piece without attribution. A straight forward biography in the PD of someone long dead is far less a problem. Masem (t) 22:51, 10 June 2024 (UTC)

Notifying Wikiprojects and WP:CANVASS

This issue has disrupted multiple threads on unrelated issues, so I figure I should raise it at a nice central location where we can hash it out once and for all:

Is notifying the relevant Wikiprojects to a discussion ever a violation of WP:CANVASS?

(My position is no, it's not, but I'll save the argumentation for later.) Loki (talk) 02:02, 28 May 2024 (UTC)

It can be, if the Wikiproject is unrepresentative of the broader community. There are several ARBCOM principles relevant to this, including:

Participation:

The determination of proper consensus is vulnerable to unrepresentative participation from the community. Because of the generally limited number of editors likely to participate in any given discussion, an influx of biased or partisan editors is likely to generate an improper illusion of a consensus where none (or a different one) would exist in a wider population.

Canvassing:

While it is acceptable to notify other editors of ongoing discussions, messages that are written to influence the outcome rather than to improve the quality of a discussion may be considered disruptive. In particular, messages to fora mostly populated by a biased or partisan audience — especially when not public — are considered canvassing and disrupt the consensus building process by making participation lopsided.

No exception is made for if the forum is organized as a Wikiproject; an influx of biased or partisan editors is an issue regardless of whether they came from a non-representative Wikiproject or another non-representative forum.

WP:CANVASS says the same thing; it forbids notifications to a partisan audience, and makes it clear that WP:APPNOTE does not create exceptions to these rules; Do not send inappropriate notices, as defined in the section directly below, and do not send messages to users who have asked not to receive them.

It's important to note that most Wikiprojects are representative and non-partisan; our rules on canvassing only affect a very small number, and even those are only partisan on some topics within their area of interest and can be notified without issue on the rest. BilledMammal (talk) 02:09, 28 May 2024 (UTC)

I have only a few short things to say:

1. The idea of a "partisan Wikiproject" is ridiculous. If such a thing existed, it would be WP:NOTHERE and get booted.

2. A Wikiproject tending to vote a particular way is not the same thing as a partisan Wikiproject: consider for instance a vote about whether evolution should be treated as true where everyone from WP:BIOLOGY and half of all other editors voted the same way while half of all other editors did (and assuming these groups are roughly balanced). In this case, the Wikiproject members are clearly in keeping with the global consensus and it's a minority of non-members that aren't.

3. The line in WP:APPNOTE that you're quoting was added only about a year ago with little discussion on the talk page. You are in fact one of the people who advocated adding it.

4. Both those lines from ArbCom that you're quoting come from the same case which was about a secret and partisan outside forum. Neither even contemplates the idea of notifications on Wikipedia being canvassing. Loki (talk) 02:32, 28 May 2024 (UTC)

We've had a long history of issues with partisan Wikiprojects, recently for example WikiProject Roads which became so hyper-partisan that it ended up forking rather than complying with policy and guideline when all their attempts to destroy those policies and guidelines failed. Horse Eye's Back (talk) 13:59, 3 June 2024 (UTC)

If a WikiProject is so problematic/"partisan" that it is causing significant issues and vote brigading, it needs to be taken to Arbcom. A project cannot be considered problematic by definition without at the very least community input through ANI, but preferably an Arbcom case. Curbon7 (talk) 21:50, 11 June 2024 (UTC)

No, it isn't. I have been accused of selective notification for notifying Wikiproject Quebec about an RfC concerning a Quebec premier, while not notifying other provincial wikiprojects, which is ridiculous. Anyway, the correct solution to perceived imbalances in notifications is always to notify more editors through various means of mass notification; it is never to accuse editors using these mandated channels of "canvassing" - the latter is what is disruptive, IMO.

And concerning BilledMammal's comment on this, the idea that any WikiProject would be a biased or partisan audience is set out here without any shred of evidence. Nor is there any evidence that Arbcom or INAPPNOTE had these public, on-wiki fora in mind when cautioning against partisanship. The fact is that Wikiprojects concern topics, not ideologies (whether on-wiki or off-wiki ideologies) so if you want to be informed on a topic where you disagree with the opinions of the most active contributors, the sensible thing has always been to join the wikiproject or at least to follow its page for updates.

Just for emphasis: accusing editors of bias because they belong to or notify wikiprojects is itself a violation of WP:NPA and disruptive. When I was accused of bias and canvassing for notifying Wikiproject Quebec, I felt both hurt and falsely accused - that is, once I was finished laughing at the absurdly false assumptions the accusation implied concerning my views about nationalism. Newimpartial (talk) 02:18, 28 May 2024 (UTC)

the idea that any WikiProject would be a "biased or partisan audience" is set out here without any shred of evidence.

As I understand it, the intent of this discussion is to determine whether it is theoretically possible for a Wikiproject to be unrepresentative or mostly populated by a biased or partisan audience and thus inappropriate to notify.

Whether any specific Wikiproject is unrepresentative or mostly populated by a biased or partisan audience is a different question that can be addressed elsewhere. BilledMammal (talk) 02:23, 28 May 2024 (UTC)

I don't see the question posed in this section as whether it is theoretically possible for a Wikiproject to be biased and notifying it to be canvassing; I think the relevant question is whether this is a practical or relevant concern. What matters isn't the theoretical (how many angels can fit on the head of a pin) but rather the practical (is there an angel on the head of my pin, and if so, does it give me an unfair advantage in discussions to determine consensus of the community on a topic).

What is clearly the case is that these kind of accusations - claims that specific wikiprojects are partisan (always without evidence; always a "theoretical" concern) and that notfiying them is therefore partisan - have had real, and unmistakable toxic effects on-wiki. These effects have included individual editors feeling attacked and misunderstood, and also community time wasted on dramaboards, and to my knowledge the community has not reached consensus that any wikiproject notification was ever canvassing, though efforts have been (correctly) made to ensure that editors having differing perspectives on issues are also notified.

In any event, there is a clear and present cost to the community thanks to toxic discussion when certain editors insist on retaining the accusation of "canvassing by notifying partisan wikiprojects" within their arsenal. Given this evident pain point, it seems clear to me that the onus is on those holding this belief to present evidence that it is a real, not theoretical, possibility. Otherwise we are dragging down the level of civility in the community and wasting the time of editors and administrators just because certain editors believe they ought to be able to make a certain argument - even though, to the best of my knowledge, the community has never reached consensus that this argument was ever borne out in an actual situation on-wiki. Newimpartial (talk) 02:55, 28 May 2024 (UTC)

always without evidence; always a "theoretical" concern

That's not accurate; the discussions that Loki linked as provoking this discussion included evidence. However, I won't go into it here, both because I don't want to derail this discussion with talk of specific WikiProjects and because you are topic banned and thus can't engage with the evidence. BilledMammal (talk) 02:59, 28 May 2024 (UTC)

Before this is closed, I wanted to clarify that when I said, to my knowledge the community has not reached consensus that any wikiproject notification was ever canvassing, I was referring to the act of issuing an appropriately worded, neutral notification to a Wikiproject. Issuing a non-neutral notification, whether to a wikiproject or a dramaboard, can of course be canvassing. The fairly extensive contributions made to this discussion have confirmed my opinion that a neutrally-worded notification to a wikiproject is never canvassing, and that the solution to selective notifications (e.g., concerning Israel-Palestine issues) is always to notify more editors, bringing in diverse views from other relevant projects or through centralized boards. I don't think this is applied Neutonian physics, here. Newimpartial (talk) 14:29, 4 June 2024 (UTC)

Agreed with @Gnomingstuff. While I don't deny there have been legitimate and serious issues with canvassing, canvassing is slowly becoming Wikipedia's Stop the Steal. By that I mean, it's a accusation freely thrown out by someone when their idea loses at a !vote or is suddenly drowned out by opposing ideas. The obvious intent is to try for an appeal by mass discrediting any opposing opnion, rather than accept their idea might might have been an unpopular one. So any policy changes, IMHO, should be to clarify what is and is not canvassing and not introduce more confusion and open more doors for appeals and lawyering when ones proposal isn't suceeding.Dave (talk) 14:10, 4 June 2024 (UTC)

Theres no such thing as a WikiProject being "unrepresentative", literally any editor can watchlist any WikiProject's talk page. I watchlist, for example: Wikipedia:WikiProject Arab world, Wikipedia:WikiProject Baseball, Wikipedia:WikiProject Biography, Wikipedia:WikiProject Egypt, Wikipedia:WikiProject Human rights, Wikipedia:WikiProject Islam, Wikipedia:WikiProject Israel, Wikipedia:WikiProject Israel Palestine Collaboration, Wikipedia:WikiProject Jewish history, Wikipedia:WikiProject Judaism, Wikipedia:WikiProject Palestine, Wikipedia:WikiProject Syria, Wikipedia:WikiProject Terrorism, Wikipedia:WikiProject United States courts and judges. Any notification to any of those I would see. Now there are times where notifying only specific WikiProjects that have an intended audience may be an issue, like only notifying WikiProject Palestine about some discussion also relevant to WikiProject Israel, but notifying WikiProjects that have within their scope whatever is under discussion is not canvassing. nableezy - 02:31, 28 May 2024 (UTC)

Theres no such thing as a WikiProject being "unrepresentative", literally any editor can watchlist any WikiProject's talk page.

They can, but the possibility that they can doesn't mean the forum isn't unrepresentative if they don't. Consider a hypothetical; lets pretend that 90% of people affiliated (watchlisting, members, etc) with Wikipedia:WikiProject Israel are pro-Israel in relation to the Israel-Palestine conflict. Clearly, it would be unrepresentative, and a WP:CANVASS violation to notify unless there is an equally unrepresentative forum in the opposite direction that is also notified (perhaps Wikipedia:WikiProject Palestine).

To be clear, I'm not saying either of these are unrepresentative or mostly populated by a biased or partisan audience; I haven't looked into either of them, and am only using them for the sake of example. BilledMammal (talk) 02:38, 28 May 2024 (UTC) Edited 02:51, 28 May 2024 (UTC) to clarify

If something is not relevant to WikiProject Palestine, like say an article on some random company in Tel Aviv, then notifying WikiProject Israel and not WikiProject Palestine would be totally fine. If something is relevant to both, then only notifying one would be an issue. I literally just said, in the comment you are replying to, there are times where notifying only specific WikiProjects that have an intended audience may be an issue, like only notifying WikiProject Palestine about some discussion also relevant to WikiProject Israel. But the idea that a page that any and every registered user can watchlist can be a target for canvassing is silly. I guarantee you "pro-Israel" users watchlist WikiProject Palestine, and "pro-Palestine" users watchlist WikiProject Israel. If the notification itself is neutral, it isnt a CANVASSING violation to post to a WikiProject about a discussion in its scope. nableezy - 02:43, 28 May 2024 (UTC)

This is similar to how I feel about it too: there are times when notifying only certain Wikiprojects says bad things about the notifier's intent, but I don't think there's ever a time where notifying only certain Wikiprojects ever causes provably skewed results.

(Furthermore, not notifying the relevant Wikiprojects is often also suspicious in this way. Sometimes it smacks of not wanting a decision to be scrutinized by people who regularly edit in the topic area.) Loki (talk) 02:48, 28 May 2024 (UTC)

You previously discussed your point of view regarding partisan WikiProjects at Wikipedia:Village pump (idea lab)/Archive 49 § Modifications to CANVASS, and it didn't get much support. As I said then, WikiProjects are just groups of editors sharing a common interest and working together to further the goals of Wikipedia, usually by working on various initiatives. Most of them are oriented around a content area, and thus attract the knowledgeable editors in that area. Notifying the corresponding WikiProjects for related content areas is considered to be a neutral way of reaching the interested editors who are best able to bring greater context to a decision. It's not partisan to be interested in a content area.

There can be groups that, by their nature, have self-selected a set of editors with a specific position on some issue, and thus its members are more prone to make partial arguments for that position. If someone set up WikiProject solely to vote in favour of removing all foreign language names from English Wikipedia articles, for example, then notifying it would result in vote-stacking. However the community has dealt with this by reaching a consensus that the group's purpose is counter to the best interests of the overall project and disbanding the group. isaacl (talk) 03:20, 28 May 2024 (UTC)

• There have been issues relating to very cliquey Wikiprojects/similar pages. Not a huge number but hard to say "ever". The question says "the relevant Wikiprojects", which is plural, while I assume the issue is usually with a relevant Wikiproject. The common practice of simply notifying all Wikiprojects on the talkpage, with a neutral message the same across all notifications, works fine in the vast majority of cases. CMD (talk) 02:46, 28 May 2024 (UTC)

  The question at issue here was originally sparked by someone notifying the relevant Wikiproject and all people on the talk page about an AFD for an essay closely related to LGBT issues. The assertion by some editors for deletion, including the person who started the AFD in the first place, was that WP:LGBT was biased such that notifying them at all, even in combination with a group of editors including some editors known specifically to oppose the existence of the page, was canvassing. Loki (talk) 02:52, 28 May 2024 (UTC)

• No, the only thing that would make a Wikiproject notification a violation of WP:CANVASS is if the notification itself was done in a POV manner, such as calling for everyone at the Wikiproject to vote a certain way. Or you might get called out if it was, say, an RfC on a religious topic and the only Wikiproject you notified was Wikiproject Atheism. Though the solution to such a case is just to notify the other relevant Wikiprojects, which anyone can do. The only other case I can think of that would get you some side-eye and comments is if you were notifying Wikiprojects that very clearly had nothing to do with the topic at hand, such as if it was a Biology RfC and you went and notified Wikiproject Football. Though that would less be canvassing and more just...confusion. Silverseren^C 03:08, 28 May 2024 (UTC)

  FYI, notifying WikiProject Football about a Biology RfC would violate WP:CANVASS; see Spamming and excessive cross-posting. BilledMammal (talk) 03:11, 28 May 2024 (UTC)

• No, notifying relevant Wikiprojects about a discussion does not in itself constitute violate WP:CANVASS. To be frank, some of the claims that it does have seemed to necessarily—whether the users writing such claims intend it or not—involve prejudicial assessments, such as the presumption that WP:LGBT is somehow inappropriately 'partisan' in a way contrary to Wikipedia's purpose because—why, honestly? Because of a presumption that the project draws in LGBT editors, and on top of that a presumption that LGBT editors are inappropriately 'partisan' about LGBT-related topics compared to cisgender and heterosexual editors? I really don't see how this claim, either in the abstract or in context, doesn't inevitably hinge on prejudicial presumptions about editors that violate the wmf:Policy:Universal Code of Conduct's tenets about collegiality, good citizenship, and creating a pleasant and safe space for participants. Hydrangeans (she/her | talk | edits) 06:32, 28 May 2024 (UTC)
• Notifying a WikiProject cannot ever be a serious canvassing problem, since it's open, widely broadcast message. The issue usually is that some people sitting on a favoured WP:LOCALCON get upset at the extra attention it brings. Bon courage (talk) 07:36, 28 May 2024 (UTC)

  I think I've seen that happen. Gråbergs Gråa Sång (talk) 07:41, 28 May 2024 (UTC)

• No, the basic assumption is IMO that Wikiprojects can be watched by all kinds of people. Hopefully several of them do so because of a general interest in the topics that can pop up, and not out of a desire to promote whatever every chance they get. Some projects are pretty close to various CTOPS, like Israel/Palestine, India/Pakistan and FTN, but that is still my basic assumption. Gråbergs Gråa Sång (talk) 07:40, 28 May 2024 (UTC)
• In general and in principle, no; but in practice, in the past, certain WikiProjects have been problematic and hard to deal with. For example, Wikipedia:WikiProject Pornography fought a long and historically successful campaign to have their own SNG for pornstars, which allowed sources that weren't independent. The fighting went on for years until the SNG was finally deprecated in 2019 after this RfC; subsequently most of the pornstar "biographies" that Wikipedia used to host got deleted on the grounds that they didn't contain any biographical information at all. Porn performers' names, dates of birth, nationalities, families and career history outside porn are understandably kept quiet, so all the information we had on these people was pure kayfabe. And for another example, although the Article Rescue Squadron isn't a problematic WikiProject, it's certainly had its share of problematic members leading to various tedious Arbcom cases. I think that what history tells me is that where a WikiProject has started to develop their own groupthink and begun to diverge from mainstream Wikipedian thought, then we're going to have a problem; and people getting unhappy about notifying that WikiProject about discussions can be an early symptom of that problem starting to be noticed. To the best of my knowledge, there aren't any WikiProjects at that stage at the moment, but it's worth keeping an eye on.—S Marshall T/C 07:47, 28 May 2024 (UTC)
• The Article Rescue Squadron also came to my mind, but that was because how it partially operated historically - a few users were using it to try and vote-stack AfDs with the goal of keeping articles rather than engaging with the arguments for and against deletion and/or improving the article. It took effort but those users were dealt with and that problem has passed. The groups current focus on improving important articles that would otherwise be at risk of deletion is unproblematic. So yes, partisan WikiProjects is a theoretical problem, but unless the OP or anyone else has any actual evidence of WikiProjects attempting to distort consensus then there is no issue here. Members of a WikiProject sharing an opinion is not itself evidence of anything untoward.
  An editor selectively notifying only some relevant WikiProjects is correctly dealt with by neutrally notifying the other WikiProjects, and, if necessary, separately engaging in dispute resolution regarding that editor. Similarly an editor notifying unrelated projects and/or making non-neutral notifications is an issue with that editor. These are not evidence of a problem with notifying WikiProjects generally or with notifying specific WikiProjects in particular. TL;DR neutral notifications to relevant WikiProjects is almost never canvassing. Thryduulf (talk) 08:56, 28 May 2024 (UTC)

  I think there are cleaner examples. ARS' purpose was to find promising candidates for a WP:HEY response, so it's reasonable for them to talk about current AFDs, even if it did have some problems. Similarly, I think it's usually fair to notify Wikipedia:Fringe theories/Noticeboard about disputes involving fringe-y subjects, even though the dominant POV there is decidedly anti-fringe.

  In other cases, the only possible connection is that you happen to know this group has an opinion. For example, editors should not notify Wikipedia:WikiProject Composers about proposals to change Wikipedia:Manual of Style/Infoboxes, because that group has a history of disputes over infoboxes in "their" articles, and because if you were interested in infoboxes, you would probably not know that. A page about musicians is not an obvious place to look for information about infoboxes. However, it would be fine to notify Wikipedia:WikiProject Infoboxes, because it's an obvious page for anyone interested in infoboxes to be watching. Regardless of whether you are pro- or anti- or something else, and regardless of whether you were actively participating or silently lurking, if you wanted to be involved in infoboxes, you would expect to get infobox-related messages there. WhatamIdoing (talk) 17:04, 28 May 2024 (UTC)

• No. Notifying Wikiprojects is generally fine, and not prohibited as a purpose of projects is to provide all kinds of notice, neutral wording of the notice is key, though. -- Alanscottwalker (talk) 11:25, 28 May 2024 (UTC)
• Yes. Suppose a project -- let's say it's astronomy -- has people who are used to what's in specialized teaching or publications. Pinging them when the issue is what's best for the general reader -- let's say it's whether to capitalize Universe -- can tilt WP:MOSCAP talks. Peter Gulutzan (talk) 12:52, 28 May 2024 (UTC)

  No, we absolutely want editors familiar with a topic to participate in a discussion. You seem to be saying that editors that are familiar with a topic will be less interested in what is best for the encyclopedia than editors who are not familiar with the topic. Assume good faith until proven otherwise. Donald Albury 13:51, 28 May 2024 (UTC)

  I didn't say what you claim I "seem" to have said. Try AGF yourself. Peter Gulutzan (talk) 17:17, 28 May 2024 (UTC)

  To the question, Is notifying the relevant Wikiprojects to a discussion ever a violation of WP:CANVASS?, you responded "yes", and then said, Suppose a project -- let's say it's astronomy -- has people who are used to what's in specialized teaching or publications. Pinging them when the issue is what's best for the general reader -- let's say it's whether to capitalize Universe -- can tilt WP:MOSCAP talks. How am I supposed to interpret that to mean something other than you are opposed to pinging a project because its participants may have specialized knowledge and would therefore "tilt" (I presume the "wrong" way) the discussion. Can you rephrase your answer to make it clearer to me? - Donald Albury 17:38, 28 May 2024 (UTC)

  I will rephrase the words "Try AGF yourself." thus: You said I "seem to be saying that editors that are familiar with a topic will be less interested in what is best for the encyclopedia than editors who are not familiar with the topic" -- which would be an aspersion against my esteemed fellow editors, so you're making a conduct accusation. Then you suggest I try AGF. I'm hopeful that others didn't interpret my remark as aspersion or lack of AGF, perhaps because they can't read any such thing in them, perhaps because they can read WP:MOSFAQ. I won't engage further with you about this, unless you take it to WP:ANI. Peter Gulutzan (talk) 21:35, 28 May 2024 (UTC)

  I had a similar interpretation of what your original statement meant. I think this would have been more productive if you'd simply replied "That isn't what I meant; what I meant was..." I still don't know what you meant. Schazjmd (talk) 22:03, 28 May 2024 (UTC)

  I too thought you meant editors that are familiar with a topic will be less interested in what is best for the encyclopedia than editors who are not familiar with the topic when you said Pinging [people who are used to what's in specialized teaching or publications] when the issue is what's best for the general reader -- let's say it's whether to capitalize Universe -- can tilt WP:MOSCAP talks.. You have since stated that that is not what you meant, but you haven't stated what you did mean. Given I misunderstood the first time, I do not think my guessing again is likely to result in my getting the right answer so I will refrain from speculating. Thryduulf (talk) 22:23, 28 May 2024 (UTC)

  That's polite of you. Well, I pointed to WP:MOSFAQ so you know the idea is that Although Wikipedia contains some highly technical content, it is written for a general audience. While specialized publications in a field, such as academic journals, are excellent sources for facts, they are not always the best sources for or examples of how to present those facts to non-experts. When adopting style recommendations from external sources, the Manual of Style incorporates a substantial number of practices from technical standards and field-specific academic style guides; however, Wikipedia defaults to preferring general-audience sources on style, especially when a specialized preference may conflict with most readers' expectations, and when different disciplines use conflicting styles. This sort of argument actually did arise in the series of universe|Universe discussions, and I remember an astronomer participant suggested magazines like Astronomy or Sky and Telescope weren't scientific journals, thinking that mattered. I have a vaguer recollection that the WP:CONLEVEL words ("... participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope.") appeared when another project group thought their rules should apply within their project's articles, but that's not what I had in mind, I was only thinking about and mentioning capitalization of Universe, where I believed that specifically addressing those people would not be addressing representatives of the broader community, and subject expertise is not contested but it's about style not subject. And yes ngrams came up too, and I see that you mentioned a case (maybe a WP:MOSCAPS thread about something in French?) where subject expertise was helpful, ngrams were not. But I believe that in the case I brought up the opposite was true. Peter Gulutzan (talk) 14:49, 29 May 2024 (UTC)

  Thank you, that was very helpful. I agree that it's important to have some sort of feedback to stay connected with the general reader, and I wouldn't want our running text to read like an Auguſtan newſpaper, with Words random'ly Capitaliſed. On the other hand, the improvement to the reader in clarity, meeting "expectations", etc. for MOSCAPS standardizations like the one mentioned, seems to me about epsilon. If these style confrontations significantly deter motivated editors from improving the encyclopedia, it is a net loss to us in terms of how much the general reader is actually able to learn from the encyclopedia in the future. This isn't intended as a declaration that "the WikiProject is always right"; just a reflection that our standing assumption that "the WikiProject is always wrong" may not actually further the goals of the encyclopedia. Choess (talk) 01:19, 30 May 2024 (UTC)

  There was an issue related to this with capitalisation in the rail transport area a while back. In at least instance the MOS-focused editors had not understood that the same 3-4 word term was being used as common noun in one context and as a proper noun in another context meaning things like ngrams were not relevant (as they have no context). This is not something that would be obvious to most non-specialists but is clear to those knowledgeable about the topic area. Subject-specialist knowledge is, in many discussions, important context required to reach the correct decision - whether that decision is to follow specialist conventions or not. Thryduulf (talk) 15:02, 28 May 2024 (UTC)

  This touches on something that's puzzled me for years. When a group of editors who are principally interested in interpreting policies & guidelines come into conflict with a group of editors, like a WikiProject, with some subject-matter expertise, we default to treating the latter as parochial fanboys. But it's not clear why this should be so in a broad moral sense: the P&G interpreters are not typically a larger or less hyperfocused group than a WikiProject. I think we tend to assume that because the community at large has ratified P&Gs to embody broadly-agreed upon principles, every statutory interpretation that invokes those P&Gs for a specific case enjoys the same level of broad community support. I'm not convinced that accurately describes the sentiments of the community, though. Choess (talk) 05:01, 29 May 2024 (UTC)

  I agree. There is a tendency among some (but not all) p&g interpreters to assume that disagreement of their interpretation is disagreement with the policy/guideline rather than disagreement with their interpretation. In the rail transport area this has on multiple occasions manifested itself with sometimes heated accusations about disliking/objecting to/ignoring community consensus regarding e.g. capitalisation of common nouns when the actual disagreement was whether a given term was a common or proper noun. Thryduulf (talk) 07:43, 29 May 2024 (UTC)

• No, neutrally notifying a WikiProject about a discussion clearly within its subject matter is always permissible. It would not be at all helpful, for example, to prohibit notifying WP:MED on the basis that its members are more diligent about applying WP:MEDRS than the average Wikipedian, and thus "partisan". WikiProjects fundamentally are places where editors can be notified of discussions and editing opportunities related to a subject area. If a WikiProject can't reliably be notified of discussions within its subject area, it can't meaningfully function. It would be fairer to take any allegedly problematic WikiProjects to MfD rather than to try and place restrictions that would allow them to exist in name but not function.--Trystan (talk) 13:44, 28 May 2024 (UTC)
• No, the idea that we should view people with an interest in a topic as being a biased set rather than an informed set is to speak against the value of knowledge. An informed person is of more value in a relevant discussion; we want the deletion discussion of the Smoking cures broken legs AFD to have more interest from those interested in Wikipedia's medical coverage in general and not just those who found themselves part of making such a page. The fact that the medical editors will not come up with the same view as whatever other editors choose to involve themselves in that discussion is a plus, not a problem. The idea that we can contact Wikiprojects only if they will respond in the exact same ratio as other editors would make contacting Wikiprojects pointless as it would have no impact on the results. The idea that Wikiprojects having an informed POV makes them a problem would suggest dismantling the entire Wikiproject system. Selectively notifying Wikiprojects with the intent of skewing results is a problem, but notifying all the obviously related Wikiprojects is not. -- Nat Gertler (talk) 16:24, 28 May 2024 (UTC)
• No, I don't believe there's partisan wikiprojects to the extent that notifying the relevant ones is canvassing. In obvious cases (i.e. only notifying WP:ISRAEL for a dicussion about the Second Intifada) selective notifications could be a sign of canvassing, but properly performed WP notifications are not canvassing. AlexandraAVX (talk) 16:48, 28 May 2024 (UTC)

  Or at least attempted canvassing. It seems probable all kinds of editors would watch something like WP:ISRAEL. Gråbergs Gråa Sång (talk) 17:05, 28 May 2024 (UTC)

  Agreed. AlexandraAVX (talk) 17:07, 28 May 2024 (UTC)

  Another example is if we are discussing whether Foo (film) or Foo (train) is a primary topic or if Foo should be a dab. Notifying Wikiproject Film but not WikiProject Trains might seem unfair. However, I agree that 99% of notifications to projects do not constitute canvassing. Certes (talk) 17:17, 28 May 2024 (UTC)

• Only if the notification does not meet WP:APPNOTE or is to a project which attempts to enforce a WP:LOCALCONSENSUS. If it is the former, rephrase; if it is the latter, focus on the local consensus-enforcement bit. ~~ AirshipJungleman29 (talk) 18:56, 28 May 2024 (UTC)

  The contention I'm trying to argue against here is that there are some projects that are biased such that notifying them at all would not meet WP:APPNOTE. So, could you please rephrase? Loki (talk) 13:08, 30 May 2024 (UTC)

  If there are projects that are so biased that a neutral notification about a topic relevant to their topic area would not meet APPNOTE then the Community needs to have a serious discussion (I guess at AN(I)) about that the problems with it and/or the relevant participants can be resolved. I'm not currently aware of any such groups, but if you are then please present the evidence. If you haven't got any such evidence, then please refrain from casting aspersions. Thryduulf (talk) 13:14, 30 May 2024 (UTC)

  Please read more carefully: the contention I'm trying to argue against here Loki (talk) 15:36, 30 May 2024 (UTC)

  My apologies. Thryduulf (talk) 18:40, 30 May 2024 (UTC)

  No problem! Loki (talk) 19:31, 30 May 2024 (UTC)

• Is notifying the relevant Wikiprojects to a discussion ever a violation of WP:CANVASS? No. Can the language of such a notification be canvassing? Yes. Can there be disagreement about which projects are "relevant"? Sure, but I don't see a way to avoid case-by-case determinations of that. All of this said, it's not impossible that a project could function like a canvassing club, but that would need lots of evidence and again should be handled on a case-by-case basis. — Rhododendrites ^talk \\ 23:15, 28 May 2024 (UTC)
• WikiProjects are an accepted option for dispute resolution per the policy Wikipedia:Dispute resolution § Related talk pages or WikiProjects. Some issues would be if the notification is phrased in a non-neutral way, or if only a subset of reasonably relevant projects were notified. —Bagumba (talk) 09:46, 1 June 2024 (UTC)
• No, and saying "yes" is, inadvertently or on purpose, helping along years' worth of reputation laundering of the deletion crusades waged by like 10 editors against topics covered by certain WikiProjects -- cricket players, football players, roads, I'm probably missing a few -- by creating consensus for reasonable, unobjectionable-sounding policies and/or against scary-sounding straw men like "partisan bias." The idea is to make it easier to do this stuff as covertly as possible, without having to deal with the pesky obstacles of the rest of the project. To establish a kind of pre-emptive canvassing where they are the only people who ever find out about deletion requests. Gnomingstuff (talk) 22:03, 1 June 2024 (UTC)

  Yeah, I will also say that my immediate reaction to the accusation that started all this was "not giving notification to anyone who might like this essay that you're trying to get it deleted is also unfair for the same reasons as canvassing would be, and it's weird we don't have a policy about it". Loki (talk) 22:20, 1 June 2024 (UTC)

• WP:APPNOTE leaves no room for ambiguity on this:
  

An editor who may wish to draw a wider range of informed, but uninvolved, editors to a discussion can place a message at any of the following:

• The talk page or noticeboard of one or more WikiProjects or other Wikipedia collaborations which may have interest in the topic under discussion.
  

The policy says explicitly "one or more WikiProjects" (my emphasis on the word one). Therefore we can conclude from the actual WP Behavioural Guideline that drawing attention of a discussion to only one WikiProject is acceptable per WP Guidelines. TarnishedPath^talk 12:55, 3 June 2024 (UTC)

You need to read all of APPNOTE; the third last paragraph makes it clear that it does not create an exception to INAPPNOTE.

This makes sense; why would we ever wish to permit biased, partisan, or non-neutral notifications? BilledMammal (talk) 13:02, 3 June 2024 (UTC)

• It really depends on the context... Not all wikiprojects are created equal, some are good places where non-partisan experts on a topic can be found and some are toxic slime cultures of fans and die hards. The biggest issue for me isn't really notification or non-notification its selective notification... People seem to want to talk about the Arab-Israeli conflict so lets use that as an example: if when soliciting comments to a discussion involving the war in Gaza a user notifies only WikiProject Palestine but not WikiProject Israel or vice-versa thats a problem. From my perspective if WikiProjects are being solicited then all of the relevant WikiProjects should be notified, but again it depends on the context. Horse Eye's Back (talk) 13:55, 3 June 2024 (UTC)

  But in that particular example, is it really a problem? Isn't it likely enough interested editors are watching both? But sure, for a Arab-Israeli conflict thing, if you're doing one, may as well do the other. Gråbergs Gråa Sång (talk) 14:00, 3 June 2024 (UTC)

  That doesn't seem likely, everything I have ever experienced on wikipedia suggests otherwise. Notifying different wikiprojects brings different people to the discussion, I have never encountered a topic area where multiple wikiprojects are made up of the exact same group of people. Anything that has the effect of skewing the discussion towards a specific POV is a problem and thats true whether or not canvassing is involved. Horse Eye's Back (talk) 14:09, 3 June 2024 (UTC)

• I infer a couple of different sentiments in play here:

A) "It's just as likely for pro- and anti- users to watch the same WikiProject. It's WikiProject Israel, not WikiProject ProIsrael."

B) "In practice, participants in WikiProject Thing are mostly pro-Thing."

Is there any way of determining which of these is true? Barnards.tar.gz (talk) 15:04, 3 June 2024 (UTC)

The difficulty is getting a list of participants. The ideal list would be a list of editors who watch a Wikiproject, but that data is not available. Instead, I've created an approximation based on the editors who are listed as members and the editors who have made at least five edits to the projects talk page.

For the purpose of demonstration I have applied to this Wikiproject US Roads in relation to this RfC; I have done so because the RfC is long past and Wikiproject US Roads has forked, so I feel using them as an example will produce less drama and be less likely to derail this discussion than more recent examples.

Extended content

Discussion Group Support Oppose Count Percent Count Percent Proposal 1: original research Members 12 100% 0 0% Non-members 36 67% 18 33% Both 48 73% 18 27% Proposal 2a: reliable sourcing Members 10 91% 1 9% Non-members 3 11% 24 89% Both 13 34% 25 66% Proposal 2b: image layers Members 6 67% 3 33% Non-members 1 4% 27 96% Both 7 19% 30 81% Proposal 3: history Members 9 100% 0 0% Non-members 10 34% 19 66% Both 19 50% 19 50% "Members" are determined by either being listed on the member list or having made five or more edits to the talk page I didn't review multi-choice questions to keep the analysis simple, and I didn't review low participation questions as they lack sufficient data.

The evidence tells us that for some Wikiprojects there are topics the editors are collectively biased on, but I don't think it is true of the vast majority of Wikiprojects. BilledMammal (talk) 03:32, 4 June 2024 (UTC)

1. Why do you think this approximation is any good? Clearly the list of members is a lot more likely to actually agree with the project of the Wikiproject than the list of watchers, right?

2. Roads is a bad example exactly because they forked. Your argument would be benefited more by a negative example: if you could show some Wikiprojects where the membership does not seem to share similar opinions on topics relevant to the topic area that would at least prove WP:LGBT is exceptional. Loki (talk) 03:38, 4 June 2024 (UTC)

1. The result is the unchanged if I only include editors with at least five edits to the talk page.

2. The question is "can a Wikiproject be partisan", to the extent that notifying them is likely to generate an improper illusion of a consensus where none (or a different one) would exist in a wider population. Roads is a good example of this because they demonstrate that it is possible. If you believe all WikiProjects are partisan, then I encourage you to provide the evidence, but I am skeptical. Alternatively, find a WikiProject that editors would not expect to be partisan, link a few well-attended, centrally-held, binary RfC's that the WikiProject was notified of, and I can do the analysis for you. BilledMammal (talk) 03:55, 4 June 2024 (UTC)

This is to me a centrally flawed concerned; it basically brings it down to "it's okay to alert a Wikiproject only if they are so in accord with non-members that it makes no difference in the results", which is silly. We want informed people making decisions based on being informed, and information should be something that changes perspective. (It is also impracticable; we cannot be effectively surveying a given Wikiproject for their view in advance of notification, so implementing the idea that notifying a relevant-but-biased Wikiproject is canvassing would in essence shut down notifying Wikiprojects at all.) -- Nat Gertler (talk) 23:12, 5 June 2024 (UTC)

I appreciate this data, but I interpret it quite differently from BM. For one thing, I would not regard the population of "non-members" who participate in a discussion as a kind of target for how the members of an "unbiased" wikiproject should be distributed. We have no way of knowing how well "non-members" represent the rest of the community or why they were motivated to participate in the discussion

Also, I want to point to the actual impact of the participation of project members on the four proposals mentioned. The first proposal was supported by members and non-members alike, so the participation of members was not likely to affect the outcome. The middle proposals were supported by members and opposed by non-members, and therefore did not reach anything approaching consensus even though members disagreed.

The most interesting case, though, is the last proposal. The net preferences of members and non-members pretty much canceled out, leaving the discussion seemingly deadlocked. I would argue that this is actually a desirable outcome of member participation; if we assume that members are more likely to be contributing to content development in this area, then it is better to have a non-consensus in which their voices are heard (motivating further discussion and new proposals) than a clear consensus against in which their perspectives are seemingly excluded.

And of course what makes this case relevant is also what makes it unusual: that members of a single wikiproject, sharing similar views, make up such a large portion of those !voting on a set of proposals. The much more typical case is that appropriate notifications of projects with different perspectives, or the use of WP:CENT, dilutes the participation from any one group to a small - if sometimes the best-informed - part of the whole. Newimpartial (talk) 21:14, 5 June 2024 (UTC)

I think both are true depending on which project we're talking about, there is a large diversity of WikiProjects and no generalization is going to apply to all of them. I will also note that some wikiprojects are strongly "anti-thing" like WikiProject Discrimination and WikiProject Alternative medicine. Horse Eye's Back (talk) 18:45, 5 June 2024 (UTC)

• We need to give up the idea that all Wikipedia editors are at the two extremes. Either ideal where the objectives of Wikipedia fully overrule biases, or where where biases are so strong that they overrule the objectives of Wikipedia. In reality most editors are somewhere between those two extremes. Conversely, give up the idea that mere expression of concern of biased-influenced editing is is a severe accusation and violation of wp:AGF. On average, a wiki-project is typically going to be slightly biased. Regarding notifying them on a contentious topic, this should be recognized (and adjusted for by casting a wider net) but IMO it doesn't rise to the level of precluding notifying them or considering it to be a wp:canvas violation. Sincerely, North8000 (talk) 16:03, 3 June 2024 (UTC)
• I strongly disagree with the notion that a WikiProject can be considered partisan or problematic without the involvement of Arbcom or some other discussion venue; otherwise, those are just an editor's personal opinion. I am also concerned with the conflation of specific canvassing cases which occurred in private or semi-private off-Wiki venues (EEML and Tropical Cyclones) with on-Wiki WikiProjects. Curbon7 (talk) 02:47, 4 June 2024 (UTC)
• I think I agree with Thryduulf's point (and Curbon7's too now I guess) here that a claim that an Wikiproject is so partisan that it is inappropriate to notify them of something within their scope of interest is a user conduct issue, an accusation of which should only be made with evidence at an appropriate forum (AN/I, but also AE or ARCA for CTs). Alpha3031 (t • c) 04:22, 4 June 2024 (UTC)

  It is certainly possible to CANVAS via a wikiproject notification … by wording the notification in a non-neutral way with the intent of generating desired support/opposition to an issue. However, that is a flaw with the wording of the notification, not the location of the notification. Blueboar (talk) 22:59, 5 June 2024 (UTC)

• I think neutral notification of relevant WikiProjects is almost never canvassing. Part of the disagreement centers on the word partisan, which has expansive enough of a definition that we can be talking about very different things. BM's analysis of various WikiProjects above has no way of distinguishing between problematically partisan ("we vote differently than the general community because we're non-neutral") and positively partisan ("we vote differently because we know more than the general community"). I think Nat Gertler's thoughts on this are well-stated. A case against a WikiProject needs much more evidence, being essentially a misconduct allegation against a large group of editors. Firefangledfeathers (talk / contribs) 01:32, 6 June 2024 (UTC)

@Firefangledfeathers: what about the other point raised which is about selective notification of relevant WikiProjects? If someone notifies one relevant wikiproject but not another could that be an issue? Horse Eye's Back (talk) 01:07, 7 June 2024 (UTC)

I think commonly understood best practice is to notify them all if you're going to notify one. I sometimes think it's overkill. For example, I remember at least considering notifying some projects about a dispute related to J. K. Rowling and being torn about whether or not to notify WP:WikiProject Gloucestershire. I certainly wouldn't hold it against someone if they did so, and I wouldn't call it canvassing if someone left it off. Firefangledfeathers (talk / contribs) 01:35, 7 June 2024 (UTC)

In cases like that it makes sense to consider whether the specific dispute is relevant to that WikiProject. For example, if it was a dispute about whether Yate (where she was born) should be described as being in "Gloucestershire" or "South Gloucestershire" then the Gloucestershire project is definitely relevant. If the dispute was about which articles to include in her bibliography then the relevance is harder to see.

In general I don't think it should ever be regarded as wrong to notify all the WikiProjects that have tagged the article, or all the ones that are not tagged as inactive. If you think there is a relevant project that hasn't been notified, then the best thing to do is notify them and AGF that not doing so was not an attempt at canvassing unless you have a good reason not to. Thryduulf (talk) 01:59, 7 June 2024 (UTC)

It isn’t great to selectively notify, but the answer is to then notify the other relevant wikiprojects. nableezy - 02:40, 7 June 2024 (UTC)

• An issue seems to be that the "is relevant to that WikiProject" test can be surprisingly subjective and unpredictable, as far as I can tell. People employ different (often unstated) heuristics to estimate relevance. Regarding "the best thing to do is notify them and AGF", this is my view too. I wonder about the scope of the AGF policy and its relationship to project notifications and the WP:INAPPNOTE guideline. AGF applies to individual editors. Wikiprojects are collections of editors. So, the AGF policy presumably extends to Wikiprojects as collections of editors. In that case, bias/canvassing concerns presumably always need to be evidence-based. Given the scope of AGF, assuming it extends to collections of editors with a shared property (like project membership), allowing people to use their own biases (maybe rebranded as 'common sense') to make non-evidence-based guesses about project bias impacting apparent consensus seems a bit inconsistent. Having said that, the AGF policy probably has its limitations in contentious areas where there is polarization and dishonesty (sockpuppetry), but it is policy, nevertheless. Sean.hoyland (talk) 03:44, 7 June 2024 (UTC)

  On this question of selective notification: for a certain RfC about René Lévesque (former premier of Québec) at article Talk, I notified wikiprojects Canada and Québec, but I was told that that was somehow canvassing. The editor making the accusation then proceded to notify wikiprojects for the rest of the Canadian provinces that had nothing to do with Lévesque's career.

  I didn't formally object at the time - based on the "more eyes" theorem - but the notifications of apparently unrelated wikiprojects did feel to me like canvassing. What is the evaluation editors here would make that kind of (presumably tit-for-tat) notification? Newimpartial (talk) 10:43, 7 June 2024 (UTC)

  There's a big difference between Wikiprojects, though. I can remember some of them listing AfDs for "their" articles on their Wikiproject page and descending en masse to vote Keep - topics that spring to mind were aircrashes, tornadoes (and US roads before they threw their toys out of the pram) - whereas participants from many other Projects treated the AfDs impartially and were quite willing to get rid of articles that didn't meet policy). Black Kite (talk) 11:01, 7 June 2024 (UTC)

• It is my opinion that while current policy does allow for the notification of WikiProjects, it is clear that there is a bias for folks involved in them to keep articles that are in their subject area, as no single WikiProject is representative of the overall community, which is why it is considered a specialized community in the first place. While it is an open message available for everyone to see in theory, in reality it will only be seen by a segmented and unrepresented faction of the overall community, and the evaluation of sources is not something that people can't do simply because they aren't in a WikiProject related to the article at question. Even when the wording is neutral, often the notification will come from someone who has already voted !keep, so how is that (or any other vote) a neutral notification? Let'srun (talk) 13:03, 11 June 2024 (UTC)

  Even when the wording is neutral, often the notification will come from someone who has already voted !keep could not be more wrong. First of all, you're assuming this only occurs for AfDs, when in fact AfDs are probably the one of the fewest things notified to WikiProjects (RMs and RfCs likely being the most). Additionally, your assumption that it is primarily people who have X opinion on the topic are the one's who notify is just not backed up by reality, to the point it seems you are arguing against notifications altogether. I think you are focusing too much on the why question (Why should WikiProjects be notified) rather than the what (What WikiProjects should be notified). Curbon7 (talk) 21:37, 11 June 2024 (UTC)

  That's fair, and my opinion may be a bit biased just because of what WikiProjects I have viewed in the past. I have seen notifications for RFCs and RMs as well, and it should be made clear that the wording is neutral while also explaining why the project deserves a notification. Let'srun (talk) 03:28, 19 June 2024 (UTC)

  Just as likely to come from someone !voting delete, if they are on the losing end! — Iadmc♫^talk  21:41, 11 June 2024 (UTC)

  If someone with a strong opinion is notifying in an attempt to sway the discussion (which does happen, but is far from the only or even most common reason) then it's equally likely to be someone arguing to keep or delete if it's going the other way, or more likely from someone arguing for deletion if it looks to be headed for no consensus. It's probably equally likely to come from either side if the trend is merge or redirect. Not that notification in such circumstances is guaranteed to have the desired outcome - I recall one discussion a few years ago where someone arguing for deletion notified a WikiProject with the intent of preventing a no consensus outcome. Several editors saw the notice and showed up to the discussion but were evenly split and it still closed as no consensus. Thryduulf (talk) 21:59, 11 June 2024 (UTC)

  Just because an editor has domain area knowledge doesn't mean they are willing to bend English Wikipedia's standards for having an article. Domain area experts typically know the best reliable sources for their area of expertise, the most reliable indicators that the standards for having an article can be met, and what achievements are actually significant versus those that just sound impressive to someone unfamiliar with the domain. If there are cases where editors fail to adhere to general consensus on the standards for having an article, then I feel the community should deal with these situations individually. If mechanisms like WikiProject article alerts aren't going to be used to notify editors interested in a topic area, there isn't a scalable way for those interested editors to be involved in related discussions. In my view, I think that will reduce the effectiveness of these discussions. isaacl (talk) 01:27, 12 June 2024 (UTC)

• WP:APPNOTE is clear that notifying one or more WikiProjects is appropriate notification. The argument that notifying specific WikiProjects may result in an influx of editors who are not representative of the Wikipedia community is not a convincing one because there may be editors who fall on either side of debates who have those WikiProjects on their watchlist. TarnishedPath^talk 10:16, 20 June 2024 (UTC)

"Failure to thrive"

I'm thinking it might be useful to have a reason for deletion that covers a swath of articles that never improve, but are technically just over the bar of notability. To come under this category, the article:

1. Must be a barely notable subject, or be reasonably well-covered in other articles. A one-off event, a small subset of a main topic, or fancruft, say.
2. Must have severe deficiencies in citation or bias
3. No substantial edits in six months.
4. Has had at least one nomination for deletion a minimum of six months ago.
5. Will get three months to improve before a final deletion decision.

What do you think? Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 14:38, 30 May 2024 (UTC)

Huh? So this is for "articles", that have already survived AfD - then what exactly do you want to happen? Do you want AFD's to be able to close with a result of Up or out? Or do you want to make a new policy rationale that can only be argued on second AFDs? Do you even want this to do through a second AFD, or is this some sort of speedy criteria request? — xaosflux ^Talk 14:56, 30 May 2024 (UTC)

Looks like he wants those rationales, as a group to be acceptable at AfD? Alanscottwalker (talk) 15:04, 30 May 2024 (UTC)

Only at a second AfD. AfD currently normally acts as a check for potential. This is for articles unlikely ever to improve, after substantial notice - ones that will never reach the theoretical potential, with terrible quality. The kind of articles where the keep rationales are solely down to sources existing, nothing about the article as it stands being sufficient to keep it. It's also meant to be a very slow series of checks, to give it every chance. Also, preliminary suggestion; workshop at will. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 18:03, 30 May 2024 (UTC)

if something is notable, why delete it? Lee Vilenski ^{(talk • contribs)} 15:04, 30 May 2024 (UTC)

It is not clear to me whether you are seeking to delete these pages so that they never have Wikipedia pages, or you are seeking to delete them with the hope that a healthier and more fertile page will grow in its place. If the latter, I should note that the argument WP:TNT usually is given accepted weight in deletion discussions, even if it's not exactly matched in policy and guidelines. -- Nat Gertler (talk) 20:54, 30 May 2024 (UTC)

So we want to delete barely notable articles now? Why? Who decides what is "barely" notable? Notable means notable, if we start deleting articles that are notable but that we don't like, there'll be no point in having WP:N. Cremastra (talk) 20:25, 1 June 2024 (UTC)

Comment - I am on purpose not going to answer this question, because "what I think" is that it demonstrates what is wrong with a lot of deletion processes (especially AfD) at present, all of which assume the key question to be, "should X topic have an article?" I think this is almost always the wrong question.

I think the right question, almost always, is "does this verifiable information belong in an encyclopaedia?" (content that fails WP:V never belongs). There can be various reasons, set out rather inconsistently in WP:NOT, WP:BLP, WP:DUE, WP:NPOV, WP:FRINGE and even WP:N - which isn't supposed to be a content guideline - why certain content doesn't belong in an encyclopaedia.

For content that belongs in an encylopaedia, the question then is, where should it be placed? WP:PRESERVE and WP:PAGEDECIDE are among the few places that address this question clearly, but unfortunately WP:N has been the tool perhaps most frequently used by editors to argue about decide whether to remove or retain content. I think this is an unfortunate situation - there are very few circumstances in which the encyclopaedia benefits from not having articles on "marginally notable" topics, except when the content of those articles is not encyclopaedic to begin with (WP:POVFORKS, for example).

If we had a way to talk about encyclpaedic inclusion directly, away from Notability, we might be able to defuse some misguided "zero-sum" conflicts and design an encyclopaedia more the way actual editors would design it, rather than allowing the shape of Wikipedia's content to emerge from a series of bar brawls between editors with particular presuppositions about what topic does or doesn't "merit an article". I know that wasn't the question lol, but that is my answer. Newimpartial (talk) 15:40, 30 May 2024 (UTC)

I'd say marginal articles are fine if they're of reasonable quality, but if articles are going to languish in a permanently bad state, that's a problem. There are cases where a very bad article is worse than no article. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 16:08, 30 May 2024 (UTC)

I absolutely know the type of article you are talking about, I recentlty nominated an article for deletion that has been a one-sentence stub for fourteen years. However, I don't think "this survived AFD but we're still going to delete it" has much of a chance of ever becoming policy. Just Step Sideways ^{from this world ..... today} 17:04, 30 May 2024 (UTC)

I just want to give articles every chance to thrive before we do delete them. There's other ways - WikiProject notifications, etc - but AfD usually forces a check of the article's potential: is there sources, etc - that I don't think any other current process does. If it has no potential, it gets deleted at the first AfD. If it's already of reasonable quality, this process shouldn't apply: it has thrived. This needs to be a slow process to have any effect. As I see it, though, this would be an argument to raise in a second AfD that would trigger the countdown to the final review. The review would be one admin comparing it to the state at the time of the failure to thrive AfD (which I think is sufficient given the number of steps before this) Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 17:50, 30 May 2024 (UTC)

A way I think this could work: we make a template for something along the lines of "this article doesn't have enough quality sources in it to establish notability (regardless of whether those sources exist out there somewhere)". Then if X amount of time passes and the situation hasn't changed, that's taken as strong evidence in an AfD that, regardless of whether the sources exist somewhere, they can't actually be used to write an article. Loki (talk) 19:38, 30 May 2024 (UTC)

But the proposal here isn't for articles that aren't notable, rather ones that are borderline. I think everything here is in violation of WP:NO DEADLINE. Lee Vilenski ^{(talk • contribs)} 20:08, 30 May 2024 (UTC)

And not voting for it is in violation of WP:Delete the junk. Essays aren't policy. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 22:25, 30 May 2024 (UTC)

• Could you give an example or two of the sort of article this proposal is envisaged to apply to? – Teratix ₵ 11:12, 31 May 2024 (UTC)

  Note that this is just some things I've found by looking through the articles without sources categories, and some fad categories. These haven't passed through AfD, some of them might be handleable with a merge, and some might be salvagable - but the point of this proposal is to try and save the articles first.

  • Naked butler: It's possible this could be saved, but it's a lot of text, very little of it cited, so the accuracy and verifiability is very questionable. It's probably a thing, but such a weak article on a marginal subject is more likely to put inaccuracies into Wikipedia than to be genuinely helpful.
  • Campaign desk: Again, subject probably exists, but there's some oddities that make me concerned. The phrase "at popular retailers" makes me wonder about copyright of the text a little bit: it's a weirdly advert-y phrase. Uncited.
  • List of Fantastic Beasts characters - fancrufty article. Maybe it'll be saved, maybe not, but there's nothing in here that isn't redundant to the films' articles.

  Should these be deleted right now? No, the whole point of this proposal is to encourage attempts to salvage articles in this kind of state. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 13:41, 31 May 2024 (UTC)

  Funny that the only citations in "Naked butler" are in the "Popular culture" section. Donald Albury 14:18, 31 May 2024 (UTC)

  There were more citations (four) in the article as originally posted (I have made no effort to see if their removal was appropriate.) However, there is more sourcing to be found, such as this Evening Standard article. I'm not sure how the procedure here would help this article (if it were even eligible, which it is not) any more than standard tagging. With articles this old, we cannot assume that the original editors are still involved enough to be aware if the article was threatened by deletion. -- Nat Gertler (talk) 16:36, 31 May 2024 (UTC)

  And, in fact, finally looking at the talk page of the article, there is (and has been since 2013) a long list of news sources which could be used. Any attempt to delete this article could be quickly laughed away by that list. If there are any good examples to which this proposed procedure should apply, this is not among them; someone who had concern with the quality of the article could improve it much more quickly than creating a deletion argument with the hope that someone else will do so. -- Nat Gertler (talk) 16:44, 31 May 2024 (UTC)

  Campaign desk appears to have text that is an exact copy of text at this site, but the text has been in WP since 2004, and the web site was first archived at the Internet Archive in 2006. Donald Albury 14:31, 31 May 2024 (UTC)

  For the record, I'd say that the key type of article this would be good for dealing with is minor fads, advertising, or one-off events long past in similar states to those articles. But I'm not sure it's worth trying to find the perfect exemplar. While I do think articles on such things can be encyclopedic, there is a certain point where you have to say that if an article with only minor notability, especially one where the interest peak is long past, is still terrible, that we need to consider if it's ever going to get better, whatever the theoretical potential. If this results in people actively working on these articles instead, that's all the better. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 16:15, 31 May 2024 (UTC)

Well, were I pressed I would say, yes, as a matter of practice having marginal subject articles is a detriment to the encyclopedia because they are often abandoned junk in practice, at best filled with templates for years upon years, at least telling the reader, "if you have not figured it out yourself, which you may well have, this has been bad since 2010, and Wikipedia does not care about bad articles and bad information" (that's a real detriment to Wikipedia). -- Alanscottwalker (talk) 16:51, 31 May 2024 (UTC)

Improving existing articles slightly is a much lower hurdle than creating a brand new article. If an article is full of irrelevant unsourced text but has a notable core then it should be reduced down to that state, not deleted. There's no deadline for when Wikipedia needs to be perfect, and an article existing in the first place is conducive to improvement. AlexandraAVX (talk) 18:19, 31 May 2024 (UTC)

Yes, Wikipedia does not care about bad articles and bad information is what you just articulated in practice. Alanscottwalker (talk) 18:23, 31 May 2024 (UTC)

If you find an utterly terrible article on a notable subject, be bold and stubify it. I don't see why we need a process specifically for deleting bad articles on notable subjects. If there's no consensus to TNT then there isn't. AlexandraAVX (talk) 18:27, 31 May 2024 (UTC)

Let me relate a Wiki tale, although not directly on point to these marginal articles, not too long ago an architect's article was eligible to be featured on the main page for winning an award, kind of like a Nobel Prize, and the article was in poor shape under wiki policies, so seven days it stayed at the news desk while some harried pedians made some effort to improve, and it was not improved sufficient to feature. (and it may still not be good enough). Now, if there were no article and it was written up with the sources that came with the prize and which surfaced in a few days, that would have been easier for the crew, instead trying to source prose and facts when one does not know where it came from. Nor would coverage of the subject have been improved by stubification, certainly not good enough to be in decent shape and probably not good at all (especially when a good number of the world was looking for the topic). So, hope for the more marginal is likely misplaced. Alanscottwalker (talk) 21:09, 31 May 2024 (UTC)

If the prose is unsourced it can be deleted. There's nothing preventing someone from being bold and with good reason tearing out unsourced and bad prose and possibly replacing it with entirely new text. If the article really is entirely beyond saving, WP:TNT is a recognised option at AfD. AlexandraAVX (talk) 13:03, 1 June 2024 (UTC)

Its not about "preventing someone", its about the doing the work by anyone, which we know through decades of practice is not something anyone apparently wants, coupled with the common sense of past is prologue. You say just delete a bunch in the article or just do other work, but cleaning up, if you care, is about significant work. In comparison, it's easier to create a decent article from the bottom up without having to do the cleanup first. Alanscottwalker (talk) 10:58, 4 June 2024 (UTC)

Once again, whether it is easier to create an article from the bottom up or easier to create an article based on someone else's work is a matter of opinion. Thryduulf (talk) 11:26, 4 June 2024 (UTC)

It remains, not having to do cleanup first is less work. Alanscottwalker (talk) 05:06, 7 June 2024 (UTC)

Apparently, it's a matter of taste; I find cleanup and reclamation to be much easier. Toughpigs (talk) 05:16, 7 June 2024 (UTC)

What do you find easier? To write a decent article you have to research and write, to cleanup you have to delete, try to understand what someone else was thinking, rework, test for cvio, etc. as well as research and write. The first is less work. -- Alanscottwalker (talk) 11:50, 7 June 2024 (UTC)

If the existing article lists some sources, then I don't need to spend as much time looking for sources.

If the existing article has some solid sections, I can ignore those and focus my effort elsewhere.

If the existing article has information that wouldn't have occurred to me, then I get a better result.

I usually find it very easy to "understand what someone else was thinking".

On the flip side, if the existing article is really lousy, then a quick little ⌘A to select all and hitting the backspace button solves that problem. Even in such cases, the article 'infrastructure' (e.g., infobox, images, and categories) is usually sound, and keeping the existing ones usually saves time and effort.

I don't pretend that what's easiest for me is what's easiest for everyone, but I personally don't mind working with existing articles. Perhaps you are the opposite. That's okay. My experience doesn't invalidate yours, and yours doesn't invalidate mine (or the experiences of the multiple other people who have disagreed with you). WhatamIdoing (talk) 21:35, 7 June 2024 (UTC)

You are mostly off-topic as the premise of the proposal is only dealing in really lousy articles, and indeed ones that no-one is even doing your process of deletion or the rest. You think deleting large swaths is easy but it seems from your telling that is not something you spend much time thinking about it. As for your presumption about infobox and images and categories, your basis is for that is just assumption not evaluation. Alanscottwalker (talk) 13:38, 8 June 2024 (UTC)

WhatamIdoing's point is simply that other people have a different opinion to you. Your assumptions about why that be are irrelevant. What constitutes a "really lousy article" is also a matter of opinion, and yours is no more or less valid than WhatamIdoing's or anyone else's. Do you understand that people can have a different opinion to you about subjective matters and contribute in good faith or are you being deliberately disruptive? Thryduulf (talk) 13:47, 8 June 2024 (UTC)

It is you who are being deliberately disruptive and you who are trying to prevent the presenting of opposing views. Somehow others can present opinions (who introduced "easiest" or "lousy") but just because you disagree with my view, you label it disputive. Alanscottwalker (talk) 13:52, 8 June 2024 (UTC)

I am not labelling your view disruptive because I disagree with it (see other people whose views I have disagreed with without labelling disruptive), I am labelling your view disruptive because you appear to be either unwilling or unable to distinguish between fact and opinion. Thryduulf (talk) 14:18, 8 June 2024 (UTC)

That makes little sense and I see now how why you disrupt things, I am using words as others use them, and your inability to not read my comments as statements of view is your fault, not mine. Alanscottwalker (talk) 14:23, 8 June 2024 (UTC)

WhatamIdoing, If you care to reply to my 13:38 comment perhaps best to do so down here. Alanscottwalker (talk) 14:05, 8 June 2024 (UTC)

that's more than enough, take it outside. Just Step Sideways from this world ..... today 19:32, 31 May 2024 (UTC)

No, because Wikipedia does not care. And you are wrong in substance too, it's easier to create a decent article than it is to reform one (and much more enjoyable) . Alanscottwalker (talk) 18:34, 31 May 2024 (UTC) Whether it is easier, and especially whether it is more enjoyable, is inherently subjective and so it is incorrect to say someone with a different opinion to you is "wrong in substance". Thryduulf (talk) 18:43, 31 May 2024 (UTC) No. And your useless tangent is not adding anything here. Thanks word police. Alanscottwalker (talk) 18:47, 31 May 2024 (UTC) This is not the first discussion in which you have replied using ad hominems and borderline personal attacks to someone who simply has a different opinion to you. I really would like to believe you are capable of listening and collaborating, but nearly every comment you leave makes that harder. Thryduulf (talk) 18:59, 31 May 2024 (UTC) You came in disruptive, to opine on the finer points of how you believe a phrase on "substance" has to be used. Which is far off-topic. So no, its not me who has shown poor collaboration here, it is you. Alanscottwalker (talk) 19:05, 31 May 2024 (UTC) You are objectively wrong on just about everything it is possible to be objectively wrong about in that sentence. Please engage with the topic rather than with ad hominems. Thryduulf (talk) 19:13, 31 May 2024 (UTC) Just look, see how you are derailing anything having to do with anything with the proposal. Alanscottwalker (talk) 19:17, 31 May 2024 (UTC) I refuse to waste more of my time on your continued ad hominems. Thryduulf (talk) 19:27, 31 May 2024 (UTC) Looking at your comments is not ''ad hominem.'' Alanscottwalker (talk) 19:28, 31 May 2024 (UTC)

Perhaps what we need is a second review process … one that is focused on Non-Improvability, rather than Notability. It would consider articles that are in such poor shape that they (arguably) can not be improved… regardless of whether the topic is notable. Blueboar (talk) 18:20, 31 May 2024 (UTC)

I can't see many cases where a topic is notable without being possible to improve. If the article is irrevocably badly written then it can just be stubified. AlexandraAVX (talk) 18:23, 31 May 2024 (UTC)

There's strong WP:OWN issues sometimes there, especially in walled gardens. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 20:23, 2 June 2024 (UTC)

While there may be articles covered by this that should be deleted, I don't think that editing inactivity is of any use in identifying them. And some of the other subjective criteria would be practically impossible to define or implement. Thanks for the idea and bringing it up here but IMO this is not workable and also not a very useful way to find articles that should be deleted. North8000 (talk) 18:58, 31 May 2024 (UTC)

I was initially torn between liking the idea of having a way to constructively reassess borderline articles that have not been improved in a long while, but also between being a firm believer in eventualism and the importance of recognising that Wikipedia is a work in progress. However, the more this discussion has gone on, the less I'm liking this. Merging, stubbifying, improving articles yourself (including using TNT), and similar activities that are not deletion are going to be preferable in nearly all cases. If you lack the subject or foreign-language knowledge to improve the article yourself use resources like WikiProjects to find people who do have that knowledge, sharing lists of the sources you've found but not understood to help them get started. If you don't have access to the sources (e.g. they're offline) then there are resources like the Wikipedia Library and at least some chapters offer grants to help you get them. Only when all of these options are unavailable or have failed, which is a small percentage of a small percentage, is deletion going to help and I'm not sure we need something other than AfD for that - especially as in a good proportion of these few cases notability is going to be questionable. Thryduulf (talk) 19:25, 31 May 2024 (UTC)

What if we have a process for quickly moving such articles to draftspace, and requiring AFC review/approval for them to be returned to mainspace? BD2412 T 20:00, 31 May 2024 (UTC)

I think that would basically be a backdoor deletion in many cases, a lot of the bad articles I come across are sometimes over a decade old and the original author is long gone. A PROD or AfD will let me and others interested in the subject area see them in article alerts, draftifying won't. AlexandraAVX (talk) 20:04, 31 May 2024 (UTC)

@AlexandraAVX: An AfD can lead to draftification, which can lead to deletion for abandonment (or, rarely, revitalization), but at least this resolution avoids keep rationales based on possible improvements that will never actually be made. BD2412 T 21:13, 1 June 2024 (UTC)

I'm not sure how to ask my question without it sounding weird, but here goes: Who cares if the improvements are never made?

At the moment, the subject qualifies for a separate, stand-along article if the real world has enough sources that someone could improve it past the doomed WP:PERMASTUB stage (plus it doesn't violate NOT, plus editors don't want to merge it away). The rules do not require the article to be "improved", and never have.

So imagine that we have an article like User:WhatamIdoing/Christmas candy. It's two sentences and 100% uncited. Imagine that we all agreed that Wikipedia would almost certainly die before that article ever got improved. Why should that be considered a deletion-worthy problem? Why can't it just be left like it is? Who's it hurting? WhatamIdoing (talk) 04:13, 2 June 2024 (UTC)

Anyone who reads the article and comes away believing something false or likely to be false?

Like, I don't see why this is hard to understand. Loki (talk) 04:25, 2 June 2024 (UTC)

Do you see anything false or likely to be false in that article? WhatamIdoing (talk) 04:30, 2 June 2024 (UTC)

If there's something false in the article you can delete that. If the subject is a hoax then that's already a speedy deletion criteria. If it isn't a hoax you can remove any information that can't be verified. If the subject is notable then there inherently must be coverage that makes something about it verifiable. AlexandraAVX (talk) 09:09, 2 June 2024 (UTC)

Agreed. This seems like an ornate process for which the problem it would address has not been actually identified; the OP came up with no examples that would qualify for this treatment. The standard processes allow for re-AfDing if the material is not notable under current guidelines, or stubbifying if it is. -- Nat Gertler (talk) 20:22, 31 May 2024 (UTC)

One structural note. Since the suitability of the article to exist in main space technically relates only to the subject of the article, technically, the subject of the article should be the only reason to remove it from mainspace. North8000 (talk) 20:32, 31 May 2024 (UTC)

That's not quite true, as there other things that are relevant in some circumstances - copyvios are the most obvious, but also articles not written in English or written by socks of banned editors. However, other than newly discovered copyvios I can't think of any that are likely to be relevant to articles being discussed here (and with old articles the chance of suspected copyvios turning out to be plagiarism of Wikipedia are of course greater). Thryduulf (talk) 20:47, 31 May 2024 (UTC)

@Thryduulf: Well copyvio is a problem with content, though if you have an article that is 100% copyvio there's really nothing to save. North8000 (talk) 13:38, 1 June 2024 (UTC)

I can understand this frustration. All the time I see articles that were poor quality get sent to AFD, the commenters there say that the existing article is crap but (minimal) sources exist, so the article should be improved rather than being deleted. It gets kept, then...nothing happens. 10-15 years later, the article is still very poor quality and essentially unchanged. Whatever original sources existed might not even be online anymore, but a second AFD probably won't get a different result. Sometimes I can stubbify/redirect, if there's gross BLP violations I can sometimes just delete it, but most just exist in this limbo indefinitely. If nobody cares to make a halfway decent article, then maybe we shouldn't have one. I would like it if there was a shift at AFD, especially for long-term poor quality articles, from "should this topic have an article" to "is this particular article worth showing to readers". In 2005, the best way to help Wikipedia was with a pen (writing new articles). In 2024, the best way is with pruning shears (removing bad articles, or trimming irrelevant bloat within articles). I'm not sure the best way to accomplish this, but some sort of draftification for these articles might be a good idea. 6 months is probably too soon, but setting it at 5 or 10 years would cut out a lot of crud. The Wordsmith^{Talk to me} 21:25, 31 May 2024 (UTC)

• The OP ignores fundamental principals like no time limits, deletion is not cleanup, preserve, before etc.. it would be political and contentious. And I'm not sure it would do much to improve Wikipedia, plus alienate and piss off editors. The whole idea of keeping a crappy article on a notable topic is that someone will find it and work on it, "hey look at this crappy article I can make it better". -- GreenC 22:54, 31 May 2024 (UTC)

  He's not ignoring those ideas, he's trying to gain support for changing them. Sure, it would be contentious but that's not a reason to not discuss it. And yes, ideally someone will find a crappy article and work on it. But for many thousands of articles, it's been years and that hasn't happened. It probably never will. So the few people who stumble upon them are left with an unvetted, unsourced, incomplete or even misleading article about a topic. Jimbo had the right idea in this post[3], which became the foundation of our BLP policy but can apply elsewhere too. It's better to have no information about a topic than bad information. The Wordsmith^{Talk to me} 00:26, 1 June 2024 (UTC)

  What if Nupedia, but without the experts? I think [4] from that same thread presents far more useful ground for reflection. Choess (talk) 01:59, 1 June 2024 (UTC)

• Adam, I started a discussion at Wikipedia:Village pump (idea lab)#Ready for the mainspace the other day, on what it means for an article to be "ready for the mainspace". This seems to be an idea that some editors have adopted. Back when we were new, the general idea seemed to be that you determined whether something's ready for the mainspace (and almost all of us created everything directly in the mainspace back then) with a two-part checklist:
  1. Is the subject itself notable (e.g., if you spent time looking for Wikipedia:Independent sources, then you could find enough to write several sentences, even though nobody's bothered to do that yet)?
  2. Is the current article exempt from Wikipedia:Criteria for speedy deletion (e.g., not a copyvio, not Wikipedia:Patent nonsense, not an obvious test edit)?
• This could, and did, and was meant to, result in articles that said little more than "A campaign desk is an antique desk of normal size which was used by officers and their staffs in rear areas during a military campaign". (BTW, ProQuest 374234967 might be a useful source for examples that article, as will this one, if you'd like to add them, and https://www.nytimes.com/1964/03/15/archives/now-on-the-home-front.html will be particularly useful if you'd like to generalize from the desk to any sort of purpose-built furniture for mobile military officers.) However, I think that a minority of editors want to expand this checklist to look a bit more like this:
  1. Is the subject itself notable?
  2. Does the current version qualify for speedy deletion?
  3. Would I be embarrassed if someone I respected said "Hey, I was looking at this short Wikipedia article the other day..."? (e.g., the article has fewer than x sentences, fewer than y cited sources, fewer than z links...)
• If requiring a certain volume sounds nice, what I think would be more practical is if we talked about what percentage of articles we were really willing to sacrifice to the spirit of "immediatism because I'm embarrassed that someone hasn't already WP:FINISHED this old article". If you're willing to delete, say, 1% or 10% or 50% of all articles to artificially raise the average quality of Wikipedia articles, then we can calculate what x, y, and z would be.
  NB that I don't think that deleting articles for problems that could be solved by ordinary editing would be a good idea, because I've found some of those old, neglected, even uncited substubs to be of immediate value to me recently, when often what I wanted was an easy way to figure out what the official website was, or a quick definition of an obscure term (19th-century furniture and clothing has ranked high in my searches recently, so Campaign desk is exactly the kind of article that I have been finding helpful). But if you're bothered enough to want to WP:DEMOLISH articles because they're not being developed to your standards, then let's talk about how much is the most you could imagine destroying, and see if we could figure out what we'd be losing as a result. WhatamIdoing (talk) 03:57, 1 June 2024 (UTC)

• Read:
  1. Wikipedia:FIXTHEPROBLEM
  2. Wikipedia:There is no deadline
  3. Wikipedia:Beef up that first revision
  4. Wikipedia:Don't demolish the house while it's still being built
  5. Wikipedia:Don't panic
  6. Wikipedia:Enjoy yourself
  7. Wikipedia:Potential, not just current state
  8. Wikipedia:Rome wasn't built in a day
  9. Wikipedia:Wikipedia is a work in progress
  10. Wikipedia:Wikipedia is a volunteer service
  11. Wikipedia:Delete_the_junk#Alternatives_to_deletion
  12. Wikipedia:Template_index/User_talk_namespace/Multi-level_templates#Blanking/Removal_of_content

Case closed. IMO the time people spend here would be put into better use to improve our articles. --Dustfreeworld (talk) 04:42, 1 June 2024 (UTC)

Of the three example articles given early in this discussion, viewing them outside of this discussion: #1 Would fail wp:notability #2 is good enough as is, and #3 is in Wikipedia's Twilight Zone: there is no system / mechanism that really vetts list articles. North8000 (talk) 13:50, 1 June 2024 (UTC)

For Naked butler, I can find a few sources:

• Paul Majendie. “Butlers Buff Up Party Scene Forget the Quintessential Image of the British Butler as the Epitome of Discreet Decorum -- the Latest Fad on the British Party Scene Is Half-Naked Waiters.” Townsville Bulletin.
• Sagar, Tracey; Jones, Debbie; Symons, Katrien; Tyrie, Jacky; Roberts, Ron (December 2016). "Student involvement in the UK sex industry: motivations and experiences". The British Journal of Sociology. 67 (4): 697–718. doi:10.1111/1468-4446.12216. ISSN 0007-1315.

These are both available through Wikipedia:The Wikipedia Library. Perhaps someone would like to put them in the article. WhatamIdoing (talk) 20:38, 1 June 2024 (UTC)

I based my comments #1 based on a quick guess. The question is coverage of sources on the specific topic. Which in turn needs the article to be about a specific topic. My first guess is that that isn't there. But the overall point is evaluating articles based on things other than lack of development activity, and that the latter is not much of an indicator. North8000 (talk) 16:49, 2 June 2024 (UTC)

Well, that's one of the problems with the proposal: it encourages people to seek deletion not on the basis of what sources might be available, such as this article in the Evening Standard (page 2 here) or this Herald-Tribune piece, but rather on their guesses of how the page will develop in the future. I see nothing in the OP's proposal that indicates that the goal is to try to save the article first, it makes no call for the implementer to try to save the article, just allows for the possibility that someone else may do so. -- Nat Gertler (talk) 17:10, 2 June 2024 (UTC)

Huh? When something goes to 2nd AfD it could be "saved" like any other time, indeed that's when people often work on such (yes, yes, 'not cleanup', but that does not mean cleanup by hook or by crook is not good) the 2nd delete participants basically have to agree 'yeah, no one cares' for it to go. Alanscottwalker (talk) 18:39, 2 June 2024 (UTC)

Yes, it could be saved then, but it would take an odd interpretation that the goal of an AfD filing is to save an article, when the very point of an AfD filing is to request its destruction. -- Nat Gertler (talk) 18:56, 2 June 2024 (UTC)

Indeed starting an AfD with the aim of doing something other than deleting the article could (arguably should) get the nomination speedily kept (WP:SK point 1). Thryduulf (talk) 19:08, 2 June 2024 (UTC)

I did not say goal, I said it is regularly the outcome (including everytime there is no consensus or keep), the conversation is still about the suitability of having this article, nonetheless. Alanscottwalker (talk) 21:03, 2 June 2024 (UTC)

You appeared to be saying "Huh?" to a statement about the goal; if you were not "Huh?"ing that statement, I don't know what you were saying. -- Nat Gertler (talk) 21:09, 2 June 2024 (UTC)

I did not think you were speaking about the goal of AfD, the proposal is for a new multi-factored rationale (like is this adequately covered elsewhere, etc.) that the AfD participants can either agree in or not. Alanscottwalker (talk) 21:35, 2 June 2024 (UTC)

The goal of creating an additional excuse to delete things is to have things deleted. -- Nat Gertler (talk) 00:00, 3 June 2024 (UTC)

Well, I would call it additional rational but yes, when the alternatives given are delete large swaths of the article or just let it continue to sit there in bad shape for more decades. Alanscottwalker (talk) 12:28, 4 June 2024 (UTC)

I strongly suspect that #2, Campaign desk, is a copyvio, and has been so since it was created 20+ years ago, but I cannot yet prove so beyond any doubt. If it is determined that the original text, which is 95% of the current article, was a copyvio, then the article will have to be deleted. Donald Albury 16:36, 2 June 2024 (UTC)

It was written by an admin, AlainV. While it's not a perfect indicator, generally speaking, if I were looking for a copyvio, I wouldn't start by suspecting something written by an admin who wrote ~150 articles. It's at least as likely that the article was original here, and got copied over there. We have a copy from 2004; the Internet Archive has a copy of the Wikipedia article from 2005; the Internet Archive has a copy on a different website from 2006. I would not assume from this information that our article is the copyvio. WhatamIdoing (talk) 17:58, 2 June 2024 (UTC)

The wording's weird, though. That one phrase at the end... Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 20:21, 2 June 2024 (UTC)

Campaign desks were something of a trend back around the time this was written, so it doesn't seem as odd to me. WhatamIdoing (talk) 20:47, 2 June 2024 (UTC)

One reason that I haven't acted on my suspicions is the possibility that the website copied from AlainV's articles (all 48 or them, with only three or four desks listed on the website that AlainV did not create an article for). I left a message on his talk page, but he hasn't edited in two years.

Looking more closely at Cylinder desk, I see that AlainV and others modified that article after he created it, and the website matches the state of the article in April 2006 rather than the original state when AlainV created it in November 2003. Given that, I withdraw any suggestion that AlainV copied from the Arts and Crafts Home website. Donald Albury 00:08, 3 June 2024 (UTC)

That was a good piece of detective work, Donald. WhatamIdoing (talk) 00:42, 3 June 2024 (UTC)

As for the viability of "campaign desk" as a topic, why, here's just one of several books that I find on the topic of campaign furniture, so it appears that content on the topic can be sourced. -- Nat Gertler (talk) 21:07, 2 June 2024 (UTC)

• Oppose There is no such thing as an article on a notable topic that will never improve. They always improve eventually if they are left for long enough. We have many articles that were massively expanded after more than a decade of inactivity. If a topic satisfies GNG, there will be people able and willing to improve it. The proposal is incompatible with the policy WP:ATD. James500 (talk) 04:19, 8 June 2024 (UTC)
• General Comment I think that the advice at WP:NOPAGE is far too often neglected, and in many cases we would be better off upmerging content. By the same token there are definitely some encyclopedic topics that would be undue detail for a parent article, but will never expand beyond a few paragraphs because there isn't anything else to say about them, and that really isn't a problem either, those type of articles exist in traditional encyclopedias; people who are interested in the niche information can still find it, and it doesn't get in the way of everyone else.
  At some deeper level of course this is a request to rethink WP:N, especially WP:ARTN, and maybe shift the current consensus a bit as to when no article is better than the existing content. Much more specific criteria than failure to thrive will be needed for that to happen, and in the end we have to confront the fact that most articles simply do not meet the theoretical baseline standard (the small percentage that do become WP:GAs after being checked), and if history is any guide, changes will considerably increase the disruption associated with deletion, at least for a time.
  That isn't to say the underlying concern is without merit, and we all want better written articles, I'm just skeptical this is the best approach to get there. 184.152.68.190 (talk) 04:01, 9 June 2024 (UTC)

Rethinking

I think we should refocus the discussion away from AFD… we DO have a problem with articles that are about notable topics, but are seriously problematic in other ways. I am thinking that we might need to create a NEW process to deal with such articles. Perhaps (for lack of a better name) we can call it “GAR” (for “Gut And Rebuild”)? Please discuss. Blueboar (talk) 14:41, 8 June 2024 (UTC)

I would be for a policy making it clearer that stubifying and similar are acceptable for badly sourced and very poorly written articles. But we already have several projects for rebuilding and restoring bad articles: WP:CLEANUP, WP:REFCHECK and WP:GOCE. I don't think creating a new process for it would help. We already have the BOLD, revert, discuss cycle for that. AlexandraAVX (talk) 14:50, 8 June 2024 (UTC)

The "problem" is no one is doing it, whether it is because it is relatively harder or just not interested, someone still has to do the research and write, I suppose this GAR could draw attention to what no one is doing and it could help but doubtful it will make the article itself decent, what it could do is produce a list of sources which would certainly be better. It is better to direct readers to RS than whatever so-called "lousy" article we have. Alanscottwalker (talk) 14:50, 8 June 2024 (UTC)

So, here’s the crux as I see it… when the issue is notability, we have a fairly clear threat (deletion) we can dangle in front of editors to force them to address the problem (or at least make the attempt). We also have a clear solution (supply sources).

But for other issues we don’t have a threat to dangle in front of editors to force (or at least strongly encourage) them to address the problem. We simply hope that, some day, someone might get around to it.

The question is… IS there some sort of threat (other than deletion) that would achieve the goal? The closest I can think of is: “Gut it back to a stub”. Blueboar (talk) 15:48, 8 June 2024 (UTC)

I'm not sure "threat" is the right word, but it seems to me that criteria for compulsory draftification - and a dedicated noticeboard for that - could serve the intended purpose. Heck, it could even be accompanied by a proposed or a speedy draftification process as well. The trick is to come up with a word that starts with a letter other than D (or B). Articles for Transformation (AfT)? Newimpartial (talk) 16:17, 8 June 2024 (UTC)

The problem with non-notable articles is that they are, well, not notable, and shouldn't be included in the encyclopaedia.

What is the problem with notable articles that are short that we are trying to solve? We can already remove unreferenced information (after looking for sources and either adding the sources you find or remove it as unverifiable if you can't find any). Why do we want to force people to expand this notable article under threat of deletion after a week (AfD) or six months (draftifying)? What does the encyclopaedia gain from this? Thryduulf (talk) 16:31, 8 June 2024 (UTC)

Again, I’m trying to take deletion off the table here, and yet still convey a similar sense of urgency to editors (fix this “or else”). The only “or else” I can think of is: “We will pare this article down to a stub”. Blueboar (talk) 17:03, 8 June 2024 (UTC)

I'm trying to understand why the urgency? Why do we suddenly need a deadline? Thryduulf (talk) 17:10, 8 June 2024 (UTC)

Which editors? If we're dealing with old rot articles like discussed above, they are likely not editing Wikipedia any more. If we're dealing with newer problem articles, we're asking the editors to suddenly become competent? If you get into a war over paring something down, yes there are live editors and you can ask for a third opinion or somesuch., but in general, problem articles are better addressed by improving or paring them than in creating another system that relies on others. -- Nat Gertler (talk) 17:24, 8 June 2024 (UTC)

I think that threatening editors is probably the wrong way to build a healthy community or encyclopedia. Toughpigs (talk) 17:25, 8 June 2024 (UTC)

@NatGertler, what if I don't want to do the work? What if my goal is to make other people do the work? I'm a WP:VOLUNTEER. I don't have to do anything I don't want to. But maybe I'd like to force "you" to do the work that I don't want to do. Threatening to take away basically accurate, appropriate information works on a timescale that humans can recognize. Either nobody cares, and the ugly article goes away, or a volunteer drops everything to save the article. I get to congratulate myself on prompting improvements without lifting a finger to do the work myself.

Waiting for someone to notice the problem and feel like fixing it doesn't feel like it works. Sure, some of them might get improved, but I can't see the connection. AFD forces people to do something about the specific article that I don't like. m:Eventualism just says – well, maybe some articles will get improved and maybe they won't, but I'll never know which ones, and it probably won't be the ones that I care about. I feel helpless and like there's nothing I can do, especially if I don't want to (or am not competent to) improve the articles myself. WhatamIdoing (talk) 17:52, 8 June 2024 (UTC)

@Blueboar, "gut it back to a stub" won't work, because for the most part, the articles that are disliked are already stubs.

Also, nobody's stopping anyone from doing that now. Wikipedia:Stub#Stubbing existing articles (guideline) officially endorses it. Wikipedia:Editing policy#Problems that may justify removal (policy) provides a list of reasons for removing bad content without deleting the article.

I think the desire is to force other people to do this work. "My" job is just to complain that your work is sub-par (sending it to AFD requires three clicks and typing a sentence); "your" job is to put in whatever work is necessary to satisfy me (could be a couple of hours of work, especially if I dislike the subject and so demand an even higher level of activity).

Consider Campaign desk, given as an example above. It's a long stub (10 sentences, 232 words according to ProseSize). Two editors easily found sources for it. It's at AFD now. Why? I don't know, but I will tell you that it's quicker and easier to send something to AFD than to copy and paste sources out of this discussion. I also notice on the same day's AFDs that someone has re-nominated an article because the sources that were listed in the first AFD haven't been copied and pasted into the article yet. Why not copy and paste the sources over yourself? I don't know. Maybe adding sources to articles is work that should be done by lesser beings, not by people who are trying to "improve Wikipedia's quality" by removing anything that hasn't been improve to my satisfaction by the WP:DEADLINE – the deadline apparently being "whenever I notice the article's existence". WhatamIdoing (talk) 17:25, 8 June 2024 (UTC)

Part of an editor’s job is to highlight problems that the author needs to fix. I do get that we ideally wear both hats at the same time, but… sometimes we can only wear one. It is quite possible for editors to identify problems with an article that they can not fix themselves because they don’t know the subject matter well enough to do so. We need something that tells those who DO know the subject matter: “hey, this urgently needs your attention”.

As for why there is urgency… we simply have too many articles flagged as having with serious problems that have never been addressed. We need something that will push those who can be authors into actually authoring. Blueboar (talk) 17:48, 8 June 2024 (UTC)

That model of "editors" and "authors" is based on a hierarchical professional structure that does not exist on Wikipedia. Everyone is an "editor" on Wikipedia; that word doesn't hypothetically grant you power over me. Toughpigs (talk) 17:51, 8 June 2024 (UTC)

@Blueboar, a while ago, I dropped everything to save articles such as White cake. (Please do not blame the innocent AFD nom; he, like 99.9% of people, didn't know the modern white cake is a technological wonder, and finding high-quality and scholarly sources about everyday subjects requires more than an ordinary search.) I had fun doing it, and those articles are much better now. (I'll deal with the complication that is fudge cake later).

But: Do you know what I could have been working on instead of those articles? Cancer survivor. Impact of the COVID-19 pandemic on education in the United States. Epilepsy and pregnancy. Suicide. Multiple chemical sensitivity. The targeted articles are much better now. But is Wikipedia as a whole better off, when you consider the opportunity cost? I doubt it.

I think @Thryduulf is on the right track when he asks why we have such urgency. There was no urgency whatsoever about White cake. There were no errors in it. It had sources. It was, admittedly, much less awesome than it is now, but there is nothing seriously wrong. Ditto for Campaign desk, and almost all of the other "ugly" articles. So: Why should fixing that have been urgent? Did we really need something to push me into improving the article? WhatamIdoing (talk) 17:57, 8 June 2024 (UTC)

Thanks, but you did not need the article to do the research and write on white cake, and why it matters, is we are not showing our research, after sometimes decades, and thus adding value, rather we are suggesting that someone shared their thoughts on white cake on Wikipedia, when you can look at the rest of the internet and google for people's thoughts on white cake. The reader would have been better off, in the reliable information department, by finding reliable information on their own, then reading the unsourced, unexamined decidedly unreliable by Wikipedia's own disclaimer article. Anything that said in effect go, read this stuff, it is a good source, would have been better. -- Alanscottwalker (talk) 19:17, 8 June 2024 (UTC)

@Alanscottwalker, why do you say that an article that cited seven (7) sources, including one from Oxford University Press, and that contained no errors is unsourced, unexamined decidedly unreliable? WhatamIdoing (talk) 19:25, 8 June 2024 (UTC)

Oh, sorry, I thought your story was about it being AfD'd for lack of sourcing, was it that the sources cited were unreliable or irrelevant meaning with no evidence in them of notability? (so yeah, the rest, of my comment would apply to the unsoured parts). Alanscottwalker (talk) 19:42, 8 June 2024 (UTC)

Here's the article on the day it was nominated for deletion. It was one paragraph/six sentences long. That one paragraph had seven inline citations. Here's the AFD page. WhatamIdoing (talk) 22:29, 8 June 2024 (UTC)

Yeah, such AfD nominations are always hard to understand, as the inner logic of the nom is 'this is part of a notable topic' (here, cake). That's similar to the campaign desk example, the salient issue is whether to redirect to campaign furniture. Alanscottwalker (talk) 10:28, 9 June 2024 (UTC)

(edit conflict × 2) That doesn't explain why there is urgency. It identifies that you (and some other editors) dislike there being lots of articles that haven't been improved to your satisfaction yet. It does not explain why that many articles needing improvement is a problem, why nominated articles need fixing more urgently than the other articles, why you can't or won't fix it yourself, nor why you get to decide what articles other people need to prioritise. Thryduulf (talk) 17:55, 8 June 2024 (UTC)

(Friendly reminder: If you don't like edit conflicts, try that Reply button. Special:Preferences#mw-prefsection-editing-discussion and "Enable quick replying" if you don't see one at the end of every sig.) WhatamIdoing (talk) 17:59, 8 June 2024 (UTC)

Honestly, just the fact that you're considering "threatening" people in order to "force" them to do what you want suggests that this may be more about you than it is about the articles. The AfD process isn't about "threats" and "force", it's about identifying and deleting articles on non-notable subjects. Toughpigs (talk) 18:14, 8 June 2024 (UTC)

I’m just being realistic. “Force” may not be the intent of the AFD process, but it is certainly a product of that process… because we “threaten” to delete articles on non-notable topics, lazy article authors are “forced” to provide sources to properly establish that the topic is indeed notable.

In any case, what I am fumbling around trying to envision is a process that would be “about” identifying and fixing seriously flawed articles on notable topics - a process perhaps similar to AFD, but not AFD. Blueboar (talk) 10:59, 9 June 2024 (UTC)

The only things such a process could bring that existing policies, processes, task forces, collaborations, etc don't are a deadline and consequences for failure and nobody has yet identified why we need either of those. Thryduulf (talk) 11:09, 9 June 2024 (UTC)

• OK… let’s break it down into more bite sized chunks… first: let’s consider articles with serious WP:NOT issues (That might be a clearer example of where the topic might be notable, but the article, as it currently stands, is problematic). Do we have any sort of process that would help us better identify and therefore fix such articles? Blueboar (talk) 11:51, 9 June 2024 (UTC)

  Yes - the various cleanup templates and categories. Thryduulf (talk) 12:03, 9 June 2024 (UTC)

  What is the process behind those templates and categories? Blueboar (talk) 12:55, 9 June 2024 (UTC)

  1. an editor identifies the that an article is in need of cleanup and applies the template.

  2. optionally, it gets added to a list (e.g. a backlog drive)

  3. an editor who can improve the article finds it through one of several methods (see below) and does so

  Methods of finding an article include:

  • seeing the banner template on an article they are reading
  • seeing the article in the category (directly or via some category intersection tool)
  • seeing the article in a list
  • seeing the edit applying the template on their watchlist

  Thryduulf (talk) 13:02, 9 June 2024 (UTC)

  In other words… eventually, someday, maybe, someone might get around to fixing the article. But until that eventual day comes (perhaps years after it is identified) we are apparently OK with Wikipedia continuing to contain content that a (somewhat core) policy explicitly says Wikipedia should NOT contain?

  I’m sorry, but if that is our “process”, I don’t think it is effective (or at least not effective enough). I think we need a better process. A process that will incentivize our authors to fix WP:NOT issues sooner rather than later. Blueboar (talk) 14:00, 9 June 2024 (UTC)

  As I stated the only things our processes lack is a deadline and consequences for failing to meet that deadline and you still haven't identified how having either of them will benefit the encyclopaedia. Policies and guidelines already allow you to remove policy violations when you see them. Thryduulf (talk) 14:13, 9 June 2024 (UTC)

  Looks to me, Blueboar has done so, 1) effectively disincentivizing long term-policy violations; 2) effectively. reducing long-term policy violations. 3) Wikipedia taking effective responsibility for long-term policy violations concerning the central reason Wikipedia exists, its content, because we can't/don't insist on individual accountability (no one can make an editor source that article they wrote 10 years ago) we need to make process for entire-project accountability, when individualist work has over the long-term failed, concerning its central mission. Alanscottwalker (talk) 14:51, 9 June 2024 (UTC)

  I thought the whole point of this proposal is to deal with articles that aren't policy violations? Articles that are policy violations should have the policy violating parts fixed or removed, or (if that would leave nothing viable), nominated for deletion as soon as someone sees them. Thryduulf (talk) 15:54, 9 June 2024 (UTC)

  What you're suggesting is a "double AfD" -- if an article has been at AfD and it's been demonstrated that the subject is notable, but you personally still don't like the current state of the article, then you want an extra do-over that gets you the result that you want. Toughpigs (talk) 15:55, 9 June 2024 (UTC)

  And that someone else has to do the work, because if the only point was to fix the article, you could do that yourself. There is nobody in this discussion who is incapable of remedying serious policy violations in any article, including subjects we're unfamiliar with. WhatamIdoing (talk) 16:00, 9 June 2024 (UTC)

  With English Wikipedia's current consensus being that stub creation is encouraged, and with Wikipedia editors being volunteers, I think the only scalable way to continually improve articles is to build up groups of editors interested in various topic areas—which in the context of English Wikipedia, are WikiProjects—who can work through the queues of stubs. I realize that with most WikiProject talk pages being dormant, this isn't easy. Now that new editors each have their own personal newcomer homepage with an assigned mentor (though at present on English Wikipedia, due to a shortage of volunteers, only 50% of newcomers are shown a mentor on their homepage), perhaps mentors can help point new users to active WikiProjects. (Building a new consensus to manage the quality of new articles is an alternative, but personally I don't foresee a change being feasible in the intermediate term, given the most recent discussions amongst the editors who like to weigh in on this matter.) isaacl (talk) 16:09, 9 June 2024 (UTC)

  Should expanding stubs be prioritized over other tasks? WhatamIdoing (talk) 16:18, 9 June 2024 (UTC)

  You know the answer to that already: it's up to each person to decide what they want to work on. A group of interested persons can discuss situations, of course, and that may influence individual decisions. isaacl (talk) 16:23, 9 June 2024 (UTC)

  Our choices about which backlogs to "advertise" affect the choices people make. If we say "Stubs are bad, so please prioritize expand stubs", then we'll get more stub expansion. If we were instead to say "Improving popular articles is more important than ignored ones, even though they're less likely to be stubs", then we would expect to get more focus on popular articles. Each person will make their own decisions about what to work on, but people will also take official recommendations and nudges into account when making their individual choices.

  Some years back, Wikipedia:WikiProject Medicine set an official goal of getting all Top-importance articles past the stub stage. (These tend to be rather generic subjects, like Burn and Infection.) I think that was valuable, but I'm not sure that there is similar value in encouraging the expansion of the least-read 50% of Wikipedia's articles. WhatamIdoing (talk) 16:45, 9 June 2024 (UTC)

  Sure, that's up to the interested editors to decide upon. For better or worse, I can't keep other editors from discussing queues of interest to them. I can raise my concerns about their relative priority, and thus try to influence whatever decisions are made (whether that's tasks undertaken or text on a WikiProject page). isaacl (talk) 16:59, 9 June 2024 (UTC)

  @Blueboar, could you give me an example (preferably hypothetical) of an article about a notable subject that has serious NOT violations? None of the examples above (e.g, Campaign desk) seem to be NOT violations.

  I feel like the common objections behind these discussions (which have been going on with some intensity for a couple of years now) don't involve serious policy violations at all. Instead, the objections appear to be:

  • WP:ITSUNREFERENCED, and I want someone else to add sources right now. We couldn't get a rule adopted to require sources in non-BLP articles earlier this year, but I want this non-BLP article treated as if we did adopt that rule.
  • It's an WP:UGLY little article. Personally, I prefer that articles be Start-class, or at least long stubs.
  • There has been WP:NOIMPROVEMENT for a long time and other editors are making WP:NOEFFORT to expand it.
  • This subject feels unimportant to me, so WP:WEDONTNEEDIT (e.g., species articles) even if it is accurate, verifiable, and cited.

  All of those shortcuts point to Wikipedia:Arguments to avoid in deletion discussions. WhatamIdoing (talk) 16:15, 9 June 2024 (UTC)

  • Sure… Suppose an article about a relatively obscure regional restaurant chain that does nothing but list every franchise outlet and its address, thus violating WP:NOTDIRECTORY. The chain might well be notable and thus worth an article… but the article we currently have is problematic. It probably needs a complete rewrite, not deletion… So… let’s say someone stumbles upon this article. They can identify the problem, but they don’t know the topic well enough to write about it (and perhaps they don’t really care enough to do so)… so they simply tag it and move on… And then… nothing happens… nothing changes… the article just sits there, tagged as violating policy, potentially for years. I don’t think that is in the best interest of WP. Surely there is some way to better incentivize fixing the article. Blueboar (talk) 18:43, 9 June 2024 (UTC)

    The person who needs incentivizing is you. You are the one who's bothered by the article's existence. You can be the one who fixes it. Take out the addresses, look for reliable sources (probably in newspapers, for a restaurant chain). If you don't find any, then put it up for deletion. If you do, add them to the article. The problem is solved. You solved it! Toughpigs (talk) 18:46, 9 June 2024 (UTC)

    Hmm… Nope… I’m not in a position to fix the problem myself. I don’t live in the area served by my hypothetical restaurant chain, I have never eaten there, I know nothing about it, I don’t even know what sources would help me to write a proper article. All I know is that the article (as it currently stands) is a directory of franchises (a WP:NOT violation). I DO care enough about WP to alert others to the problem, but I am not qualified to fix it myself. The best I can do is tag and move on.

    So, I ask again… THEN what? Do we (as a community) continue to just ignore the problems with the article I have identified?… because that is what is currently happening! Surely we can do better. Blueboar (talk) 19:44, 9 June 2024 (UTC)

    Then you nominate it for deletion. We already have a process for this. If the article is kept, then at least a couple of sources have come up, and glaring problems like the addresses have been fixed. Toughpigs (talk) 20:43, 9 June 2024 (UTC)

    Nah… If I nominate for deletion, I get told that the topic is notable (apparently there are reliable sources, even though I personally don’t know which are reliable). I get told that AFD isn’t for article clean up (so the WP:NOT violation persists), and I am scolded for wasting people’s time. Blueboar (talk) 21:32, 9 June 2024 (UTC)

    So... you don't want to use AfD because you'll be told that you're wrong. Instead, you want a separate AfD process that will tell you that you're right? Toughpigs (talk) 21:36, 9 June 2024 (UTC)

    Not at all… I want a new process that will better draw attention to problems and do more to incentivize editors who CAN fix the problems to actually DO so. That new process might (or might not) be modeled on AFD… I’m still very open to suggestions and inspiration on that. I simply know that our current “tag it and hope that someone eventually fixes it” system isn’t working. Blueboar (talk) 21:59, 9 June 2024 (UTC)

    Is fixing that the right goal for Wikipedia?

    I think this point needs to get some direct attention. I agree that the hypothetical article described above is a WP:NOT violation as written.

    But: Is this really a "Oh my goodness, that actually violates a policy! Please, somebody do something, quick!" situation? Or could this be more of a "That's unfortunate, but not actually harmful, and frankly an article that only lists the locations is not as important as other problems I could be fixing" problem?

    Most of what we do is being done by about 10K experienced editors each month. The available volunteer hours do not expand to accommodate someone's desire to have this fixed on the m:immediatism time line. Incentivizing the editors who can clean up that article "to actually DO so" means incentivizing those editors to leave other problems unaddressed. So – is this really worth the cost? Are you glad that I expanded Cottage Inn Pizza when it was prodded a few months ago? Can that question be fully answered, if you don't consider what else I didn't do, because I spent an hour or so on that "relatively obscure regional restaurant chain"? WhatamIdoing (talk) 22:34, 9 June 2024 (UTC)

    If there isn’t any urgency, perhaps we should downgrade WP:NOT to an essay?… or rename it to: “What Wikipedia arguably shouldn’t be.” Ok, snark there… but yeah, I do think dealing with violations of major policies should out weigh a lot of the other, pettier things we obsess about as editors. Blueboar (talk) 00:20, 10 June 2024 (UTC)

    Blueboar, you asked, "Do we (as a community) continue to just ignore the problems with the article I have identified?" And for me, the answer is that I would rather have lots of imperfect articles than give you and X other people the power to mass-delete articles that would pass AfD but you still think are kind of "meh".

    (Note that you have already said that the articles would pass AfD and that you would be accused of wasting editors' time if you nominated them.)

    If your proposal is (paraphrased), "Let's have a system that 'forces' people to improve random articles on notable subjects at my personal instruction or they get deleted whenever I want," then I vote for the system that we currently have. Yes, that hypothetical chain restaurant article is absolutely hypothetically fine with me. Toughpigs (talk) 01:25, 10 June 2024 (UTC)

    Well, I don't think I'd describe the hypothetical article as "fine", but I also don't think that fixing it is urgent. If it gets done sometime before the heat death of the universe, then that would be great. But if we have more important content to work on, then I'm okay with it still being in its harmless but WP:UGLY and nominally policy-violating state when I die. WhatamIdoing (talk) 06:28, 10 June 2024 (UTC)

    Toughpigs… I’m not sure why you keep bringing up deletion… I opened this section by removing deletion as an option. But just to be clear - I am envisioning a new process to fix problematic articles… and NOT delete them. Blueboar (talk) 10:29, 10 June 2024 (UTC)

    So this new process highlights that it is vital that someone drops what they are doing and fixes this article to your satisfaction right now. What happens if nobody does? It's already a stub, so gutting the article isn't an option, and deletion is apparently off the table, so we can't do that. What else is there? Do we pick an editor and stop them doing anything else until they've fixed this article? How do we choose which editor? What happens if they walk away from the project instead? Or do we just leave the article with a different banner on it to let people know that not only is this article is in a bad state but we disapprove of it being in bad state and we were unable to force anybody to fix it in time? Thryduulf (talk) 10:56, 10 June 2024 (UTC)

    Thryduulf, part of the problem in my hypothetical is that the article (as it currently stands) ISN’T “already a stub”… it’s a directory of franchises and addresses. I could definitely see “stubify” being a step in the process (the “Gut” part of my suggested “Gut and Rebuild” name for the process) but what we really need is the next step… something that will incentivize editors to rebuild. That’s what I am searching for… and I don’t have the answer yet. I am hoping that I will become inspired as we continue to discuss. Blueboar (talk) 11:39, 10 June 2024 (UTC)

    Other editors have identified articles that they see as being part of this process which are stubs. Thryduulf (talk) 11:42, 10 June 2024 (UTC)

    Fixing the Policy Violation™ 😱 requires ten seconds. You open the editor, blank the list, and save it. Fixing that would be faster than manually tagging it, and approximately the same amount of time as using Twinkle to tag it.

    Now we have a substub with less information, which presents two problems:

    • Nobody who hates having an article with two sentences and a list of locations is going to be satisfied with an article that contains only the two sentences. It's still WP:UGLY and it's still irritating to all the people who want only high-quality articles right now.
    • "Less information" can itself be construed as a different Policy Violation™ 😱, because the Wikipedia:Editing policy says that Wikipedia should generally have more information instead of less.

    So now what? Keep complaining? WhatamIdoing (talk) 18:03, 10 June 2024 (UTC)

    @Blueboar, what if it's not so petty? The next major edit I made after that pizza chain was to expand Mastitis. I don't think we have an official policy that says "Improve health-related articles by providing accurate, well-sourced facts about common medical conditions, particularly if misinformation is spreading about that subject on social media", but I do consider that more important and more urgent than nominal compliance with a policy about whether Wikipedia should or shouldn't contain a list of locations for a restaurant chain. WhatamIdoing (talk) 06:26, 10 June 2024 (UTC)

    Sure, there are things that are more important… but there are a lot of things we (as a community) obsess about that are less important. Perhaps we should adjust our priorities? Blueboar (talk) 11:44, 10 June 2024 (UTC)

    Where does removing a list of locations from a pizza chain article fall in your priority list? What's less (and more) important? WhatamIdoing (talk) 17:59, 10 June 2024 (UTC)

  I think what you're aiming for is literally impossible. Not difficult, but actually impossible, without fundamentally changing what Wikipedia is. Wikipedia is not a publication (like a traditional encyclopedia), it is a content platform. There is no way to get the users of a content platform to all work towards the same goal (any goal). The only rule that a content platform can impose -- what you call a "threat" but is more accurately described as an enforcement mechanism -- the only enforcement mechanism available to a content platform is to not allow particular content to be published (what we call "deletion"). If you want to improve the content on a content platform, literally the only possible way to enforce any standards, is to delete (or not publish) content that fails to meet those standards. So: draw a line, delete anything that falls below that line, that's all we can really do. If the content meets the minimum standards, there is no real way to require or even encourage it to be improved beyond those minimum standards. Real money won't work, and nothing else matters to people in the end. You can hope people make better content, you can help them, you can encourage them, but you'll never be able to require it--all a content platform can do is remove substandard content. As analogies, consider how could YouTube possibly get people to make better videos, especially without paying them? How could a community garden get its members to plant "better" flowers? They can rip out substandard flowers, but beyond that...? I think there's nothing. Levivich (talk) 21:40, 10 June 2024 (UTC)

Notable topics with advert/COI "failure to thrive" issues

One thing that I have noticed that I think should be discussed here is the situation with articles tagged as advertisements, COI, or the like. There are some clearly notable topics that have been tagged as such (and indeed, may well have been written as such), for which — in my humble experience — improvement of the article is difficult precisely because editors may be dissuaded from working on the article at all out of concern that adding anything positive about the subject risks accusations of being involved in the advertising/COI issue, even where there is reliably sourced information that could be added. BD2412 T 03:22, 18 June 2024 (UTC)

Why are there so many featured articles about Great Britain?

Not an issue for Village pump (all). Referred elsewhere.

Not a policy discussion. Not a useful discussion. Take it up at the talk pages of the various sections of the main page if you must Just Step Sideways from this world ..... today 00:11, 3 June 2024 (UTC)
Like literally, everytime I come on the Front Page of wikipedia theres always a featured article of euther a British or english person. Is wikipedia owned by limeys or something? ENOUGH…HAVE SOME DIVERSITY FOR ONCE!! Fact.up.world (talk) 21:53, 2 June 2024 (UTC) On the contrary, almost all main page FAs are about America! Johnbod (talk) 22:05, 2 June 2024 (UTC)

Bot-like usernames

The username policy disallows users to have a username that has "bot", "script" or other related words in them because they could potentially mislead other editors. In my on-and-off time on wikipedia, I never understood why these sorts of usernames should be prohibited.

My main issue is that I feel that it's too BITEY.

Imagine being a new editor, clicking on the edit button just to see a big ugly edit notice saying that you're indefinitely blocked from editing just because you put "bot" on your username. Wouldn't it demotivate, discourage, and dissuade you from ever editing Wikipedia, or going through the process of appealing a block?

I understand that admins should attempt to communicate to the user before taking any action, but I rarely see that happen.

The thing is, having a bot-like username is not disruptive to the encyclopedia. It's not trolling any users, or going to tackle the issue with bot-like editing.

So I ask you, what is the purpose of prohibiting bot-like usernames? OzzyOlly (talk) 01:57, 6 June 2024 (UTC)

If I see a user account called CitationBot, I assume it's a bot that in some way edits citations. Prohibiting bot-like usernames is intended to prevent that assumption from being misleading. If admins are not explaining the block reasoning, that is a distinct issue from the policy itself. CMD (talk) 02:30, 6 June 2024 (UTC)

I could how some users might ignore edits because of their username, but first, the vast majority of times it's someone who stuck robot in their because they like robots or are otherwise entirely in good faith, and also users can check the account and its contributions. OzzyOlly (talk) 02:40, 6 June 2024 (UTC)

Many usernames could be made in good faith that fall afoul of the username policy, the policy was not created to deal with bad faith usernames but to provide guidance for selecting usernames that do not impede communication and collaboration (or create potential legal issues). CMD (talk) 02:48, 6 June 2024 (UTC)

My issue is that bot-like usernames don't impede communication or are disruptive. I think we're risking shutting out perfectly good editors over minor "what-ifs" OzzyOlly (talk) 03:11, 6 June 2024 (UTC)

Bot-like usernames do both, because we editors do not communicate with bots, and expect edits by bots to be very constrained along particular lines. The username policy does not shut out any editors. CMD (talk) 03:28, 6 June 2024 (UTC)

I know it's not really a total blanket ban on editors, but the issue is that I don't believe there's a net gain in doing this. I mean, recent changes automatically doesn't show you bot edits, and it's pretty easy to distinguish a human from a bot editor (especially the ones who added bot not as an attempt to communicate anything) even without having to check if it has the bot flag.

I've checked around to see how many people are blocked because of this, I've only found two instances of bot-like behavior, both of which are simply people not realizing they need to seek approval from BAG if they want to bring a bot from another project. Some are blocked for vandalism, sockpuppetry, and other stuff but the vast majority are of just regular newcomers, acting in good faith. OzzyOlly (talk) 15:09, 8 June 2024 (UTC)

If an editor is so fragile that a username policy is something that causes them to leave this site forever, then don't let them know about all other policies and guidelines we have. Gonnym (talk) 18:01, 8 June 2024 (UTC)

If we're not (at least) issuing warnings about potentially unwanted but not automatically rejected usernames at the time of account creation, maybe we should be. WhatamIdoing (talk) 04:07, 6 June 2024 (UTC)

It could be editors create a login on another language Wikipedia that does not have this rule. They can edit there where "bot" means something different, but editting here is a problem if it sounds like you are a robot. Some other names are a problem, eg "administrator" or "official" which could mislead. Graeme Bartlett (talk) 07:29, 6 June 2024 (UTC)

What if the person happens to be called LongBOTtom or likes the Bibles and uses TheSCRIPTures etc? There must be reasonable grounds? — Iadmc♫^talk  08:00, 6 June 2024 (UTC)

The policy doesn't disallow those. It only disallows names that suggest the user's a bot.—S Marshall T/C 08:20, 6 June 2024 (UTC)

Oh OK. Thanks — Iadmc♫^talk  08:22, 6 June 2024 (UTC)

What about User:Notbot? Looks like a bot to me even though you can say he's claiming not to be a bot — Iadmc♫^talk  08:45, 8 June 2024 (UTC)

This is a borderline case and should be discussed with the community. I suspect it would?be allowed, but I can't be sure unless the discussion actually takes place. Animal lover |666| 12:35, 14 June 2024 (UTC)

I really think we should offer to do the name change on their behalf rather than make them go through all this crap and then request one and then sit around and twiddle their thumbs while they wait for us to get around to it. At the very least, give them a week to come up with a new one or something, and then block them. jp×g🗯️ 08:35, 8 June 2024 (UTC)

We really shouldn't be indefing editors because of their username, unless it's obviously offensive. I know that's kind of what we do already, but we really should just look at their edits, and see if they're WP:HTBAE or not. If they are, drop a note on their talk page, ask them what username they want, instead of mass blocks and biting. OzzyOlly (talk) 15:17, 8 June 2024 (UTC)

Theoretically, this is the rule, but in practice, the few admins who deal with this say it's too much trouble to check back to see if a request has been made. They block when it's not required because it's easier for them. WhatamIdoing (talk) 18:13, 8 June 2024 (UTC)

Usernames that suggest that the underlying account is a bot should be a communicate-level prohibited name-that is they should only be blocked after a failed attempt to convince them to change name. Additionally, they should never be blocked if their primary wiki is not English-speaking, and probably not even for other English-language wikis. And merely having words like "bot" or "script" shouldn't be a problem, only names which actually imply that the account is one. Any borderline case should be discussed with the community; "borderline" should be defined as anything that a good-faith, long-time community member may support allowing. Animal lover |666| 12:25, 14 June 2024 (UTC)

What about robot*** or bot***, these cases used bot as prefix not a suffix? -Lemonaka 02:50, 15 June 2024 (UTC)

AFAICT anything that implies the user is a bot is disallowed, I'm assuming they used suffixes as an example, and not as a hard and fast rule. All I'm saying is that disallowing those usernames causes more harm than good, for resolving an issue that even a much more experienced editor like you has never seen. OzzyOlly (talk) 04:14, 15 June 2024 (UTC)

@User:RobotGoggles Someone has called that your username is disallowed. Anyway, there are lots of user with a prefix instead of suffix and didn't cause any trouble. -Lemonaka 12:42, 15 June 2024 (UTC)

I am unsure what this discussion is regarding but I have had this username for years. It is a reference to Robotron 2084, the arcade game that was my original username, ages ago. When I lost that email and I had to make a new account, I created a portmanteau of Robotron and "Goggles", my high school nickname. It has nothing to do with any implications that I am a bot, nor that I am a human. I think, and I may be wrong about this, that users don't think that "robot" is a word to use to describe automated users on a web forum or wiki. Robots are physical machines, not just computer programs and software. I've, in fact, never even been accused by other users of being a bot, even in heated talk pages where you would expect such an accusation to be made. RobotGoggles (talk) 19:19, 15 June 2024 (UTC)

Maybe they see "RobertGoogles"? I did — Iadmc♫^talk  19:28, 15 June 2024 (UTC)

In addition, Robot-Google. If someone thought " anything that implies the user is a bot is disallowed", then this username may both considered assuming that the user is a "bot" and a "COI" editor. However, unless editing disruptively, no one may give them a block just because of the username. So the topic is a little bit absurd. -Lemonaka 02:42, 16 June 2024 (UTC)

Anyway, a bot from AmandaNP excessively positively detecting users may violate username policies, which may cause some trouble when a common newly registered user got a notice on WP:UAA just due to being detected. -Lemonaka 02:43, 16 June 2024 (UTC)

UAA should be done in such a way that doesn't notify reported users. Finding out about the report would be extremely BITEy for perfectly good user names, significantly BITEy for users with communicate-level disallowed usernames to find out that their names are problematic, and helpful for intentionally disruptively named users to help evade detection (I believe I covered the vast majority of reported names). Animal lover |666| 12:01, 16 June 2024 (UTC)

@Animal lover 666 Please report me for testing, I'd like to take a view whether they noticed reported users. -Lemonaka 14:30, 16 June 2024 (UTC)

I wonder if instead of blocking editors, an admin can rename the account to something like "Renamed user UF7IHSJ5JKIS8K" and drop a note on their talk page to ask them to create a new username. OzzyOlly (talk) 16:48, 16 June 2024 (UTC)

@OzzyOlly Sysop cannot rename user account, few sysops are global renamers. And Renamed user xxxx are left for vanished users. -Lemonaka 00:37, 18 June 2024 (UTC)

@OzzyOlly I meant that if you contribute constructively, why would someone blocked you for your username? Just as @Animal lover 666, merely having words like "bot" or "script" shouldn't be a problem. This is not something hard and robust. -Lemonaka 02:40, 16 June 2024 (UTC)

Of course it isn't robust, what I'm saying is is that it's unnecessary to resolve an effectively non-existent problem. And new users, even ones that are contributing positively do get blocked because of this rule. OzzyOlly (talk) 02:48, 16 June 2024 (UTC)

Unification of include-info and reject-info principles in the content policies

There is a suggestion to remove "not taking sides" from the NPOV policy, which is the essential point in its nutshell. The argument is that the terminology could be preventing that we reject fringe theories, etc., because that would be taking sides. Of course, this has never been the meaning of "not taking sides" in the policy. The language and the terminology are the superficial side of this. The concepts are the important side. Therefore, I suggested that before we consider the superficial terminological issue, we do a RfC about a better unification of include-info and reject-info principles in the content policies in general. I am concerned that I will be prevented from doing that RfC, because some would say that it disrupts the discussion. So, I am asking opinions about this here. Dominic Mayers (talk) 15:53, 9 June 2024 (UTC)

Negative conflicts of interest

Our policy at Wikipedia:Conflict of interest is thorough in its coverage of situations where an advocate for an organization, product, or individual is posting positive things and suppressing negative things about their favored subject, but much less so for situations where an opponent of the same tries to tip scales in the opposite direction. The policy does state that "there can be a COI when writing on behalf of a competitor or opponent of the page subject, just as there is when writing on behalf of the page subject". Without naming names, in my time here I have seen, e.g., litigants attempting to insert negative information about judges presiding over their cases and about opposing counsel (including creating articles on decidedly non-notable lawyers and firms to this end), buyers and other constituents of suppliers and services taking to Wikipedia to vent displeasures with their relationship, and others who for a litany of other personal experiences feel that some non-notable (or possibly borderline-notable) thing is so bad that it nonetheless deserves promotion to a full encyclopedia article so that it can be properly griped about. I am somewhat surprised that after all these years we do not have some kind of WP:NOTAGRIPESITE policy in place addressing the fact that a negative personal relationship between an editor and an article subject is still a COI. BD2412 T 21:51, 10 June 2024 (UTC)

WP:ADVOCACY can be seen as addressing some of this. Gråbergs Gråa Sång (talk) 10:52, 11 June 2024 (UTC)

Which names are suitable to list “given name” page? (And such page has a list of all notable people with this given name (without surname)

There is a Yuki (given name) page, list all notable Japanese people with name (without surname) Yuki, but their Chinese characters may be different (can be 雪, 幸, 由紀, 由貴, 由岐, 由樹, 友紀, 夕希, 有希, and others), the same holds for Do-yeon page, list all notable Korean people with name (without surname) Do-yeon, but their Chinese characters may be different (can be 渡然, 度妍, 度演, and others), but why not add a page for Chinese people? For example, “Yǔ-xīn (given name)” page, list all notable Chinese people with name (without surname) Yǔ-xīn, but their Chinese characters may be different (can be 語妡, 羽芯, 雨莘, 予歆, 宇馨, 禹昕, 瑀欣, and others)? All of Japanese, Korean, Chinese names use Chinese characters (Hanzi or Kanji or Hanja), which are logogram, thus unlike Linda (given name), which is a Western given name. 2402:7500:901:F0FF:2883:CBF9:5462:8F6A (talk) 03:48, 12 June 2024 (UTC)

This is the English Wikipedia. The names are grouped based on the English spellings of the names. Bookworm857158367 (talk) 04:21, 12 June 2024 (UTC)

Of course I know, all of Japanese, Chinese, Korean names can be grouped based on the English spellings, such as Yuki (Japanese), Yǔ-xīn (Chinese), Do-yeon (Korean) 49.217.63.200 (talk) 04:33, 12 June 2024 (UTC)

Any individual whose given name is written in English as Yuki in several different sources, even if it isn't the primary English-language spelling. Same goes for multipart given names, if any part is spelled this way and used as the given name in several sources. Animal lover |666| 12:15, 14 June 2024 (UTC)

Inclusion of List of compositions in an composer infobox

Does this go against any MoS? According to this edit it does. Is a notable list simply POV? See Wolfgang Amadeus Mozart as an example of the list link and Aaron Copland for a notable works list — Iadmc♫^talk  12:30, 14 June 2024 (UTC)

There was a discussion not so long back about this exact question. Unfortunately I can't find it or remember exactly what consensus it reached, but I think most people were in favour of including the link, although not necessarily with the wording "See list". I'm sad to say that it really does not surprise me to see the editor who reverted you edit warring and being obstructionate around infoboxes like it's still 2015. Thryduulf (talk) 12:55, 14 June 2024 (UTC)

No comment on the editor... Thanks for the heads up on the recent discussion. I'll look for it — Iadmc♫^talk  13:42, 14 June 2024 (UTC)

@Thryduulf@Iadmc This topic came up in the past the same way it came up for Iadmc. An editor claimed at Antonio Vivaldi that these lists violated MOS:FORCELINK. So after discussing at that article's TALK, the subject was brought up at WT:MOSIBOX. After a discussion about FORCELINK, there was very little support for that these links violate FORCELINK. In that discussion some editors objected on the basis of MOS:INFOBOXPURPOSE. That was also discussed and again there was very little support for that interpretation. In fact, quite the opposite. For whatever reason, some of the involved editors continue to edit articles citing a MOS interpretation that the community hasn't endorsed. I'm not sure where you go from here, but good luck. Nemov (talk) 15:38, 14 June 2024 (UTC)

I think I'm remembering the same conversation as @Thryduulf, and my recollection was that adding a single "List of works..." link was considered preferable to a long list. WhatamIdoing (talk) 17:13, 14 June 2024 (UTC)

If editors are knowingly editing against consensus then potentially a trip to ANI is required - especially if they are editwarring about it (or accusing others of editwarring about it). It's definitely a user conduct issue rather than a policy issue. Thryduulf (talk) 17:30, 14 June 2024 (UTC)

That's not a hornet nest I want to kick. It would probably require ARBCOM and given the editors at question here it seems like a headache. Nemov (talk) 18:13, 14 June 2024 (UTC)

Explaining how adding info helps achieve the neutral point of view

I participated in long discussions in the NPOV talk page regarding Wikipedia taking sides. Some say it should take sides in removing fringe theories. Realizing that the true issue was a debate between including vs rejecting information, I suggested that we first discuss that more fundamental issue. A participant asked me to give examples that illustrate how "describing debates instead of engaging them" helps achieve the neutral point of view. This a difficult and important challenge that I do not want to take alone. Moreover, I wish to spend less time in these discussions. So, I wrote the essay Please, explain the neutral point of view that passes the challenge to the community. It is up to the community to react or not. Dominic Mayers (talk) 15:39, 14 June 2024 (UTC)

The biggest problem in that is that the approach you are suggesting for not taking sides appears to require the use of original research. For example when a judge is not taking sides, they are in their capacity allowed to look at all evidence and all relevant case law and then synthesize a decision from that. Ideally this show mirror establish case law but often judges cradt new concepts as to remain neutral. For us on WP, our job is only to summarize what is reported in reliable sources, and we cannot craft a conclusion not given explicitly in those sources. So we can only "not that sides" from what material is presented in reliable sources, and cannot include material that would perhaps likely make a more unbiased take on the topic if that material only originates in unreliable sources. We should work to present material in a way that appears to not take sides, but if one side of an argument is what RSes give 99% coverage of, we aren't able to craft a false balance to make both sides seem equal. — Masem (t) 16:02, 14 June 2024 (UTC)

As I explained, I wish to spend less time in these discussions. Dominic Mayers (talk) 16:06, 14 June 2024 (UTC)

This has been a consistent point of discussion in the NPOV talk page threads. -- LCU ActivelyDisinterested «@» °∆t° 16:54, 14 June 2024 (UTC)

Wikimedia Movement Charter ratification vote! How should we spend a billion dollars?

I am writing to request feedback on the meta:Movement Charter by 25 June to publish as community reactions in the next issue of The Signpost.

Hi I am Lane Rasberry / user:bluerasberry. I am an editor for The Signpost. I also organize wiki stuff off-wiki in lots of ways, including in-person Wikipedia meetups and professionally as a Wikipedia researcher at my university.

I am writing to share the news that somehow - perhaps as an endpoint to 10 years of strategic planning - wiki governance has produced a draft Movement Charter. There will be a global ratification vote on it 25 June through 9 July. Lots of people have lots of views of this. My view is that this document would greatly influence and justify how the Wikimedia Movement spends the US$1,000,000,000 (billion dollars) which the Wikimedia Foundation is likely to collect over the next 6-8 years.

I am writing here to seek comments and reactions to the Charter. Also, please if you respect the views of any other individuals or organizations, then ask them to comment. I want to publish this in the next issue of Signpost to help inform voter decisions on the ratification. I also asked for comment at meta:Talk:Movement_Charter#Request_reactions_to_Charter_for_Signpost_newsletter and Wikipedia_talk:Wikipedia_Signpost/Newsroom#Movement_Charter_Ratification_vote. Thanks for any reactions. Feel free to post here, in the newsroom, or anywhere just so long as you share what you did for reporting in The Signpost. Bluerasberry (talk) 16:08, 14 June 2024 (UTC)

My initial reaction is that it doesn't feature the word "encyclopedia", and that's a shame. Barnards.tar.gz (talk) 18:34, 14 June 2024 (UTC)

I'm concerned the statement "The Wikimedia Movement is based on and embraces a factual, verifiable, open, and inclusive approach to knowledge-sharing", while full of good things, foregoes "ethical" or any other terminology that would be fight against justifying a pirate site. -- Nat Gertler (talk) Nat Gertler (talk) 18:51, 14 June 2024 (UTC)

This 'movement' is, needless to say, a fiction. People who edit stuff on WMF-hosted websites are no more a 'movement' than Redditors, or people who use X-that-used-to-be-Twitter. AndyTheGrump (talk) 19:16, 14 June 2024 (UTC)

A movement for X
That used to be Twitter
From reading the posts
Must be named Xitter
Burma-shave

-- LCU ActivelyDisinterested «@» °∆t° 20:07, 14 June 2024 (UTC)

@AndyTheGrump [5]: The “Wikimedia Movement” refers to the totality of people, groups, and organizations who support and participate in Wikimedia websites and projects. It includes all of those who operate within the policies, principles, and values of the movement. It's a thing but still you point that it is really a fiction. — Iadmc♫^talk  21:14, 14 June 2024 (UTC)

I am well aware of what the WMF claims in regard to this supposed 'movement', when trying to justify their funding efforts. I have seen precisely zero evidence that anyone has done any research into the extent those who use WMF websites actually subscribe to the 'principles' and 'values' claimed, or that they consider themselves a part of any particular 'movement'. There is nothing whatsoever in the terms of use that describes such particular beliefs, and it would be grossly improper to require them. AndyTheGrump (talk) 22:02, 14 June 2024 (UTC)

This just reads like meaningless marketing jargon to me, like calling a shopper doing some price comparison "the client's purchasing journey". That's not what a "journey" is, and this is not what a "movement" is. JoelleJay (talk) 18:17, 15 June 2024 (UTC)

@AndyTheGrump@JoelleJay Yes. Marketing probably. I Follow the WP:5P and all that goes with it. I know nothing of 'principles' and 'values' of WikiMedia. A ficticious jargon and a waste of time no one will read. — Iadmc♫^talk  18:22, 15 June 2024 (UTC)

The 5Ps only apply to the English language Wikipedia, and while we adhere to them, there is no shortage of evidence that not everybody agrees with them. Hawkeye7 (discuss) 18:59, 15 June 2024 (UTC)

Maybe the WMF should spend that money employing people in developing countries to digitize their print media rather than using it to create more and more ideological focus groups that have nothing to do with building an encyclopedia. JoelleJay (talk) 18:24, 15 June 2024 (UTC)

The WMF's flight of fancy took off long ago, and it has completely lost contact with Wikipedia or any other real-world activity. It now exists mainly to deceive donors who think they are supporting Wikipedia into financing unrelated activities. I often consider making a constructive edit but do not bother, knowing that it would be abused in this way. I am not part of any so-called Wikimedia movement, and it does not represent me in any way. Certes (talk) 19:18, 15 June 2024 (UTC)

God, how good would a developing country media digitization effort be... and the WMF has the means to make it happen! ꧁Zanahary꧂ 05:27, 19 June 2024 (UTC)

Who the hell are the "stakeholders"? Does the W?F think we care about this corporatese nonsense? I know they're out of touch, but still...

This isn't nearly as bad as the magnificently nonsensical meta:Wikimedia Foundation Annual Plan/2024-2025/Product & Technology OKRs, but still fails to actually establish anything useful.

And there are of course sneakily vague bits. Take, for example,

All contributors and other volunteers must follow Wikimedia Movement policies applicable to them while contributing and undertaking volunteer activities.

“policies applicable to them” is as open a loophole for the W?F to ban a few people they happen to not like for whatever reason as I've yet seen. How about

All contributors and other volunteers must follow the policies of the Wikimedia community (e.g. English Wikisource, French Wiktionary) they are contributing to.

I, for one, will be voting against this W?F nonsense. Cremastra (talk) 16:37, 16 June 2024 (UTC)

They can make up arbitrary rules for me to follow, but they won't change my current behaviour which I believe to be perfectly reasonable. Of course, they can office-block me for pointing out their deficiencies. However, if they do that to everyone, they will soon find themselves with no community and a stale encyclopedia that no longer generates the donations that pay them for watching us write it. Certes (talk) 17:35, 16 June 2024 (UTC)

@Cremastra, you have already individually agreed, on at least some twenty thousand separate occasions, that you will follow those policies. Have you ever read the foundation:Terms of Use? I suggest that you do so, paying particular attention to ==Resolutions and Project Policies==, which says "The Wikimedia Foundation Board of Trustees releases official policies from time to time. Some of these policies may be mandatory for a particular Project or Project edition, and, when they are, you agree to abide by them as applicable."

While I'm here, I'm always surprised to see people, even editors who have been around for a while, claiming that "the movement" is something that was created by the WMF and has nothing to do with us. The idea of 'the Wikimedia movement' was created by volunteers. It dates back to at least 2004, when the WMF had zero paid staff. WhatamIdoing (talk) 03:48, 18 June 2024 (UTC)

Oh, I support the Wikimedia movement. I contribute to four Wikimedia projects and wish more people would do the same. Cremastra (talk) 12:22, 18 June 2024 (UTC)

• Hi all - wearing my Movement Charter Drafting Committee hat here for a minute. I can quite reassure you that the WMF was not directive in what is contained in the Movement Charter that will be voted on starting next week. In fact, getting the opinion of the WMF on various topics was really difficult, especially in the early days as we started the process. The content of the Charter is largely reflective of recommendations from the 2030 strategy initiatives, which were released back in 2019 (it was released just as the world came to a screeching halt with the pandemic). We have no idea on the Drafting Committee how the WMF Board of Trustees will vote when it comes to the Charter; we'll find out at the same time as the broader community does.

  The ballot has two sections: a support/--/oppose section (with the "--" taking the place of the word "neutral" as it's hard to translate into some languages); and a comment box. People can vote any way they feel is right, AND they can include an extensive comment on their reasoning. Several people in this thread have expressed opinions; I hope they will vote and include those opinions in their ballot. A summary of all of those comments will be published, regardless of whether or not the Charter is ratified. If it is ratified, we have a Charter. If it is not ratified, we will have a much better idea of how individual community members are thinking, and that will definitely help in determining next steps. We have had so few individual community members participating in the discussions leading up to this ratification vote that there's no way to predict an outcome. We just hope that people will participate in the vote itself, and tell us what they're thinking. What do you like about the Charter? What do you not like? What made you decide to vote the way you did? We really look forward to finding out more.

  I know you'll see more about this ratification vote in the coming days and weeks, and I hope a lot of people participate. Takes off MCDC hat and goes off to eat dinner. Risker (talk) 04:43, 18 June 2024 (UTC)

  What are the languages where we’ve been able to translate the draft charter but haven’t been able to translate the word neutral? Barnards.tar.gz (talk) 06:35, 18 June 2024 (UTC)

  If it is not ratified, we will have a much better idea of how individual community members are thinking, and that will definitely help in determining next steps.

  @Risker Under what circumstance will the Movement Charter be considered "dead"? There is a non-zero part of the community which considers the Movement Charter efforts structurally flawed enough that it needs to stop. I personally think the efforts so far are underbaked and overly convoluted at once; but am not sure if that requires more effort to fix things, or the charter should just go away.

  Community fatigue is a thing (with so many elections and ratifications happening over the last few months) and I'd like a bit more clarity on what circumstances would lead to either outcome. Soni (talk) 17:30, 19 June 2024 (UTC)

  Soni, there isn't a good answer to this question. A lot of it is dependent on (a) the actual results of the vote and (b) the nature of the comments received. We will have to wait and see. Risker (talk) 20:55, 19 June 2024 (UTC)

  Fair enough. I guess pre the actual charter vote, my main question is just... "What's the point of all this?" I've tried to follow the entire discussion in meta, here and elsewhere. Nowhere can I find a clear simple articulated "Here's why we're doing this", as opposed to "People in this meeting back in 2021 recommended it" and "We've been working on this for N years, here's a timeline".

  Why is the MC a thing? What does it change for day-to-day work in the projects/top level decisionmaking? Will the movement charter be binding over WMF? The community? How is this different from ToU/UCoC/WMF's Annual Plans? Similiar question for GC/GCB but with U4C/WMF BoT? Will the decisions of GC/GCB be binding over anyone?

  I can probably think of a few more adjacent questions. It's not that none of them have been answered if you carefully read between all the lines, it's that the entire process could really use a "Simple answers FAQ" instead of a "Here's all the ways you can help the MC" style FAQ page we have. I remember giving this feedback to someone from WMF/MCDC working on this, but the FAQ continues to be as unhelpful as ever. Soni (talk) 22:15, 19 June 2024 (UTC)

Policy for chemical data page

Hello, when I was discussing Wikipedia:Articles_for_deletion/2-Pyridone_(data_page), some one noted that there are lots of datapages on Category:Chemical_data_pages, much of them are created by Edgar181 (talk · contribs) who was banned years ago. These pages are in different styles, and some of them lack references. We may need a policy for such pages, for example, should they merged to main article of the related chemicals? Should they moved to Wikidata? Is there Any additional requirements for such pages since they are not an article?

I've viewed previous discussion on project, Wikipedia talk:WikiProject Chemistry/Archive 36#Data pages and Wikipedia talk:WikiProject Chemistry/Archive 50#Chemical data pages - move to Wikidata?, no clearly consensus got. Some users who discuss this topic also banned for years. -Lemonaka 02:45, 15 June 2024 (UTC)

Pinging Graeme Bartlett, Boghog, and Bduke, who seem to know things about chemistry.

Lemonaka, these look to me like very large infoboxes. Perhaps they could be transcluded into a collapsed section? WhatamIdoing (talk) 03:01, 15 June 2024 (UTC)

Count me out. It is 20 years since I was a chemistry academic and I was more into physical chemistry and not individual chemicals. Bduke (talk) 05:04, 15 June 2024 (UTC)

I think I was the someone in that discussion. I am by no means an expert in chemistry but as an outsider I would assume that people who need such information have a better source for it than Wikipedia pages. I suspect that most of the pages are pretty-much unused but I would be happy for any deletion/merge decisions to be made on a case-by-case basis in case some some of them are considered useful.

I would suggest changing the line If using the full Chembox, a supplementary page should be created as soon as time allows on WP:CHEMBOX § Supplementary data page. Even if some data pages are useful, I don't think it is useful to encourage indiscriminately creating them for all chemicals. Mgp28 (talk) 07:25, 15 June 2024 (UTC)

I've added links to this discussion from Wikipedia talk:Manual of Style/Chemistry and Template talk:Chembox Mgp28 (talk) 07:37, 15 June 2024 (UTC)

Much of the info on the datapages are in the main articles under chemboxes. I never even knew these datapages even existed. They seem to be miscellaneous pages or partly redundant compared to chemboxes that are found in main chemical articles which provide up to date info. And some that I looked at don't seem to be updated for years on chemicals properties. Some carry interesting documents like Materials Safety Datasheets (MSDS). Ramos1990 (talk) 08:08, 15 June 2024 (UTC)

We should discourage datapage creation. Instead articles should be made if the information is too detailed for the main article. I like the idea of "Properties of chemical". The banning of Edgar181 really has no bearing on the quality. But the main issue with the datapages is the lack of references. Graeme Bartlett (talk) 09:58, 15 June 2024 (UTC)

I like this idea. I would be much happier with any extra information being presented in properly-sourced articles. Mgp28 (talk) 11:03, 19 June 2024 (UTC)

• Wikisource seems like the most appropriate place to include additional data that is beyond the scope of an encyclopedia article. Masem (t) 12:30, 15 June 2024 (UTC)

  You may mean wikidata?? -Lemonaka 12:40, 15 June 2024 (UTC)

• I vaguely recall AFD for the lot of them a few years ago, that did not get consensus to delete. Can't find the page at the moment... DMacks (talk) 03:08, 16 June 2024 (UTC)

MOS on date format by country

Hello. Recently I learned by observation that Wikipedia tends to use DMY date formats (except for US subjects). Can someone please cite that policy? MOS:DATETIES applies to the use of English by country, as does MOS:TIES. I cannot find an applicable policy for subjects from non-English-speaking countries in MOS:NUM. I searched your archives and found mainly arguments, not really a useful pointer, sorry. Thank you for your time. -SusanLesch (talk) 14:21, 16 June 2024 (UTC)

The applicable guideline is "Retain existing format". In summary,

*The date format chosen in the first major contribution in the early stages of an article (i.e., the first non-stub version) should continue to be used, unless there is reason to change it based on strong national ties to the topic or consensus on the article's talk page.

Jc3s5h (talk) 14:27, 16 June 2024 (UTC)

Thank you for the quote. That's exactly what I need. However the administrator who corrected me thinks MOS:VAR doesn't apply. He says MOS:DATETIES covers Italian subjects. I have read, and re-read MOS:DATETIES and conclude that no, it relates to English usage by country. Where does MOS offer guidance on date format by country? -SusanLesch (talk) 14:38, 16 June 2024 (UTC)

When I use the feature at Wikipedia talk:Manual of Style/Dates and numbers to search the archives for the word "countries" I see 127 discussions. The most recent discussion I found was Wikipedia talk:Manual of Style/Dates and numbers/Archive 161#Date Formatting for non-English speaking countries. Jc3s5h (talk) 15:04, 16 June 2024 (UTC)

Thank you again. I read the entire recent discussion. Exasperating. The result was an upset stomach, not answering the question, and instead reminding me that Wikipedia does not even know whether or not it should use citation templates. (If someone were to advocate for the metric system, to do away with daylight savings time, to prohibit pharmaceutical advertising on television, and to adopt the DMY date format, they'd have my vote in the US November elections.)

I guess this means my argument is with the administrator who corrected me without consensus, and not with Wikipedia policy. -SusanLesch (talk) 16:53, 16 June 2024 (UTC)

Were you guys going to notify me about this topic given you are talking about me? The height of bad manners.

I repeat - Italy uses DMY (see Date and time notation in Italy), hence why the articles on Leonardo da Vinci et al do. Retaining an existing format does not count when the existing format is incorrect. If a British person was to create an article about a US politician, would it stay DMY? No, course not. GiantSnowman 17:31, 16 June 2024 (UTC)

Publications, including Wikipeda, use whatever date format is called for in their style manual. Would-be authors who don't want to follow the style manual are likely to get rejection letters or the equivalent. Looking outside the rules of the publication to see what is or isn't "correct" is the wrong approach. But if you want to change the rules, that's a different matter. Jc3s5h (talk) 19:40, 16 June 2024 (UTC)

What are you on about? Italy uses DMY and so Italian-related topics should follow that. GiantSnowman 20:03, 16 June 2024 (UTC)

For evidence that a publication may use whatever date format they want see an obituary in the Telegraph about Italian pianist Maurizio Pollini which uses "24 March 2024 • 9:11am" for the timestamp of the article but "January 5 1942, died March 23 2024" for the birth and death dates of the subject of the article. Jc3s5h (talk) 20:29, 16 June 2024 (UTC)

Date and time notation in Italy says DMY is standard. DMY is also used in USA (military) but is not standard. GiantSnowman 20:38, 16 June 2024 (UTC)

@GiantSnowman: MOS:DATETIES says (emphasis added) Articles on topics with strong ties to a particular English-speaking country. Last I checked Italy is not considered an English-speaking country, so MOS:DATETIES doesn't apply. Anomie⚔ 21:19, 16 June 2024 (UTC)

True. That said, MOS:DATEVAR simply says unless there is reason to change it based on strong national ties to the topic with no mention whatsoever of English-speaking, so either GiantSnowman's reasoning is correct, just filed under the wrong MOS shortcut, or if national ties in DATEVAR was meant to apply specifically to English-speaking countries, it needs its wording adjusted. AddWittyNameHere 21:26, 16 June 2024 (UTC)

Since MOS:DATEVAR immediately follows MOS:DATETIES, it could easily be that "English-speaking" was omitted from the latter because "strong national ties to the topic" was considered a reference to the previous section titled "strong national ties to a topic". When the language was originally added in December 2007 the two were even more closely associated. Checking Wikipedia talk:Manual of Style/Dates and numbers/Archive 92 for contemporaneous discussion, I see some discussion over "English-language" along the lines of GiantSnowman's argument but it doesn't seem to have resulted in its removal at the time. Anomie⚔ 21:57, 16 June 2024 (UTC)

Just a note here that the "height of bad manners" is supposed to refer to me. I came here for information, and when a break occurred I went back to post on the original thread. Another editor had entered the conversation at length. -SusanLesch (talk) 22:16, 16 June 2024 (UTC)

We should remove 'English-speaking' - otherwise we have carnage, as shown here. GiantSnowman 17:29, 17 June 2024 (UTC)

WP:DATETIES is good for English speaking countries and their 2 formats (DMY, MDY). For countries that do not align with the 2 English formats (eg, most of Asia) then DATETIES is also fine with first come, first served. But for non-English countries such as Italy that do align with DMY or MDY, then I say we should honour that that format. It is for the same reasons that we let Yanks have their format and Brits have theirs - to align with the most likely readers and editors of those articles without constant edit wars. It is only for articles tied to YMD countries (typically Asia) and articles not tied to a specific country that should be first come, first serve.  Stepho  talk  08:01, 17 June 2024 (UTC)

Which "most likely readers"? Wouldn't Italians be more likely to read the Italian Wikipedia, since that's in their own language? Unless maybe they're wanting to practice their English or think their own language's coverage is lacking, but do we really want to be in the position of deciding which non-English Wikipedias aren't "good enough"? Anomie⚔ 11:06, 17 June 2024 (UTC)

As you are specifically talking about non-English speaking countries, what they do is absolutely irrelevant. How they write the dates is no more important to us than what word they use for "dog". --User:Khajidha (talk) (contributions) 12:12, 17 June 2024 (UTC)

It's reasonable to think most of the edits in the English Wikipedia will be made by editors who's first language is English. Although most editors may be able to look at a few dates in most European languages and figure out what the format is, they likely will not know what reference works best represent editorial practices in non-English speaking European languages, nor are they likely to possess copies of those works unless they're free. Requiring editors to figure all this out is an undue burden on editors. I know if I have a English-language date format question outside of Wikipedia, I'd look at, perhaps, the Chicago Manual of Style or the Associated Press Stylebook, and I know which shelf I keep them on. If I had a similar question about Polish, I would have no idea where to look. Jc3s5h (talk) 14:08, 17 June 2024 (UTC)

A place to look is the Italian Wikipedia, it:Aiuto:Manuale di stile#Date which permits only DMY ordering. This concurs with Date and time notation in Italy, the sources used in that article, and every relevant hit (reliable and unreliable) I found on the first three pages of a google search for What date order does Italy use?. In other words, every relevant bit of evidence suggests that articles about Italy should use DMY. Thryduulf (talk) 19:19, 17 June 2024 (UTC)

May I suggest that anybody interested in making that change explain it at MOS talk and maybe we'll see the guidelines revised? For now, MOS:DATEVAR has precedence. -SusanLesch (talk) 20:58, 17 June 2024 (UTC)

If you want to enforce the Italian Wikipedia's manual of style you can go and do so on Italian Wikipedia. There is and should be absolutely no requirement for English-speaking Wikipedians writing in English on English Wikipedia to know or care what it.wiki's manual of style says. Caeciliusinhorto-public (talk) 14:11, 18 June 2024 (UTC)

You have completely misinterpreted my comment. I am not advocating applying the Italian Wikipedia's MoS to the English Wikipedia, but for using the Italian Wikipedia's MoS as one point of evidence regarding what Italian style guides state is correct usage in Italian/in Italy. Jc3s5h stated they wouldn't know where to look to find what is correct in Italian, I simply pointed out places to look to find the answer. Thryduulf (talk) 14:29, 18 June 2024 (UTC)

and I have already highlighted Date and time notation in Italy multiple times. GiantSnowman 17:00, 18 June 2024 (UTC)

I personally think it's pretty silly to have MDY set on articles whose topic doesn't touch North America. It's just awkward to work with when most quotes and literature will be in the other format. Remsense诉 17:59, 18 June 2024 (UTC)

Well, we could solve all of this by uniformly using metric dating (largest to smallest, or year-month-day-hour-minute-second, etc). That would be the international standard, but of course I'm just stirring the pot here. Risker (talk) 22:10, 18 June 2024 (UTC)

ISO 8601 FTW! RoySmith (talk) 22:21, 18 June 2024 (UTC)

This conversation should be merged with the parallel conversation at Wikipedia talk:Manual of Style/Dates and numbers#DATETIES_vs._DATEVAR. There are currently editors contributing to both discussions on both pages. Doremo (talk) 07:40, 19 June 2024 (UTC)

Looks to me like User:EEng edited MOS:DATEVAR to clarify it as a result of this discussion, User:GiantSnowman decided to edit war over it because it clarified that his interpretation wasn't what the guideline intended, and then someone started a discussion about the edit on WT:MOSDATE which quickly shifted to discussing whether "English-speaking" should be removed from both MOS:DATETIES and MOS:DATEVAR. I'm not sure "merging" this discussion would be appropriate, but notifying that people here who have something useful to contribute there (and aren't afraid to get into a MOS-warring discussions) should do is. Anomie⚔ 11:26, 19 June 2024 (UTC)

Thank you; this summary is helpful. Doremo (talk) 12:26, 19 June 2024 (UTC)

I did not edit war. GiantSnowman 17:41, 19 June 2024 (UTC)

Discussions in the NPOV talk page

I am not sure what is the purpose of the current discussions in the NPOV talk page. I am concerned that people want to remove "Not taking sides" from the nutshell, because they feel that it can be used to prevent rejecting fringe theories. So, I wrote this essay about rejecting vs including info, because I think this fundamental issue should be discussed first. My hope is that I can stop discussing in the NPOV talk page and let others discuss. People blame me for that and claim that I must discuss, because I want to change the policy, but that is not true. I do think that a global discussion about NPOV is useful, but not in the policy talk page, not until we have a concrete proposal. So, I removed the policy from my watch list, despite the blame for not wanting to discuss. Dominic Mayers (talk) 20:29, 16 June 2024 (UTC)

Note added: The last comment from Shooterwalker was not there and I was not aware of it when I started to write this. This last comment might have taken care of the issue. Dominic Mayers (talk) 20:42, 16 June 2024 (UTC)

Policy on translation

Hi, I would like to know the policy on translation. I don't mean translation of entire articles, I mean translation of specific quotes, such as for example the lyrics of a song. Should there be a) only the original language text, b) only our translation, or c) both? My concern is that a) prevents some people from understanding the article, b) in a way misquotes the sources, and c) ends up with a lot of [original text] (meaning [en text]), or similar, that clutter the article a bit. I didn't manage to find this as most translation-related page are about translation of full articles. Thank you, — Alien333 (what I did & why I did it wrong) 18:47, 18 June 2024 (UTC)

Both… If the lyrics of a song are significant enough to quote, they are significant enough to include a translation. Consider a footnote if you think it would clutter the article. Blueboar (talk) 20:38, 18 June 2024 (UTC)

I like the way Cædmon's Hymn does it.—S Marshall T/C 20:42, 18 June 2024 (UTC)

Unfortunately that all looks rather odd unless your using a standard desktop resolution, as it's trying to force a specific formatting by using spaces. -- LCU ActivelyDisinterested «@» °∆t° 19:29, 19 June 2024 (UTC)

Are you talking about the part where each half-line is separated by three spaces? That's actually conventional formatting for Middle English alliterative verse. But what I meant was the part where the translation is side by side with the original.—S Marshall T/C 22:46, 19 June 2024 (UTC)

I mean the side by side doesn't line up properly, as new line placement is all over the place. These are better handled by tables, so the lines match the correct placement for each other however it's viewed. -- LCU ActivelyDisinterested «@» °∆t° 14:26, 20 June 2024 (UTC)

Oh, that's interesting. It uses {{verse translation}} so you're describing some kind of problem with the template rather than the article. It looks fine to me, on my laptop, desktop, tablet and phone.—S Marshall T/C 15:19, 20 June 2024 (UTC)

The policy says that we should provide translation… it does not (and in my opinion, should not) specify how to do so. There are lots of different ways to provide translations… all are acceptable. Which to use can be left up to consensus at the article level. Blueboar (talk) 14:38, 20 June 2024 (UTC)

Please, see MOS:FOREIGNQUOTE. Ruslik_Zero 20:48, 18 June 2024 (UTC)

Also see: WP:RSUEQ Blueboar (talk) 01:39, 19 June 2024 (UTC)

Thank you all! — Alien333 (what I did & why I did it wrong) 07:19, 19 June 2024 (UTC)

How the understanding of due weight affects the application of NPOV

This is an attempt to continue here a "great and important topic" that started in the talk page of NPOV. In short, North8000 started by saying that the section on due weight was "obsolete on two fronts in the post-journalism era and the current media-are-now-partisan-advocates era", Philomathes2357 agreed and asked how would you rewrite it and Masem mentioned "the need to value sources far separated in both time and relationship to the topic at hand than those that are very near the topic in both ways."

Here is my reply, but it is long. I will find the way to insert it in the discussion

Here is my reply. I do not disagree that the above points are real issues. However, unless I am misunderstanding them, they are about which sources to use, which, in my understanding, seems complementary to due weight: due weight enter into consideration after we have chosen the sources that must be taken into account. I believe I can explain why this happens. Why we discuss reliable sources when the subject is due weight. I suggest that the issue is that "weight" have never been a well explained concept. So, it became a "fourre-tout" (cath-all) for any new concern we might have with any content rule of Wikipedia. In particular, "weight" suggests a total order: every content has either more weight or less weight than any other content, that is, we could order the different possible contents on a line, those on the left side having less weight than those on the right. But, this total order corresponds to nothing in reality. Knowledge is not organized in this way. It creates a fictive world: we speak of less or more weight, but it's not real. Nobody, for example, will count the number of sources that support a given content. It is always more complicated than that. Not more complicated in the sense that evaluating the weight is technically complex, but in the sense that the notion of weight itself is too simplistic and has no practical value. Yet, we somehow convinced ourselves that we can correctly order the possible information on a subject using weight. This creates false dilemmas. Again, because it's not a concept that matches with reality, the request for due weight becomes a "fourre-tout" or catch-all for any practical concern we might have with the policies. It is especially the case with concerns with sources, because they can easily, but yet in a fictive manner, be turned into a less dichotomic notion of weight on the content. I am not saying that the concerns mentioned by North8000, Philomathes2357 and Masem aren't real. I am saying that we should perhaps stop placing them in the context of a fourre-tout or catch-all, because that is not a good organization of the rules. Most importantly (perhaps I should have raised this earlier), this distracts us away from other important aspects of the neutral point of view. Really, some people even argue that NPOV is essentially the same as due weight. That is the real problem.

Dominic Mayers (talk) 09:51, 20 June 2024 (UTC)

Discussion about whether this discussion should happen here

I think that a real in depth discussion of wp:weight would be beneficial. But if we scatter it amongst many different places we really aren't going to have it. Sincerely, North8000 (talk) 12:42, 20 June 2024 (UTC) Yes, but this page is the right place. Please, read what it says at the start: "The policy section of the village pump is used to discuss already proposed policies and guidelines and to discuss changes to existing policies and guidelines." We should only use the talk page of NPOV when we have some concrete change to propose. Dominic Mayers (talk) 13:10, 20 June 2024 (UTC) [we don't have a sufficient point on the NPOV page to even start that type of discussion here. Once we have a proposed wording change on NPOV it then makes sense to call on more voices from VPP. — Masem (t) 13:54, 20 June 2024 (UTC) Any discussion to find a proposed wording should happen here. This is the right place. If it not, then I don't know where is the right place. It is not the NPOV talk page. Dominic Mayers (talk) 14:01, 20 June 2024 (UTC) It should stay on the NPOV page, where there is already a large discussion on the matter. Rather than splitting it and starting a new thread here. -- LCU ActivelyDisinterested «@» °∆t° 14:48, 20 June 2024 (UTC)

• I see two issues that I see needing to be addressed. The first is that people too often jump right to UNDUE to exclude viewpoints instead of using DUE to weigh how they should be included. The second is an over reliance on breaking news coverage. This type of coverage, by its nature, omits nuance… and we need nuance to properly weigh what is DUE. Blueboar (talk) 15:20, 20 June 2024 (UTC)

  There is a subtle aspect that should not be neglected. The way you present it, the viewpoints considered already exist. In practice, this means that the statements already exist. In that case, DUE is simply the opposite of UNDUE: if a statement is proposed and it is not rejected, this means that it is accepted. This is why there is a single rule "Undue and due weight..." But, achieving the neutral point of view often requires to provide new contents, such as the arguments or simply a neutral attribution, that are not yet under consideration. This is not at all simply DUE, as the opposite of UNDUE, at the least not the way it is stated now, because it refers to a known statement or viewpoint. In contrast, the neutral point of view often requires that we think out of the box to find what must be added. This means that the notion of weight as a total order (see my hidden comment above) is not useful. The knowledge that we must read and understand is not at all organized in this manner. Dominic Mayers (talk) 15:41, 20 June 2024 (UTC)

  How is this different than arguing for a FALSEBALANCE? If we happen to know there are alternative views out there than what RS already cover, but otherwise not covered in RSes themselves, how are we supposed to include them? — Masem (t) 17:06, 20 June 2024 (UTC)

  I am not talking about alternative views out there than what RS already cover. I am restricting the discussion to views that can be found in reliable sources. I think you greatly underestimate what is required in a synthesis and what is the role of the editorial process. Once we are presented a given article and we have read and understood the reliable sources, we can judge whether or not there is FALSEBALANCE or undue weight, but that does not give you any method to avoid it. This method is the editorial process and the synthesis. My point is that the difficult part to achieve the neutral point of view (and avoid undue weight) is finding out what must be added. More attention is needed on that side. Just saying that the goal is to avoid FALSEBALANCE is not sufficient and, more importantly, only focalising on NOR, V and RS only tells us what to reject and that is, even more clearly, not sufficient. Dominic Mayers (talk) 17:21, 20 June 2024 (UTC)

  I'mn a hypothetical situation, we can collect all the RSes about a topic ever written. From that, we could make a survey to catalogue all viewpoints given and tally the number of sources that support that viewpoint. We would the have a good measure of what are significant viewpoints and insignificant ones with which can use DUE, UNDUE and Fringe to properly present the most important st neutral POV as reported in RSes.
  However we do not have that ability to collect all sources. So what I have recommended is to do a sources survey, gather like 100 RSes on the topic, randomly select say 25 or even go through all 100, to do a source survey as to estimate the weight of viewpoints and then proceed to apply DUE, etc. — Masem (t) 18:47, 20 June 2024 (UTC)

  You are proposing to completely change the way of writing articles in Wikipedia and what you propose seems to greatly underestimate the challenges in doing a synthesis and in the editorial process. It's difficult to further argue about that, because the process that editors use to understand sources, do a synthesis, etc. cannot really be explained and should be a shared background on the basis of which a discussion can occur. Dominic Mayers (talk) 21:49, 20 June 2024 (UTC)

  We are supposed to summarize viewpoints without bias. I can't see how this approach isn't good towards that. There is no invalid synthesis used. This is what editors should be doing as they write articles. Instead more commonly these days, editors have a preset goal they want to write for and only seek out sources to support that, and then often use that to assert what the majority POV is having not done a properly neutral evaluation of sources. — Masem (t) 09:53, 21 June 2024 (UTC)

  Again, the complexity of the editorial process (synthesis being a part of it) does not show in your description. The fact that it says 25 reliable sources are used is not the issue. The mention of the abstract notion of weight is not so wrong in itself either. Your description is wrong because of what it does not say, not because of what it says. I will illustrate a very small part of what it does not say. A notorious source says "Life is great". The name of that source is Joe Blow, but it does not show when you read the statement. It is only mentioned in the cover page. A simple editorial process could result in the inclusion of "Life is great" in the article, with the source as a reference, just as if it was a fact that life is great. I suspect that you will stop me and say that it is not what you mean and that we should, in that case, include "Joe Blow says life is great". But, even if you understand that an attribution is required in that case, it still remains that it is not mentioned at all in your above description. That is a small part of what I mean by the complexity of the editorial process does not show in your description. This small part is emphasized in the policy nowadays, but it used to say more, for example, that arguments must be provided. Regarding the arguments, you might again stop me and say that, yes in some cases we must provide the arguments. It is great, if that is the case, but it is not true that there is no need to have the concepts of arguments in order to do that and that a mechanical simplistic process will automatically extract the arguments only by counting occurrences of sentences. So, again, your description of the editorial process says nothing about key aspects of the process. As in the case of attributions, the description of the editorial process will not and cannot provide a simple criteria to determine when the arguments must be provided, but the fact that in some cases arguments must be provided should still be a part of the description. Ideally, simple examples should be provided and explained. The serious issue, not only in your description, but also in the current text of the policy, is the emphasis on the abstract notion of weight as if it was enough to cover the essential of the process. Dominic Mayers (talk) 11:09, 21 June 2024 (UTC)

  WP:YESPOV is how we know or determine when attribution should be required to a statement that appears to be a statement of opinion rather than fact. There is a grey area here and there's no way we can set down exacting standards to when attribution may be used or not, though as I've talked before, when you see agreements in sources far distant in time and independence from the topic on a seemingly opinioned statement, that's when we can start treating it as more factual and drop attribution. But there is a lot of middle ground here, far too difficult to distill into any guideline, and instead, we do have to rely on editorial concensus. I would only think the key aspect is that if there is any serious question of whether unanimity of a subjective statement has been reached, we should always default to assuming some type of attribution is needed. Masem (t) 20:58, 21 June 2024 (UTC)

  I agree with all of that. The idea of the NPOV policy is to convey the idea how some method, in this case attribution, works to achieve the neutral point of view. Once the idea is understood, how and when to apply the method is to be determined on a case by case basis. Some simple non polemical examples could be needed. However, in the case of attribution, I think experienced editors already understand the concept. But, as I said, attribution is only a small part of what might need to be used to achieve the neutral point of view. Other times, we need to provide the arguments. There is no telling in advance what might need to be added to achieve the neutral point of view, but the policy would benefit from more examples that convey the general idea. I am repeating my last sentence here: The serious issue, not only in your description, but also in the current text of the policy, is the emphasis on the abstract notion of weight as if it was enough to cover the essential of the process. In the discussion below, I expand on this point. Dominic Mayers (talk) 21:33, 21 June 2024 (UTC)

• I think this misses the point... Neither of those eras actually exist. There never was a time when the media didn't engage in partisan activism, it only seems that way to white men with money because thats the only POV which was presented before the current golden age of journalism (yes, we currenly live in a golden age of journalism, it has never been better). Horse Eye's Back (talk) 15:39, 20 June 2024 (UTC)
• I'm all for improvements to NPOV, but we've been trapped for a little while now in a cycle of unproductive discussion. Pick any random section currently at WT:NPOV and you're likely to land on an illustrative example. If anyone has a concrete change to the policy to suggest, I hope they'll do so, here or at the policy talk page. Firefangledfeathers (talk / contribs) 18:10, 20 June 2024 (UTC)

  I have a concrete change to the policy that is basically entirely unrelated to this thread. :P

  (It's "rename it". Specifically, rename it to Consensus Point of View or something similar, to avoid the common misconception that it endorses a view-from-nowhere.) Loki (talk) 18:28, 20 June 2024 (UTC)

  NPOV also is used to write and structure articles as to write in a neutral voice, and that should not be consensus driven compared to identifying sources are determining where the apparent viewpoints sit in terms of weight. — Masem (t) 18:32, 20 June 2024 (UTC)

  (edit conflict) Discussion about terminology in terms of the impression it creates on the public, which is different from a request for the meaning of a term for our own personal need in the discussion, is also not productive unless we have already an agreement about the concepts themselves. Dominic Mayers (talk) 18:36, 20 June 2024 (UTC)

  I don't think we ever will have an agreement about the concepts themselves, we'l have a consensus. Horse Eye's Back (talk) 21:32, 20 June 2024 (UTC)

  I only propose to try sharing our understanding. It will succeed at the least partially among rational people and that should result in a more interesting consensus. Dominic Mayers (talk) 22:07, 20 June 2024 (UTC)

  I would strongly object to shifting to a “Consensus Point of View”. One of the core elements of NPOV is that we don’t omit significant views, even if they are minority views. How we include them is open to discussion… whether to include them is not. Blueboar (talk) 18:50, 20 June 2024 (UTC)

  I would add to this that the problem that the suggestion tried to solve is not an important one. The problem arises only when we use the definite article "The" before "Neutral Point of View", because the question is then what is this unique point of view that seems to come from nowhere. It is a moot issue, because it is easy not to do that. It is only done once in the text of the policy and, if that is a big issue, it could be modified. I see the use of the definite article as a reference to some unity among rational people, some unique point of view that is a stance to adopt when we write the articles. We could replace "the neutral point of view" by "the policy", but we would lose the feeling of unity. Dominic Mayers (talk) 20:15, 20 June 2024 (UTC)

  Huge difference between “The” neutral POV and “A” neutral POV. In fact, the entire POINT is that there often isn’t one single POV, so we must discuss several. Blueboar (talk) 00:41, 21 June 2024 (UTC)

  The article must present all relevant points of view. These are sources' points of view that are described in the articles. But when the policy refers to the neutral point of view, it refers to something else. It refers to an editor's point of view, a point of view that is used to describe the points of view in sources. The use of the definite article in that case, only indicates a unity among the rational editors. It does not conflict at all with the POINT that there often isn't one single POV in sources. This can be explained by an example. Joe Blow, a source, says "Life is great". "Life is great" is a source point of view. The neutral point of view is "Joe Blow says Life is great". If there are many notorious and pertinent points of view in sources, the neutral point of view includes them all. Dominic Mayers (talk) 01:07, 21 June 2024 (UTC)

  (edit conflict) Asking for a conclusion before a discussion can conclude is how unproductive discussion starts. Dominic Mayers (talk) 18:30, 20 June 2024 (UTC)

I made an attempt at consolidating the many threads on this at Wikipedia talk:Neutral point of view#Consolidated discussion on wp:weight North8000 (talk) 19:38, 20 June 2024 (UTC)

• Again this is just a duplicate of the very long discussion at WT:NPOV. Going over the same points. I still see no reason to split it here. -- LCU ActivelyDisinterested «@» °∆t° 21:25, 20 June 2024 (UTC)
• This is why we use overview sources like books and literature reviews. If it's not in an overview source, you shouldn't include it unless you have a very good reason to. If there are no overview sources for the subject, then reconsider whether it needs an article. News media should be the last sources we consider after we've gone through the overview sources and academic journals and there are still gaps. If you're making heavy use of news media sources in your articles, then your articles might not be very well-sourced. Thebiguglyalien (talk) 23:05, 20 June 2024 (UTC)

Or the articles could be about something which while recent is notable... And the expectation is that in time the original news media sources will be replaced by higher more recent quality ones. There has never been a requirement that there be "overview sources" in any notability standard I am aware of. The opposite in fact... WP:NOTNEWS says "Editors are encouraged to include current and up-to-date information within its coverage, and to develop stand-alone articles on significant current events." Horse Eye's Back (talk) 23:27, 20 June 2024 (UTC)

There's a big gap between what's required and what makes a half decent article. Thebiguglyalien (talk) 23:36, 20 June 2024 (UTC)

Thats going to come down to what you think "a half decent article" is and I think you and I are likely in different neighborhoods there. For me a stub is half decent, a start is decent and it goes up from there. I would also note that because our current standards are based solely on existing coverage you could have a GA which used zero overview sources and academic journals if none then existed... But I don't think you actually meant by the consenus standard, I think you meant by your own ideosyncratic standard. Horse Eye's Back (talk) 23:42, 20 June 2024 (UTC)

I've written two essays explaining my thoughts on this in more detail: Avoid contemporary sources and The source, the whole source, and nothing but the source. Also, current GA standards require that there be no original research, which includes analysis of primary sources. Thebiguglyalien (talk) 16:49, 21 June 2024 (UTC)

I am not going to take the time to read those essays today, although I may in the future. Was there something I said which suggested that I was advocating for original research or is that a non-sequiter? Horse Eye's Back (talk) 16:52, 21 June 2024 (UTC)

I was looking at "you could have a GA which used zero overview sources and academic journals". If I was reviewing something like this at GAN, one of the first things I would check would be weight issues and whether the sources were used appropriately. It's certainly possible to have a well written article using only newspapers, but it's much more difficult, and I'd be looking to see whether the nominator used primary sources as an indication of weight, as opposed to just verifiability. Thebiguglyalien (talk) 16:59, 21 June 2024 (UTC)

And what does this response have to do with original research? Horse Eye's Back (talk) 17:07, 21 June 2024 (UTC)

...have you read our biographies? We likely have hundreds of thousands of articles on people sourced exclusively to news sources. It would be great if "4-sentence blurb from 1918 in local paper #1" + "5-sentence blurb from 1918 in local paper #2" wasn't a GNG pass, but that's exactly what gets through AfD all the time. JoelleJay (talk) 07:41, 21 June 2024 (UTC)

• There is a related discussion in the NPOV talk page. I think the NPOV talk page should be left alone until we are closer to some concrete changes. Here is the right place. North8000 proposed, as an example of a misuse of DUE, that the mention of a "Help Starving Children" program not discussed in secondary sources, should nevertheless be not rejected using WP:DUE from an article in which that program is alleged relevant, even though some editors feel it is a way to promote the current government. Following this, WhatamIdoing, avoiding the polemical aspect, said that, in general, we should be allowed to add normal information expected from an encyclopedia, i.e., ordinary facts (e.g., when and were a person was born) even if sources [centred on the topic] don't dwell on them at great length. Firefangledfeathers commented I agree about ordinary encyclopedic facts, though maybe it's a common enough caveat that it doesn't need to be mentioned here. There was then an emphasis on the distinction between not so basic info such as that one day when the factory exploded or the a company's product line and some basic information about when it was in existence, etc. Then Blueboar added that it depends on the topic of the article: Is it an article about a company, or an article about an explosion?. Dominic Mayers (talk) 16:11, 21 June 2024 (UTC)

  Here is my reply. A central point in that discussion is the distinction between basic and not basic information in the context of a given topic. The goal is to make sure that DUE cannot prevent us from adding basic information from reliable sources: we should not have to show that they have the required weight. This is an issue with DUE, but only a small part of a more global issue with DUE that I explored a bit with Masem (see above). The notion of basic information is not the most fundamental one. We must also consider attributions, arguments, etc. The reason why basic information are OK is that they are neutral. They do not take sides. Attributions, arguments, etc. are also ways to not take sides. Let me illustrate with an example, how the editorial process, which makes use of these added informations, is very important to create a good article that is coherent and not confusing. In the sources, we see that ExpertA says the number of immigrants is 10,000 and we also see that ExpertB says that it is 50,000. If the article stupidly says "The number of immigrants is 10,000. The number of immigrant is 50,000" that is just confusing. A good editorial process will carefully read the sources and find the arguments, etc. so that the whole thing is informative, factual and there is no contradiction. After having read more carefully the sources, the editors might write: "Using method A of evaluation, the number of immigrants is 10,000, but using method B it is 50,000". This is writing on the stance of the neutral point of view. Let me emphasis that weight has not entered into consideration in that process. More weight can be given to one side than the other in the final result, but the process itself is just a rational process that does not take sides. The process is not taking sides, even if at the end a method is shown factually to be less good. Even if one side is entirely dropped, after it has been given due weight in the editorial process, this is not taking sides. The key point is that the process often requires to add information and at that stage, as illustrated in the above example, the process should not be discussed only in terms of weight. There is way too much emphasis on weight in the current text of the policy and not enough on the need to add arguments, attributions, etc. Dominic Mayers (talk) 16:36, 21 June 2024 (UTC)

  Please Dominic, step out of the drivers seat on this. You've started so many non-concrete NPOV discussions across two separate pages, and now you're sabotaging one concrete one started by another editor. I welcome your thoughts, even when I can't understand them, but why not let other participants lead the way for a while? Firefangledfeathers (talk / contribs) 17:00, 21 June 2024 (UTC)

  I think I am saying something very important in terms of the NPOV policy here. As far as my opinion regarding where the discussion should occur, it is just that I really cannot discuss in the NPOV talk page, because I do not think it is fine to have these long discussions over there, and therefore I reply here to say what I think is very important. And I am not sabotaging any discussion. On the contrary, I participate in the discussion here and I publicize it by making a summary, etc. Dominic Mayers (talk) 17:15, 21 June 2024 (UTC)

  I’m not sure I understand very well what’s being discussed here; but I found the language / words used in the “summary” above not very neutral ... --Dustfreeworld (talk) 20:44, 21 June 2024 (UTC)

  I did my best to be neutral. Please tell me how it can be improved. I have no interest in not making a good summary: it is so easy to get to the original with the link provided. Also saying we understand nothing is not helpful in the discussion and it cannot be true. I don't buy it. It sounds more like a fallacious way to win the arguments. Dominic Mayers (talk) 21:40, 21 June 2024 (UTC)

References

• Question: When we talk about the DUEness of “basic information” are we discussing RELEVANCY (ie, should article X mention factoid Y?) or are we discussing situations where sources disagree on relevant facts (source X says “sales = 5 million”, but source Y says “sales = 7 million”)? Blueboar (talk) 16:51, 21 June 2024 (UTC)

  I generally understand people to mean everything under the WP:NPOVHOW heading when they say "due". WP:DUE is technically one subsection of that, but people generally use it to many any or all of those things. Thebiguglyalien (talk) 17:07, 21 June 2024 (UTC)

  And that may be part of the problem here… we all mean different things when we say something is DUE/UNDUE. Perhaps it would help if we coined new wiki-jargon terms to help us differentiate what we are talking about. Lumping it all under DUE is just confusing everyone. Blueboar (talk) 18:25, 21 June 2024 (UTC)

  The problem is not terminological. The concepts themselves need to be better understood. I want to point out something that might shed some light on the problem. The expression "due weight" is also used to describe how a judge in a court of law must consider the facts and arguments. In many cases, if not all cases, it does not refer to the final ruling. It refers to the attention given to the facts and the arguments. So, when a judge does not accept the conclusion of an argument, it does not mean that the judge did not give due weight to the argument. Of course, there will be a ruling in some direction, but due weight refers to the process, not to the final ruling. I feel this is a much more realistic concept, because the ruling itself is way too complicated and depends on so many factors. The important is that it is the outcome of a process that gave due weight to the arguments and facts. In Wikipedia, if my understanding is correct, it refers to the weight given to a POV in the article. It is also a useful concept, but it is not sufficient, because it does not deal enough with the process, including what information might need to be added. That is why I feel we put too much attention on that concept in the policy. There is a lot of distinctions, BALANCE, BALASP, etc. but the fundamental difficulty remains: how to evaluate the weight? it does not cover the process, including what kind of information might need to be added. Dominic Mayers (talk) 18:45, 21 June 2024 (UTC)

  It certainly applies to situations where sources disagree: we must give due weight to both. Relevancy is certainly a factor to consider to give due weight: the editorial process must give due weight to every point of view and the outcome will depend on relevancy to the topic. I think your question is what if there is only one point of view and we ask if it is relevant. Is this an aspect covered by DUE ? I think DUE applies as well in this case, for the same reason, because there is this point of view and the rest of the article. Dominic Mayers (talk) 18:24, 21 June 2024 (UTC)

• Ok… I have to bow out for a while here. We all (including me) seem to be discussing different things. It’s clear that we all think “something needs fixing at WP:DUE”… but I don’t see any agreement on what that “something” actually is. If I’m confused, my continued involvement will just add to the confusion. I will rejoin once I am clearer on what we are actually discussing. Have fun storming the castle! Blueboar (talk) 22:21, 21 June 2024 (UTC)

  Yes, we are discussing different things. Some want to discuss due weight within some view of what it is. I am not rejecting that view, but I am questioning the need to further discuss and expand on due weight under that view, because the policy has already way too much expanded on it with all its subsections. Dominic Mayers (talk) 22:55, 21 June 2024 (UTC)

Technical

Heading markup changes

The HTML used to render all headings is being changed to improve accessibility. It will change on 22 May in some skins (Timeless, Modern, CologneBlue, Nostalgia, and Monobook). Please test gadgets on your wiki on these skins and report any related problems so that they can be resolved before this change is made in all other skins. The developers are also considering the introduction of a Gadget API for adding buttons to section titles if that would be helpful to tool creators, and would appreciate any input you have on that.

MediaWiki message delivery 23:01, 20 May 2024 (UTC)

Based on a quick search, it looks like the heading change will affect almost 300 scripts, many of which have inactive maintainers. Some arbitrary highlights from the top of the list include:

• Awesome Aasim's User:Awesome Aasim/rcpatrol.js
• BrandonXLF's User:BrandonXLF/FFUHelper.js
• Cacycle's User:Cacycle/wikEd.js, User:Cacycle/wikEd dev.js, and User:Cacycle/wikEd.user.js
• DannyS712's User:DannyS712/DiscussionCloser.js, User:DannyS712/SectionRemover.js, and User:DannyS712/SectionMover.js
• Enterprisey's User:Enterprisey/reply-link.js, User:Enterprisey/copy-section-link.js, User:Enterprisey/archiver.js, User:Enterprisey/strike-archived.js, User:Enterprisey/section-watchlist.js, and User:Enterprisey/section-redir-note.js
• Equazcion's User:Equazcion/OneClickArchiver.js, User:Equazcion/TeahouseRespond.js, and User:Equazcion/NewSectionSummary.js
• Evad37's User:Evad37/OneClickArchiver.js and MediaWiki:Gadget-XFDcloser-core.js
• Mr. Stradivarius's User:Mr. Stradivarius/gadgets/SignpostTagger.js
• PhantomTech's User:PhantomTech/scripts/AFCRHS.js
• SD0001's User:SD0001/RFUD-helper.js
• Terasail's User:Terasail/COI Request Tool.js
• Technical 13's User:Technical 13/Scripts/OneClickArchiver.js
• The Earwig's User:The Earwig/permalink.js and User:The Earwig/afc-helper.js
• The Evil IP address's User:The Evil IP address/hdedit.js

Plus many, many more. --Ahecht (TALK
PAGE) 19:22, 21 May 2024 (UTC)

A quick way to test these scripts right now, is to enable the Parsoid beta option (which already uses the new html structure) and to disable DiscussionTools, which uses a partial form of the new heading structure. —TheDJ (talk • contribs) 08:39, 22 May 2024 (UTC)

Indeed, you can already see it in Parsoid mode (but note that there are other differences – e.g. Parsoid output has <section> tags around each section, which may require a separate set of updates in some scripts).

Disabling DiscussionTools doesn't actually change anything though. The HTML structure is the same whether it's enabled or disabled, only the styles are different. Also, note that it uses a "hybrid" heading structure currently when using the default parser, as you say, but it uses the new structure when using Parsoid.

So in short, you can just use Parsoid mode to test these scripts today here on English Wikipedia, but beware that there may be extra issues. But if they work with Parsoid, they will work with the new headings too. Matma Rex talk 11:25, 22 May 2024 (UTC)

The technical 13 script was blanked, so we don't have to worry about that one.

Will the fact that they're rolling this out for only some wikimedia-deployed skins at this time make the patch more complicated? If I'm reading it right, the scripts may temporarily have to support both heading styles. –Novem Linguae (talk) 09:16, 22 May 2024 (UTC)

Yes, it does, and they have to. Matma Rex talk 11:20, 22 May 2024 (UTC)

At a glance, it seems that User:Mr. Stradivarius/gadgets/SignpostTagger.js already supports the new style, as it uses $( '#bodyContent h2:first' ).text() as a backup if $( '#bodyContent h2:first span.mw-headline' ) doesn't exist (line 291). — Mr. Stradivarius ^{♪ talk ♪} 13:09, 22 May 2024 (UTC)

Fixed RFUD-helper. Thanks for the ping. – SD0001 (talk) 18:33, 22 May 2024 (UTC)

This is going to break both my edit request scripts, I will try to fix them at the weekend. Terasail^[✉️] 18:41, 22 May 2024 (UTC)

I've fixed my fork of the OneClickArchiver script (though now it only works with the new format; I don't care enough to get it working with both). Elli (talk | contribs) 02:09, 8 June 2024 (UTC)

And copy-section-link too (same caveat). Elli (talk | contribs) 02:16, 8 June 2024 (UTC)

Another one: User:Σ/Testing_facility/Archiver.js. Izno (talk) 00:45, 7 June 2024 (UTC)

And a couple other gadgets still remaining:

• MediaWiki:Gadget-PrintOptions.js
• MediaWiki:Gadget-ptoc.js
• MediaWiki:Gadget-teahouse/content.js

Izno (talk) 00:51, 7 June 2024 (UTC)

Gadget-teahouse is no longer used now that DiscussionTools has been rolled out. Pinging @Prtksxna and @TheDJ for the other two. --Ahecht (TALK
PAGE) 15:54, 12 June 2024 (UTC)

Σ's Archiver script has been superseded by forks. See subsection just below: #Tech News – User:Enterprisey/archiver.js. —⁠andrybak (talk) 01:19, 7 June 2024 (UTC)

I had no idea that one had gotten forked. Izno (talk) 01:24, 7 June 2024 (UTC)

Gadget-autonum (Auto-number headings)

I'm assuming ~ and feel free to correct me if i'm wrong ~ that something about this deployment is why headings no longer have numbers (for me)? Will it be possible to go back to that at some point? I find long pages almost impossible to navigate around without numbered headings, so will have to learn a new way of working if it won't be possible. Thanks, Happy days, ~ Lindsay^Hello 16:24, 27 May 2024 (UTC)

@LindsayH: No, that was removed a while ago. You may try the "Auto-number headings" gadget here. Nardog (talk) 19:31, 27 May 2024 (UTC)

If you're speaking about the table of contents, Vector 22 does not provide numbering. Vector, Monobook, and Modern do.

If you are speaking about each actual heading, then indeed the preference is gone and indeed there is a gadget for it now. You have correctly identified that gadget as needing to be updated for this change. It looks like the necessary change to the snippet (documentation) has already been made, so someone needs to port that here. Izno (talk) 19:59, 27 May 2024 (UTC)

Thank you, Izno, helpful. I'd assumed it was a script/gadget, as so many appeared to be affected above. I shall patiently wait in hope Happy days, ~ Lindsay^Hello 11:51, 28 May 2024 (UTC)

@LindsayH. I think I fixed this gadget for monobook/timeless/modern with this update. But there is still a double number bug on some talk pages on vector/vector-2022. Will work on that next. –Novem Linguae (talk) 16:50, 1 June 2024 (UTC)

You star! Thanks for the notification (and, of course, for fixing it). Happy days, ~ Lindsay^Hello 06:14, 2 June 2024 (UTC)

Tech News – User:Enterprisey/archiver.js

I've been testing my fork of Enterprisey's script – User:Andrybak/Archiver. Example edits: 1226884323, 1227442551, 1227443165, 1227444165. So far, the script doesn't seem to be affected. —⁠andrybak (talk) 19:21, 5 June 2024 (UTC)

✅ Another successful test with random things (including cases, which were mentioned in bug reports): Special:Diff/1227451320. —⁠andrybak (talk) 21:33, 5 June 2024 (UTC)

Did you try all the old skins such as Timeless and Monobook? Vector isn't affected at all yet, and editing likely uses the API, but I can imagine the location of the header links this script places being possibly broken in old scripts. I fixed this kind of thing in 2 gadgets so far. –Novem Linguae (talk) 22:15, 5 June 2024 (UTC)

I know that Σ's User:Σ/Testing facility/Archiver supported at least Timeless: User talk:Σ/Archive/2021/January#Archy McArchface button caption in Timeless, so I expect Enterprisey's version to have remained compatible with other skins.

Good shout.  Checking... —⁠andrybak (talk) 22:28, 5 June 2024 (UTC)

Facepalm argh, I didn't read past the first sentence. My bad. Thank you, Novem Linguae, for pointing it out. —⁠andrybak (talk) 22:44, 5 June 2024 (UTC)

Novem Linguae, support for MonoBook and Timeless has been added: Special:Diff/1227543602. —⁠andrybak (talk) 11:22, 6 June 2024 (UTC)

Tests on real discussions: MonoBook, Timeless, Vector 2010, Vector 2022. —⁠andrybak (talk) 11:47, 6 June 2024 (UTC)

New h2 headings use serif font even when the "Vector classic typography" gadget is enabled

Vector classic typography is a gadget that forces all text to use sans-serif fonts, but even with the gadget enabled h2 headings on articles use a serif font. Incorrect behavior seen on both Firefox and Edge. TomatoFriesLAN (talk) 18:51, 6 June 2024 (UTC)

@TomatoFriesLAN Thanks for reporting, this is caused by the heading changes announced two weeks ago, which were deployed to legacy Vector as well this week. This edit should fix it: [6] – please try now. Matma Rex talk 20:27, 6 June 2024 (UTC)

Works, good job. TomatoFriesLAN (talk) 03:53, 7 June 2024 (UTC)

XFDcloser

I usually spend part of the day closing AFD discussions but none of the XFDcloser options are showing up. Not even the ability to relist. I've uninstalled every installation, unchecked the XFDcloser gadget, returned everything to normal but nothing works. Do I have to reboot my computer or something? Log out and log back in? This rarely happens so I'm not sure what happened today. I've posted a message on the XFDCloser talk page but it doesn't get much activity there. Liz ^{Read! Talk!} 23:26, 6 June 2024 (UTC)

It's not an XFDC issue, it's a THURSDAY issue. Primefac (talk) 00:35, 7 June 2024 (UTC)

Izno, I see you've moved this section, and it does appear to be mentioned in the original post of this threading, but why would it only appear now? I seem to recall closing discussions earlier this week (and I suspect Liz has as well). Primefac (talk) 01:17, 7 June 2024 (UTC)

I mean, it could not be this, and you're welcome to move it back, it just has the smell. Izno (talk) 01:24, 7 June 2024 (UTC)

I patched xfdcloser a couple days ago, so a new bug today is probably something else. Will take a look. –Novem Linguae (talk) 02:52, 7 June 2024 (UTC)

Well, I thought this thread was deleted until I found it reposted up here.

It's odd because XFDCloser was working fine this morning and then this afternoon, it just didn't load at all. But I see other editors closing discussions so I hope it isn't just me. I've had ongoing problems with XFDCloser not loading on CFD pages but it hasn't been a problem on AFD daily logs until today. Thanks for checking Novem Linguae, there are usually over 100 AFD discussions daily so if this is happening for other closers, they could pile up pretty quickly. If it matters, I use a laptop with Windows. Liz ^{Read! Talk!} 03:17, 7 June 2024 (UTC)

It's still working in Vector 2022, so changing your preferences temporarily is a workaround. Hopefully the issue will be fixed soon. Extraordinary Writ (talk) 03:39, 7 June 2024 (UTC)

I figured out the cause. I should have a fix deployed soon.

For the record, it looks like WMF deployed mw:Heading HTML changes to old skins (monobook, timeless, modern, cologneblue) last week, vector (2010) this week, and probably minerva and vector-2022 in the coming weeks. All breakages we see today will probably be vector (2010) only.

This staggered deployment has pros and cons. It means that if someone like me does fix a bunch of gadgets today, I'll just have to go fix them all again next week when they break on vector-2022.

It would be nice if there were an API for inserting header links. phab:T337286. APIs like mw.util.addPortlet(), mw.util.addPortletLink(), etc are great for multi-skin support and for keeping HTML changes from breaking gadgets and user scripts. –Novem Linguae (talk) 05:43, 7 June 2024 (UTC)

Yeah, I don't understand all of this jargon but I am FOREVER grateful that their are editors who do. Thanks for looking into this. Liz ^{Read! Talk!} 06:33, 7 June 2024 (UTC)

Fix deployed for XFDcloser. Should be fixed within the next 15 minutes (gadget code is cached for up to 15 minutes). –Novem Linguae (talk) 06:35, 7 June 2024 (UTC)

I see I did use Vector Legacy 2010. I don't like for page formatting and white space of the updated Vector 2022. Liz ^{Read! Talk!} 06:37, 7 June 2024 (UTC)

I also use Vector 2010. Best skin :) –Novem Linguae (talk) 06:38, 7 June 2024 (UTC)

I am looking forward to Vector 2034 — GhostInTheMachine ^{talk to me} 06:51, 7 June 2024 (UTC)

Yeah, and I don't like the left-side menu. But thanks Novem Linguae, it looks like things are now back to normal. I can go back to my old skin! Many thanks. Liz ^{Read! Talk!} 07:24, 7 June 2024 (UTC)

Novem Linguae, XFDCloser disappeared again! I think you said this might happen. It came back when I changed to Vector 2022 but, ugh! I guess I'll use that skin when working in AFDLand and then change back when doing regular editing. Liz ^{Read! Talk!} 22:15, 8 June 2024 (UTC)

I'm trying out Timeless. It's not as bad as Vector 2022. Liz ^{Read! Talk!} 22:32, 8 June 2024 (UTC)

But it doesn't work with Twinkle. Liz ^{Read! Talk!} 01:53, 9 June 2024 (UTC)

Well, XFDcloser returned to operational status. Thanks to whomever fixed that. Liz ^{Read! Talk!} 03:13, 9 June 2024 (UTC)

Very strange. I haven't done any work on XFDcloser since the last deploy on Thursday, and I don't see any relevant backport patches at wikitech:Server Admin Log that might have changed MediaWiki behavior this weekend. This is all quite mysterious. –Novem Linguae (talk) 08:56, 9 June 2024 (UTC)

Novem Linguae, it's just happened again, over the span of the past hour! This is getting annoying to have to keep changing skins. Liz ^{Read! Talk!} 23:31, 12 June 2024 (UTC)

@Liz. I deployed a fix related to the beta version of XFDcloser. Can you try Vector again and let me know if things are fixed? –Novem Linguae (talk) 00:48, 13 June 2024 (UTC)

User script that puts a ¶ symbol next to headings

What's the user script or gadget that puts a ¶ symbol next to headings, and when you click on it, it opens a modal with links to that section that you can copy/paste? It broke for me today and I want to fix it, but can't remember what it's called. Thanks. –Novem Linguae (talk) 03:35, 7 June 2024 (UTC)

Is it User:Enterprisey/copy-section-link? Sounds like what you described, but I don't see where you have it imported. – 2804:F14:809B:2701:19B4:583A:7C56:999F (talk) 04:22, 7 June 2024 (UTC)

Ah, it's in my global.js. No wonder I couldn't find it. Thank you very much for this link. –Novem Linguae (talk) 06:37, 7 June 2024 (UTC)

I wrote a script that provides links to user comments as well as headings, which I updated to support both the new and legacy methods of marking up headings. Its interface is a bit different though from the copy-section-link script. isaacl (talk) 06:23, 7 June 2024 (UTC)

I can't find where the script is putting the link(s) on Vector 2010. Any hints? –Novem Linguae (talk) 07:04, 7 June 2024 (UTC)

The function showCommentLinks() (starting on line 73) adds the links. The section of code starting at line 84 finds headings in the HTML document structure previously generated by MediaWiki (which I believe is the same across skins). The section of code starting at line 93 finds headings in the currently generated HTML document structure. isaacl (talk) 15:27, 7 June 2024 (UTC)

I was hoping you'd just tell me where the links are. lol. Anyway, I put a breakpoint on line 75 and the breakpoint is not getting hit when I refresh this page. I'm missing something. –Novem Linguae (talk) 20:33, 7 June 2024 (UTC)

I'm sorry, I didn't realize you were asking about the interface. As described in the documentation, you have to select the "Toggle link2clipboard" item in the tools menu (the location of the menu depends on your skin; for Vector 2010 it's in the left sidebar). </> is prepended to the start of each comment. For headings, <h/> is also prepended. Most of the time I don't want to see the links, so I chose to require an extra step to display them. Another difference from the other script is that for the major non-Safari browsers, the link text is automatically copied to the clipboard (always without surrounding square brackets; the other script can be configured not to do that if desired). isaacl (talk) 20:51, 7 June 2024 (UTC)

Nice, that worked. Thanks a lot. Feature idea: Add a way to copy it as an external link. I do this a lot when writing GitHub or Phabricator tickets, for example. –Novem Linguae (talk) 20:59, 7 June 2024 (UTC)

As my personal frequent use case is to link to comments or sections in wikitext, I wanted a way that would provide easy access to the link without underscores ;-) (And I chose to avoid square brackets as it's easier to add them when needed than delete them, and I like to use {{section link}} when feasible.) I'll take it under consideration, though; thanks for the feedback! isaacl (talk) 21:08, 7 June 2024 (UTC)

@Novem Linguae: I made a copy of Enterprisey's script with this fixed, if you'd like to switch to it: User:The Earwig/copy-section-link.js. — The Earwig (talk) 03:37, 20 June 2024 (UTC)

And I've just been informed that Enterprisey has replicated the fix to his version. — The Earwig (talk) 03:45, 20 June 2024 (UTC)

Section header typeface

I just noticed that section headers in articles are now using a serif typeface on both Vector and Vector legacy. Sorry I couldn't find information about this elsewhere but when and why was this change made? I do not like that it uses Oldstyle figures and would like to change it in my settings or .css page to be the same sans serif font used in other headers. Thanks! Reywas92^Talk 17:23, 7 June 2024 (UTC)

@Reywas92 Vector headers have actually been using serif fonts by default for a long time, but you have user CSS which was overriding that. It no longer works due to some changes to heading HTML. You can either change that part of your user CSS to:

h1, h2, .mw-heading1, .mw-heading2 {
    font-family: inherit !important;
}

Or alternatively just use the gadget "Vector classic typography" which has already been fixed. the wub "?!" 19:25, 7 June 2024 (UTC)

Thank you! Forgot they did that a decade ago, these numerals are awful. Reywas92^Talk 20:23, 7 June 2024 (UTC)

One click archiving not working?

I have been using User:Evad37/OneClickArchiver for some time, but I noticed the other day that the archiving links are no longer appearing for me. Anyone know why that might be? Just Step Sideways ^{from this world ..... today} 18:06, 9 June 2024 (UTC)

Just Step Sideways, see § Heading markup changes. I believe User:Andrybak/Archiver is a working fork. — Qwerfjkltalk 18:08, 9 June 2024 (UTC)

Thanks for the pointer! I guess I'm off to install that. Just Step Sideways ^{from this world ..... today} 18:13, 9 June 2024 (UTC)

Well, that works, but it certainly isn't "one-click". Oh well. Just Step Sideways ^{from this world ..... today} 18:17, 9 June 2024 (UTC)

Just Step Sideways and Qwerfjkl, there are two kinds of scripts, which make semi-automatic archiving easier. Page Wikipedia:One click archiving lists User:Evad37/OneClickArchiver as the most recent script for "One click archiving". My User:Andrybak/Archiver is the latest for "Multi-section archiving". —⁠andrybak (talk) 18:28, 9 June 2024 (UTC)

I didn't mean to disparaige your script,it works just fine, while currently, the Evad one does not. Just Step Sideways ^{from this world ..... today} 18:44, 9 June 2024 (UTC)

No disparagement taken. From Qwerfjkl's reply it might seem like User:andrybak/Archiver is a fork of User:Evad37/OneClickArchiver, but it's not. I just wanted to ensure there's no confusion about that. —⁠andrybak (talk) 18:49, 9 June 2024 (UTC)

Apologies, my mistake. — Qwerfjkltalk 19:30, 9 June 2024 (UTC)

It looks like Elli and FlightTime have recently worked on their copies of OCA. Are yours functioning in the new structure? Izno (talk) 21:00, 9 June 2024 (UTC)

Yep, mine works :) Elli (talk | contribs) 21:05, 9 June 2024 (UTC)

Elli, please consider adding your script to Wikipedia:One click archiving and Wikipedia:User scripts/List#Discussions 3. —⁠andrybak (talk) 21:57, 9 June 2024 (UTC)

I've now done so. Elli (talk | contribs) 22:07, 9 June 2024 (UTC)

@Just Step Sideways ^ Izno (talk) 22:06, 9 June 2024 (UTC)

Nice, just installed it works great. Thanks all. Just Step Sideways ^{from this world ..... today} 17:19, 10 June 2024 (UTC)

Neat! I came to VPT just to browse, and not even 10 sections in, I learned of a script that deals with the new header markup. Rusty4321 ^{talk contribs} 01:34, 14 June 2024 (UTC)

OneClickArchiver disappeared...Answers found here

Very handy gadget for manual-archiving - User:Evad37/OneClickArchiver.js - but it isn't showing up today on any talk pages for me. Don't know why, the script is still sitting on my common.js page. Has it been disabled/usurped by a better gadget? Why isn't it showing up?... Help please & thanks, Shearonink (talk) 14:48, 15 June 2024 (UTC)

Ok so after posting the above query I have now read through some of the other threads about archiver scripts... Is there a present script or fork that works on individual sections/posts/threads like Evad37's used to do? Shearonink (talk) 14:54, 15 June 2024 (UTC)

Forgot to add...I am editing with Vector 2010 original/legacy if that make a difference. Shearonink (talk) 14:57, 15 June 2024 (UTC)

For anyone who is as much of a non-adept at code & tech stuff around here and has Evad37's one-click oneclick one click archive script installed, and wants the same functionality, do the following:

• go to the Wikipedia:One click archiving page.
• navigate to Wikipedia:One click archiving#One click archiving (1CA) section.
• See User:Elli/OneClickArchiver listed there? It is an updated 2024 script that is maintained and fixes some issues with Evad37's script (having to do with the 'Heading markup changes' mentioned at the top of this page.
• Follow the instructions at the User:Elli/OneClickArchiver page.
• Yay! You made it. - Shearonink (talk) 15:49, 15 June 2024 (UTC)

Broken template in Vector 2010

It would appear that these recent changes have broken Evad37's WP:Highlight duplicate links script in Vector 2010, which now no longer distinguishes between repeated links in the lead section and repeated links in the article body. ‑‑Neveselbert (talk · contribs · email) 18:20, 14 June 2024 (UTC)

Script works for me. What kind of skin are you using ? —TheDJ (talk • contribs) 18:41, 14 June 2024 (UTC)

Oh lol, it was in the title :) Anyway. works with vector 2010 for me. —TheDJ (talk • contribs) 18:42, 14 June 2024 (UTC)

This seems unrelated. Should be moved out to its own section. Nothing has changed in Vector 2010 skin. 🐸 Jdlrobson (talk) 20:01, 14 June 2024 (UTC)

@TheDJ and Jdlrobson: On Elizabeth II, using Vector 2010, the script highlights links in the lead section which shouldn't be highlighted, as they're not repeated in the lead section, and highlights links (in red) that are the first instances of those links in the article body. This does not occur in Vector 2022. ‑‑Neveselbert (talk · contribs · email) 22:49, 14 June 2024 (UTC)

This is indeed caused by mw:Heading HTML changes. I think this needs to be fixed in User:Evad37/duplinks-alt.js. It should be sufficient to replace this line:

if (this.nodeName.toLowerCase() == 'h2') {

with this:

if ( $(this).is('h2, .mw-heading2') ) {

(cc @Evad37) Matma Rex talk 08:46, 15 June 2024 (UTC)

I made an edit request: User talk:Evad37/duplinks-alt.js#Update for mw:Heading HTML changes Matma Rex talk 17:03, 18 June 2024 (UTC)

help desired

Real life has kept me away for the better part of a fortnight; I really shouldn't be taking the time to write this...

I have a script User:Trappist the monk/HarvErrors.js that is a tweaked copy of User:Ucucha/HarvErrors.js. Some of those tweaks were my own to turn down the glare of the red error messages that Ucucha's script produced. At some point someone asked me for further tweaks. What I know about javascript can be put in a thimble so I had to rely on the expertise of other more javascript fluent editors.

My script may have become broken because of the mw:Heading HTML changes. I suspect that the broken code is at lines 46–48. The code is supposed to make three separate lists of references found in each of an article's §External links, §Further reading, and §Publications sections. The purpose of that is to suppress the error messaging that would occur if any reference in those sections duplicates or can be linked from a short-form reference ({{sfn}} and the like).

With my script installed for example, this version of Rudolf Roessler (permalink) shows Harv error: linked from CITEREF... for every reference in (§Bibliography (permalink)). Those were 'fixed' by renaming §Publications to §Works (diff).

Is there anyone out there who would be willing to show me how to fix the issue? Because I'm not really here for the time being, a post on my talk page will find me via an email notification from MediaWiki.

Thank you.

—Trappist the monk (talk) 17:05, 19 June 2024 (UTC)

@Trappist the monk I'm not sure if I understand exactly what the script should do, however, I think it may be enough to add .mw-heading2 to the selectors in those 3 lines, like this:

		var further_reading = $content.find('#Further_reading').parent().nextUntil('h2, .mw-heading2').find('.citation').get();	// get all cites inside a Further reading section
		var external_links = $content.find('#External_links').parent().nextUntil('h2, .mw-heading2').find('.citation').get();		// get all cites inside a External links section
		var publications = $content.find('#Publications').parent().nextUntil('h2, .mw-heading2').find('.citation').get();			// get all cites inside a Publications section

Matma Rex talk 17:25, 19 June 2024 (UTC)

@Matma Rex: Ding! Ding! Ding! That works though I don't understand why it works. Thank you.

—Trappist the monk (talk) 13:56, 21 June 2024 (UTC)

The HTML nesting of headings changed recently. The fix done above is to check for both the old and the new selector (h2, .mw-heading2), until all skins are switched over in a couple weeks, at which point just the new selector can be used. –Novem Linguae (talk) 21:02, 21 June 2024 (UTC)

Gadget for unsupported titles

Would people be open to deploying a gadget similar to wikt:MediaWiki:Gadget-UnsupportedTitles.js on the English Wikipedia? The code there is somewhat specific to Wiktionary, but the idea is that pages like https://en.wiktionary.org/wiki/:%7C get JavaScript redirected to pages describing the characters in question, and it also uses JavaScript to fix the H1. I personally care less about the second issue than the first one, and would like to enhance it further so things like Building#19 get redirected to Building No. 19 rather than a nonexistent anchor in building. That part could be done using a template gadget that only loads on pages transcluding {{technical reasons}}. Not sure if the first part is feasible that way yet. * Pppery * _{it has begun...} 04:10, 11 June 2024 (UTC)

I pretty strongly believe that page titles should display the page title as accessible by the URL, regardless of whether that's the best title. Izno (talk) 06:27, 11 June 2024 (UTC)

That's not what's proposed. Pppery clearly say they "personally care less about" ... "us[ing] JavaScript to fix the H1". – SD0001 (talk) 07:20, 11 June 2024 (UTC)

If it's what e.g. isaacl came to, then I do probably still oppose implementation - fighting with MediaWiki over just how to navigate to a page sounds like a pure lose lose situation. Izno (talk) 15:54, 11 June 2024 (UTC)

It's a "pure lose lose" situation that readers get to read about Building #19 when they search for Building #19? Don't overuse hyperbole – it spoils its impact when actually needed. – SD0001 (talk) 17:03, 11 June 2024 (UTC)

No, I'm not being hyperbolic. Please don't be a dick. I sincerely don't think there's a win to "let's fuck around with anchors". Izno (talk) 23:24, 11 June 2024 (UTC)

mediawiki.action.view.redirect.js – MediaWiki has for decades, to use your language, fucked around with anchors (to resolve sections links on redirected pages). You not thinking it's a win does not mean it's suddenly considered a bad practise. – SD0001 (talk) 15:37, 12 June 2024 (UTC)

Not sure if the first part is feasible that way yet. It won't be feasible with a template gadget, but it would have been if phab:T241524 had been implemented instead, as you could inject the parser tag into the noarticletext interface message. – SD0001 (talk) 07:25, 11 June 2024 (UTC)

Did you mean MediaWiki:Badtitletext? I don't see how you could end up at noarticletext instead - it's been standard practice for longer than I've been editing to create redirects like Gunnin' for That -> Gunnin' for That No. 1 Spot where the title would otherwise be red. * Pppery * _{it has begun...} 14:48, 11 June 2024 (UTC)

Yeah that one. – SD0001 (talk) 15:20, 11 June 2024 (UTC)

We probably can add logic to MediaWiki:Badtitletext to at least show a "did you mean" for that case, though. * Pppery * _{it has begun...} 15:22, 11 June 2024 (UTC)

I've done that for now. Still think a gadget would be nice there, though, but it's probably not practical. * Pppery * _{it has begun...} 17:31, 11 June 2024 (UTC)

Wait a minute, turns out I'm wrong. Putting the interface message in the category does have the desired effect, even though it doesn't (obviously) cause pages using the message to show up in the category. – SD0001 (talk) 20:41, 11 June 2024 (UTC)

I don't think we should do this as a default gadget. — xaosflux ^Talk 09:44, 11 June 2024 (UTC)

I agree that work along these lines would be better implemented as a core feature rather than a gadget. I also don't like trying to redefine how URLs with fragment IDs work. It makes the behaviour non-standard and so the advantage of readers leveraging their experiences with the rest of the web is diminished. isaacl (talk) 15:34, 11 June 2024 (UTC)

It's a common pattern for fragment ids to redefine page content. SPAs wouldn't be possible without that. – SD0001 (talk) 17:03, 11 June 2024 (UTC)

(SPA = single-page application). * Pppery * _{it has begun...} 17:31, 11 June 2024 (UTC)

And the goal of Wikipedia is to educate people about the topic they are looking for, not preach about unrelated topics like how web apps work. * Pppery * _{it has begun...} 17:31, 11 June 2024 (UTC)

Didn't say anything about preaching. Just saying that following common web patterns means people know what to expect. A web page-based app uses a fragment ID to access a subresource of the page, as intended. Redefining the syntax to redirect to a completely different page is a different model. Sure, it can be done, but it's something unexpected. isaacl (talk) 00:49, 12 June 2024 (UTC)

And my point is that fact is irrelevant in almost all contexts, and it's unnecessary preaching to convey that point instead of taking people where they clearly want to be taken. But whatever, it's clear that, for reasons that make no sense to me, this is being shot down and we're instead choosing to deliberately get in people's way. * Pppery * _{it has begun...} 01:03, 12 June 2024 (UTC)

The majority of readers reach Wikipedia via search engines. Making it easier for search engines to know the right index phrases for an article will help readers the most, as most of them pay little attention to the characters in the URL. (For those that do, personally I'd rather not defy their expectations by showing a page with a title that differs from what appears before the URL fragment ID.) isaacl (talk) 01:40, 12 June 2024 (UTC)

I don't really like this idea. What good is having the page under an invalid title if you can't link to it (except as an external link)? All kinds of other interfaces also won't work or will display a different title as a result (e.g. what links here, watchlist, page view counts…). Matma Rex talk 20:56, 12 June 2024 (UTC)

I agree with Matma Rex. This kind of reminds me of phab:T315893 and phab:T338151, which I am also disinclined to support. We should keep all the various systems (what links here, watchlist, page view counts, wikilinks, how the title displays when loading the page) in sync with each other, and try to avoid adding more complexity than what we already have (the redirect system, CirrusSearch accepting case insensitivity, unnecessary space character in mobile talk page titles, etc.). By continuing to pile on complexity to the title system, I see a lot of potential for technical debt here. Debugging becomes difficult as the system gets so complex that few can wrap their head around the entire thing. –Novem Linguae (talk) 21:48, 12 June 2024 (UTC)

This system thinking is exactly what is needed across the wiki. But to the point, I agree it should apply here. All the best: Rich Farmbrough 23:26, 16 June 2024 (UTC).

Thursday 13 June style changes

Update: The images problem was resolved on Tuesday 19th, the changed styling of infoboxes and hatnotes was reverted on Fri 14th

Infobox problems

Tracked in Phabricator
Task T367462

I am not seeing infobox borders anymore (at Walter Cronkite and Google for example). Is that a "me" issue, or is something broken? (I am on Debian/Firefox, so it might very well be a "me"/specific issue.)

On Android (both app and Firefox) everything seems normal. JackTheSecond (talk) 19:08, 13 June 2024 (UTC)

Same here. Also, my search box now disappeared! Martinevans123 (talk) 19:13, 13 June 2024 (UTC)

In My Preferences, Vector legacy (2010) restores my search box, Vector (2022) removes it. Perhaps coincidental/ unrelated. Martinevans123 (talk) 20:44, 13 June 2024 (UTC)

Consider starting a new section for that. I have no idea what could be causing it. Izno (talk) 20:51, 13 June 2024 (UTC)

 Done Have started a new thread. Thanks. Martinevans123 (talk) 21:10, 13 June 2024 (UTC)

The infoboxes look different for me as well, starting recently. But I'm not sure it's a technical problem, it could be a recently released change? Simeon (talk) 19:14, 13 June 2024 (UTC)

I have the same thing. On further investigation, it only affects me on Vector 2022 and not on any other skins. If it's a change to the skin, it's also broken some images in infoboxes and sidebars. The images seem to have either shrunk considerably at their default size, stopped loading or completely disappeared. Examples include: Next Senedd election, 2024 United States presidential election, Template:Donald Trump series, Template:Joe Biden series, Template:Keir Starmer sidebar, Template: Rishi Sunak sidebar, Template:Elon Musk series, etc. I remember a similar change to infoboxes was made a few months ago but dropped within a day or two. Can anyone at Wikimedia provide some clarification? ThatRandomGuy1 (talk) 19:16, 13 June 2024 (UTC)

Images are the same cause. I'll file a separate task for them since it's not obvious to me what the best resolution is for them. Izno (talk) 20:07, 13 June 2024 (UTC)

Tracked in Phabricator
Task T367463

Ok, this one was caused by phab:T113101 and I've filed phab:T367463 for resolution. Izno (talk) 20:23, 13 June 2024 (UTC)

On Monobook, I'm finding that certain infobox images are showing smaller than usual. Images in {{Infobox station}}, for example, are appearing at 272px for me rather than the 340px that I normally see that at. I assume this is related to this issue? Pi.1415926535 (talk) 03:03, 14 June 2024 (UTC)

Pi.1415926535, please see subsection #Infobox thumbnail-sized images are a few pixels too small. —⁠andrybak (talk) 09:40, 14 June 2024 (UTC)

@Andrybak: I'm not sure if the issue I'm seeing is that - I'm on Monobook rather than Vector, and I'm seeing them at ~80% size rather than just a few percent smaller. Regardless, hopefully it'll be sorted out by one of these Phabricator threads. Pi.1415926535 (talk) 20:16, 14 June 2024 (UTC)

For disappearing images in {{ombox}}, subsection #Ombox images sometimes not showing has been created below. —⁠andrybak (talk) 09:40, 14 June 2024 (UTC)

Same here on Firefox/Windows11. Don't remember seeing any discussion about this change anywhere before now. --JackFromWisconsin (talk | contribs) 19:23, 13 June 2024 (UTC)

It's affecting me on Windows 10 as well. ThatRandomGuy1 (talk) 19:26, 13 June 2024 (UTC)

This happened yesterday on commons with Wikidata Infobox when using Vector-22 so it seems to be a Wikimedia change. Cakelot1 ☞️ talk 19:33, 13 June 2024 (UTC)

Did looking around and the infoboxes now look like they do on the Minerva skin, and the hatnotes on the top of the article also look like Minerva now. Not sure if this is intentional or not. --JackFromWisconsin (talk | contribs) 19:40, 13 June 2024 (UTC)

I'm not surprised this happened, I will poke the relevant task. And yes, the relevant task also caused the hatnote differences below. Izno (talk) 19:45, 13 June 2024 (UTC)

So, these were caused by the work in phab:T361573 and elsewhere. I've filed phab:T367462 for a resolution. Izno (talk) 20:01, 13 June 2024 (UTC)

Please have a look at the infobox on 2024 European Parliament election in Ireland to see another issue this has caused. Why was it even changed in the first place? Was there a strong consensus for this change? The new format is causing many more problems than the old one ever did. Please ping me in your reply. Helper201 (talk) 05:26, 14 June 2024 (UTC)

I have reported this specific problem at T367462 just in case it is a separate problem from the other problems in this section. – Jonesey95 (talk) 06:05, 14 June 2024 (UTC)

Thanks. You can see another issue in this - Next Australian federal election - infobox as well. Helper201 (talk) 06:33, 14 June 2024 (UTC)

And another - 2017 United Kingdom general election. Helper201 (talk) 08:31, 14 June 2024 (UTC)

And more: 2024 European Parliament election, 2024 European Parliament election in Denmark, 2024 European Parliament election in Finland, 2024 European Parliament election in Germany, 2024 European Parliament election in Latvia, 2024 European Parliament election in Malta, 2024 European Parliament election in Poland, 2024 European Parliament election in Portugal, 2024 European Parliament election in Romania (see the middle overstretching in the middle as well as the extension outside of the infobox in this example), 2024 European Parliament election in Sweden. Helper201 (talk) 08:57, 14 June 2024 (UTC)

The latest post on "phabricator" says "We can either inverse the media queries for those hatnotes/infobox.less for now. (only apply at lower resolutions), or revert." I don't have an account on this platform but my vote in 100% revert this infobox change and return to how things were on Wednesday 12 June. Helper201 (talk) 09:25, 14 June 2024 (UTC)

I've been seeing issues with {{Infobox film}} which I assume are a result of this change. If no image is used in the infobox, then the width is set so low that even average-length names get split across two lines (see Normal Love for an example). hinnk (talk) 09:58, 14 June 2024 (UTC)

Multi-column tables in infoboxes aligned badly

split from the section above for tracking purposes

Bad infobox formatting on Chris Dangerfield

This seems to have broken a lot of infoboxes. The career history of every association football player is a misaligned mess; see the screenshot I've attached for an example. It seems like this change needs to be reverted until it's more polished. –IagoQnsi (talk) 20:12, 13 June 2024 (UTC)

Consider that your specific example is also how it displays on mobile and you should consider how best to remedy that regardless. This just made the issue visible for desktop as well. There probably needs to be some work done on the template to support small resolutions. Izno (talk) 20:25, 13 June 2024 (UTC)

The footballers infoboxes look nasty now it's true. CNC (talk) 21:48, 13 June 2024 (UTC)

A four-column table should be four columns. Not four items placed at seemingly-random horizontal alignments. I checked, and the HTML has the data as a table with several rows and four cells per row. Now, HTML tables go right back to HTML 3.2 (27 years ago), and it's always been the case that tables having multiple rows and multiple columns are presented in such a way that each cell is the same width as the other cells in the same column. How can this have been screwed up so badly? It looks as if all of the cells in a row have been merged into one, with proportionate spacing between the items. --Redrose64 🌹 (talk) 22:19, 13 June 2024 (UTC)

We have a chicken-egg problem. The issue here is that the infobox is currently a table element. Using the table for this element is bad, as it is difficult to consistently make tables friendly on a mobile device. For mobile devices, we currently resort to using display: flex.

Hopefully this GIF demonstrates the problem we are talking about here and how it impacts our mobile users (please click):

GIF demonstrating the challenges with using table based infoboxes at different font sizes and screen resolutions

Some wikis have successfully moved away from using a table for this reason. For example fr:Pic_de_Guadeloupe. English hasn't been able to move away from a table so easily, as many infoboxes like this example rely heavily on the status quo that it is a table.

The correct solution here would be to insert a table inside the relevant infobox section and not rely on the fact it will always be a table.

I've applied a change to Module:Infobox3cols to restore the old behaviour for now - but I hope we can agree this is not a long term solution. 🐸 Jdlrobson (talk) 01:28, 14 June 2024 (UTC)

Thanks. That fixed the column alignment. The infobox is still incredibly wide, much wider than it used to be and much wider than on Vector legacy, and there is also far too much vertical padding. I hope that fixes to the tickets tracked here will undo those changes. Also, it is not clear to me that French Wikipedia uses something other than tables for infoboxes. fr:Diego Maradona's infobox definitely uses a table for its infobox layout. fr:Pic_de_Guadeloupe, which does not use an infobox, also uses tables for layout of its taxobox, inside of div tags. – Jonesey95 (talk) 01:56, 14 June 2024 (UTC)

Sorry I should have clarified - French Wikipedia still has legacy infoboxes that they are trying to migrate away from. If you inspect the newer ones tend to come from newer infobox templates! 🐸 Jdlrobson (talk) 03:45, 14 June 2024 (UTC)

Links to examples of post-migration French infoboxes would be magnifique. – Jonesey95 (talk) 06:06, 14 June 2024 (UTC)

fr:Projet:Infobox/V3 is probably the best entry point! 🐸 Jdlrobson (talk) 16:06, 14 June 2024 (UTC)

Font size change

split from the section above for tracking purposes

Tracked in Phabricator
Task T367462

For me, at least, the font size in infoboxes has changed to 90% of the default size instead of 88%, which it has been forever. In Vector 2010, the font size in infoboxes is still 88%. I am looking at John Dalton, for example. I have the (formerly default) "small" font size selected as my prose body font preference in the new radio-button switcher on the right-side toolbar. – Jonesey95 (talk) 19:50, 13 June 2024 (UTC)

Is the small size also related to the massive line spacing as well? Is that visible for everyone else? microbiologyMarcus ^{[petri dish·growths]} 20:09, 13 June 2024 (UTC)

Line spacing inside infoboxes? Yes, that would be this change. Line spacing outside? Probably worth a different section Izno (talk) 20:52, 13 June 2024 (UTC)

Dear MediaWiki designers, dividers can be either gaps or lines – there is absolutely no need to use both approaches together, as this consumes valuable space and adds visual noise at the same time without producing any benefits. — Mikhail Ryazanov (talk) 06:23, 14 June 2024 (UTC)

And why .infobox td has that damn padding in hard-coded pixels instead of font units?! — Mikhail Ryazanov (talk) 07:24, 14 June 2024 (UTC)

A font size change this minor can have a significant impact, as in Louisville, Kentucky, two of the image descriptions in the montage went from two to three lines. I may have to change to a combined description as a cleanup, unless, of course, the font size is reverted back. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 06:56, 14 June 2024 (UTC)

I just changed a couple images to make the descriptions go back to two lines. Image widths make a difference in this case. And it so happens I was able to select images that focused more on the entities they represent. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 15:54, 14 June 2024 (UTC)

You should t be relying on fontsize to begin with. Ever. —TheDJ (talk • contribs) 17:11, 14 June 2024 (UTC)

I'm not "relying on fontsize". I never set any font size involved here. I just want to ensure things display well given the typical display settings and relative sizes of things. If anything, I have made the display less brittle due to underlying font size changes. And that's the point. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 19:50, 14 June 2024 (UTC)

I've noticed a significant decrease in font size across all text, not just infoboxes, while using the Vector 2010 skin on my iPad since the style changes. Here's a screenshot for reference. @Jonesey95: do you know if this is a separate issue? Thanks, ‑‑Neveselbert (talk · contribs · email) 17:53, 14 June 2024 (UTC)

Unrelated. This issue only applied to Vector 2022 skin. 🐸 Jdlrobson (talk) 19:55, 14 June 2024 (UTC)

Biographical infoboxes

Biographical infoboxes suddenly got much larger! Anybody know what is going on? Hawkeye7 (discuss) 21:55, 13 June 2024 (UTC)

Hawkeye7, please see section #Infobox problems above. —⁠andrybak (talk) 21:58, 13 June 2024 (UTC)

Hatnotes have Minerva-style background color?

Tracked in Phabricator
Task T367462

Look at the documentation for {{hatnote}} under Vector 2022. A WP:THURSDAY just happened; is there some change in MediaWiki that would've caused this? The CSS indicates that the change is intended to apply to any responsive skin. Aaron Liu (talk) 19:21, 13 June 2024 (UTC)

Is it possibly related this change to Module:Message box/fmbox.css? Oops, that was a month ago, but the class seems to be affected. With a bit more digging, that change seems unrelated. Probably something in the MediaWiki code itself, probably related to dark mode changes. – Jonesey95 (talk) 19:38, 13 June 2024 (UTC)

I've made some notes above. Regarding specifically hatnotes, you should also consider participating in Module talk:Hatnote#Mobile styling, which I started some time ago. Izno (talk) 20:01, 13 June 2024 (UTC)

Not keen on the new look at all, this is something that should have been agreed. Also, the font on the hatnotes looks smaller than it used to, it was a slight strain to read it on my laptop... this seems like a MOS:ACCESS issue if nothing else - small text is a huge no no.  — Amakuru (talk) 08:51, 14 June 2024 (UTC)

Infobox madness

Tracked in Phabricator
Task T367462

OK, does anyone know what is going on with infoboxes right now? The formatting is all askew as of the past 10 minutes or so. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:04, 13 June 2024 (UTC)

Came here to raise similar concerns. We have articles like SS United States with two infoboxes tucked inside one another having extraordinarily wiiiiide boxes, to the point that articles are hard to read. I've seen broken infoboxes thinner than the current ones.

Yesterday, I was set to the old 2010 display settings. Who's screwing with the new vector display? GGOTCC (talk) 22:21, 13 June 2024 (UTC)

Annnnd it's fixed! Check Thursday 13 June style changes above for more info. GGOTCC (talk) 22:23, 13 June 2024 (UTC)

The pages I'm looking at are not fixed. I work on pages for Star Wars characters and have done a lot of work to get infobox items to stay on one line. Now they're wrapping to a second line. Wafflewombat (talk) 22:26, 13 June 2024 (UTC)

Yes, the worst of it has apparently been corrected, but I'm still seeing things out of whack. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:27, 13 June 2024 (UTC)

Definitely not fixed yet in Vector 2022. The borders are still missing, and there are new, unnecessary borders between the rows, with excessive vertical spacing. The font size is also still at 90% instead of 88%, which is wrong. – Jonesey95 (talk) 23:37, 13 June 2024 (UTC)

Are the borders suppose to be missing? When I first saw it, I thought the change was to improve ascetics. GGOTCC (talk) 00:29, 14 June 2024 (UTC)

Yes, this appears to be an issue with the Vector (2022) skin. Infoboxes look fine on the old Vector. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:25, 13 June 2024 (UTC)

Others on this page are wondering the same thing. Some infoboxes now have far less space for content, which messes everything up. Wafflewombat (talk) 22:23, 13 June 2024 (UTC)

If I may summarize the key problem I'm seeing at this point, it's when you have a tabular presentation within the infobox, the first column is hogging up too much width. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:45, 13 June 2024 (UTC)

Perhaps, although the infoboxes seem thinner altogether, like there is simply less room for text overall. Or perhaps the text is just bigger than it was before? For me, changing the skin to 2010 doesn't fix the issue. Wafflewombat (talk) 22:47, 13 June 2024 (UTC)

From what I'm seeing, that is the appearance because first columns (usually data descriptions) are being given lots of extra width at the expense of second columns (the data). Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 23:15, 13 June 2024 (UTC)

Just my 2¢ I'm working on Præsidenten fra Nordvest and the infobox looks so strange with the width being the size of the image. It looks inconsistent with other films like Batman (1989 film) (which I presume the width maxes out when there's a line break in one of the cells). The new infoboxes look the same as mobile-view, so it feels like a mobilificiation. Do style changes like this have a consensus discussion before changing? Svampesky (talk) 23:11, 13 June 2024 (UTC)

Infobox thumbnail-sized images are a few pixels too small

Tracked in Phabricator
Task T367462

FWIW, thumb-sized images now show slightly smaller than my chosen preference (300px) in infoboxes in Vector 2022. A normal thumbnail or frameless image shows as 300px, and the same image in Template:Infobox person (which defaults to the "frameless" image size option) shows as 295px.

https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1228927316

When I force the view to Vector legacy, both images are the same, correct, size. Vector 2022's style sheets do not appear to be respecting users' (or at least my) preferred image thumbnail size. Maybe it's just me. I entered the above info into T367462, but it might be a separate bug. – Jonesey95 (talk) 00:00, 14 June 2024 (UTC)

See Izno's message above about T367463. —⁠andrybak (talk) 00:09, 14 June 2024 (UTC)

These images are not minuscule; they are just a little smaller than they should be, about 1.5% too small. – Jonesey95 (talk) 06:03, 14 June 2024 (UTC)

My mistake. I've struck link to the incorrect ticket. —⁠andrybak (talk) 10:04, 14 June 2024 (UTC)

Other images (which are not in infoboxes) have also shrunk. The images in the {{Public art row}} template in List of public art in the London Borough of Ealing § Acton are now minuscule, but the portrait-format images in List of public art in the London Borough of Ealing § Ealing are the size they ought to be. Ham II (talk) 06:56, 14 June 2024 (UTC)

Take a look at Wikipedia:Top 25 Report or any other page in Category:Wikipedia Top 25 Report; all of them them have images set to 100px inside a wikitable, but the displayed images are much smaller than what it should be... Vestrian24Bio (TALK) 14:29, 14 June 2024 (UTC)

How do I get these style changes on my local MW install?

I just noticed the new look of the infobox and am wondering how I can get this to my local MediaWiki install. I've already used Special:Export with Template:Infobox and Module:Infobox with Include templates on, but the changes have not applied. Anything I've forgotten to import? A diehard editor (talk | edits) 00:48, 14 June 2024 (UTC)

A diehard editor, because it is WP:THURSDAY, these changes are caused by the latest deployment of a new version of MediaWiki, which is 1.43.0-wmf.9 (see Special:Version). These changes are considered to be a bug. It was reported to the bug tracker at phab:T367462 and phab:T367463. —⁠andrybak (talk) 01:04, 14 June 2024 (UTC)

Oh, so it's not supposed to be like this on desktop, and I should not bring them over? I'm still on 1.42. A diehard editor (talk | edits) 01:07, 14 June 2024 (UTC)

Infoboxes

Tracked in Phabricator
Task T367462

Who and what changed the infoboxs to their new format in the last 24 or 48 hours? It’s causing issues I'd to let them know about. Where do I do this? Helper201 (talk) 05:21, 14 June 2024 (UTC)

This was a change to the MediaWiki code. Nobody at the English Wikipedia caused it. See above. – Jonesey95 (talk) 06:03, 14 June 2024 (UTC)

Jonesey95 can you please give me the link to the MediaWiki page where this decision came about or where on MediaWiki to present the issues this change has caused? Helper201 (talk) 06:17, 14 June 2024 (UTC)

Ombox images sometimes not showing

Tracked in Phabricator
Task T367463

Screenshot illustrating the problem.

Screenshot illustrating what it should look like.

Seems like there is a problem with {{ombox}} where sometimes images are not showing up, see e.g. {{sockpuppet}}. Mz7 (talk) 06:28, 14 June 2024 (UTC)

That's phab:T367463. Vector 2022 is now being affected by the same issues which affected Minerva (mobile) and Timeless skins for a long time (phab:T282588). —⁠andrybak (talk) 09:36, 14 June 2024 (UTC)

{{tmbox}} got a workaround applied in Special:Diff/1228936760. —⁠andrybak (talk) 09:40, 14 June 2024 (UTC)

I've submitted a request to apply the same workaround to {{ombox}}. —⁠andrybak (talk) 10:42, 14 June 2024 (UTC)

  Workaround has been applied. —⁠andrybak (talk) 19:35, 14 June 2024 (UTC)

@Andrybak: Thank you so much for your help on that! Mz7 (talk) 10:09, 15 June 2024 (UTC)

Infobox & Hatnotes

What just happened? Infoboxes and Hatnotes on Vector 2022 looks similar to that on Minerva... Is it any of my scripts or is it the new MediaWiki software causing these madness??? Vestrian24Bio (TALK) 07:37, 14 June 2024 (UTC)

How hatnote looks like in Minerva

How hatnote now looks like in Vector 2022

How hatnote should look like (Vector)

Added screenshots for reference. Vestrian24Bio (TALK) 08:46, 14 June 2024 (UTC)

@Vestrian24Bio, you started this subsection "Infobox & Hatnotes" of the big section #Thursday 13 June style changes. Please see other subsections for details about infoboxes and hatnotes. All issues highlighted in your screenshots are already being discussed there. —⁠andrybak (talk) 09:13, 14 June 2024 (UTC)

Got it. Thanks! Vestrian24Bio (TALK) 09:16, 14 June 2024 (UTC)

It's not the skin; it's the parser

Earlier this week, Wikimedia newsletter stated this week they are making changes to the HTML parser; even though it was supposed to only effect the citations, looks like its effecting other things as well.

I just tried breaking the parsing process and the images, hatnotes and even the infoboxes looked just like how they were yesterday and had none of these problems other than broken rendering. (Same for the Parsoid and Legacy as well) Vestrian24Bio (TALK) 14:47, 14 June 2024 (UTC)

Blue background for section hatlinks making them almost illegible

Combination of tiny font and pale blue background is making section hatlinks almost illegible and major eyestrain on my laptop. The text size does not increase with selecting larger text from the appearance menu. This combination with excessively small text in edit boxes is untenable. I am now spending too much time zooming in and out when I could be actually improving content. · · · Peter Southwood ^(talk): 12:37, 14 June 2024 (UTC)

Is this part of Wikipedia:Village_pump_(technical)#Thursday_13_June_style_changes above or something different? Can you provide a link to an example, if you are on mobile or desktop, your skin, and your viewport size? — xaosflux ^Talk 13:17, 14 June 2024 (UTC)

It is part of #Thursday 13 June style changes. Vestrian24Bio (TALK) 14:22, 14 June 2024 (UTC)

Friday message from the Web team

Hey everyone, this is the Web team working on skins. We wanted to explain the situation, apologize, and share what will happen next. Thank you all for reporting and helping us fix things.

This week, we released styling changes to hatnotes, templates, and images. Some of these changes were not intended for rollout this week. Our focus was mostly on "Images should be responsive in Vector and restrained to a max-size" (T113101) and related tasks. We apologize for introducing bugs and making editors confused.

We read concerns shared on different wikis and on Discord, and went over our options. We decided to revert all changes to templates and hatnotes for the time being, and keep the changes to images. Next, we'll review the changes to templates and hatnotes, and bring them for discussion one by one prior to proceeding. If you notice any remaining issues with images, please report them in comments to this Phabricator ticket. We hope to have a fix for the remaining issue on Monday.

Thank you! SGrabarczuk (WMF) (talk) 17:24, 14 June 2024 (UTC)

@SGrabarczuk (WMF) thanks for addressing us here! These changes seem massively consequential. Was the mistake the rollout of these changes or were these changes not supposed to be as broken as they were, i.e. it wasn't properly tested but the changes where rolled out as planned? microbiologyMarcus ^{[petri dish·growths]} 18:52, 14 June 2024 (UTC)

Hey @MicrobiologyMarcus. The former - the mistake was the rollout of changes to hatnotes and infoboxes (and maybe other templates too). We only wanted to roll out the changes to images. SGrabarczuk (WMF) (talk) 19:09, 14 June 2024 (UTC)

@SGrabarczuk (WMF) Hi! I liked the design for infoboxes that was changed, will it be coming back? Interestingedits (talk) 20:03, 14 June 2024 (UTC)

@Interestingedits: It had better not be coming back, see #Multi-column tables in infoboxes aligned badly. --Redrose64 🌹 (talk) 21:46, 14 June 2024 (UTC)

Seconded. It caused way too much damage. Some articles had infobox images going off into the border whilst others had them shrinking or seemingly disappearing. Plenty other issues also emerged. They should fix those issues caused by the redesign first before considering whether to bring it back as an actual feature. ThatRandomGuy1 (talk) 21:58, 14 June 2024 (UTC)

Just FYI, it is the same infobox design as in the Minerva (mobile) skin. Just an idea if you wanted to switch over. JackFromWisconsin (talk | contribs) 07:46, 15 June 2024 (UTC)

Hey @Interestingedits - yes, we would like to bring the main ideas of the design back in the future! The issue was that it got batched together with some other changes before it was fully tested and ready for release. To bring it back we would need to do a bit more testing of the design and discussing on here and other wikis to make sure we can adapt everything in time before proceeding with the change. OVasileva (WMF) (talk) 08:12, 17 June 2024 (UTC)

Hi! Looking forward to it. Is there a way to keep track of the tests/discussions? Would love to be apart of it! Interestingedits (talk) 00:03, 18 June 2024 (UTC)

These changes/discussions are being tracked in phab:T367519 Jon (WMF) (talk) 21:13, 18 June 2024 (UTC)

Thanks for the update and your work. For me, there was a bright side to these events: It pushed me to fix display issues in two infoboxes that will make them appear less clunky on mobile. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 20:10, 14 June 2024 (UTC)

Tuesday 19th update

The problem with images was resolved on Tuesday 19th, the changed styling of infoboxes and hatnotes was reverted on Fri 14th. —TheDJ (talk • contribs) 07:58, 19 June 2024 (UTC)

U.S. county infobox display issue

See Template talk:Infobox U.S. county#"Location within the state" map broken?. This is a map display problem seemingly discovered just today. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 23:29, 16 June 2024 (UTC)

FYI, This doesn't seem to be related to the CSS changes. File:Map of Texas highlighting Liberty County.svg is not displaying correctly for me. Are others seeing this? I am using Vector 2022, logged in or logged out, mobile and desktop view. It also does not display in Timeless or Vector legacy. – Jonesey95 (talk) 05:35, 17 June 2024 (UTC)

I possibly assumed too quickly this connected to the infobox formatting. The problem exists in the Commons version too. SVG processing error, or some problem at the Commons source? Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 06:22, 17 June 2024 (UTC)

Rendering of US county SVG files has changed and fixed replacements must be uploaded at Commons. See Wikipedia:Teahouse#Infobox probelem and Wikipedia:Teahouse#Us couties on article map. PrimeHunter (talk) 09:35, 17 June 2024 (UTC)

SVG file not displaying correctly - Microsoft Edge

Tracked in Phabricator
Task T367645

Hi, it looks like SVG files and their PNG preview versions are not displaying correctly in Microsoft Edge browser Version 126.0.2592.56 (64-bit). For example, Cabell County, West Virginia shows the red outline of the county but no background map of the state in the infobox picture. It has the same appearance if "reloaded in Internet Explorer mode". Tsarivan613 (talk) 14:10, 17 June 2024 (UTC)

I just submitted a bug report to Phabricator site. Tsarivan613 (talk) 14:20, 17 June 2024 (UTC)

It's a problem with the SVG files that was revealed by last week's software update (see #Tech News: 2024-24) – it's already filed as T367645. Matma Rex talk 14:33, 17 June 2024 (UTC)

I've filed a BRFA over on Commons to sort these. Mdann52 (talk) 17:46, 19 June 2024 (UTC)

Font size change in Vector 2010

Tracked in Phabricator
Task T367643

Since the style changes, I've noticed a significant decrease in font size across all text, not just infoboxes, while using the Vector 2010 skin on my iPad. Here's a screenshot for reference. ‑‑Neveselbert (talk · contribs · email) 22:54, 14 June 2024 (UTC)

In phab:T349793 the viewport changed from 1000px to 1100px which may explain a feeling of being zoomed out. 🐸 Jdlrobson (talk) 02:28, 15 June 2024 (UTC)

@Jdlrobson: How can I change it back to how it was? ‑‑Neveselbert (talk · contribs · email) 03:02, 15 June 2024 (UTC)

Section headings with links

Tracked in Phabricator
Task T367468
Resolved

Resolved

(putting this here because it seems related, feel free to move if needed) I noticed on mobile web that section headings that include both linked and unlinked text place each type of text into a separate column. I first encountered it at Wikipedia talk:WikiProject Film but I'm seeing it elsewhere. Any idea what might have caused it? RunningTiger123 (talk) 21:20, 13 June 2024 (UTC)

I don't know what caused it, but as per MOS:NOSECTIONLINKS there shouldn't be links in section headings in any case - Arjayay (talk) — Preceding undated comment added 21:25, 13 June 2024 (UTC)

That MOS only applies to ns:0. — xaosflux ^Talk 13:18, 14 June 2024 (UTC)

Unrelated cause to the above, I think this is the heading change previously notified about and how DiscussionTools is or was dealing with stuff in headings? Matma Rex Izno (talk) 21:32, 13 June 2024 (UTC)

Stjn just filed phab:T367468 which identifies the issue (it's the flex), but IDK how the future is supposed to be. Izno (talk) 21:33, 13 June 2024 (UTC)

Yep, not related to the style changes discussed above, it's a bug in the styles I wrote for Minerva for the heading HTML changes rolling out to that skin this week, as noted in Tech News. It affects any formatting in a heading, not just links, and somehow I never thought to test that. Sorry about that, I'll get it fixed soon (Monday at the latest). Matma Rex talk 23:19, 13 June 2024 (UTC)

Yep, and it happens with italicized text as well ꧁Zanahary꧂ 23:45, 14 June 2024 (UTC)

Formatting

I'm here to report a bug. There is a weird format going on where if you go to September 1967 (as an example) and look at the Wednesday and Thursday sections, the dates are in two separate spaces. It is not how its supposed to be set up. This is also goes for pretty much every page that's made for the 1950s, 60s, 70s, etc... I use an android to get on to Wikipedia so it may or may not differ from other devices but I wanna know if this is some kind of bug that can easily be fixed? Arcadia (talk) 23:00, 14 June 2024 (UTC)

Section headings on numerous pages are currently glitched when I view the mobile version on my phone. I came here to report a similar issue with Matchbox Twenty; the section "Yourself or Someone Like You lawsuit" gets broken up with the album title on the left and "lawsuit" broken up into "law sui t" on three separate lines over to the right. Home Lander (talk) 00:00, 15 June 2024 (UTC)

It's the same problem as #Section headings with links above. It should get fixed on Monday. Matma Rex talk 08:49, 15 June 2024 (UTC)

Subheadings containing italics example text lorem ipsum

I was organising my user page and noticed that the part of the subheading in italics appeared strange in the mobile view. I visited articles to see if the issue was in the main space. I checked music articles like Madonna and Nirvana, as they would have italic subheadings when discussing their works and the issue is present. If this issue has already been noted, please direct me to it and close this discussion. On mobile view, it looks like it creates a table and puts the part in italics in a cell. Svampesky (talk) 15:16, 15 June 2024 (UTC)

This also happens with wikilinks in headings... Janhrach (talk) 15:19, 15 June 2024 (UTC)

Update: It's discussed above, see #Section headings with links. Janhrach (talk) 15:23, 15 June 2024 (UTC)

Wiki links in section titles mangled in mobile view

For example:

• https://en.m.wikipedia.org/w/index.php?title=Talk:Nonmetal&oldid=1229452664#Notabilty_of_Nonmetallic_compounds_and_elements_article_disputed

The section title appears like a 3-column table with the three columns as follows:

1. the text before the link: "Notability of"
2. the text of the link itself: "Nonmetallic compounds and elements"
3. the text after the link: "article disputed"

Lines wrap in the three parts separately, which is REALLY weird. In portrait mode it appears on three lines:

1. Notab … Nonmetallic … article
2. ilty of … compounds and … dispute
3. … elements … d

In landscape mode on two lines:

1. Notability … Nonmetallic compounds and … article
2. of … elements … disputed

This does not occur in the desktop version of the page, no matter how narrow the screen. To fix this, I changed the wiki link square brackets to double quotes:

• special:diff/1229452664/1229453097

And then the issue disappears in both mobile and desktop view:

• https://en.m.wikipedia.org/w/index.php?title=Talk:Nonmetal&oldid=1229453097#Notabilty_of_Nonmetallic_compounds_and_elements_article_disputed

But it really should be fixed so that this is not required. ——YBG (talk) 00:47, 17 June 2024 (UTC)

Never mind. I see this is already being discussed. I will subscribe to the appropriate section. YBG (talk) 00:49, 17 June 2024 (UTC)

Search box

In My Preferences: Vector (2022) removes my search box, Vector legacy (2010) restores it. Any ideas? Thanks. Martinevans123 (talk) 21:09, 13 June 2024 (UTC)

Vector 2022 is responsive. I can reproduce that at screen width below 1120 pixels, the search box disappears, but a flat button with magnifying glass icon (or in dark mode) appears. Clicking on it shows the search box. To focus on the search box, you can also use accesskey F.

Does this correspond to what you encountered? What width screen are you using? —⁠andrybak (talk) 21:57, 13 June 2024 (UTC)

Many thanks for the advice. Now resolved. Martinevans123 (talk) 08:21, 14 June 2024 (UTC)

Resolved

–Novem Linguae (talk) 03:04, 16 June 2024 (UTC)

Can a caption in a group of images span an entire row?

There is a large amount of empty space next to this caption. Is it possible to make this caption span the entire row of images, so that no space is left empty next to the caption?

This footer spans an entire row of images, unlike the caption above.

See the discussion here: is it possible to display a caption using {{Multiple image}} that spans a row of images? Jarble (talk) 16:42, 14 June 2024 (UTC)

Everything is possible, but shoving all possible functionality into a single template is generally a bad idea and creates a maintenance nightmare. —TheDJ (talk • contribs) 17:09, 14 June 2024 (UTC)

@TheDJ: If this template doesn't have this capability, which template should I use instead to display images in this format? Jarble (talk) 21:05, 14 June 2024 (UTC)

I don't think we have a template for this and don't see a big need for it. You could use {{multiple image}} more than once and use the footer parameter when wanted. The images will be split into separate boxes with a gap but is that so bad? At least it would be very clear what the captions apply to. PrimeHunter (talk) 14:11, 15 June 2024 (UTC)

How to create a redirect or even new article if one letter is capitalized?

I had a hard time creating MaryLand because it kept redirecting to Maryland. I found there was a way around the problem if I added an extra letter and then deleted it in the URL when creating the article.— Vchimpanzee • talk • contributions • 22:59, 14 June 2024 (UTC)

If you search for a title like MarYlAnD that doesn't exist except with different capitalization, it'll take you to one of those existing variations. You can get to the nonexisting title by typing the correct title into the url or by clicking on a redlink like MarYlAnD. SilverLocust 💬 23:29, 14 June 2024 (UTC)

You could just add ?redirect=no to an URL to avoid redirects or just use the NoRedirect script. Vestrian24Bio (TALK) 02:37, 15 June 2024 (UTC)

This wasn't actually a redirect, so that wouldn't have made any difference. SilverLocust 💬 02:58, 15 June 2024 (UTC)

@Vchimpanzee: You can click "Search for pages containing" in the dropdown below the search box. Then you will not go directly to a matching page name. If the searched term is not an exact page name including the same capitalization then you get an option to create the page. PrimeHunter (talk) 14:19, 15 June 2024 (UTC)

SilverLocust mentioned what I did, but I don't get a dropdown below the search box. Maybe it's because I use Monobook. Anyway, Vestrian24Bio had the best solution.— Vchimpanzee • talk • contributions • 15:42, 15 June 2024 (UTC)

@Vchimpanzee: Please always say from the start if you don't use the default skin when you ask for interface help. MonoBook has a "Search" button below the search box with the same functionality as the Vector dropdown "Search for pages containing". PrimeHunter (talk) 19:08, 15 June 2024 (UTC)

High quantity of poor edits to short descriptions

I suddenly see a swarm IPs and newbie editors happily adding short descriptors in my watchlist of 20K+ pages. Today, "assuming good faith" I reviewed a couple hundred edits and notified several editors to go careful with these. And suddenly I paid attention that it looks like some tool was rolled out which puts edit summary "Added short description, #suggestededit-add-desc 1.0" and of course this bot screws up numerous articles because it is brainless and newbies brainlessly follow stupid advices. Whatever the feature is, it must be disabled ASAP for editors without extended confirmed status, because it increases unnecessary workload on other wikipedians. It takes much more time to confirm validity of such an edit (because it comes from who knows who) compared to brainlessly clicking some button. And developers deserve a trout slap for a tool that suggests edits to people who have no idea what they are doing. - Altenmann >talk 03:12, 15 June 2024 (UTC)

Broadly agree, although I think any relative newbie could add a short description if they've checked the guidelines and looked at SDs on similar pages to the one they're editing. But there is probably no automated way to get people to do that. I'm not familiar with the tool in question, does it mention the general best practices for SDs? It could be limited to articles that are very easy to give a good SD, such as albums. Wizmut (talk) 04:27, 15 June 2024 (UTC)

If a noob makes an edit per 1 minute in widely disparate areas, I doubt best practices help them without domain knowledge. - Altenmann >talk 04:44, 15 June 2024 (UTC)

Sounds like Wikipedia:Suggestededit-add 1.0. -- Malcolmxl5 (talk) 07:08, 15 June 2024 (UTC)

I don't see the feature being the issue. It's an editor making edits as quickly as possible without giving any care to whether they are useful or not. Traumnovelle (talk) 07:41, 15 June 2024 (UTC)

What the editor is motivated/thinks is constructive to do is informed an awful lot by the user interface. Remsense诉 07:51, 15 June 2024 (UTC)

He could've made poor edits to other articles via the suggested edits thing regarding copy editing. Traumnovelle (talk) 07:55, 15 June 2024 (UTC)

And you know what? people were complaining about this several times on several issues (including mine), and the tool still runs.

• Problems with suggested edits
• Very large number of troubling edits with SuggestedEdits
• Many file descriptions added from Commons Android app (Suggested Edits) are unhelpful
• Turning off SuggestedEdits on Commons

Someone deserves a BIG trout.- Altenmann >talk 09:22, 15 June 2024 (UTC)

Again, there's a phabricator ticket about it. Devs have a lot of work to do. Remsense诉 09:27, 15 June 2024 (UTC)

Then it must be disabled until fixed. Don't you think editors have a lot of work to do other than struggling with screw-ups of devs? If I tell my customers "our devs have a lot to do", they will say "goodbye, we will renew our contract once your devs become less busy". - Altenmann >talk 09:33, 15 June 2024 (UTC)

Shrug. It's annoying to me, but I can't easily summon your level of frustration. Remsense诉 09:34, 15 June 2024 (UTC)

Do you have a link to the Phabricator ticket handy? That is the quickest way to read up on the issue and also to tell the devs. –Novem Linguae (talk) 03:02, 16 June 2024 (UTC)

The WMF doesn't want to help you, they want to feel good. Cremastra (talk) 20:50, 15 June 2024 (UTC)

Yes the feature is an issue. It is a suggested edit. A novice would normally think they should trust the suggestion supposedly coming from someone smarter (not). Therefore I came here to take the blame off the novice and put in on tool owners. - Altenmann >talk 09:33, 15 June 2024 (UTC)

Where in the suggestion does it tell you to add something like the article's title as the description? It directs the editor to the feature/function but doesn't tell them what to write. Traumnovelle (talk) 10:16, 15 June 2024 (UTC)

Whatever. Still, my point is that this feature should not be available to random IPs who often no clue to write and also have no clue that in this case they should not write (Dunning–Kruger effect :-) and my suggestion was to permit "Edit suggester" only to extended confirmed users. - Altenmann >talk 21:01, 15 June 2024 (UTC)

Have you seen IPs do this? The feature Malcolmxl5 mentioned, in commons, claims to be logged-in users only. – 2804:F1...54:15BE (talk) 21:06, 15 June 2024 (UTC)

Oops, you are right. I reviewed my contribs, with plenty of recerts of IPs, and only logged-in users have "uggestededit-add-desc " in edit summary. Still, I am standing with my suggestion to increase level to extended confirmed status. - Altenmann >talk 00:03, 16 June 2024 (UTC)

How bad are these edits? Can you provide a couple diffs of edits you fixed/reverted? How many edits did you check and what percent of those are problematic? Can this be fixed by warning a couple people or do we need to get a consensus for an edit filter to block these edits? (If the latter, we should probably start an AN/ANI thread.) –Novem Linguae (talk) 03:01, 16 June 2024 (UTC)

The edits of this one editor are very poor – I had to revert at least two-thirds of the recent ones – and that editor has been asked to stop. I don't know if there is a systemic problem with the tool or if this is just a single-editor CIR problem. If there is a way that an edit filter could prevent the "suggested edits" tool from changing a short description of "none" to something else, contrary to instructions, that would be great. T326898 has been waiting for action for over a year, and it is not fixed yet. It is always disappointing when the developers roll out shiny new toys and then don't stick around to fix them. – Jonesey95 (talk) 04:30, 16 June 2024 (UTC)

I went to test this, since there hasn't been any new "edit short description" newcomer task added recently. I noticed that in Suggested Edits "mode" (clicking through to a suggested edit from the newcomer Homepage), if I switched to VisualEditor, the short description of an article displays at the top of an article as a box with the grey text "Short description", rather than displaying the short description, which is only shown if you click through to alter it. See c:File:Screenshot suggested edit short description visual editor.png. Folly Mox (talk) 22:19, 16 June 2024 (UTC)

Dragging a url from the &action=edit text area into the search box

Why does drag-and-dropping an url from the page editor's textarea (and seemingly only from there) into the search box strip most of the url?
Steps:

1. Go to https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit
2. Put the link https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit somewhere in the editor's text area
3. Select that text and drag and drop it into the search box at the top of the page
4. Observe how the text that showed up was index.php

This doesn't happen only with urls, any text that starts with text: gets altered.
What I expected was for the link to not be altered, which is what happens if you drag and drop while holding ctrl (a copy drag and drop).
I'm on Google Chrome (v 125.0.6422.142, Official Build, 64-bit), desktop. – 2804:F1...C5:7348 (talk) 04:37, 15 June 2024 (UTC)

• For anyone looking in to this, the user story can be a bit simpler. It doesn't matter what the link is (e.g. https://www.google.com/search?q=things works); also it isn't about the "search box" - same behavior can be seen "drag/drop" a link within the edit box. — xaosflux ^Talk 09:40, 15 June 2024 (UTC)

  Ah. I put 2 and 2 together, i.e. looked at your comment and @Nardog's below, and turns out this is just an issue with Google Chrome (Chromium?) in general?

  The same thing happens if you go to the google search link you gave, paste the link at the start of Google's search box and then drag it to the other side of the word things. No wonder I couldn't find anything in the JavaScript backtrace of the preview search request. – 2804:F14:8086:B701:BF:AF2B:7254:15BE (talk) 19:31, 15 June 2024 (UTC)

  Thanks, looks like you've confirmed this is a quirk of Chromium, and not a Wikipedia, or Mediawiki issue. Chromium bugs can be reported here: https://issues.chromium.org/issues/wizard — xaosflux ^Talk 20:29, 15 June 2024 (UTC)

  Seems like this 2019 issue that they never fixed and were unable to reproduce: https://issues.chromium.org/issues/41437089.

  A fun example from there: drag-and-dropping a text that starts with data: followed by something that has a space (like data: a) turns into the word download! wow.

  Thanks for the help. – 2804:F14:8086:B701:BF:AF2B:7254:15BE (talk) 21:01, 15 June 2024 (UTC)

Appears specific to Chromium. Nardog (talk) 10:08, 15 June 2024 (UTC)

Banner collapsing question

What causes banners made with Module:WikiProject banner to collapse when placed inside {{WPBS}}. I imported that module among others to another wiki and everything works, except the banners don't collapse automatically. I've looked in Module:WikiProject banner/styles.css, Module:Banner shell/styles.css, Module:Message box/tmbox.css, and even the Vector.css and it eludes me. Could someone point me in the right direction? –Fredddie™ 04:56, 15 June 2024 (UTC)

@Fredddie: Module:WikiProject banner adds the class innercollapse which has code in MediaWiki:Common.js and MediaWiki:Common.css. PrimeHunter (talk) 10:17, 15 June 2024 (UTC)

Huh that did the trick. It must have been the Common.js because I already had Common.css. Thanks for the quick reply. –Fredddie™ 16:47, 15 June 2024 (UTC)

Resolved

–Novem Linguae (talk) 02:51, 16 June 2024 (UTC)

Size for text renderings at Zero-width non-joiner

I need help resizing the Bengali and Telugu render images in the table to appear the correct size, matching the x-large font size (Example Text) when viewed on desktop using default settings. It may be preferable to replace them with unpadded SVGs. The Malay Jawi script renderings are in the correct format, but at a very large native size, and the sizes of those images in the ZWNJ article should be double-checked. –LaundryPizza03 (dc̄) 07:01, 15 June 2024 (UTC)

In one case I have reduced the image size, in the other it said 148p instead of 148px. All the best: Rich Farmbrough 23:48, 16 June 2024 (UTC).

Is AFDStats down?

I've been sitting here about half an hour trying to pull up my AFD stats (https://afdstats.toolforge.org/afdstats.py?name=Maile66&max=&startdate=&altname=) and it just hangs in a never-ending loop. — Maile (talk) 11:57, 15 June 2024 (UTC)

My Toolforge bot has been working fine. This is probably a software-specific issue. Dragoniez (talk) 13:11, 15 June 2024 (UTC)

Meaning, I guess, the MediaWiki software, because the AFD stats were working perfectly when I edited yesterday, and nothing has changed on my computer. — Maile (talk) 13:48, 15 June 2024 (UTC)

It finally came up, but took two hours to finally complete. Hope this gets better soon. — Maile (talk) 15:29, 15 June 2024 (UTC)

FYI - Here we are eight hours later, and absolutely nothing has changed as far as the hours it takes to pull up the AFD Stats. Something is not good somewhere. — Maile (talk) 23:30, 15 June 2024 (UTC)

It looks like the tool is semi-abandoned, but User:Legoktm has semi-adopted it. I've contacted him off-wiki and he says he'll take a look when he gets back to a keyboard. RoySmith (talk) 01:28, 16 June 2024 (UTC)

And, yes, it sure looks like it fell down and can't get up. I'm getting python stack dumps. RoySmith (talk) 01:30, 16 June 2024 (UTC)

Thank you! Thank you! We don't know how much we rely on something until it falls down on its job. — Maile (talk) 02:19, 16 June 2024 (UTC)

The homepage is still up so the tool is not down completely. A query for my AFD stats completed after several minutes so is going much slower than it should. The only thing this tool does to interface with MediaWiki is via a couple mw:Action API queries, so I think it's unlikely that MediaWiki is the culprit. Maybe the webserver needs to be restarted, or maybe we need to step debug the python code and see if something there is slowing things down. –Novem Linguae (talk) 02:46, 16 June 2024 (UTC)

Thanks Roy for the ping. The database server queries are taking much slower than they should (I just killed one that had been running for 30 minutes!). s1 replag is currently ~4 hours, which might be the cause or another symptom of something else.

I applied one small performance fix and restarted it and now it seems to returning results, so one of those two did the trick. Legoktm (talk) 05:02, 16 June 2024 (UTC)

Also if someone has some time, the tool is running as a legacy CGI application running under lighttpd. Would be great if we could convert it to a proper WSGI application (e.g. flask) or ... port it to Rust. Legoktm (talk) 05:06, 16 June 2024 (UTC)

Outdated GA review still hanging around on an article talk page

If someone around here who isn't as exhausted as I am today would please visit Talk:Tiny Town (miniature park), there is an old GA assessment I did - see the GA1 (show) line - that needs to be moved off the article talk into wherever. I can't remember how to make that happen and if you did that it would be awesome. Thanks, Shearonink (talk) 19:22, 15 June 2024 (UTC)

An ending </div> was missing so it combined with the following section. This was fixed by [7]. PrimeHunter (talk) 21:39, 15 June 2024 (UTC)

omg. it's the little things ain't it... thank yooooooou. Shearonink (talk) 00:48, 16 June 2024 (UTC)

O wise PrimeHunter...the next thing is this: Since the GA Review is outdated etc how does one make it go off the main article talk/go away? GA Reviews don't hang around forever right? Don't laugh, I should know this but it's been a long day.... I think I can just archive the GA Review at its actual talk page - Talk:Tiny Town (miniature park)/GA1 which will then archive the GA Review to Talk:Tiny Town (miniature park)/Archive 1 and all will be well. Lol I confess I'm always concerned I'll break something around here... Please confirm and thanks - Shearonink (talk) 01:01, 16 June 2024 (UTC)

If you want to make it auto archivable, you'd probably want to wrap it in a level 2 heading and a signature. Then since you don't have WP:AUTOARCHIVE set up, either set that up, or one click archive it. –Novem Linguae (talk) 02:31, 16 June 2024 (UTC)

@Shearonink and Novem Linguae: I have noticed that newly-created GANs and GARs are generally transcluded into a totally unrelated section, whichever one happened to be last on the talk page when Legobot popped by. Once the GAN/GAR is over, it's no longer an ongoing discussion; but it seems that Legobot has no post-GA clearup task, and it's left for a manual edit.

I have never come across anybody wrapping a GAN/GAR in the manner that you describe, whether to be bot-archived or not; and generally speaking, it's not necessary to retain it since either the {{GA}} box or the article history box should already link to it. When I find that a talk page still transcludes a closed GAN/GAR, I first make sure that it's linked from the article history box together with its outcome, and then I simply de-transclude it, like this. --Redrose64 🌹 (talk) 08:13, 16 June 2024 (UTC)

Thanks for this info. I maintain the user script that closes a lot of GANs and GARs. I just checked and the script's closing algorithm leaves these template transclusions in place. GAN example. GAR example.

Perhaps we should have a wider discussion about what to do with these on the WT:GAN and WT:GAR talk pages. The fact that they're not wrapped means they don't get auto archived and hang around forever. Perhaps there's a work instruction we can get consensus to update somewhere, and we could ask that it be updated to wrap these in headings and signatures so that they don't hang around forever. –Novem Linguae (talk) 08:32, 16 June 2024 (UTC)

There should be no need to archive it, as it's technically already archived - GANs and GARs are talk subpages, albeit ones that don't contain the word "Archive" in their names, for example Talk:Kurt Wolff (aviator)/GA1. As I mentioned, for anybody curious about reading the text of the GAN/GAR, these pages are linked from one of the boxes at the top of the talk page - either {{GA}} or {{article history}}. Please can we not suggest creating a process that is more complex than it needs to be: simple de-transclusion should be quite sufficient. --Redrose64 🌹 (talk) 10:22, 16 June 2024 (UTC)

A lot of things hang around forever. It's a capital mistake to think that "things" should be deleted (or moved) just because one currently has no use for them. All the best: Rich Farmbrough 23:30, 16 June 2024 (UTC).

Date problem

I am citing an issue of a journal dated "July August 2024", but "date=July August 2024" gives an error message. How can I show this date? Dudley Miles (talk) 20:57, 16 June 2024 (UTC)

Dudley Miles, you may wish to try |date=July–August 2024 per Help:Citation Style 1 § Date format compliance with Wikipedia's Manual of Style, but the template might still get mad at you for using a date in the future. Using the parameter |publication-date= instead of |date= might fix the problem of the date being in the future; I'm not sure if that parameter is checked the same way. If nothing works better, |date=2024 will at least not produce an error. Folly Mox (talk) 22:03, 16 June 2024 (UTC)

Both are checked, but it appears there is no issue with how far in the future it is: "T". J. July–August 2024. Izno (talk) 22:17, 16 June 2024 (UTC)

date=July–August 2024 works OK provided it is an endash not a hyphen. Thanks to you both for your help. Dudley Miles (talk) 22:45, 16 June 2024 (UTC)

Lots of problems with Quarry

Tracked in Phabricator
Task T367464

There have been problems with Quarry query for days now (and I opened a phab ticket but no action so far) and now the bots I rely on issue reports that are all out of whack, coming hours after they are regularly scheduled to be issued. I'm wondering if there is a bigger problem going on here with the database and since my phab ticket had has little response, I thought I'd inquire here in case anyone had any answers. It's frustrating and it's been going on days now. Liz ^{Read! Talk!} 06:03, 17 June 2024 (UTC)

According to the ticket, SD0001 wrote a patch to try to fix it and got it deployed. Sadly it didn't completely fix things though and more work is needed. Seems like a tricky bug. –Novem Linguae (talk) 01:06, 18 June 2024 (UTC)

(Un)subscribe JS error [Gadget?] (and many warnings)

(Skin Monobook) Example from this page:

Wikipedia:Village_pump_(technical):984 This page is using the deprecated ResourceLoader module "mediawiki.ui.input".
[1.41] Please use Codex. See migration guidelines: https://www.mediawiki.org/wiki/Codex/Migrating_from_MediaWiki_UI
Wikipedia:Village_pump_(technical):984 This page is using the deprecated ResourceLoader module "mediawiki.ui.checkbox".
[1.41] Please use Codex. See migration guidelines: https://www.mediawiki.org/wiki/Codex/Migrating_from_MediaWiki_UI
Wikipedia:Village_pump_(technical):984 This page is using the deprecated ResourceLoader module "mediawiki.ui.button".
[1.41] Please use Codex. See migration guidelines: https://www.mediawiki.org/wiki/Codex/Migrating_from_MediaWiki_UI
(anonymous)	@	Wikipedia:Village_pump_(technical):984
Wikipedia:Village_pump_(technical):984 This page is using the deprecated ResourceLoader module "codex-search-styles".
[1.43] Use a CodexModule with codexComponents to set your specific components used: https://www.mediawiki.org/wiki/Codex#Using_a_limited_subset_of_components
(anonymous)	@	Wikipedia:Village_pump_(technical):984
startup.js:1307 This page is using the deprecated ResourceLoader module "jquery.ui".
Please use Codex instead.
2
log.js:79 Use of "addPortletLink" is deprecated. Use mw.util.addPortletLink instead
maybeLog	@	log.js:79
index.php?title=User…=text/javascript:67 Reflinks: Loading messages from cache @ 1718487515832
index.php?title=User…text/javascript:185 Promoting reFill 2
log.js:79 Use of "addPortletLink" is deprecated. Use mw.util.addPortletLink instead
maybeLog	@	log.js:79
startup.js:1307 This page is using the deprecated ResourceLoader module "mediawiki.ui".
[1.41] Please use Codex. See migration guidelines: https://www.mediawiki.org/wiki/Codex/Migrating_from_MediaWiki_UI
execute	@	startup.js:1307
ext.gadget.Navigatio…ps-script-0.js:2997 Uncaught 
TypeError: Cannot read properties of null (reading 'indexOf')
    at Title.namespaceId (ext.gadget.Navigatio…script-0.js:2997:22)
    at isInStrippableNamespace (ext.gadget.Navigatio…script-0.js:3220:18)
    at navlinkTag.getPrintFunction (ext.gadget.Navigatio…script-0.js:7580:48)
    at navlinkTag.html (ext.gadget.Navigatio…-script-0.js:7360:8)
    at navlinkStringToHTML (ext.gadget.Navigatio…script-0.js:7347:19)
    at pg.structures.menus.popupTopLinks (ext.gadget.Navigatio…script-0.js:1146:10)
    at pg.structures.shortmenus.popupTopLinks (ext.gadget.Navigatio…script-0.js:1160:30)
    at fillEmptySpans (ext.gadget.Navigatio…script-0.js:3876:12)
    at simplePopupContent (ext.gadget.Navigatio…s-script-0.js:365:3)
    at mouseOverWikiLink2 (ext.gadget.Navigatio…s-script-0.js:331:4)


Error does not seem to be 100% consistent, but I've had it on other pages too.

What is Codex? Were we asked about it?

All the best: Rich Farmbrough 10:59, 17 June 2024 (UTC).

Codex is "described" here. All the best: Rich Farmbrough 11:20, 17 June 2024 (UTC).

Most of that isn’t relevant, just warnings. The part that matters is:

ext.gadget.Navigatio…ps-script-0.js:2997 Uncaught TypeError: Cannot read properties of null (reading 'indexOf') at Title.namespaceId (ext.gadget.Navigatio…script-0.js:2997:22) at isInStrippableNamespace (ext.gadget.Navigatio…script-0.js:3220:18)

so it was an error when rendering a Navigation popups of a specific link that you were hovering. —TheDJ (talk • contribs) 21:32, 17 June 2024 (UTC)

Any console warnings that talk about "deprecation" mean that there are plans to delete support for that in the future, so folks are encouraged to update their code before that happens. But they don't result in any errors yet, just noisy warnings. So deprecation stuff can be ignored when debugging. –Novem Linguae (talk) 01:00, 18 June 2024 (UTC)

Many thanks for the replies.

• I know what deprecation is.
• I sometimes raise issues solely because they are a problem for me, though I would probably do so ref desk.
• Generally I will raise issues here because they are issues for the wiki. These are such.

Breakdown of issues

1. Warnings are important, including deprecations. They are a designed to enable us to prevent things from breaking rather than letting them break then (maybe) fixing them.
2. We have a whole new JS component infrastructure. It may well be that most people are already aware of this, on the other hand it may not. If not this is a series socio-technical issue that needs addressing. Which is the case?
3. We need to have a program to remove these deprecated items before they are no longer supported, or, a campaign to undeprecate them. This pf course applies to other wikis. Is such in place?
4. There is an issue with a popular gadget. Someone willing and competent should look at this. If that someone is reading this great, if not who is it?

I've added a question to each issue (to try and move things forward), except the first, which is really a matter of maintenance philosophy, though I hope most people agree with it. Hope this makes the issues clearer.

All the best: Rich Farmbrough 08:55, 18 June 2024 (UTC).

MediaWiki:Actionthrottledtext triggered for non-bot account

Hi. Using this account (which is not automated, albeit new), I tried to make a major edit to this page. Request got blocked by MediaWiki:Actionthrottledtext. I tried again roughly 14 hours later : same error message. The Help Desk told me to publish this technical difficulty here. You can found my original message here.
I did try to make the same edit with an older account : got hit by the MediaWiki:Actionthrottledtext too.
Thanks in advance. Alpiiiiiine (talk) 14:42, 17 June 2024 (UTC)

The help desk and Teahouse has recently got several posts from users reporting this message. None of them were autoconfirmed. We didn't get such reports before so something has probably changed. PrimeHunter (talk) 21:56, 17 June 2024 (UTC)

That older account, which is autoconfirmed, is also hit by the same restriction, even after waiting for a day. It's @Erwan789. I really don't understand why both accounts are receiving that message is one is years older and autoconfirmed, and the other one isn't. Alpiiiiiine (talk) 08:47, 18 June 2024 (UTC)

User:Erwan789 is not autoconfirmed. It requires both four days and ten edits at the English Wikipedia. Erwan789 only has seven edits here. Special:CentralAuth/Erwan789 shows edits at other wikis but that doesn't count. PrimeHunter (talk) 11:46, 18 June 2024 (UTC)

Oh OK I got it now, thanks for explaining, that really helped me. Erwan789 (talk) 22:49, 18 June 2024 (UTC)

@Alpiiiiiine: I know this happened because of this situation, but please read the policy on multiple accounts, you really aren't supposed to be using more than one account at once without it being for at least one of the valid reasons, and even then the accounts should usually be linked – 2804:F14:80D0:4F01:ECC5:CFE4:210D:21A8 (talk) 19:00, 18 June 2024 (UTC)

Do not worry : I will delete the newly (and useless) account, thanks for reminding me to do so. Erwan789 (talk) 22:50, 18 June 2024 (UTC)

@Alpiiiiiine:/@Erwan789: Did you get a CAPTCHA with your "major edit", and if so how many times did it take for you to get it right? In any case, can you try one more time, from the Alpiiiiiine account, please? Suffusion of Yellow (talk) 23:09, 18 June 2024 (UTC)

I did get CAPTCHA for them, and I got them right on the first trim except for one.

I tried again, this time i got not CAPTCHA, just the error message. Erwan789 (talk) 08:00, 19 June 2024 (UTC)

That post was the tenth edit by User:Erwan789, meaning the account is now autoconfirmed. Can you test whether it still fails for Alpiiiiiine but now works for Erwan789? PrimeHunter (talk) 11:27, 19 June 2024 (UTC)

The edit was blocked on Alpiiiiiine, but it (finally) went through for this account! Erwan789 (talk) 11:41, 19 June 2024 (UTC)

Thanks for the information. It may help somebody (not me) who tries to track down the cause. PrimeHunter (talk) 12:43, 19 June 2024 (UTC)

Sorting problem

Why it's impossible to sort properly "Monthly net minimum wage (EUR)" in this list. Eurohunter (talk) 21:14, 17 June 2024 (UTC)

The documentation for sortable tables is at Help:Sortable tables —TheDJ (talk • contribs) 21:34, 17 June 2024 (UTC)

@Eurohunter: I have added data-sort-type="currency" to all wage columns [8]. They now ignore the currency symbol and sort the numbers in numerical order. If you want to sort by value then see Help:Sortable tables#Specifying a sort key for a cell. You could add data-sort-value="€..." | with an approximate € value to numbers not given in €. The data-sort-value is not shown to readers so the conversion doesn't have to be precise. PrimeHunter (talk) 22:10, 17 June 2024 (UTC)

@PrimeHunter: Thanks. Eurohunter (talk) 16:54, 18 June 2024 (UTC)

New York City locator maps in Slovenian?

Screenshot of the locator map for Radio City Music Hall on 2024-06-17

It appears that the locator maps for places in New York City are being displayed with labels in what appears to be Slovenian or another Slavic language. For example, see the screenshot I just took of the locator map in the Radio City Music Hall article: Lincoln Square is "Linkoln Skver", Columbus Circle is "Kolambus Serkl", Hell's Kitchen is "Hels Kičen", South Central Manhattan is "Južni Srednji Menhetn", etc. —Bkell (talk) 21:59, 17 June 2024 (UTC)

See Wikipedia:Village pump (technical)/Archive 212#Serbian place names displayed on Manhattan maps. It's being worked on. PrimeHunter (talk) 22:12, 17 June 2024 (UTC)

The priority of one ticket, T230013, was recently moved from "Backlog" to "Later". A second ticket, T195318, looks like it might actually have a patch available, but it needs to be moved forward. – Jonesey95 (talk) 22:22, 17 June 2024 (UTC)

In Wikipedia, language translates you! RoySmith (talk) 14:30, 18 June 2024 (UTC)

I have a similar issue but with the '2022 Russian invasion of Ukraine.svg' image used in Russian invasion of Ukraine. It's only visible one the original file option. -- LCU ActivelyDisinterested «@» °∆t° 19:23, 19 June 2024 (UTC)

Tech News: 2024-25

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• People who attempt to add an external link in the visual editor will now receive immediate feedback if they attempt to link to a domain that a project has decided to block. Please see Edit check for more details. [9]
• The new Community Configuration extension is available on Test Wikipedia. This extension allows communities to customize specific features to meet their local needs. Currently only Growth features are configurable, but the extension will support other Community Configuration use cases in the future. [10][11]
• The dark mode beta feature is now available on category and help pages, as well as more special pages. There may be contrast issues. Please report bugs on the project talk page. [12]

Problems

• Cloud Services tools were not available for 25 minutes last week. This was caused by a faulty hardware cable in the data center. [13]
• Last week, styling updates were made to the Vector 2022 skin. This caused unforeseen issues with templates, hatnotes, and images. Changes to templates and hatnotes were reverted. Most issues with images were fixed. If you still see any, report them here. [14]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 June. It will be on non-Wikipedia wikis and some Wikipedias from 19 June. It will be on all wikis from 20 June (calendar). [15][16]
• Starting June 18, the Reference Edit Check will be deployed to a new set of Wikipedias. This feature is intended to help newcomers and to assist edit-patrollers by inviting people who are adding new content to a Wikipedia article to add a citation when they do not do so themselves. During a test at 11 wikis, the number of citations added more than doubled when Reference Check was shown to people. Reference Check is community configurable. [17]
• Mailing lists will be unavailable for roughly two hours on Tuesday 10:00–12:00 UTC. This is to enable migration to a new server and upgrade its software. [18]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 23:46, 17 June 2024 (UTC)

Morebits

Hi. I recently created the AlertAssistant user script. Would it be possible to make the two radio buttons appear on the same line and display the {{Contentious topics/log}} template? Also, would it be possible to not be warned by filter 602? Thanks. '''[[User:CanonNi]]''' (talk • contribs) 00:19, 19 June 2024 (UTC)

This is not directly supported by Morebits, but can be achieved by custom CSS modifications. – SD0001 (talk) 04:51, 20 June 2024 (UTC)

Saving settings

Whenever I attempt to save my settings (both on mobile and laptop) it instantly resets as soon as I leave the settings page, regardless of whether I have clicked save. Has anyone else experienced this? The main issue for me is the email settings and I am considering just removing my email address so I am not constantly receiving emails, however it does mean that if I forgot my password I will be locked out of my account. Any help would be greatly appreciated. Longhorncowfish (talk) 00:25, 19 June 2024 (UTC)

@Longhorncowfish The options at Special:Preferences#mw-prefsection-echo include having one email per week with all your notifications, and check boxes to specify what these notifications should include. Are you saying you can't save changes to that set of preferences? Mike Turnbull (talk) 21:24, 19 June 2024 (UTC)

Accessibility of map pushpin in infobox

Hello,

On this page, Glover-Archbold Park, I noticed the red dot signifying coordinates on the map in the infobox is quite hard to see. The background has a lot of lines, etc., that make it hard to identify where on the map the red dot is at a glance. Are there more accessible ways to portray this within infobox? Namely, a red dot on a green line seems like a colorblindness nightmare. Cheers, --Engineerchange (talk) 01:17, 19 June 2024 (UTC)

@Engineerchange: Template:Location map#Parameters has mark to change File:Red pog.svg, but Glover-Archbold Park uses {{Infobox NRHP}} which doesn't pass on mark so this method doesn't currently work here. There is no pretty way to do it. An ugly way is wrapping the whole infobox call in {{replace}} to change the file name but it would make it hard to edit the infobox in VisualEditor, and it could fail later if the infobox changes a detail in its output. I don't recommend such a hack for a minor change like this. You could try a request at Template talk:Infobox NRHP to pass on mark. PrimeHunter (talk) 11:12, 19 June 2024 (UTC)

"Talk:" page locked

• cannot reply on Talk:Anthony Fauci
• CHANGE: Anthony Fauci
• FROM: His paternal grandparents, Antonino Fauci and Calogera Guardino, were from Sciacca
• TO: His paternal grandparents, Antonino Fauci and Calogera Guardino, were from Sciacca, Sicily

98.248.161.240 (talk) 03:53, 19 June 2024 (UTC)

This edit was also requested at Wikipedia:Teahouse#"Talk:" page locked. This request was implemented by User:RudolfRed in this and this edit. LightNightLights (talk • contribs) 09:44, 19 June 2024 (UTC)

Heads-up: Diff colour

Hey everyone,

On the topic of accessibility: As you might know, the Wikimedia Foundation Web team is working on a night mode, which is currently available on mobile but continues to be developed. As part of the accessability work around this, the developers made some slight changes to the colour in the diff text, which will be visible on the wikis this week but didn't make it into Tech News until next week. You can read more in phab:T361717.

As part of the Tech News crew, I wanted to let you know since it didn't make it into this week's issue. /Johan (WMF) (talk) 15:07, 19 June 2024 (UTC)

Is having different colours between different modes such a hard thing to add? The colour look much worse now on the default/white mode and are too pale. Traumnovelle (talk) 10:17, 20 June 2024 (UTC)

I'm using the old Vector style, and I want to switch back to old diff colors. This is hurting my eyes...can someone help me with the css code needed? Jonatan Svensson Glad (talk) 11:56, 20 June 2024 (UTC)

I came here to ask the same, particularly the new yellow is painfully vivid due to light sensitivity. -- LCU ActivelyDisinterested «@» °∆t° 14:23, 20 June 2024 (UTC)

This should restore the old colors:

.diff-deletedline {
  border-color: #ffe49c;
}
.diff-addedline {
  border-color: #a3d3ff;
}
.diff-deletedline .diffchange,
.mw-diff-inline-deleted del, .mw-diff-inline-changed del, .mw-diff-inline-moved del {
  background: #ffebad;
}
.diff-addedline .diffchange,
.mw-diff-inline-added ins, .mw-diff-inline-changed ins, .mw-diff-inline-moved ins {
  background: #a3d3ff;
}

-- hgzh 14:31, 20 June 2024 (UTC)

Thanks hgzh that works perfectly. -- LCU ActivelyDisinterested «@» °∆t° 15:36, 20 June 2024 (UTC)

Before too many people copy this over to their user CSS, I strongly advise instead that you use the CSS I recommended in T361717#9910664 instead as diff HTML (and thus associated selectors) is not covered by the mw:Stable_interface_policy/Frontend. Jon (WMF) (talk) 16:21, 20 June 2024 (UTC)

I used the selectors because they work in all skins, while the changes to css variables will have no effect in timeless and monobook skin (don't know how many people are using these over here, in dewiki I think we have quite a lot of people that still use monobook and are not very keen on a changing interface). If you are only on Vector/Minerva skins, the variable override is better. hgzh 17:41, 20 June 2024 (UTC)

Ack. I forgot the old skins are not getting CSS variables right now. I'll update my comment with clearer advice by the end of the day. Thanks for pointing this out. Jon (WMF) (talk) 21:11, 20 June 2024 (UTC)

@Johan (WMF), Tech News is distributed to 700+ communities. So it is extremely weird (and a bit disheartening) to see WMF people inform only the English-speaking community if something was not relayed there.

(Though I am of the opinion that this strange diff colour change should not have been made at all, or should’ve been made with more care to keep the colours closer to the original.) stjn 16:32, 20 June 2024 (UTC)

Stjn: I absolutely understand that perspective, and this is not a substitute for a Tech News update – there will be a Tech News update – but I'd like to point out didn't only update the English-speaking community. I also posted on a mailing list for people who have signed up to spread technical information to their home communities. Where this quick update ended up doesn't reflect Foundation priorities, but language limitations – it's also been posted on Swedish Wikipedia, for example. Johan (WMF) (talk) 17:05, 20 June 2024 (UTC)

Thanks for that hgzh! I think two of the colors are slightly off. I think this will restore the original colors:

/* restore old diff colors */
.diff-deletedline {
  border-color: #FFE49C;
}
.diff-addedline {
  border-color: #A3D3FF;
}
.diff-deletedline .diffchange,
.mw-diff-inline-deleted del, .mw-diff-inline-changed del, .mw-diff-inline-moved del {
  background: #FEEEC8;
}
.diff-addedline .diffchange,
.mw-diff-inline-added ins, .mw-diff-inline-changed ins, .mw-diff-inline-moved ins {
  background: #D8ECFF;
}

I did try the CSS that Jon (WMF) linked, but sadly it did not work. –Novem Linguae (talk) 16:59, 20 June 2024 (UTC)

What should be the previous colors can be found at Special:Permalink/1228175150 (old version of Help:Diff). The hex color codes in Novem Linguae's version look accurate to me. —⁠andrybak (talk) 22:38, 20 June 2024 (UTC)

The hex colour codes are correct and normally work fine; however, when one is comparing a diff with highlighted text such as [19] the colours are more bold and vivid than before.

Diffs where text is not highlighted such as [20] appear fine however. Traumnovelle (talk) 00:20, 21 June 2024 (UTC)

Just wanted to remark that the colours are interfering with the ability to highlight text (for example, for copying and pasting)—the highlight can't be seen against the purple colour. — SGconlaw (talk) 02:33, 21 June 2024 (UTC)

The colours used when marking text for copy and paste are a feature of your browser and/or operating system, we have no control over them. There aren't even any CSS pseudo-classes, CSS background properties or CSS color properties that might provide any means of selection or setting. --Redrose64 🌹 (talk) 07:07, 21 June 2024 (UTC)

Pseudo-element ::selection applies styles to the part of a document that has been highlighted by the user (such as clicking and dragging the mouse across text). —⁠andrybak (talk) 09:51, 21 June 2024 (UTC)

@Novem Linguae: thanks for that version. It worked with my monobook. I was fearing I'd have to stop editing here, it was that bad. My eyes hurt and watered. -- Valjean (talk) (PING me) 22:12, 21 June 2024 (UTC)

Thanks for this. The new colors are awful and non-intuitive. Some1 (talk) 22:30, 21 June 2024 (UTC)

Why isn't that a setting in preferences? I already have problems with my head hurting lately, and high contrast on my computer or phone screen doesn't help. LilianaUwU ^{(talk / contributions)} 03:07, 21 June 2024 (UTC)

Speaking of which, there already is a gadget called "Display diffs with the old yellow-and-green colors and design". Time for another one? lol Nardog (talk) 03:15, 21 June 2024 (UTC)

I mean... why not. LilianaUwU ^{(talk / contributions)} 03:19, 21 June 2024 (UTC)

Or you can paste the old diff color CSS code that NL made to your Meta global.css page. Codename Noreste 🤔 Talk 19:50, 21 June 2024 (UTC)

Novem Linguae's version worked for me. -- Valjean (talk) (PING me) 22:13, 21 June 2024 (UTC)

This should be some type of setting one can easily toggle. -- Valjean (talk) (PING me) 22:15, 21 June 2024 (UTC)

New color for added text in diffs?

Is it just me, or has --background-color-content-added changed to a lilac #afb6e9 from the previous blue? The color contrast's awful now. Aaron Liu (talk) 17:39, 21 June 2024 (UTC)

see #Heads-up: Diff colour above. Nthep (talk) 17:49, 21 June 2024 (UTC)

Recent change to colors in "Difference between revisions" window?

When I look at the "Difference between revisions", the colors have been changed. When did this happen? It is now more difficult for me to read the text. The previous version worked fine. -- Valjean (talk) (PING me) 21:47, 21 June 2024 (UTC)

Wikipedia:Village_pump_(technical)#Heads-up:_Diff_colour -- GreenC 21:51, 21 June 2024 (UTC)

Thank you! I'll check it out. I hope it isn't a permanent change, as it's really disturbing to my eyes. -- Valjean (talk) (PING me) 21:57, 21 June 2024 (UTC)

Watched pages at Wikidata

Is this possible to see which pages are already in watch list on Wikidata while on page at ENWP? Is there any icon to show it? Eurohunter (talk) 20:32, 19 June 2024 (UTC)

@Eurohunter: I don't know a way to see on a Wikipedia page whether the Wikidata item for the page is on your watchlist at Wikidata. It's not what you asked for but in case you don't know this, you may be interested in the option "Show Wikidata edits in your watchlist" at Special:Preferences#mw-prefsection-watchlist. PrimeHunter (talk) 21:44, 19 June 2024 (UTC)

@PrimeHunter: Yes, I have it but all the time I visit page at ENWP I don't know if I watch it already in WD. Eurohunter (talk) 15:47, 20 June 2024 (UTC)

Line of text at top of user page or user talk page with statistics

In the past when I was on a user page or user talk page I would see a line of text near the top with the age of the account, number of edits and most recent edit date or something like that. It disappeared a while ago. I've tried some things but couldn't figure out to bring it back. What's the deal? SchreiberBike | ⌨  21:07, 19 June 2024 (UTC)

@SchreiberBike: Are you sure it wasn't just displayed when you hovered over a link and had Navigation popups enabled? PrimeHunter (talk) 21:57, 19 June 2024 (UTC)

Nope. I even tried turning on Navigation popups, but that didn't bring it back. I remember reading about the trick to see that line of text at VPT many years ago and I think I copied some code to one of my code pages, but it stopped some time in the last month or so. I then deleted all the code from the code pages so I could move forward with a clean slate. Thanks for the idea though. SchreiberBike | ⌨  22:07, 19 June 2024 (UTC)

@SchreiberBike: This would be User:PleaseStand/User info, which you attempted to disable two weeks ago (but probably broke instead, hence the subsequent edit). Please note that the <!--...--> tags only work on HTML pages, they are not valid Javascript for which the comment syntax is /* ... */. --Redrose64 🌹 (talk) 22:18, 19 June 2024 (UTC)

@Redrose64: That did the job. Thank you for your help. SchreiberBike | ⌨  22:35, 19 June 2024 (UTC)

I think this is the XTools gadget. Izno (talk) 22:14, 19 June 2024 (UTC)

@Izno: Nope, but that's interesting too. Thank you. SchreiberBike | ⌨  22:39, 19 June 2024 (UTC)

Delay after editing pages found by insource search

I Wikignome IMDb errors using this insource search. Tonight, I corrected about a dozen articles based on the hits (see my contributions for details). Usually, if I repeat the search, the hits are gone as soon as I've made the relevant correction but this time they only disappeared slowly: the search is still giving six hits despite, in reality, the articles currently not having the issue searched for! Is this a known behaviour? Mike Turnbull (talk) 21:13, 19 June 2024 (UTC)

I sometimes see delays in search results, not specific to insource. The time stamp at the search result shows the searched revision but doesn't reveal if there is a newer revision. I assume any search will be based on the same revision until the search index is updated with a newer revision. Navigation popups shows how long ago a page was edited when you hover over a link. This time should always be up to date. PrimeHunter (talk) 21:53, 19 June 2024 (UTC)

Thanks, I thought I was cracking up! I do use navigation popups and can see the discrepancy in the times: there are still six hits as I write and the oldest is now ~ 2 hours out-of-date. Mike Turnbull (talk) 22:01, 19 June 2024 (UTC)

In case you don't know how a search index works: It's far too slow for the software to actually search every page when a user performs a search. For efficiency reasons, a search index is built, e.g. listing all pages with "imdbtitle" in the wikitext. This search index has to be updated every time a page is saved. I remember years ago when the search index of all pages was always only updated once a day, and some days skipped the update. PrimeHunter (talk) 22:13, 19 June 2024 (UTC)

Yes, over the years I've had experience with Db2 and Oracle for large scientific databases. I just hadn't noticed such latency here on Wikipedia before. Mike Turnbull (talk) 09:09, 20 June 2024 (UTC)

They recently introduced such a latency, it would take 10 mins to process. Sjoerd de Bruin (talk) 16:02, 20 June 2024 (UTC)

Bugs persisting after last week

Hello! Ever since the infobox bugs last week, I've been experiencing some issues. Just wanted to let you know.

1. The search bar at the top of the page disappears if I zoom in on the page too far. I usually read and edit WP zoomed-in, and this doesn't usually happen.
2. On Talk pages, the WikiProject headers have lost their icons.
3. When I'm in the visual editor and I click the number for an inline citation, the full citation pops up in a box like usual, but sometimes I am unable to click links in the citation.

Thanks! Wafflewombat (talk) 16:19, 20 June 2024 (UTC)

@Wafflewombat: Regarding no. 1: the search bar does not disappear, it collapses into a magnifying glass icon - try clicking that. No. 2 doesn't happen for me. --Redrose64 🌹 (talk) 18:27, 20 June 2024 (UTC)

Do you know if the search bar is supposed to collapse, or if the collapsing is a glitch? Wafflewombat (talk) 21:16, 20 June 2024 (UTC)

@Wafflewombat Re: 1 - If you zoom-in far enough using your browser's settings, the page will eventually switch into the layout that it uses for everyone if their browser-window is less than 1120pixels wide (which doesn't use the sticky header)

Re: 2 - It might help if you could link to an example page, and describe what icons you used to see at that example, but no longer see. E.g. I don't see any missing icons at Talk:Cat. (It might also help if you clear your browser cache with a hard-refresh, cf. WP:REFRESH.)

Re: 3 - Matma Rex has covered below. Quiddity (WMF) (talk) 01:10, 21 June 2024 (UTC)

I figured out the icons issue, but I still find the search bar issue strange, because it's disappearing at a zoom level that I always use, and it didn't disappear at that zoom level before. Not a big deal, though. I can live with it, if it's not a problem for anyone else. Wafflewombat (talk) 01:22, 21 June 2024 (UTC)

When I'm in the visual editor and I click the number for an inline citation, the full citation pops up in a box like usual, but sometimes I am unable to click links in the citation.

This is now filed as T368119. Matma Rex talk 01:09, 21 June 2024 (UTC)

Just a heads-up, this clicking problem in the VE is now happening with other buttons in addition to the inline citations. Wafflewombat (talk) 06:22, 21 June 2024 (UTC)

@Wafflewombat Hi, please could you describe which specific other buttons you are experiencing problems with? (I tried opening an article in VE and clicking random things, but everything else worked as expected.) Thanks. Quiddity (WMF) (talk) 17:39, 21 June 2024 (UTC)

Thanks for the message. The other buttons are working properly now, but the links within citations I mentioned above are still not functioning. Wafflewombat (talk) 17:48, 21 June 2024 (UTC)

Category:Wikipedia requested photographs of

This page, which redirects and seems completely redundant to Category:Wikipedia requested photographs, has been created three times since November 2023 (twice so far this month). The first two creations were misplaced userspace drafts. As I type, it's slowly being populated with talk pages, with the corresponding redirect link being left behind on each talk page. I've just switched it from a "hard" to a soft redirect in line with WP:R#CATEGORY.

Does anyone know why this category is continuing to be populated? Also, considering its recreations, has there been some kind of template documentation change somewhere on en.wiki which keeps leading users to this page?

I'm not sure the category must be deleted, but seeing as the category title is longer than the one it redirects to, keeping it seems rather pointless to me.

I'm in half a mind to just G6-delete and re-salt on account of the technical issues from the category population, but I'm intrigued... SuperMarioMan (Talk) 20:51, 20 June 2024 (UTC)

I am pretty sure this is due to |image-needed= not being set up correctly or there being something not quite working in Module:WikiProject banner. @MSGJ? Izno (talk) 20:58, 20 June 2024 (UTC)

• Soft-redirecting appears to have stopped the category population. When it was a hard redirect, the category seemed to be accumulating talk pages at a rate of ~10 a minute. SuperMarioMan (Talk) 21:10, 20 June 2024 (UTC)

Correction: the category is still populating, but more slowly. SuperMarioMan (Talk) 21:57, 20 June 2024 (UTC)

The code is in Module:WikiProject banner/auxiliary. I see it looks whether a category of the form Category:Wikipedia requested photographs of {{{topic}}} exists. If it does then it uses that category, otherwise it will use the default, which for biographies is Category:Wikipedia requested photographs of people. So creating Category:Wikipedia requested photographs of has actually caused this problem. But I obviously need to update the code so that a blank topic parameter will be considered. — Martin (MSGJ · talk) 22:34, 20 June 2024 (UTC)

I posted a similar query at the module's talk page. – Jonesey95 (talk) 23:09, 20 June 2024 (UTC)

I think that the main problem is that Category:Wikipedia requested photographs of got created - this occurred yesterday, and was done by The Sharpest Lives (talk · contribs). The code in Module:WikiProject banner/auxiliary relies on the non-existence of that category page. We may need to delete it, and then WP:NULLEDIT every page in the category. --Redrose64 🌹 (talk) 07:16, 21 June 2024 (UTC)

I assume it got created because it already contained some pages, which I don't understand. But anyway I have updated the module code so this should no longer happen — Martin (MSGJ · talk) 07:31, 21 June 2024 (UTC)

Apologies – I created the redirect because I noticed it was on Special:WantedPages with thousands of links. I thought that making the category a redirect would "move" the pages into the correct category, but I'm sure now that that's not how all this works. Sorry for any trouble. – The Sharpest Lives (💬•✏️•ℹ️) 12:53, 21 June 2024 (UTC)

@The Sharpest Lives: If a page uses mw:Help:Extension:ParserFunctions##ifexist then it causes an entry in WhatLinksHere for the tested page, and probably also counts in Special:WantedPages. A template may make thousands of ifexist checks of the same page. It doesn't imply somebody wants the page to exist, or that anything actually links to the page. PrimeHunter (talk) 15:42, 21 June 2024 (UTC)

A null edit isn't needed, a purge with forcelinkupdate works. Eventually the job queue should get around to doing that due to the module edit, but I don't know how long that might take or if there's job queue breakage of some sort at the moment. Anomie⚔ 14:57, 21 June 2024 (UTC)

Mysterious alteration of anchor

Resolved

I made two edits, to Template:Citation Style documentation/title and to Template:Citation Style documentation/quote. The second one works to allow a link like Template:Cite web#csdoc_trans-quote, but the first one doesn't work - the link Template:Cite web#csdoc_trans-title fails. Checking the HTML emitted by Template:Cite web, I find that the intended anchor id="csdoc_trans-title" is being silently altered to id="csdoc_trans_title" but id="csdoc_trans-quote" is left as intended. Does anybody know why the behaviour differs? --Redrose64 🌹 (talk) 21:37, 20 June 2024 (UTC)

csdoc_trans_title appears in Template:Citation Style documentation/web, could that have something to do with it? That's the extent I have looked at it, haven't perused around the code. – 2804:F14:80D0:4F01:D5D6:530:F7B:3C2A (talk) 21:45, 20 June 2024 (UTC)

The markup in Template:Citation Style documentation/web is transcluded from Template:Citation Style documentation/title, and the third entry in the search provided shows the correct markup. --Redrose64 🌹 (talk) 21:56, 20 June 2024 (UTC)

Maybe I'm just misunderstanding things, but neither /web nor /title appear to transclude each other, they're both manually written, even if it's the same content. /web is trancluded in Template:Cite web... personally I would just have tested if changing it in /web and purging the cache fixed Template:Cite web#csdoc_trans-title, but I don't know the reasons for the id being what it is and am afraid of messing things up. – 2804:F14:80D0:4F01:D5D6:530:F7B:3C2A (talk) 22:07, 20 June 2024 (UTC)

@Redrose64: Eh, I didn't see how changing it could break anything, so I did change it(diff) - Template:Cite web#csdoc_trans-title now works. – 2804:F14:80D0:4F01:D5D6:530:F7B:3C2A (talk) 22:29, 20 June 2024 (UTC)

This sounds like a MediaWiki parsing error, and if I had a suspicion of cause it would have to do with title being a valid HTML attribute. Izno (talk) 21:56, 20 June 2024 (UTC)

On that basis, Template:Citation Style documentation/title#csdoc_trans-title would also fail, but it works. --Redrose64 🌹 (talk) 22:03, 20 June 2024 (UTC)

Both of the links you gave, Template:Cite web#csdoc_trans-quote and Template:Cite web#csdoc_trans-title, work for me. Matma Rex talk 23:29, 20 June 2024 (UTC)

I fixed #csdoc_trans-title, as I mentioned above. – 2804:F14:80D0:4F01:D5D6:530:F7B:3C2A (talk) 23:56, 20 June 2024 (UTC)

Thanks. It totally missed me that Template:Citation Style documentation/web did things its own way. Late evening and sleepy, I guess. --Redrose64 🌹 (talk) 07:09, 21 June 2024 (UTC)

Getting a list/count of values of a parameter.

(not real example). Template Infobox:Guinea Pig has a parameter called "Tail color". I'd like to be able to see what values this parameter has over all articles that use the infobox. (I asked on the help desk and got no response)Naraht (talk) 21:46, 20 June 2024 (UTC)

Bambots TemplateParam supports it for templates that have TemplateData. Izno (talk) 00:14, 21 June 2024 (UTC)

Any template that has a TemplateData section filled out in its documentation should also have a {{TemplateData header}} template. That header template contains a link to a report, generated monthly, of parameter usage. If the template you are interested in does not have a TemplateData section yet, one will have to be added. After that, the bot runs sometime around the 10th of each month and generates a report. – Jonesey95 (talk) 01:42, 21 June 2024 (UTC)

"updated since your last visit" stopped working on WP:RSN

The "updated since your last visit" feature (where that text is displayed next to revisions in the edit history) has stopped displaying for me on Wikipedia:Reliable sources/Noticeboard. It still works on other pages. I suspect the issue is the extraordinary size of Wikipedia:Reliable sources/Noticeboard, currently 1,051,395 bytes. Is this a known issue, that this feature fails on large pages? It is not overly pressing, as it seems some big discussions are going to be archived off that page soon, bringing the size back down. -sche (talk) 00:20, 21 June 2024 (UTC)

Ensure Preferences -> Gadgets -> Watchlist -> Subtle update marker is checked. Separately, ensure you're watching that page still. Izno (talk) 00:23, 21 June 2024 (UTC)

Thanks. I checked and I still have it enabled, and still have the page watchlisted. And now it's showing up for me on that page again. It had always continued showing up for me on e.g. WP:AN, even when it wasn't showing up on RSN. I guess it was a temporary glitch. (If it stops showing up again, I'll report back.) -sche (talk) 01:22, 21 June 2024 (UTC)

The time allocated for running scripts has expired

Hello, appear to get red messages of "The time allocated for running scripts has expired." As an example there is 3 messages at end of Bridlington and The Wolds (UK Parliament constituency). The page does not display the templates at the end of the article. I have tried a dummy edit on page to see if that will clear the problem. The page is OK when viewed in edit preview, wikitext editor. Keith D (talk) 12:26, 21 June 2024 (UTC)

A purge seemes to have fixed it. — xaosflux ^Talk 13:20, 21 June 2024 (UTC)

@Keith D: This has been affecting random pages at random times for some weeks, all you need to do is WP:PURGE. --Redrose64 🌹 (talk) 16:06, 21 June 2024 (UTC)

Proposals

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.

Add nowrap for para

Wrong venue. Copied from the edit request at Template talk:Para#Add nowrap for para, which was rejected as "consensus required". April 2023 attempt to seek said consensus received no response. That system leaves a lot to be desired.

I used {{para}} and got a line break after the pipe character. This looked ridiculous and makes little sense. I assume other line breaks would be possible, such as after a hyphen in the parameter name. Adding {{nowrap}} or equivalent would make far more sense than requiring editors to code, e.g., {{nowrap|{{para|archive-url}}}}. While Note 2 below the table at "General-purpose formatting" speaks of nowrap options, I'm at a loss to see how they help my situation. In any event, I don't see how automatic, unconditional nowrap for all uses of {{para}} could be the slightest bit controversial. At the very least, an option could be added to suppress the default of nowrap for cases where horizontal space is limited, such as in tables.

See also Template talk:Para#no line-breaks in output, where a request for this was ignored (or never seen) 13 months ago. As to If the proposed edit might be controversial, discuss it on the protected page's talk page before using this template., well, we've seen how effective that was. ―Mandruss ☎ 21:53, 5 May 2024 (UTC)

It's unfortunate that the edit request was declined, when this seems like a fairly straightforward improvement and there seems to be a silent consensus to implement. I will plan to implement unless there are objections (courtesy pinging @Redrose64 as edit request responder). (Yes, coming here for this is a little POINTy, but the frustration at the edit request is understandable, and in any case let's not get bogged down by process concerns. Next time, though, I'd suggest replying to or talk page messaging the edit request responder.) Sdkb ^talk 22:05, 5 May 2024 (UTC)

Thanks. I did reply to Rose, with a ping, a mere four minutes after her rejection. When she hadn't replied after another 25 minutes, I surmised that she wasn't going to. Mea culpa: If I had checked her contribs, I would've seen that she hadn't made an edit after the rejection, so it's likely she left the site during those four minutes. Now self-flagellating for one hour. In any case, Rose doesn't change her mind much in my experience; she's that good.

I fail to see any POINTiness here; I'm just playing the cards I was dealt. ―Mandruss ☎ 22:22, 5 May 2024 (UTC)

I'm generally against adding nowrap, and would rather see it's use curtailed. It's causes endless formatting issues for those not using desktop screens, where the auto-formatter would do a better job. Nor do I see how not having 'para' wrap is an improvement, wrapping won't lead to any misunderstanding and may not even be wrapped on different screen aspects. -- LCU ActivelyDisinterested «@» °∆t° 01:46, 6 May 2024 (UTC)

From a usability standpoint, |archive-url= should all be on one line, not wrapped, because "archive-url" is a single concept (the parameter name) and should not be split in any way, despite the hyphen. I do not find broader ideological opposition to nowrap persuasive if it is applied reflexively to this circumstance without considering the particular situation here. I would find examples of instances in which parameters should be wrapped much more persuasive. Sdkb ^talk 02:36, 6 May 2024 (UTC)

It would be helpful to hear from TheDJ, who appears to have disabled nowrapping after it had been in place for about 11 years. – Jonesey95 (talk) 04:04, 6 May 2024 (UTC)

Yes. Applying nowrap to anything longer than a word is really bad practice and causes many issues for mobile, and situations where width is restricted. if you are going to apply it, apply it just to to the param= part, not to values (which can be giant urls) and definitely not to the entire line. A lot has changed in 11 years. —TheDJ (talk • contribs) 06:30, 6 May 2024 (UTC)

One of the problems here is that people give examples of common usages of this template. The problem is that those are NOT the only usages of the template. Even the doc page of the template itself has examples of pretty long values that basically form an entire sentence. Making an entire line not wrap is bad. Htm has to be flexible for many situations and if you set a very strict css option on a very generic template block that has very differing uses, you will run into problems like this. Solutions are to make the css more targeted (which in this case means being more strict about what the parameters can be, instead of just wrapping the template around a block of arbitrary text) or applying the css more targeted. |archive-url= for instance is ok.it just requires more thought by those writing the uses. —TheDJ (talk • contribs) 06:57, 6 May 2024 (UTC)

Applying it only to the param= part sounds reasonable. Sdkb ^talk 14:14, 6 May 2024 (UTC)

I'd be happy with that, provided it included the pipe character (that was the case that brought me here). ―Mandruss ☎ 16:29, 6 May 2024 (UTC)

@TheDJ: Looks like a limited-participation agreement, but I don't see any edit activity to the template. And this is due to fall off the page in three days. At the least, this comment will keep it for another nine. ―Mandruss ☎ 20:01, 12 May 2024 (UTC)

Keep for another nine days. ―Mandruss ☎ 20:48, 21 May 2024 (UTC)

Surely |quote=Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. should be wrapped, although "|quote=" should not be. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:59, 28 May 2024 (UTC)

• Support nowrapping the parameter-name, per Sdkb. The left side of param=value is a specific string of characters, not ordinary text, so it's best that it stays unified so it can be recognized or discussed correctly. DMacks (talk) 20:54, 21 May 2024 (UTC)
• Support binding the leading pipe with the first alphanumeric string of the first argument passed to the template. I don't much care if |chapter-url-access= wraps on a hyphen, and certainly the "value" passed to the template should be able to wrap (think |title=Dictionary of Law, Containing Definitions of Terms and Phrases of American and English Jurisprudence, Ancient and Modern: Including the Principal Terms of International, Constitutional and Commercial Law; with a Collection of Legal Maxims and Numerous Select Titles from the Civil Law and Other Foreign Systems 1891), but it's disorienting to receive as output |
date=. Folly Mox (talk) 12:11, 31 May 2024 (UTC)

  Redrose64 (as original declining admin), I count here five editors including myself supporting adding {{nowrap}} to the "parameter name" ($1) of {{para}}, with one editor neither supporting nor opposing that specific implementation, and all of us expect possibly the OP opposing nowrapping all arguments to {{para}}. Is that sufficient consensus for change? Folly Mox (talk) 12:29, 6 June 2024 (UTC) updated 13:39, 6 June 2024 (UTC) per below

  OP (me) supports nowrapping the whole parameter name, including the pipe character, no matter how long the parameter name is. For longer parameter names at the ends of lines, we can waste a little space without costing me any sleep. OP does not support nowrapping the parameter value, if any. ―Mandruss ☎ 12:39, 6 June 2024 (UTC)

• Support binding |1= from the leading pipe through the trailing equal. However, I oppose nowrap for |2=. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:16, 6 June 2024 (UTC)

Keep for another nine days. ―Mandruss ☎ 12:11, 15 June 2024 (UTC)

Setting focus to the search box by default

I would guess that most of the time one opens Wikipedia it's to search for something.

It would be so very much easier if, when the page is opened and after a search, focus could be set to the search box, and any content there be selected.

Please. AlStonyBridger (talk) 21:06, 1 June 2024 (UTC)

See the FAQ on WP:VPT. In short, WP will not be setting focus on the search box. DalsoLoonaOT12 (talk) 21:58, 1 June 2024 (UTC)

Text:

No, we will not use JavaScript to set focus on the search box.

This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

DalsoLoonaOT12 (talk) 22:01, 1 June 2024 (UTC)

Random Article Feature Could Use Some More Work

I have come to observe that the random article function on wikipedia doesn't make use of the logged history of one's past searches e.g. A person who maybe predominantly searches and edits sports articles, biographies, scientific or whatsoever type of article, the random article that might be brought up could be something of a far different angle, e.g. medievial hisory, gothic architecture or even ancient people/languages. So I want to request if there could be a change to this, because sometimes I may want to edit an article, preferably stubs, on a topic that I'm interested in by using the random article feature and it brings out something else! So, I believe there could be a few needed adjustments here so that random articles will get the interest of the editor/reader by following the past pattern of the user's search history, and making the work done faster and more enjoyable. elias_fdafs (talk) 00:41, 3 June 2024 (UTC)

If it draws from a selection of articles based on what topics a given editor isn't contributing to, then it isn't very random, is it? Also, I'd have concerns about the feature automatically tracking and analyzing my contributions. Cremastra (talk) 00:54, 3 June 2024 (UTC)

Try Special:RandomInCategory instead. Folly Mox (talk) 01:07, 3 June 2024 (UTC)

And if that's more technical or specific than what you're looking for, you could try enabling the Newcomer Homepage (if you haven't already) select all tasks from the Suggested Edits pane, then choose a topic or topics you're interested in working on. Folly Mox (talk) 01:13, 3 June 2024 (UTC)

The problem with Special:RandomInCategory is that it doesn't know how to drill down through high-level cats. To use the examples here, Category:Sports, Category:People, and Category:Science are all useless for a RandomInCategory search. I tried a few experiments using Google's site: qualifier, i.e. site:en.wikipedia.org science. The results weren't terrible, but not as good as I would have hoped. RoySmith (talk) 15:15, 3 June 2024 (UTC)

You can try combining sort=random with articletopic: (like this) or with deepcat:, but deepcat: will fail for such large container categories as listed just above (it even fails against Category:Gothic architecture) due to the number of subcategories. Folly Mox (talk) 11:38, 5 June 2024 (UTC)

Some of the WikiProject categories might actually be more suitable for the OP's task than the content categories. (The discussion shows that this is one of the disadvantages of the "tree" model for categories as opposed to the "tag" model). —Kusma (talk) 11:51, 5 June 2024 (UTC)

Non-free license template for thumbnails of online videos

Should an image copyright template be made for copyrighted online video thumbnails, presumably derived from those for non-free title cards and for non-free video screenshots. It would ideally be titled Template:Non-free video thumbnail. JohnCWiesenthal (talk) 03:48, 11 June 2024 (UTC)

Create a Wikipedia for Arbëresh language

Hi dear Wikipedians!

I am from Albania and I have a request. Can you consider to create a Wikipedia for Arbëresh language, an Indo-European language which belongs to the Albanian language family and is spoken in Italy, but this language is different from Albanian and isn't mutually intelligible with Standard Albanian. That's why I am requesting to someone who can contribute and make available a Wikipedia in Arbëresh language, in order to keep this language alive and for Arbëresh speakers, which are different from Albanian speakers, to have their own Wikipedia and to create and also edit articles on their own Wiki. Thanks SanoIsufi (talk) 10:13, 13 June 2024 (UTC)

I think you need to post at Meta and show how it is more useful than Gothic. Best of luck! ——Serial Number 54129 10:17, 13 June 2024 (UTC)

Just by the way that’s not a fair comparison. Gothic is extinct and not even fully attested due to a tiny corpus, but people in villages somewhere actually speak Arbëresh. But yes, Meta is the correct place. RadioactiveBoulevardier (talk) 16:37, 20 June 2024 (UTC)

This is not something that editors on the English Wikipedia can help with. Requests for new languages need to be made on meta, specifically at m:Requests for new languages. However, before making a new request it is important that you first read the m:Language proposal policy and follow the instructions at m:Language committee/Handbook (requesters). Thryduulf (talk) 10:20, 13 June 2024 (UTC)

One important step in getting the Wikipedia approved is starting it in the incubator. The ISO code here is aae. Animal lover |666| 00:29, 16 June 2024 (UTC)

Mechanism for requesting a neutral facillitator for RfCs

A mechanism where editors sign up to do this role and get selected/pinged randomly by a bot to make an RfC where the involved editors feel they wouldn't be able to be neutral or facilitate discussion and target common ground. The botched RfC I've done at Talk:United States is what propels me to ask for this, I'm too passionate about it and can't find neutrality/respectful constructive discussion. I'm sure this issue is commonplace and I think this would be a good solution, similar to 3O. Alexanderkowal (talk) 11:59, 16 June 2024 (UTC)

It's certainly true that there are a lot of RfCs that waste a lot of time or affect results with the way they're initially presented, so there could be something here. We could create a 3O for RfC development, but I'm not sure how often it would be used and I'm not sure how many people there are who loves developing RfCs on topics they have no interest in and would actually be good at doing so. At the end of the day, I think what could be accomplished through such a process could probably get just as much pre-RfC buy-in from just using the talk page to workshop it first. Then if people object to your framing, well they shouldn't helped you to write it. — Rhododendrites ^talk \\ 13:21, 16 June 2024 (UTC)

yeah that might be a better idea, start a topic about workshopping the rfc. If people agree, that might make a good section at WP:RfC Alexanderkowal (talk) 14:59, 16 June 2024 (UTC)

A proper RFCbefore, equivalent to workshopping, usually leads to a decent RFC, or it should. Selfstudier (talk) 15:16, 16 June 2024 (UTC)

I just think the role @BilledMammal is currently doing at Talk:Kerma kingdom#Requested move 9 June 2024 is so important and necessary for rfcs Alexanderkowal (talk) 20:57, 16 June 2024 (UTC)

@Alexanderkowal Intermittently I have been trying to play a role of discussion facilitator for an example at Talk:Jinn. IMO Probably three type of experienced users can play such role WP:3O volunteers, WP:DRN moderators and substantial experience in RfC closing. Bookku (talk) 07:28, 21 June 2024 (UTC)

Specially new users are interested in starting RfC and they do not know ins and out, facilitators can be good help. Bookku (talk) 07:31, 21 June 2024 (UTC)

That’s great, I suppose WP:DRN does this role well. Maybe at WP:RFC have a sentence saying “If there is minimal collaboration and you feel you can’t be neutral when designing the RfC, go to WP:DRN” Alexanderkowal (talk) 09:23, 21 June 2024 (UTC)

I would support that,

• presently #Responding to an RfC says "..If you feel an RfC is improperly worded, ask the originator to improve the wording, or add an alternative unbiased statement immediately below the RfC question (after the {{rfc}} tag). You can also ask for help or a second opinion at Wikipedia talk:Requests for comment. ..".
• Presently #Responding to an RfC largely goes unnoticed. Bookku (talk) 09:35, 21 June 2024 (UTC)

Yeah I think it’d reduce the chance of malformed RfCs and address wasting editors time Alexanderkowal (talk) 09:42, 21 June 2024 (UTC)

In this latest example one new user went on to begin RfC on their own with personalized complaint. As a discussion facilitator I added a neutrally worded question. Discussion facilitators can have a role. Bookku (talk) 08:42, 21 June 2024 (UTC)

I have seen Robert McClenon play this role at WP:DRN a few times. When filing a DRN case, you fill in a field asking "How do you think we can help resolve the dispute?". It would be reasonable to say "I would like the dispute participants and the moderator to work together to craft a brief, neutral statement and start an RfC." Firefangledfeathers (talk / contribs) 12:19, 21 June 2024 (UTC)

What would happen if the other involved editors say this would be a waste of time, meaning the rfc is unlikely to be made neutral? Alexanderkowal (talk) 12:23, 21 June 2024 (UTC)

I am ready to perform this role again when requested. If the other editors do not want to participate, then I will consider whether I can write a neutral RFC based on working with one participant. It takes a minimum of one involved editor and a facilitator. Mediation requires that the principal involved editors be willing to work with the mediator, but facilitation can be done by the facilitator and one involved editor. It is true that one disruptive editor can gum up the process, but one disruptive editor can gum up many processes, and that is what topic-bans are for. It is also true that one really disruptive editor can ignore a topic-ban and break things, but, unfortunately, that is what indefinite blocks are for. Robert McClenon (talk) 13:12, 21 June 2024 (UTC)

yeah I'd be happy to help out at WP:DRN once I'm more familiar with policy and done the training, it sounds like a good role Alexanderkowal (talk) 13:18, 21 June 2024 (UTC)

Idea lab

Wikipedia Hall of Fame?

What are your thoughts? Is it going to work? Comment down below. Wolverine XI ^{(talk to me)} 17:28, 8 April 2024 (UTC)

i think it would be pretty cool, maybe for significant editors. Cyb3rstarzzz (talk) 10:09, 14 June 2024 (UTC)

Hall of fame topic; section break 1

• I'll bite. What do I get? Like, a room with a comfy chair? The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons. BD2412 T 17:37, 8 April 2024 (UTC)

  "The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons." That's a good point. Though, IMO, I don't think HOF should be behavior-exclusionary and should be open to anyone who has made an enduring impact on WP, regardless of how they made the impact. For instance, I say induct Jordan French (maybe not in the inaugural cohort, but eventually). Chetsford (talk) 18:47, 8 April 2024 (UTC)

  I agree with Chetsford on this. Wolverine XI ^{(talk to me)} 04:11, 9 April 2024 (UTC)

  French certainly made an impact but then so did many LTA vandals. If this idea is adopted, it seems appropriate to limit membership to those who have shown altruism rather than encouraging those who make Wikipedia worse for personal gain. Certes (talk) 08:24, 9 April 2024 (UTC)

  Never say never. Wolverine XI ^{(talk to me)} 13:16, 9 April 2024 (UTC)

  Yeah, that's a good point, Certes. I think this was intended more as an exaggeration for emphasis that we not be rules-bound for a HOF, but probably not a good example to underscore that! Anyway, I agree with your suggestion. Chetsford (talk) 15:26, 9 April 2024 (UTC)

• We already have a lot of perks for experienced editors (Special holidays, Wikimedian of the Year, Editor of the Week, Service awards, ...), and I honestly don't think we need yet another way to separate "elite" Wikipedians from the rest of us. Chaotıċ Enby (talk · contribs) 18:02, 8 April 2024 (UTC)
• Similar to Internet Hall of Fame, to be serious, there would need to be a reliable advisory board. They can help surface little known but important people from the early founder days. It could be a popular vote nomination process, like the Nobel, but picking the winners would need a small august body, known for deep institutional knowledge and experience. After a few rounds/years of winners, those winners then become members of the advisory board. Overall this is probably something that should be organized by WMF. Or you can just do it, but it will be another "This one is special. This one is also special" award. -- GreenC 18:32, 8 April 2024 (UTC)

  @GreenC, i like the discussion here of this idea, but how about an opposite approach? such as, anyone who wants to be in the hall of fame, can be?? and maybe split it up by topic, so that it would have some actual useful format to make it readable to others? Sm8900 (talk) 20:10, 17 April 2024 (UTC)

• I like it. While we may have a superfluidity of awards, these cost essentially nothing to produce so I'm not sure I ever understand the resistance. All recognition systems are voluntary and those who don't approve can opt-out. Moreover, a HoF -- if managed through some approximation of the way GreenC describes -- would be different from existing accolades which are either interpersonal recognition (editor to editor) or metric-based recognition (e.g. Four Award, etc.). Chetsford (talk) 18:41, 8 April 2024 (UTC)

Hall of fame topic; section break 2

• Of course they "cost nothing to produce", that's not the problem, the problem is that they give one more excuse to divide Wikipedians between "the ones who have power" (i.e. the unblockables) and the plebs like us. Chaotıċ Enby (talk · contribs) 13:36, 10 April 2024 (UTC)

• It might be a good idea. 3.14 (talk) 19:07, 8 April 2024 (UTC)
• The key questions for any initiative is what is the objective, and how helpful is the initiative in achieving this objective? For recognition programs, it's important to also consider how the selection process will work, and whether or not it will create more difficulties than benefits gained. Recognition programs are tricky because the flip side of selecting some is that many others are not selected, and that can result in conflict. isaacl (talk) 02:36, 9 April 2024 (UTC)

  That's how recognition programs work, but I don't think they'll necessarily cause any conflict. Wolverine XI ^{(talk to me)} 04:09, 9 April 2024 (UTC)

  "it's important to also consider how the selection process will work" After the inaugural cohort is selected, maybe it should become self-perpetuating with all prior inductees selecting each subsequent cohort. (Though you'd still need some system to choose the inaugural cohort.) This would mitigate politicization and degradation as inducted members would have a vested interest in maintaining its reputational coherence. Chetsford (talk) 05:37, 9 April 2024 (UTC)

  That would be difficult if they are dead or so long retired from WP they don't give a toss about the place anymore/are out of touch about who is still active and "deserves" a shout. - SchroCat (talk) 07:44, 10 April 2024 (UTC)

  "would be difficult if they are dead" I imagine it would. Chetsford (talk) 08:48, 10 April 2024 (UTC)

  I would object to exclusion of the deceased. There are some amazing editors who left us too soon, but with great work done first. BD2412 T 02:37, 11 April 2024 (UTC)

  We don't mean a blanket exclusion, just that we will ensure that batches of cohorts keep on coming; this line of discussion was about a proposal to have each cohort select the next. Aaron Liu (talk) 02:59, 11 April 2024 (UTC)

  I don't think we'll select a cohort that are all dead or inactive, for the reasons you've mentioned. Aaron Liu (talk) 11:34, 10 April 2024 (UTC)

  I think it best if you don't have any intake at all: voting for one's friends make this an inbred and insular process. As I've said before (as has Chaotic Enby), this is a bad idea - divisive and with the potential for conflict when the "wrong" people are elected and the "right" people over looked. - SchroCat (talk) 12:02, 10 April 2024 (UTC)

• The English Wikipedia Hall of Fame idea sounds peachy keen, as Babe Ruth would say before tying his hands behind his back and hitting a home run with his neck (Ruth is, all kidding aside, the most underrated ballplayer in baseball history). The initial "class" obviously would include J and L, the pioneering heroes of our story, and I can think of several others who would be obvious. That first class probably shouldn't be large, maybe 7 or 8 inductees. Then the rules get tricky, but doable. In a perfect world we'd lock J and L in a room until they get to a place where they can come up with a plan of how to handle this that everyone says "Of course that's how it should be done". But, bottom line, I think an EWHoF is a good idea all around (without WMF involvement). Randy Kryn (talk) 03:22, 10 April 2024 (UTC)
• A second rate popularity contest with ill-defined criteria? What could possibly go wrong. Terrible and divisive idea. You think someone's great - give 'em a barnstar, or, even better, leave them a thank you note, but to 'promote' people who will undoubtedly be divisive to others? That way grief and conflict lies. And this ignores the fact that "hall of fame" is not a worldwide concept that people everywhere readily grasp or buy into.- SchroCat (talk) 07:44, 10 April 2024 (UTC)

  Schro, the procedure is akin to the Wikimedian of the Year, except that it exclusively concentrates on the English Wikipedia. There's a purpose for these initiatives, and I firmly disagree that this is a "bad idea." Wolverine XI ^{(talk to me)} 13:25, 10 April 2024 (UTC)

  You are, of course, entitled to disagree. For what it's worth, I think the Wikimedian of the Year is a fairly crap award too, being a process with no criteria and something else that divides, rather than unites. Most people are happy to do the work for the sake of the work, not to seek vacuously external praise or validation just because they've caught the eye of someone powerful or happen to be pushing a zeitgeist line of thinking. - SchroCat (talk) 14:44, 10 April 2024 (UTC)

  As you haven't yet stated the purpose behind your suggestion, nor proposed a process, there isn't enough info to understand the potential benefits and costs. There's an understandable view that costs quickly outweigh benefits as any process involves more people, adding up to more total effort expended. isaacl (talk) 16:53, 10 April 2024 (UTC)

Hall of fame topic; section break 3

• More awards? At this rate, all our time will be spent giving ourselves pats on the back and giving each other shiny things. While I don't agree with the more extreme anti-award views (take wiktionary for example; wikt:Template:User barnstar has been nominated for deletion twice, and been described as cheesy and gaudy. I don't think we need all that Wikipedia's tinsel to encourage people.), we shouldn't go overboard with this. Cremastra (talk) 22:07, 10 April 2024 (UTC)

  (the correct link is wikt:Template:User Barnstar, with a capital B. Aaron Liu (talk) 01:51, 11 April 2024 (UTC)

  Thanks. Cremastra (talk) 19:39, 12 April 2024 (UTC)

  It's okay if you choose not to participate in the process. Wolverine XI ^{(talk to me)} 04:55, 11 April 2024 (UTC)

  How would one choose not to participate? I would not participate, but saying so would make it look as if I thought I stood a chance of being elected, which I do not. I imagine that most of those who would choose not to participate think the same way. Phil Bridger (talk) 20:07, 11 April 2024 (UTC)

  Maybe. Wolverine XI ^{(talk to me)} 16:07, 12 April 2024 (UTC)

I don't much like anything on Wikipedia which encourages elitism, political campaigns, cliques, inequality, etc. I can imagine that many wiki-politicians would waste a lot of time campaigning to be elected to a HOF and that the results would be divisive. "How come so-and-so got elected, and I didn't?" Smallchief (talk) 21:44, 12 April 2024 (UTC)

• I think this sort of thing is better left to other sites. Maybe the people who hang out at Wikipediocracy would create a Wikipedia Hall of Fame? Or would it become a Wikipedia Hall of Infamy? Phil Bridger (talk) 08:09, 13 April 2024 (UTC)

  I especially don't like the idea of putting infamous characters in a HOF. Follow baseball standards. Pete Rose and Shoeless Joe Jackson are not in the baseball HOF because of scandal, despite being qualified. No bad actors, no matter how famous, in a HOF. Smallchief (talk) 09:04, 13 April 2024 (UTC)

  Good point, but Wikipedia is not baseball. Wolverine XI ^{(talk to me)} 06:57, 14 April 2024 (UTC)

  Indeed. Baseball is a sport where defeating others on the field is encouraged. Wikipedia is a cooperative endeavour where it's frowned on. Certes (talk) 09:48, 14 April 2024 (UTC)

  Yes, this program is designed for honoring purposes rather than competition. I hope that's clear to all. Wolverine XI ^{(talk to me)} 04:41, 16 April 2024 (UTC)

  In that case, it seems the honor should not be of the Wikipedian itself, but of the work that they accomplished in a given area. That's why the Barnstars exist, of course. Just as WP:NPA encourages us to comment on the content and not on the creator, so too should we be aware to not place individual people on a pedestal.

  Frankly I find it disappointing that, in bringing forth the idea, the OP has not brought forth any comprehensive or detailed arguments in support of this idea and in response to the above critique. We are simply discussing a nebulous concept of recognition, which I think Wikipedia already addresses, and which if people really needed to see more of, they could use other websites or mediums for this purpose. _{Duly signed,} ⛵ WaltClipper -(talk) 12:29, 16 April 2024 (UTC)

  And we do celebrate content, quite satisfactorily, with DYK and TFA. So there is no need for a "hall of fame", it's just more self-congratulation. Cremastra (talk) 20:45, 16 April 2024 (UTC)

section break 4; [wikilounge idea]

• how about a lounge WikiLounge for experienced wikipedians? would that be immediately misused, or could it serve a helpful purpose? Sm8900 (talk) 13:41, 17 April 2024 (UTC)

  That would just be a way to create an in-group, and I don't really see how it would help the project. Chaotıċ Enby (talk · contribs) 13:47, 17 April 2024 (UTC)

  I agree with Enby. What purpose would that serve? Aaron Liu (talk) 15:27, 17 April 2024 (UTC)

  Who decides who is experienced enough? On what basis? I hope it's not edit count, which can vary enormously between people having the same overall effect. Phil Bridger (talk) 15:48, 17 April 2024 (UTC)

  Like an actual lounge, or some cliquey forum that would do nothing to benefit the project? All these ideas go against our core principles. Cremastra (talk) 19:46, 17 April 2024 (UTC)

  ok, fair enough; all of these points are quite valid. so then, how about a lounge which would be labeled as being open to all experienced wikipedians, plus anyone who wishes to shmooze with them? that way, we are actually opening it to everyone, but giving it an underlying theme for those who are interested.

  to use an analogy, it would be like opening a lounge for woodworkers, or one for musicians, or one for ferryboat drivers, and also admitting anyone interested in that specialty. it would be basically open to anyone, and yet the theme would be clearly stated in terms of the specialty which is its actual focus. Sm8900 (talk) 19:56, 17 April 2024 (UTC)

  can an editor nominate themselves for this "Hall of Fame"? if so, then it might preserve the grassroots nature of wikipedia, and still have a positive effect. kind of like hanging out at the local skateboard park, and popping wheelies to show off one's skills to other fellow aficionados. Sm8900 (talk) 20:08, 17 April 2024 (UTC)

  Don't we already have every single needed discussion "board" known to Man? Aaron Liu (talk) 20:24, 17 April 2024 (UTC)

  What would actually be the point of having a lounge with this theme? Like, how would it help the project like, say, the Wikipedia:Teahouse, the Wikipedia:Help desk or the Wikipedia:Administrator's noticeboard does? Chaotıċ Enby (talk · contribs) 21:21, 17 April 2024 (UTC)

  The idea of an "experienced user lounge" very much echoes of Wikipedia:Esperanza which, although it did result in useful derivative projects, very much had a problem back in its day with regards to ingroup/outgroup behavior. _{Duly signed,} ⛵ WaltClipper -(talk) 12:58, 18 April 2024 (UTC)

• One downside of this proposal is that it would involve a fair amount of the electorate's time if they are not to just elect people who they already know. That time would be better spent improving the encyclopedia, which is what we are here for (or at least are supposed to be here for). Phil Bridger (talk) 15:48, 17 April 2024 (UTC)

  another idea; how about simply call it something whimsical or jocular, such as "Wikipedia League of Super-friends"? or "league of adventurers"? that way, it still retains the air of a unique league, yet it would be clear it is not anything awarding actual higher privileges here. Sm8900 (talk) 20:15, 17 April 2024 (UTC)

  I still don't see what the actual point is. Even with a funny name, it will still be a pretty divisive thing. Chaotıċ Enby (talk · contribs) 21:22, 17 April 2024 (UTC)

  Divisive programs, like the WP:Editor of the week, already exist. Wolverine XI ^{(talk to me)} 22:41, 20 April 2024 (UTC)

  And that's not an excuse to have more of them. Chaotıċ Enby (talk · contribs) 22:46, 20 April 2024 (UTC)

  OK, if you say so. Let us see if we can reach a consensus. Wolverine XI ^{(talk to me)} 23:10, 20 April 2024 (UTC)

Section break 5

• Editor of the Week was set up with a specific goal in mind: to demonstrate appreciation of specific positive behaviours and collaborative spirit by its recipients, with an explicit disclaimer that it's not intended to be a judgement about their overall characteristics. It was deliberately set up as a no-big-deal award with a very lightweight process, to avoid making it something that people would argue a lot about. The original pool of candidates was lesser-known editors, in order to give them a bit more encouragement to continue contributing, but has since been broadened to anyone. It's basically a slightly fancier barnstar, with some people slapping recipients on the back with a "good job". As a result of this carefully planned design, it hasn't fostered division. isaacl (talk) 02:05, 21 April 2024 (UTC)

Many such award schemes have been previously proposed. Only two, to my knowledge, still function: WP:QAI, because of the dedication of one editor, and WP:EOTW. If you want another one, set it up and run it yourself—if people like it, you can then apply to formalize it as a Wikipedia-wide process. ~~ AirshipJungleman29 (talk) 12:13, 26 April 2024 (UTC)

• Oppose. I'm not sure what I'm opposing here, but whatever it is, I'm against it.

Anyway, the Service Awards are good because they are purely mechanical and entirely removed from politics. Entirely: If you're banned, you qualify. If everyone hates you, you qualify. If you drove your car up the steps and into the door of the Wikimedia Foundation offices on purpose, you qualify. Also, you continue to accrue service time -- which is measured from the date of your first edit, and does not take into account gaps -- after you're dead. So, if service time is the limiting factor for you, you will progress up the levels even after your demise, and I know of one editor who is. So... Maybe our Hall of Fame could be only for deceased editors. After all, you have to be dead five years before you're eligible for the baseball Hall of Fame. Then I think most people would be "Oh its nice to remember Smith" and not upset about the politics. My 2c. Herostratus (talk) 02:53, 28 May 2024 (UTC)

How about a Hall of Shame?

I know generally we are a bit negative especially when it comes to disruption, which is why we generally note previous hurdles as a cautionary tale of what not to repeat. A reminder everyone is human. A hall of fame will make editors more concerned with scoring brownie points than actually improving the project. Awesome Aasim 20:29, 7 May 2024 (UTC)

We already have Wikipedia:STOCKS, more than this would actually be more harmful than it might help. Chaotıċ Enby (talk · contribs) 20:33, 7 May 2024 (UTC)

Yeah I know. I was just thinking about why we have a hall of shame but not a hall of fame. Awesome Aasim 00:05, 8 May 2024 (UTC)

The stocks aren't a hall of shame, it's a humourous list of mistakes. -- LCU ActivelyDisinterested «@» °∆t° 21:04, 9 May 2024 (UTC)

Awesome Aasim, isn't WP:Long term abuse already kind of that? — 🌙Eclipse ^{(talk) (contribs)} 14:49, 18 May 2024 (UTC)

That page should not really be intended to be a 'hall of shame' due to WP:DENY and WP:BEANS (none of which apply to the village stocks in comparison). Xeroctic (talk) 19:33, 20 May 2024 (UTC)

We already have a hall of shame. Just Step Sideways ^{from this world ..... today} 17:40, 26 May 2024 (UTC)

An idea that might work: A Wikipedia statue

In place of the Hall of Fame, which doesn't seem to be going anywhere, how about this: Wikipedians can request that the Foundation agree to raise funds for and construct a Wikipedia statue featuring Jimbo Wales, Larry Sanger, and a stylized rendition of Wikipedia and Wikipedians enlarged and forever enlarging behind them (with, of course, the incomplete-globe logo somewhere in the mix). This should be a major statue, not a small standing one, and incorporate the full quality and historical significance of the encyclopedia.

Wales and Sanger should have no veto in the idea of their inclusion in the statue but both probably should have input on the final design of their figures portrayed at the time of Wikipedia's founding. Many of the world's major sculptors should either compete for the final design or submit ideas for it. If done well, with a full mix of realism and modern art, it would be beautiful, educational, and honor the two initiators, the tens of thousands of volunteers, and the concept of knowledge itself. Randy Kryn (talk) 00:25, 10 June 2024 (UTC)

Would sound good to me, though I fear that some may think it's spending they should focus on technical debt, which may or may not be valid. Aaron Liu (talk) 01:24, 10 June 2024 (UTC)

Thanks Aaron. It feels like a reasonable idea, the community asking the Foundation to do something like this. As for expense, focused fundraising works. Major funders, both former and potential, often like to focus their money on specific goals. Some may delight in funding the expansion of tech, others would appreciate the chance to fund an artwok, some might be glad to fund a full evening Wikibanquet as well as add more scholarships to the regional conferences. A large well-done statue (and please also appreciate the Wikipedia Monument) dedicated to the free sharing of knowledge would catch the eye of some art loving major funders, so that shouldn't be an issue. If I was a tech giant it'd be funded already. Imagine the design proposals that would come in. Randy Kryn (talk) 03:25, 10 June 2024 (UTC)

Simpsons did it. Just Step Sideways ^{from this world ..... today} 20:07, 10 June 2024 (UTC)

A true Wikipedia statue should be a big framework sphere like this but with the design of the Wikipedia globe logo, and made of little shelves. The public to be encouraged to climb all over it and place (and remove) items of their choosing on the shelves. A webcam to make it a live-streaming sensation. Activate the fountains below to hose it down regularly. Barnards.tar.gz (talk) 21:10, 10 June 2024 (UTC)

Guy brings Vitamin C effervescent tablets Aaron Liu (talk) 11:56, 11 June 2024 (UTC)

An interesting idea, if one drops the silliness of including Sanger. The man had as much input into the founding of this as Ronald Wayne did for Apple. That is, hardly a thing. Zaathras (talk) 00:13, 11 June 2024 (UTC)

Allowing Master's theses when not used to dispute more reliable sources

WP:SCHOLARSHIP generally allows PhD dissertations and generally disallows Master's theses, unless they have had "significant scholarly influence." I feel that this is really locking us out from a lot of very reliable sourcing. I understand that these are often not quite as polished as something like a monograph or PhD dissertation, but often times they are the highest quality sources available about very niche subject matters. They are subject to professional review, they cite their sources, and they are published by reliable institutions. Can we really say that these are less reliable than an entry in a historical society newsletter or an online news report from an assuredly hurried local journalist?

Just today I encountered a 2022 masters thesis, East Meets West in Cheeloo University (doi:10.7916/scmr-6237). As far as I can tell, this is the most comprehensive source available on the architecture of Cheeloo University. But I can't use it, since it's a masters thesis, and as far as Google Scholar can tell, it has yet to be cited elsewhere.

I feel that people should be allowed to use masters theses in certain fields (I can only speak for the humanities, I'd be interested to know this from a STEM perspective) so long as A) They are not used to dispute something said in reliable sources and B) They are not used to confer notability. I feel this would strike a good balance of allowing us to use these often very useful sources, while still recognizing that a book, journal article, or PhD thesis is probably preferable if you have the choice between them. I'd love to hear other folks thoughts! Generalissima (talk) (it/she) 00:43, 7 May 2024 (UTC)

In the stem area I would expect that important research would also be published in journals. I would discourage use of Masters theses rather than disallow. One issue is lack of accessability. Even when referenced, may not be accessible. The lack of "peer" review can also mean there are more errors included. Graeme Bartlett (talk) 02:03, 7 May 2024 (UTC)

Is there any public information generally available about the process of publishing masters' theses for a given university? What level of scrutiny or review is generally applied, etc. I think considering whatever information is available there could lend a lot of clarity to deciding whether a given thesis is reliable. Remsense诉 02:09, 7 May 2024 (UTC)

• The rule in question is a counsel of perfection but perfect is the enemy of good and so WP:IAR applies. By coincidence, notice that today's featured article is about a work which started as a dissertation. The main thing I notice about this is that the readership for this topic is tiny. If you're working on a topic like the architecture of an obscure university that no longer exists, then you're mainly writing to please yourself and so should do what you think best. Andrew🐉(talk) 06:49, 7 May 2024 (UTC)

  I both agree and don't, to the extent that I don't think less popular topics should be viewed as less important as regards our content policies. Of course, I certainly understand the distinction between there being less available coupled with internal motivation, and that. Remsense诉 06:54, 7 May 2024 (UTC)

• I'd question whether Master's theses are really subject to professional review or published by reliable institutions. By professional review, I assume you mean that somebody examines them. But unlike a PhD examination or journal peer review, which both act as barriers to publication, getting a low grade on a Master's thesis doesn't stop the thesis existing. The author can still put it online – presumably without the grade. Also, and speaking as a university teacher myself, the person who examined it examined it as a Master's thesis, not as a piece of publishable research. A middling or good grade means "I think the student did a good job with this material" not "I think this is a reliable source on this subject". As for publication, in my experience most Master's theses are not published (though those that are, e.g. in a journal, certainly become reliable sources). Some university libraries make archived copies available online, but this isn't really the same thing because again, any Master's theses that meets the formal requirements for submission will be there, regardless of quality. – Joe (talk) 07:59, 7 May 2024 (UTC)

  Fair enough, I didn't think about the barrier to publication angle. I guess if we think about them more along the lines of a newspaper article (which can be of wildly different quality) then we could just evaluate them on their own merits. Just like how there is great journalistic coverage of some areas of history and archaeology, there is horrible, misleading coverage; and if it's not used as a major source in the article, it's pretty easy to spot when it's the latter. Generalissima (talk) (it/she) 15:42, 7 May 2024 (UTC)

• Purely anecdotal, but with respect to professional review, the only person on my master's thesis committee (my director) who understood what I was doing left on sabbatical half-way through. His replacement as chair kept me on the straight and narrow in my use of statistics, but knew no more about what I was doing than the rest of the committee. In retrospect, I can say that my thesis did not add anything useful to the sum total of human knowledge. On the other hand, I have dug into the bibliography section in a thesis to find sources I had otherwise missed, but that is a long shot. - Donald Albury 16:20, 7 May 2024 (UTC)
• If we would accept a blog post from the university itself (which would be self-published, primary, and non-independent) for the same kind of contents, then we should probably accept a master's thesis for it. A source only needs to be strong enough to support the weight of the claims it's cited for. If they're non-controversial (e.g., everyone agrees that there are some buildings on the campus), then the source doesn't have to be ideal. WhatamIdoing (talk) 21:53, 7 May 2024 (UTC)

  I believe that you are referring to WP:ABOUTSELF. My understanding of that is that we could cite the thesis for statements about the thesis and the author of the thesis, but not for statements about topics covered by the thesis. Donald Albury 22:33, 7 May 2024 (UTC)

  Not really. With the possible exception of contentious BLP matter, I think we should accept it for pretty much all non-controversial content. WhatamIdoing (talk) 22:50, 17 May 2024 (UTC)

• I agree that rigid exclusion of master's theses does not serve the project well. The language in WP:SCHOLARSHIP regarding Ph.D. dissertations would seem also to address many of the concerns above: Some of them will have gone through a process of academic peer reviewing, of varying levels of rigor, but some will not. If possible, use theses that have been cited in the literature; supervised by recognized specialists in the field; or reviewed by independent parties. (Of course, this issue would also be solved more efficiently by treating this guideline like a guideline to be applied flexibly in service of the mission rather than as a pseudo-policy that must be followed rigidly except in the most exceptional circumstances -- but that seems to be a bit too much to ask these days.) -- Visviva (talk) 04:12, 8 May 2024 (UTC)
• I have come across some very high quality master's theses and agree that rigid exclusion of master's theses does not serve the project well. I had to work around this on Revolt of the Admirals and it was painful. In the case of my own master's thesis, it was thoroughly reviewed by two external examiners (as well as, of course, by my supervisor). It is available online and widely cited in the literature. The PhD was reviewed by three external reviewers, but is not as widely cited, and while also available online, I never got around to publishing it. Hawkeye7 (discuss) 04:47, 8 May 2024 (UTC)

  I think there's some regional differences here. In Europe, a Master's thesis isn't examined by a committee and their are no external examiners, just the supervisor. – Joe (talk) 06:34, 8 May 2024 (UTC)

• I agree that theses provide weak arguments for controversial points, as do other sources often accepted as reliable such as news articles or unreplicated one-off studies (I also think that there are many PhD dissertations that are questionable.) But, in writing research on historical topics, I these can be very useful and informative. They often provide a well-cited overview of a particularly esoteric topic that may not be the focus of a book or major study, which interested readers can read an analyze themselves. I like using them when they can be linked so readers can view them. As others have pointed out, At bare minimum, I'd like to be able to cite them even if they aren't standalone. (e.g., sometimes I can get the point cited by a book by a mainstream press, but it covers the topic in a sentence, whereas the dissertation gives the in-depth detail.) Wtfiv (talk) 20:47, 9 May 2024 (UTC)

Theses are a mixed bag. Master's thesis even more so. I can say that mine went through a rigorous review process (I had a former president of the Canadian Association of Physicists as an external examiner on mine) as well as one other physics PhD, and had two physics PhD as my supervisors. The comments/feedback were substantive and relevant, and had to be addressed before acceptance.

But go to a different department, in the same university, and the reviewing standards and requirements for a master's thesis are quite different. Headbomb {t · c · p · b} 21:34, 9 May 2024 (UTC)

As Visviva said above, if people treat the guideline like a policy that "no masters theses can be cited for anything (or they can only be cited if lots of other people cite and repeat what they say, making it unnecessary to cite them), because we assume no masters thesis has ever been reviewed and made reliable; meanwhile, PhD theses are reliable because we're assuming every one has been reviewed by reviewers who know what they were doing", that's a problem (in fact, it's two problems separated by a semicolon). I think it would make more sense, as Visviva seems to be suggesting, to apply the same kinds of evaluative criteria as are supposed to be applied to PhD theses to both PhD and Masters theses, plus OP's suggestion that we don't use them to contradict a more reliable source; together with the fact that tighter sourcing requirements are already in effect for BLPs, medical topics, and various contentious topics, we'd in practice only cite masters theses when there was reason to think they were reliable for the uncontentious thing we were citing them for, e.g. the architecture of a particular university, which seems reasonable. (As WhatamIdoing said, if we'd accept a passing aside in blog post by the university as reliable for saying the buildings were neoclassical, it seems weird to reject a masters thesis all about the buildings being neoclassical.) Notability seems like a separate issue and it seems reasonable to say masters theses also don't impart much notability. -sche (talk) 00:48, 19 May 2024 (UTC)

• As per Graeme Bartlett's comment, if the underlying research in a master's thesis is of sufficient quality to source, the author should have or would have submitted it for publication to a journal. If sources used in the literature review are beneficial, then just directly cite those, don't cite the thesis (I've used many master's theses to discover references for WP articles, but I've never directly cited the thesis). My thesis was looked at by external examiners but it was certainly not done with the same critical eye as they would have applied to a Ph.D. dissertation. Opening this door seems like a recipe for disaster. Chetsford (talk) 01:04, 2 June 2024 (UTC)
• I think I agree most with WhatamIdoing here. Master's theses face nowhere near the oversight of that PhD theses do, but it's still generally going to be much more thorough work than the newspaper articles that make up the bulk of Wikipedia citations. _signed, Rosguill ^talk 01:35, 2 June 2024 (UTC)
• I used to teach a Master's course at the University of Birmingham (UK)aimed at non-college grads. The thesis was just part of the course. There's no way these could have been used as sources for Wikipedia. I've seen a US thesis which was also part of a taught course and not reliably published — Preceding unsigned comment added by Doug Weller (talk • contribs) 14:23, 13 June 2024 (UTC)
• What Doug said. The only use I'd ever consider appropriate for a Masters thesis not already cited in a published reliable source would be as a research tool for references. The level of scrutiny such material gets varies wildly, and none of it is being examined as material intended for publication. AndyTheGrump (talk) 15:06, 13 June 2024 (UTC)
• I would sooner accept an undergraduate research paper/thesis than say, a newspaper story from 1900 (which often seem embellished). There's no such thing as a medium that is universally perfect by nature of how it is created. Even the Voyager Record reflects the biases of its creation and the time it was made, despite the immense cost and effort put into it. Wikipedians who place newspaper articles above master's theses are cherry-picking which forms of subpar scholarship they care about. There are many, many examples or allegations of subpar reporting from A-grade or B-grade news organizations. You could browse through criticism sections on The New York Times or Reuters, or reference the criticism levied by people like Alec Karakatsanis. Master's theses should be allowed like most other "reliable" sources - on a case by case basis, subject to comparison to other reliable sources. Such theses are often the best or only source on obscure topics, and average arrive closer to verifiability than their exclusion would. Anonymous-232 (talk) 20:07, 16 June 2024 (UTC)

  This is not really addressing the issues being discussed, which are more about a lack of peer review allowing basic errors in rhetoric and research to be transmitted, rather than the more abstract cultural concerns you're gesturing to. We can't "use them on a case by case basis" if there's no other sources to check them for errors against. They're not reliable.Remsense诉 20:18, 16 June 2024 (UTC)

I've used and seen used master's theses in articles, and agree with a lot of the people here. I'm not sure which if any academic departments fully fact check every claim in the master's theses they go on to approve, but the same is true for most publication media. My position can be summarised as Use cautiously and replace with better source where possible.

Also, honestly, have yall seen what's out there in the wild in mainspace? The people who frequent this board tend to be responsible editors, and take our sourcing pretty seriously, but the amount of truly garbage sources cited like they're totally unproblematic is deafening. A master's thesis, despite the potential flaws, is head and shoulders above a blog post, a self-published book, a blog post someone uploaded to academia.edu, a google books search result, ViralFinance.info's "Top 150 Most Disuptive Blockchainers of 2019", an Amazon product listing, a 1930s travellogue published by a popular printing house but cited like it's a legitimate historical source for a period centuries prior, literature that's long been superseded by newer research that's more difficult to access than one-click borrowing from Internet Archive, etc.

Sorry I kinda lost the trail there. In most cases, a master's thesis will not be the best source. But I don't think we need to (nor, indeed, do) straitjacket ourselves with a blanket ban if no one else has bothered to publish on some obscuratum that would improve an article to include. Folly Mox (talk) 20:52, 16 June 2024 (UTC)

Almost completely unrelated, but if we had something like a Reference: namespace, we could attach things like levels of confidence in a source, and represent that somehow to the reader, like changing the little blue clicky numbers from blue to orange for sources that are not too tier. Folly Mox (talk) 20:58, 16 June 2024 (UTC)

@Folly Mox yes! This is something meta:WikiCite/Shared Citations could address ~ 🦝 Shushugah (he/him • talk) 22:32, 18 June 2024 (UTC)

I see I somehow haven't registered my written support for that project, despite being aware of it for a year or so. I see the allure of wanting to make a big software architecture like that work all across the Wikimedia ecosystem, and have concerns about how it would translate technically into different spaces, ✂️ [three paragraphs of yelling at clouds trimmed and binned] Folly Mox (talk) 04:14, 19 June 2024 (UTC)

User:SuperHamster/CiteUnseen adds icons according to RSP. Aaron Liu (talk) 02:16, 19 June 2024 (UTC)

Oh right there is that, and WP:UPSD and User:Novem Linguae/Scripts/CiteHighlighter also provide borderline similar functionality. Folly Mox (talk) 04:04, 19 June 2024 (UTC)

Make the edit request facility optional

An uncontroversial, "change X to Y" request can be done just as easily using a normal discussion thread. The edit request facility exists for low-activity protected articles where there is a need to summon an editor to handle the request; otherwise the request could sit unseen or ignored for years. In my experience, edit request is used far more often for changes that are not uncontroversial, and/or are not in the required "change X to Y" format. This is because users don't take the time to read the instructions presented to them in the request path.

It should be possible to turn off the edit request facility at articles where it isn't needed; i.e., articles that always have editors around. In such cases the edit request path could be replaced by instructions directing the user to the talk page (or saving them a step and presenting the same thing they would get by clicking "New section" at the talk page). ―Mandruss ☎ 22:31, 21 May 2024 (UTC)

Well it is already optional and editors do make requests in text only. The template makes it formal and encourages identifying the exact change, although often not used correctly. Graeme Bartlett (talk) 22:52, 21 May 2024 (UTC)

The use is optional; the facility is not. Again in my experience, editors are spending too much time rejecting "invalid" edit requests (which also wastes the requester's time).

The facility summons an outside editor by placing the article in a maintenance category for that purpose. In my 10+ years at normal-activity articles, I've yet to see a request handled by such an outside editor. Rather, the request is invariably changed to answered=y by a "local" editor, removing the article from the category, before an outside editor arrives to handle it. So, for a normal-activity article, what's the point of the category or the facility? ―Mandruss ☎ 23:26, 21 May 2024 (UTC)

Not every request-reviewer is that lazy. Quite a bit will engage in discussion. Aaron Liu (talk) 23:29, 21 May 2024 (UTC)

And they will do so improperly, all the more reason to turn off edit requests. The edit request instructions are quite clear: "What an edit request IS NOT for: [...] making a comment or starting a discussion: go to the talk page [...]". Again, if discussion is the goal, there is already a way to do that. ―Mandruss ☎ 23:55, 21 May 2024 (UTC)

Hmm. But should people new to a topic carry the burden of assessing whether a talk page is active? Aaron Liu (talk) 01:24, 22 May 2024 (UTC)

I don't understand the question. If you're referring to the requesters, they wouldn't have to make that assessment. It would have already been made by the article's editors (or not). For example, the editors at Donald Trump would turn off the edit request facility and any user clicking "View source" on the article page would be directed to the talk page (or, as I said, the box would be presented to start a discussion thread). More precisely, they would be presented the option to start a discussion thread, just as they're presented the option to submit an edit request today (big blue button).

And, again, if they don't seek discussion—if they have something clearly uncontroversial—a normal thread works equally well for that purpose. Heading: "Typo correction". Comment: "Please correct the spelling of 'envirmental' in the 'Climate change, environment, and energy' section. ~~~~". Done. The only material differences are (1) a more meaningful section heading, hopefully, (2) no need to change to answered=y, and (3) no maintenance category pointlessly involved. ―Mandruss ☎ 02:15, 22 May 2024 (UTC)

Then just add the edit notice for articles where all edits will be controversial. I don't see why we should remove the ER facility, which is still perfectly good for uncontroversial edits. I don't see why editors already being available is a problem. Aaron Liu (talk) 11:31, 22 May 2024 (UTC)

@Mandruss: The facility summons an outside editor by placing the article in a maintenance category for that purpose. In my 10+ years at normal-activity articles, I've yet to see a request handled by such an outside editor. Can you please clarify what you mean by this. Many volunteers watch CAT:ESP and related pages and handle requests. RudolfRed (talk) 02:45, 22 May 2024 (UTC)

@RudolfRed: I'm sure they do, but I've never seen them handle one at an article that always has editors around to handle it. Not once in 10+ years. They simply can't get there fast enough, presumably because they are processing a FIFO queue containing a number of older requests. Even if they could, why bother them when they aren't needed? They have many requests to handle where they are needed. ―Mandruss ☎ 02:56, 22 May 2024 (UTC)

There's a lot of high traffic articles here. In my experience handling well over 10,000 edit requests and patrolling all of the edit request queues, edit requests are often ignored by the regulars on well attended talk pages, and edit request patrollers handle requests on those articles very often. ScottishFinnishRadish (talk) 02:36, 25 May 2024 (UTC)

Great. Then those articles would not turn off the edit request facility. Hence "optional". ―Mandruss ☎ 04:30, 25 May 2024 (UTC)

Pages that are protected are normally of interest to many editors. So hopefully they are on watchlists. Also I expect that admins the protect, add the page to their watchlist so they can see any requests or edits. Graeme Bartlett (talk) 22:39, 23 May 2024 (UTC)

That reads like an argument for eliminating the edit request facility entirely, which would be a step too far in my opinion. It's certainly not an argument against making the facility optional at article level. ―Mandruss ☎ 01:10, 24 May 2024 (UTC)

And the argument is very wrong too. There are plenty of obscure protected pages. High-risk templates. MediaWiki-namespace pages. Gadgets like MediaWiki talk:Gadget-watchlist-notice-core.js, where even the edit request template itself has failed for two months. * Pppery * _{it has begun...} 04:04, 24 May 2024 (UTC)

I implemented this a while ago per Wikipedia:Administrators' noticeboard/Archive334#Possible new tool/technique/procedure as {{Manual edit requests}}. It never got used then because the person who was advocating for it retired due to unrelated drama shortly after that discussion. * Pppery * _{it has begun...} 04:04, 24 May 2024 (UTC)

I still don't see why editors being already available is a problem. Aaron Liu (talk) 11:29, 24 May 2024 (UTC)

You're choosing to frame this in a greatly oversimplified way that ignores points already made. I hate circular/repetitive discussion, and I suggest a re-read with more effort to see a different perspective. ―Mandruss ☎ 02:27, 25 May 2024 (UTC)

Bump. It's been said, not by me, that Idea Lab is where good ideas go to die. ―Mandruss ☎ 21:48, 5 June 2024 (UTC)

Even if that's true, I don't think the precondition is met for this one.

Suppressing the normal edit request mechanism IMO should only be done for pages where it makes it too easy for confused users to make completely misplaced edit requests (e.g. all the people who used to wind up at Template talk:Reflist trying to add references to some particular article, or Help talk:Edit summary trying to add a summary to their edit). If people are using it to make appropriate requests, even if malformed and even if the article always has editors around, then it's not a problem. Especially in the "always has editors around" case, those editors can handle it.

Above you complain about Rather, the request is invariably changed to answered=y by a "local" editor, removing the article from the category, before an outside editor arrives to handle it, which IMO is the mechanism working as intended: an editor answers the request and sets answered=y. Just because that happens to be an editor who'd have seen it anyway because they watch the page is not a "problem" that needs fixing. Anomie⚔ 11:22, 6 June 2024 (UTC)

The point is that, where there is no need to summon someone via the category, there is no need for the facility. That's it. In my nine years at the perpetually-protected Trump article, perhaps one in twenty edit requests have resulted in an edit to the article—and it could have been done using a normal thread. The other nineteen have been malformed, controversial, attempts to start discussion, or requests for permission to edit the article directly. That is a distracting waste of resources too easily avoided. ―Mandruss ☎ 12:12, 6 June 2024 (UTC)

It's not that I don't understand your point. It's that I disagree that removing the edit request pre-fill would make things better, outside of your own personal annoyance at seeing the edit request template. You or other editors on the page are free to retitle sections and mark the "bad" request as answered when you answer them. Anomie⚔ 12:46, 6 June 2024 (UTC)

Well, I think you do misunderstand my point, unless you're saying that the distracting waste of resources is acceptable. If that's the case, I invite you to come spend a few weeks at the Trump article; might change your perspective. We have more important things to do, and not enough time to do them. ―Mandruss ☎ 12:52, 6 June 2024 (UTC)

On second thought, it's not a good time for your visit. The article talk page has been temporarily semi-protected due to vandalism related to the conviction, and I think that's preventing edit requests. ―Mandruss ☎ 13:13, 6 June 2024 (UTC)

Sorry, I can't stand Trump. Anomie⚔ 00:49, 7 June 2024 (UTC)

I might be misunderstanding the proposal; currently I'm interpreting it as "disable the ability to create edit requests on controversial pages/pages with lots of watchers". If that's the case: last year, I made an edit request to the List of Conspiracy Theories article, which is unsurprisingly a controversial article and has over a thousand talk page watchers. By your criteria, I'm pretty sure edit requests would have been disabled. As it was, it took 23 days for anyone to bother to respond, during which time (if my memory's correct) it became the 12th-most-stale edit request on the entire site. ...had your proposal been in place, and had my request been forced to have been opened as a normal thread, it would have vanished into the void and would still be unanswered today. Because surprise surprise, the ultimate responder found it through the Edit Request Tool, not from watching the talk page. 2603:8001:4542:28FB:BC84:B937:5E69:2838 (talk) 14:42, 7 June 2024 (UTC) (Send talk messages here)

That's the general gist I saw when I was I patrolled edit requests. ScottishFinnishRadish (talk) 14:45, 7 June 2024 (UTC)

The proposal is to give an article's editors the power to turn off the edit request facility if they judge that it's doing more harm than good at that article. The test is not an arbitrary one based on # of watchers or anything else. Are you suggesting that decision would be made at List of conspiracy theories? Made on what basis?

Regardless, it's not like the decision is irreversible. If your normal thread sat unanswered for a long time, would that not be a clear reason to turn the facility back on? If your edit request went unanswered for 23 days, how is that an argument against this proposal? ―Mandruss ☎ 18:27, 7 June 2024 (UTC)

I'm just not seeing what it really does. The template attracts the patrollers. If they close an edit request it doesn't mean that the watchers of that particular article can't action or respond to the request in any way they see fit. ScottishFinnishRadish (talk) 18:30, 7 June 2024 (UTC)

If I've failed to make the point about "distracting waste of resources", I guess there's nothing else I can say. ―Mandruss ☎ 18:40, 7 June 2024 (UTC)

What you call waste, we call extremely effective redundancy. Aaron Liu (talk) 18:48, 7 June 2024 (UTC)

Perhaps I'm misreading, but it is unclear what resources are being wasted (server kittens?) or that anyone is distracted. One of two things is true. Either the request is answered by someone who is patrolling the categories for edit requests, in which case the system functioned as expected. Or the request is answered by a talk page watcher, in which case the proposed change would make no difference except perhaps cosmetically due to a different template. I suppose there is the tiniest chance that a patroller inspects a request at the precise instant a talk page watcher answers it and edit conflicts, but the benefit of eliminating an extremely rare occurrence is more than outweighed by the extra complications entailed by the proposed change. 184.152.68.190 (talk) 04:49, 10 June 2024 (UTC)

I doubt that new users would be able to know how to request turning the facility back on, nor if there were a facility because it was turned off. Aaron Liu (talk) 18:49, 7 June 2024 (UTC)

Proposed revision of the COI guideline

Our current Conflict of Interest guideline is 6000 words - or 0.2 tomats - long, and often ambiguous and confusing. To address this we have recently been discussing at WP:COI a replacement, and I'm opening a discussion here to get further input on it now that it has gone through a few rounds of revisions.

It is considerably shorter than the current guideline, at just 1000 words, and is intended to be clearer about what restrictions apply to which editors. The intention is that it would replace the current COI guideline; the current text would be moved to an explanatory supplement where it could be edited and pruned as appropriate. BilledMammal (talk) 18:06, 23 May 2024 (UTC)

Draft of the proposed guideline

To preserve the integrity, neutrality, and public trust in Wikipedia, it is crucial to effectively manage conflicts of interest among editors. A conflict of interest arises when an editor's personal, professional, or financial connections might compromise the objectivity of their contributions. This guideline outlines the types of conflicts and specifies the conduct required for editors who may be affected by them. Financial Conflict of Interest An editor has a financial conflict of interest when they stand to gain, or can reasonably be expected to gain, financial benefits from the coverage of a topic on Wikipedia. This conflict arises in various forms: Direct Financial Benefits: These include receiving direct payment for editing Wikipedia articles. Indirect Financial Benefits: Such benefits are not as overt as direct payments but are significant. Examples include: Business Exposure: Gaining from increased visibility when a product, service, or company is featured in an article. For example, an editor who is a major shareholder or partner in a business could materially benefit from increased sales due to enhanced visibility of their product on Wikipedia. Conversely, an individual who holds a inconsequential stake, such as a small fraction of a percent of shares in a publicly traded company, would not be positioned to experience noticeable financial gains from such coverage. Reputation Enhancement: Benefiting indirectly from an enhanced reputation due to having a personal article on Wikipedia or being prominently featured as an expert. This can lead to increased professional opportunities, such as book sales, speaking engagements, or consultancy work. Non-financial Conflict of Interest An editor has a non-financial conflict of interest when their personal or professional connections may compromise their ability to present a subject objectively. This type of conflict arises in various forms: Personal Relationships: Editing articles about friends, colleagues, family members, romantic partners, or personal adversaries can lead to biased content, whether overly favorable or unduly negative. Professional Connections: Editing articles related to one's employer or competitors in the industry can introduce biases that may either unfairly promote one’s own organization or undermine others. Similarly, citing oneself or ones close acquaintances as sources can introduce bias, influencing the content to unduly favor personal or professional interests. Significant Roles: Editing articles related to organizations in which an individual holds a significant role, or recently held a significant role, may introduce biases and a lack of objectivity in content related to the organization's interests. This is a spectrum, with whether an editor has a conflict of interest depending both on the level of authority or influence their role granted them, and the recency of the role. For example: A general volunteer for the Democratic Party would have no conflict of interest. A precinct captain for the Democratic Party would have a conflict of interest for a few years after they hold the role. A presidential elector for the Democratic Party would permanently have a conflict of interest. Managing Conflicts Editors with a Financial Conflict: Must not directly edit affected articles. Instead, they should propose changes using the Edit COI template, disclosing the nature of their conflict on their user page and in any location they discuss the topic. Editors with Non-financial Conflicts: While not strictly forbidden from directly editing affected articles, transparency is required; they must disclose their conflict in the edit summary and in any location they discuss the topic. Exceptions Aside from those explicitly listed here, no exceptions exist to this guideline; edits must abide by it regardless of their perceived harmlessness or quality. Editors who wish to avoid disclosing their conflict of interest may do so only be avoiding topics affected by it. General exceptions Reverting obvious vandalism—edits that any well-intentioned user would agree constitute vandalism, such as page blanking and adding offensive language. Removal of clear copyright violations or content that unquestionably violates the non-free content policy (NFCC). What counts as exempt under NFCC can be controversial, and should be established as a violation first. Consider opening a deletion discussion at Wikipedia:Files for discussion instead of relying on this exemption. Removal of content that is clearly illegal under U.S. law, such as child pornography and links to pirated software. Removing contentious material that is libelous, biased, unsourced, or poorly sourced according to Wikipedia's biographies of living persons (BLP) policy. What counts as exempt under BLP can be controversial. Consider reporting to the BLP noticeboard instead of relying on this exemption. Reverting unambiguous spam, where the content would be eligible for page deletion under criterion G11 if it were a standalone page. Wikipedians in residence A Wikimedian in Residence (WIR) is a professional role in communications for an organization to share its knowledge within the Wikimedia platform, measure the impact of the same, and promote Wikipedia through training, education, and edit-a-thons. While WIRs can greatly benefit Wikipedia, there is a risk of edits that could unduly benefit their employers. To manage this risk, the following guidelines apply: Scope of Editing: WIRs may edit articles related to but not directly involving their institution. They must not edit articles where their institution is the primary subject or could reasonably be seen as directly benefiting from the article's content; if they wish to make changes to such articles they must follow the instructions at #Managing Conflicts for Editors with a Financial Conflict. Disclosure Requirements: WIRs must clearly disclose their role and association with their institution on their user page, as well as in any discussions or edits related to their role as a WIR Reporting suspected violations When violations of this policy are suspected or identified it is crucial to address them with transparency and caution, balancing protecting the encyclopedia with respect for the editors involved. Always adhere strictly to our no-outing policy; only post personal information if the editor has disclosed it on Wikipedia. User talk page: Non-urgent issues can be raised on the editor's talk page, using the COI warning template as appropriate. COI noticeboard: If issues remain unresolved after user talk page discussions, or if the user talk page is an unsuitable venue, escalate the matter to the Conflict of Interest Noticeboard. This noticeboard also provides guidance for editors dealing with their own conflicts. Private communication: For issues requiring confidentiality, including where posting the information on Wikipedia would violate our policies on the posting of personal information, email evidence to the appropriate channels: for general COI issues, contact functionaries-en@lists.wikimedia.org, and for paid editing concerns, reach out to paid-en-wp@wikipedia.org. Always consult these channels for advice before sending private information.

Discussion

Any way to internationalise the bit under Significant roles? A "precinct captain for the Democratic Party" doesn't really map intuitively onto anything in my experience, and others may feel similarly. Folly Mox (talk) 20:41, 23 May 2024 (UTC)

I tried to think of a few as I didn't consider it ideal either, but I couldn't think of anything more recognizable. If you have any ideas I would be glad to change them. BilledMammal (talk) 00:08, 24 May 2024 (UTC)

• I am really not liking the direction this proposal is taking us. This focuses on the editor and not the edits.

Having a conflict of interest should NOT bar anyone from editing as long as their edits are in accordance with our content policies and guidelines. Even a paid editor is not problematic UNLESS they are editing in a way that is contrary to our p&g.

I agree that it IS all too easy to (even unintentionally) edit in a way that is contrary to p&g when you have a tie to the topic… and so I agree with requiring disclosure. After all, when you disclose, others can better guide you when you unintentionally edit in a problematic way. BUT… those with a conflict CAN edit properly with such guidance.

The flaw isn’t in having a conflict of interest… the flaw is in allowing that conflict to impact one’s editing. And THAT is resolved by addressing the edits, not the editor. Blueboar (talk) 22:36, 23 May 2024 (UTC)

I agree that the flaw is in allowing the conflict to impact one's editing. However, I don't believe it's useful to focus on the edits within the conflict of interest guideline. All edits are held to the same standard: they are proper if they align with our content policies and guidelines, and improper if they don't.

Instead, we should recognize that editors with a conflict of interest can make significant positive contributions but also face an increased risk of making problematic edits - especially ones that are difficult to detect and address. Our goal should be to minimize this risk without hindering those positive contributions, and we can achieve this through two complementary processes: providing additional guidance to editors with a conflict of interest and subjecting their edits to greater scrutiny.

A conflict of interest guideline that focuses on the editor, promoting transparency and disclosure, supports these processes, and allows us to better manage the risk. BilledMammal (talk) 00:08, 24 May 2024 (UTC)

I agree with Blueboar, the only thing that matters is the edits. Everything that isn't directly supporting the inclusion of good edits and the exclusion of bad edits, regardless of source, is irrelevant. The significant majority of this proposal is focusing on completely the wrong thing. Thryduulf (talk) 21:34, 24 May 2024 (UTC)

@Blueboar and @Thryduulf, can't the same thing be said about the existing COI guideline? Is this really "taking us" somewhere new, or is it "keeping us exactly where we have been since 2012"?

Related to the comment from @Curbon7, I think the most recent major change was when Gigs and SlimVirgin largely re-wrote COI in 2012. If memory serves, the goal was to make COI focus on the editor instead of the edit, because real-world definitions (e.g., for corporate board malfeasance) focus on the individual actors instead of the actions. For example, if a non-profit board member owns an office building, and offers to rent badly needed office space to the non-profit at a massive discount, he can theoretically get in COI trouble for voting to accept his offer, even if that's clearly the best possible thing for the organization. WhatamIdoing (talk) 06:17, 25 May 2024 (UTC)

Wikipedia's COI policies don't ban those with a COI from editing. However, they do require you to:

1. Disclose that COI
2. Keep any bias in check
3. Involve other editors to verify all edits are unbiased
4. Avoid letting your voice "dominate" any articles on the topic.

The editor matters because we don't have perfect information. If a rando gives a citation for "Bob the scientist says X", it's reasonable to include this in an article, and I won't give it much thought. However, it's possible Bob's view falls outside the mainstream; to determine that, I'd need to learn all about X. I can't do this for every possible X, so I take a shortcut: if a COI editor who would benefit from X writes this edit, I make sure to be extra-careful when reviewing the edit. –Sincerely, A Lime 20:17, 9 June 2024 (UTC)

• I think rather than re-writing the guidelines entirely it may be more wise to trim the guideline section-by-section. I'm not sure many editors have an appetite for a ground-up re-structuring which to some may seem to be the addition of new guidelines and removal of existing one; the issue with huge proposals like this is the risk of a controversial change in one spot derailing the entire thing. Curbon7 (talk) 22:59, 23 May 2024 (UTC)

  As a matter of practical politics, you're probably right. I don't remember a wholesale re-write ever being adopted in one go, though we have (10+ years ago) made really substantial changes to some policies through a series of edits. But it's also helpful to look at the potential goal. If it's going entirely the wrong way, then we might not want to propose any of the changes. WhatamIdoing (talk) 06:05, 25 May 2024 (UTC)

  I think an attempt at a ground-up restructuring is worth attempting; a lot of the changes only make sense in context, and I feel trying to run a dozen RfC's will quickly fatigue the community. BilledMammal (talk) 07:18, 2 June 2024 (UTC)

Worth the effort; there are many problems caused by the current guideline. North8000 (talk) 13:43, 4 June 2024 (UTC)

Ready for the mainspace

I'm here to solicit opinions about what it means for an article to be "ready for the mainspace". This phrase has turned up in hundreds of AFDs during recent years. Here's the story:

You are looking at an article. You have determined that the subject is notable, and that none of the Wikipedia:Criteria for speedy deletion apply to the article. Another editor says to you: "I don't think that article is ready for the mainspace".

What would you guess that the editor means? Is that consistent with our rules, such as the WP:NEXIST guideline or the WP:IMPERFECT policy? WhatamIdoing (talk) 19:32, 28 May 2024 (UTC)

Personally, and this is just my own opinion here, I find this "ready for the mainspace" thing a little ambiguous. As you said, as long as WP:GNG is met, an article that is properly sourced (or at least whose topic does) deserves to be in the mainspace. Not all articles are perfect, and by having an article in the mainspace, more people will see it and improve it, which is exactly the purpose of Wikipedia. It's a work in progress! Cocobb8 (💬 talk • ✏️ contribs) 19:45, 28 May 2024 (UTC)

I think it's a little ambiguous, too, which is why I'm asking. ;-) WhatamIdoing (talk) 20:14, 28 May 2024 (UTC)

However, WP:DRAFTIFY clearly states that the aim of moving an article to draft is to allow time and space for the draft's improvement until it is ready for mainspace, so maybe a change to that guideline could be required to make it clearer? Cocobb8 (💬 talk • ✏️ contribs) 20:17, 28 May 2024 (UTC)

If we can figure out what it means, that might be helpful. WhatamIdoing (talk) 20:32, 28 May 2024 (UTC)

I would generally interpret it as "WP:N has not been shown." Gråbergs Gråa Sång (talk) 19:53, 28 May 2024 (UTC)

Then what about you have determined that the subject is notable per @WhatamIdoing's original comment? Cocobb8 (💬 talk • ✏️ contribs) 20:02, 28 May 2024 (UTC)

If I couldn't see for myself why the other editor would say that, I'd ask. For myself, I could see saying "not ready for mainspace" for something so poorly or inappropriately written that it does a disservice to the topic and the reader (although I'd probably say specifically what my concern was). Schazjmd (talk) 20:12, 28 May 2024 (UTC)

Wikipedia:Drafts#During new page review says that it's enough that the topic is plausibly notable to draftify. An unsourced article with a claim of significance (or notability) could fit this description, not being eligible for WP:A7 but still not meeting the referencing standards for mainspace. Chaotic Enby (talk · contribs) 20:34, 28 May 2024 (UTC)

In my opinion, if the article draft meets all of the following it's ready for mainspace:

• Is not being discussed at XfD
• Would not meet a speedy deletion criterion in article space
• Has no identified copyright, BLP, etc issues
• Has sufficient sources to demonstrate notability
• Has been at least minimally proof-read (perfection is not required, basic readability is).
• Has no in-line editing notes ("need to reword this", "add more info here", etc) (excluding templates and hidden comments).
• Has no obviously broken templates (if you don't know how to fix it, ask for help before moving). Thryduulf (talk) 21:22, 28 May 2024 (UTC) ("article" changed to "draft" for clarity Thryduulf (talk) 23:20, 28 May 2024 (UTC))

I'm not sure why you're asking in this venue. The only way to know is to ask the editor making the statement what they meant. Even if it could be done, I don't think it will be helpful to try to establish a common interpretation. Editors should be specific about their concerns. isaacl (talk) 22:15, 28 May 2024 (UTC)

It's difficult to ask hundreds of editors. Also, if everyone has their own ideas, then the phrase becomes useless. We might as well just say WP:IDONTLIKEIT in that case. WhatamIdoing (talk) 22:29, 28 May 2024 (UTC)

The phrase is useless on its own, as it's not specific. It sounds more like you want to revisit the criteria for deleting an article, to examine what should be considered showstopping shortcomings. Commenters in deletion discussions should be encouraged to list those shortcomings. They can optionally add that as a result, the article isn't ready for the mainspace. isaacl (talk) 22:48, 28 May 2024 (UTC)

I do not want to revisit the criteria for deleting an article. Also, if you take a look, this phrase frequently is given as a reason for not deleting the articles (but instead moving them to Draft: or User: space).

Consider Wikipedia:Deletion policy#Deletion of drafts: "If an article isn't ready for the main namespace, it can be moved to the draft namespace". Commenters in deletion discussions can listed specific shortcomings, but the deletion policy itself can't. Is this a matter of pure consensus, in which case it's nearly indistinguishable from IDONTLIKEIT (which sounds worse than it probably would be in practice)? Does it mean, e.g., what @Thryduulf said about "Has sufficient sources to demonstrate notability", in which case WP:NEXIST is no longer valid? Would a visibly broken template count as the sort of IMPERFECT thing that the deletion policy won't countenance? WhatamIdoing (talk) 23:09, 28 May 2024 (UTC)

To be clear, my criteria are for moving a page from draft space to article space, not for moving a page in the other direction (where such issues as broken templates should simply be fixed). Thryduulf (talk) 23:18, 28 May 2024 (UTC)

Articles don't avoid deletion to be moved to draftspace simply because they're not ready for mainspace by someone's measure, but because someone thinks there's promise to demonstrate that the topic meets English Wikipedia's standard for having an article. There's no point in trying to retroactively figure out what others have meant by a non-specific phrase they used in the past. Moving forward, users should be asked to provide specific details, assuming that it's not already clear from context what shortcomings are being considered.

Regarding the quote from the deletion policy, I agree that ideally it wouldn't use a vague phrase. I appreciate, though, that the sentence is trying to be a placeholder to cover any scenario where the participants in a deletion discussion agreed that the best course of action was to move the article to the draft namespace. It's essentially tautological. isaacl (talk) 00:05, 29 May 2024 (UTC)

If it means "by consensus at AFD", then it should say that. We could change the deletion policy to say that.

In re no point in trying to retroactively figure out what others have meant by a non-specific phrase they used in the past, I don't agree. This phrase seems to mean something to people. You are the only editor who thinks that understanding what we want to communicate (in about a thousand AFDs, in the deletion policy, twice in Wikipedia:Drafts, in more than forty thousand pages all told). When a bit of wiki-jargon has been used tens of thousands(!) of times, I don't think that figuring out what we mean, and whether we all mean the same thing, is pointless. If it doesn't interest you, then that's fine, but please don't tell other editors that what they've been saying is meaningless.

Also, I suspect that in a substantial fraction of cases, "not ready for mainspace by someone's personal standards" is exactly what is meant. WhatamIdoing (talk) 02:10, 29 May 2024 (UTC)

To clarify, I mean from my view, there's no point in trying to guess at the meaning in a village pump thread. If we're serious about trying to figure it out, we should be systematic: take a sampling and ask the editors in question if they're still around. We can also analyze the discussion threads to see if there is enough context to understand. isaacl (talk) 05:05, 29 May 2024 (UTC)

This phrase is used in WP:DELPOL and WP:DRAFTIFY. The village pump is the normal place to discuss confusion that affects multiple policy/guideline/help/etc. pages.

But I'm no longer hopeful that we can have that discussion. If you look at this thread, five editors thought they had something useful to contribute. Then you started posting that you thought it was not helpful to figure out what editors mean, that it's useless, that there's no point – and nobody else has shared their thoughts since. I think you have effectively discouraged editors from sharing their their views. WhatamIdoing (talk) 18:54, 31 May 2024 (UTC)

The main thing that it means to me is that most claims in the article are sourced, and that they're sourced to enough separate reliable sources to establish notability by just reading the references. Many topics are notable in the sense that sources exist out there somewhere, but implicit in the notability guideline is that the reason we're looking to establish there exist such-and-such many reliable sources about a topic is to use those sources to write the article. Any article that does not actually do this is half-baked. Loki (talk) 04:30, 1 June 2024 (UTC)

@LokiTheLiar, how many existing articles do you think meet the standard of "most claims in the article are sourced"? WhatamIdoing (talk) 21:56, 1 June 2024 (UTC)

I'm aware that there's lots of bad articles out there, if that's what you're asking. I'd still say that the majority of articles meet that standard, and that the overwhelming majority of traffic to Wikipedia is to articles that meet that standard.

Like, compare naked butler, which doesn't meet the standard I've set here, to complaint tablet to Ea-nasir, which does. They're both small articles on obscure subjects but the complaint tablet one is totally fine. Loki (talk) 22:12, 1 June 2024 (UTC)

I believe that the complaint tablet has about five times as many sentences as the median article and about ten times as many sources. So if that's the standard, we'd probably be deleting about 90% of current articles. WhatamIdoing (talk) 22:19, 1 June 2024 (UTC)

To put it another way: The median article is a stub. You have given a C-class article as an example that should be considered a "small article". A quick look at Wikipedia:Version 1.0 Editorial Team#Statistics suggests that my off-the-cuff 90% estimate is correct. Only about 10% of articles (excluding lists, dab pages, etc.) rate as C-class or higher. WhatamIdoing (talk) 22:25, 1 June 2024 (UTC)

Stub class articles don't necessarily violate this standard. So for instance, I just found a list of stubs and clicked randomly and found Ty Barnett, which clearly meets my standard. Or have Fred Baxter or William Beavers, literally the next two articles I clicked on. All stubs of obscure people, all definitely meet the standard I laid out. Loki (talk) 04:31, 2 June 2024 (UTC)

• ORES says the first is Start-class. I think editors might have different opinions about whether it's a long stub vs a short Start, but at 200 words/10 sentences long, it is at minimum on the long side for a stub.
• The second is a four-sentence, four-source stub, which might put it around the median article for length, but I think it is above average for sourcing.
• The third is also Start-class. It has 2750 bytes of readable prose and 450 words. This is about twice the length of the maximum described in Wikipedia:Stub#How big is too big? The stub tag was removed from the article during an expansion in 2006. I have corrected the WP:1.0 rating on its talk page.

Looking at Fred Baxter (the second one), would you feel the same way if it had only three sentences and three sources? WhatamIdoing (talk) 06:16, 2 June 2024 (UTC)

Yes. I don't care about length at all. Loki (talk) 13:44, 2 June 2024 (UTC)

Are you interested in the number of sources, or the percentage of sentences with inline citations? WhatamIdoing (talk) 18:05, 2 June 2024 (UTC)

Number of sources only has to be enough to meet the notability guideline. Otherwise it's fraction of claims that need to be sourced that aren't. Loki (talk) 23:39, 2 June 2024 (UTC)

WP:NEXIST says that the number of citations required to meet the notability guideline is zero. (Per that long-standing guideline, the sources have to exist in the real world, but they don't have to be cited in the article.) There are no claims in User:WhatamIdoing/Christmas candy that need to be sourced (nothing about BLPs, nothing WP:LIKELY, etc.). Is that "ready for the mainspace" in your opinion? WhatamIdoing (talk) 23:51, 2 June 2024 (UTC)

In my opinion, that article isn't 'ready for mainspace' because it is unreferenced. Cremastra (talk) 00:51, 3 June 2024 (UTC)

I realize that the notability guideline itself says that the sources just have to exist somewhere, and not be actually present in the article. However, it's pretty clear that the reason the notability guideline says the sources have to exist somewhere is so they can be used to write the article.

My big problem with the example article you linked is that it's not clear that "Christmas candy" is a notable subject separate from specific types of Christmas candy. I also think some of the list of examples is more WP:LIKELY to be challenged than you think. I think that for instance someone who did not know what a szaloncukor was is very likely to start out doubtful that it is Christmas candy. Loki (talk) 02:33, 3 June 2024 (UTC)

Do you really think I needed to consult sources to write that "Christmas candy is candy associated with the Christmas holiday season. Candy canes are one type of Christmas candy"? WhatamIdoing (talk) 05:25, 3 June 2024 (UTC)

No, but someone who doesn't celebrate Christmas and has lived in a Hindu/Buddhist/Muslim-majority country all their life might need to. WP:V still stands, whether you like or not. Cremastra (talk) 12:05, 3 June 2024 (UTC)

WP:V says that it must be possible to find sources (e.g., at a library). It does not say that sources must be cited in the article, except four types of material, none of which are in this article. WP:V is not violated by having those two sentences uncited. WhatamIdoing (talk) 19:31, 3 June 2024 (UTC)

I would guess the editor means:

• The article is completely unreferenced, and/or many of the claims are factually dubious
• The article is written in English, but is barely coherent. It can be understood, so isn't gibberish, but is an embarrassment and not very helpful.
• The article is blatantly and overtly promotional

Cremastra (talk) 20:30, 1 June 2024 (UTC)

I could also interpret "not ready for mainspace" to include glaring MOS or technical issues, like:

• templates outputting nothing but error messages
• external links peppering article prose
• infobox with default values for parameters
• entirely empty sections
• no subheadings whatsoever, just a giant chunk of text
• unintentional blockquotes from starting a paragraph with whitespace
• other Wikipedia pages incorrectly formatted as references instead of internal links
• etc

Folly Mox (talk) 14:22, 2 June 2024 (UTC)

First, to emphasize the obvious, "ready for mainspace" is a vague subjective term. Probably the only more objective term that could fall under that is "allowed to exist in mainspace" and the most universal standard for that is "likely to survive a reasonably well run AFD". And for an article (NOT article content) NPP and AFC passage ostensibly follow that. Which in turn (presuming no eggregious speedy or wp:not violations) the main criteria ends up being passing wp:notability. Many people (e.g. at AFC, during mentoring, and in this thread) set a higher standard for "ready for mainspace" which is that the content of the article and the article does not have any significant problems or shortcomings. Yes, this is a double standard, and can make AFC a somewhat rough and arbitrary path. But we need to recognize that it is only human by the person reviewing it. If somebody took an article to you that was allowed to exist in mainspace (usually a wp:notability decision on the topic) but which was in really bad or undeveloped shape, would you be willing to bless putting it into mainspace? Most people would want it to meet a higher quality standard before they would personally say "ready for mainspace". North8000 (talk) 19:21, 31 May 2024 (UTC)

• If I'm not mistaken the "not ready for mainspace" phrase originated in WP:DRAFTIFY and has since leaked into deletion discussions. As everyone here seems to agree, it is very poorly defined phrase and, far from the low bars proposed above, I've seen new page and AfC reviewers invoke it for things like a draft not being long enough or using plain text references instead of {{cite}} templates. Rather than trying to define it, I think we should purge it from guidelines and templates in favour of listing specific problems in an understandable way. – Joe (talk) 12:35, 4 June 2024 (UTC)

  Rather than trying to define it, I think we should purge it from guidelines and templates in favour of listing specific problems in an understandable way. I agree with this. U ideally we would not move something out of mainspace or disallow moving it into mainspace unless there are problems that are all of specifically identified, actionable, adversely detrimental* and not trivially fixable (anything that is trivially fixable should just be fixed). *"adversely detrimental" means things like failed verification or no evidence of notability, not merely lacking inline sources, cite templates or being "too short". Thryduulf (talk) 12:44, 4 June 2024 (UTC)

  I suppose we could try to re-define it as "does not qualify for deletion" (either CSD or AFD), but (a) it'd take a couple years for the usage to shift and (b) there is a strong demand from a minority of the community to have ways to get rid of "ugly" (i.e., short) articles. WhatamIdoing (talk) 16:42, 4 June 2024 (UTC)

  Following up on what @Joe Roe said about DRAFTIFY, I find this in that page:

  2a. The page is obviously unready for mainspace, for example:

  2a-i. is not a reasonable WP:STUB (e.g. has very little verifiable information, or is interchangeable with a short dictionary entry, but the definition is not good);

  2a-ii. or it would have very little chance of survival at AfD;

  2a-iii. or it meets any speedy deletion criterion.

  This was introduced by SmokeyJoe as a result of his proposal at Wikipedia talk:New pages patrol/Archive 5#Clarification and guidance for draftification. (The original proposal was that "unready for mainspace" mean "It does not meet WP:STUB.")

  This suggests that the definition of "not ready for the mainspace" is:

  • a very short stub, containing either a bad dictionary definition or very little information in general;
  • the article is not ready because the subject is non-notable; or
  • the article qualifies for speedy deletion.

  Based on this, I suspect that the definition could be reduced to "contains less than about 20 words of encyclopedic content", because a look at Wiktionary suggests that the mode for dictionary definition length is a mere four words, and 20 words would give you one long sentence or several shorter ones. WhatamIdoing (talk) 01:45, 9 June 2024 (UTC)

  A stub should be defined at WP:STUB, not at WP:Drafts.

  A stub is a very short article that is accepted in mainspace, despite not meeting other inclusion guildelines. They seem to be inherently acceptable topics, like natural species, capable of expansion. SmokeyJoe (talk) 02:05, 9 June 2024 (UTC)

  Per WP:STUB, a stub is any short article. Generally, it is taken to be less than about 250 words/10 sentences. There are no minimum requirements in WP:STUB. Cancer is a disease – a mere four words with no sources and no other content – would be a valid stub per WP:STUB.

  WP:IDEALSTUB (perhaps that's what you had in mind?) recommends adding "enough information for other editors to expand upon it" and to avoid a {{db-nocontext}} deletion. Cancer is a disease is realistically enough to fulfill that recommendation.

  IDEALSTUB also recommends that you "try to expand upon this basic definition", so we could add something like Sometimes people die from it or It is mostly treated with surgery or drugs.

  Finally, IDEALSTUB recommends citing a source (though our policies only require this for BLPs, not for articles about diseases), so we could add a link to https://www.cdc.gov/cancer/ or some similar website.

  I don't know what you mean by "despite not meeting other inclusion guildelines". The inclusion guidelines are at Wikipedia:Notability and its friends, and none of them require any length or particular content in the articles. Cancer is a disease, unsourced, with nothing else, meets the inclusion guidelines. WhatamIdoing (talk) 04:24, 9 June 2024 (UTC)

  You’re referring to the sourcing requirement speaking to sources that exist, not sources currently listed. Ok, yes you are right. SmokeyJoe (talk) 09:56, 9 June 2024 (UTC)

  @SmokeyJoe, I wonder whether this list of "three" items could be shortened to two:

  • The subject is non-notable (in which case, you should usually send it to AFD instead of Draft:)
  • The article qualifies for speedy deletion (on any grounds, but particularly for {{db-nocontext}}).

  The example of "has very little verifiable information, or is interchangeable with a short dictionary entry, but the definition is not good)" is redundant with {{db-nocontext}}. But perhaps there is a different example of "not a reasonable WP:STUB" that should be retained? WhatamIdoing (talk) 15:30, 9 June 2024 (UTC)

  Three is a pleasing number.

  Lists of two encourage binary thinking. SmokeyJoe (talk) 00:17, 10 June 2024 (UTC)

  Sure, a great many things could be.

  I wonder whether it’s actually not a good thing to attempt to tidy up definitions of edge cases. Edge cases are messy, subjective, and cause emotional disputes. Mistakenly precise language can make this worse, setting up a conflict between rules oriented wikilawyers and new content creatives.

  Where are the actual problems that you are trying to solve? SmokeyJoe (talk) 00:08, 10 June 2024 (UTC)

  The problem I need to solve is: People use the same words to mean different things, which results in (preventable) confusion.

  The problem I want to solve is: People have significantly different ideas of what the minimum acceptable amount/type of content for an article is, which results in some preventable disputes (and some non-preventable disputes).

  For example, one editor looks at an article and says "Wow, ten sentences, nicely written, I understand what the subject is, and it's even kind of a cool subject. It's WP:NOTFINISHED, but readers will be happy if they run across it, especially if they only need basic information (which is usually the case)."

  Another editor looks at the same article and says "It's soooo embarrassing! WP:ITSUNREFERENCED so the whole thing might be made-up nonsense, and readers hate uncited articles. There's been WP:NOEFFORT to improve it. WP:WEDONTNEEDIT, and we do need to hide that WP:Garbage to protect our reputation. There's no chance of it getting deleted at AFD, but it's obviously not ready for the mainspace!"

  Some divergence is a desirable thing, but there's very little overlap between those two positions. If we're going to function well, we need to have most of us mostly agree on what the minimum requirements are for something being "ready for the mainspace".

  If "ready for the mainspace" is even a soft requirement, then we need to have a shared understanding of what that means, and it needs to be the same for both going into and getting back out of the Draft: space. WhatamIdoing (talk) 05:16, 10 June 2024 (UTC)

I agree with WAID that there is a real problem here. If you read the subpoints of WP:DRAFTIFY#During new page review, then it's clear that obviously unready for mainspace is intended to refer to a fairly narrow set of seriously problematic articles: something less than a stub, deletion almost certain, etc. But divorced from that context, "not ready for mainspace" admits a much wider range of understandings, as we've seen above. For example, the draftify script leaves the canned edit summary Not ready for mainspace, incubate in draftspace followed by a selection of prespecified reasons why the article is not ready, which include things like it needs more sources to establish notability and it has too many problems of language or grammar – a far cry from very little chance of survival at AfD. A similar message is given to the creator the explain what happened to the article. If you look at the logs, the vast majority of moves to draft use one of these canned reasons: people take their cues on what they should and shouldn't do from the UI in front of them, not the guideline. Taken out of the guideline and into scripts and other pages, the phrase "not ready for mainspace" itself has taken on a life of its own and is used to systematically circumvent the deletion policy on a daily basis. – Joe (talk) 08:12, 10 June 2024 (UTC)

Who are these draftifiers? Are they sufficiently qualified/experienced? My biggest concern about NPR approvals was insufficient expectation of experience at AfD, draftifiers are t performing AfD-like decisions, but unilaterally.

The wording of the script, was there any discussion or consensus behind it.

“Not ready for mainspace”. They are very simple word. I think it might be worth an essay, WP:Not ready for mainspace.

While trying not to embarrass individuals, is it possible to show me a list of bad draftifications? SmokeyJoe (talk) 12:37, 10 June 2024 (UTC)

I wouldn't know where to start. I've been reviewing draftifications through WP:PERM/NPP requests, CSD R2 nominations and from the logs for years now and I'd say I come across an egregious example just about every time I look. To be clear, by 'bad', I mean something that clearly exceeds the boundaries set by WP:DRAFTIFY and/or what I understand community expectations to be, not my own. I don't want to unfairly single anyone out, but you could check my contributions to the draft namespace for a representative sample. – Joe (talk) 13:44, 10 June 2024 (UTC)

Egregious?

Some brainstorming questions, not having looked at your contribution history yet:

Are reviewers systematically applying a higher standard to new articles than would be applied at AfD? I’ve seen that AfC reviewers do this. Could this be explained by an increased expectation of article standard, and AfD voting lagging this change? I know that some people complain about how hard it is to get article deleted at AfD.

Are bad draftifications being done by editors who are not NPRs? And are they doing bad things randomly?

Is there any sense that draftifications are being done to endorse a reviewers POV bias on what content should be in Wikipedia?

Is the problem with this page’s asserted boundaries, or with poor training of NPReviewers? Or with bias from the draftification script(s) due to them proving an easily option for difficult cases? I don’t think that anything in the fairly heavy NPR and AfC training pages instructions to read WP:Drafts. SmokeyJoe (talk) 13:59, 10 June 2024 (UTC)

Egregious meaning systematic enough that I feel I have to discuss it with the user and, if they don't stop, pull their NPR right. I think the rest of your questions are good ones and, although I give my anecdotal conclusion on them, I don't have any data to hand (and unfortunately I don't think anyone does, which is why this issue has been festering for years now). I do think the lack of clarity in the phrase "not ready for mainspace"—taken out of context, as discussed above—has contributed to the problem and that's why I think WAID's original question (what is ready for mainspace?) is a good one.

To suggest a concrete next step, there is a list of specific, consensus-backed things that make a page "not ready for mainspace" at WP:DRAFTYES. We could brainstorm what could be added to those, and/or consider making a separate list of things that don't disqualify a page from mainspace. – Joe (talk) 14:13, 10 June 2024 (UTC)

My impression:

• Are reviewers systematically applying a higher standard to new articles than would be applied at AfD? – Yes. And it's not just one "rogue" editor; it's anyone who doesn't want to be seen "endorsing" or "accepting" an WP:UGLY article. You have to be willing to expend a lot of social capital to follow the written rules. This is one reason I recently suggested a "three strikes and you're out" approach to AFC: On the third time AFC rejects a submission, a bot should do a procedural nomination at AFD. There is no more reliable method of figuring out whether it will be kept at AFD than to send it to AFD.
• Could this be explained by an increased expectation of article standard, and AfD voting lagging this change? – Yes, but I don't think that "increased" is the right word. AFD still operates on the written rules (e.g., sources must WP:NEXIST in the real world, but don't have to be cited in the article). NPP and AFC functionally reject this rule and want notability "demonstrated".
• Are bad draftifications being done by editors who are not NPRs? And are they doing bad things randomly? – Yes, overly aggressive draftifications sometimes are done by anyone who believes they are defending Wikipedia against ugly articles, but it's not really random. It is an effort to "raise Wikipedia's quality" by forcing other editors to choose between improving the article or having it hidden from readers.
• Is there any sense that draftifications are being done to endorse a reviewers POV bias on what content should be in Wikipedia? – I have not seen evidence of, e.g., editors draftifying articles related to geopolitical disputes. There have been times in which we see editors draftifying articles about, e.g., Bollywood actors or African politicians. This could be due to cultural differences (the normal, everyday ways of describing powerful people in some cultures looks like "pure promotional garbage!" in others) and is probably often due to WP:NEVERHEARDOFIT (with that bias applying both the subject and to the newspapers/standard sources in that country).
• Is the problem with this page’s asserted boundaries, or with poor training of NPReviewers? Or with bias from the draftification script(s) due to them proving an easily option for difficult cases? – I don't think that training is the problem, because part of Wikipedia's notion of "training" is to watch what others are doing and follow their lead. The problem that I want to deal with is the problem of nobody knowing/agreeing on what those words mean. If we agree that ugly articles should be accepted, then the script should reinforce that. If we agree that ugly articles should be hidden, then the script should reinforce that (and WP:UGLY should be updated to say that ugly articles can be hidden in draftspace).

Joe, I like your idea of having "a separate list of things that don't disqualify a page from mainspace". WhatamIdoing (talk) 17:44, 10 June 2024 (UTC)

Me too. SmokeyJoe (talk) 11:44, 11 June 2024 (UTC)

• User:WhatamIdoing, User:Joe Roe, how about “isn’t acceptable in mainspace”? Eg1. Eg2. SmokeyJoe (talk) 13:23, 12 June 2024 (UTC)

  If two people argue about whether something is ready, it does seem to be a horribly subjective argument over an undefined and unimportant threshold.

  If two people argue about whether something is acceptable, one can say “it is acceptable because I accept it” and the other can say “it is not acceptable because I am not accepting it”. It goes to AfD where the decision will be made, deleted or pseudodeleted, or kept in mainspace, proving one of the two to be right. SmokeyJoe (talk) 13:34, 12 June 2024 (UTC)

  If two uninvolved editors disagree in good faith about whether something is or isn't ready for mainspace, I think it should be declared ready and moved to mainspace but explicitly without prejudice to AfD (obviously nothing is immune from AfD, but it should be made explicit so the psychological bar to nomination is lower). Thryduulf (talk) 13:46, 12 June 2024 (UTC)

  If two uninvolved editors disagree in good faith about whether something is or isn't acceptable for mainspace, I think it should be declared acceptable and moved to mainspace but explicitly without prejudice to AfD (obviously nothing is immune from AfD, but it should be made explicit so the psychological bar to nomination is lower). SmokeyJoe (talk) 13:52, 12 June 2024 (UTC)

  I think any new wording is worth a try but I'm not sure that it is sufficiently different from "ready for mainspace" to make a difference. We don't generally encounter problems when editors disagree about drafts, because the obvious course of action then is to discuss it at AfD. The problem is that the vast majority of articles moved to draftspace are only seen by two people: the creator, and the reviewer who draftifies it. Reviewers shouldn't, but unfortunately often do (not least through the wording of the automated script), imply that their 'decision' on an article is uncontestable. Even if they don't, creators, especially inexperienced ones, are often ignorant of the fact that they don't have to go along with what the reviewer says. So unless a third party happens to come across the draft, we don't get disagreement, just a creator trying to meet whatever arbitrary standard a particular reviewer has decided is required for mainspace, or just concluding that their contribution has been rejected and giving up. This is incidentally the precise opposite of what WP:DRAFTIFY and most frequent draftifiers say they want to achieve: to "allow time and space for the draft's improvement". – Joe (talk) 14:01, 12 June 2024 (UTC)

  I think that “acceptable” is better defined, via tautology with hindsight, than “not ready”. On reflection, I think “not ready” is suggestive that it is ok to Draftify a topic that is undoubtedly suitable, cf meta:Conflicting Wikipedia philosophies and extreme Immediatism.

  I think that draftification should include a mandatory link to WP:DRAFTOBJECT, both in the edit summary / move log entry, and in the message posted to the author. I agree with you concern about content creators not knowing all of the rules. SmokeyJoe (talk) 14:41, 12 June 2024 (UTC)

  I don't think that wording helps much. For one thing, it implies that there is a consensus that some articles are "unacceptable", but gives nobody any idea what is "acceptable" and what is "unacceptable". WhatamIdoing (talk) 14:40, 12 June 2024 (UTC)

  Acceptable means it survives AfD. Unacceptable means it doesn’t survive AfD. SmokeyJoe (talk) 14:42, 12 June 2024 (UTC)

  So in the deletion policy, you wrote "If an article isn't acceptable in mainspace, it can be moved to the draft namespace" but what you mean is "If a subject isn't notable, it can be moved to the draft namespace"? WhatamIdoing (talk) 14:50, 12 June 2024 (UTC)

  I’ve been trying to remember what I meant seven years ago with “ready for mainspace”. One thing that comes up was that reviewers were expecting citations in a BLP to be “inline”. I think I was attempting to not engage with dubious reasons reviewers were using. This was then quite a new backwater page. I am disturbed to discover my verbiage to have been copied into deletion policy and to have become common phraseology at AfD.

  WP:Drafts is not supposed to rewrite WP:N. Pages that pass WP:N are sometimes deleted. Pages that fail WP:N are sometimes kept.

  When a reviewer moves a page to draftspace, the reviewer should be justifying their action, not quoting generic statements. SmokeyJoe (talk) 21:33, 12 June 2024 (UTC)

  I think the wording should be more direct regarding expectations. Taking some text from Wikipedia:Deletion policy § Incubation, it could be something like "If a recently created article shows potential but needs additional development to establish that the subject meets Wikipedia's standards for having an article, it can be moved to the draft namespace." isaacl (talk) 15:59, 12 June 2024 (UTC)

  Is the rule you have in mind that the subject must not only be notable (e.g., NEXIST) but also demonstrate notability (e.g., cite multiple sources)? WhatamIdoing (talk) 16:26, 12 June 2024 (UTC)

  Whatever is necessary to convince a consensus of editors that the subject meets English Wikipedia's standards for having an article. This doesn't necessarily require citing multiple sources appropriate for demonstrating that the standards have been met, though that would be an easier route. isaacl (talk) 18:14, 12 June 2024 (UTC)

  Does the English Wikipedia have any standards other than WP:N for having an article? WhatamIdoing (talk) 19:08, 12 June 2024 (UTC)

  Having an article, no. Having this article, yes - e.g. WP:V, WP:COPYVIO, WP:NOTENGLISH, WP:BLP, WP:G10, etc. Thryduulf (talk) 19:36, 12 June 2024 (UTC)

  WP:V is not in the business of deciding whether we should have an article, in any mainspace. It's about which discrete bits of material require inline citations. Uncited material (WP:ITSUNREFERENCED) is not grounds for deletion under WP:V.

  If the article violates BLP, then it can't be moved to the Draft: space, either, because BLP applies to all namespaces. Ditto for COPYVIO and G10, which are reasons for immediate deletion and apply to all namespaces.

  NOTENGLISH has a two-week timer for deletion. It also says "Please keep in mind that drafts are out of scope for this page." WhatamIdoing (talk) 19:55, 12 June 2024 (UTC)

  You are missing the distinction between whether there should be an article about a topic, and whether any given individual content written about that topic is appropriate. For example, Australia is a notable topic about which we should have an article, but an article reading "Australia is land of criminals and man-eating spiders that is permanently on fire. Citation: My ex-girlfriend" should not be in mainspace. Thryduulf (talk) 20:11, 12 June 2024 (UTC)

  I'm pretty sure that the hypothetical Australia example would qualify for Wikipedia:Criteria for speedy deletion#G3. Pure vandalism and blatant hoaxes. WhatamIdoing (talk) 00:44, 13 June 2024 (UTC)

  Possibly (it's definitely not a hoax, vandalism is debatable. Unarguably it would fail WP:V) however these are all matters that have absolutely nothing to do with notability and are relevant to whether a page should or should not be in the mainspace. Thryduulf (talk) 01:08, 13 June 2024 (UTC)

  Prcicely right. There are a lot of topics that pass GNG or ann SNG, and thus deserve to have AN article. But, that does not mean any specific attempt at creating that article is acceptable. That attempt may have serious issues with other policies and guidelines, and need a complete rewrite. Draftspace is a temporary holding pen where that rewrite can take place. Blueboar (talk) 20:05, 12 June 2024 (UTC)

  Yes, as you are aware, there are other considerations than those explicitly listed at Wikipedia:Notability. That page does link in its introduction to one of the other key guidance pages to consider, Wikipedia:What Wikipedia is not. I didn't get into it as I find it hard to discuss the entirety of Wikipedia guidance related to having an article at once, and so I linked to the most commonly referenced guidance page in this area. (It wasn't a final proposal for a different wording, just a starting point.) I appreciate you like to use Socratic questioning, but it feels like you're trying to elicit a response that you can counter with your knowledge of current guidance, rather than bringing up additional guidance to consider.. isaacl (talk) 22:58, 12 June 2024 (UTC)

• Perhaps some of the confusion here stems from the fact that deletion is based purely on notability, while draftification can be based on other criteria. Yet, “not ready for Mainspace” gets invoked in edit summaries as an “explanation” for both actions. Blueboar (talk) 00:39, 13 June 2024 (UTC)

  Yes, plus there seems to be no agreement about what the "other criteria" are. WhatamIdoing (talk) 00:46, 13 June 2024 (UTC)

  User:WhatamIdoing, I’ve noticed that “unsourced” is a reason. SmokeyJoe (talk) 11:18, 15 June 2024 (UTC)

  The "unsourced" claims are probably in WP:PGCONFLICT with WP:NEXIST.

  I wonder whether the typical claim is actually "unsourced" (e.g., if it were a BLP, it'd qualify for WP:BLPPROD) or if the claim is closer to "does not contain a sufficient volume of sources that, in my opinion, clearly demonstrate notability". WhatamIdoing (talk) 14:04, 15 June 2024 (UTC)

  My opinion is that in new page review, if the page is unsourced, the reviewer should make some attempt to find sources, and if they fail to find sources, they should PROD the article (or BLPPROD) noting that they cannot find evidence of sources, and they should not Draftify, becuase unsourced content is dubious content that should be considered junk.

  At AfC, submitted drafts are routinely declined as unsourced. SmokeyJoe (talk) 00:18, 16 June 2024 (UTC)

  Do you really believe that "unsourced content is dubious content that should be considered junk"? If someone starts an article on French Renaissance gardens, and it says "French Renaissance gardens were the style of gardens in France during the Renaissance", do you actually think that's worth a {{dubious}} tag? Is it WP:JUNK?

  I can imagine it being irritating for those few people who want a Wikipedia:Four Award, but that article wouldn't violate a single policy. WhatamIdoing (talk) 16:57, 16 June 2024 (UTC)

  User:WhatamIdoing, I wrote with a few unstated assumptions. I’m assuming a new article, it is completely unsourced, no external links, a single author who is no longer active, and a new page patrollers has tried to find sources, at least by google search. The content is unverified and possibly unverifiable.

  French Renaissance gardens is the sort of article I’m imagining. Doubtless it exists, there were gardens in France during the renaissance, and it seems likely that they had a unique style. The information in the page may be true, but may just as likely be made up, embellished, oversimplified, etc. I consider this dangerous, through the process of citogenesis. Is the risk managed by draftififcation? SmokeyJoe (talk) 11:22, 18 June 2024 (UTC)

  If I found a new article or draft “French Renaissance gardens” containing unverifiable content, I would redirect it to Gardens of the French Renaissance. SmokeyJoe (talk) 11:40, 18 June 2024 (UTC)

  Template:Dubious would be not applicable. That template refers to “a specific statement or alleged fact that is sourced but that nevertheless seems dubious or unlikely. The unsourced article more likely contains BLUESKY plausible stuff.

  The WP:JUNK essay is about notability. I am talking about pages that are unverifiable. I don’t agree with that essay defining junk as stuff that fails Wikipedia-Notability. SmokeyJoe (talk) 11:28, 18 June 2024 (UTC)

  If it's actually unverifiable (which, as you can see from the books cited in Gardens of the French Renaissance, this is definitely not unverifiable), then the material would have to be removed. All material must be verifiable – that means that it must be possible for someone to check whether a reliable source says the same thing, with "possible" defined as including actions such as "getting help from a reference librarian at your own library" or "finding sources through Wikipedia:The Wikipedia Library" – though a sentence such as the one I gave does not require an inline citation according to WP:V. For WP:V purposes, it does not require a source even if it is the only sentence in the entire article.

  It is not my experience that uncited content is "just as likely be made up, embellished, oversimplified". About half of all sentences in the English Wikipedia are uncited; in my experience, it is not true that half of them (representing a quarter of our content) is made up, embellished, oversimplified, etc. I generally find that only a small proportion of our uncited content is wrong. My impression is that the proportion of wrong-and-uncited content is not as different from the proportion of wrong-and-cited content as one might wish.

  I have given you an example of a definitely verifiable (though presently uncited) sentence about a definitely notable subject. Do we agree that "unsourced content" is not necessarily "dubious content that should be considered junk"? WhatamIdoing (talk) 15:38, 18 June 2024 (UTC)

  We agree, "unsourced content" is not necessarily "dubious content that should be considered junk". SmokeyJoe (talk) 09:54, 19 June 2024 (UTC)

  Another reason if seen for non notability reasons to Draftify is “COI”. Including “suspected COI”. SmokeyJoe (talk) 00:37, 16 June 2024 (UTC)

  COI has no effect on non-notability. If it's non-notable, it should go to AFD, regardless of whether COI is suspected. WhatamIdoing (talk) 15:39, 18 June 2024 (UTC)

Contemplation of a Proposal: Mandate edit summary linking to WP:DRAFTOBJECT in every unilateral draftification

Proposal: Mandate edit summary linking to WP:DRAFTOBJECT in every unilateral draftification.

The more I think on this years old idea the more I think it should be done. In practical terms, it is a simple thing to write into draftification scripts. For manual draftifications, these draftifiers are probably not experience and the rule is even more important. For consensus based draftifications, via AfD or informal discussion, they should link the discussion.

I suspect the rule should also strongly encourage including WP:DRAFTOBJECT in the usertalk explanation (automatic by the scripts), but not mandated due to occasional complications such as the first page author being an IP or banned user. SmokeyJoe (talk) 00:33, 16 June 2024 (UTC)

I think we could realistically make this happen in the scripts, but not in manual edit summaries. WhatamIdoing (talk) 16:52, 16 June 2024 (UTC)

I agree, but but would it be a good idea, to make it happen in the scripts, and to encourage it in manual edit summaries? It seems to me to be an easy fix to some of the problems you’ve noted (eg newcomers being intimidated). Would it have downsides? It would not fix everything. Would you support this proposal? SmokeyJoe (talk) 11:37, 18 June 2024 (UTC)

This is the wrong place for proposals, and I would oppose it anyway, as mandating a link to an essay is a bad idea, as it gives the impression that DRAFTOBJECT is a policy without going through the policy validation process. E.g. the "you can't draftify again" part is being misused by some people to object to redraftification a priori, pretending that it isn't allowed. Often the same people who then object to an AfD because AfD is not cleanup, leaving not much room for other options to deal with very poor articles which, yes, aren't ready for the mainspace. Yes, the drafter could in theory do a complete cleanup of the article, providing coherent prose, sources, ... for a subject they know nothing about, where the sources are in a language they don't speak. Realistically speaking though, the best solution is to move the page to draft again and again until the creator or someone else with the time and knowledge to deal with it turns it into an acceptable article. Fram (talk) 10:03, 19 June 2024 (UTC)

Hi Fram.

Wrong place? Yes, I know, actually I meant it as contemplation for formally proposing this. I have learned to not propose something without at least one person agreeing with me. If supported, I would start a new page tagged {{Proposal}}. SmokeyJoe (talk) 11:26, 19 June 2024 (UTC)

DRAFTOBJECT *is*, already, pseudopolicy, and the proposal would be defacto ratification.

Redraftification, excepting for WP:COI, is not allowed. It is move warring. Two people disagreeing should not move war, but should discuss, and the perfect forum is AfD.

AfD is not cleanup? No, it is not. Neither is draftification. Draftification is not for cleanup.

What do you mean by a very poor article that is not “ready for mainspace”, to ask the central question of this thread?

If there is any disagreement, it should go to AfD. I firmly disagree with you if you if you think it is ok for one editor to have the authority over another to send their work to draftspace until it meets the first editors undefined standard. —SmokeyJoe (talk) 11:37, 19 June 2024 (UTC)

"Pseudopolicy" doesn't exist. Draftofject isn't only about "one editor to have the authority over another to send their work to draftspace until it meets the first editors undefined standard.", it also means that a second editor may not send a page back to draftspace. And the essay gives the right to "one editor to have the authority over other editors to send their own work to main space", no matter how poor. I see no problem with this nor a reason to burden AfD with it. I moved Draft:2025 Rugby Europe Championship to draft twice because it had no sources about the topic but about different topics, but if it could be sourced to good sources it would be a notable subject. An article with such poor sourcing is "not ready for the mainspace". Jesus Calls was draftified, recreated, speedy deleted, and then recreated as Jesus calls. I draftified that one, is that a redractification? And if so, is it for some reason problematic? I redraftified Air 1 (airline) (another editor did the original draftification), why not? Same for Mangkunegara III.

As for "not ready for mainspace", things like Draft:Sahajanya (unsourced microstub), Draft:Azad Samaj Party (Kanshi Ram), Uttar Pradesh and Draft:Azad Samaj Party (Kanshi Ram), Madhya Pradesh (barely above speedy deletion), Draft:2025 in Belgium (explanation for the "not ready" statement: "So far, this contains 1 sure event only, plus speculative claims about who will be PM, links to unrelated articles, and the holidays for 2024."), Draft:San Sanana (not ready as in "No evidence of notability at the moment, chart performance section is not for this song" but being an Indian song not easy for me or many others to check for actual notability), ... Fram (talk) 13:09, 19 June 2024 (UTC)

Taking Draft:2025 in Belgium as the example: Why did you decide that we shouldn't have that page in the mainspace?

There is no question about the notability. It would easily pass AFD, and AFC's mandate is to accept pages that will pass AFD. If Thief-River-Faller submits it to AFC, they ought to accept it immediately (assuming they follow their own rules, about which there has been some doubt).

It would also be more likely to get corrected if it were in the mainspace. So why hide it in Draft: space? WhatamIdoing (talk) 17:05, 19 June 2024 (UTC)

Whoever would accept that page as is would need their reviewer rights removed. "AFC's mandate is to accept pages that will pass AFD." Among many other things. Accepting pages with almost exclusively blatantly incorrect information just because the topic is notable is making Wikipedia worse, not better. The page at the moment has one correct entry, "7 – 17 August: Belgium at the 2025 World Games"; everything else is either speculation or just factually wrong for the topic. I would urge you to reread Wikipedia:WikiProject Articles for creation/Reviewing instructions, which contains a lot more than "notable = accept". Fram (talk) 21:28, 19 June 2024 (UTC)

Sure, I've read that page. I even helped write it. In particular, see Wikipedia:WikiProject Articles for creation/Reviewing instructions#Core purpose, which says (second sentence): "Articles that will probably survive a listing at Wikipedia:Articles for deletion should be accepted."

See also the second sentence of the next section: "Article submissions that are likely to survive an AfD nomination should be accepted and moved to mainspace" (bold in the original). WhatamIdoing (talk) 21:57, 19 June 2024 (UTC)

All the while ignoring the detailed checklist and workflow, which give further, more detailed instructions than the (by definition) simplified summary. I see no good arguments why this page should be in the mainspace as it is now, and putting it in the mainspace while knowing about the issues (which is what you claim a reviewer should do now, if asked by the creator) is basically vandalism, deliberately and knowingly putting incorrect information in the mainspace. Fram (talk) 07:43, 20 June 2024 (UTC)

I believe it would be best to blank the obviously wrong information. WhatamIdoing (talk) 20:24, 20 June 2024 (UTC)

Taking Draft:San Sanana as an example, why did you choose to hide it in Draft: space instead of blanking the apparently incorrect information (KjjjKjjj, that song isn't "Falling Behind", like it says in Draft:San Sanana#Charts, right?) and tagging it with {{notability}}? WhatamIdoing (talk) 18:14, 19 June 2024 (UTC)

So, if it is notable, I should keep it in mainspace. If it is not notable, I should nominate it for deletion. And if notability is unclear I should tag it with "notability", even if there are (like here) clearly other problems as well. Is there any scenario where you believe draftifications is an acceptable course? Fram (talk) 21:30, 19 June 2024 (UTC)

Yes, there are a couple of scenarios for which I would accept and even recommend draftification. The first and most obvious is when the editor(s) working on it want to take that route. The second obvious case IMO is when the subject is not currently notable but is reasonably likely to become notable within the next couple of months. For example, we know that certain events, such as the US State of the Union speech or the United States census, will continue to happen on a predictable schedule, but future events frequently fail Wikipedia:Notability (events) until shortly before they happen. If an article is created a bit too early, when we don't have enough sources/attention from the world at large, but when we also believe such sources will be forthcoming in short order (e.g., a press conference has been scheduled for an announcement), then I think draftification is better than either deletion or keeping it. WhatamIdoing (talk) 22:15, 19 June 2024 (UTC)

I don't think that extremely minimal approach to draftification is shared by many, and would leave many very poor new articles in the mainspace. Something like Draft:Science Centre, Patan has now been draftified twice, which is a good thing. Would the subject survive an AfD? No idea, and as discussed elsewhere, it isn't the job of reviewers to do a WP:BEFORE check. Fram (talk) 07:43, 20 June 2024 (UTC)

I think your extremely maximal approach to draftification, openly ignoring the only written guidance on the subject because it's "just an essay", is shared by even fewer. – Joe (talk) 11:16, 20 June 2024 (UTC)

See below, we actually have policy about this, which is what I follow. Fram (talk) 11:43, 20 June 2024 (UTC)

the proposal would be defacto ratification if in effect the idea is to make DRAFTOBJECT policy then that should be the proposal, rather than discussing edit summaries. -- LCU ActivelyDisinterested «@» °∆t° 19:13, 19 June 2024 (UTC)

Something doesn't have to be a policy (or even a guideline) to be linked in a tool-generated edit summary. WhatamIdoing (talk) 21:51, 19 June 2024 (UTC)

...which should be obvious given that the current edit summary used by scripts is a paraphrase of the very same essay (Not ready for mainspace, incubate in draftspace). Apparently it's okay to use a non-policy to justify moving tens or hundreds of thousands of articles out of mainspace, but not to remind the creators that they're entitled to move it back? – Joe (talk) 11:21, 20 June 2024 (UTC)

My point had nothing to do with adding anything to the summary of automated edits. It was that if editors wanted to make suggestions for new policy they should do so. The comment I was replying to was suggesting that policy should be made via discussion on another topic. -- LCU ActivelyDisinterested «@» °∆t° 14:35, 20 June 2024 (UTC)

I don't use that edit summary either, and if you both want a policy about draftification; WP:ATD-I: Recently created articles that have potential, but do not yet meet Wikipedia's quality standards, may be moved to the draft namespace ("draftified") for improvement. Fram (talk) 11:43, 20 June 2024 (UTC)

Where are those quality standards defined? Thryduulf (talk) 11:45, 20 June 2024 (UTC)

Nowhere probably, just like many things around here. Having reliable sources and intelligible prose, being factually correct, and actually being about the topic as suggested by the title, is what I (and in my experience most others who do new page checking) apply. I don't think any of these can be considered really controversial. Fram (talk) 12:01, 20 June 2024 (UTC)

This discussion demonstrates that every one of those is controversial:

• The only requirement for sources is that they exist - if they don't exist the article should be prodded or sent to AfD, if they do exist add them to the article, if you don't know then look.
• If there is no intelligible prose then the article should be deleted (speedy deletion criteria G1, G2, A1, A2 and/or A3 almost certainly apply)
• If the article is factually incorrect then it should be corrected or nominated at prod or AfD (unless it's a blatant hoax, in which case it should be speedily deleted under criterion G3).
• If it isn't about the topic as suggested by the title, then either rename the article or nominate it for prod/AfD. Thryduulf (talk) 12:14, 20 June 2024 (UTC)

Nobody would disagree that those are desirable qualities in an article, but whether they constitute a required standard for mainspace is indeed controversial. As just one data point, the existence of {{unreliable sources}}, {{incomprehensible}}, {{disputed}}, and {{off topic}} would suggest that all of the problems you list have been tolerated in mainspace in the past. The lack of a definition of "Wikipedia's quality standards"—AKA being "ready for mainspace"—is the problem that motivated this discussion and, as the discussion shows, it leaves room for a wide range of understandings. – Joe (talk) 12:17, 20 June 2024 (UTC)

Feel free to ping me when a policy proposal is put up for a vote. Until then, I don't think anything useful will come from continuing this discussion with you three. The requirements put up here, basically requesting the reviewers needing to do all the work the creator should have done and can do much easier, are mainly based on misreadings of policy ("The only requirement for sources is that they exist", well, no: "Any material lacking an inline citation to a reliable source that directly supports[b] the material may be removed and should not be restored without an inline citation to a reliable source. " and "The burden to demonstrate verifiability lies with the editor who adds or restores material" (bold in original). A completely unsourced article may thus be blanked (which would make it eligible for speedy deletion, not really preferable), or by draftifying it "removed" from the mainspace; and the burden to add sources lies with whoever wants it back in the mainspace, the one who "restores material". Putting that burden on new page reviewers is not acceptable (of course they may do so if they wish, but it should never be a requirement). Similarly, "If the article is factually incorrect then it should be corrected or nominated at prod or AfD (unless it's a blatant hoax, in which case it should be speedily deleted under criterion G3)" yes, it should be corrected by the creator or whoever wants the material in the mainspace. Otherwise it will be deleted. It shouldn't be brought to Prod or AfD as these are not for cleanup. "If it isn't about the topic as suggested by the title, then either rename the article or nominate it for prod/AfD." No, if you actually do new page patrol then you will encounter many cases where someone has created an article for topic X by copying their own previous creation about topic Y, and forgot to change all or most of the text. Topic X is notable, the creator is probably knowledgeable and interested in correcting this, but until then we have a completely wrong article in the mainspace (not incomplete, poorly sourced, just wrong). Speedy deleting this as a hoax is very WP:BITEy and draftifying the much more friendly, gentle solution, the middle ground between keeping the mainspace factual and the editor encouraged to continue working on it.

The approach taken by you three seems to be "we need a policy or you can not do this" (even though we have a policy encouraging draftification in such cases), and "you are not allowed to do things which go against this essay here". Oh, and "all the work should be done by the reviewers, not the creators" or (judging from their contributions) people who never patrol new pages, edit draft space, or nominate pages for deletion (like Whatamidoing and Thryduulf) I'll continue to ignore this until you get a policy that actually supports your positions, or until you get a consensus at ANI or so that I should change my approach. Fram (talk) 12:49, 20 June 2024 (UTC)

Most of that is not opposing DRAFTOBJECT, which is about empowering the newcomer to get their week at AfD if they want it. Opposing part of DRAFTOBJECT are a few example of something draftified twice, where WP:ATD-I rolled with DRAFTOBJECT would mean that Fram is supposed to send the bad article to AfD with a nomination to Draftify. Maybe “do not Draftify twice” is a soft rule, maybe newcomers mainspacing a draftified article do not actually mean that they want to debate it at AfD. SmokeyJoe (talk) 13:15, 20 June 2024 (UTC)

I find your (Fram's) response interesting, because underneath it, it feels like there is a question about whether Wikipedia is a collegial, collaborative project. Several of the examples you give sound like a Wikipedia-as-a-game model: Any sentence could be required to have an inline citation, so if "you" don't have "enough" (or any) inline citations, then "my" move is to capture your article. If you make the right moves, you can get your article promoted back to the mainspace, but I see my role as fundamentally adversarial: I will prevent you from sharing information until you do so in a way that I believe is appropriate, and I will not help you fix any problems you encounter. WhatamIdoing (talk) 21:06, 20 June 2024 (UTC)

And here I thought the singular purpose of Wikipedia is to be a factual, verifiable encyclopedia that anyone can edit. But all this time it has actually been a social platform where the real goal is to get more precious users by zealously protecting their right to publish whatever they want to the first page of Google. Editor retention above all else. JoelleJay (talk) 09:11, 21 June 2024 (UTC)

How the fuck are we going to maintain a "factual, verifiable encyclopedia" if we don't retain editors? – Joe (talk) 09:27, 21 June 2024 (UTC)

Editor retention can still be achieved without militantly assuming every article creation is inherently encyclopedic as a standalone regardless of sourcing and content. JoelleJay (talk) 10:15, 21 June 2024 (UTC)

Assuming bad faith, hiding their work in place that nobody will ever find it, and refusing to put any effort into even checking whether what they wrote is correct, let alone making trivial improvements to things new editors cannot reasonably be expected to master is not the way to retain editors. Thryduulf (talk) 10:31, 21 June 2024 (UTC)

Perhaps not, but frankly speaking, if new editors are not either of the mindset to proactively learn those "things new editors cannot reasonably be expected to master" beforehand or of the mindset to look for help afterwards on figuring out the issues with their creation(s), how to fix them, and then try again? Chances are, you won't retain them long-term with your suggested course of action either.

Instead, you'll likely as not lose them shortly after that newness has worn off just enough that people will start expecting them to have picked up on the basics of "articles need to be factual, non-promotional, in readable English-language prose, with sources", the major policies and guidelines, and some slightly-beyond-basic skills like how to create a reference without scattering CS1 errors all over the page, edit a table or infobox without breaking it, and so on. At that point, people will stop fixing their issues for them and expect them to do it themselves—with skills and knowledge they cannot reasonably be expected to have mastered if other people have silently fixed all issues for them so far.

The solution is not "let them figure it out entirely by themselves" nor "fix it for them without even making them try". It is guidance on where they went wrong and how to do it right. And yes, depending on the severity of the issues and how long fixing it is likely to take (and how likely an editor is to even give it a try), sometimes that guidance is better done outside mainspace. AddWittyNameHere 12:39, 21 June 2024 (UTC)

But what happens is not "move to draftspace, teach them what they need to know, including where to get help, assist them to improve their article and welcome them as a productive editor" but "move to draftsapce where someone can delete in six months". Thryduulf (talk) 13:01, 21 June 2024 (UTC)

Yes, hence my won't retain them [...] either (emphasis added) and [t]he solution is not "let them figure it out entirely by themselves" nor "fix it for them without even making them try" (emphasis), i.e. if the aim is predominantly "retaining editors", then absolutely, the current method does indeed not work well for that purpose. I just do not believe the course of action suggested by you would work any better, for the reasons outlined above (and would come with an additional hidden cost: still no long-term retaining of productive editors, but an increase in workload as a result of these editors leaving a little later)

That said, I don't think the primary intended objective of draftification-as-concept is or has ever been "retaining new editors", it is "guarding mainspace from incorrect, dubiously notable and/or unverifiable, but potentially improvable, new articles while retaining the contents somewhere so that (at least in theory, as we all know that this only rarely happens in practice) someone could work on improving it without the hassle of having to get it undeleted first". It is a slightly less BITEy alternative to deletion, but also only slightly so.

That in practice it ends up being less of an alternative to and more of a delayed form of deletion is exactly where the guidance I mentioned comes in: such guidance is lacking, it should not be, and if it were not, it would work towards both objectives (editor retention/mainspace not getting flooded by New Editor's Clueless First Article) and make it a significantly less BITEy alternative to deletion that produces some actually-mainspaceable articles instead of an almost-as-BITEy-delayed-deletion that produces a heap of stale drafts to be cleared like clockwork. AddWittyNameHere 14:09, 21 June 2024 (UTC)

And where was it decided that mainspace needed to be 'guarded' from such things? Not to state the obvious, but this is a wiki; we don't need a special place where people can work on things. Our editing policy even explicitly states that poor articles, if they can be improved, are welcome. – Joe (talk) 14:19, 21 June 2024 (UTC)

And where was it decided that mainspace needed to be 'guarded' from such things? Among various places, in the WP:ATD-I section of the WP:Deletion policy, which states Recently created articles that have potential, but do not yet meet Wikipedia's quality standards, may be moved to the draft namespace ("draftified") for improvement, with the aim of eventually moving them back to the main namespace, optionally via the articles for creation (AfC) process.; the WP:DRAFTIFY of the WP:Drafts explanatory essay, which states The aim of moving an article to draft is to allow time and space for the draft's improvement until it is acceptable for mainspace; during the RfC which proposed the creation of a Draft namespace and which explicitly described one of its potential uses as a successor of the now-historical WP:Article Incubator; during the various discussions and decisions which led to the existence of said now-historical Article Incubator. AddWittyNameHere 20:54, 21 June 2024 (UTC)

I've heard (but not read myself) that if you want to retain new editors who add content, then one of the best things you can do is add an inline tag like {{fact}}, which they will often fix the next day.

So if you want stuff WP:Glossary#cited, hiding the whole page in Draft: space probably isn't the right way to go about it. WhatamIdoing (talk) 21:10, 21 June 2024 (UTC)

Yes, exactly this. Frankly I don't expect the editors who aren't bothered to do even the bare minimum in making their first article PAG-compliant (citing sources in any format) to have any interest in sticking around long-term. If they don't understand they need citations in 2024, despite all the hand-holding alerts and training modules available for new editors nowadays and the ubiquitousness of "citation needed" in English online discourse, then best case scenario is they're a child or geriatric person who doesn't know any better. More likely they're careless, incompetent, a vandal or amateur self-promoter, and/or don't speak English at all, and would be both highly unlikely to continue editing anyway and not the type of editor we'd want to retain regardless. A person who actually cares about contributing would put in some effort and not be discouraged by the mildest difficulty, and a person we'd want to keep around would be familiar enough with "citations" and "what is an encyclopedia" that we wouldn't need to explain very basic concepts that have been universal in secondary education for 30+ years. JoelleJay (talk) 23:45, 21 June 2024 (UTC)

I also think that it's supposed to be a verifiable, factual encyclopedia. However, that's not a full and complete description. Consider:

• A verifiable, factual encyclopedia produced by people working together collaboratively (e.g., if you created an article by copying/pasting a previous one, and you forget to remove something from the old article, I could blank that off-topic content for you), versus
• A verifiable, factual encyclopedia produced by people working adversarially (e.g., instead of fixing an obvious problem, I'll hide the whole thing in the Draft: namespace).

WhatamIdoing (talk) 21:06, 21 June 2024 (UTC)

What is this "pseudopolicy" and why is it exempt from actual policies, like Policy and guideline pages are seldom established without precedent[3] and require strong community support. Policies and guidelines may be established through new proposals, promotion of essays or guidelines, and reorganization of existing policies and guidelines through splitting and merging. [...] Proposals for new guidelines and policies require discussion and a high level of consensus from the entire community for promotion to guideline or policy status. Adding the {{policy}} template to a page without the required consensus does not mean the page is policy, even if the page summarizes or copies policy. and Wikipedia has a standard of participation and consensus for changes to policies and guidelines. and The burden to demonstrate verifiability lies with the editor who adds or restores material and Because a lack of content is better than misleading or false content, unsourced content may be challenged and removed.? JoelleJay (talk) 08:39, 21 June 2024 (UTC)

I’m not sure what the point in the green stuff is, but pseudo policy is something that is in practice as policy but without being documented. The most obvious pseudo policy is the guideline WP:N, which is not policy, but is enforced as policy through WP:DEL#REASON#8 (used to be #6). SmokeyJoe (talk) 13:56, 21 June 2024 (UTC)

The thing that bothers me about quoting "The burden to demonstrate verifiability lies with the editor who adds or restores material" in this context is that it seems to mean "Editors are supposed to magically know that I wanted an inline citation for that, even before I saw the page, so they should have provided one in advance of me actually WP:CHALLENGING the content, but since they didn't read my mind, the content should be hidden until they (a) find where I've hidden it and (b) fix it up well beyond the level of adding a source, but so that an AFC reviewer will feel comfortable publicly endorsing it".

That's not really what the policy says, but it appears to be what's meant in the specific context of draftification. WhatamIdoing (talk) 21:03, 21 June 2024 (UTC)

"Not ready for mainspace" is pure "I don't like it"-ism

if an article is:

• in some form of English
• has at least one citation
• meets notability guidelines
• is not an attack page
• is not vandalism
• is written in good faith

it *is* ready for mainspace. it does not need to be draftified.

It can be tagged to the skies. It can be ignored in NPP for months or years. It does not need to be put into a box labeled "go away you suck". New articles and new users are awkward teenagers that need a little patience and encouragement and many of them *will* grow into beautiful competent adults. Sending them away to reform school in the mountains is just avoiding dealing with our own discomfort with our own flaws and imperfections.

NPP should ideally be a "gates wide open come on in" group of greeters who are there to welcome new articles and new users to the party. "Hi here's a cocktail. It's crazy up in here. Here's the syllabus and another cocktail and a cookie and also a kitten. Don't mind them, that's a WikiProject, they're kindly fanatics."

Shitty articles are good actually. Shit is fertilizer. Shit is rich in nutrients and promotes growth. Scrubbing the world of shit reduces cholera transmission but also increases the prevalence of autoimmune disorders. There's got to be a balance.

Anyway, IMHO, "not ready for mainspace" is mean and vague and more harmful than helpful. Even the worst article that meets the standard above should be greeted with a compliment sandwich: "Thank you so much for contributing to Wikipedia! Your passion for this topic is so evident. I wanted to let you know that that according to our current guidelines, this article may be [list top 3 problems here]. Let me know if you need any help resolving these issues. We really appreciate you contributing to the sum of all human knowledge. There's so many topic domains that still need attention and we so appreciate your participation in growing the project."

Anyway, please enjoy the snacks and thanks for coming to the party. jengod (talk) 16:46, 21 June 2024 (UTC)

WP:FERTILIZER should be blue! – Joe (talk) 17:47, 21 June 2024 (UTC)

done. Let's groooooooowwwwww! jengod (talk) 18:29, 21 June 2024 (UTC)

Meh… I’m now considering writing a contrary essay, and calling it WP:Prune the weeds. Weeds need to be pruned in order for a healthy garden to grow. Blueboar (talk) 18:41, 21 June 2024 (UTC)

I would very much like all Wikipolicies to be presented as a series of (increasingly unhinged?) rambunctious garden metaphors, and would like to be pinged at the creation of each entry in the series please and thank you. :) jengod (talk) 18:57, 21 June 2024 (UTC)

Keukenof, said to be the most beautiful garden in the world, requires an awful lot of maintenance. The best Wikipedia articles, in terms of maintaining volunteer sustainability, are spontaneously maintained and updated by passing readers. SmokeyJoe (talk) 01:30, 22 June 2024 (UTC)

This is operating under the assumption that a primary purpose of Wikipedia is cultivating a social community that effusively courts all potential new users, even when it comes at the expense of encyclopedia quality and requires established editors to take time away from editing to mentor newbies. That's fine for the people who want to do that, but a huge proportion of editors are mainspace-only and so would not know about or care to participate in any kind of newcomer-welcoming behavior regardless of whether "building a community" was an actual WP goal, and would interact with newcomers the same way they always would with any other editor they encounter. Meanwhile I would guess a large percentage of those who do get involved in Wikipedia-space are only there for reasons directly related to improving the specific pages or topics they're working in rather than a desire to be part of a broader "Wikipedia movement" or to socialize or do outreach. These are the editors who have their individual motivations for expanding articlespace, enforcing content rules, molding the PAGs, etc. towards what they think the encyclopedia should be; why should they be forced into additional social roles, beyond what is needed for civil discourse between colleagues, in furtherance of the WMF's or other people's agendas for "Wikipedia the Institution", that are not actually backed up by empirical evidence showing they'd have the intended effect, and for which it isn't even clear how the intended result would improve the encyclopedia? JoelleJay (talk) 01:52, 22 June 2024 (UTC)

Reliable source engine

Created a prototype 'reliable source engine' (you can try it here) to simplify finding reliable sources. Is this something that already exists? That others might use? (if so, maybe Wikimedia can partner with Google to make the search engine ad-free?) Superb Owl (talk) 20:11, 4 June 2024 (UTC)

I just tried it and liked the results. Thanks! Schazjmd (talk) 20:23, 4 June 2024 (UTC)

See WP:WRS. --Talky Muser (talk) 20:37, 4 June 2024 (UTC)

Love it! Maybe that's something to implement to the Find sources link present in most citation needed templates? But, it already seems to exist as above. Cocobb8 (💬 talk • ✏️ contribs) 21:53, 4 June 2024 (UTC)

Thanks all! I pinged User_talk:Syced/Wikipedia_Reference_Search#Relationship_with_WP:RSP? for feedback and to see if they think it'd be helpful to have more versions and added a second version narrowed down to reliable sources without paywalls. Superb Owl (talk) 09:14, 5 June 2024 (UTC)

WP:RSSE is another. Levivich (talk) 02:29, 6 June 2024 (UTC)

Oh awesome! I added all of these to the esssay Wikipedia:Advanced source searching#Niche search engines so they are all in one place Superb Owl (talk) 22:20, 8 June 2024 (UTC)

Awesome! I'm definitely bookmarking it for later use. ‍Relativity ⚡️ 18:57, 8 June 2024 (UTC)

Would love your thoughts when you've tried it!
I also just filtered-out opinion pieces when possible.
And also confirmed that all of the other existing search engines include at least some sources where there is no consensus on reliability. Superb Owl (talk) 22:19, 10 June 2024 (UTC)

possible idea; entry compiling overviews of multiple novels, in a single series

hi all. i made the article below in my own userspace, to compile plot summaries for all novels in a series, namely the Aubrey-Maturin series, by Patrick O'Brian. what do folks here think of this, as a possible model for a type of article?

as far as I know, there is no rule currently against this type of article, but I wanted to get a little feedback here, just to see what reactions or comments on this type of article people might wish to express.

• User:Sm8900/obrian novels

appreciate any feedback. thanks! Sm8900 (talk) 14:05, 7 June 2024 (UTC)

I like the idea, but I don't really think Wikipedia would be the best project for it, as this is mostly based on summarizing primary sources. However, it would be great to envision this as a separate Wikimedia project, if that can be possible! Chaotic Enby (talk · contribs) 14:17, 7 June 2024 (UTC)

WP:NOTPLOT seems like the relevant guideline here. While an encyclopedia article on a series of books can be appropriate (and indeed we do have Aubrey-Maturin series) an article which does nothing but summarise the series, as this seems to be, would not be. Caeciliusinhorto-public (talk) 14:20, 7 June 2024 (UTC)

TV Tropes has recap pages for series {example} Mach61 16:52, 8 June 2024 (UTC)

That is very long. Maybe incorporating condensed synopses of each entry just like List of Black Mirror episodes vs longer summaries on each individual article into Aubrey–Maturin series#Series would be more appropriate. Aaron Liu (talk) 14:20, 7 June 2024 (UTC)

Proposed edits feature

I was thinking that there could be a new feature where someone makes an edit but instead of applying it, ticks a box so that it has to gain approval from one other editor to be applied (and can’t outright be refused). This is a much less time consuming method that would replace talk page spam and be more of a proposal. It would also be ideal for contentious topics, to stop incorrect or uncertain content from being applied. Alexanderkowal (talk) 12:03, 9 June 2024 (UTC)

Something like Wikipedia:Pending changes? Anomie⚔ 12:59, 9 June 2024 (UTC)

Yes but as an option per edit for an editor, or give the edit a timer of a few hours until it’s automatically applied, during which someone can revert it preemptively Alexanderkowal (talk) 13:07, 9 June 2024 (UTC)

Is it worth the effort to distrust an editor so much that we need a giant conservatorship scheme? Aaron Liu (talk) 13:12, 9 June 2024 (UTC)

It is not to distrust the editor, it’s for edits where the editor is unsure Alexanderkowal (talk) 13:21, 9 June 2024 (UTC)

@Aaron Liu My reading of the OP is that it's partly intended for editors to apply a "please check this" flag to their edits. This would only be used by editors who are editing in good faith but are unsure of Wikipedia's norms, etc (the vast majority of whom will be newcomers) so this might be a good way reducing entry barriers for some but I don't think it would be at all effective at reducing spam, deliberate misinformation, other bad-faith editing or those who are confidently wrong in good faith. Thryduulf (talk) 13:24, 9 June 2024 (UTC)

Yes correct, and it could be a less inflammatory way of doing WP:BRD on contentious topics or controversial edits Alexanderkowal (talk) 13:27, 9 June 2024 (UTC)

Only when the editor is not confident they are right. To catch the bad faith and confidently wrong it would have to apply to all editors (or all (extended-)confirmed editors), which is what pending changes is. Thryduulf (talk) 13:40, 9 June 2024 (UTC)

Yes Alexanderkowal (talk) 13:42, 9 June 2024 (UTC)

Editing already effectively works this way, especially if a "proposed edit" has a timer after which the edit is automatically accepted. Any edit can be reverted, so in effect every edit already is what a "proposed edit" would be under this scheme. I wonder if there's some value in making this into a technical restriction we could apply to problematic editors? Right now, if we identify that an editor's work is problematic, all we can really do is talk to them or else ban or block them. A sanction where we could impose pending changes on just their edits might be a decent lower-level enforcement mechanism. Then again our technical options for less-than-total blocks are already getting kind of complicated. Ivanvector (^Talk/_Edits) 13:54, 9 June 2024 (UTC)

You're right that a "proposed edit" with a timer is sort of like the status quo, but the status quo means that edit is published and likely to be read by some readers, the binary between published and unpublished edits facilitates conflict Alexanderkowal (talk) 13:57, 9 June 2024 (UTC)

(edit conflict) You still seem to be conflating things. This feature would either apply to all editors or be opt-in.

• If opt-in it might have merit as a feature for good-faith new editors, but it would be useless at best against bad faith and confidently wrong editors so it would be a waste of time to discuss it in relation to the latter.
• If applied to everyone it might be effective against good and bad faith errors, but it would duplicate the existing pending changes, so it would be a waste of time to discuss it.

So forget bad faith editors, controversial topics, BRD, etc and develop this as a proposal solely to reduce barriers to entry for not-yet-confident, good faith new editors. We need more of those people so reducing barriers to entry for them is a Good Thing. Thryduulf (talk) 13:55, 9 June 2024 (UTC)

Yes completely agree, I'm not tech literate so I would struggle to progress this but I'll try and lay out what I have in mind Alexanderkowal (talk) 13:59, 9 June 2024 (UTC)

The idea is a checkbox next to where the editor types the edit summary, to make this edit a "proposed edit", which appears in the edit history at the time it is 'published' and the edit is automatically applied after a chosen period of time, I suggest the options being 10 mins, 30 mins, 1 hr, 2hr, 6 hr, 12hr, 24 hr. Other editors, when reading the edit history, can either 'support' or 'oppose', support applies it immediately, oppose reverts it (reasons are given for both). If the edit is reverted, you accept it or move to the talk page.

The policy around this would have to be clear to counter spam or wasting editors' time. It would also have to counter page ownership, guardianship, and unnecessary reverting. Alexanderkowal (talk) 14:07, 9 June 2024 (UTC)

Also anyone can revert an edit that has been supported, it is not necessarily consensus 2 v 1 Alexanderkowal (talk) 14:09, 9 June 2024 (UTC)

It doesn't feel like you've taken Thryduulf's comments into account. A spammer doesn't have any incentive to opt into a mechanism intended to counter their work. And by design, your proposal is to ask other editors to consider proposed edits, so it's not countering additional effort from other editors. As written, it's encouraging editors to make proposed edits with the cost of additional work by others. Depending on the relative amount of good-faith edits that end up getting reverted today, versus ones that don't, in theory this could be a net gain. My instinctive feeling, though, is that the target audience isn't large enough for it to significantly reduce net effort. Thus I agree with Thryduulf that it would better to focus on encouragement as a goal. I suggest reading about Wikipedia:Article Feedback Tool, which has some similarities to your proposal. It was discontinued as the amount of useful suggestions was completely swamped by the numbers of poor suggestions, and there wasn't enough volunteer effort to handle them. isaacl (talk) 16:11, 9 June 2024 (UTC)

This isn't anything to do with spammers or bad faith editing. It is a feature for newer editors who're generally unsure and unfamiliar with policy. To be clear it is an option, most editors will not check the box. The second paragraph there was just about writing policy around it and foreseen problems. Alexanderkowal (talk) 16:28, 9 June 2024 (UTC)

I apologize; your second paragraph is a bit unclear to me. I suggest avoiding the word "policy" in that context, as it seems you're saying that the procedure should strive to avoid unhelpful suggestions, rather than suggesting relationships to policy. You could try discussing your proposal with WMF Growth team to see if they've considered anything along those lines. isaacl (talk) 16:50, 9 June 2024 (UTC)

Okay, thank you, yeah I could've worded it clearer Alexanderkowal (talk) 17:04, 9 June 2024 (UTC)

Could you clarify what 'and can’t outright be refused' means, and what problem it solves? If an editor checks the edit and see it's in error they can still just revert it, if they check the edit and don't think it's appropriate why then waste another editors time doing the check again. -- LCU ActivelyDisinterested «@» °∆t° 17:31, 9 June 2024 (UTC)

Please ignore my first two comments, I later combined them Alexanderkowal (talk) 17:35, 9 June 2024 (UTC)

Sorry I didn't reply properly. It encourages new people to edit wikipedia who're put off by their unfamiliarity with procedure and can facilitate master, student relationships between editors. It also means editors who're unsure about their particular edit can seek approval so that false information/edits contradicting policy are not published, even if for a short time. It can also be a less inflammatory method of doing BRD on controversial edits on contentious topics/pages. Alexanderkowal (talk) 12:58, 10 June 2024 (UTC)

It can also be a less inflammatory method of doing BRD on controversial edits on contentious topics/pages Don't understand this, what does "doing BRD" mean? Or why is doing BRD inflammatory? Selfstudier (talk) 13:18, 10 June 2024 (UTC)

Acting boldly on controversial topics can produce genuine conflict between editors and make it harder to work collaboratively, especially if editors are emotionally involved. This feature could provide a more measured way of going about it. Alexanderkowal (talk) 13:30, 10 June 2024 (UTC)

To be clear, a proposed edit can be outright refused/reverted by one other editor Alexanderkowal (talk) 13:02, 10 June 2024 (UTC)

If the edit has been made, it is not really "proposed" is it? And isn't it the case that any editor can already revert it? Selfstudier (talk) 13:20, 10 June 2024 (UTC)

I think you’re misunderstanding, which is fair because I haven’t been clear, the proposed edit is not immediately applied or published. It appears in the edit history like a published edit but isn’t yet one. After a chosen amount of time, during which it can be prematurely reverted, it can become a published edit. Another editor can immediately apply it if they agree with it and bypass the timer. Alexanderkowal (talk) 13:28, 10 June 2024 (UTC)

The German-language Wikipedia does this (with their version of Pending Changes), but it's applied involuntarily and per-user (e.g., all inexperienced users), rather than edit-by-edit.

There have been times when I've wished to have someone else check an edit for me. Here's one that I would have flagged for review. Ten years later, it's still in the article (and I still think it's correct). WhatamIdoing (talk) 17:53, 10 June 2024 (UTC)

Could do with a source though lol Alexanderkowal (talk) 18:11, 10 June 2024 (UTC)

Its bad enough that my typos may not be corrected for years, but I only noticed this error 8 years later. Donald Albury 23:57, 10 June 2024 (UTC)

This is an interesting idea: essentially, allowing editors to apply pending changes to their own edits on a per-edit basis. I like it. I think you'd need someone to add to MediaWiki the ability to do per-edit pending changes (not sure if that's possible with current software). It could help reduce edit wars and BLPvios and the like. Levivich (talk) 05:46, 11 June 2024 (UTC)

Another use case would be an intuitive replacement for edit requests. Aaron Liu (talk) 11:54, 11 June 2024 (UTC)

Yes, maybe the timer could have an option of unlimited, which would be the only option for non EC users on certain topics? Alexanderkowal (talk) 11:56, 11 June 2024 (UTC)

• Do I make this a proposal now we've whittled it down? Alexanderkowal (talk) 12:02, 16 June 2024 (UTC)

  Since this is a software thing, you'd have to file a task on Phabricator. Aaron Liu (talk) 17:07, 16 June 2024 (UTC)

Whales

We don’t have enough content about whales. The whale content is lacking. Are kids going to be successful if they’re not skilled in whales? The answer is no. Hence, we need more whale content. First, how do they breed? Second, what do they like to eat? Third, 2603:7000:4EF0:9ED0:F9B8:A706:2018:DF70 (talk) 03:32, 10 June 2024 (UTC)

Moot We already have sweet Jimbo Wales. Aaron Liu (talk) 11:35, 10 June 2024 (UTC)

And {{whale}}! Chaotic Enby (talk · contribs) 12:44, 10 June 2024 (UTC)

^{[cetacean needed]} —Jéské Couriano v^_^v ^{threads critiques} 23:16, 10 June 2024 (UTC)

fixœd Aaron Liu (talk) 02:58, 11 June 2024 (UTC)

Third, how often do they explode. —Cryptic 15:39, 10 June 2024 (UTC)

We can talk about whales during lunch. --jpgordon^{𝄢𝄆𝄐𝄇} 21:20, 10 June 2024 (UTC)

We have a lot of content on this subject, but (per WP:ENGVAR) we use the UK spelling … without the “h”… see: Wales. Blueboar (talk) 21:31, 10 June 2024 (UTC)

I've created a task force homepage. Aaron Liu (talk) 22:20, 10 June 2024 (UTC)

I think you mean how often does he explode. The Wordsmith^{Talk to me} 00:37, 11 June 2024 (UTC)

Add a timeline to Wikipedia pages

Hi, More than 10 years ago I thought about improving Wikipedia pages, but I was convinced that Wikipedia would logically end up integrating it over time. However, I note that this was not the case even though it would certainly add value to the presentation of the information.

In fact it involves adding a horizontally scrolling timeline in each Wikipedia page in which the topics of the page are located, accompanied by a bunch of events of all types from the period, where each event listed in the timeline would be clickable to go to the relevant Wikipedia page.

This timeline could be enhanced with a zoom to go into more or less detail, as well as filters such as: Characters, History, Politics, Science, Sports... so that its presentation is not too busy.

Clicking on a date or event could also refocus this timeline on the period concerned.

For students, journalists and anyone doing research, this would provide a temporal view of information.

And for all other WEB users another way to navigate your encyclopedia.

In my opinion, this is interesting work which would enhance the encyclopedia by making it evolve qualitatively in terms of ergonomics.

For any clarification if you have not understood the concept, I will be happy to clarify my suggestion with the hope that it will eventually succeed. Htordj62 (talk) 14:54, 12 June 2024 (UTC)

This is a good idea, but I am afraid that it might not necessarily work when different timelines are considered. For instance, taking something like Dinosaur, would we show the timeline of dinosaur evolution from the Triassic onwards with events such as the Cretaceous–Paleogene extinction event, or the timeline (at a completely different scale) of dinosaur research, with the discovery and classification of fossil species and events like the dinosaur renaissance? Chaotic Enby (talk · contribs) 14:58, 12 June 2024 (UTC)

That's right but the scale could be not linear and if you can zoom in/out you can select what you want to see, the idea is not to see complete timeline at first view but to see on page an interesting period.

There is many things to do around this graphically for instance on mouse hover it could break the timeline in several popup timelines depending on different subjects.

Regards Htordj62 (talk) 15:08, 12 June 2024 (UTC)

What I see in https://en.wikipedia.org/wiki/Template:Horizontal_timeline this is a text textline not a graphic so it is limited, and the idea is not to force the page creator to manage it. I see that like a task of server which extracts dates of the page to build the graphic time line and add it on page.

I will try to provide you a graphic view I mean. Htordj62 (talk) 09:43, 13 June 2024 (UTC)

Here you can find a good sample of view using TimelineJS : https://timeline.knightlab.com/ Htordj62 (talk) 10:00, 14 June 2024 (UTC)

↓You

↓might

↓want

↓to

↓take

↓a

↓look

↓at

↓{{Horizontal timeline}}.

↓2603:8001:4542:28FB:46B:9E7E:661:108F (talk) 05:31, 13 June 2024 (UTC) (Actual talk)

│

0

│

1080

│

2160

│

3240

│

4320

│

5400

For any of yall reading this thread in desktop mode, here's what the above template renders like on mobile:

Folly Mox (talk) 23:15, 16 June 2024 (UTC)

Dark Mode as a Premium Feature

If dark mode was offered as a premium feature I'd be pretty likely to pay $0.99 per month for a premium "membership".

Offering this feature would help my eyes and could be a great way to get users to support the site more consistently. 2601:644:9282:65E0:6844:BE91:592E:183F (talk) 01:22, 13 June 2024 (UTC)

See Wikipedia:Dark mode. You can sort-of get it for free. And it would be grossly improper to charge for it. The WMF don't really need the money anyway. They are rolling in it, and a great number of contributors here consider both the way they raise funds and some of the things they spend it on to be less than optimal. AndyTheGrump (talk) 01:34, 13 June 2024 (UTC)

Appreciate your response. Good to know they aren't hurting for funds.

I've used Wikipedia extensively and have donated/contributed multiple times, and thought since I could be convinced to pay for this feature it was worth mentioning as a possible fundraising tactic.

Perhaps it would be grossly improper. Admittedly, I would trust an official Wikipedia feature more than installing a browser extension. 2601:644:9282:65E0:6844:BE91:592E:183F (talk) 01:40, 13 June 2024 (UTC)

I have been using the Dark Mode Gadget for I think a couple years. Some pictures came out wrong, but not enough to persuade me to give up the lovely darkness. Several minutes ago the notice came up that the Gadget was interfering with the new Dark Mode Feature, so I clicked the deactivate and found the correct option in Preferences. Very nice. Well, I don't notice if there's any difference. Alas, I have forgotten which pictures came out wrong with the old Dark Gadget, so don't know whether that was fixed. Anyway go, go, dark! Jim.henderson (talk) 01:44, 13 June 2024 (UTC)

The Wikimedia Foundation is working on a night mode; see mw:Reading/Web/Accessibility for reading. You can feel free to take that amount and donate it to a charitable organization whose goals align with Wikipedia, or some other Wikimedia Foundation project. isaacl (talk) 01:57, 13 June 2024 (UTC)

Lack of Filipino folk arts

It has come to my attention that Wikipedia lacks info about Filipino folk arts. So far I've only seen three pages of Filipino folk songs, and in the folk section of Dance in the Phillipines a plethora of some dance's pages haven't been created. Obviously I'm not trying to say that we should add EVERY SINGLE BIT. But it would be nice to add others. Cyb3rstarzzz (talk) 14:10, 14 June 2024 (UTC)

Try being bold and editing pages yourself to see what you can improve. – Teratix ₵ 14:36, 14 June 2024 (UTC)

To underline what Teratix said, every page on Wikpedia was created by someone. You can be that someone. Phil Bridger (talk) 18:42, 14 June 2024 (UTC)

I (kind of) take my word back for Filipino folk songs, I've done some more research. I don't know the exact amount but it's more than three pages. But Wikipedia is still missing some more, the absence of Filipino folk dances is still present. I'll be sure to make their Wikipedia pages as soon as I can. Cyb3rstarzzz (talk) 09:17, 15 June 2024 (UTC)

As good old dear Liza would say, then fix it dear Henry then fix it. Davidstewartharvey (talk) 09:33, 15 June 2024 (UTC)

Yeah, I'll make sure to make their Wikipedia pages as soon as I can. Cyb3rstarzzz (talk) 14:09, 15 June 2024 (UTC)

Please do remember I am a new user, it'll take some time. Cyb3rstarzzz (talk) 16:58, 15 June 2024 (UTC)

Hi Cyb3rstarzzz, if you haven't already, you should take a look at Wikipedia:Tambayan Philippines and its discussion page. It looks like it's active, so you might be able to find another editor there who has some familiarity with the topic or who would be interested in coordinating efforts. hinnk (talk) 21:18, 15 June 2024 (UTC)

Some kind of reminder at AN/I

This is not a joke proposal.

I'd like to propose some kind of reminder/checker that automatically runs at AN/I, in the style of [21]. Actually reading it back to the user is good, but a given user's computer probably doesn't have the sound turned on all the time, so a pop-up dialogue box, with a five-second delay before the user can click "continue" would probably work too. Something like this:

Here's what you just posted to AN/I:

“ And what the hell is that supposed to mean? You're being very unconsructive here, in fact, you're being a bit of a jerk. Go away, because you are SO not helping. — Swanky Signature (talk :: contribs) ”

Yes, post this comment.Wait, go back.

Thoughts? Cremastra (talk) 20:05, 16 June 2024 (UTC)

Having a delay for every single reply can really make things really annoying. You also have all the different userscripts for replying (CD, Factotum, etc.) that to make that warning appear to every one of them would be really hard. Aaron Liu (talk) 22:41, 16 June 2024 (UTC)

Forced preview was a feature(?) in the early days of the visual editor. However, it previewed the entire page, which would be a terrible experience at ANI.

There's another Wikipedia (Korean, maybe? I can't remember) that does something like this for all posts to their village pump. I don't think it shows your comment. It's more like a message that says "This is the village pump, which is not for random chatting". I don't know for certain how they set it up, but it might be implemented with the 'warn' setting in Special:AbuseFilter. That method would probably work on (almost) all tools. WhatamIdoing (talk) 18:24, 19 June 2024 (UTC)

Wikipedia:MOS on Music / Song Track Listing Credits

I was reading Let_It_Be_(album) #Track_listing and perplexed to find the tracks credited to Lennon–McCartney. While this was the mythos at the time, later scholarship has done a great job distinguishing many of the Beatles tracks as predominantly or entirely written by Lennon or McCartney. I can't seem to find the style guideline on this, but I assume it's something like "song credits should be as written on the original release."

This is unencyclopedic and ahistorical. While most song credits will line up neatly with later scholarship, some rare cases exist where listed credits were chosen for political or business reasons.

The style guide should default to credits as printed (except in cases where artists changed their name later), but allow for those to be de-emphasized in favor of newer research. For example, Let_It_Be_(album) #Track_listing's writer credits should be almost the same as the lead vocalist credits. Anonymous-232 (talk) 20:16, 16 June 2024 (UTC)

The MOS is a style guide that really doesn't deal with what sources are best to use in a given situation, which is why you couldn't find such guidance in it; it's possible that WikiProject Music has some sort of established norm for this, but Wikipedia policy (see WP:V) already greatly favors information in reliable, secondary sources. If such consensus in scholarship exists, and it's cited, I doubt anyone will have an issue with changing the credits of songs to fit that consensus. ~Adam ^{(talk · contribs)} 02:55, 17 June 2024 (UTC)

[22] Rolling Stone interview with Paul about it the credits. Should we be changing what was agreed? Davidstewartharvey (talk) 08:41, 17 June 2024 (UTC)

My gut feeling is that the track listing should match the credit listed on the actual release. Later discussion (whether scholarly research, notable speculation or something in between) is something that should be discussed in prose (maybe accompanied by a list in some cases) that explains the background, why this is a thing that has been researched/speculated about and what the basis for assigning different authorship to each track is. Thryduulf (talk) 09:07, 17 June 2024 (UTC)

Track listing should be as published at time of release. The text of the article can cover anything else: pseudonyms, legal challenges, scholarly analysis, etc. --User:Khajidha (talk) (contributions) 12:33, 17 June 2024 (UTC)

Re-use and edit citation

I find the re-use citation tab to be of limited use, because it only allows using the exact same citation, pages and all. If then I try to edit just the page numbers in the new instance, it will change the page numbers in all instances of that citation, which I do not want. Instead what I'd like to see is the ability to just edit the page numbers in the new instance. I've encountered this use case hundreds of times, when I want to cite the same source but different pages in various places, thus it would greatly ease the burdensome tasks of adding citations. I have yet to encounter a case where i wanted to edit page numbers simultaneously in all instances of a citation. If the latter use case exists, then an option could be provided to change just this instance, or all instances of same citation.

I'd like to hear what other people think Thhhommmasss (talk) 02:44, 19 June 2024 (UTC)

I'd recommend using {{rp}} instead of the page parameter. Using the same source with a ton of different pages multiple times clogs up the reference list IMO. Or you could also use {{sfn}} if you're going to reuse the same page from a source that has multiple pages cited as well. Aaron Liu (talk) 03:09, 19 June 2024 (UTC)

I prefer using rich-text edit to source edit, since former is more convenient and faster for me. Instead I now have to use sfn which is a pain, and to get around that very often I use multiple automatically generated citations, via link, of the same source. But that too requires me to go to Google books or a similar source to get the same link again, so again more effort, plus it generates duplicate entire citations of same source. 95%+ of my citations from the same source are for different pages, and I do not need each one of these in the reference list, instead just the last referenced page could be kept in the list Thhhommmasss (talk) 06:22, 19 June 2024 (UTC)

Well, VE is indeed slower if you're working with templates. I find the 2010 Wikitext editor to be the best. It loads fast, has syntax-highlighting, and works with templates fast. You can use WP:ProveIt to autogen cites in source mode. Aaron Liu (talk) 19:40, 19 June 2024 (UTC)

The issue isn't the extra second or two that it takes VE to load vs. wikitext, instead t the considerably greater time it takes to to manually type out the wikitext citation template, vs. just clicking to select a source in VE from the reference list, and as noted below, input the new page number into a dialog. Plus, new editors are much less likely to be familiar with wikitext, so this could be another hurdle to participating Thhhommmasss (talk) 22:13, 19 June 2024 (UTC)

I do not doubt that the current workflow in VE has things to be desired. However, what I'm saying is that in the meantime, you can use the 2010 Wikitext to edit the pages faster than what you probably currently do. You can use a clipboard manager (including Windows's default, ⊞ Win+V) to copy the parts of the sfn templates right before the page number, and all you'll have to type is e.g. 41}}.
While WMDE works on the wish, someone might be able to make a userscript. Aaron Liu (talk) 22:38, 19 June 2024 (UTC)

When using Word or gmail, I also prefer their VE, instead of having to use Word markup or html, no matter the templates or other features they may have. I suspect the vast majority of users do too. I know some prefer different, and the proposal has no impact on current wikitext edit, it's only intended to help those who prefer VE. Believe change outlined below should be relatively easy Thhhommmasss (talk) 00:51, 20 June 2024 (UTC)

You can file a Phabricator task if you want. Aaron Liu (talk) 02:32, 20 June 2024 (UTC)

Thank you, I will look into thatThhhommmasss (talk) 22:25, 20 June 2024 (UTC)

Personally I despise {{rp}}: it's ugly, confusing to anyone who doesn't already know that ^[1]:23 is supposed to mean "page 23 in reference 1", and separates the page number from the reference. I wish m:WMDE Technical Wishes/Reusing references / m:WMDE Technical Wishes/extending references would happen; unfortunately it seems to keep stalling because of having to support VE. Anomie⚔ 11:42, 19 June 2024 (UTC)

I would also like to see WMDE's work become an option here (subject to all the usual WP:CITEVAR standards, of course). WhatamIdoing (talk) 18:18, 19 June 2024 (UTC)

Another approach would be not to save the pages to the reference list, since it is much more common that one wants to reference different pages in the same source, instead of wanting to repeatedly reference the same page. Then when user selects the source from the re-use list, a dialog could pop-up to let the user input the page numbers and save. As noted, I generally use the GUI edit since it is much faster, and I find having to switch to source edit for wikitext templates, just to reference a different page, to be one of the greatest pain points in WP usage. Citing in general is the biggest, most time-consuming chore, probably one of the main reasons people are less likely to edit and why many articles lack sufficient in-line citations, The issues with re-use make this worse Thhhommmasss (talk) 18:38, 19 June 2024 (UTC)

A confusion disclaimer should be added to the top of the page for cisgender

[section originally titled: "A confusion disclaimer should be added to the top of the page for cisgender to avoid confusion with the Russian military pact Commonwealth of Independent States often abbreviated as (CIS)"]

i tried searching for CIS Commonwealth of Independent States and i received the page for Cisgender. if somebody who maybe was unaware of the full name of the commonwealth of independent states attempted to search for the frequently used acronym CIS the full page maybe be hard to reach.

full disclaimer I don't intend to degrade gender science and thus the page for cisgender I love trans people 2601:584:4400:4110:CC8A:47DD:7DBD:EA0D (talk) 14:13, 19 June 2024 (UTC)

• What method did you use to search? Cis and CIS are disambiguation pages? Thryduulf (talk) 14:18, 19 June 2024 (UTC)

Indeed. I did a quick test by searching for CIS with 3 search engines:

• Wikipedia's internal search engine:takes me directly to the disambiguation page
• Google: First hit was the Center for Internet Security
• DuckDuckGo: First hit was the Wikipedia page for Cisgender

So based on that HIGHLY SCIENTIFIC test,;) the search results aren't consistent and likely vary based on the search engine's profile of the user. It also appears Google's algorithm differentiates between CIS and Cis while DuckDuckGo's does not. However, the only one we directly control lands on the disambiguation page. So I'm not convinced there's much we can or should do. Dave (talk) 15:27, 19 June 2024 (UTC)

What to do with near-empty lists of names of obscure asteroids?

At Wikipedia:Articles for deletion/Meanings of minor planet names: 500001–501000, it was suggested to start a broader discussion about what to do with these lists. We have now 568 (and counting) such lists (Category:Lists of meanings of minor planet names, and while the lower-numbered ones are about notable subjects where the lists are perfectly acceptable as is, the higher-numbered ones are a collection of explanations of the names of obscure asteroids, named after obscure people (e.g. the great-grandfather of the discoverer of the asteroid, Meanings of minor planet names: 623001–624000). Should these be deleted, merged, ...? Simply keeping something like Meanings of minor planet names: 618001–619000, a one-entry list sourced to a primary source, seems to go against all notability guidelines and what is accepted for other topics. And where is the cutoff between the notable ones and the non-notable ones? All ideas to help write an RfC or other proposal about this are welcome. Fram (talk) 07:51, 20 June 2024 (UTC)

One problem here seems to be that the structure of the lists that makes sense for the first 20k or so entries is extended to 700k entries. Aggressive merging into larger lists covering 10k-100k asteroids each would already substantially improve the usefulness of these. —Kusma (talk) 09:09, 20 June 2024 (UTC)

I looked at Meanings of minor planet names: 623001–624000. It ostensibly covers 1000 minor planets. It has ten ==Sections==, each of which is intended to cover 100 minor planets.

The number of minor planets actually covered is: two (2). On the whole page. There are nine empty sections with nine empty tables, and one section containing a table that has information about two of them.

I'm okay with the page only having a couple of entries; presumably some others will m:eventually get added. But I would like to consider a rule that says there should not be so many empty sections. IMO sections should be added when they're needed, not merely because the page exists. So that's one thing that could be discussed in an RFC: Should the structure be set up before there is content? WhatamIdoing (talk) 21:27, 20 June 2024 (UTC)

Disagree. --Dustfreeworld (talk) 19:01, 21 June 2024 (UTC)

Maybe empty lists could be removed, and the pages consolidated into larger ranges (say, 500001–600000) with only named minor planets discussed in reliable sources? Chaotic Enby (talk · contribs) 20:19, 21 June 2024 (UTC)

Search engine for policy

I think there should be a search engine for Wikipedia policy where you can put in key words and the relevant pages come up Alexanderkowal (talk) 22:50, 20 June 2024 (UTC)

We have discussed putting policies in a separate hyphenated namespace as we do with the manual of style..... but to no avail yet. Pls see WP:GOVP for a whole bunch of different search boxes as seen down below..... that can be found on the namespace pages. You can also select this by the magnifying glass see Help:Searching.

Moxy🍁 00:11, 21 June 2024 (UTC)

But the MOS is in the project namespace? The MOS: redirects are in mainspace. Aaron Liu (talk) 00:20, 21 June 2024 (UTC)

Because the MOS are subpages organized like Wikipedia:Manual of Style/search term you can narrow down a search to just the manual of style (as seen in the box below). If policy pages or guidelines were set up in the same manner it would be an easy search. ....like Wikipedia:Policy/search term. But one of the problems is the MOS is a guideline.... so the search parameter Wikipedia:Guideline/search term maybe confusing and give a multitude of results that aren't actually part of the MOS. It's a conundrum that has never really been solved. It is odd that it's easier to search for Wiki projects then our policy pages because of the hyphenated name setup Wikipedia:WikiProject/search for a project you're interested in Moxy🍁 02:19, 21 June 2024 (UTC)

Don't we have searching in categories now? Aaron Liu (talk) 02:53, 21 June 2024 (UTC)

Deepcat for policies seem to always fail for some reason. Normal incategory doesn't. Aaron Liu (talk) 02:59, 21 June 2024 (UTC)

Those search boxes you’ve linked are really good, maybe have them on the page for beginners? Like the introduction to policy one Alexanderkowal (talk) 04:49, 21 June 2024 (UTC)

The writing could be “Feel free to search some key words to start reading policy. Editors intimate with Wikipedia policy will usually link relevant policies in discussions.” Alexanderkowal (talk) 05:30, 21 June 2024 (UTC)

WMF

Proposal: "job aids" for Wiki editors

Moved to Wikipedia:Village pump (idea lab) § Proposal: "job aids" for Wiki editors

 – Suffusion of Yellow (talk) 23:27, 7 May 2024 (UTC)

Digital Safety on Wikimedia Platforms

Hello Wikimedians,

We are reaching out to you all today with a message from the Human Rights and Trust and Safety Teams at the Foundation to provide you with some resources around digital safety while using the projects.

What do we mean when we say “digital safety”? Your digital safety on Wikimedia platforms can refer to your risk of being harassed, doxxed, or targeted by external organisations. There are ways to reduce the risk to yourself while you are using the platforms. For example, protecting your personal information gives anyone targeting you limited access to you and your life outside Wikimedia.

Here are some available resources to help with your digital safety:

• You can find lots of helpful resources at the Human Rights Meta page for Digital Security;
• You can read this Meta page on digital security concerns for Wikimedians;
• There is this Meta page from Trust and Safety with some resources for those dealing with harassment;
• We also have a learn.wiki module about digital safety where you can learn how to do a digital security risk assessment on yourself.

You can also read the following Diff posts:

• How can a username keep you safe?
• Doxing: Have you tried doxing yourself?
• Doxing: Why should you care?
• Digital safety during election time
• Digital safety best practices when attending conferences
• The Internet Outages Guide

Also, for some resources produced by other organisations, see the simple Security Planner to proactively stay safe online, and explore the Digital First Aid Kit for guidance in addressing digital harms as they arise.

If you are ever experiencing digital safety issues due to being active on Wikimedia platforms and you don’t know how to resolve them, or if you have any thoughts or questions on digital safety, you can reach out to our teams:

• For concerns around harassment, abuse, doxxing, disinformation, or other Trust and Safety concerns: ca@wikimedia.org
• For concerns about being targeted by a government or other human rights related concerns: talktohumanrights@wikimedia.org

Kind regards, Human Rights and Trust and Safety at the Wikimedia Foundation Wikimedia Foundation office (talk) 10:43, 24 May 2024 (UTC)

Wikimedia Foundation banner fundraising campaign in India

Dear all,

I would like to take the opportunity to inform you all about the upcoming annual Wikimedia Foundation banner fundraising campaign in India.

The fundraising campaign will have two components.

1. We will send emails to people who have previously donated from India. The emails are scheduled to be sent between the 22nd of July to the 15th of August.  
2. We will run banners for non-logged in users in India on English Wikipedia itself. The banners will run from the 13th of August to the 10th of September.

Prior to this, we are planning to run some tests, so you might see banners for 3-5 hours a couple of times before the campaign starts. This activity will ensure that our technical infrastructure works.

I am also sharing with you a community collaboration page, where we outline more details around the campaign, share some banner examples, and give you space to engage with the fundraising campaign.

Generally, before and during the campaign, you can contact us:

• On the talk page of the fundraising team
• If you need to report a bug or technical issue, please create a phabricator ticket
• If you see a donor on a talk page, VRT or social media having difficulties in donating, please refer them to donate at wikimedia.org

Thanks you and regards, JBrungs (WMF) (talk) 05:59, 6 June 2024 (UTC)

Board of Trustees election

The Q&A phase is underway, closing on June 12. Here's the candidate list. –Novem Linguae (talk) 21:11, 7 June 2024 (UTC)

WMF Transparency Report Accounting

During our discussion on Katherine Maher, the comms team shared resources on cases where WMF intervenes on content and policy decisions and I had some follow up questions. For example it's showing 89 requests on English Wikipedia, 33 by USA in H1 2021 . How do we see which content was affected? cc @LDickinson (WMF) Tonymetz 💬 22:07, 10 June 2024 (UTC)

No content was affected. All of the requests were denied. * Pppery * _{it has begun...} 23:16, 10 June 2024 (UTC)

I don't believe that's true, because @WMFOffice has contributions that are a subset of the above report, so there are some changes that are recorded and some that are not yet accounted for. Tonymetz 💬 23:28, 10 June 2024 (UTC)

What are you talking about? Most of WMFOffice's edits are marking users as globally banned (a process that has nothing to do with anything in the transparency report). None of it's extremely few other edits have anything to do with third-party requests for removal or alteration of content. * Pppery * _{it has begun...} 23:36, 10 June 2024 (UTC)

can you share more context on that? The transparency report doesn't seem to show that Tonymetz 💬 23:32, 10 June 2024 (UTC)

Scroll up to the very top of your link:
Content alteration and takedown
0 Requests granted
276 Total requests
* Pppery * _{it has begun...} 23:36, 10 June 2024 (UTC)

thanks i use a screen reader and the section i was using seemed to show alterations vs deletions. I'll see about the section you were talking about. Tonymetz 💬 20:14, 11 June 2024 (UTC)

Wikimedia Foundation Bulletin: an experiment

Hi all. We invite your feedback on a proposed way to improve communication from and about the Wikimedia Foundation. The Wikimedia Foundation Bulletin is an experiment to establish a more standardised format and cadence. It would include headlines and links from the Wikimedia Foundation's technical work; Foundation activities with communities and affiliates; as well as with other stakeholders like readers, donors, regulators, the media, and the general public.

A short overview of the concept itself is on Meta at m:Wikimedia Foundation Bulletin, with the first “trial” issue at m:Wikimedia_Foundation_Bulletin/2024/06-01 - also copied below. You can subscribe to the bulletin via talk page delivery on any Wikimedia wiki. Depending on the feedback received, we might start this as a regular Bulletin for the coming fiscal year (which starts July 1).

This is an experiment: we want to know what you think, what is missing, what is too much, and whether this is something that we should consider investing more time and effort into. Please post your feedback on the Bulletin talk page - on the concept itself, and suggestions on anything from the design to specific words used would also be helpful. You can also provide feedback in this thread; by email to askcacwikimedia.org; or at the next Conversation with the Wikimedia Foundation’s Board of Trustees on 27 June at 18:00 UTC.

On behalf of the Wikimedia Foundation Community Affairs Committee, MPeel-WMF (talk) 18:38, 18 June 2024 (UTC)

Bulletin June 2024

Here is a quick overview of highlights from the Wikimedia Foundation over the first half of June 2024. Please help Translate.

---

Upcoming and current community conversations

Talking: 2024 continues

• Open AffCom Office Hours on Affiliates Strategy Implementation (June 19 at 14:00 UTC)
• Procedure for Sibling Project Lifecycle: Call for feedback (through June 23)

Annual Goals Progress on Infrastructure

See also newsletters: Wikimedia Apps · Growth · Research · Wikifunctions & Abstract Wikipedia · Tech News · Langauge and Internationalization · other newsletters on Mediawiki.org

• Improvements for editors with extended rights - Edit Check, PageTriage, Edit Patrol on Android, Release Rights improvements in Upload Wizard, and the Watchlist on iOS.
• Responding to other community needs with Edit Recovery, QR share, Multiblocks schema changes, AutoSuggestSiteLink and bringing back The Who Wrote That Extension.
• Voting on Community Wishlist Survey renaming (through June 20)
• Scholarship Applications for the Wikimedia Technology Summit (WTS-2024) are open (through July 10)
• Wikimedia Enterprise updates: Realtime Streaming Updates: Parallel Connections and Restart Support (June 14)
• AI for the people: How machines can help humans improve Wikipedia
• Designing the typography of Wikipedia
• Latest Tech News

Annual Goals Progress on Equity

See also a list of all movement events: on Meta

• Upcoming Wikimania (7–10 August, Katowice, Poland): the Program will be soon announced!
• Africa Growth Pilot: feedback is invited for Module 2: 101 Ways to Contribute to Wikimedia
• Let's Connect: about the new Event Registration Tool and a Women's Health in Wikimedia Projects
• WikiLearn: Check out some of our newest courses such as Open Refine for Wikimedia Commons
• WikiCelebrate: Celebrated the work of B20180, a prolific administrator of Thai Wikimedia projects and a content contributor in Thai and beyond!
• Community conferences: submission deadline for Round 1 applications: September 2.

Annual Goals Progress on Safety & Inclusion

See also blogs: Global Advocacy Blogs · blogs

• Final draft of the Movement Charter published on June 10. Movement Charter Launch Party on June 20. Ratification: June 25–July 9
• Evaluation of the U4C election results (ongoing)
• “Don’t Blink”: Protecting the Wikimedia model, its people, and its values in April 2024 (June 4)

Annual Goals Progress on Effectiveness

See also: quarterly Metrics Reports

• Feedback welcome on community collaboration page for annual banner fundraising campaign on English Wikipedia in India for non-logged in readers (planned for Aug 13 to Sep 10)
• Banner fundraising campaigns started in Japan, Spain (also on Catalan Wikipedia), Greece, Malaysia, Portugal, South Africa, and Sweden (through June 25)
• Progress on the plan: How the Wikimedia Foundation has advanced on its 2023-2024 Annual Plan goals – Part 3 (June 12)

Wikimedia Endowment updates

• The Wikimedia Endowment 2022–2023 annual report published
• First grantees – Abstract Wikipedia and Wikifunctions, Kiwix, the Wikimedia machine learning project and Wikidata

Board and Board committee updates

See Wikimedia Foundation Board noticeboard · Affiliations Committee Newsletter

Trustees talk about how the Wikimedia Foundation Board of Trustees works

• 2024 Board Selection: Call for Questions for candidates ended on June 12
• Affiliates strategy: Affiliate Health Criteria and changes to the User Group recognition process (June 12)
• Upcoming Board meeting: June 20 (agenda)
• Upcoming Conversation with Trustees: June 27

In the media

• Elections 2024: How Wikimedia is combating misinformation using AI, human intervention (June 2)
• AI ‘gold rush’ for chatbot training data could run out of human-written text (June 6)
• ‘We’re writing history’: Spanish women tackle Wikipedia’s gender gap (June 12)

Other Movement curated newsletters & news

See also: Wikimedia blog · Goings-on · Wikimedia World · Signpost (en) · Kurier (de) · other newsletters:

• Topics: Education · GLAM · The Wikipedia Library
• Wikimedia Projects: Communities newsletter · Milestones · Wikidata
• Regions: Central and Eastern Europe

Subscribe or unsubscribe · Help translate

Previous editions of this bulletin are on Meta. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!

MPeel-WMF (talk) 18:38, 18 June 2024 (UTC)

what is status of movement charter drafting commission (mcdc)?

what is the current status of the movement charter drafting commission (mcdc)? can someone please post an update here, on the status of this process? I'm somewhat surprised that an update has not been posted here, for the current stage of the process. Sm8900 (talk) 19:37, 21 June 2024 (UTC)

In § Bulletin June 2024, see the item starting with "Final draft of the Movement Charter published on June 10." isaacl (talk) 00:45, 22 June 2024 (UTC)

Miscellaneous

Inexplicably popular article (by views)

Tracked in Phabricator
Task T366554

Neatsville, Kentucky in April was the 2nd most viewed Kentucky-related article and has been similarly highly viewed for several months. I cannot make sense of this. This is a small unincorporated community in the middle of rural Kentucky. I cannot find any TV show or movie referencing it. It also doesn't make sense that anyone would be gaming this outcome for months (although I suppose this isn't impossible). Am I missing something? Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 21:00, 28 May 2024 (UTC)

Fascinating. Two-year pageviews are even higher on average, peaking in mid-2023. I see no news coverage or anything else that would drive this traffic. BD2412 T 21:28, 28 May 2024 (UTC)

The start of this climb in pageviews seems to have been on 24/25 August 2021 ([23]), when daily pageviews climbed from 2 to 410 to 1,717. Perhaps this may narrow the search for what is causing this. Curbon7 (talk) 22:39, 28 May 2024 (UTC)

Billy Joe in the same Kentucky county announced he saw a UFO on 8/24. LOL. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 23:47, 28 May 2024 (UTC)

Also, nearly all of the traffic coming to the article is from unidentified external routes (which is highly unusual), and there is virtually no traffic from this article to other articles (also highly unusual). BD2412 T 22:02, 28 May 2024 (UTC)

Maybe there's a viral post or tweet somewhere with an easter egg? Schazjmd (talk) 22:07, 28 May 2024 (UTC)

Possibly. Although I've not heard it, I can easily imagine a meme in which "Neatsville" (a redirect to the article) becomes a trendy term of approval. (Compare Coolsville.) Alternatively, someone may be trying to get it into a most-viewed listing. It would be interesting to know how many different IPs have accessed the article (perhaps counting each IPv6 /64 as one), rather than just the number of hits. Certes (talk) 22:20, 28 May 2024 (UTC)

Redirects seem to be negligible in their impact. Unchecking "Include redirects" makes virtually no difference. Regarding someone gaming this, that's an awful lot of such to sustain. Of course, this could be a script disguising itself as a real person. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:35, 28 May 2024 (UTC)

Thanks for the pointer on redirects: I hadn't spotted that. Yes, I assumed it was scripted. It does seem erratic and slightly seasonal, with peaks in spring 2023 and 2024, but does not vary much by day of week. Certes (talk) 22:49, 28 May 2024 (UTC)

That crossed my mind, but I think the incoming traffic would be more varied and identifiable for something like that, rather than a dark web monolith (speculation before further details). Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 23:23, 28 May 2024 (UTC)

This sounds like a repeat of Mount Takahe, which also has inexplicably high reader numbers. And like Takahe, Neatsville has fairly average reader numbers when only counting the Mobile App and only slightly elevated reader numbers with by spiders. FWIW, neither News nor Twitter/X show many if any mentions. Jo-Jo Eumerus (talk) 07:18, 29 May 2024 (UTC)

This is getting really ridiculous. It's skewing statistics, even to the point where new editors are noticing. I don't want make this into some huge problem, but I think "nipping it in the bud" is well called for now. Please admins block the access of this apparent script kiddie. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 21:51, 3 June 2024 (UTC)

I have logged a case in WP:ANI. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:10, 3 June 2024 (UTC)

Admins do not have the ability to block people from viewing articles, this would have to be handled by the system administrators. You would probably be best filing a ticket on Phabricator, though I'm not sure they'd take action. 86.23.109.101 (talk) 22:53, 3 June 2024 (UTC)

I'm not sure what action can or should be taken. This doesn't seem to be a denial-of-service attack (or, if it is, it's an incredibly lame one). Wikipedia's terms of service don't prevent anyone from viewing pages, even multiple times; in fact it's encouraged. I don't know whether the hosting system can, or should, rate-limit a particular IP address or range, even assuming that most of the unusual traffic comes from one IP or a small range. Certes (talk) 23:13, 3 June 2024 (UTC)

Indeed. I wouldn't be reporting this as a performance or security issue, but rather a data corruption issue. And I sense this might not be taken very seriously, but I have a thing against the presentation of false data and that in that presentation, the person doing it is getting away with it, possibly encouraging more of this kind of corruption by others. I think it is in our long-run interests to stop it or put some kind of brakes on it. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 23:52, 3 June 2024 (UTC)

If this is due to a malicious botnet, shouldn't you have WMF report this to law enforcement? –LaundryPizza03 (dc̄) 01:20, 4 June 2024 (UTC)

I don't know if it's malicious. It's just skewing our cumulative views data on a single article. I might rather have an ISP notified if that could be pinned down. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 02:10, 4 June 2024 (UTC)

The internet can be a bit of a wild west sometimes. I don't think calling the police to report a DDOS attack would result in anything. DDOS attacks are usually carried out by hacked zombie computers, and are often transnational. So it's a bit hard to police. –Novem Linguae (talk) 07:43, 4 June 2024 (UTC)

An inexplicable steady increase in readership to an article happened one time before, and the explanation was that it had been included as an example/default link somewhere. Will see if I can find the details. –Novem Linguae (talk) 23:20, 3 June 2024 (UTC)

That's a possibility if it's not a link from English Wikipedia but another project or website. I had already reviewed EN pages linking to the article and didn't see anything. Thanks for checking. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 23:46, 3 June 2024 (UTC)

It's tempting to put a banner on the top of the article: "Please tell us what brought you to this article" with a link to the talk page, see if any of the 17,000+ readers answer. Schazjmd (talk) 23:49, 3 June 2024 (UTC)

Many years ago I found – guess how – that the address anton@pobox.com was used as an example in what appeared to be a guide to email for new users (in Russian, but hosted in Israel). —Tamfang (talk) 22:17, 12 June 2024 (UTC)

Found this through some searching, not really sure where it came from: urlscan1: Kepler's Supernova article, urlscan2: Neatsville, Kentucky article. The scan was for a different url, which redirected to those Wikipedia pages with some (ad tracking?) parameters. – 2804:F1...99:B28F (talk) 05:48, *edited:06:42, 4 June 2024 (UTC)

Mind you, the interesting thing would have been to know where that original link was from (possibly emails? unsure) - both were scanned on the 17th of last month and both articles have an increase in views, but without knowing where that's from and if it always redirects there, it doesn't really mean it's even related with the view count unfortunately. – 2804:F1...99:B28F (talk) 06:42, 4 June 2024 (UTC)

Thanks for bringing this here. Is it fair to say that Kepler's Supernova is also getting the same kind of fake views? Or could its extra recent views have a legitimate reason behind it? Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 07:03, 4 June 2024 (UTC)

Not that I could find, both noticeably grew in views since April: Kepler's Supernova, Neatsville, Kentucky

According to wikitech:Analytics/AQS/Pageviews#Most viewed articles the most viewed list (same data as the graphs) tries to only count page request from "human users", so it's not clear if the views are fake, though a reason is also not obvious. Do you know why the Neatsville article had similar numbers in from March to June of last year? – 2804:F1...99:B28F (talk) 08:21, 4 June 2024 (UTC)

I have no idea, and I'm in Kentucky. This place really is "in the sticks". Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 08:34, 4 June 2024 (UTC)

Talk page for Kepler's Supernova says Publishers Clearing House for some reason included a link to [the page] in email (promoting daily contests) for awhile. Page view patterns are the same as with Neatsville. Not sure if this IP is relevant either 107.128.181.22 (talk) 08:31, 4 June 2024 (UTC)

Publishers Clearing House for some reason included a link to [the page] in email (promoting daily contests) for awhile. This seems like the most plausible explanation so far. –Novem Linguae (talk) 12:10, 4 June 2024 (UTC)

I have reported this as a security issue (re: data integrity) to Phabricator. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 06:54, 4 June 2024 (UTC)

It might be very helpful to know how many different IP addresses access the page a lot (say >100 times a day) and whether they're in a single range. Obviously this requires access to non-public information, but it should be safe to pass on a digest with the actual IPs removed. Certes (talk) 11:04, 4 June 2024 (UTC)

Update: Neatsville, Kentucky in May was the top most viewed Kentucky-related article. This effectively trashes the point of having a Popular pages list. There are bigger things to be outraged about in this world, but as far as Wikipedia goes, this really honks me off. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 17:00, 10 June 2024 (UTC)

The number of views 26k is so low it could easily be explained by a default link somewhere. The Publishers Clearing House explanation given above sounds reasonable, or something like it. These kinds of things are not uncommon. If the popular pages list is important, you could modify the list with another bot. -- GreenC 17:20, 10 June 2024 (UTC)

This isn't a very recent phenomenon. The views have been skewed off and on since over a year ago (see "Two year pageviews..." link above). Also, the explanation as such doesn't absolve this as not being a problem. There is no excuse for PCH or any entity for sending non-purposeful (junk) links to people. Whether or not it affects our system performance, it is abusive. As far as modifying Popular pages results, if there was a straightforward way to asterisk, strikethrough, hide or shade an entry based on particular criteria, that would suffice, but writing a new bot seems overwrought. I could temporarily strikethrough, hide or shade the top or nth entry via CSS but then that would require monthly maintenance. I think I'll just write a nasty letter to PCH - that may be our real solution (half-joke, half-serious). Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 20:47, 10 June 2024 (UTC)

Meh, somebody put a link in an email or newsletter or something. That doesn't strike me as abusive; if people are clicking the links and reading our article that's really no different than anyone who sees one of our articles through a link in a tweet or Discord, that page was popular. It doesn't seem like there's anything to be done. The Wordsmith^{Talk to me} 21:24, 10 June 2024 (UTC)

We'll just have to disagree on this. They had no business skewing views to these articles. What on earth is the purpose? These are not legitimate views. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:37, 10 June 2024 (UTC)

Wait one min-u-ette here. If these are all genuine human visits off an e-mail or promotion, how come I'm the only one to edit the article (once) since September? With the huge amount of visits, that seems to defy reason. For a small rural town, it has a kind of interesting story, having been relocated twice – so it's weird that edits wouldn't have happened. These are highly likely bot hits disguised as human hits. That's not a problem?? Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:57, 10 June 2024 (UTC)

Is it possible for Wikipedia articles to be embedded into a webpage, and if so, is it possible these collect pageview data without people clicking through? Curbon7 (talk) 23:43, 10 June 2024 (UTC)

Yes (<iframe>) and yes. Probably uncommon though. –Novem Linguae (talk) 23:53, 10 June 2024 (UTC)

No. it's not a problem. Who cares why any of our articles are read and who by? Phil Bridger (talk) 06:36, 11 June 2024 (UTC)

Thanks for your opinion, but it's not as simple as that. This is systems data used beyond the superficial aspect that you imagine. Note that if views data wasn't important, it wouldn't be collected and stored in the first place. It can be used for various purposes, like for instance, project prioritization. Corruption of data is a real problem. I am not suggesting this specific issue reported here is a huge problem but one that should be addressed lest it really get out of hand. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 06:53, 11 June 2024 (UTC)

I agree with Phil. Usually website backlinks are a good thing, for search engine optimization and brand awareness reasons. If it causes one aberrant data point in one report, that's fairly minor. –Novem Linguae (talk) 07:13, 11 June 2024 (UTC)

Through my background in database development and 20 years as a Wikipedian, I insist it's a real (though not currently huge) problem by what I've already stated. Also, there seems to be an insistent assumption these are true views. Based on information that's been made available, the strong suggestion is that these are effectively bot hits. Also, I highly doubt we are getting SEO benefits from distributed junk hits, and who doesn't already know our brand? The bottom line is this has a potential to really bollocks up various processes that use this data if it isn't nipped in the bud. "Fairly minor" is today. But tomorrow? Yeah, let 'em increasingly tarnish our data. Cool, man, cool. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 07:32, 11 June 2024 (UTC)

We really need to ask someone with access to private logs whether these views come predominantly from one IP (or a small range) or are widespread. If the latter then they may also be able to tell us (perhaps from the referrer) whether they are predominantly from one webpage, perhaps via an iframe embedded in HTML bulk e-mail. Certes (talk) 09:53, 11 June 2024 (UTC)

I concur. That's a part of why I logged the issue in Phabricator, so that an investigation can be conducted. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 19:37, 11 June 2024 (UTC)

Also, I realize that when I said "distributed", I was buying into an assumption but yes, it's possible this comes from one IP or a small range. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 19:39, 11 June 2024 (UTC)

Even that's not absolute proof. A significant portion of our page views from mainland China come to use through just two (2) IP addresses (used by a VPN service). If you find that most of the traffic comes from a single IP, that does not mean that a single person is reloading the same page every few seconds round the clock. It could mean that a lot of people are using a VPN or other shared service.

You might also be interested in https://theconversation.com/2022-wasnt-the-year-of-cleopatra-so-why-was-she-the-most-viewed-page-on-wikipedia-197350 and similar reports. WhatamIdoing (talk) 15:41, 12 June 2024 (UTC)

I guess my view doesn't count because I have only been editing Wikipedia for 17 years and my background is in systems programming, but I'll state it anyway. It is that the only problem here is with people who place too much faith in reports. Measure what you actually want to measure, not what's easiest to measure, and don't try to change what you're measuring to make it easier. Phil Bridger (talk) 20:47, 11 June 2024 (UTC)

Some reports do weed out automated views, sometimes by limiting their scope to articles which have between 5% and 95% of their views from mobiles. (Example: Signpost.) This technique is helpful but not foolproof, especially if someone who reads the report is trying to appear on it in some sort of SEO game. Certes (talk) 21:51, 11 June 2024 (UTC)

As someone with a similar background, these are the kinds of arguments you find in IT departments, I suppose. The report isn't the problem but rather the report is indicative of a data problem, and it's the data problem that should be solved, because that problem could increase and cause other issues. And yes, we should change what we're measuring, rather, prevent bad data input (the case here), because you don't want "garbage in". Spending time to assure clean data going into further processing in other systems was a significant part of my IT work. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 17:01, 17 June 2024 (UTC)

I am inclined to concur that we aren't looking at genuine readers here - few people seem to go from Neatsville to other articles. Compare Donald Trump, where almost all readers then go on to read other articles. That might be an iframe deal or a bot, but not people directly reading the article. Jo-Jo Eumerus (talk) 07:45, 11 June 2024 (UTC)

Of course we aren't. But what does any of this have to do with Wikipedia? Phil Bridger (talk) 20:47, 11 June 2024 (UTC)

There are lots of people who are interested in how widely shared information on a given Wikipedia page is. That tells us something about which topics are important, which ones need to be taken care of etc. Distributing information is the purpose of a Wikipedia page after all. Jo-Jo Eumerus (talk) 06:01, 12 June 2024 (UTC)

This may be related (or unrelated), but my talk page received an unusual number of page views each day from late March to early April: see here. Besides a couple of messages from the bots, there weren't any other activity on my talk during that time [24]. I doubt those page views (at least on my talk page) are genuine. Some1 (talk) 03:40, 18 June 2024 (UTC)

Rename the article?

This constant pinging of our article could easily be disrupted by renaming the article without leaving a redirect, if only for a day or two. Of course that might still count as vandalism, and make Skynet very angry. NebY (talk) 19:02, 16 June 2024 (UTC)

• Done. I have temporarily boldly moved the page to Neatsville, Adair County, Kentucky. I will move it back in a week (at 16:00, 24 June 2024 (UTC)), and we will see what comes of that. BD2412 T 16:08, 17 June 2024 (UTC)

• Note: I have also temporarily changed all incoming links from reader-facing spaces. In case anyone is concerned that the above move will impede legitimate searches for this title, it is now the first search result that comes up when searching for Neatsville, Kentucky. Cheers! BD2412 T 16:25, 17 June 2024 (UTC)

  Neat! And nicely done. I'm looking forward to seeing how it turns out; already I've been surprised to find that the iOS app is still giving me the article at Neatsville, Kentucky (but a blank talk page and an "unexpected response from the server" for its history) as well as at Neatsville, Adair County, Kentucky. Maybe I'm the last to learn the iOS app uses a different database, which lags. NebY (talk) 20:38, 17 June 2024 (UTC)

Thank you both for the concept and implementation. I imagine at the very least the results will add to our body of knowledge. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 17:22, 17 June 2024 (UTC)

Seems a bit odd to let off-site pressures dictate the titles of our articles. Also if the Publisher's Clearing House explanation is accurate, we have now broken this link for regular users. Also may be a violation of WP:PMRC. –Novem Linguae (talk) 01:14, 18 June 2024 (UTC)

This is effectively an experiment to determine whether moving the article — for one week — resolves the issue that has been reported. It may well be that these views are the result of an internal glitch rather than on off-site one, and this resolves that all the same. It may be that when the article is moved back, the issue will resume. The only way to find out is to perform the experiment and gather the data for analysis. As noted, the correct article is still the number one article that comes up when using the search function, and given the page views prior to this situation arising, actual inconvenience to regular users should be nominal. BD2412 T 02:50, 18 June 2024 (UTC)

I would oppose a permanent rename for a flimsy reason like that, but all along, this was set up as a one-week test, and I don't see a big problem there. Anyway, I saw that Neatsville, Kentucky was redirected after this test was started, so I wonder if that defeats the point of the test. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 02:58, 18 June 2024 (UTC)

I don't think it will defeat the point, since pageviews of redirects are tracked separately from pageviews of their targets. But then I could be misunderstanding. * Pppery * _{it has begun...} 03:04, 18 June 2024 (UTC)

Yes that's true, but now these miscreant/fake hits will be hitting a live mainspace page that happens to be the same page they were targeting before. So, they won't be getting any indication they are hitting a nonexistent page like they would have when the test was first set up. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 03:10, 18 June 2024 (UTC)

(edit conflict) The point of moving without the redirect was to see whether the absence of anything at this target would "break" whatever is causing the excessive page views. Perhaps the few hours during which there was no redirect was enough to do that. The test does not have to run for a week, that was an arbitrary time set figuring that whatever process was involved might itself be on a week-long clock. Maybe a few days would do. BD2412 T 03:11, 18 June 2024 (UTC)

New data: This is remarkable. Two days after moving the article, Neatsville, Kentucky continues to average close to 20,000 pageviews per day, but Neatsville, Adair County, Kentucky is averaging 50 pageviews per day. Anyone actually navigating to the Neatsville, Kentucky link would be redirected to Neatsville, Adair County, Kentucky, which should therefore also have those tens of thousands of views. This definitively means that visits to Neatsville, Kentucky are not organic views from regular readers, but are queries of the URL itself that therefore do not get redirected. BD2412 T 17:15, 19 June 2024 (UTC)

That's maybe not so clear; I find that if I click "include redirects" then Neatsville, Adair County, Kentucky is receiving 20,000+ pageviews a day[25]. On the other hand, toying with the Agents setting gives me another puzzle. Over the last 90 days, the ratio of "User"[26] to "Automated"[27] views of Neatsville, Kentucky varied from 1:1 to 8:1 and more, but both peaked on 01 June 2024. Even assuming some views misidentify themselves, I can't even start to explain both the variation and the coincidence. NebY (talk) 18:26, 19 June 2024 (UTC)

My understanding (and this may be incorrect) is that including redirects merely adds the number of views to the page and the number of views to the redirect. I do not believe it is possible to have a view of the redirect that results in the viewer being redirected to the page, but does not also lead to a view to the page itself, such that pageviews alone should always be higher than redirect views alone (compare pageviews of "FBI" versus "Federal Bureau of Investigation"). BD2412 T 19:09, 19 June 2024 (UTC)

Ah, that it's simple addition does make sense. Still, the FAQ does say If a user browses to a redirect, a pageview is registered for the redirect but not for the target page. That suggests to me that it's technically feasible that ~20,000 human readers went to Neatsville, Kentucky, were redirected, and did read Neatsville, Adair County, Kentucky - but I've little experience of this tool, could be very wrong. NebY (talk) 19:42, 19 June 2024 (UTC)

I have yet to find a working redirect that has more pageviews than the page to which it redirects. BD2412 T 04:12, 20 June 2024 (UTC)

How to make B heads smaller than A heads?

I've just noticed that A heads (i.e. headings made by pairs of double equals signs ==) are in a much smaller unbold roman point size than sans-serifed bold B heads (i.e. headings made by pairs of three equals signs ===), which looks ridiculous. I'm sure this never used to be the case in the near 20 years I've been editing here. Is there any way of viewing pages so that A heads appear bigger and bolder than B heads? Thanks, Ericoides (talk) 10:15, 12 June 2024 (UTC)

much smaller. h2's look bigger than h3's on my skin vector (2010). Example. What skin are you using? –Novem Linguae (talk) 10:39, 12 June 2024 (UTC)

Cheers. I'm not sure. How can I tell? Ericoides (talk) 12:16, 12 June 2024 (UTC)

@Ericoides You have some custom CSS at User:Ericoides/vector.css which is overriding the default styles. Note that there have been some recent changes to heading HTML structure which might affect how that CSS behaves. the wub "?!" 11:15, 12 June 2024 (UTC)

Thanks. Is there a simple fix so I can revert to the default? Ericoides (talk) 12:18, 12 June 2024 (UTC)

Just edit the page User:Ericoides/vector.css, delete all the content, and save it as a blank page. — xaosflux ^Talk 13:20, 12 June 2024 (UTC)

Ah, OK, thanks for the tip. Ericoides (talk) 15:29, 12 June 2024 (UTC)

ETA, I've done as advised and it's all back to normal. Good stuff. Ericoides (talk) 17:44, 12 June 2024 (UTC)

Resolved

–Novem Linguae (talk) 00:04, 13 June 2024 (UTC)

Hatnote styling?

Did the hatnote stylesheet change? It seems to have become harder to read and a different font color in the last few days. -- 64.229.90.32 (talk) 06:40, 14 June 2024 (UTC)

See discussion at Wikipedia:Village pump (technical)#Hatnotes have Minerva-style background color? PamD 07:09, 14 June 2024 (UTC)

Kurds and the rule of crowd

Moved to Wikipedia:Administrators' noticeboard/Incidents § Discussion of the block

— Preceding unsigned comment added by Novem Linguae (talk • contribs) 15:00, 14 June 2024 (UTC)

Wikipedia in Fiction

Nature magazine has been running a series of Science Fiction short stories called "Futures". The latest one -- "Plastic-eating fungus caused doomsday:[2][3] A collaborative effort" -- is told as a series of entries to a Wikipedia talk page. Never thought of Wikipedia as a genre. AFAIK, this is the first Wikipedia fiction -- not counting hoax articles, of course.

I don't know how long this link will be good, so I downloaded a pdf copy of this story in case it goes away. -- llywrch (talk) 02:44, 17 June 2024 (UTC)

Good find, thanks! Gråbergs Gråa Sång (talk) 07:59, 17 June 2024 (UTC)

@Llywrch see lena by qntm Mach61 23:20, 17 June 2024 (UTC)

I have to do this:

References

Gråbergs Gråa Sång (talk) 08:11, 17 June 2024 (UTC)

AFAIK, this is the first Wikipedia fiction Nope! Pre-dated by works like Neurocracy (2021), Missing Links and Secret Histories (2013), and I'm sure there's many more examples. – Teratix ₵ 10:02, 17 June 2024 (UTC)

@Gråbergs Gråa Sång, Llywrch, and Teratix: I have redirected Wikipedia in fiction to Wikipedia in culture. If the use of the above mentioned works is discussed in sources, it would be worth adding mention of them to that article. BD2412 T 19:49, 17 June 2024 (UTC)

I'm surprised that I missed Missing Links and Secret Histories, since I've read every issue of the Signpost since its creation years ago. But my oldest daughter was 6 at the time & having children that young limits every activity outside of work, eating & sleeping -- & sometimes the last two are also affected. -- llywrch (talk) 06:57, 18 June 2024 (UTC)

If there's any doubt that we need more sysops...

...I've made a graph comparing stats across English projects. Active users per admin is in blue. Cremastra (talk) 20:21, 18 June 2024 (UTC)

A better comparison would be the other major Wikipedia's (German, French, Japanese, etc). BilledMammal (talk) 20:27, 18 June 2024 (UTC)

Given that its users/admin, as opposed to straight-out number of admins, I'm not sure I see much of a difference. Cremastra (talk) 20:29, 18 June 2024 (UTC)

I think there are a lot of different variables to account for when comparing non-Wikipedia projects to Wikipedia projects that makes a direct comparison tricky. Ultimately, though, English Wikipedia has a lot of editors paying attention to it, and so out of necessity its community has tried to develop processes to handle large numbers of edits. (As I've stated previously, I do think that more administrators are needed in order to feed the pipeline of experienced users.) isaacl (talk) 02:12, 19 June 2024 (UTC)

That doesn't demonstrate anything much. It could just as easily be used to argue that (a) other projects need more sysops per user, or (b) other projects don't need more sysops per user, they just make it available to more people as a proportion. AndyTheGrump (talk) 20:46, 18 June 2024 (UTC)

Indeed. It might also indicate that we have well-developed dispute resolution systems, effective patrolling by non-admins, a strong culture of mutually advising and warning editors, and/or more efficient sysops, due in part to those other factors. NebY (talk) 21:47, 18 June 2024 (UTC)

Why is users-per-sysop a valuable metric? Admins are not responsible for users in the same way a schoolteacher or prison guard is responsible for their charges. What you should be measuring is perhaps troubled users (vandals, etc) and required admin tasks (page protection, blocks) per admin. If you have 1 million users who behave and 3 admins, who cares? RudolfRed (talk) 01:31, 19 June 2024 (UTC)

More users, in general = more admin tasks. Cremastra (talk) 01:33, 19 June 2024 (UTC)

It would be interesting to compare the average admin workload (i.e. number of logged actions per admin) on different projects. RoySmith (talk) 02:10, 19 June 2024 (UTC)

Help for article creation

I want to create article about Genetic studies on Bengali. I created many historical, political or other simple articles so I know how to find sources for these topics. But I am clueless about source indexing of genetic studies in search engines and I am having difficulties finding sources about genetic studies of Bengali people. Do you people have any idea how to find genetics-related sources effectively? Or can anyone redirect me to anyone who can really help me about the sources? Mehedi Abedin (talk) 04:33, 19 June 2024 (UTC)

Mehedi Abedin, you might have better luck asking at WP:RD/S. The people there will likely know how to find research materials about genetic studies. Folly Mox (talk) 05:37, 19 June 2024 (UTC)

Is this a Wikipedia error now appearing as an RS?

Until this edit[28], Austronesian peoples stated that Madagascar was reached by Austronesians c. 50–500 CE ("In the Indian Ocean, they sailed west from Maritime Southeast Asia; the Austronesian peoples reached Madagascar by ca. 50–500 CE"). Looking at that version[29], there are three references with failed verification tags. The last two references have been associated with this part of the article for some time. Precisely what is wrong with the references is discussed on the talk page[30] (It's the third of three issues under this heading.) Note these last two references, The Culture History of Madagascar and A chronology for late prehistoric Madagascar.

In a recent version[31] of the article, we have two reintroductions of early dates for Austronesian settlement of Madagascar. The one that says Estimates for when this occurred vary from the 1st century CE,[153]... has a new ref, Herrera et al. If you read that paper, you find, in the introduction:

• "[Austronesians] ...colonized Madagascar during ca AD 50–500 [1,2]."

Checkout those references – they are The Culture History of Madagascar and A chronology for late prehistoric Madagascar. Since neither of them support this date range, where did the authors of the paper get this from? There are plenty of other potential references in the literature (giving later dates). So why use these? The most likely explanation is that they were lifted straight from the Wikipedia article that existed at the time.

So, do we have a Wikipedia error (since corrected) now being recycled back into the article to perpetuate the error? What do you think? ThoughtIdRetired _TIR 22:42, 19 June 2024 (UTC)

Link: Herrera et al. 2017.

It does look like citeogenesis. As far as I can tell the A chronology for late prehistoric Madagascar source is unrelated to the statement made. CMD (talk) 04:43, 20 June 2024 (UTC)

Wikipedia on visionOS

I neither have nor can afford an Apple Vision Pro at this time, and I don't think most of us do or can as well. I'd like to know, from those using the device, how Wikipedia on Safari functions as well as the Wikipedia mobile app there. George Ho (talk) 21:33, 20 June 2024 (UTC)

@SGrabarczuk (WMF), is this something that the Web team has tested? WhatamIdoing (talk) 22:46, 20 June 2024 (UTC)

Hey everyone, thanks for the ping @WhatamIdoing.

Not yet! Compared to our total traffic, few people use this device. We had a talk about it soon after it was launched, but I guess we're still far from the decision to buy one. SGrabarczuk (WMF) (talk) 00:37, 22 June 2024 (UTC)

They should make the interface shaped like a puppy and rotating on a few axes. Like three. ꧁Zanahary꧂ 07:42, 21 June 2024 (UTC)

Getting a list/count of values of a parameter.

(not real example). Template Infobox Guinea Pig has a parameter called "Tail color". I'd like to be able to see what values this parameter has over all articles that use the infobox. (I asked on the help desk and got no response)Naraht (talk) 21:46, 20 June 2024 (UTC)

I think the data only flows in one direction. You can double check at WP:VPT if you want. That's probably the best board for this question. –Novem Linguae (talk) 22:05, 20 June 2024 (UTC)