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.

Click here to purge the server cache of this page (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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
But that was not the situation being discussed, it was word for word, copying the work. Alanscottwalker (talk) 15:48, 12 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
Yes, copying a poem likely warrants inline attribution, so... it depends on the situation. isaacl (talk) 16:24, 12 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
As plagiarism and copyright are two different, if sometimes related, inquiries. -- Alanscottwalker (talk) 17:08, 12 May 2024 (UTC)[reply]

>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)[reply]
Attribution is required. Inline attribution is not (that is, stating the source within the prose). isaacl (talk) 15:58, 12 May 2024 (UTC)[reply]
It still requires sourcing. Traumnovelle (talk) 16:06, 12 May 2024 (UTC)[reply]
Yes, attribution is sourcing. isaacl (talk) 16:15, 12 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]
Surely there's some reasonable position between "attribution doesn't matter" and "attribute every sentence inline". Remsense诉 09:06, 14 May 2024 (UTC)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
I propose all WP:GREATWRONGS should be righted immediately.Boynamedsue (talk) 20:06, 12 May 2024 (UTC)[reply]
WP:IAR! Alanscottwalker (talk) 20:12, 12 May 2024 (UTC)[reply]
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)[reply]

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Support not adding any more bold-face votes. Suffusion of Yellow (talk) 04:19, 13 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

"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)[reply]

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)[reply]

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.^{[public domain]}

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Hate speech

I should already know this, but I don't: where is our policy page on hateful remarks directed at groups (as opposed to individuals) – ethnic, national, religious, sexual and so on? And our guidance on how best to deal with them without attracting undue attention? I don't see that this topic is specifically covered in the Wikimedia Foundation Universal Code of Conduct. Thanks, Justlettersandnumbers (talk) 09:03, 27 May 2024 (UTC)[reply]

We have a few explanatory essays covering this like Wikipedia:Hate is disruptive. —Kusma (talk) 09:10, 27 May 2024 (UTC)[reply]

We don't accept statements like "I hate <named kind of> people". We usually do accept statements like "I hate Bob's Big Business, Inc.". WhatamIdoing (talk) 15:48, 27 May 2024 (UTC)[reply]

“Some people can’t get along with other people… and I hate people like that!” Blueboar (talk) 16:05, 27 May 2024 (UTC)[reply]

There seems to be varying interpretations of what that essay means or how we should enforce it or if if we should at all. For example, this situation:[3]. Courtesy ping to Snow Rise. I'm bringing this up because I think how that discussion was handled has broader implications that are relevant here. For the record, I do agree with that explanatory essay. Clovermoss🍀 (talk) 21:31, 28 May 2024 (UTC)[reply]

the subjective belief that transmen and trasnwomen are not "real": I will hope that Snow Rise meant to type "the false belief" that trans people aren't real. Whether sky or sapphire is the finer blue, or whether Avengers: Endgame is a good movie, are subjective beliefs. Expressing denial of the existence of a category of people—whether people of Black African descent, Jewish folks, First Nations, gay people, Catholics, or those who are transgender (to nonexhaustively give examples)—is WP:FRINGE at a minimum and more generally is better described as prejudicial and destructive to the cultivation of a civil and collegial editing environment on Wikipedia, regardless of whether the expression's phrasing is hostile or sweet, passionate or anodyne. Reducing such to "abstract belief"—when it's a belief about concrete people who exist in the world and in this community—is, however inadvertently, a language game, an alchemy of words. If it's a true and dispassionate assessment to say that the Wikipedia community generally prefers a site where participants receive no penalty for denying the existence of people groups or for opposing the extension of rights to them (including by denying they exist and therefore can be extended to)—or, perhaps, selectively receive no penalty for doing so for certain groups—then something is rotten in the state of Denmark, proverbially speaking.

Or, to answer OP's question and express myself in another way, as zzuzz points out elsewhere in this thread, the Universal Code of Conduct is unequivocal that [h]ate speech in any form, or discriminatory language aimed at vilifying, humiliating, inciting hatred against individuals or groups on the basis of who they are is unacceptable within the Wikimedia movement. I'd point out that also considered unacceptable is content that are intimidating or harmful to others outside of the context of encyclopedic, informational use: expressions on talk and user pages often exist outside of the context of encyclopedic, informational use. Hydrangeans (she/her | talk | edits) 09:47, 30 May 2024 (UTC)[reply]

You have truncated the quote; Snow Rise said the subjective belief that transmen and trasnwomen are not "real" men or women. gnu 57 11:03, 30 May 2024 (UTC)[reply]

My argument at the time was that this was sanctionable behaviour, despite what others say. You can't exactly make sweeping statements about a group without it also being a personal attack. I don't see much of a difference between going "I don't think you're a real man" and "I don't believe that anyone that's like you is a real man". Hydrangeans, I also argued at the time that this went against the Code of Conduct. My purpose in bringing this up now is that something I thought was obvious apparently is more controversial than it seems within the community. Even if I think things shouldn't be this way. Another example would be when I filed this ArbCom case against someone that argued some people were subhuman. I think it if it was a regular editor, they would've been indeffed and not just desysopped. Clovermoss🍀 (talk) 13:46, 30 May 2024 (UTC)[reply]

Also, in the interest of fairness, this diff was part of a wider discussion that took place here and here. Clovermoss🍀 (talk) 13:55, 30 May 2024 (UTC)[reply]

truncated the quote: The whole quote amounts to altogether the same thing. To hold that, for example, transgender men are not "'real' men", is to hold that transgender men are not real—as they are women. Etc. Hydrangeans (she/her | talk | edits) 16:52, 30 May 2024 (UTC)[reply]

I would presume this would be covered under general guidance regarding disruptive editing or using WP as a forum. I have no love for the Kardashians, but I don't make it a point to go to relevant articles and voice my opinion. If it isn't disruptive but merely objectionable, then that gets into slippery NOTCENSORED territory very quickly, because what is objectionable but not disruptive is very much in the eye of the beholder. GMG ^talk 16:21, 27 May 2024 (UTC)[reply]
WP:CIVIL, while focused on individual interactions can be extended to group incivility. Blueboar (talk) 16:32, 27 May 2024 (UTC)[reply]
WP:HA does deal in passing at least with conduct even if the target is not an editor. And you are correct that something like CIVIL can be broadly construed in the sense that if someone says "I hate gypsies" then it can be reasonably assumed that some of our community are Roma and so it discourages collaboration. But it's difficult to tell what the real angle here is without more specifics. For example, many, including myself, may consider parts of the Bible as hateful, although that at some level has to be balanced with historical significance and the fact that hateful views are in-and-of-themselves a topic we cover extensively. Not being doomed to repeat history and all that. Others surely would consider what I just said as a form hatefulness against a religious group for their sincerely held beliefs.

But as I indicated before, there is always going to be a nuanced judgement about the dividing line between what is hateful and what is merely offensive. GMG ^talk 21:17, 27 May 2024 (UTC)[reply]
"The following behaviours are considered unacceptable within the Wikimedia movement ... Hate speech in any form, or discriminatory language aimed at vilifying, humiliating, inciting hatred against individuals or groups on the basis of who they are or their personal beliefs ..." --UCOC. -- zzuuzz ^(talk) 21:35, 27 May 2024 (UTC)[reply]
Thanks to zzuuzz and all others who replied. It was that line in the You-cock that I was looking for. So do we in fact have no local policy specific to this? Someone asked about context: a couple of days ago a note was left on my talk asking me to revdelete a fairly unpleasant remark; I'd already gone to bed and the matter was quickly dealt with, but I was left wondering the next day how we should best handle these (fortunately rare) occurrences. I'm not talking about incivility but stuff like "[your choice of ethnicity/sexuality/caste/religion/etc here] should be put up against a wall and shot" or whatever other nastiness unpleasant minds may dream up. I looked for our policy page and didn't find it. Should there in fact be such a page? Justlettersandnumbers (talk) 21:46, 28 May 2024 (UTC)[reply]
I'd say those types of situations are covered under WP:NOTHERE. Clovermoss🍀 (talk) 21:51, 28 May 2024 (UTC)[reply]

My go-to would be the blocking policy, which has this covered (even if not explicitly). The revdel policy also allows deletion (mostly RD2). Is there anything else to do? Hate speech is just a subset of disruption, and we have wide latitude to throw it in the trash, because trash goes in the trash. -- zzuuzz ^(talk) 21:56, 28 May 2024 (UTC)[reply]
In some cases oversight is also a possible action, but revision deletion is going to be more common. Especially when the target of the comment is a specific person, WP:NPA also allows for the removal of the comment. Thryduulf (talk) 07:53, 29 May 2024 (UTC)[reply]

The policy is that you are required to be civil and not attack other users. I don't think there is any civil way for a person to express the opinion of, e.g. "I love being racist and I hate black people". At any rate, the de facto policy is that somebody will block for this kind of garbage regardless. jp×g 🗯️ 07:04, 30 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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. Silver seren^C 03:08, 28 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
I think I've seen that happen. Gråbergs Gråa Sång (talk) 07:41, 28 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

I didn't say what you claim I "seem" to have said. Try AGF yourself. Peter Gulutzan (talk) 17:17, 28 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Agreed. AlexandraAVX (talk) 17:07, 28 May 2024 (UTC)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
Please read more carefully: the contention I'm trying to argue against here Loki (talk) 15:36, 30 May 2024 (UTC)[reply]
My apologies. Thryduulf (talk) 18:40, 30 May 2024 (UTC)[reply]
No problem! Loki (talk) 19:31, 30 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

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
Discussion	Group	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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

Fair use of non-free content

What is the process of using non-free images are? Currently, the Lockheed YF-22 and Northrop YF-23 makes use of non-free images in thumbnail form (with original source attributed in their Wikimedia pages) to help illustrate their design histories. I've seen articles use them (typically cinema articles) and typically they're downscaled thumbnails without any higher resolution, but I'm not familiar with the process for using them. If that's not possible then a lot of images in those articles will have to be removed until I can get express permission from Lockheed/Northrop or if they're uploaded on something like DVIDS. Steve7c8 (talk) 14:49, 29 May 2024 (UTC)[reply]

Non-free content is used in accordance with the Wikipedia:Non-free content criteria and Wikipedia:Non-free content provides and introduction and explanation. However, all there don't appear to be any non-free images at either Lockheed YF-22 or Northrop YF-23, indeed the images in the sections about the design are all either public domain or CC0. If you believe the licenses on those images are incorrect then you would need to nominate them for deletion at Commons (with evidence). Thryduulf (talk) 15:32, 29 May 2024 (UTC)[reply]

I was the one who uploaded a lot of those images, but I may have incorrectly applied CC0 to many of them, although I deliberately uploaded them as low-resolution thumbnails because I don't think they're free content. They've been nominated for deletion, so I'm wondering how to justify them as fair use of non-free images, at least until I can get express permission from Lockheed Martin and Northrop Grumman for their use, in which case I can upload the full resolution version. Steve7c8 (talk) 15:58, 29 May 2024 (UTC)[reply]

The immediate issue you're running into is that you uploaded all of those to Wikimedia Commons, a related but separate project that's exclusively for freely usable media. If the images are non-free, they need to be deleted from Commons. Non-free files can be uploaded to English Wikipedia if they meet the criteria Thryduulf linked to. The important boxes to check are including an appropriate copyright tag and a rationale explaining how the image meets the criteria. For a topic that probably has a lot of {{PD-USGov}} works available, I'd be surprised if any non-free images managed to meet both WP:NFCC#1 and WP:NFCC#8. hinnk (talk) 09:06, 1 June 2024 (UTC)[reply]

"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:

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.
Must have severe deficiencies in citation or bias
No substantial edits in six months.
Has had at least one nomination for deletion a minimum of six months ago.
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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
Funny that the only citations in "Naked butler" are in the "Popular culture" section. Donald Albury 14:18, 31 May 2024 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

No. And your useless tangent is not adding anything here. Thanks word police. Alanscottwalker (talk) 18:47, 31 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

Just look, see how you are derailing anything having to do with anything with the proposal. Alanscottwalker (talk) 19:17, 31 May 2024 (UTC)[reply]

I refuse to waste more of my time on your continued ad hominems. Thryduulf (talk) 19:27, 31 May 2024 (UTC)[reply]

Looking at your comments is not ''ad hominem.'' Alanscottwalker (talk) 19:28, 31 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]
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[4], 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)[reply]
What if Nupedia, but without the experts? I think [5] from that same thread presents far more useful ground for reflection. Choess (talk) 01:59, 1 June 2024 (UTC)[reply]
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)[reply]

Read:

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

On the contrary, almost all main page FAs are about America! Johnbod (talk) 22:05, 2 June 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

Technical

Tech News: 2024-21

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

The Nuke feature, which enables administrators to mass delete pages, will now correctly delete pages which were moved to another title. [6]
New changes have been made to the UploadWizard in Wikimedia Commons: the overall layout has been improved, by following new styling and spacing for the form and its fields; the headers and helper text for each of the fields was changed; the Caption field is now a required field, and there is an option for users to copy their caption into the media description. [7][8]

Changes later this week

The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 May. It will be on non-Wikipedia wikis and some Wikipedias from 22 May. It will be on all wikis from 23 May (calendar). [9][10]
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.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

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

Something weird happened. I received a notification for this edit by ClueBot III archiving the section "Tech News: 2024-21". The notification is for a section on a talk page, which I've never edited (and don't think I ever interacted with user Cocobb8 before). I had no need to subscribe to that section. I did, however, subscribe to the section with the same name #Tech News: 2024-21 on the Village pump, because I participated in related section #Heading markup changes just below.

If I go to User talk:Cocobb8/Archives/2024/June#Tech News: 2024-21, I see an "Unsubscribe" button. —⁠andrybak (talk) 11:19, 8 June 2024 (UTC)[reply]

Wait a second. I also see an "Unsubscribe" button at Wikipedia:Tech news#Tech News: 2024-21. It's this just a quirk of the subscription system?

But I don't see it at User talk:Xaosflux#Tech News: 2024-21 and User talk:DannyS712#Tech News: 2024-21, which were delivered at 23:02, a minute later. Which would suggest that some key is constructed from section name and the timestamp. —⁠andrybak (talk) 11:31, 8 June 2024 (UTC)[reply]

Confirmed per Wikipedia talk:Talk pages project/Archive 4#Site-wide thread subscription?, quote: not based on a title match, but on the author and time of the initial message. —⁠andrybak (talk) 11:51, 8 June 2024 (UTC)[reply]

I guess this is one of the reasons for deliberately separating #Heading markup changes into separate ==level 2== section, even though it is related to the topic of #Tech News: 2024-21. See Special:Diff/1227646231, Special:Diff/1227682725, and Special:Diff/1227745219. —⁠andrybak (talk) 11:57, 8 June 2024 (UTC)[reply]

DiscussionTools tracks subscriptions using the first poster's name and timestamp. This lets the heading name be changed easily without messing up everyone's subscriptions. In this case keeping both subscriptions seems ideal. –Novem Linguae (talk) 13:07, 8 June 2024 (UTC)[reply]

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)[reply]

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:

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

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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

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

And a couple other gadgets still remaining:

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

Σ'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)[reply]

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

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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

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)[reply]

✅ 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

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)[reply]

@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: [11] – please try now. Matma Rex talk 20:27, 6 June 2024 (UTC)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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

The obsolete nowrap attribute

See this edit and User talk:Awesometd#nowrap. The nowrap attribute on a td element, already deprecated in HTML 4 (December 1997), was marked as obsolete in HTML 5 (October 2014). The user says that they are copying its use from other pages, so does anybody know where in Wikipedia such usage is recommended or even suggested? --Redrose64 🌹 (talk) 10:30, 28 May 2024 (UTC)[reply]

I doubt it's suggested anywhere. A few cases may have been added long ago and some users just copy what they saw in other articles. The user is right that it's used in 2024 F1 season. Unsurprisingly it's also in previous seasons. It's common to start such pages with a copy-paste from another season. PrimeHunter (talk) 11:16, 28 May 2024 (UTC)[reply]

At a first estimation there are about 10k uses of it; I'm sure someone can refine that. Izno (talk) 15:26, 28 May 2024 (UTC)[reply]

There's many more obsolete attributes still being used in tables, such as align or bgcolor. If we truly want to get rid of them, the solution would probably be to extend the Linter extension, so that they'll be listed at Special:LintErrors. That's probably a discussion to be had over at WT:LINT. --rchard2scout (talk) 07:56, 29 May 2024 (UTC)[reply]

One could easily ask as well where in Wikipedia such usage is deprecated or discouraged? I'm pretty sure the amount of editors that read the HTML5 instructions prior to editing articles is rather low. You can't just assume that everyone is always aware of what parameters have become obsolete.

I am a regular editor of the Formula 1 Wikiproject and I remember us starting to use that parameter because it is more practical and intuïtive than the nowrap template and takes up less memory. The fact that it never produced any technical issue, nor was there any message that it is obsolete. This is litterally the first time anyone give an indication there is a problem. Why isn't this advertised more to the relevant WikiProjects? Like another person pointed out here, if these things would be flagged as LintErrors they would not be used. But I do wonder why such a simple, well working parameter was made obsolete.

We are well-intentioned people, so I'm sure that if you invite a couple of editors from the relevant WikiProjects, explain the issue and tell us what the correct CSS code is, per the HTML5 documentatien's recommendation, we'll set out to deal with those obsolete parameters. As a side note, I think the Superbike article has even more issues, like the usage of external links.T v x1 21:53, 3 June 2024 (UTC)[reply]

This one is actually pretty easy to switch, we have a CSS class nowrap that you can change whatever templates to use instead. Izno (talk) 23:31, 3 June 2024 (UTC)[reply]

And what is that CSS class nowrap? T v x1 10:26, 4 June 2024 (UTC)[reply]

The CSS rule is

.nowrap,
.nowraplinks a {
  white-space: nowrap;
}

and it's already set up for you. You use it in a table as e.g.

{| class="wikitable sortable"
|+ Demo table
|-
|class="nowrap" | Row 1 Column 1 || Row 1 Column 2
|}

This applies the class to one specific cell. It can also be applied to a whole row at once; or to the entire table. Doing those isn't such a good idea, you may cause excessive sideways scrolling. --Redrose64 🌹 (talk) 13:55, 4 June 2024 (UTC)[reply]

What about style="white-space:nowrap"? T v x1 23:17, 4 June 2024 (UTC)[reply]

Yes, it does the same thing, but (i) it's more to type; (ii) less easily remembered; (iii) more easily broken e.g. by omitting or mistyping that hyphen; (iv) more difficult to apply cascading styles to. In general, class= is preferred over style=.

As for "why such a simple, well working parameter was made obsolete", it's part of the overall plan for HTML, going right back to the mid-1990s, that HTML should concern itself only with semantics, and leave styling to style sheets. Accordingly attributes that have no semantic meaning and affect only the style - other than style= itself, were first deprecated and then made obsolete; similarly with elements like <font>...</font> that affect only the style and have no semantic meaning. --Redrose64 🌹 (talk) 05:46, 5 June 2024 (UTC)[reply]

New Gadget for viewing CT images

We at Wiki Project Med have built a gadget to view stacks of images such a as CT scans, which you can see here[12]. We are wanting to install it on EN WP.

Previously mentioned to User:MusikAnimal here who want to verify community consensus first.

We have an earlier version working on Commons[13]. Based on Template:PD-medical we have collected a few thousand complete CT and MRI scans of various conditions. Doc James (talk · contribs · email) 19:13, 29 May 2024 (UTC)[reply]

@Doc James about how many pages would this need to run on? We are currently experimenting with our very first implementation of Template Gadgets (see a couple sections up) right now, which I imagine would be the way we would want to implement this (and most certainly not by hooking a full page text analyzer in to common.js). — xaosflux ^Talk 18:49, 30 May 2024 (UTC)[reply]

A template gadget version has been copied to mediawiki.org as a demo. See mw:Template:ImageStackPopup Bawolff (talk) 19:00, 30 May 2024 (UTC)[reply]

So User:Xaosflux sounds like it only loads when a specific category is present already. Doc James (talk · contribs · email) 19:21, 30 May 2024 (UTC)[reply]

@Doc James yes, where said category would come along with a template that would wrap whatever is being used. It sounds like all instances of this would use some template so that part isn't hard. What order of magnitude of pages would you expect this would get used on? — xaosflux ^Talk 19:23, 30 May 2024 (UTC)[reply]

User:Xaosflux few thousand at most, Doc James (talk · contribs · email) 19:44, 30 May 2024 (UTC)[reply]

Thanks for the note. — xaosflux ^Talk 19:24, 30 May 2024 (UTC)[reply]

The mediawiki version is quite a bit better.

For a default gadget, i'd have some concerns about the accessibility of the play button. It's not a button, and it's also not labeled.
Similar for the pager and slider in the window. This is unlabeled. It should have accessibility labels to make it possible to understand what the slider does.
The play button positioning and sizing might need a little bit more work, it seems kinda off (esp on iphone)
Might want to hide the play button on media print
Good to see that media credits are being linked.
Seems to work on mobile, but could use some additional spacing at the top controls, they are really difficult to hit because everything is so close together now.
Closing the dialog. All MW dialogs currently have close at the top (an old pattern i note due to mobile usage favoring thumb interaction at the bottom of a dialog). This does create an inconsistency, but i'm not particular concerned.
The whole ImageStackPopup-viewer is inside a label element atm. I think that's an accident?

—TheDJ (talk • contribs) 20:27, 30 May 2024 (UTC)[reply]

User:TheDJ We have added labels. Let me know if what was done is sufficient? Doc James (talk · contribs · email) 13:06, 1 June 2024 (UTC)[reply]

Perhaps we can use gitlab instead of mediawikiwiki for development? It can probably serve as the version which wikis copy from. I created a blank project at gitlab:repos/gadgets/ImageStackPopup, and can extend SDZeroBot 13 to support tracking updates from gitlab. – SD0001 (talk) 09:14, 31 May 2024 (UTC)[reply]

There's been some accessibility improvements in the latest version. Button is also now hidden on print. The label thing and the close button at the bottom seem to be due to using OO.ui.alert. I'm not sure why OOUI does it that way for alert boxes. Bawolff (talk) 13:18, 31 May 2024 (UTC)[reply]

Synced local fork from upstream. — xaosflux ^Talk 13:57, 31 May 2024 (UTC)[reply]

@Doc James, As one of our professors often says, "One view is no view in Radiology." From a content perspective, I am confident that these imaging stacks will enhance the quality of our radiology related articles. Looking forward to seeing this implemented soon. _signed,511KeV ^(talk) 19:03, 30 May 2024 (UTC)[reply]

Moral support for the idea, bug-report for the implementation: the stack is scrolled by a left–right slider, but when hovering over the image the stack scrolls when I move the mouse up-and-down and not side-to-side. DMacks (talk) 19:49, 30 May 2024 (UTC)[reply]

Given the bird's-eye view with the line indicating the location of the specific scan is an up-and-down position, having the slider be side-to-side is confusing. Everything needs to be in sync. DMacks (talk) 00:09, 31 May 2024 (UTC)[reply]

I've forked ImageStackPopup over for anyone that wants to test it out in sandboxes etc, you can either manually opt-in to it in the "testing and development" gadget section, or you can load it to a page with the ?withgadget query parameter. From discussion above, this seems like it will need some extensive testing and tweaking. Nothing should currently be placed in to an article that is dependent on this right now, as readers will not be able to make use of it yet. — xaosflux ^Talk 23:55, 30 May 2024 (UTC)[reply]
The Vivarium template gadget being currently tested is much simpler, and we will make sure our roll out of template gadgets is done carefully. Additional discussion around if these should be able to be opted out of should also occur (i.e. not making them default+hidden). For a default here, we'll likely also use a fork, we have a bot to monitor remote changes and flag for promotion that can be used. — xaosflux ^Talk 23:58, 30 May 2024 (UTC)[reply]

The test version on Commons loads 250 images. Given how heavy these images are, this seems like a bad use case for a gadget and should potentially be in some sort of video instead, which won't try to download that many images all at the same time. Izno (talk) 00:24, 31 May 2024 (UTC)[reply]

That does seem like a lot if its all hitting the browser right away. Something that heavy sounds like it would be better to paginate and be done in mediaviewer perhaps. — xaosflux ^Talk 00:28, 31 May 2024 (UTC)[reply]

To clarify, the images get downloaded only after the user hits the play button, so only users who want to see them do the download. Perhaps that could be improved with a progress loading bar or something or the ability to cancel. The goal is to allow users to directly compare all the images all at once, so i'm not sure pagnation would work here. I agree that as a long term solution, transfering as a video with p-frames/temporal compression would probably be much more bandwidth efficient. Bawolff (talk) 05:43, 31 May 2024 (UTC)[reply]

Also, just to be clear, this gadget does not exist on commons. There is a separate gadget on commons called ImageStack, which is the inspiration for this gadget, but its a totally different gadget. Bawolff (talk) 09:46, 31 May 2024 (UTC)[reply]

Perfect. Got it working here on EN WP User:Doc_James#CT_scan_viewer. Agree a bit of fine tuning is still required.

I like the idea of a progress loading bar. As User:DMacks suggests lets move the scroll bar to the right of the image. We will need a naming convention for these pages User:Doc James/Appendicitis CT Doc James (talk · contribs · email) 15:43, 31 May 2024 (UTC)[reply]

this link can be used to manually enable to gadget once for others that want to see this without doing the opt-in. — xaosflux ^Talk 18:13, 31 May 2024 (UTC)[reply]

Next steps

We have implemented a bunch of the suggestions made above, see this link. Any further comments or can we have this go live and start using these in main space? Doc James (talk · contribs · email) 18:38, 1 June 2024 (UTC)[reply]

Ping User:TheDJ and User:DMacks Doc James (talk · contribs · email) 18:39, 1 June 2024 (UTC)[reply]

Looking very nice, but I still think it needs a bit more work for mobile. I'd still say that my fingers are not 3mm x 3mm. Additionally the right positioning of the controls now gets into the scroll zone, which is possibly even worse. I can trigger the rubber banding of the scroll area, and if I zoom in, we overlap with the scrollbar of the viewport. If you switch to desktop skin on mobile, you have the same, but zoomed out 6 times so you really do need that zooming and scrollbar. —TheDJ (talk • contribs) 22:33, 1 June 2024 (UTC)[reply]

How about we use swipe right / left on mobile to move through images? Doc James (talk · contribs · email) 05:22, 2 June 2024 (UTC)[reply]

My concerns about consistency in direction of scrolling are resolved. For the record, I'm using a desktop machine. DMacks (talk) 05:32, 2 June 2024 (UTC)[reply]

User:TheDJ We have done a bunch of work on the mobile interface. Let me know if you have further concerns. Doc James (talk · contribs · email) 04:36, 6 June 2024 (UTC)[reply]

This search has timed out. You may wish to try different search parameters.

I'm getting this error pretty frequently lately when opening my watchlist. Maybe a third of the time over the past several days. Anyone know what this is? — Rhododendrites ^talk \\ 01:32, 1 June 2024 (UTC)[reply]

Reset your filters, so the page has to do fewer calculations ? Your watchlist is probably really large, I assume. —TheDJ (talk • contribs) 10:22, 1 June 2024 (UTC)[reply]

@Rhododendrites: It could be several different things, or more likely, a combination of these.

A large number of pages are listed at Special:EditWatchlist/raw
A significant proportion of pages listed at Special:EditWatchlist/raw have been edited recently
Some of the pages listed at Special:EditWatchlist/raw have recieved large numbers of edits recently

Things to try:

Go through Special:EditWatchlist/raw and remove pages that you're no longer interested in
If you are watching a high-traffic page (like WP:ANI), unwatch it
At Watchlist options, try
- reducing the period of time to display
- applying some of the "Hide" options
- selecting one namespace (possibly with its Associated namespace enabled) rather than all

HTH. --Redrose64 🌹 (talk) 10:41, 1 June 2024 (UTC)[reply]

Thanks. I do have a very large watchlist (17k pages), but this issue started happening all of a sudden a few days ago and the list has barely changed in recent weeks. I don't think I've ever once seen the error before then. It's also inconsistent. If I just refresh a few times, it'll display. — Rhododendrites ^talk \\ 13:44, 1 June 2024 (UTC)[reply]

But the software and servers change all the time. If you are up to those numbers, even half percent of change in performance on that side can easily push you over an edge. —TheDJ (talk • contribs) 14:07, 1 June 2024 (UTC)[reply]

@Rhododendrites You can try User:Ahecht/Scripts/watchlistcleaner to clean out unneeded or stale pages from your watchlist, but with 17k pages you may have to let it run overnight. I've only tested it on about half that many pages. --Ahecht (TALK
PAGE) 01:53, 3 June 2024 (UTC)[reply]

Thanks. Frankly, though, I don't want to change my watchlist. It's huge, yeah, and includes a ton of e.g. deleted pages, but I like being able to see when something is recreated or when someone edits a page from way-back-when that probably shouldn't be edited anymore. Edits to inactive pages sneak through too easily sometimes. I'm just kind of surprised that I've had a massive watchlist for years (I became an active editor playing with counter-vandalism tools and AWB, so built up a huge watchlist early) and it's never caused a problem. Of all the things that use memory on Wikipedia, it's volunteers' watchlists that need to be limited? — Rhododendrites ^talk \\ 14:29, 3 June 2024 (UTC)[reply]

Almost everything is limited. It’s just that most people don't know about that because they hardly ever run into those limits. —TheDJ (talk • contribs) 17:23, 3 June 2024 (UTC)[reply]

It's more common on other projects (where RC tables are larger as well though), but I don't think 17K pages should be close to where these problems would start to occur (at least when you only select to display 50 or 100 pages, maybe). 1234qwer 1234qwer 4 18:19, 7 June 2024 (UTC)[reply]

The likelihood of a timeout can vary depending on how much load the servers are under. More load, more likelihood of a timeout. Watchlists are actually the single most database intensive feature on Wikipedia, probably by a fairly wide margin. On smaller wikis, adjusting the time period to search can help a lot but on a wiki the size of Wikipedia not so much. (Essentially there are two methods of calculating the watchlist depending on if the number of changes in the time period being search is smaller or larger than the amount of entries in your watchlist. On Wikipedia you'd probably have to set that super low before it made a difference because so many edits are happening all the time). Most of the other filters (including total number of results to show) don't make much of a difference most of the time, although there might be edge cases where they matter. Bawolff (talk) 00:04, 4 June 2024 (UTC)[reply]

Thanks for this background. Did not know they were the most database intensive feature, but I guess that makes sense. So I take this to mean the only way to fix it is to remove pages from the list? — Rhododendrites ^talk \\ 00:07, 4 June 2024 (UTC)[reply]

Rhododendrites, you could remove some pages from your watchlist and put links to those pages somewhere in your userspace, then use Special:RecentChangesLinked on that page as a kind of pseudo-watchlist. That'd allow you to split your watchlist into smaller chunks for the servers to process, at the cost of part of your watchlist becoming public. Rummskartoffel 16:28, 6 June 2024 (UTC)[reply]

I get this off-and-on, started about a week ago. No particular time of day afaict. My watchlist has been in the 25-26k range for ages, so it's not down to any change on my part. DuncanHill (talk) 16:47, 6 June 2024 (UTC)[reply]

Detecting transclusion through a redirect

In Wikipedia:Templates for discussion/Log/2024 May 22#Template:Edit semi-protected a reason some editors, including myself, are opposed to merging is that the merged template will no longer be able to work properly if used on an unprotected page (which can happen in the case of an unprotected WP:ARBECR page, for example). SilverLocust put it like this: If these were all redirected to one template, then there would be a loss of functionality unless someone knows how to tell a module not merely which wrapper is invoking a module (since there would only be one merged wrapper), but rather which redirect is being used to transclude the wrapper that invokes the module (and I don't think that is possible). So, is that right? Or is there a way to detect which redirect is used and merge the templates without any loss of functionality? Nickps (talk) 14:07, 2 June 2024 (UTC)[reply]

@Nickps The module could use getContent() to get the text of the current page and then search it for one of the redirect templates. --Ahecht (TALK
PAGE) 02:30, 3 June 2024 (UTC)[reply]

I would oppose that as confusing and probably inefficient. Editors expect it to make no difference whether a redirect is used. If we really want a certain "redirect" to behave differently then don't make it a redirect but a wrapper which passes a certain parameter. PrimeHunter (talk) 02:47, 3 June 2024 (UTC)[reply]

Yes, and that's exactly what has been done (but is proposed to be undone by merging the templates). Certes (talk) 13:56, 3 June 2024 (UTC)[reply]

@Certes It's no less efficient than what every single citation template is currently doing (using getContent() to get the text of the current page and then searching the text for date format templates). --Ahecht (TALK
PAGE) 16:59, 6 June 2024 (UTC)[reply]

update Credits

Who is responsible for running the maintenance script updateCredits.php, and how often is it run? wbm1058 (talk) 15:41, 3 June 2024 (UTC)[reply]

Generally it is run once per major MediaWiki release by those making the release. So every 6 months or so. —TheDJ (talk • contribs) 17:20, 3 June 2024 (UTC)[reply]

So, next up in 1.42, expected later this month. Thanks! wbm1058 (talk) 14:21, 4 June 2024 (UTC)[reply]

Tech News: 2024-23

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

It is now possible for local administrators to add new links to the bottom of the site Tools menu without JavaScript. Documentation is available. [14]
The message name for the definition of the tracking category of WikiHiero has changed from "MediaWiki:Wikhiero-usage-tracking-category" to "MediaWiki:Wikihiero-usage-tracking-category". [15]
One new wiki has been created: a Wikipedia in Kadazandusun (w:dtp:) [16]

Changes later this week

The new version of MediaWiki will be on test wikis and MediaWiki.org from 4 June. It will be on non-Wikipedia wikis and some Wikipedias from 5 June. It will be on all wikis from 6 June (calendar). [17][18]

Future changes

Next week, on wikis with the Vector 2022 skin as the default, logged-out desktop users will be able to choose between different font sizes. The default font size will also be increased for them. This is to make Wikimedia projects easier to read. Learn more.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 22:32, 3 June 2024 (UTC)[reply]

Are images transfers to WikiData working? (repost from help desk)

I use Wiki Shoot Me to take photos for Wikipedia while I’m traveling. Typically you can identify articles that need photos by looking for yellow dots indicating Wikipedia articles and larger red circles near by indicating WikiData items without photos (as previously these seemed to sync). In two cases recently I noticed articles with CC-licensed images placed correctly in the lead and appropriately sized that did not have their photos synced with WikiData: National Hotel (Q65056276) and Wet Mountain Valley (Q7989973). I know the page image is being picked up because they display correctly on Special:Nearby using their coordinates: National Hotel and Wet Mountain Valley. It looks like they’re just not making it to WikiData. - Scarpy (talk) 05:46, 4 June 2024 (UTC)[reply]

I'm not aware of any bot or tool which scrapes Wikipedia articles for suitable images to import into Wikidata. This may be an idea worth exploring, but there would be plenty of false positives. For example, on an article about an artist, if we do not have an image of the artist it is common to include a picture of one of their well known works instead. This would not be suitable for importing to Wikidata, and I can't think of a reliable way for an automatic process to detect these. Perhaps a semi-automated tool (which makes suggestions but requires manual review) is the way to go? I suggest you post at Wikidata:Project chat for a more informed response. — Martin (MSGJ · talk) 07:50, 4 June 2024 (UTC)[reply]

I found WDFIST which seems to do something like this — Martin (MSGJ · talk) 07:53, 4 June 2024 (UTC)[reply]

Thanking other users

The link for thanking other users for their edits H:THANK is currently not available on my browser based interface. Am I missing something here? ♦IanMacM♦ ^{(talk to me)} 19:51, 4 June 2024 (UTC)[reply]

Well that's bizarre, it's back again. It was definitely missing earlier today.--♦IanMacM♦ ^{(talk to me)} 20:35, 4 June 2024 (UTC)[reply]
@Ianmacm, if you're using different devices, different networks, proxies, VPNs, or any combination of these, then you might be affected by an IP range block. The "thank" links are hidden in such cases. —⁠andrybak (talk) 18:43, 5 June 2024 (UTC)[reply]

That's useful. Maybe something along these lines could be added to H:THANK, as I read through this page and could not figure out why the thank link did not show up.--♦IanMacM♦ ^{(talk to me)} 19:22, 5 June 2024 (UTC)[reply]

Cite error: Invalid ref tag; no text was provided for refs named

In Economy of South Asia there are four "Cite error: Invalid <ref> tag; no text was provided for refs named..." error messages. I found the definitions in Economy of India, and copied them to the Economy of South Asia article following the example in Help:Cite_errors/Cite_error_references_no_text#List-defined_references, but I've still got the error messages and also some new messages about ref names not being used. How do I fix it? Thanks, DuncanHill (talk) 10:28, 6 June 2024 (UTC)[reply]

Scrub it, I managed to guess the answer. I have to give the refs a different name in the definition to that used in the text. I expect someone thought that was clever, especially when combined with not mentioning it on the help page. DuncanHill (talk) 10:32, 6 June 2024 (UTC)[reply]

The problem is an undocumented feature in {{Excerpt}}. It adds the page name to ref names it's transcluding. Economy of India says <ref name="India_kapur"/> and defines it elsewhere with <ref name="India_kapur">...</ref>. That works fine in the article itself but {{Excerpt|Economy of India}} only transcludes the reuse and changes it to <ref name="Economy of India India_kapur"/>. If you manually copy the definition then you have to change name="India_kapur" to name="Economy of India India_kapur", as you found out. The purpose of the name change is to avoid a clash with an existing reference using the same name in the article calling {{Excerpt}}. VisualEditor often creates the same ref names so it can easily happen for completely unrelated references. It should certainly be documented in the template, and maybe mentioned as a possible cause in Help:Cite errors/Cite error references no text. PrimeHunter (talk) 11:58, 6 June 2024 (UTC)[reply]

Thanks. VisualEditor refnames are a menace, when people copy-paste lumps of articles they often produce clashes. Excerpt generates both undefined refname errors and harv/sfn no-target errors. I can see how adding the name can stop clashes, but it needs to be mentioned on the help page for the error messages. DuncanHill ::(talk) 12:05, 6 June 2024 (UTC)[reply]

It looks like {{Excerpt}} does try to handle the case where the ref is defined elsewhere in the page. But for some reason it's failing in that particular case. Anomie ⚔ 12:09, 6 June 2024 (UTC)[reply]

Looks like the "some reason" is that those four refs are defined inside an infobox parameter. When the reference fix-up runs the infobox is still present, so it sees no need to fix anything. Then, later, the code strips out the infobox and along with it the definitions of those four refs. Anomie ⚔ 12:30, 6 June 2024 (UTC)[reply]

Wikipedia:Help_desk#Where_did_all_the_bytes_go?

If you can, please join and explain why this edit [19] is marked in the edit-history [20] as "+10,000‎". Gråbergs Gråa Sång (talk) 13:21, 6 June 2024 (UTC)[reply]

Gråbergs Gråa Sång, the user appears to have added a very large number of invisible Unicode characters. Specifically it's the Combining Grapheme Joiner character hundreds of times.
Credit to the user script w:de:Benutzer:Schnark/js/diff which shows invisible characters as well as their names. — Qwerfjkl talk 14:04, 6 June 2024 (UTC)[reply]

Thanks! Gråbergs Gråa Sång (talk) 15:30, 6 June 2024 (UTC)[reply]

Courtesy link Combining grapheme joiner. DuncanHill (talk) 16:48, 6 June 2024 (UTC)[reply]

Need help finding incoming link on a page

Can someone help me ... find the link to Wikipedia:Graphics Lab that is apparently on the page Sir William Ramsay School? I've been trying to find it to see if the link is valid in its placement, but to no avail. Steel1943 (talk) 17:58, 6 June 2024 (UTC)[reply]

It came from | image_size = {{ifc| (low quality)}}, which I removed as it was misusing the parameter. * Pppery * _{it has begun...} 18:10, 6 June 2024 (UTC)[reply]

It's Thursday, 6 June and I have spots before my eyes

Tracked in Phabricator
Task T366845
Resolved

Resolved

See this diff, where one line was moved. The moved line ought to be preceded with curved arrows, on both the left- and right-hand sides. Instead, I see that these arrows are obscured by large black discs. If I hover my mouse over the disc, it resoves to the correct curved arrow, but returns to being a disc on moving the mouse away. This started happening in the last half hour. Firefox 126.0.1, all skins, logged in or out. I blame WP:ITSTHURSDAY. --Redrose64 🌹 (talk) 19:42, 6 June 2024 (UTC)[reply]

Can confirm. Same issue for Extended Support Release version of Firefox. Similar on Chrome and desktop site version on Mobile Firefox, except that the black disks are respectively dark blue and dark grey there. Desktop site on Mobile Chrome gives emoji-style white curved arrows in a blue box rather than plain box-less curved arrows with or without obscuring dot. AddWittyNameHere 20:09, 6 June 2024 (UTC)[reply]

I've filed phab:T366845 for this. Also happens with inline mode as well. Izno (talk) 20:24, 6 June 2024 (UTC)[reply]

You can also click them, they take you to where the software thinks the line was moved to or from (with no highlight whatsoever), not sure why they were turned into black discs though. – 2804:F14:809B:2701:19B4:583A:7C56:999F (talk) 20:53, 6 June 2024 (UTC)[reply]

Oh yes, you can click them... but you could click them before today. --Redrose64 🌹 (talk) 22:33, 6 June 2024 (UTC)[reply]

Wow. – 2804:F14:809B:2701:19B4:583A:7C56:999F (talk) 22:35, 6 June 2024 (UTC)[reply]

And I've been Ctrl+F-ing moved lines like a dummy this whole time‽ (╯°□°)╯︵ ┻━┻ And it's not really that hard to discover yourself

Self-trout. —⁠andrybak (talk) 08:44, 7 June 2024 (UTC)[reply]

I too am seeing this same exact issue on edit diff pages. Also Firefox 126.0.1 64-bit here, I think it happened on my Linux computer as well. Vector 2022 skin.

I didn't know you could click on the arrows, that's something new I learned today! — AP 499D25 (talk) 08:34, 7 June 2024 (UTC)[reply]

The following code does kill the black spots, but it is very dirty and I really don't want to leave it like that. Is there an edit preview event that I can hook to?
setInterval( function() {$('.mw-diff-movedpara-left, .mw-diff-movedpara-right').text(''); }, 666); — GhostInTheMachine ^{talk to me}

There is wikipage.diff —TheDJ (talk • contribs) 09:26, 7 June 2024 (UTC)[reply]

Thanks. The code now reads — mw.hook( 'wikipage.diff' ).add( function() { $('.mw-diff-movedpara-left, .mw-diff-movedpara-right').text(''); } );

That works fine and is clean enough for me to feel that it can stay there if I don't notice when

T366845 gets fixed — GhostInTheMachine ^{talk to me} 10:08, 7 June 2024 (UTC)[reply]

That was a bug? I thought it was some new design change. — Qwerfjkl talk 16:12, 7 June 2024 (UTC)[reply]

Scores won't play MIDI inside rendered mainspace?

Some JavaScript script loads, and on e.g. Syncopation, clicking on the JS'd play buttons just load forever now. Disabling JS enables normal playback, and page previews don't have this issue. Aaron Liu (talk) 20:57, 6 June 2024 (UTC)[reply]

WikidataInfo

Hi!!! In it.wiki there's a gadget that show me a link to the wikidata item. Is possible to have it also in other wikis? Is there a way to activate tha same preferences on all wikimedia projects?
Thanks for help Esc0fans -and my 12 points go to... 08:08, 7 June 2024 (UTC)[reply]

There should be a "Wikidata item" option under the Tools menu. That takes you to the matching Wikidata page — GhostInTheMachine ^{talk to me} 09:21, 7 June 2024 (UTC)[reply]

Help needed with collapsible infobox section templates

On the Ryzen article (permalink), I added Template:Collapsed infobox section begin and Template:Collapsed infobox section end to some parts of the Template:Infobox CPU to make it so they are put into collapsed boxes. The cache one came out fine aside from odd indenting which looks like it can be fixed using an additional parameter for CISB, however the transistor count one is not working as intended. While the transistor count entries are indeed in the box, the core count and extension parameters are also somehow in the collapsed template even though the CISB template is placed below them. What could be causing this? Is there some issue with Template:Infobox CPU? I turned on the syntax highlighter and couldn't see anything that sticks out, but my knowledge of template programming is quite minimal.

I tried enabling parameter "hide_subheadings=yes" for the infobox, and also tried adding "div=yes" parameters to the CISB templates (after seeing an editor remove it for lint error), neither of which have rectified the issue. — AP 499D25 (talk) 08:11, 7 June 2024 (UTC)[reply]

@AP 499D25: The display order of infobox fields is not determined by the order in the call but by the coding of the infobox template. The call can use any order and the order is ignored. The {{{name}}} box at the right of Template:Infobox CPU shows that the field right before transistors is numinstructions. Ryzen doesn't use that field so we go back one more field to extensions. That's where {{Collapsed infobox section begin}} should be placed if you only want transistors collapsed. I have reorganized the call accordingly.[21] Is that the result you want? I didn't actually have to move down the extensions parameter. Since the call order is ignored, I could instead have moved up {{Collapsed infobox section begin}} to wherever extensions is placed in the call, but my call layout is easier to understand and less likely to be broken later. PrimeHunter (talk) 16:49, 7 June 2024 (UTC)[reply]

I see what you are talking about. I didn't know the collapsed section begin template could affect what's above it. Indeed, that's the outcome I was looking for. I am happy with the reordering option as it is straightforward to see how the code works. Thanks! — AP 499D25 (talk) 23:59, 7 June 2024 (UTC)[reply]

Discussion at User talk:Enterprisey/script-installer#Confusing history of importScript

You are invited to join the discussion at User talk:Enterprisey/script-installer § Confusing history of importScript. —⁠andrybak (talk) 12:39, 7 June 2024 (UTC)[reply]

Template-generated redlinked categories

The latest run of Special:WantedCategories features a cluster of redlinked categories that are being somehow autogenerated by WikiProject templates — but I can't work out where they're coming from because the category declaration does not exist in either the template or its documentation, and none of the templates have been edited recently to suddenly generate new categories that didn't exist before this week, which means they're being passed through by a new coding change somewhere other than the templates themselves, such as in a module or a template framework I'm not familiar with.

But I can't justify creating most of them either, as they mostly seem to correspond to task forces rather than full wikiprojects, and thus would never have categories at the names that have been newly autogenerated for them — and in many cases they already have categories located at different names than the ones that have been newly autogenerated for them, which are sitting on the template alongside the redlink. By and large, they seem to correspond word-for-word to the name of the template itself, meaning that most likely some edit somewhere has caused an erroneous assumption that every WikiProject template should automatically generate an eponymous category matching its own name, which is obviously not the case.

So I'm at a loss. Could somebody look into the following categories, and figure out how to resolve them?

Thanks. Bearcat (talk) 17:56, 7 June 2024 (UTC)[reply]

Created the first one, which is an upstream software change not related to the others. The others were due to recent changes to Module:WikiProject banner/templatepage, which I've now reverted. * Pppery * _{it has begun...} 18:05, 7 June 2024 (UTC)[reply]

It's related to recent work by MSGJ (talk · contribs) and others. --Redrose64 🌹 (talk) 22:34, 7 June 2024 (UTC)[reply]

@Gonnym: should these categories be created? — Martin (MSGJ · talk) 05:34, 8 June 2024 (UTC)[reply]

Quarry - now fails with error

Greetings, Earlier today, I ran this query to find Orphan articles. It previously ran Ok. First error View 'enwiki_p.pagelinks' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them. I then logged off, waited a while, logged back in, then Second error Unknown column 'pl.pl_title' in 'on clause' .

This afternoon, same (second) error, so I ran this query instead. Same error Unknown column 'pl.pl_title' in 'on clause' .

I have no idea how to fix, so I am reporting here and hoping a Quarry expert will be able to correct. Regards, JoeNMLC (talk) 19:55, 7 June 2024 (UTC)[reply]

Wikipedia:Village pump (technical)/Archive 212#Tech News: 2024-20. The sql munging given there is a really bad idea that won't work at all in some queries, and there's conceivably queries where it would appear to work but change the meaning, but it looks like it'll work ok for your two. —Cryptic 20:26, 7 June 2024 (UTC)[reply]

THanks @Cryptic - tried to follow those instructions without any luck. For example, broken Quarry code:

77922 Orphaned - June, 2024

USE enwiki_p;
SELECT p.page_title
FROM page p
INNER JOIN categorylinks c ON p.page_id = c.cl_from AND c.cl_to = "Orphaned_articles_from_June_2024"
INNER JOIN pagelinks pl ON p.page_title = pl.pl_title AND p.page_namespace = pl.pl_namespace
INNER JOIN page p2 ON p2.page_id = pl.pl_from
AND pl.pl_from_namespace = 0 and p2.page_is_redirect=0
GROUP BY p.page_title
having COUNT(pl.pl_from)>1
ORDER BY COUNT(pl.pl_from) desc, p.page_title;

I may be good a cloning a quarry that works (changing month/year), but have zero knowledge of how to fix. Above is the broken one. If someone here can fix, that would be great. Thanks. JoeNMLC (talk) 20:55, 7 June 2024 (UTC)[reply]

Here you go. —Cryptic 21:15, 7 June 2024 (UTC)[reply]

Done - Thanks @Cryptic for this solution, very useful. Cheers! JoeNMLC (talk) 01:19, 8 June 2024 (UTC)[reply]

Broken infoboxes

I'm seeing broken infoboxes on Henry Kissinger and Donald Trump (broken styling making them too big, some kind of parse error in the 'spouse' field, specific offices held replaced by a redlinked 'Ambassador to'). No obvious recent edits to either that would have broken them, and both are high profile articles that I'd expect to quickly get fixed. Both use {{infobox officeholder}}, but again I don't see obvious recent changes (last one in April). It's probably something in the infobox machinery but I don't even know where to start looking or who to notify. Polyphemus Goode (talk) 11:43, 8 June 2024 (UTC)[reply]

Came here with the same issue! It appears to be all uses of that template. Jlalbion (talk) 11:46, 8 June 2024 (UTC)[reply]

Looks like Special:Diff/1227899624 fixed it. Anomie ⚔ 11:55, 8 June 2024 (UTC)[reply]

That edit to Template:If both fixed the marriage templates; the "Ambassador to" link is still there as the TFD template is still on Template:Both. Peter James (talk) 12:02, 8 June 2024 (UTC)[reply]

I've reverted that, and that appears to have worked. -- zzuuzz ^(talk) 12:08, 8 June 2024 (UTC)[reply]

I've added the notice back to Template:Both enclosed in <noinclude>...</noinclude> as Nickps suggested on the talk page.[22] Nick has added the notice to Template:Both using |type=disabled.[23] Did these edits restore the merge notices without breaking anything? Rjjⁱⁱⁱ (talk) 12:43, 8 June 2024 (UTC)[reply]

Wow, that was bad! Yeah, I really should have chosen disabled from the start. I took two templates that are sometimes supposed to return nothing and made them always return something. What could possibly go wrong? As for my suggestions, there is no way for WP:noinclude to break since its whole purpose is to transclude nothing but I'm not so sure about |type=disabled. I guess we'll see. Nickps (talk) 13:19, 8 June 2024 (UTC)[reply]

Proposals

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Applying it only to the param= part sounds reasonable. Sdkb ^talk 14:14, 6 May 2024 (UTC)[reply]

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)[reply]

@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)[reply]

Keep for another nine days. ―Mandruss ☎ 20:48, 21 May 2024 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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[reply]
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)[reply]
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)[reply]

Political userboxes (especially PIA)

The recent pages Wikipedia:Miscellany for deletion/User:AtikaAtikawa/Userboxes/Anti-israeli apartheid and Wikipedia:Miscellany for deletion/User:AtikaAtikawa/Userboxes/Antizionist have involved contentious discussion, where commenters have suggested deleting other PIA-related userboxes. Political userboxes in contentious areas, especially ones involving war and violence, have strong potential to antagonize other users and threaten Wikipedia's values of civility, collaboration and discussion. This may outweigh the value of users' political self-expression as Wikipedia is not a forum. In the case of PIA, userboxes open an avenue for unproductive controversy that does not improve PIA articles by users who are blocked from editing them by ECR. Do you believe that such controversial userboxes are a problem? If so, would you consider broader policy restrictions on userboxes that make politically controversial statements about PIA? Air on White (talk) 00:47, 27 May 2024 (UTC)[reply]

I think they may still have to be argued on a case by case basis. One problem may be that some box is "anti" or against something, rather than for something else. eg instead of anti-zionist, they could have said, the user wants only Arabs in Israel. Instead of Anti-israeli apartheid it could have said the user wants one joint Israeli-Palestinian state, and then been acceptable. So MFD probably has to consider the name and the content of each box. Graeme Bartlett (talk) 01:06, 27 May 2024 (UTC) edited Air on White (talk) 03:27, 27 May 2024 (UTC)[reply]

I agree that case-by-case evaluation makes sense, but I don't think that only positive statements will help. Remember the scandal about the editor who made a positive statement that he "respected" Hitler? Or the drama over the positive statement that the editor believed marriage should involve one man and one woman? "I positively affirm that I believe it would be best if your whole nation ceased existing" is not the kind of statement that builds up the community. It is the kind of statement that makes individuals feel excluded and rejected.

On the other hand, there are some statements that might be acceptable. The community would probably not object to more generic statements like "I'm anti-genocide" or "I support peace in the Middle East". WhatamIdoing (talk) 03:16, 27 May 2024 (UTC)[reply]

This has been discussed ad nauseam, and I'll say what I've been saying: using userspace to make politically charged statements violates WP:SOAPBOX, WP:NOTBLOG, and WP:UPNOT, and it calls into question whether an editor is capable of complying with WP:NPOV. Thebiguglyalien (talk) 01:59, 27 May 2024 (UTC)[reply]

Well the bias would be recorded on the userpage, and is disclosed, so NPOV has something to check. Undisclosed POV pushing could be worse. Graeme Bartlett (talk) 03:01, 27 May 2024 (UTC)[reply]

I agree that it gives us information about how biased an editor might be, but I still think it would hurt the community overall. We have to be able to work together. Sometimes that means not posting messages that you wish people would die, or that countries would fail. WhatamIdoing (talk) 03:18, 27 May 2024 (UTC)[reply]

(edit conflict)Agree with Graeme in that respect, there may be reasons to avoid userboxes taking clear positions on X and Y, but a userbox is, at most, a symptom of NPOV issues. CMD (talk) 03:19, 27 May 2024 (UTC)[reply]

My view, having spent years watching the ARBPIA topic area, is that this is easily resolved by not caring about PIA-related userboxes people put on their user page that no one needs to look at or spend any time thinking about (unless and until an editor does something ANI/AE-report worthy in terms of content editing or their interactions with other editors).

It could be argued that to care about them and draw attention to them can itself be 'unproductive and may antagonize other users and threaten Wikipedia's values of civility, collaboration and discussion' via something resembling the Streisand effect.
Or they can be viewed as a signal in all the noise, a useful public declaration of an editor's biases that may influence their editing.
If someone is deeply offended by an Israel flag on my page, or something about how great the IDF are, or my agreement with human rights organizations' assessments of Israel or Palestine, and such-like, I wonder why they are editing in the ARBPIA topic area. I wonder if they have read Wikipedia:Arbitration/Index/Palestine-Israel_articles#Editors_counselled and should do something else for a while.
The PIA topic area is blessed with a diverse set of editors/drive-by visitors ranging from infuriatingly dumb piece of shit fire-starter motherfuckers to very experienced and knowledgeable editors who (want/try to) focus on content. Those experienced editors all have biases that influence their content edits and talk page comments in various ways that can and do 'antagonize other users and threaten Wikipedia's values of civility, collaboration and discussion' on an almost daily basis. It's okay, the PIA topic area is not that brittle.
For interest (or not), many years ago I added some photos from an Israeli human rights organization to the top of my talk page, arranged in the form of a comic strip. It is deliberately ambiguous. I was interested in whether anyone would interpret them as 'politically charged statements that violate WP:SOAPBOX', because to do so they would have to use inference to decide whether they represented support or opposition to the removal of Palestinians from land in the West Bank by the IDF. No one has ever commented on them. No one cares, and for me, this is how it should be in ARBPIA.

Having opinions about how to socially engineer/nudge the ARBPIA topic area seems to be quite popular, but they are rarely evidence-based, and no one really understands the complicated dynamics and can predict the impact of rule changes and the ways they are interpreted/enforced on content and behavior. As I have said elsewhere, it's probably better to focus on enforcing the existing simple rules that cover PIA. Sean.hoyland (talk) 05:23, 27 May 2024 (UTC)[reply]

None of these boxes belong here at all. Including such things in a user box comes across as more "official" or site supported than the user just writing their views in their own words. While this site isn't a blog, having a user simply state their own biases so that others can tell that they are (or are not) someone you want to associate with is preferable to them slapping these things on their page giving the impression that Wikipedia endorses their position. Short version, we should do away with all user boxes.--User:Khajidha (talk) (contributions) 13:05, 28 May 2024 (UTC)[reply]

Deja vue. User:Donald Albury/The Great Userbox Wars Donald Albury 13:56, 28 May 2024 (UTC)[reply]

I've long thought that Userboxes expressing opinions on social/political issues should all go. I wish we had done it after the Pedophilia userbox wheel war of 2006 or any of the other userbox-related cases, but instead we just carved out very narrow exceptions. They're a pointless waste of far too much time, and don't really have a use in an online encyclopedia. I'd support any proposal that limits userboxes to those related to Wikipedia in some way. The Wordsmith^{Talk to me} 22:57, 29 May 2024 (UTC)[reply]

To clarify my position, I'd oppose a proposal to kill PIA-related userboxen. That just kicks the can down the road until the next big ethnic, religious, social or political conflict just like killing the pedophilia, anti-SSM, Hezbollah or pro-Russian userboxen did. The piecemeal approach isn't working, it just wastes more time with each flare-up and it does nothing to improve the encyclopedia. I'd support a proposal to remove all of them at once. The Wordsmith^{Talk to me} 18:13, 31 May 2024 (UTC)[reply]

I'd also support something like this. I'll note the Hezbollah one as particularly telling because it never got fully resolved. It was clear that some of the editors kept the same userbox endorsing Hezbollah's militant activity and reworded it in the hopes of creating plausible deniability. I tried to point this out last year, they shouted AGF, and nothing was done about it. None of this should matter because it's detrimental to the encyclopedia with minimal benefit—in my mind that should be the start and end of the discussion. Thebiguglyalien (talk) 20:24, 31 May 2024 (UTC)[reply]

I really don't like edgy politics shit in userboxes -- I consider it stupid and in poor taste regardless of whether I agree with it -- but I don't really know how we can put a stop to it without some kind of extremely broad dragnet apparatus that sweeps up all kinds of normal stuff. jp×g 🗯️ 04:05, 30 May 2024 (UTC)[reply]

In the real world, it has proven futile to use the law to ban expressions of dumb, distasteful opinions. It remains legal to say all kinds of obnoxious, provocative trash, and to print it on bumper stickers and T-shirts. Since it’s a big waste of time to try to legislate boundaries on this stuff, we generally deal with it through the use of quiet disdain. That is, rolling our eyes and shaking our heads, but ultimately moving swiftly on. Barnards.tar.gz (talk) 19:48, 31 May 2024 (UTC)[reply]

That's for governments, where these opinions directly affect how the government operates and there are real world implications that make restrictions on this conduct undesirable. Our situation is more analogous to a workspace, where making people feel unwelcome by bringing up controversial topics is absolutely something that's penalized. Thebiguglyalien (talk) 20:27, 31 May 2024 (UTC)[reply]

I'm sorry but I'm shocked that is discussion is categorized as "political" and that these userboxes are even debatable. Both userboxes mentioned support and advocate for violence against Israeli and Jewish people. What next? "Greater Germany" and "Heim ins Reich" userboxes? Gonnym (talk) 06:35, 30 May 2024 (UTC)[reply]

Hitler was a politician, and the Nazis were a political party, so yes, that would straightforwardly be a political issue -- political issues tend to be fairly serious and important, and millions of people die over them all the time. jp×g 🗯️ 06:54, 30 May 2024 (UTC)[reply]

"Both userboxes mentioned support and advocate for violence against Israeli and Jewish people." No they don't, neither one does any of that. Levivich (talk) 10:35, 30 May 2024 (UTC)[reply]

War and struggle over which people govern a piece of land is, by definition, an issue of geopolitics. That's political, and there's really no denying that. The Wordsmith^{Talk to me} 20:22, 30 May 2024 (UTC)[reply]

i don't generally comment here, but i saw it on the dashboard and thought i'd give my ~~brief~~ two cents. i have a single PIA-related userbox on my userpage, which says that apartheid is wrong, and another which advocates for an end to capitalism (nested among about 30 other userboxes unrelated to politics), so of course i'll be a little more generous to political userboxen than some above this comment. in my opinion, political (or otherwise controversial) userboxen are case-by-case. i find gratuitously or emphatically political userboxen usually kind of gauche, and highly provocative userboxen like the first one mentioned to be generally a bad idea, to say the least. however, i believe that self-expression on wikipedia userpages is a good thing to preserve, and i would probably oppose any kind of change to the P&Gs we currently have on this issue. we shouldn't, as some seem to say, expect that editors themselves must be neutral - No One Is Neutral, nor capable of being truly neutral. edits must be what's considered regarding NPOV. the matter here is one of disruption - i don't edit at all in the PIA area, so my userbox really has no indication on my views about the topics that i do edit about, some of which are contentious. for example, i edit articles related to the Caucasus region - if i had a "Georgia for Georgians" userbox with Abkhazia & South Ossetia erased from a map of Georgia, i couldn't blame anyone for assuming i was NOTHERE or a POV-pusher regarding Georgian topics. therefore, i keep my views on the various conflicts in the Caucasus private, as i want my editing in that area to be as explicitly NPOV and inscrutable as possible. i suggest a similarly nuanced approach for others working in contentious areas.

tl;dr - it's really all about context and disruptive potential in the areas an editor works in, rather than a hard-and-fast line. MfDs for particularly offensive or provocative userboxen are perfectly effective here. ... sawyer * he/they * talk 06:49, 31 May 2024 (UTC)[reply]

quick addendum: sean.hoyland i think says it best, regarding PIA specifically.
(edit: also, i'm unsubscribing from notifications for this and don't plan on replying or reading this thread further) ... sawyer * he/they * talk 06:58, 31 May 2024 (UTC)[reply]

Article name change - nuances in a bilingual context

Hello, I am not entirely sure if this belongs here, but I wanted to ask if I could change the title of the article 'CD Atlético Baleares' to 'CE Atlètic Balears'. This football (soccer) club is from Mallorca, Spain, where both Spanish (dominant language) and Catalan (original language) are spoken. I want to change the club name in the article from Spanish to Catalan because the majority of supporters uses the Catalan name and all bibliography about the club and its history always uses the Catalan name as well. On the other hand, the club's official name is only in Spanish. Still, I consider the Catalan name more appropriate and representative. Does anyone know what the policy on these topics is? Thanks in advance! Liamb723 (talk) 14:58, 31 May 2024 (UTC)[reply]

The relevant policy is WP:TITLE, which instructs us to choose titles based on what is most recognizable to English-speaking audiences, which in practice means following English-language RS's conventions. _signed,Rosguill ^talk 19:54, 31 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Try Special:RandomInCategory instead. Folly Mox (talk) 01:07, 3 June 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
"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)[reply]
I agree with Chetsford on this. Wolverine XI ^{(talk to me)} 04:11, 9 April 2024 (UTC)[reply]
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)[reply]
Never say never. Wolverine XI ^{(talk to me)} 13:16, 9 April 2024 (UTC)[reply]

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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]

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)[reply]
It might be a good idea. 3.14 (talk) 19:07, 8 April 2024 (UTC)[reply]
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)[reply]
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)[reply]

"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)[reply]
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)[reply]
"would be difficult if they are dead" I imagine it would. Chetsford (talk) 08:48, 10 April 2024 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
(the correct link is wikt:Template:User Barnstar, with a capital B. Aaron Liu (talk) 01:51, 11 April 2024 (UTC)[reply]
Thanks. Cremastra (talk) 19:39, 12 April 2024 (UTC)[reply]

It's okay if you choose not to participate in the process. Wolverine XI ^{(talk to me)} 04:55, 11 April 2024 (UTC)[reply]
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)[reply]
Maybe. Wolverine XI ^{(talk to me)} 16:07, 12 April 2024 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
Good point, but Wikipedia is not baseball. Wolverine XI ^{(talk to me)} 06:57, 14 April 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]

I agree with Enby. What purpose would that serve? Aaron Liu (talk) 15:27, 17 April 2024 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

Don't we already have every single needed discussion "board" known to Man? Aaron Liu (talk) 20:24, 17 April 2024 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
Divisive programs, like the WP:Editor of the week, already exist. Wolverine XI ^{(talk to me)} 22:41, 20 April 2024 (UTC)[reply]
And that's not an excuse to have more of them. Chaotıċ Enby (talk · contribs) 22:46, 20 April 2024 (UTC)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

The stocks aren't a hall of shame, it's a humourous list of mistakes. -- LCU ActivelyDisinterested «@» °∆t° 21:04, 9 May 2024 (UTC)[reply]

Awesome Aasim, isn't WP:Long term abuse already kind of that? — 🌙Eclipse ^(talk) ^(contribs) 14:49, 18 May 2024 (UTC)[reply]

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)[reply]

We already have a hall of shame. Just Step Sideways ^{from this world ..... today} 17:40, 26 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

Ideas for promotion of the mentorship program

Hello all,

As you are probably aware, the growth team has introduced the Mentorship program on the English Wikipedia a little while ago. Currently, only 50% of new accounts on Wikipedia are assigned a mentor due to the amount of mentors currently available. I would like to know if anyone had ideas about potential ways to promote the mentorship program to experienced editors who would not know about it, or not have considered it?

This could include:

Mass-messaging users involved in help forums who might be interested in mentoring
Adding mentorship on the Task Centre for experienced editors

Any other ideas welcome!

Cheers, Cocobb8 (💬 talk • ✏️ contribs) 18:20, 11 May 2024 (UTC)[reply]

Have you asked @Trizek (WMF) about what's worked at other Wikipedias? WhatamIdoing (talk) 23:11, 17 May 2024 (UTC)[reply]

Let's see what he says! Cocobb8 (💬 talk • ✏️ contribs) 21:09, 18 May 2024 (UTC)[reply]

Well, you are the only wiki where it is difficult to find enough mentors!

At most other wikis, we got the right amount of mentors to signup; in a few cases, we had too many mentors for the size of the wiki (Ukrainian Wikipedia has so many mentors that some mentors never got a question after 6 months).

My advice: try what you suggested. :) Trizek_(WMF) (talk) 15:09, 20 May 2024 (UTC)[reply]

Thanks for the info! @WhatamIdoing, what are your thoughts on the options I proposed for promoting mentorship here on English Wiki? Should I propose adding mentorship on the task centre on the centre's talk page, and formally proposing mass-messaging at proposals in village pump? Cocobb8 (💬 talk • ✏️ contribs) 16:55, 20 May 2024 (UTC)[reply]

How about an article in the next Signpost, explaining the program and recruiting experienced editors to sign up? Schazjmd (talk) 16:57, 20 May 2024 (UTC)[reply]

@Schazjmd Neat idea as well, I would support that! I have no experience in writing/proposing anything for the signpost though. Cocobb8 (💬 talk • ✏️ contribs) 17:01, 20 May 2024 (UTC)[reply]

@Cocobb8, me neither, but they do have a quick-start guide. Schazjmd (talk) 17:05, 20 May 2024 (UTC)[reply]

Nice idea! Let me know how I can assist you there @Cocobb8. I can find facts and data, but also stories to share. Trizek_(WMF) (talk) 17:05, 20 May 2024 (UTC)[reply]

@Trizek (WMF) and @Schazjmd, I have started a Signpost draft. Please, feel free to edit it and add to it (anyone, really)! The more people who have some things to add, the better chances are we can have a successful Signpost news story to share :). Cocobb8 (💬 talk • ✏️ contribs) 18:54, 20 May 2024 (UTC)[reply]

There is also opportunity for graphs and images, so if you have any of value @Trizek (WMF) that would be amazing. Feel also free to comment direclty on the draft's talk page. Cocobb8 (💬 talk • ✏️ contribs) 18:55, 20 May 2024 (UTC)[reply]

I have added the mentorship on the Task Center. Cocobb8 (💬 talk • ✏️ contribs) 19:10, 20 May 2024 (UTC)[reply]

@Cocobb8, rather than a mass message, if might be more effective to try Snowball sampling. Imagine a template that's easy to post on someone's talk page that says something like this:

	Seeking mentors for new editors
	The homepage needs new mentors. Mentors are important because... If you're interested in helping new editors learn how to become productive contributors, please take action... If you know someone that would make a great mentor, please invite them by adding {{subst:Snowball}} to their talk page.

The overall idea is that a semi-personal invitation from someone you know might be more effective than impersonal spam. WhatamIdoing (talk) 19:29, 20 May 2024 (UTC)[reply]

Great point, that might be more effective and there would be no need for consensus before posting on talk pages. I'm not really good at creating templates though, but what you proposed looks pretty good! Cocobb8 (💬 talk • ✏️ contribs) 19:31, 20 May 2024 (UTC)[reply]

The important part is writing good text. You probably need:

a brief explanation of what it is,
a reason why this is important,
a specific, straightforward action that they should take, and
a talk page where they can ask questions.

The format above is just a table. I copied it from one of the Wikipedia:Barnstars. WhatamIdoing (talk) 05:50, 25 May 2024 (UTC)[reply]

Wikipedia:Naming conventions (royalty and nobility) - RfC drafting for reversion of the November 2023 change

In November 2023, NCROY was altered by consensus to instruct editors to not disambiguate royalty and nobility with their geography unless disambiguation is required.

This has proven controversial with some editors arguing that the result does not reflect the consensus of the broader community; there has been considerable disruption as a result of this.

To resolve this I believe a second, broadly advertised, RfC would be beneficial; this would be held at the Village Pump, be listed at WP:CENT, and ping all the editors involved in the recent RfC as well as any relevant RM's. One way or the other, this should provide a path to resolving this dispute; I am opening this discussion to help draft it with the intent of opening it once the current ArbCom case request closes.

My initial proposed question is:

Should our naming convention on royalty and nobility instruct editors to generally disambiguate royalty and nobility with their geography, unless there is an "overwhelming commonname"?
The context for this discussion includes:
A November 2023 RfC consensus instructing editors to disambiguate only if disambiguation is required.

A May 2023 ArbCom case request that raised concerns about disruption in the topic area. This case lists a number of recent requested moves and move reviews.

A village pump discussion drafting this RfC.

BilledMammal (talk) 05:11, 13 May 2024 (UTC)[reply]

It's a good question, in my opinion. Deb (talk) 10:18, 13 May 2024 (UTC)[reply]

Notified: Wikipedia talk:WikiProject Royalty and Nobility, Wikipedia talk:Naming conventions (royalty and nobility)‎. Rosbif73 (talk) 08:03, 13 May 2024 (UTC)[reply]

First thought: I'm not convinced that the RFC should lump royalty and nobility together. The changes made following the November RFC related only to monarchs. Non-ruling nobility are a different kettle of fish with their own issues, but if we want to avoid getting sidetracked it would be best to keep the focus on monarchs only at this point IMO. Rosbif73 (talk) 07:38, 13 May 2024 (UTC)[reply]

I'm not sure that the proposal quite captures the nature of the opposition. In at least some of the RMs the dispute is whether NCROY is more, less or equally important than other guidelines (e.g. WP:PRECISE, WP:RECOGNISABLE, WP:PRIMARY, WP:COMMONNAME). I think a better question would be something like "Should articles about monarchs include a geographical element in the title when it would be unambiguous without it (e.g. "Oliver III" or "Oliver III of Montenegro")?" The possible answers to that should be "(almost) always", "sometimes" and "(almost) never". Including the "sometimes" option is important, further discussion would probably be needed (if that gets consensus) to determine whether there should be guidance (and if so what) about when to include and when not to inlcude. Thryduulf (talk) 09:08, 13 May 2024 (UTC)[reply]

@User:BilledMammal Thank you for the initiative.

For pragmatic reasons, I'd also like to consider the possibility of a carve-out for British monarchs and/or 20th Century monarchs (or some other arbitrary date). We're searching for a norm that is workable for thousands of articles, across two thousand years of history, covering hundreds of countries, serving readers from all across the globe. The search for a workable norm should not be held hostage to nationalist squabbles of recent or local interest.
It should also consider the matter of variant spellings of names. Monarch names are usually translated in reliable sources, often in a variety of ways (Louis, Luis, Ludwig, Ludovico, Luigi, Lajos, Lodewijk etc. are all the same name). Wikipedia readers come from all sorts of backgrounds, using different sources with different spellings, and they should not have to guess which language or spelling Wikipedia editors happened to choose. The aforementioned "Oliver III" is the same name as "Olivier III".
Expanding the norm with full designation "king" should be considered. That is, to obtain "Oliver III, King of Montenegro", or "King Oliver III of Montenegro" or "King Oliver III" (which is how he is usually referred to in most RSs, e.g. Britannica, indexes of books, etc.). This would be consistent with how we treat non-numeral monarchs (e.g. "John, King of England"), and practically all nobility and peers articles ("Geoffrey II, Count of Anjou", "William Cavendish-Bentinck, 3rd Duke of Portland" etc.). I expect this would not find much support among minimalists. But maybe should be an option to consider. It would be particularly useful for such unrecognizables as Nicholas II (Who? Pope? King? Duke? Rocket? Ship? Movie? Hedge fund?), who would be instantly recognizable as "Tsar Nicholas II".
On Sovereign vs. Nobility. Clarification needs to be made for non-sovereign German & Italian nobles, who some editors oddly think or treat as sovereigns, and try to apply WP:NCROY rather than WP:NCPEER (weirdly arguing that NCPEER only applies to British). And if they are treated as sovereigns, then does this apply also to great French nobles, Polish nobles, Danish nobles, etc.? If the norms are going to be different, then it needs to be clear who is sovereign and who is nobility.
On Big vs. Small Countries. This came up in RMs. If shortening is permitted, what, if any, safeguards will there be for small countries? Or shall big famous countries (Great Britain, France, etc.) be allowed to dominate the titling? In the previous norm, "Oliver III of France" is on equal footing with "Oliver III of Montenegro" - article titles are distinct, neither primary over the other. But with shortening, which is the WP:PRIMARYTOPIC for "Oliver III"? The current post-RFC says to keep country "when disambiguation needed", but nonetheless that was not respected. Once shortening was allowed there was an immediate spate of RMs to move the kings of large countries as primary at the expense of small countries (or other units - e.g. Tsars are apparently primary over Popes for some reason). France is a big country, with a large population, and a lot more history books written about it, whereas Montenegro is a small country with fewer works on it. So if allowed to shorten, then it is very easy for RMs to insist that the French king is "primary topic" for "Oliver III", and relegate the Montenegrin Oliver III. I don't think Wikipedia should be setting up a norm that reinforces the dominance or superiority of big countries over small countries. The insinuation is disturbing: "my king is more important than your king", "my country is large & important, yours is small & irrelevant" etc. This is not something Wikipedia guidelines should endorse, in an international encyclopedia, written for a global audience. It is not only distasteful in itself, it it also setting up a pig's breakfast that will feed a lot of horrific nationalist squabbles (France over Sweden, Great Britain over Georgia, Serbia over Montenegro, Spain over Portugal, Russia over Ukraine, etc.). So I'd like the proposal to contain CLEAR safeguards that prevent large country monarchs from dominating titling, and protect monarchs of small countries from being relegated to second tier status. Walrasiad (talk) 10:32, 13 May 2024 (UTC)[reply]

If one of the contenders for a primary topic features much more prominently in the history books (or other reliable sources) than all the others, then it is normal for them to be considered primary. Sure, in many cases that will appear to favour "big countries", but there are also cases where the sources show a prominent monarch from a "small country" to be of greater long-term significance than their namesakes from larger countries. In all cases, primacy on Wikipedia is simply a reflection of primacy in sources, not any form of judgement on the relative importance of the countries. The only safeguards that are needed are already laid down in WP:PRIMARYTOPIC. Rosbif73 (talk) 13:21, 13 May 2024 (UTC)[reply]

Regarding translation / variant spellings of names, Wikipedia should simply reflect the preferred spelling in reliable English-language sources. It is perfectly normal, per WP:SMALLDIFFERENCES, for Maria I to be a different person than Mary I. It is also normal to find Philip V but Felipe VI, because the norms in English-language sources have changed over time. Any potential confusion can and should be cleared up via standard wiki mechanisms such as hatnotes and short descriptions. Rosbif73 (talk) 13:49, 13 May 2024 (UTC)[reply]

Strongly disagree with both your points.

(1) Deliberately introducing large country bias should not be acceptable in Wikipedia guidelines, for both moral and practical reasons. (WP:SYSTEMICBIAS). There are ways of avoiding it. I would hope for a better answer than that.

(2) You can title the article as per RSs. But you can't rely on "small differences" when the sources Wikipedia readers are coming from use many variations. Readers of Wikipedia can be expected to read & understand English. They should not be also expected to know Romanian, Danish, Portuguese, etc. and certainly not be demanded to guess the idiosyncratic tastes of Wikipedia editors. Walrasiad (talk) 14:16, 13 May 2024 (UTC)[reply]

You raise some points that will be worthwhile to consider - but we also need to keep in mind that the primary goal is to conclusively resolve whether editors who oppose the recent moves are correct that the November 2023 RfC did not reflect community consensus.

Because of that I want to keep the primary question of the RfC simple, so that this question can be clearly answered - if the primary question starts to deviate too far from the pre-RFC status quo then it will become unclear whether the community opposes recommending geographical disambiguation even when otherwise not required, or whether the community merely opposes the additional changes proposed in that RfC.

However, if we are going to run a widely advertised RfC then it may be appropriate to make the RfC a multi-part one, to take full advantage of that attention - are any of your points part of long-running disputes that it would be helpful to bring the broader communities attention to? BilledMammal (talk) 17:41, 13 May 2024 (UTC)[reply]

I think we should almost certainly phrase this in terms of an example. Using Louis XVI, the question would be:

In the absence of a need to disambiguate, how should we title the articles of monarchs?
Louis XVI

King Louis XVI

Louis XVI of France

King Louis XVI of France

Loki (talk) 13:34, 13 May 2024 (UTC)[reply]

I like this formulation because I find it very easy to understand. But whether the rule (whatever it may be) should apply to monarchs or nobles or both, and whether it should apply to all monarchs/nobles or just some, seem to be live issues? I also think the polling should be set up as ranked voting so people can express a preference for, e.g., 3/4 over 1/2 (include geography regardless of title), or 1/3 over 2/4 (exclude title regardless of geography), or 1>2/3>4 (less is better), or 4>2/3>1 (more is better), etc. Levivich (talk) 14:57, 13 May 2024 (UTC)[reply]

Having read WP:NCROY more closely, I would like to also add 5. Louis XVI, King of France as a possibility, to match what it currently recommends for monarchs with a title lower than king. Loki (talk) 21:19, 13 May 2024 (UTC)[reply]

I like this phrasing. I would adjust it slightly, though, to include both the general description and the example:

In the absence of a need to disambiguate, how should we title the articles of monarchs?
Regnal name and nominals; eg Louis XVI
Title, regnal name, and nominals; eg King Louis XVI
Regnal name, nominals, and realm; eg Louis XVI of France
Title, regnal name, nominals, and realm; eg King Louis XVI of France
If you support multiple, please rank your preferences. If the closer finds it necessary to resolve preferences, they will resolve them through the single transferable vote method.

This also includes Levivich's suggestion of ranked voting; I've also added a proposed method for resolving the preferences, as previous ranked !votes have resulted in disputes over the method used - by specify it at the start we should be able to avoid that. BilledMammal (talk) 17:52, 13 May 2024 (UTC)[reply]

Should we really be envisaging a poll (single transferable vote or otherwise) rather than the usual assessment by the closer of policy-based arguments? WP:VOTE reminds us that the use of polls is often controversial and never binding. Rosbif73 (talk) 19:05, 13 May 2024 (UTC)[reply]

I agree that the only allusion to voting we should have is an instruction to rank choices. Saying the closer will resolve "votes" in any particular way mistakes how RFCs work. While they can feel similar to votes from the perspective of the participants, from the perspective of the closer they're very clearly not votes. Loki (talk) 02:29, 14 May 2024 (UTC)[reply]

While I understand the impulse here, in my view the actual effect of including the description is to add a bunch of extra jargon that's completely redundant with the examples. Loki (talk) 02:32, 14 May 2024 (UTC)[reply]

How about

Louis XVI (regnal name and nominals)
King Louis XVI (title, regnal name, and nominals)
Louis XVI of France (regnal name, nominals, and realm)
King Louis XVI of France (title, regnal name, nominals, and realm)
Louis XVI, King of France (regnal name, nominals, title, and realm)

Levivich (talk) 02:47, 14 May 2024 (UTC)[reply]

I like that a lot better. I'm still not convinced the description is necessary, but I'd accept it. Loki (talk) 03:37, 14 May 2024 (UTC)[reply]

What about Louis XVI (king of France) (following standard practice, no special rules for monarchs) or Louis XVI (France) (how German WP does it)? Not all options would be possible for every king, since some names are ambiguous. We have to distinguish between the question of how to handle kings like Henry IV (which one?) and Louis XVI (no question of primary topic). Srnec (talk) 15:45, 14 May 2024 (UTC)[reply]

At this time, I have no comment on which of Loki's proposals may be the "best". However, after seeing the comment on German Wikipedia article titling, I do want to the note that according to WP:CONSISTENT (emphasis mine): The English Wikipedia is ... under no obligation to use consistent titles with other language versions of Wikipedia. AndrewPeterT (talk) (contribs) 15:54, 14 May 2024 (UTC)[reply]

The English Wikipedia is indeed under no obligation to be consistent with other language Wikipedias, however that is irrelevant to Srnec's comment. If another language Wikipedia solves a problem in a certain way, it is entirely reasonable to suggest including that way in a list of options for how to solve that same problem on the English Wikipedia. Thryduulf (talk) 21:28, 14 May 2024 (UTC)[reply]

On a slight tangent, I note that my proposal to change the guideline's name to "Naming conventions (European royalty and nobility)"—to better reflect what the guideline purports to be—received no input: any thoughts now? ~~ AirshipJungleman29 (talk) 17:36, 13 May 2024 (UTC)[reply]
Since this issue is different from what the potential RfC seeks to address, I will comment on this: Yes, I support this change to the guideline's title (and creating a shortcut like WP:NCEUROY accordingly). And I would even go further to retitle the guideline Naming conventions (post-classical European royalty and nobility). Simply stated, it is Eurocentrism and/or WP:BIAS to attempt to conform article titles like Emperor Kinmei, Nawaf Al-Ahmad Al-Jaber Al-Sabah, or even Claudius to WP:NCROY as written. AndrewPeterT (talk) (contribs) 18:54, 13 May 2024 (UTC)[reply]
The guideline notes all those exceptions and points editors to the right places for guidance. —Compassionate727 ^(T·C) 00:29, 14 May 2024 (UTC)[reply]
In this case, the European guideline shouldn't have a generic title that makes it appear to be the "default" for royalty naming conventions. Chaotıċ Enby (talk · contribs) 19:48, 14 May 2024 (UTC)[reply]

One other point worth clarifying is the definition of "Europe" (assuming that the November 2023 change is preserved). There were some recent RMs over Georgian monarchs for which it was disputed whether Georgia was a European country. -- King of ♥ ♦ ♣ ♠ 17:41, 13 May 2024 (UTC)[reply]
If we are going to include multiple questions I like the idea of focusing on ones that will apply regardless of the result of the primary question, such as the question you raise here. BilledMammal (talk) 17:53, 13 May 2024 (UTC)[reply]

The introduction to NCROY sets out its scope as being European monarchs that share a set of given names, and tells us that elsewhere, territorial designations are usually unnecessary in article titles. Georgia is something of a special case: some of its monarchs share given names (Stephen, David, George, Michael, Alexander, Constantine, Simon) with western European monarchs, but most do not. The important point is the namestock, not the geographical location. Rosbif73 (talk) 19:34, 14 May 2024 (UTC)[reply]
Indeed, it may be worth amending the guideline to explicitly apply to all names following the (name)(ordinal)[of territory] pattern, because Georgia is not the only non-European example of this. (E.g., Musa III [of Mali]). —Compassionate727 ^(T·C) 16:16, 26 May 2024 (UTC)[reply]
Yep. If the proposed RfC takes place and confirms the current status (i.e. use a territorial designation only if disambiguation is necessary) then we really ought to review the entire guideline. As it stands, the November RfC was implemented by making a minimal change to the wording, and some of the provisions in the introduction could do with being revised for consistency. Rosbif73 (talk) 06:30, 27 May 2024 (UTC)[reply]

BilledMammal, thank you for taking the time to start this conversation. Because my previous comments on this topic (namely in a previous November 2023 request for comment (RfC) on this same matter) have received negative feedback, I have no comment on the scope of potential new RfC at this time. My only hope is that the community will finally be at a mutually agreeable place with WP:NCROY after this discussion concludes, however long it takes. AndrewPeterT (talk) (contribs) 18:43, 13 May 2024 (UTC)[reply]

That being said, should a notice at WP:AN to invite an uninvolved administrator to monitor and close this possible RfC be posted? This way, any problematic conduct can be immediately addressed. AndrewPeterT (talk) (contribs) 18:43, 13 May 2024 (UTC)[reply]

I would also note that European monarchs whose rank is below that of emperor or king (i.e. those of the tiny German states in the Holy Roman Empire) follow the different notational standard established in WP:NCROY#5 ([Name] [Ordinal if applicable], [Title] of [Primary holding]; ex. Maximilian I, Elector of Bavaria or Casimir, Margrave of Brandenburg-Kulmbach). So the latest proposed RfC question In the absence of a need to disambiguate, how should we title the articles of monarchs? may more accurately be titled something along the lines of [...] how should we title the articles of European imperial and royal monarchs?. Curbon7 (talk) 20:53, 13 May 2024 (UTC)[reply]
I think all of the above is skirting the real issue. The scope here is only those articles where the COMMONNAME for the subject does not include regional information ("of country") and is sufficiently PRECISE to distinguish from other uses (i.e., the COMMONNAME is either unique or this use is the PRIMARYTOPIC for the COMMONNAME). That is, if usage in RS demonstrates that including the regional information is the COMMONNAME, or the regional information is necessary for disambiguation because the COMMONNAME is not unique and this use is not primary for this COMMONNAME, then there is no issue about including the regional information. So the RfC question should reflect exactly that:

When the COMMONNAME for a sovereign or royalty subject does not include "of country" regional information, and the COMMONNAME is unique, or the subject is primary for its COMMONNAME, should we ever include "of country" information in the title? If so, when and why?

Of course, people can also disagree about what the COMMONNAME is based on usage in RS, but in those cases CONCISION is an excellent and convenient tie-breaker, favoring leaving off the regional information. Similarly, there can be disagreement about whether a given use is primary for the COMMONNAME in question, but that's no different than for any other article with an ambiguous COMMONNAME and there is debate about whether the topic is primary, and is not a problem unique to NCROY. So we don't need to be concerned with addressing those cases in this guideline.

--В²C ☎ 03:41, 17 May 2024 (UTC)[reply]

As I asked elsewhere, can you provide any actual examples of sovereigns whose regnal name would be unambiguous without a territorial designation but whose COMMONNAME unequivocally includes one? If not, then this issue is moot and should be kept out of the guideline to avoid future contention. Rosbif73 (talk) 06:41, 17 May 2024 (UTC)[reply]

I wanted to account for the possibility for such cases. But if you want to assume there are none, fine:

When the COMMONNAME for a sovereign or royalty subject is unique, or the subject is primary for its COMMONNAME, should we ever include "of country" information in the title? If so, when and why?

—

В²C ☎ 23:05, 17 May 2024 (UTC)[reply]

I think that the missing piece of context is: A lot (most? nearly all?) of the individual RMs since that November RFC have come to the opposite conclusion. It's bad form to have a rule saying the opposite of what the community wants to do. WhatamIdoing (talk) 23:16, 17 May 2024 (UTC)[reply]
The majority of the decisions have been consistent with NCROY since it was revised. —В²C ☎ 12:49, 24 May 2024 (UTC)[reply]
That's obscuring that many of the decisions have been highly controversial and there have been comments that support moves to match NCROY with the sole purpose of matching NCROY rather than any opinion about whether that is best - indeed I've seen at least one comment that supported a move to match NCROY despite the editor thinking that was an inferior title. Thryduulf (talk) 16:28, 24 May 2024 (UTC)[reply]
That may be, but presumably most editors who supported "per NCROY" like the guideline's prescription. Those who dislike it have been vocal enough. —Compassionate727 ^(T·C) 22:24, 25 May 2024 (UTC)[reply]
Maybe, maybe not. We have insufficient evidence to say one way or the other. Thryduulf (talk) 00:23, 26 May 2024 (UTC)[reply]

Inflation template

The template is a terrific idea, but can give ludicrously precise quotients. An example I recently came across in the Miles Davis article:

". . . leaving Davis to pay over $25,000 (equivalent to $251,800 in 2023)"

It's a basic principle that the solution of a conversion should not have a greater degree of precision than that of the supplied data. That applies to measurements where the conversion factor is known with a high degree of accuracy, but of course depreciation of the value of currency depends on the medium of exchange, be it gold or a tradesman's wages. In an improved template, the above should, by default, read:

". . . leaving Davis to pay over $25,000 (equivalent to roughly $250,000 in 2023)" (my bolding)

with the option for the editor to increase or decrease the level of precision for special purposes. Doug butler (talk) 14:50, 14 May 2024 (UTC)[reply]

IMO {{inflation}} should be deleted and Wikipedia shouldn't be in the business of calculating inflation. {{inflation/US}} uses the Consumer price index (CPI). The problems with using CPI to measure inflation are extremely well-reported, so much so that even the Bureau of Labor Statistics, which published CPI in the US, has said The CPI cannot claim to be a completely precise measure of inflation and publishes the variance of its estimates. {{inflation/US}}, however, doesn't present the figure as a range, it provides a calculation, leading to false precision (on top of the problems with using CPI in the first place). I have no idea what {{inflation}} uses for countries other than the US or how accurate it is. And I don't know how often the numbers are updated or with what precision or what the qualifications are of the editors who are doing the updating. If you ask me, the templates should be deleted, we are basically misinforming the reader when we say that $X in year Y is equal to $Z today. Such statements should be cited to reliable sources, not to CPI calculations by editors. It's WP:OR. Levivich (talk) 15:21, 14 May 2024 (UTC)[reply]

Well, if you don't know (and cannot be bothered to look up) anything about the template, how it works, where the information comes from, or how it's computed, why would your opinion about it be useful or relevant? jp×g 🗯️ 04:03, 15 May 2024 (UTC)[reply]

FWIW, I fully agree with you on this. —Compassionate727 ^(T·C) 16:25, 26 May 2024 (UTC)[reply]

I would agree. If I recall correctly, the inflation template does some amount of rounding (either by default or as an option, I can't remember) so as to avoid false precision of this sort. jp×g 🗯️ 04:05, 15 May 2024 (UTC)[reply]

The template already has a parameter to round the output - r=, see Template:Inflation#Rounding so what the OP is really asking is to change the default from unit precision to the same precision as the source data. Given that it is not possible for the template to know the precision of an input (e.g. is £2000 accurate to 1, 2, 3 or 4 figures?) the option to specify a non-default level of precision is always going to be required.

All pages that currently correctly use the default precision would need to be adjusted to explicitly specify that before changing the default so as to avoid introducing inaccuracies. Given that there is no automatic way to know which articles are using the default correctly and which are using it incorrectly, every such usage would need to be examined by a human. That would be a very large job, for not really much benefit. Thryduulf (talk) 08:23, 15 May 2024 (UTC)[reply]

I agree that inflation figures usually need rounding, but it is difficult to get the default right. Whenever you see this type of false precision, WP:SOFIXIT by using the parameter as suggested by Thryduulf. —Kusma (talk) 09:18, 15 May 2024 (UTC)[reply]

Yep. — SMcCandlish ☏ ¢ 😼 18:20, 15 May 2024 (UTC)[reply]

I've marked it as such in the templatedata. Aaron Liu (talk) 18:27, 15 May 2024 (UTC)[reply]

It would surely be possible to automatically calculate the number of significant figures in the input and by default round to the same. —Compassionate727 ^(T·C) 00:23, 26 May 2024 (UTC)[reply]

It isn't possible to reliably calculate the number of significant figures in the input without the context from the source material. For example "It cost £2000" could be accurate to 1, 2, 3 or 4 significant figures. Thryduulf (talk) 00:34, 26 May 2024 (UTC)[reply]

Nobody on Wikipedia uses scientific notation or "$4000. blabla were lost." with that dot. Aaron Liu (talk) 01:17, 26 May 2024 (UTC)[reply]

Good points. However, I do think that for numbers ending in some quantity of zeroes, it would probably be okay to round by default to the corresponding number of preceding digits, especially given the vagaries inherent in inflation calculation. —Compassionate727 ^(T·C) 16:23, 26 May 2024 (UTC)[reply]

Hmm, good point. I guess the user could always specify if it's different. Aaron Liu (talk) 19:34, 26 May 2024 (UTC)[reply]

Revisiting date auto-formatting

Back in the late 2000s to early 2010s, we had a feature by which dates were auto-formatted. This ended up leading to a bunch of strife, and the feature was turned off. This happened because the feature (implemented as a MediaWiki parser function) relied upon linking, such that every date was a link, and it caused a "sea of blue" problem.

With the advent many years ago of Lua modules, it seems that we could do this better now, untied in any way to linking. We already have Lua code in various templates (as well as Javascript code in user scripts) that can parse most dates. So, it seems to me that it would be beneficial to have something like the following:

Parse all sane date formats, from 1852-02-08 to 8th February 1852 to Feb. 8, 1852 to 8-FEB-1852, and so on.
- Exclude material between quotation marks or inside a quotation template.
- Flag as errors any instances that cannot be unambigously parsed, e.g.
- Provide an "ignore" wrapper template that can be used around things that appear to be (or contain) dates but should not be parsed as such (e.g. a serial number that is coincidentally in the format 1852-02-08, or a book titled On Feb. 8, 1852.
Identify templates like {{use mdy dates}}, etc., at the top of the page and "obey" them, to normalize all dates to the prescribed format for that page.
- If there isn't one, but there is a {{Use X English}} template, pick the date format that conventionally matches the specified country name.
- If both of the above conditions fail, then do some statistical analysis, and normalize dates to whatever date format already dominates in the article (other than ISO's YYYY-MM-DD, which is not human-friendly for our readers).
Read a preferences setting, for logged in users, and override the display of dates to whatever the user set as their preference.
Use a bot to replace all the non-excluded dates in the code with a single canonical format (probably ISO).

The results of this would be:

An end to the need to keep re-re-re-normalizing dates (manually or by script) in an article back to the format specified in {{use xxx dates}}. (The dates always become inconsistent over time because various citation tools that people use only output a single format, or have an option to pick one that people don't bother to use, or people are writing entirely manually and use the date format they like better without regard to the rest of the article content).
Article source code that is better for WP:REUSE purposes, with consistent dates that can be reformatted by reusers in an automated manner as they see fit.
Articles with consistent date display, matching whatever is set by the article-top template.
Ability of readers who really, really like one particular format to impose it on their personal WP experience.

— SMcCandlish ☏ ¢ 😼 18:17, 15 May 2024 (UTC)[reply]

WHAT HAVE YOU DONE WITH SANDY MCCANDLISH? E Eng 18:25, 15 May 2024 (UTC)[reply]

That sounds better suited as a configured mw:Writing systems/LanguageConverter than basically a specific version of zhwiki's NoteTA, though both would work, and Lua does seem like the language more popular here than PHP. Aaron Liu (talk) 18:31, 15 May 2024 (UTC)[reply]

No, there is no need to revisit auto-formatting, for the reasons that were given when it was discontinued, but we should recognise that is some countries, such as the UK and India, either 8 February 1852 or February 8, 1852 is perfectly acceptable, with the addition of "th" to "8" also acceptable. Phil Bridger (talk) 20:24, 15 May 2024 (UTC)[reply]

Given that the Chinese Wikipedia manages to allow people to switch between different varieties of Chinese with a single click, I have always found it a bit embarrassing that we can't even offer date formatting choices. A date autoformatter would need to be more powerful than the old one, though, and would need to be able to deal with date ranges (the old one could only do full dates). —Kusma (talk) 20:47, 15 May 2024 (UTC)[reply]

I certainly see no harm in developing a tool that allows readers to choose a display for their own purposes. Starting with that functionality and getting it working reliably and consistently would likely be a useful first step towards implementing something broader.

Rather than/as well as inferring things that look like dates in prose and marking things that aren't, having something like "Bob Smith ({{date|1852|February|8}} – {{date|1921|August|8}}) was a British politician. He served as Chancellor of the Exchequer from {{date|1890|March|1890}} to {{date|April|1894}}. He was president of the Imperial Society {{date range|1899|-|1908|April}}" a la semantic HTML may prove useful more broadly. Thryduulf (talk) 12:59, 16 May 2024 (UTC)[reply]

I don't think this would work for "readers". See Read a preferences setting, for logged in users. The average reader does not have prefs settings.

If I were going to mess with dates, it would be to specify in WP:BADDATE that unambiguous year–month combinations (e.g., 2024-05, which never means "this year through nineteen years in the past) are acceptable, and that it is concerned solely with what readers see, and definitely does not restrict the input for templates such as the CS1 citation templates.

In other words, people shouldn't be manually replacing the ISO-approved "2024-05" to "May 2024" in citation templates, because the citation templates should detect the unambiguous dates and treat them exactly the same way they already convert the display of "2024-05-01" to "1 May 2024" or "May 1, 2024" (the choice is made automagically, based on the specified ENGVAR for the page). WhatamIdoing (talk) 23:34, 17 May 2024 (UTC)[reply]

The average reader does not have prefs settings. Easy, default to converting to mdy. I also don't see how "2024-05" is relevant here. Aaron Liu (talk) 00:43, 18 May 2024 (UTC)[reply]

The problem to be solved is: "An end to the need to keep re-re-re-normalizing dates (manually or by script) in an article back to the format specified in {{use xxx dates}}."

Most of the dates that need to be re-re-re-normalized are in the citations (not in the words of the article). See Category:CS1 maint: date format for the current list.

This problem could be solved by changing a bit of code in the citation templates. To be clear: nearly every article that appears in this category, or that has been in this category during the last few years, could have been prevented from appearing there by changing the citation template's code.

The reason this change was rejected is because the maintainers of that code believe that MOS:BADDATE disallows editors from putting unambiguous, ISO 8601-compliant numeric year–month combinations in wikitext, even when the numeric form of the date would never be shown to a single reader. That is, they believe that the MOS will allow editors to type |date=2024-05-01 in a citation template, so they can show "May 1, 2024" to readers (if the article is tagged as mdy), but that the MOS does not allow editors to type |date=2024-05 and have "May 2024" shown to readers.

If you want to end "re-re-re-normalizing dates (manually or by script) in an article back to the format specified in {{use xxx dates}}, I suggest that you start with the problem that could be solved in two edits: a single edit to the MOS page, to officially reassure the template maintainers that it's 'legal', and a single to the citation template's main module, to implement the code (which AIUI already exists). WhatamIdoing (talk) 06:36, 18 May 2024 (UTC)[reply]

Well, that change would probably be put in tandem with this one, but only if this (automatic date conversion) is developed and passed. Aaron Liu (talk) 00:59, 19 May 2024 (UTC)[reply]

I don't think that solving the citation problem needs to wait for solving the other problem. WhatamIdoing (talk) 04:37, 19 May 2024 (UTC)[reply]

I don't think we should explicitly allow "2024-05" as a "good " date format. There could be an RfC about this small issue, though. Aaron Liu (talk) 13:04, 19 May 2024 (UTC)[reply]

Why not? It's an officially accepted international standard. It cannot be confused with a date range. So why not use it? WhatamIdoing (talk) 19:31, 20 May 2024 (UTC)[reply]

Huh, TIL ISO 8601 actually explicitly allows it. Aaron Liu (talk) 20:30, 20 May 2024 (UTC)[reply]

2024-05 cannot be confused with a date range, but 2004-05 can. That's why we disallow it. Headbomb {t · c · p · b} 09:44, 22 May 2024 (UTC)[reply]

But we could allow the format for anything can't be confused that way (e.g., the years 1912 to 1999 and 2012 to 2099 + year–month combinations that can't be a range of years, such as 2010–09). I think the whole thing could be evaluated in a single line of regex. WhatamIdoing (talk) 05:48, 25 May 2024 (UTC)[reply]

No, we really shouldn't, because as soon as you have a new date, you have to re-evaluate if the old date format is allowable or needs to be converted to something new, or have inconsistent date formats in an article, e.g.

Headbomb {t · c · p · b} 12:28, 2 June 2024 (UTC)[reply]

Allowing it would reduce that problem. We would go from today:

2009-01 produces a red error message that will have to be fixed by hand
2009-08 produces a red error message that will have to be fixed by hand
2009-23 produces a red error message that will have to be fixed by hand

to

2009-01 automagically gets displayed as January 2009, which means the article has consistent date formats
2009-08 automagically gets displayed as August 2009, which means the article has consistent date formats
2009-23 produces a red error message that will have to be fixed by hand

I'd rather have two automatically fixed than three broken. WhatamIdoing (talk) 00:24, 4 June 2024 (UTC)[reply]

I'm a bit leery of this step: Use a bot to replace all the non-excluded dates in the code with a single canonical format (probably ISO). Wouldn't this entail making edits to every article on the project that contains a date of the format "11 November 1919" or "January 1, 1970"? Do we have any idea what the scope of that effort might be? I would expect at least a few hundred thousand articles, which people with large watchlists might get pretty annoyed about. Folly Mox (talk) 21:26, 18 May 2024 (UTC)[reply]

I also agree that that step is probably unnecessary. They're gonna get converted anyway. Aaron Liu (talk) 00:52, 19 May 2024 (UTC)[reply]

For something like this, we need a special way to hide these edits from watchlists (something that will not hide other edits), where editors who do want to see them need to opt in and swear an oath that they won't complain about seeing these edits. We should solve the problem of annoying people with large watchlists, but we should not let this issue prevent large-scale improvements. —Kusma (talk) 08:56, 22 May 2024 (UTC)[reply]

But why would we want to replace all the dates in the first place? Aaron Liu (talk) 11:27, 22 May 2024 (UTC)[reply]

If we don't need to, that is fine. Currently there are people with scripts who annoy me greatly by replacing my beautiful ISO dates in citation templates with mdy or dmy although they are already displayed like that via {{use dmy dates}}. So apparently some people think we need to replace all dates. —Kusma (talk) 11:34, 22 May 2024 (UTC)[reply]

I agree, that is annoying. But the better solution would probably be to filter out edits that only change date formats. Aaron Liu (talk) 11:41, 22 May 2024 (UTC)[reply]

FYI, a {{#dateformat:}} magic word already exists to apply the preference. I don't think the preference is directly accessible in Lua, but you could use frame:callParserFunction{ name = '#dateformat', args = { date } } to format dates according to the preference. Anomie ⚔ 12:11, 19 May 2024 (UTC)[reply]

I'm very supportive of this entire proposal except for using a bot to update dates in articles (or any other changes to how dates should be entered in the source / editor behaviour). Today we accept any date format in citation templates and have them display in the proper format without any extra work from the editor; this works well today and it doesn't seem to cause any problems of having the article display dates in a different format (the article's "correct" format, in the future also a user preference) than what's entered in the source. This proposal would extend the functionality to any date in a "sane" format within the article body, without the need for any edits to the article content or any changes to editor behaviour. I also think the "Ignore" bit would take some work to minimize unintentional date reformatting (extending the proposed ignore logic to try to catch as many reasonable scenarios as possible where a date might be in a title or quotation). I would generally oppose any changes that require change to editor behaviour or bot edits (e.g. having dates structured in the source in a non-editor friendly format like {{date|1852|February|8}}). Consigned (talk) 08:19, 5 June 2024 (UTC)[reply]

Who are these people who either don't understand or get seriously offended by dates, with the month being non-numeric, in the "wrong" format? I certainly haven't come across any. Phil Bridger (talk) 08:39, 5 June 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

Not every request-reviewer is that lazy. Quite a bit will engage in discussion. Aaron Liu (talk) 23:29, 21 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

Great. Then those articles would not turn off the edit request facility. Hence "optional". ―Mandruss ☎ 04:30, 25 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

I still don't see why editors being already available is a problem. Aaron Liu (talk) 11:29, 24 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Sorry, I can't stand Trump. Anomie ⚔ 00:49, 7 June 2024 (UTC)[reply]

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)[reply]

That's the general gist I saw when I was I patrolled edit requests. ScottishFinnishRadish (talk) 14:45, 7 June 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

What you call waste, we call extremely effective redundancy. Aaron Liu (talk) 18:48, 7 June 2024 (UTC)[reply]

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)[reply]

idea for a new resource; "Town Hall"

I would like to suggest a new type of resource here for discussions. It would be called a "Town Hall." The purpose would be a place where wikipedians for various communities could have group discussions, centered on a particular field, i.e. based on topic.

One main idea is that there would be various town halls centered around groups of active WikiProjects, based on their general topical category.
- Would also include any other groups of wikipedians who edit various topics, as a group.
- E.g. one town hall would be all wikipedians who work on wikiprojects focused on science. and another for all based around history. and another for all wikiprojects centered on specific places such as cities, countries, etc.
a wikiproject would add the relevant Town Hall to their own page, by adding a new tab to their own tab header, where that Town Hall would be transcluded.

Ok so what do you think of that? Open to feedback. Thanks! Sm8900 (talk) 15:17, 23 May 2024 (UTC)[reply]

Comments on "Town Hall" idea

I like the idea. Would it be for Wikipedia-related discussion or topic-focused discussion? Cocobb8 (💬 talk • ✏️ contribs) 15:29, 23 May 2024 (UTC)[reply]

it would be mainly topic-focused discussion, but it would be as it relates to new efforts to add new entries to wikipedia, or refine existing entries, but the discussion itself would have a very broad scope and latitude, within the topic itself of course. and thanks for your reply!

Sm8900 (talk) 15:31, 23 May 2024 (UTC)[reply]

I think this a great proposition because rn most discussion places have to be Wikipedia-related Cocobb8 (💬 talk • ✏️ contribs) 15:37, 23 May 2024 (UTC)[reply]

We already have larger and more encompassing wikiprojects like Science, and many projects have task forces. I don't see the need, which will also require some infrastructure in guidelines. Aaron Liu (talk) 15:39, 23 May 2024 (UTC)[reply]

I think the point that Sm8900 is making is that it would allow for discussion on the topic to happen, scuh that it wouldn't need to be related on specific articles to improve, Cocobb8 (💬 talk • ✏️ contribs) 15:41, 23 May 2024 (UTC)[reply]

I don't think any stretch beyond reference desks would be accepted, due to WP:NOTFORUM. Aaron Liu (talk) 15:43, 23 May 2024 (UTC)[reply]

Hmm good point. Cocobb8 (💬 talk • ✏️ contribs) 15:44, 23 May 2024 (UTC)[reply]

ok. any other comments? Sm8900 (talk) 16:30, 30 May 2024 (UTC)[reply]

Quantifying current consensus on LLM usage

Would User:Sohom Datta/LLM be a good description of current consensus in the area? Sohom (talk) 16:20, 23 May 2024 (UTC)[reply]

I don't think there is anything close to a consensus yet, although that description is something I would personally agree with. Chaotıċ Enby (talk · contribs) 16:27, 23 May 2024 (UTC)[reply]

Notified: Wikipedia:WikiProject AI Cleanup. Chaotıċ Enby (talk · contribs) 16:31, 23 May 2024 (UTC)[reply]

Your statement generically covers any content: all submitted content must be checked for accuracy, including references, and all submitted content that conflicts with policy can be removed. isaacl (talk) 17:19, 23 May 2024 (UTC)[reply]

Yes, definitely. I wanted to use it as a starting point to having a baseline policy/document on the usage of LLMs that we could point editors to. If there is a majority opinion/consensus that we need to do something stronger, I see that as a good outcome. Sohom (talk) 17:40, 23 May 2024 (UTC)[reply]

My suggestion for a base line policy on the use of LLMs on Wikipedia: “Don’t”. Blueboar (talk) 12:48, 24 May 2024 (UTC)[reply]

+1. Although Sohom's text is the closest formulation I've seen to what I think might be consensus. Levivich (talk) 14:09, 24 May 2024 (UTC)[reply]

Agreeing too. And yes, in terms of consensus Sohom's proposal is a baseline we should be able to start with. Chaotıċ Enby (talk · contribs) 14:13, 24 May 2024 (UTC)[reply]

Well, I agree with your comment in terms of creating new articles/new content. I'm less convinced that indirectly using LLMs to copyedit a paragraph is really that bad but I'm open to being proven wrong. Sohom (talk) 15:13, 24 May 2024 (UTC)[reply]

Yes, I mostly had content generation in mind, although LLMs can add a lot of puffery when "copyediting" so that's also a risk. Chaotıċ Enby (talk · contribs) 15:15, 24 May 2024 (UTC)[reply]

Yeah that's fair, I just saw the link you posted on the Discord (relevant link for peeps not on Discord) and I'm now less confident of that statement :) There are ways (anecdotally) of prompt injecting LLMs remove puffery, but I absolutely don't trust new editors to be using them. Sohom (talk) 15:29, 24 May 2024 (UTC)[reply]

It's a starting point for anything, though: Any X must be checked for accuracy, including references, and all X that conflicts with policy can be removed. isaacl (talk) 17:17, 24 May 2024 (UTC)[reply]

The text you've linked is identical to that of WP:LLMP, which I wrote over a year ago.

I started an RfC, in which a quite wide majority of commenters supported adopting it, and it was closed as "no consensus" for reasons that remain unclear; essentially, the closer arbitrarily chose to interpret a large amount of the support votes as being opposed to each other, in which case it would no longer have a majority. This has been extremely disheartening to me, and I have been intending to initiate a review of the close, but it's been several months, and I think the whole landscape has changed in the meantime. jp×g 🗯️ 12:39, 24 May 2024 (UTC)[reply]

It's not identical, it's not even similar. Sohom's text takes out the two major provisions of LLMP that most editors in that RFC objected to. From the LLMP RFC closure:

The primary objections from those opposing included concerns about mandatory disclosure and about the proposed ability to summarily remove suspect LLM content...There does seem to be an implied consensus for "Large language model output, if used on Wikipedia, must be manually checked for accuracy (including references it generates)" among those both favoring and opposing this wording but this was not stated explicitly enough by enough editors for me to formally find a consensus for it. Nothing in this close should be construed to suggest that current policies and guidelines do not apply to Large Language models, with a number of editors explicitly noting (especially among those opposing) that current policies and guidelines do apply.

Sohom's text omits the mandatory disclosure and summary removal provisions of the LLMP draft (that's how it differs). The first sentence of Sohom's text is the manual checking provision, and the second sentence of Sohom's text is the existing-PAGs-apply provision, both of which were suggested by the LLMP close as having implied consensus or at least significant support.

@Sohom: I wouldn't go so far as to say that is the "current consensus" as that's never been confirmed, but it certainly seems to match the prevailing views of editors, based on prior discussions (such as the LLMP RFC). Levivich (talk) 12:58, 24 May 2024 (UTC)[reply]

You are incorrect.

The proposal was supported by 44 people and opposed by 23, so almost a factor of two -- it was closed as "no consensus" under the completely arbitrary claim that half of the 44 supporters were actually opposed to it.

However, even if we play along with the idea that everyone who said e.g. "I support this as a half-measure for the thing I really want" was lying (?) and disregard their comments, the proposal was still favored by 52% of commenters, both a plurality and an absolute majority.

Furthermore:

jp×g 🗯️ 13:05, 24 May 2024 (UTC)[reply]

This is not the place to argue with the close of that RFC, jp. You're derailing this discussion, which is not about the close of that RFC, so I'm going to hat this now. Levivich (talk) 14:05, 24 May 2024 (UTC)[reply]

I reverted the hat, the discussion of the consensus established at the previous RfC is absolutely relevant to the topic of Quantifying current consensus on LLM usage Chaotıċ Enby (talk · contribs) 14:09, 24 May 2024 (UTC)[reply]

You were the one who brought up that close in the first place -- and to say something that was flatly incorrect (that "most editors objected to" it). Most editors did not object to it. If you're going to be clerking this section, how about you strike "most editors" from your comment, and I'll strike "identical" from mine? jp×g 🗯️ 21:38, 24 May 2024 (UTC)[reply]

I'm not going to pull out the "if it's disruptive they can be blocked for disruptive editing" line, but due to the lack of a firm consensus that is what I did recently when blocking for, largely, disruptive LLM use. There are tools in the toolbox now, but firmer consensus would be great.

In that recent situation I reverted multiple responses at WP:AN to close reviews that were clearly generated by chatGPT. Editor time is our most valuable resource, so making people argue with robots is disruptive on its face. ScottishFinnishRadish (talk) 14:14, 24 May 2024 (UTC)[reply]

In terms of article content, I don't understand why we need anything more than what we already have: "all submitted content must be checked for accuracy, including references, and all submitted content that conflicts with policy can be removed." If content is accurate, referenced, notable, neutral and compliant with copyright, etc. then we should be including it regardless of whether it was written by human or machine. Likewise if it isn't those things we should be removing it regardless of whether it was written by human or machine. Thryduulf (talk) 21:28, 24 May 2024 (UTC)[reply]

The issue that arises is that enormous amounts of shit can be created with little or no time. Investigating and addressing that requires a significant investment of editor time to remedy. Time we're already lacking. ScottishFinnishRadish (talk) 21:33, 24 May 2024 (UTC)[reply]

That's true of both humans and machines. If it's shit it doesn't matter whether it's human shit or machine shit, get rid of it. Thryduulf (talk) 21:36, 24 May 2024 (UTC)[reply]

The difference is that the average human typing speed is fifty words per minute, versus a thousand. jp×g 🗯️ 21:45, 24 May 2024 (UTC)[reply]

You can generate shit that's hard to easily detect infinitely faster training an LLM. The speed and scale at which large language models (LLMs) can produce content present unique challenges that surpass those associated with human-created content. While human editors certainly can and do produce inaccurate or low-quality material, the volume is naturally limited by human capacity. An LLM, however, can churn out vast quantities of text in a fraction of the time it would take a person. This means that even if only a small fraction of machine-generated content is problematic, the absolute number can quickly become overwhelming.

One major issue is the subtlety of errors in LLM-generated text. Machines can produce content that appears superficially accurate and well-referenced but may contain nuanced inaccuracies or fabrications that are not immediately obvious. These errors can be particularly insidious because they might be less apparent to casual readers or even experienced editors at a glance. The result is that detecting and correcting such content requires a disproportionate amount of editorial effort.

Moreover, the nature of machine-generated text often involves creating convincing but ultimately false narratives, sometimes interwoven with factual information. This can mislead readers and complicate the editorial process as it blurs the lines between fact and fiction. The effort required to meticulously verify every claim, cross-check references, and ensure neutrality becomes exponentially greater when dealing with a high volume of content.

In addition, there is the issue of copyright compliance. While human writers are generally aware of the need to respect intellectual property, LLMs may inadvertently generate content that closely mirrors existing copyrighted material, leading to potential legal issues. This requires an additional layer of scrutiny to ensure that machine-generated content does not violate copyright laws.

The editorial community is already stretched thin, and adding the burden of sifting through vast amounts of machine-generated content exacerbates the problem. Each piece of content, whether human or machine-generated, demands a thorough review to ensure accuracy, neutrality, and compliance with policies. However, the sheer speed and volume at which LLMs can produce text mean that editors could find themselves perpetually behind, struggling to keep up with the influx.

Additionally, the motivation behind content creation differs between humans and machines. While humans generally write with specific purposes, interests, or biases, machines generate content based on prompts and training data without intrinsic motivation or understanding. This can lead to the production of content that is contextually irrelevant, off-topic, or otherwise misaligned with editorial standards and community guidelines.

To address these challenges, it might be necessary to implement stricter pre-publication checks for machine-generated content, including more rigorous fact-checking protocols and automated tools to assist in the detection of subtle inaccuracies. Furthermore, encouraging transparency about the origins of content can help readers and editors apply the appropriate level of scrutiny.

In summary, while the core principles of content inclusion should remain consistent—accuracy, neutrality, notability, and compliance with copyright—the unique challenges posed by machine-generated content necessitate additional considerations. The editorial community must adapt its strategies and tools to effectively manage the influx and maintain the quality and integrity of published content. ScottishFinnishRadish (talk) 21:46, 24 May 2024 (UTC)[reply]

More shortly: humans and elephants poop the same thing, but you won't get rid of elephant poop by flushing it down the toilet. Chaotıċ Enby (talk · contribs) 21:54, 24 May 2024 (UTC)[reply]

You haven't seen my toilet! Levivich (talk) 22:36, 24 May 2024 (UTC)[reply]

And how is a policy against using LLM going to stop bad actors from flooding the encyclopedia with LLM-generated content? In the end, we will have to sort the bad contributions out, and we can deal with editors who make disruptive edits without having to figure out whether the edits are LLM-generated or human-generated. Donald Albury 00:09, 25 May 2024 (UTC)[reply]

And how is a policy against X going to prevent bad actors from doing X isn't a good argument.

The benefit of having a policy is that administrators could take action immediately upon recognizing LLM usage with significantly less opportunity cost than there is currently. ScottishFinnishRadish (talk) 00:18, 25 May 2024 (UTC)[reply]

The main issue is that there is (or at least was when I last looked a few months ago) no reliable way to detect LLM content - everything has significant rates of both false positives and false negatives. And anyway what we want is not to detect LLM content, but to detect bad content.

how is a policy against X going to prevent bad actors from doing X isn't a good argument why is it not a good argument? A policy that cannot achieve its aim is a bad policy. Thryduulf (talk) 00:26, 25 May 2024 (UTC)[reply]

WP:VANDALISM cannot achieve it's aim, so let's get rid of it? That's bonkers. We establish and enforce acceptable and unacceptable behavior all the time. ScottishFinnishRadish (talk) 00:37, 25 May 2024 (UTC)[reply]

And how do admins recognize that an editor is adding LLM-generated content? If the edits violate any of our policies or guidelines, we can deal with it. And if edits adding LLM-generated content do not violate any of our policies or guidelines, why should we care? Donald Albury 00:27, 25 May 2024 (UTC)[reply]

That depends, do you want to read 18.8 tomats long arguments between LLMs? Do you want to close those discussions, or are you fine with people just feeding discussions into chatgpt and asking it for a close? That's why we need to care.

As for recognizing it, it's pretty easy with a human brain. User talk:FailedMusician#LLM usage has an example of an admin (me) easily recognizing LLM written text. ScottishFinnishRadish (talk) 00:35, 25 May 2024 (UTC)[reply]

Looking at the linked thread, this feels like we should have a "LLM-generated text is not exempt from 'don't make up fake sources'" reminder somewhere... Chaotıċ Enby (talk · contribs) 00:44, 25 May 2024 (UTC)[reply]

That concerns me far less than using LLMs in internal project discussions. ScottishFinnishRadish (talk) 00:48, 25 May 2024 (UTC)[reply]

One doesn't prevent the other, but you're right that the latter is much more worrying indeed. Chaotıċ Enby (talk · contribs) 00:56, 25 May 2024 (UTC)[reply]

While some edits are definitely harder to detect and fall into a grey area, having a policy could at least help weed out the most egregious cases. LLM-generated content is often unsourced and way more editorializing than our standards, and this kind of policy could help deal with these mass additions more easily. Chaotıċ Enby (talk · contribs) 00:37, 25 May 2024 (UTC)[reply]

having a policy could at least help weed out the most egregious cases how?

LLM-generated content is often unsourced and way more editorializing than our standards often != always, but when it is unsourced and/or more editorialising than our standards we can source it, rewrite it or remove it under existing policy.

this kind of policy could help deal with these mass additions more easily how? Thryduulf (talk) 10:39, 25 May 2024 (UTC)[reply]

If users repeatedly add many paragraphs of unsourced, editorializing text that is clearly consistent with the use of keywords used by LLMs (see Wikipedia talk:WikiProject AI Cleanup#Some common AI-generated phrases), it could be good to have a policy allowing us to remove it rather than having to nitpick every single sentence. Chaotıċ Enby (talk · contribs) 11:04, 25 May 2024 (UTC)[reply]

If any user repeatedly adds many paragraphs of unsourced editorialising text that's a user problem that needs to be dealt with regardless of whether they're using an LLM or not. Thryduulf (talk) 11:26, 25 May 2024 (UTC)[reply]

Except that's what LLMs typically write. That's their default text output. Yes, some users might do it on their own, but LLMs make it so much easier and more frequent that we shouldn't ignore the correlation between the two. Chaotıċ Enby (talk · contribs) 11:48, 25 May 2024 (UTC)[reply]

The problem is the output, not the method.

If our current polices are adequate to resolve the problems with the output then adding new ones just for LLMs is a waste of time and effort better spent actually resolving the problems.

If our current policies are not adequate to resolve the problem, then we need to strengthen our existing policies for all methods not just LLMs. Doing otherwise would mean we can't fix them problem when the method isn't LLMs, which would obviously be harmful to the encyclopaedia. Thryduulf (talk) 11:56, 25 May 2024 (UTC)[reply]

The issue is that the method (LLMs) completely changes the scale of the problem, which means policies adequate at a smaller scale might not translate effectively at a larger scale, even if the output is superficially similar. While LLM ability to generate text is unlimited, volunteer time isn't, meaning we simply do not have the time to verify every single line of massive LLM outputs like our current policies will have us do. Chaotıċ Enby (talk · contribs) 12:04, 25 May 2024 (UTC)[reply]

Your argument only makes sense if you are claiming that large amounts of nonsense in the encyclopaedia is only a problem when it is written by an LLM. If that is not what you are claiming then the final paragraph of my previous comment applies. Thryduulf (talk) 12:08, 25 May 2024 (UTC)[reply]

No. I'm claiming that LLMs can add a much larger amount of nonsense than users can write organically. While you claim that Doing otherwise would mean we can't fix them problem when the method isn't LLMs, the fundamental difference is that the scale is completely different. LLMs can write more nonsense in a minute than users can in an hour. Chaotıċ Enby (talk · contribs) 12:11, 25 May 2024 (UTC)[reply]

None of that addresses my points. Either our current policies are adequate to handle it or they are not. In neither case do we need a policy specific to LLMs. Thryduulf (talk) 12:33, 25 May 2024 (UTC)[reply]

Our current policies are not adequate to handle it, so we need stronger policies, like, being allowed to remove paragraphs of unsourced, editorializing text on sight rather than having to argue every sentence of it. Whether these policies are LLM-specific or not, we still need them because of the disruption potential caused by LLMs. Chaotıċ Enby (talk · contribs) 12:57, 25 May 2024 (UTC)[reply]

Also, regarding the "often unsourced" part, the cases where the generated text isn't unsourced are often more concerning, as LLMs are known for creating spurious, plausible-sounding sources, or even citing unrelated sources that don't support the claims. Chaotıċ Enby (talk · contribs) 11:06, 25 May 2024 (UTC)[reply]

Again, adding sources that don't support the claim is a problem regardless of whether it's LLM-generated or not. Verifying whether sources actually support what they claim to is something we should be doing for all text added. Thryduulf (talk) 11:28, 25 May 2024 (UTC)[reply]

The issue is that users have already (more or less successfully) argued that they were exempt from the blame of adding fake sources if ChatGPT wrote them. This shouldn't be the case, and users should not get off the hook just because they used a LLM to generate fake sources instead of making them up themselves. Chaotıċ Enby (talk · contribs) 12:00, 25 May 2024 (UTC)[reply]

users have already (more or less successfully) argued that they were exempt from the blame of adding fake sources if ChatGPT wrote them^{[citation needed]}. Policy is already clear that everybody is responsible for the content of the edits they make. If what you claim is true then all we need is to point editors claiming that to the existing policy and noting that there is no exception for LLM-generated text. Once again the problem is the fake citations, not the method used to generate the fake citations. Thryduulf (talk) 12:11, 25 May 2024 (UTC)[reply]

See User talk:FailedMusician#LLM usage for an example, where some users argued that ChatGPT-hallucinated sources were not fully the responsibility of the user adding them, or less than made-up sources they wrote themselves. Chaotıċ Enby (talk · contribs) 12:27, 25 May 2024 (UTC)[reply]

No they are not claiming that at all - they are claiming that ChatGPT was not used to generate content. Regardless of whether that is true or not, nobody is arguing that they are not responsible for the content of the edits. Thryduulf (talk) 12:37, 25 May 2024 (UTC)[reply]

I linked to the highest talk page section for context, but other users later down the line claimed that if you truly believe that this wasn't the work of an LLM, this [...] means the block was even more justified and that adding fake citations is just a simple misunderstanding regarding an LLM (if I misinterpreted these comments, please tell me and I will retract this). Chaotıċ Enby (talk · contribs) 13:01, 25 May 2024 (UTC)[reply]

What we have there is a user that didn't know that ChatGPT can hallucinate references and a lot of argument about whether that is a suitable justification for an indefinite block. I'm still not seeing anybody claim that the editor inserting such sources is not responsible for them, just disputing whether someone should be indefinitely blocked for doing something they didn't know was wrong. Thryduulf (talk) 14:00, 25 May 2024 (UTC)[reply]

That's the issue. Whether a user knows or doesn't know that ChatGPT can hallucinate references, they are still responsible for checking that whatever they add is not made up, and not knowing about what they added should not exempt them from this responsibility. Chaotıċ Enby (talk · contribs) 14:18, 25 May 2024 (UTC)[reply]

And nobody is arguing anything different. A few years ago I saw something that claimed child pornography wasn't banned in one of the countries in the Middle East. The justification for this claim was that there was no law specifically banning child pornography. While technically true, the reason for this was because that country bans all pornography, so no specific law was needed. It's the same issue here - we don't need a specific rule against adding fake references using LLMs because we already have a rule against adding fake references. Thryduulf (talk) 14:27, 25 May 2024 (UTC)[reply]

Yes, that makes sense and I agree. I just feel like it would be helpful to have it spelled out that "ChatGPT wrote this" is not an exemption, but I agree that it does already fall under our current policies. Chaotıċ Enby (talk · contribs) 15:14, 25 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]
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)[reply]

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)[reply]

Worth the effort; there are many problems caused by the current guideline. North8000 (talk) 13:43, 4 June 2024 (UTC)[reply]

Talk page archives and RfCs

Hey, don't do that, you should know there was an important RfC 6 years ago on talk page archive page #7 of #14. The only one who remembers has retired from Wikipedia. There should be a way for perennially important consensus results to be permanently and easily visible on the main talk page. Easily accessible not just for those with a long memory or time to doom scroll talk archives. -- GreenC 18:08, 27 May 2024 (UTC)[reply]

There was very recently a discussion (archived at Wikipedia:Administrators' noticeboard/Archive362) about these "/Consensus" subpages listing key points, often decided in previous RfCs. It seems to be the closest to what you are looking for, if you wish to take a look at that discussion. Chaotıċ Enby (talk · contribs) 18:14, 27 May 2024 (UTC)[reply]

Apparantly there are only 7 of these, and they are controversial. I was thinking like the mechanism to notify of prior AfDs. This could include prior RfCs and prior RMs. That's all, nothing proscribing consensus, only notifying the location of formal consensus discussions, and maybe a brief summary of the result. -- GreenC 18:27, 27 May 2024 (UTC)[reply]

That could be a great improvement on that old "Current consensus" system indeed! Chaotıċ Enby (talk · contribs) 18:37, 27 May 2024 (UTC)[reply]

Templates already existing:

{{Old XfD multi}} for AfD and related deletion discussions.
{{Old moves}} for RMs.

Templates that might be useful:

{{Discussion interlink}} for RfC notification on top of talk page, using the |T=yes option. See also Category:Wikipedia requests for comment templates

I added a discussion interlink to the top of Talk:Elizabeth_Holmes, it's not very good or clear. This is not what the template was designed for. -- GreenC 19:21, 27 May 2024 (UTC)[reply]

FAQ, a similar system, has 574 results. Aaron Liu (talk) 16:24, 28 May 2024 (UTC)[reply]

User:Aaron Liu, FAQ could work. Although it looks easy to abuse: gaslighting non-existent or weak consensus. Looking at Talk:Shin_Bet/FAQ, consensus is described, but there is no link a consensus discussion(!) Checking the talk archives, there was never an RM for this question. Only a few talk page posts, but no clear consensus discussion. Recently I had 4 users tell me, forcibly, that there was established consensus end of story. I disagreed, started an extremely neutral RfC (black and white question this or that), they go so angry, they almost took me to ANI for "abusing the consensus process". After 30 days the RfC closed and my position prevailed, they lost. I guarantee you they would have used FAQ and "current consensus" to continue gaslighting their non-existent consensus. -- GreenC 18:10, 28 May 2024 (UTC)[reply]

The same thing can happen to any way of "pinning" consensus. Such gaslighting is very disruptive editing, and I believe the benefits outweigh the risks here. Aaron Liu (talk) 01:04, 29 May 2024 (UTC)[reply]

Also, there was, in fact, a requested move. I'll edit that FAQ entry to include relevant information. Aaron Liu (talk) 01:05, 29 May 2024 (UTC)[reply]

I don't see how notifying users of previous RfCs is the same. There is no interpretation of results, like you see in Talk:Shin_Bet/FAQ. They are qualitatively different things. -- GreenC 21:57, 29 May 2024 (UTC)[reply]

I don't see why one must include the entire RfC to inform on prior consensus. If something's misleading, overwrite it. Aaron Liu (talk) 22:28, 29 May 2024 (UTC)[reply]

Hmm.. check Talk:Jack_Schlossberg. Notice the list of previous AfD's listed at the top. It is generated by {{Old XfD multi}}. This is all, except for RfCs. It's a way for readers to find old consensus discussions in the archives. It's completely neutral and informative and in-line with other similar systems for AfDs and RMs. -- GreenC 00:18, 30 May 2024 (UTC)[reply]

I don't see how omitting a summary of rationale makes things more neutral or helpful. Aaron Liu (talk) 00:40, 30 May 2024 (UTC)[reply]

It's helpful because it removes the ability to gaslight users with fake consensus results like we see with the broken FAQ system at Talk:Shin Bet/FAQ. The proposed template {{Old RfCs}} would display the question and a link to the actual RfC result, so users can explore it directly, for themselves. Nobody should be describing the consensus, it's unnecessary and easily prejudiced. -- GreenC 05:23, 30 May 2024 (UTC)[reply]

As if you can’t just link and claim consensus or change the bolded AfD/RfC result to something you’d like. Disrupters gotta disrupt, and only blocks and sanctions may stop them. Aaron Liu (talk) 10:58, 30 May 2024 (UTC)[reply]

Also, results like userfy, keep and delete have clear meanings across all AfD contexts while these and Option 4 don’t. Aaron Liu (talk) 11:00, 30 May 2024 (UTC)[reply]

Now you're at the level of vandals, and obviously that is true for the entire site on every level with everything so we might as well shut Wikipedia down because it's hopeless. But there is a qualitative difference between a system like FAQ and {{Old RfCs}}, if you can't see it, I don't know what else to say. -- GreenC 14:41, 30 May 2024 (UTC)[reply]

I am indeed saying that an {{old AfD}} analogue does not provide any more protection. Your premise is that anyone can edit the FAQ to be absolutely wrong and mine is that anyone can edit the results to be absolutely wrong. Aaron Liu (talk) 15:02, 30 May 2024 (UTC)[reply]

Talk:Elizabeth_Holmes#RfC_list_(pinned) works fine, until we get a template like {{old RfC}}. You will notice it does one thing, and one thing only: link to previous RfCs. Thus, when someone uses the word "fraudster" in the article, one can simply revert with the comment "see talk page", and the person will know where to find the discussion. All this stuff about rephrasing the consensus results, indeed even creating consensus results, is nuts it will be a continuous source of trouble. -- GreenC 02:52, 3 June 2024 (UTC)[reply]

I think the /Consensus pages interpreted as binding policy exist on somewhat questionable procedural grounds, but the /FAQ pages are a very good idea, and ought to be used wherever appropriate, jp×g 🗯️ 21:37, 30 May 2024 (UTC)[reply]

What I've done is create a frequently asked questions page, and use {{FAQ}} to include it on the talk page. isaacl (talk) 21:29, 27 May 2024 (UTC)[reply]

there are only 7 of these - So far. Best way to prevent wide adoption of something: Avoid it because it isn't yet widely adopted. and they are controversial Show me something powerful and highly visible that isn't controversial. No good deed goes unpunished. that old "Current consensus" system, read time-tested.

Create something that functionally overlaps consensus lists (the lists cover RfCs and other consensuses), solve a nonexistent problem, I don't care, but I'm not letting go of my consensus list. And don't ask me to help maintain your new thing in parallel with it. ―Mandruss ☎ 08:45, 28 May 2024 (UTC)[reply]

Well... actually I do care, per every new thing should survive a rigorous application of the question: Is it really worth the added complexity? A principle that has been ignored far too long, resulting in the massive over-complexity that we have to live with every day (never mind the barrier to entry and the several-years-long learning curve). We have a strong tendency to focus on benefit and fail to fairly weigh it against cost. Lacking a concerted community effort to simplify the existing environment (good luck with that), this can only continue to get worse with time. ―Mandruss ☎ 02:04, 29 May 2024 (UTC)[reply]

By the by, RMs are nothing but a special kind of consensus, so there's no reason they couldn't be included in consensus lists.
9. Article title is: Reproductive habits of Wikipedia admins. (RM July 2024)
Fits quite nicely, actually. ―Mandruss ☎ 00:42, 30 May 2024 (UTC)[reply]

Aaron Liu (talk) 00:44, 30 May 2024 (UTC)[reply]

Inappropriate capitalization of links is making me claw the draperies

Executive summary: There are zillions of instances of "He then ate a Pork chop, and sang..." when it should be "He then ate a pork chop, and sang..." and it's slurvy and let's think if it's possible to do anything about it. I got an idea for a bot.

Detailed exposition:

So, there are very many instances where links are capitalized, or the first word of multi-word links are capitalized, when they shouldn't be. For example, a passage that should read "...he worked in legitimate theatre after that..." instead reads "...he worked in Legitimate theatre after that..." (emphasis added). So wrong. I'm sure it jars other readers than me. Very very common.

It's little better than if our material was peppered with constructions like "...there were twenty People on deck...". It looks slurvy and it is slurvy.

I'm confident that this mostly happens because the editor is copying from the title of a page and pasting it into running text and moving on. There's no way to stop that I guess.

I can imagine a fix for this -- a program, a bot. Writing code for that would be way above my pay grade, but the process I imagine would be something like this (if this is laughably wrong or simplistic, OK, but you can see where I'm going):

Go thru an article checking each link
- If it's the beginning of a sentence (preceded by a period and space(s) or a line break or whatever), skip it. Else
- If it's piped, skip it. Else
- If it's just one word, skip it (for now). Else
- If the first word is capitalized and the others not, you've got a potential positive.

So then

Go to the article that the link points to.
- If it's a redirect, go home (for now). Else
- Check for each instance of the article-title string in the text. And
- If it's not found (somewhat uncommon), go home. Else
- If it's at the beginning of a sentence, skip it. Else
- If the first word (perforce midsentence) is capitalized, go home. Else
- Check the next instance (if any). And when you reach the end
- Since you've gotten to the end without being sent home (non-zero instances of midsentence use, and they all have the first word uncapitalized), you've got a likely positive.

So uncapitalize the first word in the link in the original article.

I recognize that this would be checking a lot of links -- into the nine figures I'd guess. Not a billion I hope. I have no idea if that'd be a deal-killer. If it is, well just slap my butt and put me to bed and forget it I guess. Just an idea.

Still here? OK. Now... of course you're going to get some false positive. I can't think of any, but there must be some. In which case maybe the devs could do code magic. They're smart. If not, maybe that's a deal killer.

Altho, for every "Should be this" --> "should be this" errors you're going to have a hundreds of "Pork chop" --> "pork chop" corrections I would think. A net positive, at least by the numbers, altho "we're not going to have a bot that we know is going to generate some non-zero number of errors, period" would probably be the response. Anyway, I got this Off my chest. Herostratus (talk) 06:44, 28 May 2024 (UTC)[reply]

This idea sounds at least interesting enough to try it with a read-only bot that proposes a list of changes without making them. The main false positives might occur where the link is already incorrect, e.g. Ash Vale is near Ash where the second link should have been piped to Ash, Surrey but is still correctly capitalised. It may also be led astray by the occasional lead such as Cairns is named after some rock cairns. (it isn't; I made that up) but hopefully not too many. Certes (talk) 16:38, 28 May 2024 (UTC)[reply]

In the latter case, I think the title "Cairns" will likely also be found in later places in the article. From what I understand, it looks at whether there's at least one capitalized mid-sentence instance, not whether all mid-sentence instances are capitalized. Chaotic Enby (talk · contribs) 17:21, 28 May 2024 (UTC)[reply]

Fair enough. We can probably also exclude targets with {{Infobox settlement}} (or {{Infobox person}}, if k.d. lang and will.i.am aren't looking). Certes (talk) 17:31, 28 May 2024 (UTC)[reply]

Probably not a terrible idea to exclude targets with a taxobox or automatic taxobox (or the various other related templates like {{speciesbox}}), as well, since the binomial naming system requires initial-capitals on anything genus and above, as well as the generic part of a species' binomial name, subspecies' trinomial name, etc. AddWittyNameHere 08:12, 2 June 2024 (UTC)[reply]

Here are some other interesting cases that could make things easier or harder:

Acronyms. I would expect nearly any link beginning with two or more caps is intentionally that way, so the target probably would not need to be checked. Except "IPhone" is not correct and "iPhone" is not a unique situation.
Multi-word phrases. Building on the acronyms case, if there is any subsequent capital letter, maybe assume the first letter should also be capitalized? That immediately accepts "City, State" and a ton of proper nouns without having to parse any target pages.
{{lowercase title}}. Although this template is "only" used 24k times, checking for its presence (which should be even prior to the first sentence of content) catches 24k targets that are known with absolute certainty and need no further parsing or heuristics. It solves the iPhone case.
Prefixes. Lots of technical terms have tons of prefixes (non-English characters, numerals, English-spellings of Greek letters) that should be ignored, prior to the first English character that is actually the one that follows sentence-case. Therefore, they also are subject to the "copy-paste the article title" mistake. And many of those articles' pagenames make it even harder to automate. Example: the page Gamma-Hydroxybutyric acid is titled "gamma-Hydroxybutyric acid" but "gamma-hydroxybutyric acid" is how it should be used mid-sentence. But L-Glucose is "L-glucose" mid-sentence (and the "L" is set smallcaps) and 1-Bromobutane is "1-bromobutane" mid-sentence. Many of these also use the various title-formatting templates, so that could be a short-circuit to flag ones that really need human eyes.
All special titles. It would be useful if articles could declare their own non-obvious sentence-case styling. If (just thought about this as a seed for a different task) articles did that, we could always just obey them, and that includes forbidden special characters, italics, smallcaps, and other fun things.

I definitely don't think we need a perfect solution, but I'd want to be as conservative as possible (minimize false-positives) to make this potentially large task that affects many pages be more acceptable when watchlists start blowing up. DMacks (talk) 17:29, 28 May 2024 (UTC)[reply]

I think the biggest problem is going to be figuring out whether it's the start of the sentence. Some are easy enough: Pork Chop, otherwise known as Floyd Womack, ate a pork chop but others are really complicated: My shoping list includes 1. pork chop 2. flour 3. eggs 4. mushrooms. Detecting these things programmatically is very difficult in English.

@Herostratus, I suspect that most of these are being added in the visual editor. In 2013 or 2014, the Editing team's PM (a long-time Wikipedia admin) had to decide whether to default to incorrect capitalization in Pork chop or in porkchop Cash. Getting the capitalization right for BLPs won.

It's possible that what we should do is consider an inline tag that says ^{[capitalization?]}. It could be bot-applied under limited circumstances (e.g., less experienced editor, using the visual editor, article hasn't been edited for >30 minutes [to avoid an edit conflict]). Checking and fixing them could be an easy task for the Wikipedia:Newcomer homepage. WhatamIdoing (talk) 22:43, 1 June 2024 (UTC)[reply]

I'd rather have it default that any link after terminating punctuation will be ignored. Worst case is a false negative and nothing is corrected. Aaron Liu (talk) 23:20, 1 June 2024 (UTC)[reply]

False negatives aren't a big problem. We should accept that the solution can't be 100% automated and ensure that there are a negligible number of false positives which might bring calls to cancel the whole task. Certes (talk) 10:40, 2 June 2024 (UTC)[reply]

Wow thanks for the interest! OK, so first, yes, of course, test rollouts first. Second, to address some of the false positive issues-- many I think, tho far from all I'm sure, can be avoided by being as conservative as reasonably possible; some of the objections raised would not go thru cos the links are more than one word or it gets caught in one of the other nets. Yes links that start a sentence should not be checked, and also let's say anything with a character that is not in the Latin alphabet would be skipped (links with parenthesized disambiguation would have been thrown out anyway as these are very often piped except on disambig pages), and any links with a word other than the first capitalized, as suggested.

Zimmerman telegram... you'd have soooo many potential positives like that, but is that article going to have either no midsentence uses of "Zimmerman telegram", or, if any, all of them would be lowercase "zimmerman telegram"? Not many... but you are going to have an article with a link to say "Liederman effect" capitalized like that (which is the correct capitalization), but the person(s) who edited the Liederman effect article prefer "liederman effect" on grounds of parallelism with "low-voltage effect" etc. (or whatever), and use the title term once (or more) midsentence and always in lowercase. You'd think with AI there's be a way to figure out some solution to this, I don't know. Herostratus (talk) 22:01, 2 June 2024 (UTC)[reply]

Please don't use an AI, unless you want an external link to the Telegram account of someone called Zimmerman. Certes (talk) 22:19, 2 June 2024 (UTC)[reply]

I think that before attempting to code anything, it would be worth deciding what level of (active) errors we could tolerate from the bot/script/whatever. Does it need 95% accuracy? That might be acceptable if it's only tagging, but downcasing the wrong thing in one out of every 20 edits will not be accepted by a bot. WhatamIdoing (talk) 00:02, 3 June 2024 (UTC)[reply]

99.9+% I would say, if you're talking about corrections vs erroneous changes. Very very few changes of links from "This should be capitalized" changed to "this should be capitalized" would be acceptable I think. People watching an article where this is done will be plenty mad (also the bot will keep doing it I supppose). I think this'd be achievable by adding code to handle exceptions causing errors found during debugging? I haven't yet seen any of you come up with an example of a error (once you throw out links with non-Latin characters as suggested above).

I don't know about AI. I do know that I can open a free app and ask it for a picture of Susan Hayward in a bikini (don't crush shame) and boy howdy if it doesn't do it a couple minutes. It's smart. Maybe it can figure out stuff like that.

Absolutely run paper tests first, I assume that that's done with all bots. Maybe instead of a fix we just send a message to users on their talkpage as suggested above: "You capitalized the text for such-and-such link, we think that might be wrong, are you sure you intended that?" might be as far as we're willing to go. This is done for links to disambiguation pages and it's almost always correct. This might well be the most that is acceptable to the community (and that'd be after we'd shown like 99.9+% accuracy). This means that existing wrongly capitalized links would not be changed, which is big shame IMO, but that's life.

So... I'm actually seeing possible interest in this idea (by a few people, granted). Would it be reasonable to go on to a next step? Would that be to move it to the Proposals section of the Village Pump? Herostratus (talk) 21:51, 3 June 2024 (UTC)[reply]

AI uses a ton of resources for this task for which I have yet to see a false positive for.

So, bots usually test themselves on test.wikipedia first and then go through a trial run of a certain amount of edits. Aaron Liu (talk) 21:57, 3 June 2024 (UTC)[reply]

This sounds like a task for human supervised editing, like many typo fixing projects or disambiguation runs. I do not think it is suitable for bots. —Kusma (talk) 22:17, 3 June 2024 (UTC)[reply]

Initially, yes. If we find that 99.9+% of its suggested edits are good then we can consider automating later. Certes (talk) 23:30, 3 June 2024 (UTC)[reply]

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)[reply]

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)[reply]

I think it's a little ambiguous, too, which is why I'm asking. ;-) WhatamIdoing (talk) 20:14, 28 May 2024 (UTC)[reply]

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)[reply]

If we can figure out what it means, that might be helpful. WhatamIdoing (talk) 20:32, 28 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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))[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Yes. I don't care about length at all. Loki (talk) 13:44, 2 June 2024 (UTC)[reply]

Are you interested in the number of sources, or the percentage of sentences with inline citations? WhatamIdoing (talk) 18:05, 2 June 2024 (UTC)[reply]

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)[reply]

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)[reply]

In my opinion, that article isn't 'ready for mainspace' because it is unreferenced. Cremastra (talk) 00:51, 3 June 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

Guestbook/New Editors' Corner?

My proposal is to create a simple page in which new editors can say hi and other editors can greet them. It will introduce newcomers to our community and the concept of editing and communicating. I think being greeted and welcomed would create a warmer atmosphere and aid in editor retention. Korean Wikipedia has a space identical to my proposal Do you see any potential issues? What should the pagename be? From where should it be linked? Ca ^{talk to me!} 14:28, 29 May 2024 (UTC)[reply]

Are you familiar with the Wikipedia:Tea Room? I'm not active there but my first impression is that covers much of what you propose. Thryduulf (talk) 15:20, 29 May 2024 (UTC)[reply]

Regarding the place where to put a link to any greeting space, each newcomer has access to Special:Homepage as their first step while onboarding. Trizek_(WMF) (talk) 15:24, 29 May 2024 (UTC)[reply]

WP:TEAHOUSE is more for answering questions from new editors. What I am thinking of is a space for new editors to introduce themselves or just say hi. Ca ^{talk to me!} 15:25, 29 May 2024 (UTC)[reply]

I totally support this idea. Sm8900 (talk) 16:29, 30 May 2024 (UTC)[reply]

I would also support this. Cocobb8 (💬 talk • ✏️ contribs) 20:01, 31 May 2024 (UTC)[reply]

The best way for new editors to introduce themselves is to start editing. They can introduce themselves on their user pages, in case anyone cares. E Eng 20:49, 31 May 2024 (UTC)[reply]

Copyleft trolling -- taking the temperature in the room

Years ago, there was someone who paid low-wage workers to create a ton of stock photos. He released them all with a free license, then scoured the internet for anyone who used those images and sued them indiscriminately for even trivial violations. This practice is called "copyleft trolling", taking advantage of the "please use this!" signal that free licenses send and then exploiting it. It has been strongly condemned by Creative Commons itself (here and elsewhere) and various free culture advocates (Cory Doctorow has written about it several times, for example, referring to it as "a new breed of superpredator"). Flickr changed their community policies in response to the behavior, requiring users who opt for a CC license to give people the opportunity to fix the problem before suing them. In short, it's widely viewed as antithetical to free culture principles.

Over on Commons, that user's files were deleted. It was no great loss because the quality wasn't all that high to begin with. Sometime later it happened again, but with someone's personal concert photography. In that case, as the quality of the photo was higher, Commons settled on "forced watermarking" as an intervention that would let us keep good quality free media while doing all we can to ensure reusers know the terms and the risk involved with making a mistake. You can see an example at File:Lukas Nelson.jpg. I don't know how we settled on that precise wording of the watermark, but in hindsight it should probably be changed to be a bit clearer and less pointed. Of course, these files can still be displayed on Wikipedia without the watermark using {{CSS image crop}}, but when you go to download the image or view it at full size it's intrusive by design. The idea is to make someone either use the image with correct attribution intact or manually crop an image that ensures they see the correct attribution that will avoid them getting sued.

It's happening again, and this time with one of our most accomplished and celebrated wikiphotographers, whose images are widely used on enwiki and elsewhere on the internet (long threads here, here, and here). They have been clear that they have contracted with Pixsy (the company most closely associated with copyleft trolling) and will insist on payment from even independent/small-time/non-profit media users, even if they agree to fix the issue and there was no real damage done. It's perhaps the case with the most potential for harm for people who rely on us for free content, but also the case with the most valuable images.

There are ongoing debates on Commons over what to do, and forced watermarking is back on the table. If it happens, enwiki will have a decision to make: stop using the images altogether (not likely), replace all syntax with {{CSS image crop}} (on about 1500 pages), or host a watermark-free local version (ignoring the risk for reusers in order to avoid the hassle of the CSS image crop template). If forced watermarking doesn't happen on Commons, enwiki has a different decision to make about whether it's ok with people building a business demanding money from the wide range of people who depend on our content but make a mistake in using it (whether a major mistake or trivial mistake).

Another way to frame this discussion is: where does the English Wikipedia community stand on using our projects for "copyleft trolling"?

There are a lot of strong opinions over on Commons ranging from "delete all the files and ban the user" to "anyone who messes up attribution deserves to be sued" (though most are somewhere in between). I'm hoping this section won't turn into a splintered conversation between the same folks so we can better understand the English Wikipedia's take on what we've been discussing on Commons. — Rhododendrites ^talk \\ 15:07, 29 May 2024 (UTC)[reply]

Genuine question, why isn't the usual attribution on Commons considered enough for these specific authors, like it is for everyone else? I don't see why they should be able to say "nope, I don't like this attribution, I want a watermark on the file". Otherwise, no, I don't believe it's productive to host images whose main purpose is to make money by suing people who re-use them. Chaotic Enby (talk · contribs) 17:22, 29 May 2024 (UTC)[reply]

What's the usual attribution, though? Technically the CC licenses typically require (a) appropriate credit (which can include the name of the creator/attribution parties, a copyright notice, a license notice, a disclaimer notice, and a link to the material), (b) a link to the license itself, and (c) must indicate if any changes were made. If it's a sharealike license and you produce a derivative work with it, you must also release the resulting work with the same license.
Most of us who use the licenses just don't care that every detail is satisfied because we, you know, want people to use the work. That's why we use a free license. Now, I'm not a professional photographer (although my images are used enough that copyleft trolling would probably be pretty lucrative), but when someone says "By Rhododendrites, via Wikimedia Commons" I don't care that they omitted the license.. because meh. When they just say "By Wikimedia Commons" I might send them an email to tell them to fix it to include the "by Rhododendrites" part (and they almost always do). But I would technically be within my rights to demand money for their error, even if just missing a little piece of it, and even if it's because I chose an intentionally overcomplicated attribution statement, and even if they offer to fix it, and even if it's just some kid who threw it up on their blog with 0 visitors. The question is what we want to do about it if someone abuses CC licenses in this way (which, again, CC itself condemns). — Rhododendrites ^talk \\ 17:33, 29 May 2024 (UTC)[reply]

By usual attribution, I mean the fact that the link to the image points to the usual Commons file description page with the license and attribution statement, as described in c:Commons:Credit line. As far as I know, this has usually been considered enough to comply with CC BY licenses. In this case, as the creator's required credit line Photo by Larry Philpot, www.soundstagephotography.com is already present in the file's description, I don't see why this is not considered enough and an additional watermark is needed. Chaotic Enby (talk · contribs) 17:40, 29 May 2024 (UTC)[reply]

Presumably the software used to identify violations is either not taking linking into consideration or, more likely, when people reuse content they find here on on Commons, they're not providing that link. To clarify, we're not talking about Wikipedia violating the license and creating watermarks to protect this encyclopedia. The watermarks are to protect everyone else who comes to Wikipedia/Wikimedia Commons knowing that this is a great place to find free content (WP:5P#3) and don't fully understand the complexities of what's technically required by the license. Wikipedia doesn't need to display a watermark, which is why I talk about using the CSS crop template to avoid displaying the watermark here. — Rhododendrites ^talk \\ 17:47, 29 May 2024 (UTC)[reply]

Thanks a lot for the clarification! I still believe it's quite a sleazy move from the user doing the "copyleft trolling", and very much not in the spirit of Creative Commons. Chaotic Enby (talk · contribs) 17:52, 29 May 2024 (UTC)[reply]

I think as you explained on the Commons village pump, the ultimate issue is that the options for dealing with failures in attribution are poor. Unless some billionaire decides to fund a organization to only pursue violations in a spirit-of-the-license manner, accounting for the legal savviness of the violators, unfortunately at present it may be best to advise Commons contributors that there is no cost-effective way to pursue violations selectively. isaacl (talk) 18:29, 29 May 2024 (UTC)[reply]

We learned in subsequent discussions that there is a stage in the process whereby the copyright owner could decide not to take action on the violations Pixsy flags. Diliff still pursues compensation when the violation wasn't a big deal because he feels it is owed to him for time spent determining that the violation wasn't a big deal. It was that which pushed me over to "the other side". At that point, where you're billing people for your own time spent investigating their violation, it has become the kind of business Creative Commons objects to (and, I would argue, we should, too). — Rhododendrites ^talk \\ 19:43, 29 May 2024 (UTC)[reply]

I'll qualify my earlier statement: any contributor who wishes to enforce the attribution requirements needs to consider the cost-to-benefit ratio, including the opportunity cost. I think trying to single out specific methods of enforcing licensing terms is in effect a backdoor way to try to add additional license conditions, but it's not very effective in limiting problems for re-users, since we can't enact any remedies that will help them. Watermarking is probably the best way to inform re-users of potential issues, but cropping them out on Wikipedia would work against this. It would both hide the attribution information, and seem to make it legitimate to do so. If the community can't agree on displaying watermarks, I think either a new license needs to be allowed that balances the concerns of professional photographers versus unaware, casual re-users, or Commons and English Wikipedia will just have to make do without contributions from photographers concerned about enforcing attribution. isaacl (talk) 21:51, 29 May 2024 (UTC)[reply]

a new license needs to be allowed that balances the concerns of professional photographers versus unaware, casual re-users – That's actually what CC BY 4.0 already does, as it gives people one month after a notice to fix the attribution. And that's why it is (and should be) encouraged compared to previous versions of the CC licenses. Chaotic Enby (talk · contribs) 22:36, 29 May 2024 (UTC)[reply]

CC4 doesn't do that. CC4 makes it so after you cough up your fee, your license is restored and, assuming you've fixed the violation, you can continue using it. Under older licenses even if you fixed it, the license was invalidated so you could be sued again. So CC4 doesn't stop this behavior, but does make it less lucrative in some situations. — Rhododendrites ^talk \\ 23:33, 29 May 2024 (UTC)[reply]

Thanks for the explanation! I knew it gave an opportunity to fix the violation, but didn't know the person was still liable for prior use. Chaotic Enby (talk · contribs) 23:58, 29 May 2024 (UTC)[reply]

Re after you cough up your fee: while you may still legally have to pay a fee for the violation, the restoration of rights if you fix the violation within 30 days is automatic as soon as you do so, whether or not you pay any fees. Anomie ⚔ 13:08, 1 June 2024 (UTC)[reply]

Sure, and commons:Commons:Village pump/Proposals#Feedback from Creative Commons covers the viewpoint that content licensed under version 4 is probably less likely to be a target for claims of copyright violation. But it doesn't prevent suing for damages that occurred prior to the violation being cured, so there remains an exposure for casual re-users and the potential for aggressive enforcement. There is good reason for the curing provision not to eliminate damages for prior harm, and so I can't see the Creative Commons licence getting rid of it in a future version. isaacl (talk) 23:39, 29 May 2024 (UTC)[reply]

I think Rhododendrites has misrepresented things a little here. Copyleft trolling is the deliberate creation of supposedly freely licenced images and then running a business collecting "fees" from people who don't follow the licence conditions perfectly. Diliff was an active Commoner and Wikipedian for many many years and uploaded 1500 world class images. Many English cathedrals and other historic buildings are illustrated to professional level thanks to Diliff. They are frequently lead images and featured pictures. Diliff was active on both projects reviewing images for featured picture and offered his expert knowledge to others trying to learn better techniques (myself included). Diliff uploaded his images not only to illustrate Wikipedia, but also on both Commons and Flickr with CC licences so others could use the images for free (though the Flickr licence was NC). He frequently got asked by people to reuse the images and if X was acceptable and were helped to do so. You can see such a query here just yesterday, where someone enjoyed being able to use Diliff's images for free for next to no effort and no cost.

What appears to have happened is Diliff got increasingly pissed off with companies using his images for free without attribution, including for example Apple. He enlisted the service of a controversial company, Pixy, that locates such misuse and demands a fee for unlicenced use of copyright images, which is indeed the case and legal. Unfortunately, Pixy's business model doesn't allow for forgiveness or for differentiating between small companies and large. I don't think Rhododendrites characterised Diliff's attitude correctly, as he has said that personally he would do so but (a) he doesn't have time/resources to do the work Pixy do and (b) he isn't given the choice by Pixy who need to get a return on their investigative work.

I think the general mood on Commons is that what Diliff is doing isn't acceptable and doesn't meet with CC's own recommendations that forgiveness and allowing users to fix up the attribution should be a priority and fees/fines left for egregious misuse. However, despite what Rhododendrites hinted above, about "on the table", neither deletion nor watermarking are anywhere near consensus levels of support.

I think we mostly are where we are because Wikipedia itself does not explicitly attribute in the way the CC licence demands. If you read a CC licence it requires something like "(c) David Iliff, CC BY-SA 3.0, Source" and none of that appears on Wikipedia. Users have to click on the image and then (for most) get a page where the licence reuse terms are only shown after further right clicks or clicking on download buttons etc. If the user simply left clicks on the big image to get the full size one, then they don't get any help on licence at all. Wikipedia has hidden the attribution behind a click, which legally is acceptable but practically isn't working 100% and isn't what nearly any reuser would do.

I assume the purpose of "idea lab" would be to figure out if we can come up with a good solution. Can we enhance the experience when a user clicks on one of Diliffs images so they are even more aware of the conditions attached to reuse. I wouldn't be opposed to such a page having a carefully worded warning that users of such images have been sued if the licence conditions are not met, for Diliff's works. But I don't think we should start defacing the image with a "watermark" or deleting them. -- Colin°^Talk 08:01, 30 May 2024 (UTC)[reply]

You may want to read the CC licenses again, they do not require a specific method of attribution. They merely require the method be "reasonable to the medium or means You are utilizing". The 4.0 license simplifies the language and explicitly states that a URI or hyperlink to a page providing the information is reasonable. Anomie ⚔ 11:38, 30 May 2024 (UTC)[reply]

I don't think he's alleged an actual violation by Wikipedia. I think he's pointing out that when we don't provide a "visible" credit line (e.g., in plain text in the caption of an image in an article), then it's not obvious to casual re-users that they might need to include a visible credit line. WhatamIdoing (talk) 19:04, 31 May 2024 (UTC)[reply]

In re Users have to click on the image and then (for most) get a page where the licence reuse terms are only shown after further right clicks or clicking on download buttons etc. If the user simply left clicks on the big image to get the full size one, then they don't get any help on licence at all.

In mw:MediaViewer, which is what most readers use to get the full size one, there is a proper credit line. For example, if you open today's Featured Picture at Commons in MediaViewer, underneath the image is the caption ("Interior of the Cathedral of Brasília.") and the credit line ("Donatas Dabravolskas - Own work"); on the other side is the "More details" button and the license ("CC BY-SA 4.0").

If by "they don't get any help", you mean that there's no tutorial about license requirements, then that's true, but all the information is there. Nobody in this discussion would need any further information to know what's required. WhatamIdoing (talk) 19:16, 31 May 2024 (UTC)[reply]

But there isn't a credit line where they see the image - in the article. There is nothing that tells them they need to give a credit when they use the image. There is nothing that tells them they need to know what the license is, not what "CC BY-SA 4.0" means. I suspect many people just click to get the larger version, then right click to save the image locally so they can use it. Obviously as experienced Wikimedians we understand what copyright is, what licenses are, that we need to know what license an image is released under, that there are (probably) conditions we need to comply with and that the license will tell us what they are. Not everybody does know that, and they don't even know that there is something they don't know. Thryduulf (talk) 19:36, 31 May 2024 (UTC)[reply]

It might not be a bad idea to put a copyright notice above the images in the File: namespace. Putting messages like that "above the fold" increases the chance that readers will see it. The Wordsmith^{Talk to me} 20:58, 31 May 2024 (UTC)[reply]

On Wikipedia, readers mostly don't see the File: page. On Commons, it's not up to us. WhatamIdoing (talk) 22:46, 1 June 2024 (UTC)[reply]

Most readers don't see it, but if they're looking to reuse images they're going to click on the image (which brings up the File: page) so they can get a better resolution and copy/save it from there. Putting a notice there gives them a better chance of seeing it. The Wordsmith^{Talk to me} 18:38, 2 June 2024 (UTC)[reply]

When readers click on the image, it doesn't bring up the File: page. It brings up the image (including credits and license information) in MediaViewer. WhatamIdoing (talk) 00:09, 3 June 2024 (UTC)[reply]

The Wordsmith, the behaviour you describe is similar to me and controlled by my Settings choices. I go straight to the Commons file page, which is fairly useless at helping re-users. If you read a Wikipedia page with a different browser or logged out you'll see what 99% of our readers see. Alternatively, try this link. The MediaViewer does the attribution explicitly per CC license terms (if the appropriate templates are used on the Commons page). It is good, but it doesn't explain to the reader that this is what they need to do to reuse this image, vs some random clutter on the page. I mean "CC BY-SA 4.0" looks like some sort of code. If that text appeared in the caption of every CC-licenced thumb, the reader would be left in no doubt that this is some kind of requirement. Showing it on mouse hover might also be acceptable (I know tablets and phones don't have this, but I suspect most people reusing the images are doing it on a computer).

If you right-click on the big image you do get a pop-up saying that you need to attribute this image and guidance for doing so. But if you left-click on the big image, it goes to the full size version and you are dealing with a JPG in your browser, not an HTML page, so no help at all. Since your cursor is a little magnifying glass, the temptation to left click and zoom in is high. -- Colin°^Talk 13:50, 3 June 2024 (UTC)[reply]

Got it, I have MediaViewer disabled so I forgot it exists. I definitely think there's room to change that text to better explain the copyright terms. The Wordsmith^{Talk to me} 19:11, 3 June 2024 (UTC)[reply]

I think that the root of the problem is that the English Wikipedia's piss-poor image attribution practices somehow manage to combine the worst possible aspects of every approach to create a user-hostile experience AND provide insufficient attribution. That is to say:

On one hand, it's far too onerous. Every image in every article is a hyperlink that takes you away from the current page -- often including icons and interface elements! -- this is horrible for usability.
On the other hand, it's nowhere near onerous enough, as it doesn't really give attribution to the photographer/artist/etc -- the page itself is totally verboten to give any textual credit, and something as simple as their name is hidden behind a hyperlink... the very same hyperlinks that are annoying and disruptive to click on and everyone learns to avoid doing that. This gets far worse if somebody, say, mirrors the page or prints it out or reuses the image somewhere else -- they probably don't even realize there is a photographer. Before I became an involved Wikipedia editor I just figured that they had all come from some kind of public-domain catalog, or were taken by paid employees of the WMF, or were fair use stock photos or something.

There are other Wikipedias that provide the photographer's name in the thumbnail next to a photo, and it's completely normal and unobtrusive (almost every major website does this already, and you don't see anybody saying that it makes the Washington post look unprofessional).

I think that we should probably lead by example and stop hosing all the photographers who give their images out for free. jp×g 🗯️ 11:58, 30 May 2024 (UTC)[reply]

Generally endorse all of this. There are a wide variety of ways that attribution could be better integrated into Wikipedia itself. But that would require some combination of consensus to highlight dreaded "authors" in articles or improvements to the interface that volunteers can't realistic expect to execute. But yeah if we could resolve all that, clunky kludges like forced watermarking wouldn't be necessary (and, I'd add, could easily be undone should these improvements come along). — Rhododendrites ^talk \\ 12:51, 30 May 2024 (UTC)[reply]

@Colin: Copyleft trolling is the deliberate creation of supposedly freely licenced images and then running a business collecting "fees" from people who don't follow the licence conditions perfectly - It's defined by the enforcement, not the creation. Someone who creates images in order to collect fees is indistinguishable in effect from someone who creates images and then collects fees.

Pixy's business model doesn't allow for forgiveness or for differentiating between small companies and large. I don't think Rhododendrites characterised Diliff's attitude correctly, as he has said that personally he would do so but (a) he doesn't have time/resources to do the work Pixy do and (b) he isn't given the choice by Pixy who need to get a return on their investigative work. - I think one of us misunderstands something about Pixsy. When I was looking for information about the site, what I saw was that Pixsy doesn't take action without the rights holder's go-ahead. i.e. there is a point where one could intervene. The way I interpreted that, combined with what Diliff actually said was that [when he reviews the violation] even if he determines there was no real harm to his photography business, he still wants money from people who messed up attribution to make up for the time he spent determining there was no real harm to his photography business. (this is from multiple comments in the DR). If Pixsy doesn't actually give him that opportunity, or if Pixsy perhaps charges Diliff if he decides to pass, which would be surprising, then that changes my understanding of the situation a little without actually fixing anything as the effect on reusers is the same. — Rhododendrites ^talk \\ 12:42, 30 May 2024 (UTC)[reply]

I think you'll find law has a thing or two to say about intent rather than effect. Diliff's first comment on the DR was to deny being a "copyleft troll". Diliff's a bright chap. I think there is room for reasonable people to disagree on the definition, which isn't in any dictionary. All the evidence points to his body of CC work being created in good faith with the ongoing (just yesterday on his talk page) intention of allowing free use, subject to the terms of the licence. There is zero evidence of the opposite. Zero evidence of malicious intent. Zero evidence of setting a trap. Zero evidence of someone making a "minor" mistake. Zero evidence that anyone asked to pay is actually short of funds or using the image non-commercially. We know nothing about the person who complained at Commons other than that they fully admit to thinking the image was public domain and not giving licence conditions a moments thought. Why they might think a modern professional-level photo of a London landmark was public domain I don't really know.

I think there is room to interpret Diliff's comments in different ways. You could ask him. I read it more as an explanation of Pixsy's business model. He says "I do want to make it clear that I am sympathetic to those who have been inadvertently caught up in this due to accidental misuse, and that this is not, as Nosferattus implies, the actions of a heartless copyleft troll" and "I did feel the need to correct the assumption being made by many here that all reusers involving minor breaches are being 'extorted' for the initial asking figure as I don't believe that is the case."

I think we are giving way way too much weight to some random unknown person on the internet who's annoyed they messed up and wants revenge, and not enough to a user we actually know to be a generous free-content producer for many many years. I suspect the fact Pixsy's involved has led to the automatic assumption this is copyleft trolling, but Diliff's remarks suggest otherwise. Read the descriptions here. These are people who set out to create a mass of supposedly CC images and then demand high fees for "minor attribution errors". There's nothing at all in Doctorow's articles about him having sympathy for people who just steal photos off the internet because "If it's on the internet it is free" stupidity and lack of care about content creators. Are we overreacting because someone got butthurt when they got caught stealing one of Diliff's photos for commercial use without the slightest concern for licence conditions? No evidence at present to suggest otherwise. -- Colin°^Talk 13:34, 30 May 2024 (UTC)[reply]

That gets back to the ultimate problem to which I referred, regarding the available enforcement mechanisms being poor. From the re-user's perspective, the photographer's intent doesn't matter, just how enforcement of the licensing requirements is done. Changing English Wikipedia to provide attribution next to the images would at least provide a very prominent example of the attribution requirement being visibly met, thus making the need to do so more evident to re-users. (To avoid any discrepancy with user interface graphic elements, English Wikipedia could choose to only use public domain images for this purpose.) isaacl (talk) 15:18, 30 May 2024 (UTC)[reply]

On a side note, I disagree that the use of term "trolling" should be defined solely by enforcement. Not everyone who tries to enforce their license terms should be considered a troll, whose origins as an online term derives from its meaning in fishing. isaacl (talk) 15:25, 30 May 2024 (UTC)[reply]

Of course. I mean "by [manner of] enforcement". — Rhododendrites ^talk \\ 16:16, 30 May 2024 (UTC)[reply]

I don't think manner of enforcement is a sole determinant, either, but as I said, it doesn't really matter to the re-users. isaacl (talk) 01:36, 31 May 2024 (UTC)[reply]

IMO both the apparent intent of putting the images up and also the nature and scope of enforcement should be relevant to Commons/Wikipedia's stance. North8000 (talk) 21:20, 31 May 2024 (UTC)[reply]

I don't think this has necessarily been presented neutrally, and I'm in favour of going after people who are commercially appropriating CC-licensed work without adhering to the terms of the license. At the same time, I think we're within the licensing requirements - I guess the question is whether we make it easier for users to understand what is CC-licensed. I generally like the idea of including attribution in-line in the article itself. SportingFlyer T·C 02:50, 1 June 2024 (UTC)[reply]
- Indeed not neutral, and not intended to be (this isn't a proposal, after all). But [again] this has nothing to do with whether Wikipedia is within the licensing requirements. This is about the reality that these licenses are poorly understood by the public and our "use our media!" messaging has been so successful that people assume they can just use it. A few users have decided to build a business on that misunderstanding -- a business model which both Flickr and Creative Commons itself have condemned and taken steps to curb. What I've said thus far is that we should be thinking about two things (a) design changes to avoid these misunderstandings, but (b) thinking about what to do about users who adopt this model of enforcement, without taking for granted that we will be successful in implementing any significant design changes (which is not something we're reliable for). Colin disputes whether Diliff should be considered a copyleft troll in particular. I'll disagree and say that anyone using automated means to demand money from small-time reusers, without providing any opportunities to fix the problem and demanding money even after determining damages are little-to-none, should qualify for use of that term, but we don't need to decide about Diliff here. I opened this thread to talk about the different options available and to see how enwiki views the more ... unorthodox approaches like "forced watermarking" (whether or not it happens for Diliff, and that does very much remain to be seen, it has already happened for Philpot and many users seem to consider it on the table for this sort of scenario). Ideally we can come to better design solutions to avoid licensing errors to begin with, but until we get there we need to deal with the problems as they arise. — Rhododendrites ^talk \\ 04:03, 1 June 2024 (UTC)[reply]
I see a few people above suggesting the idea of inline image credits in articles. If some of you think you want to turn that into an actual proposal, I'd encourage you to address the points listed at WP:Perennial proposals#Add in-article credit for images, particularly the points about whether there's evidence that doing this would actually make an impact on people copying images without correct attribution (not just your hopes that it would), whether it would incentivize people to spam their images into articles to get their name in them, and whether the CC-BY 3.0 and earlier's requirement that credit be "at least as prominent as the credits for the other contributing authors" would be problematic for icons using those licenses if we make the standard credit for illustrative images more prominent. Anomie ⚔ 12:50, 1 June 2024 (UTC)[reply]

So what level of enforcement is acceptable

There are many many sites out there using my stuff without attribution. So which of these people if any would people say its acceptable for me to send legal threats to:

conferences-uk Seems to be a commercial site using my image with no credit of any kind nor mention of CC-BY-SA
organrecitals.uk same image seems to be a one man fan site no credit of any kind nor mention of CC-BY-SA
4coffshore.com some kind of consulting firm using this image no credit of any kind nor mention of CC-BY-SA
plymouth.ac.uk University on the south coast of England. same image used as a header. no credit of any kind nor mention of CC-BY-SA
railfreight.com Some kind of trade publication. Gives credit but no mention of CC-BY-SA.

My take is that the problem isn't in contacting them, it's what you're saying to them. Are you trying to get them to fix the missing attribution and such, or are you going for big fees regardless of whether they fix it? I think https://creativecommons.org/license-enforcement/enforcement-principles/ that was linked at the start of the discussion is a good read. Note that doesn't mean you can't ask for money in any situation, just that it should be reasonable to the use.

I'd also expect little sympathy from general editors (versus other photographers) for "I need $X from every violator to compensate me for the time I spent searching for violations and sending letters" or "to compensate me for what I paid some company to do the searching and sending for me", or for "the company I hired does this, even though I sometimes try to reduce it in some cases". Anomie ⚔ 13:58, 1 June 2024 (UTC)[reply]

Well US statutory damages start at $750 a time so lets assume thats what is being asked for.©Geni (talk) 15:33, 1 June 2024 (UTC)[reply]

Going straight for statutory damages seems counter to the principles suggested in https://creativecommons.org/license-enforcement/enforcement-principles/ to me. Anomie ⚔ 16:50, 1 June 2024 (UTC)[reply]

Many of these people probably aren't specialists about the exact specifics of what attribution is needed, so maybe first you could contact them to ask them to fix it and tell them what attribution is needed? Going for legal threats directly sounds a bit too much for just forgetting to credit an image. Chaotic Enby (talk · contribs) 22:29, 1 June 2024 (UTC)[reply]

This was Flickr's approach when they modified their community guidelines (see "give some grace"). — Rhododendrites ^talk \\ 22:54, 1 June 2024 (UTC)[reply]

That puts us in the "CC-BY-SA means public domain outside the unlikely event that the photographer contacts you personally" position. Remember most of these images have no attribution at all so we aren't talking "exact specifics" here.©Geni (talk) 00:35, 2 June 2024 (UTC)[reply]

Well, sure, in that "CC BY-SA means public domain outside the unlikely event the photographer sues you personally" is also true. Both require that the copyright owner notices and does something about it; the difference is what they do. But you're right that figuring out how to draw the line is very difficult and will probably defy short definitions. I don't think we'll see Commons adopt the Flick approach of "you need to give them a chance to fix it" (maybe, but I'd be surprised). At minimum because we just host so much content imported from other sites where the copyright owner isn't involved. So any determination of "copyleft trolling" (or whatever we want to call it) is going to require a degree of evidence, pattern of behavior, and judgment of uninvolved parties like most other behavioral cases around here, From the past cases the things which, I think, have pushed people over the line in that judgment have been: commissioning a ton of low-quality work just to enforce licenses and using a very particular custom attribution line that includes a URL and suing people for omitting the entirety of that custom line. In the current case, for me anyway, it was learning that the copyright owner wants to charge people for the time he spends determining that their license mistake wasn't damaging. I should say, in case it's not evident by Colin's replies, that not everyone sees a problem with that (or doesn't see it as enough of a problem to intervene). — Rhododendrites ^talk \\ 16:39, 3 June 2024 (UTC)[reply]

I think is unfortunate that Rhododendrites focused on the "copyleft trolling" aspect rather than a neutral discussion of how we help our content re-users comply with the licence conditions. It taints things with the idea that those enforcing the licence conditions are bad people, and has let this discussion to focus too much on whether Diliff is a copyleft troll and has "decided to build a business on that misunderstanding" which is so exaggerated I am getting BLP concerns we might have to erase this conversation. -- Colin°^Talk 13:38, 3 June 2024 (UTC)[reply]

That was the framing in this section because that was the framing on Commons. Regardless of what you'd like to call it, this section (which didn't even directly mention Diliff to begin with) was to see what the enwiki community thinks about the various solutions that have been proposed, in part because you said at the DR that the enwiki community would reject the watermarking idea. It's not about how bad anyone is but how to protect reusers from people who, yes, build a business on people making licensing mistakes (that quote referred to a category of people doing so and didn't mention Diliff btw). After learning a bit more about Pixsy, I learned that they do nothing other than automate the collection of possible violations and sort them into a bunch of categories of websites for copyright owners to peruse. It's 100% up to the user to decide whom they want to initiate a case against. So that means Diliff is manually looking at these independent reusers and then, per his comments in the DR, making the affirmative decision to pursue damages even when there wasn't any real harm, in order to make money from the time he spends evaluating those cases. If that isn't explicitly contravening the enforcement principles set out by Creative Commons, I don't know what is. I don't know why you're trying to litigate the Diliff case here, though. — Rhododendrites ^talk \\ 16:10, 3 June 2024 (UTC)[reply]

Re

Unless some billionaire decides to fund a organization to only pursue violations in a spirit-of-the-license manner

Well I can think of one, if not a billionaire then a multi-millionaire at anyway: the Wikimedia Foundation, which takes in millions and millions of dollars more than it needs, could throw a roomful of good lawyers at anyone, and is a nonprofit public good with as much standing as anyone to sue or counter-sue.

The Foundation continues to have a huge income (for good or ill). It only costs us a fraction of our income to run the IT department, run a developer group, run a cubicle farm with people in suits doing accounting and all the other stuff a big nonprofit requires, run Wikimania, and do various other cost-effective interfacing with other organization and whatnot. And I mean not only do we not need to turn a profit, we can't. Can'td take it with us, so might as well spend it on something worthwhile. Experienced and profitable grift operation or on, adozen white-shoe lawyers being unleashed on you is hard to beat, or at least being a slam dunk to beat, so...

(I do get that there are various ah organizational issues that might prevent the Foundation from doing this, but also some encouraging markers... never know til you try I guess...)

I'm just saying, to anyone who knows how to get thru to important people in the Foundation and the political chops to make a good case... wouldn't this be a job for the Foundation? Herostratus (talk) 19:01, 2 June 2024 (UTC)[reply]

No. WhatamIdoing (talk) 00:12, 3 June 2024 (UTC)[reply]

This seems very very unlikely. I definitely can't see an organization with the ethos of Wikimedia being at all associated with suing someone for content enforcement. In theory, it might be nice if there were some automated process that contacted websites to say "hey it looks like you have an unattributed photo that came from commons -- can you fix that. the copyright owner could take legal action if you don't fyi" with no teeth behind it, but that doesn't seem remotely realistic to automate reliably and there's still a lot more we can do on the front-end much more cheaply to better communicate what reusers have to do. — Rhododendrites ^talk \\ 16:14, 3 June 2024 (UTC)[reply]

Wrt "I don't know why you're trying to litigate the Diliff case here, though", your opening post brought Diliff into the discussion with "It's happening again, and this time with one of our most accomplished and celebrated wikiphotographers,...." so your turned what could have been a neutral discussion into a posting that is trashing a Wikipedian's reputation and standing in our community.

I think there are two possible Wikipedia discussions. One is a neutral one about trying to improve things so that when people reuse CC images, they do so properly per the licence. I don't see how that discussion needs to involve Diliff or trolling or moral views. And that discussion might well belong on the idea lab. The second discussion would be if the Commons DR decided they would in fact delete or watermark all of Diliff's excellent photos (which right now seems as likely as the Tory party winning the general election). Then I think you'd need to go to the more public village pump, and ping all the relevant wiki projects, and personally I think a mob would go after you with pitchforks and flaming torches. That's the aspect I was most concerned about, because I don't think Wikipedians prioritise "free content project" the same way Commoners do. And also because Diliff is a human and I'm concerned about what news coverage might do. We both are disappointed in Diliff's actions here. -- Colin°^Talk 14:20, 5 June 2024 (UTC)[reply]

Why Wikipedia articles have no DOIs?

I was recently asked and I am not sure. Why don't we have them? Wikipedia:Digital Object Identifier does not answer this. (WikiJournals articles have them, but also many articles in academic encyclopedias do have them, ex. https://onlinelibrary.wiley.com/doi/full/10.1002/9781405165518.wbeos0736.pub2). Should we have DOIs for our articles? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 06:04, 31 May 2024 (UTC)[reply]

Huh, I had a vague impression that a DOI was something higher and mightier. But is DOI stuff supposed to be as changeable as a WP-article? Gråbergs Gråa Sång (talk) 11:59, 31 May 2024 (UTC)[reply]

@Gråbergs Gråa Sång Good question. Need more research, but this forum post suggests it should be fine. Better citation needed, sure :P _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 12:09, 31 May 2024 (UTC)[reply]

It costs money and I'm not sure it provides a great deal of benefit. Barnards.tar.gz (talk) 12:30, 31 May 2024 (UTC)[reply]

It would provide a magnitude more credibility to middle school papers.^{Main Author et. al (2024). "Village pump (idea lab)". A Wikimedia Project. doi:10.1234/enwiki.26740553.} CMD (talk) 12:57, 31 May 2024 (UTC)[reply]

In that case, Veto. Gråbergs Gråa Sång (talk) 13:06, 31 May 2024 (UTC)[reply]

We have RevIDs. Our articles get merged, deleted, revised, etc... which goes against the purpose of DOIs: to link to stable versions. Headbomb {t · c · p · b} 03:04, 2 June 2024 (UTC)[reply]

I think it would make sense to have DOIs that resolve to Special:Permalink/rev_id, so if someone has reason to reference a Wikipedia article, they would at least perforce be providing a link to the version they're quoting, but I'm not sure how DOIs interact with CC-BY-SA 4.x licensing. Folly Mox (talk) 12:26, 31 May 2024 (UTC)[reply]

The goal of a DOI is that you can always find the link, even if the periodical gets sold or the website gets rearranged. We don't really have that problem. A link to a revid will always find the page.

(I could imagine someone doing this for the specific revid at FA promotions. It would cost about US$2,000 in fees, and much more [the time needed to find/check each relevant revision].) WhatamIdoing (talk) 19:27, 31 May 2024 (UTC)[reply]

As in US$2,000 per article/instance? Gråbergs Gråa Sång (talk) 19:33, 31 May 2024 (UTC)[reply]

No. As in US$2,000 to get all of the existing FAs and FFAs listed, at an average cost of about twenty-five cents each. WhatamIdoing (talk) 21:59, 1 June 2024 (UTC)[reply]

Just noting that a, WMF has a ton of surplus funds (enough to give six digits to other NGOs doing stuff of no relevance to the community, see User:BilledMammal/2023 Wikimedia RfC) and b, according to this, "it is possible to get DOI without... paying a fee". I think getting DOIs for FAs, and possibly GA+ (i.e. articles that have passed semi-reasonable review process) would be a good idea. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 02:50, 2 June 2024 (UTC)[reply]

Zenodo’s scope is “research outputs” so it’s debatable whether encyclopaedia articles would qualify. But even if it were a completely free and open system, I’m not seeing a problem that it would solve. Barnards.tar.gz (talk) 08:05, 2 June 2024 (UTC)[reply]

DOIs make a source look more reliable/respectable. Making Wikipedia more reliable/respectable is good, no? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 11:52, 2 June 2024 (UTC)[reply]

Making Wikipedia more reliable/respectable is definitely a good thing. Making it look more reliable/respectable... not so much. Barnards.tar.gz (talk) 15:27, 2 June 2024 (UTC)[reply]

Yeah, that. WP:General disclaimer etc. Though pretty good in parts, we're a user generated wiki, to a significant extent open to any article-change whatsoever. Though I might enjoy it if a WP-text I mostly wrote has a DOI. What do you think, @Jenhawk777? Gråbergs Gråa Sång (talk) 17:34, 2 June 2024 (UTC)[reply]

I have no real opinion on this one way or the other. Jenhawk777 (talk) 23:00, 2 June 2024 (UTC)[reply]

Imagine the co-author list. I’ll change my mind if this proposal allows me to lower my Erdős number. Barnards.tar.gz (talk) 21:27, 3 June 2024 (UTC)[reply]

Exactly. Our links are stable. There's no need for DOIs. Case closed. Jason Quinn (talk) 20:36, 31 May 2024 (UTC)[reply]

Yes, it is. However, getting new DOI numbers is rather expensive, especially for a free project like us. NW1223<Howl at me•My hunts> 20:54, 1 June 2024 (UTC)[reply]

The expensive part is getting someone to do the work. WhatamIdoing (talk) 22:00, 1 June 2024 (UTC)[reply]

Specifically, someone would need to spend hours figuring out which version of the 8,000 FAs and FFAs is the correct link. For example, Schizophrenia is an FA. Do we use the original 2003 promotion, or the 2011 FAR keep?

Once we had the list of versions in hand, someone need to spend hours figuring out which metadata to report for that version.

Some of this is easy (titles, posted_date, acceptance_date [the same], institution, license, funding [i.e., none]). I don't know whether citation_list is desirable. I'm not sure what component_list is (Table of Contents? Or is that for abstract/tables/figures/appendices?).

The entry for contributors is possible, but it would take some doing. Clicking around with Wikipedia:Who Wrote That? tells me that Vaughan wrote 84.4% of the 2004 version, 213.253.39.xxx 4.1%, and Ram-Man 3.4%. For the 2011 version, Doc James wrote 19.7%, Vaugahn 13%, Casliber 6%, EverSince 5.3%, SandyGeorgia 4.3%, and a whole lot of people wrote tiny amounts (this is not systematic, so I could have missed important contributors).

The fees themselves are trivial. The costs are all in human time. WhatamIdoing (talk) 19:31, 2 June 2024 (UTC)[reply]

Better pipeline for anonymous AFD nomimations

Currently, if an anonymous editor wants to nominate an article for deletion, they have to make a request at WT:AFD. Sometimes it gets done promptly, sometimes slowly, and sometimes not at all. This also tends to flood this page with AFD requests instead of general talk about the main AFD page or specific AFD-related issues.

It might be good to have a more streamlined approach for this situation. Maybe a template that could be placed on the article's talk page that would place open requests onto a tracking page, like how edit requests are handled? Maybe just a dedicated subpage with a clear "yes", "no", or "more info needed" response to requests?

Thoughts? Suggestions? 35.139.154.158 (talk) 17:02, 2 June 2024 (UTC)[reply]

It sounds like you're asking for another page that would still work the same way: users post their nominations somewhere, and logged-in editors use that as a backlog. I don't see how either of your suggestions would make that more efficient. Toughpigs (talk) 17:24, 2 June 2024 (UTC)[reply]

I'm not sure "efficiency" is the full goal; if you've watchlisted the page interested in policy changes in the text of the page or development of new procedures but have no interest in helping with anonymous deletion requests (and I have zero idea how many people that describes), you're getting a lot of unhelpful notifications. Meanwhile, discussion topics are archived quicker than they might be otherwise because there is so much more traffic (example this attempt to suggest a new notification related to AfDs was on the talk page less than a month.) So the current situation is not ideal, but if we shuffled it off to its own tracking board, I'm not sure how many people would move over there to actually answer requests (he says, looking at the months of wait for a AfC.) -- Nat Gertler (talk) 18:53, 2 June 2024 (UTC)[reply]

I agree with Toughpigs. Plus, if you can't be bothered to read to find out how to do it in a way that even if you mess up someone'll notice it, I doubt that you have read deletion policies. Aaron Liu (talk) 17:41, 2 June 2024 (UTC)[reply]

Category:Wikipedians against censorship

I was going to create Category:Wikipedians against censorship but saw that it was removed during a long discuss in 2007. I think, the members of this project need to be placed in a separate category. This category can be connect to Template:User against censorship then, on users pages, "Wikipedians against censorship" is shown instead of "WikiProject Wikipedians against censorship participants". Same as "Wikipedian WikiFairies" or "Disabled Wikipedians".

In my opinion, the same idea should be implemented for "Biography Wikipedians" and "Human rights Wikipedians". Claggy (talk) 04:39, 3 June 2024 (UTC)[reply]

Category:WikiProject Wikipedians against censorship participants has existed since Category:Wikipedians against censorship was "selectively renamed and deleted" following Wikipedia:Categories for discussion/User/Archive/December 2007#Category:Wikipedians against censorship. It is possible consensus regarding categories for Wikipedians who like/dislike/support/oppose X has changed in 16½ years, but you haven't presented any arguments why it should. Thryduulf (talk) 11:37, 3 June 2024 (UTC)[reply]

The OP has been glocked. Liz ^{Read! Talk!} 02:56, 4 June 2024 (UTC)[reply]

That’s a great abbreviation Dronebogus (talk) 09:33, 4 June 2024 (UTC)[reply]

Having WMF pay for IRCCloud for all users who have a Wikimedia cloak

Before officially posting this to the WMF section of Village Pump, I'd first like to gather some feedback on this. What I would like to propose is that all users who have a Wikimedia cloak be given a paid subscription to IRCCloud by the WMF.

Why IRCCloud?

IRCCloud seems to be the best IRC client that works for all users. It does not require installation, as it works directly on any web browser. As such, it will work on MacOS, Windows, any Linux distro including ChromeOS (Chromebooks). IRCcloud also has iOS and Android apps.

Why a paid subscription?

A paid subscription to IRCCloud would give cloaked users the ability to stay connected to Libera chat server at all times even when they're offline, unlimited access to chat history, and priority support.

Given the WMF's stable economic state, this seems like a productive use of their money that would benefit users accross Wikimedia projects.

Thoughts?

Cheers, Cocobb8 (💬 talk • ✏️ contribs) 20:10, 3 June 2024 (UTC)[reply]

Would support this. Qcne (talk) 20:13, 3 June 2024 (UTC)[reply]

Even though I wouldn't use this - I have a client I regularly use already - I would support this. —Jéské Couriano v^_^v ^{threads critiques} 20:16, 3 June 2024 (UTC)[reply]

Before proposing this, I would recommend working out a ballpark figure for how much it would cost. Pricing seems to be £5 (+20% VAT) per user per month, but I haven't the foggiest how to find out how many people have a cloak. I haven't used IRC in years, but when I did I think I had a cloak - if they don't expire (again, I have no idea) then the raw figure will be too high as it's only worth spending money on people who are going to benefit (i.e. active users). Thryduulf (talk) 20:21, 3 June 2024 (UTC)[reply]

@Thryduulf It would totally depend on the amount of cloaked users of course (I also have no clue what the current number is)... But that's a good point though, maybe have something like "the subscription cancels after 3 months of inactivity on Libera chat (i.e. connection to)"? That way money wouldn't be spent unnecessaril. The good thing is, in order to obtain a cloak, users still need to be quite active on Wikimedia projects so it shouldn't be too much of an issue. Cocobb8 (💬 talk • ✏️ contribs) 20:27, 3 June 2024 (UTC)[reply]

Speaking as a GC, there are currently 802 cloaked users. (This includes Wikimedia-cloaked bots though too) stwalkerster (talk) 21:14, 3 June 2024 (UTC)[reply]

Another option would be to have this be on-request so that only those who are botk cloaked and active on IRCCloud for Wikimedia channels. Cocobb8 (💬 talk • ✏️ contribs) 14:22, 4 June 2024 (UTC)[reply]

What is a Wikipedia cloak? Phil Bridger (talk) 20:25, 3 June 2024 (UTC)[reply]

@Phil Bridger See https://meta.wikimedia.org/wiki/IRC/Cloaks Cocobb8 (💬 talk • ✏️ contribs) 20:26, 3 June 2024 (UTC)[reply]

It also auto-voices users in #wikipedia-en-help. Cocobb8 (💬 talk • ✏️ contribs) 20:30, 3 June 2024 (UTC)[reply]

While I'd love for folks to get easier access to IRC clients that are usable on mobile devices and from a browser, I'm going to have to oppose this. I love the general idea of "WMF provides web-based IRC client to Wikimedians", but this proposal has too many issues. Firstly, cloaks on Libera Chat are designed to show an affiliation to a project, and some people (myself included!) don't have a Wikimedia cloak even though they may be eligible for one. Sure, it's a minor detail, but it changes the cost calculation immensely. Secondly, this would have to be an on-request thing. Like Jeske, I've got my own preferred client setup and I suspect most people who've been around IRC for a while do too. Finally, IRCCloud is a commercial service, and free self-hosted alternatives exist that could probably be hosted somewhere for a much lower cost. stwalkerster (talk) 21:20, 3 June 2024 (UTC)[reply]

There are dozens perfectly good IRC clients including many free and open source options. Why on earth should the WMF, an organisation that exists to promote free content, throw all this money at one particular commercial product over all the rest? – Joe (talk) 09:37, 4 June 2024 (UTC)[reply]

I used to use Matrix as an IRC bouncer before they (Libera) shut that off, so if we were wanting an official form of IRC persistence IMO a better use of resources might be looking at a way to reenable or self-host a bridge for Wikimedia users. Or just host a bouncer themselves, that would probably be easier. One good thing about bridging is the potential to have one or two channels (probably not the main ones unless people primarily using IRC want that) also bridged to Discord (I know it's not official, but we could probably make an official one) to unify the community. I know some open source projects that do that. Alpha3031 (t • c) 14:07, 4 June 2024 (UTC)[reply]

Doesn't Libera Chat already provide a free web client for everyone at web.libera.chat? Why would we want to send our users to this other vendor in the middle? — xaosflux ^Talk 14:12, 4 June 2024 (UTC)[reply]

KiwiIRC is not robust and lacks in functionality when you compare it to IRCCloud, at least from my experience in using web-browser clients. Cocobb8 (💬 talk • ✏️ contribs) 14:13, 4 June 2024 (UTC)[reply]

@Xaosflux, general webchat tools like either of Libera Chat's web-based clients do not allow for persistent presence, and generally disconnect users whenever the user's browser decides to stop running JS on that tab to save resources. It leads to a fairly unreliable connection for anyone who wants to idle in a channel and isn't actively using IRC all the time. Bouncers (ZNC, irssi, weechat, soju, etc) and web clients which behave like bouncers (such as IRCCloud or The Lounge) persist the connection server-side, allowing persistent presence and easy session resumption.

For casual users, such as those who visit -en-help, -en-revdel, or -en-unblock for assistance with a specific issue, webchat is absolutely fine. For users who want to hang around in channels long-term, webchat isn't really feasible. stwalkerster (talk) 14:22, 4 June 2024 (UTC)[reply]

Thanks for the update. We have several channels that specifically ask for no-logging, wouldn't this completely circumvent that? Additionally, as far as privacy goes this would insert another man-in-the-middle correct? IF WMF is going to purchase and provide subscriptions to this vendor I'd like to hear what their legal, privacy, and vendor management teams have to say about it. — xaosflux ^Talk 14:33, 4 June 2024 (UTC)[reply]

I think you're conflating things here. Most of our channels ask for no public logging - aka publishing of channel logs in a way that others can access it. It's even one Libera Chat's policies that public logging shouldn't happen without explicit notification. I'm not aware of any of our channels which ask no private logging (please do enlighten me if you know of any - I'm curious), nor am I aware of any non-webchat client that doesn't log privately by default. If we do have no-logging-at-all channels, then I strongly suspect that not every member of those channels has configured their client to not log that channel.

We already have many users who use IRCCloud as their main client, either using the free version that doesn't offer persistent sessions or the paid version which does. As far as I'm concerned, WMF paying for a tool that many people use already will have zero practical impact on our privacy stance. If you look at a names list in any of our channels (or even look through joins/parts), you'll probably see that the user/ident part of a good portion of people's nick!user@host is either sid000000 or uid000000 - this is the common pattern for IRCCloud users (paid and free respectively).

That said, as I mentioned above, I don't think IRCCloud is a good solution to the underlying issue when other FOSS alternatives exist (The Lounge) that we might be able to host somewhere like WMCS. stwalkerster (talk) 16:39, 4 June 2024 (UTC)[reply]

As long as a good, free (and unlimited in terms of connection) alternative that works for basically any device can be found, that would satisfy what I wanted with this proposal :). Cocobb8 (💬 talk • ✏️ contribs) 17:39, 4 June 2024 (UTC)[reply]

Adding some bracket colors (or anythin) to improve readability (and shorten sentences) therefore helping the reader's eye to jump from core sentense part to core sentence part (without the need to seek eternally for a lines away closing bracket) even though shorter sentences are a superior solution (but not so easy to enforce with open data).

Moved to Wikipedia:User scripts/Requests § Collapsible parentheses in body text

– Aaron Liu (talk) 19:05, 4 June 2024 (UTC)[reply]

Dealing with forum bloat

Some high-activity fora (in particular WP:ANI and WP:RSN) are so clogged with activity they become difficult to navigate and can even start to glitch and slow down web browsers. I think it’s a reasonable idea to break these down somehow, probably with case-based subpages. thoughts? Dronebogus (talk) 09:32, 4 June 2024 (UTC)[reply]

The main issue with RSN at the moment is that the very large at the top was restored from the archives. It needs to be closed, but that could have happened without it being restored. Anyone interested in closing it? -- LCU ActivelyDisinterested «@» °∆t° 15:41, 4 June 2024 (UTC)[reply]

I still think it’s emblematic of a larger issue— i.e. major fora working more akin to XfDs (lots of discussion and sometimes voting, more than enough for separate pages) but being treated like a simple noticeboard with minimal user interaction (i.e. Wikipedia:AIV) Dronebogus (talk) 16:48, 4 June 2024 (UTC)[reply]

There was a discussion about similar issues here on Village Pump, see WT:VPR#Looking for some unofficial clerks and Wikipedia:Village pump (technical)/Archive 209#SIZESPLIT but for Village pumps. I could see the same idea working, opportunistically creating subpages for large topics, but doing it in anyway automatically could cause issues. Especially on RSN the vast majority of posts get few is any replies, pushing them to subpages would only give them less visibility. -- LCU ActivelyDisinterested «@» °∆t° 17:00, 4 June 2024 (UTC)[reply]

I think the main solution for RSN is to insist that RSP proposals happen somewhere else. WhatamIdoing (talk) 17:01, 4 June 2024 (UTC)[reply]

We also need to do better at emphasizing what RSP is for (or perhaps stress what it ISN’T for). It has turned into a general RFC page for sourcing questions, and that was NOT the original intent. It is supposed to be a list of perennial sources (ie sources that are repeatedly discussed), not a comprehensive list of reliable/unreliable sources. Blueboar (talk) 12:59, 5 June 2024 (UTC)[reply]

Rename it to “perennial sources noticeboard”? Dronebogus (talk) 13:00, 5 June 2024 (UTC)[reply]

WP:RSP is the list of perennial sources, which doesn't seem to be particularly bloated or diluted. WP:RSN is the noticeboard that deals with questions about reliable sources - both determining the general reliability of frequently-used sources and whether a source is reliable in a specific context - that is very long. We need a place to discuss both types of question the RSN currently deals with and while that doesn't necessarily have to be the same place, there is sometimes overlap between them. I can think of two ways of reorganising that might help:

Leaving all discussions as they are currently until they get to beyond a certain size, at which point they are moved to a subpage that is linked/transcluded from the main page (similar to how some VP and AN/I discussions are treated)
Leaving RSN as is for small, specific discussion with new RFCs being their own subpage. There would be a (bot-maintained?) list of open (and recent?) RFCs at the top of the noticeboard, possibly similar to the recent ECP protections report at the top of WP:AN (but not collapsed) showing the title of the RFC, the source(s) being discussed, date and time initiated, number of comments and timestamp (and author?) of the latest comment and whether it is open or closed (and if the latter when it was closed and who by).

Thryduulf (talk) 13:34, 5 June 2024 (UTC)[reply]

It's a common problem that editors open discussions/threads about getting sources added to RSP that have been regularly discussed, they all get closed down quite quickly. Very few source have recently been added to RSP.
RSN isn't usually very long, it only gets so when specific discussions are ongoing. Dealing with those discussions as they happen seems a lot less bureaucratic then setting up a mess of transcoded bot maintained pages.
Also transcluding all pages to one page is worse than having all discussions on one page, all the translcuded text has to be displayed but now with the overhead of transclusion. If the issue on any page is difficulties in display due to size then transclusion is the opposite of the solution. -- LCU ActivelyDisinterested «@» °∆t° 14:17, 5 June 2024 (UTC)[reply]

I've thought about splitting ANI. My current favorite idea is to imagine that we split it according to the day of the week (Wikipedia:Administrators' noticeboard/Incidents/Monday, Wikipedia:Administrators' noticeboard/Incidents/Tuesday, etc.). Everything can get archived together, but you could watch just the one page that "your" discussion is on. Because most are resolved and archived in about two days, the page should be nearly empty by the time it rolls around again. Admins could sign up to deal with a defined fraction of the week's load and not feel like the firehose never stops. We might have less feeling that it's just overwhelming because there are "too many" sections on the same page. And maybe we'd see less emotional spillover, in which I'm so mad about this discussion that I'm too harsh about everything else on the page. WhatamIdoing (talk) 17:00, 4 June 2024 (UTC)[reply]

I know this is a minor thing and a bit of a tangent, but ANI is not only frequently large (50+ sections some days, despite aggressive archiving) but it has an unusually high number of revisions, which means that various tools like https://xtools.wmcloud.org/ don't work on it. Sometimes I think it would be a good idea to do an archiving-esque Move procedure on that page at the start of each year (or at least for each decade). WhatamIdoing (talk) 17:07, 4 June 2024 (UTC)[reply]

I really like this idea. And the built-in reminder it provides when a discussion has been open for a week (and two weeks) could have a salutary effect. Newimpartial (talk) 17:08, 4 June 2024 (UTC)[reply]

What about going the whole way and turning it into dated subpages like TfD or MfD? Each subpage would be transcluded at WP:ANI until all the discussions on it have been closed. This could have the side benefit of making ANI more outcome-oriented, which seems to be a common characteristic of our more functional noticeboards. – Joe (talk) 09:09, 5 June 2024 (UTC)[reply]

Subpages make it much more difficult for people to watchlist the page and become aware of new discussions. Currently you can subscribe to and/or watchlist the page and be alerted to new discussions. With daily subpages you have to explicitly visit the main page and look for changes, watchlist/subscribe to 365 individual pages per year and/or use a workaround equivalent to user:Thryduulf/RfD watchlist. A forum like ANI needs visibility to work. Thryduulf (talk) 10:12, 5 June 2024 (UTC)[reply]

It needs visibility from admins, and I don't think that will stop. Maybe the peanut gallery watchlisting ANI and showing up for every discussion is actually a bad thing. Wilhelm Tell DCCXLVI (^{talk to me!}/_{my edits}) 11:19, 5 June 2024 (UTC)[reply]

Agreed. The problem with ANI is that it's too visible. A person with ANI on their watchlist is a person we don't want participating in ANI (I'm joking... kind of.) – Joe (talk) 12:04, 5 June 2024 (UTC)[reply]

As a non-admin, I occasionally watchlist ANI when there's a discussion of particular interest to me, such as unconstructive editing that I've recently helped to deal with. I try not to do so regularly, because it would flood my watchlist with edits which are important to someone but largely irrelevant to me. I would love to have my watchlist show only updates to a particular section. (I'm aware of subscriptions.) Certes (talk) 13:54, 5 June 2024 (UTC)[reply]

The issue with that is we need consensus from uninvolved editors for a lot of proposed actions at ANI. Making it more difficult to keep an eye out for something you may be able to contribute to isn't going to make it better. Also, this is another chance for me to bang the Administration noticeboard, not Administrators' noticeboard drum. AN and ANI are not for administrators, they're for site administration. ScottishFinnishRadish (talk) 13:59, 5 June 2024 (UTC)[reply]

We don't seem to struggle to get a consensus of uninvolved editors at other high-volume venues that use subpages, like AfD, TfD/MfD, or DRV. Conversely, it is rare for discussions at those venues to turn into lengthy pile-ons, boomerangs, or unclosable trainwrecks. When was the last time you heard somebody complain that ANI is awful because there are too few opinion-havers there? – Joe (talk) 14:31, 5 June 2024 (UTC)[reply]

I've also seen many threads there which start with a small group of editors pushing for something, that later uninvolved editors push back on. With less visibility comes less oversight. As a new editor the other high volumes venues you mention certainly felt more cliquey with the same editors turning up in discussion on a very regular basis, something the other noticeboards didn't seem to have. -- LCU ActivelyDisinterested «@» °∆t° 14:45, 5 June 2024 (UTC)[reply]

You think that the average AfD, MfD, or DRV would meet a reasonable quorum of uninvolved editors to indefinitely block, topic ban, ban, or otherwise sanction an editor? AfD is chronically underattended, for example, and articles are often deleted or kept on the word of two or three editors. ScottishFinnishRadish (talk) 14:51, 5 June 2024 (UTC)[reply]

Yes. When the outcome is obvious at XfD, a few editors will participate and others will not see the point in piling on: this is a feature, not a bug, and something that we could well try to emulate in our user conduct processes. When they're controversial (as an ANI sanctioning an established editor would be), 10-20 participants is not uncommon. – Joe (talk) 15:06, 5 June 2024 (UTC)[reply]

It's difficult to measure people not posting a comment, but I can confirm what @Joe Roe says: I avoid "piling on" at AFD, especially when the outcome is to delete, because it's unnecessary and might feel hurtful to the article's creator. WhatamIdoing (talk) 03:55, 6 June 2024 (UTC)[reply]

Subpages make it much more difficult for people to watchlist the page

That's why I thought that /Monday, /Tuesday would be better than each day. People can manually click on seven buttons more easily than 365 (times however many years you wanted to pre-load). However, I believe there is a script-y kind of way to watchlist all the pages for (say) a calendar year, if someone really wanted to do that. WhatamIdoing (talk) 03:54, 6 June 2024 (UTC)[reply]

I'm not sure formally closing all discussions at ANI is a good idea. Currently most of the uncontentious stuff is "closed" by bot archiving; explicit human closes of everything could easily lead to increased bickering about discussion closures for "no one cares"/"no longer interesting"/"nobody wants to act on this"/"no action needed" discussions (usually it is not worth determining which of these is the case). —Kusma (talk) 15:19, 5 June 2024 (UTC)[reply]

Maybe mention drafts after redirects?

In my opinion, the {{Draft at}} template is very useful. I'm wondering if it would be useful for visitors to get a similar notice after being redirected from an article that has a draft. I will give three semi-random examples (their names start with A, B, and C). AIOS, Beatpath, and Capitol Highway. Each has a draft, but each redirects without displaying the template. Maybe a knowledgeable editor visiting one of these would have helped improve the draft, were they made aware a preliminary version is available. Maybe something as basic as "(Redirected from X; there is a draft at Y)"? --Talky Muser (talk) 18:22, 4 June 2024 (UTC)[reply]

Technically speaking this could work. By default it would only display a message if there exists a page in draftspace with a name that exactly matches the title of the redirect used. For example Capitol Highway, Oregon would not indicate the existence of Draft:Capitol Highway unless explicitly linked (I'm not sure whether matching is case sensitive). The message would also not display in a logical place if the redirect is to a section (the "redirected from" message always appears at the top of the page). Within those limitations though this seems like something useful to have. Thryduulf (talk) 19:28, 4 June 2024 (UTC)[reply]

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)[reply]

I just tried it and liked the results. Thanks! Schazjmd (talk) 20:23, 4 June 2024 (UTC)[reply]

See WP:WRS. --Talky Muser (talk) 20:37, 4 June 2024 (UTC)[reply]

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)[reply]

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)[reply]

WP:RSSE is another. Levivich (talk) 02:29, 6 June 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

WMF

The movement

The phrase "Wikimedia movement" is not a recent invention, though it has received more attention in the past couple years. We individual Wikians of course are free to call ourselves proudly as we will but I think the failure a few years ago to rename the outlying and ancillary sites to "Wikipedia [something]" was unfortunate as it would have helped in public recognition. It would help in recruiting; almost all my students have been attracted to our teaching sessions in hopes of writing a new article when really, it would usually be easier for them to learn how to add a new picture. For my own editing, for a decade or more I have been putting about as much effort into Wikimedia Commons and Wikidata as into English Wikipedia. Those sites do a few things but mainly they supply pictures and data (geographical coordinates are one of my specialties) to the hundreds of Wikipedias including English. Even without a common name, I figure there ought to be a common policy structure and general set of guidelines for us all, so the WMF staff don't have to decide so many things for us. Naturally there will be an interest in adding matters that are mainly the concern of only the encyclopedias or of only few of the various other autonomous member sites, who each ought to handle such things by their already established methods. There will be disagreements on such questions, but I'm confident our usual methods of drawing a consensus will prevail. Jim.henderson (talk) 00:16, 4 April 2024 (UTC)[reply]

In short: I'm curious whether you're saying you believe that a difference of one letter (in some cases) constitutes a real detriment to the development of Wikipedia's sister sites? "Wiki" is already very widely associated with Wikipedia by the public, does "Wikipedia Data" being a thing people hear about and are surprised it exists seem much more unlikely than with "Wikidata"?
I really disagree that even in effect Commons's main function is to act as Wikipedia's image repository. Its use is ubiquitous.

I figure there ought to be a common policy structure and general set of guidelines for us all, so the WMF staff don't have to decide so many things for us.

I don't really think this structure makes sense. WMF doesn't really make that many choices for us—or at least, I feel part of the process for just about every choice I would like input on. I'm not sure what exactly you would like centralized, the current model seems to work. Do you have specific areas of policy or administration in mind?

Remsense诉 00:39, 4 April 2024 (UTC)[reply]

I think it's important to remember that there isn't a "we", strictly speaking. Not all of us are here to be part of a movement or whatever, or even editing for the same reasons; some just want to fxi a tyop that bugged them, others to add information about their favourite volcano. Jo-Jo Eumerus (talk) 07:18, 4 April 2024 (UTC)[reply]

I have a great respect for sister projects. I refer to Wiktionary regularly, and I use Commons unconsciously most times I read a Wikipedia article with images, though I've contributed very little to either. I use Wikidata occasionally, and was briefly an enthusiastic contributor; I would use it much more if it had an intuitive user interface. None of this makes me part of a "Wikimedia movement", which I see largely as a political stance shared by some but not all editors. Certes (talk) 09:08, 4 April 2024 (UTC)[reply]

The fact that you think the other projects are nothing more than ancillary sites that should be rebranded as under the Wikipedia umbrella is a very, very bad sign. Cremastra (talk) 22:04, 5 April 2024 (UTC)[reply]

I completely understand that Wikipedia editors have a very Wikipedia-centric view of the broader Wikimedia community. It would be nice if everyone had the interest to learn more about the other projects, and how they are used, but I understand that it's not a priority for most Wikipedians, regardless of which language Wikipedia they choose to edit. But I'll just throw in a few tidbits:
For many mainstream media sources that use images, Wikimedia Commons is often a go-to resource. There isn't a day that I don't find a Wikimedia Commons credit on the series of mainstream media sources I look at.
Wikidata is used widely as a data aggregator by many other not-for-profit resources.
Some language editions of Wikisource are the largest repositories of open-source historic documents and literature in those languages
Some language editions of Wiktionary are having a major impact in preserving dying languages

The 339 Wikipedias, with their collective 62+ million articles, are indeed the major drivers of the Wikimedia family of projects; the largest Wikipedias, especially the English one, have deservedly gained a reputation for accuracy and neutrality in providing the entire world with information. That doesn't mean that the "sister projects" don't make a valuable contribution to the sum of all human knowledge. I will never fault anyone for choosing to focus on one specific Wikimedia project, or even one small aspect of a specific project. We're all better for those contributions. Risker (talk) 08:39, 4 April 2024 (UTC)[reply]

Fearful of being caught beating a dead horse, I'll speak once more and hope to be disciplined enough to hold my peace. Yes, one little letter can indeed make a difference. Besides the local Wikimedia Chapter I am a member of local clubs concentrating on bicycling and astronomy. I'm always nattering to them about how we make Wikipedia and sometimes they actually listen. A couple times, though they did not surrender to my efforts to get them to edit an article or two, they decided that a money contribution would be a good thing. "Eh? The form said 'Wikimedia Foundation'. Is that the same thing, or did someone else sneak in with some kind of Internet scam?" These people had me to make the explanation, unlike most outsiders.
A common brand can't help us thousands of insiders to understand what we're doing; like other big busy communities we are too complex to be understood with just a few simple labels. However, that's not what brands are for. Brand names are to promote instant understanding among the mass of outsiders, in this case their understanding that this is a big complex of websites with a common theme. We have different detailed policies to handle our specialties, but we are all about Wikipedia's original aim of promoting universal knowledge by organizing it for accessibility.
I have uploaded thousands of pictures to Wikimedia Commons, and I know of a dozen that are used in news publications, books, and other works. Probably hundreds more are so used; we don't require to be given notice. The usual credit, when given, is "From Wikipedia" or "From Wikimedia Commons" or "by Jim.henderson via Wikimedia Commons". I figure, out of the small minority of their readers who actually wonder where the pictures came from, "From Wikipedia" is the only one that isn't mysterious. Yes, knowledge professionals, most often, know what they are doing but they hope their product will be read by many more people than are composing it; same as we do. They don't expect their readers to learn what it takes to be a knowledge professional.
Wikidata is indeed used by many knowledge professionals. I am most familiar with the work of librarians since I work with them often, and have a lunch appointment tomorrow with a relative who's in that line of work. They are familiar with the different workings of OCLC, Worldcat, LoC and various local or specialized catalogs, and many of them also use Wikidata to help find their way through and among the others. Haha, a couple years ago I looked at the Wikidata item about me, and it showed my LoC Authority Control Number. What, has my good work come to such high prominence? No, that was another Jim Henderson, so I corrected it. Wikidata is full of dirty data like that, some of it imported from massive outside databases a century old or more. Not a big problem since WD serves people in the database business who are aware. I have also worked with art museum archivists and have no idea whether their old catalogs have as many errors as the databases for community gardens in Brooklyn or defunct restaurants in The Bronx. Hmm, perhaps I have wandered but anyway yes, the question of what brand name Wikidata ought to use is a lot less important than for Wikiprojects that serve a wider direct audience.
Oh-oh, it seems this paragraph on WD has revealed that I've already gone overboard. So, I'll drop my stick and carefully back away from the dead horse. Jim.henderson (talk) 01:13, 5 April 2024 (UTC)[reply]

The full Movement Charter draft awaits your review on Meta

Hello again! I am following up on the pre-announcement from the previous week to let you know that the full draft of the Movement Charter has been published on Meta for your review.

Why should you care?

The Movement Charter is important as it will be an essential document for the implementation of the Wikimedia 2030 strategy recommendations. Participating in the Charter discussions means that you ensure that your voice is heard and your interests are represented in shaping the future of the Wikimedia Movement. As the English Wikipedia community is the largest of the Wikimedia movement, it is essential to have the perspectives from your community presented in the global conversations. I hope many of you will find time to provide feedback, share your thoughts and perspectives!

Community Engagement – April 2nd to April 30th

The Movement Charter Drafting Committee (MCDC) cordially invites everyone in the Wikimedia movement to share feedback on the full draft of the Movement Charter.

Let your voice be heard by sharing your feedback in any language on the Movement Charter Talk page, attend the community session today, on April 4th at 15.00-17.00 UTC, or email movementcharter@wikimedia.org. I will also be monitoring conversations on this talk page, to bring back the summaries to the ongoing global conversations.

You can learn more about the Movement Charter, Global Council, and Hubs by watching the videos that the Movement Charter Drafting Committee has prepared. Read the Committee's latest updates for more information about the most recent activities from the Drafting Committee.

Thank you again for your time and kind attention! I look forward to your input and feedback. Have a wonderful month of April! --KVaidla (WMF) (talk) 13:07, 4 April 2024 (UTC)[reply]

Unified enwiki response to the charter

In votes like these a significant issue is that interested editors do not have the time or wherewithal to properly assess the issues or candidates presented and so abstain from the vote. I propose that we attempt to address this, by having more engaged editors consider the proposal carefully and, in consultation with the community though an RfC, issue a recommendation either to support or oppose the change. Specifically, I propose a three-stage process:

A pre-RfC discussion where we will write a neutral summary of the proposal.
An RfC where we will:
1. !Vote to approve the summary and its dissemination
2. !Vote whether we should encourage eligable enwiki editors to vote for or against the change
Assuming the summary is approved, a mass message to all eligable enwiki editors providing it. Further, assuming there is a consensus either for or against the change, a recommendation to the editors that they vote in line with that consensus.

Stage one should probably begin soon, in time for a RfC in May; first, however, I wanted a brief discussion of the general idea. BilledMammal (talk) 02:41, 7 April 2024 (UTC)[reply]

Thanks for your comment, BilledMammal. This isn't a bad idea, but it is worth noting that the draft charter will be revised in early May following this current feedback round. Although the MCDC (of which I am a a member) does not anticipate making really large changes, I think it would be reasonable to assume that the final version is going to have at least some differences from the current draft. Would it make sense to create a feedback page on this project as a place where interested enwiki editors could flesh out their opinions before the final revision is made? I'd hate to see people investing a lot of time reviewing a draft and proposing a project-wide opinion in an RFC-type format, based on a document that we know will change. There is something to be said for having a local page for comments and suggestions for improvement (and please yes, if someone thinks X is a bad idea, propose an alternative) as long as there's a link to it on the Meta page so that the MCDC will be well-informed of the discussion on this project. (For that matter, it may be a good idea for other projects, and I'm pretty sure some of them are thinking about this too.) Risker (talk) 03:17, 7 April 2024 (UTC)[reply]

That's a good point, but we also need to consider that it will take time for the RfC to run. I think we should start drafting the summary based on the current document, and then make any updates that are necessary to align it with the May changes and start the RfC a few days after it is released.

I would also agree that creating a local page where editors can make comments and suggestions for improvements would be useful, although I would suggest just using this page as it isn't as busy as the other village pumps and thus an extensive discussion of the proposed charter won't disrupt other discussions. BilledMammal (talk) 04:59, 7 April 2024 (UTC)[reply]

I think mass messaging every eligible voter WP:ACE style might be too many people. Perhaps a watchlist notice, or pinging rfc participants, would be a good compromise. –Novem Linguae (talk) 16:30, 7 April 2024 (UTC)[reply]

I don't think that the vote to ratify this charter is less important than the vote to elect the Arbitration Committee. BilledMammal (talk) 16:32, 7 April 2024 (UTC)[reply]

Thank you for this initiative, BilledMammal, to approach the Movement Charter conversations in a constructive way! For reference, the timeline for the steps can be found here on meta and you are right, the time is of essence. It has been already pointed out on the meta discussion page that the review of the Charter would benefit from additional contextual materials for informed decision-making. As a supporting staff member to the MCDC I will see what I can do, yet it might take some time. If there are priority areas for further context in the English Wikipedia community, please let me know, so I can focus my work around that and hopefully have respective content available earlier. Also let us know, if we can support the discussions around the Charter in other ways. Looking forward to hearing the perspectives and seeing good participation from en.wp community! --KVaidla (WMF) (talk) 12:47, 9 April 2024 (UTC)[reply]

@KVaidla (WMF), can you please provide an update on recent actions by the WMF Board,. re the movement charter? thanks!! Sm8900 (talk) 20:20, 31 May 2024 (UTC)[reply]

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)[reply]

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:

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)[reply]

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.

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.
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)[reply]

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)[reply]

Miscellaneous

Arabic Wikipedia

Hi, sorry to bother everyone but I stumbled address the Arabic Wikipedia and they had a large banner that said something about the Hamas Israel war, and it was like (don’t quote me on this) stop the genocide in Gaza! And I could be wrong I’m not a Wikipedia editor but I was just curious like is this agents policy, like I don’t mind it at all but I was just wondering 2600:6C48:617F:2533:9D74:4184:C6F7:F5D6 (talk) 03:43, 28 May 2024 (UTC)[reply]

All language versions of Wikipedia are editorially independent, none of our policies at en.wiki affect ar.wiki and vice versa. CMD (talk) 04:16, 28 May 2024 (UTC)[reply]

I know this issue has been discussed in places, also in the media, but I don't have any links atm. Gråbergs Gråa Sång (talk) 07:23, 28 May 2024 (UTC)[reply]

https://ar.m.wikipedia.org/wiki/%D8%A7%D9%84%D8%B5%D9%81%D8%AD%D8%A9_%D8%A7%D9%84%D8%B1%D8%A6%D9%8A%D8%B3%D8%A9 2600:6C48:617F:2533:55B:74F7:C323:A7C (talk) 20:41, 28 May 2024 (UTC)[reply]

I think it was this one meta:Requests for comment/Community consensus for blackouts and other advocacy. -- LCU ActivelyDisinterested «@» °∆t° 22:32, 28 May 2024 (UTC)[reply]

The phrase "be careful what you wish for" springs to mind. I'm sure that if there was a world-wide vote on the Arabic Wikipedia's definition of neutrality it would not result in the American position being supported. Do the OP and supporters want an anti-genocide message to be displayed on all Wikipedias, including the English and the Hebrew? Phil Bridger (talk) 19:16, 5 June 2024 (UTC)[reply]

Inexplicably popular article (by views)

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)[reply]

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)[reply]

The start of this climb in pageviews seems to have been on 24/25 August 2021 ([24]), 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)[reply]

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)[reply]

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)[reply]

Maybe there's a viral post or tweet somewhere with an easter egg? Schazjmd (talk) 22:07, 28 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

I have logged a case in WP:ANI. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:10, 3 June 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

If this is due to a malicious botnet, shouldn't you have WMF report this to law enforcement? –LaundryPizza03 (d c̄) 01:20, 4 June 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Help us rename the Community wishlist

Hey folks - WMF is making updates to our Community Wishlist, from making it open year round to prioritizing "focus areas" of user submitted ideas, requests, and bugs that share an underlying problem.

In this process, we've realized we're outgrowing the the name "Community Wishlist Survey" and I wanted to get your feedback on a few other options. We've offered 3 ideas, and if you have another preference, we welcome you to suggest alternatives! JWheeler-WMF (talk) 21:31, 29 May 2024 (UTC)[reply]

I suggest you spend all the effort that would be spent on renaming on fulfilling requests on the wishlist. The name doesn't matter, and all of the options are objectively worse. It's a survey of the community about what features they wish existed. ScottishFinnishRadish (talk) 21:34, 29 May 2024 (UTC)[reply]

Can't you see there's important bike-shedding to be done? Jason Quinn (talk) 21:18, 30 May 2024 (UTC)[reply]

I'm totally in agreement with SFR. Changing the name is silly, both because it's accurate as is and because it wastes effort which could more profitably be spent writing code to fill more of the wishlist items. RoySmith (talk) 22:18, 30 May 2024 (UTC)[reply]

In my opinion, the existing name describes the process clearly and has some recognition. It seems more precise than the other options presented, and I'm unable to come up with a different term which would be an improvement. Certes (talk) 21:44, 29 May 2024 (UTC)[reply]

I agree with the others. The existing name is both descriptive and familiar. Dramatically changing the underlying process already makes the process significantly difficult for folks to adjust to. Changing the name makes it more obscure and harder for people to find. I'd suggest using this time to make the new process as thrilling and synergistic as the old process was. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:10, 29 May 2024 (UTC)[reply]

Hey, all, please share your views over there, instead of setting up a WP:TALKFORK here. WhatamIdoing (talk) 22:15, 29 May 2024 (UTC)[reply]

(In Herb Tarlek voice) OK fine. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:35, 29 May 2024 (UTC)[reply]

I've not commented on Meta, as I'm just here to edit English Wikipedia and don't have time to monitor yet another forum, but doing nothing sounds like an economical and productive way forward. Certes (talk) 08:54, 30 May 2024 (UTC)[reply]

Rule of Three

Has there been anybody who tried to complete the rule of three when it comes to "Editing Wikipedia while driving" and "Editing Wikipedia while drunk" on Wikipedia:Deleted articles with freaky titles? Perhaps, "Editing Wikipedia while drunk driving"?

i am very interested in the deleted articles with freaky titles but i'm too chicken to make it myself OrlandoApollosFan69 (talk) 02:29, 2 June 2024 (UTC)[reply]

Announcing the first Universal Code of Conduct Coordinating Committee

You can find this message translated into additional languages on Meta-wiki. Please help translate to other languages.

Hello,

The scrutineers have finished reviewing the vote results. We are following up with the results of the first Universal Code of Conduct Coordinating Committee (U4C) election.

We are pleased to announce the following individuals as regional members of the U4C, who will fulfill a two-year term:

North America (USA and Canada)
- –
Northern and Western Europe
- Ghilt
Latin America and Caribbean
- –
Central and East Europe (CEE)
- —
Sub-Saharan Africa
- –
Middle East and North Africa
- Ibrahim.ID
East, South East Asia and Pacific (ESEAP)
- 0xDeadbeef
South Asia
- –

The following individuals are elected to be community-at-large members of the U4C, fulfilling a one-year term:

Barkeep49
Superpes15
Civvì
Luke081515
–
–
–
–

Thank you again to everyone who participated in this process and much appreciation to the candidates for your leadership and dedication to the Wikimedia movement and community.

Over the next few weeks, the U4C will begin meeting and planning the 2024-25 year in supporting the implementation and review of the UCoC and Enforcement Guidelines. Follow their work on Meta-wiki.

On behalf of the UCoC project team,

RamzyM (WMF) 08:14, 3 June 2024 (UTC)[reply]

Typo or intentional?

Tracked in Phabricator
Task T13700

When visiting this cascade-protected image file page, the action bar at the top shows "Edit source" instead of "View source". Was this a typo, or was it intentional? I would highly appreciate any responses, especially from WikiMedia staff.

MasterOpel 20:39, 3 June 2024 (UTC)[reply]

Should probably have posted this at WP:VPT. I was able to replicate the error. Looks like phab:T13700. You can subscribe to that ticket if you'd like updates. However it looks like devs are hesitant to fix this due to performance reasons. –Novem Linguae (talk) 21:31, 3 June 2024 (UTC)[reply]

A survey regarding patrolling

Hello

The moderation tools team is working on Automoderator, a tool that would make it possible to revert vandalism automatically. This tool could replace vandalism bots (or be used in parallel), or help users prevent vandalism on wikis where no bot is available.

From 6 June to 7 July 2024, on your wiki, we will randomly display an invitation to complete a survey to selected users, as part of our efforts to understand how patrollers behaviors will change when Automoderator is deployed.

The survey will be shown to registered users, who signed up before 2024, and who have made more than 500 edits.

You can find out more about this survey at phab:T362462.

Please share this information anywhere useful. Thank you in advance for your participation!

Trizek_(WMF) (talk) 13:22, 5 June 2024 (UTC)[reply]

Attribution of articles translated from foreign language wikipedias

Hello all,

Questions for input from Wikipedians regarding how articles that include text translated from foreign language wikipedias should have attributions handled. All translations of content from any language wikipedia are derivative works that require attribution. (See here for rationale.)

This arises from pages like Abeozen which have in-article mentions of the translation source ( The above article was created as a translation of its counterpart on the French Wikipedia, . (Specifically this version) but no mention of this attribution in the edit history or talk page. Current policies WP:TFOLWP and Help:Translate recommend inserting this information only in the edit history, and there are many pages (approx. 94,000 with Template:Translated page included in their talk page, but this appears to be additional and alone does not satisfy attribution requirements.

Looking for input on the following points:

Should pages which do not have attribution information in the edit history have this information added to the edit history?
Rationale for Yes is that WP:TFOLWP and Help:Translate state this is a requirement for attribution, and prevents against any removal of attribution from future edits.

Rationale for No is that attribution in the article is more visible than attribution in the edit history and is sufficient to meet Wikipedia's attribution requirements regardless of current policies as per WP:TFOLWP and Help:Translate.
Should attribution information be included the article?
Rationale for Yes is that this raises awareness and visibility of the article's origin as a translation.

Rationale for Undecided / Decision between editors on individual articles is that changes to existing articles is not necessary, this is optional to each article's authors.

Rationale for No is that to prevent WP:CIRCULAR, articles should not cite or present wikipedia in any language in a manner that could be confused with a source or reference, and guidance for attributions is for this to only be included in edit histories as per WP:TFOLWP and Help:Translate.
Should attribution information be included in the talk page with Template:Translated page ?
Rationale for Yes is that this raises awareness and visibility of the article's origin as a translation.

Rationale for Undecided / Decision between editors on individual articles is that changes to existing articles is not necessary, this is optional to each article's authors.

Rationale for No is that translation attribution should only be in the edit history..

Other answers or positions regarding the above questions are welcome, as are other questions arising in discussion on this point.

Pinging potentially interested Wikipedians: @Mike Peel @RudolfRed (thanks for suggestion to move question here from WP:Teahouse) @GreenLipstickLesbian (thank you for your clarification for new editors at WP:Teahouse and your position in this diff)

Thank you all for your input! Shazback (talk) 07:55, 6 June 2024 (UTC)[reply]

My understanding is that translations must be attributed in an edit summary in the main article. The talk page template is optional and can be skipped. I don't recall ever seeing attribution included in the article itself (i.e. via a citation to the foreign language Wikipedia, via a "note: this was translated", etc.). If you want to fix that article and you are sure there is no previous edit summary giving attribution, feel free to make a small edit to the article (add a space or something) and give the proper attribution in the edit summary. I believe the guideline WP:TFOLWP has suggested text for this. –Novem Linguae (talk) 08:36, 6 June 2024 (UTC)[reply]

I see there was also a discussion about this with several other editors on Wikipedia talk:Copying within Wikipedia and at Wikipedia talk:WikiProject Articles for creation about a month ago. I am pinging them for comment with the aim to gather a broader consensus / ensure all points of view are represented. @asilvering @Mathglot @S0091 @Ingratis @Greenman @Primefac @KylieTastic Shazback (talk) 06:20, 7 June 2024 (UTC)[reply]

Also @WhatamIdoing Shazback (talk) 06:28, 7 June 2024 (UTC)[reply]

Also (for completeness) there was a template merge discussion which may be relevant (Wikipedia:Templates for discussion/Log/2024 February 4), pinging involved Wikipedians @Matrix @Anomie @Noahfgodard @Ipigott @Cl3phact0 @Riad Salih @scope_creep @Occidental Phantasmagoria @Knowledgekid87 Shazback (talk) 06:37, 7 June 2024 (UTC)[reply]

Perhaps too many pings. Hopefully you have plenty of answers now. –Novem Linguae (talk) 09:14, 7 June 2024 (UTC)[reply]

Similar to Novem, I feel it unusual to have attribution in the article but not in the edit summaries (which is I assume what is meant by edit history). If attribution is added to an edit summary, that seems good practice for quicker glances although I suspect the licence is met by the in-article attribution. I'm not sure if there is a best way to add attribution to an article, the text is not permanently linked to the original language article and will have to stand on its own with regards to referencing etc. The talkpage template can be helpful, but doesn't seem a requirement for the licence. CMD (talk) 06:33, 7 June 2024 (UTC)[reply]

The license requirements can be met through any of several methods, including importing the original non-English article (the approach used at the German-language Wikipedia, where you can find non-lawyers solemnly averring that it is a legal requirement), adding a link to the original in the edit summary (the approach used by the Wikipedia:Content translation tool, and about which you can also find non-lawyers solemnly averring that this is a legal requirement), by adding a relevant template on the talk page, by adding a non-templated message on the talk page, by adding a message in the mainspace, and probably by other methods, too.

I suggest that if you encounter someone claiming that a specific method must be used for license/legal reasons, you should probably not believe anything that person says.

Having dispensed with what we must do, I will tell you my own views about what we should do:

Should pages which do not have attribution information in the edit history have this information added to the edit history?
- Sometimes. Although it is not legally required, I personally prefer and recommend this method, particularly for the first edit summary. If you forget on the first edit, and it can be done quickly, quietly, conveniently and near the start of the history (e.g., one of the first five edits), then I think that's a fine thing to do. But purely as a practical matter, adding an edit summary somewhere in the middle of hundreds of edits is not going to help anyone. In those cases, I think that a template on the talk page is more functional.
Should attribution information be included the article?
- No. Although it is legally permitted, we don't provide attribution information in the mainspace for the English Wikipedia editors, and therefore IMO we shouldn't provide attribution information in the mainspace for the non-English Wikipedia editors. Attribution of non-Wikipedia content (e.g., public domain sources) is permissible (e.g., within ref tags) and sometimes is legally required (e.g., a CC-BY source. Although this would not absolutely require attribution directly in the mainspace, ref tags may be the most convenient and reasonable way to fulfill the requirement).
Should attribution information be included in the talk page with Template:Translated page?
- Usually. Although it is not legally required, I think this should be used as often as practicable. Ideally both the source and the translated article would get a note on their talk pages. The reason for this is because admins who are considering deletion usually check the talk page, and it may be informative to them (e.g., if they are investigating an alleged copyvio).

WhatamIdoing (talk) 06:53, 7 June 2024 (UTC)[reply]

I support attribution in edit summaries and definitely on talk pages, but I very strongly oppose attribution in the article text (with rare exceptions) because of WP:CIRCULAR. The concerns about visibility are perhaps valid, but authorship information is never listed in the article body, so why should authorship information from a different Wikipedia page? As long as external sources are supplied to support the translated material (which they should be anyway), I see no particular reason to note the translation in the article itself. I think the violation of WP:CIRCULAR outweighs the desire for increased visibility here. Noahfgodard (talk) 06:44, 7 June 2024 (UTC)[reply]

(edit conflict) Yes; No; Yes if possible (as a nice-to-have, not a must-have).

With all due respect, this topic is not really subject to consensus from a discussion at Wikipedia, as it is part of the Wikimedia Terms of Use and supersedes any policy or guideline belonging to Wikipedia or any Wikimedia sister project, so I view this discussion as informative, but having no impact other than that, as decisions about attribution are not subject to debate here. That said, the Terms appear to be written in a way that if you squint hard and look sideways, it may admit a different interpretation by at least a minority of Wikipedians, but even in that case, the solution is to seek clarification from WMF legal about what the Terms actually mean, and not to try to draw up a consensus here which would have no effect, even if one was reached.

But since you asked, my understanding is this: translation attribution must be in the edit summary per ToU § 7, and must either have a link to the foreign article with the history of contributing editors readily available (e.g., in the History tab), or else list every contributing editor in the edit summary). Adding a citation to the article in no way satisfies the attribution requirement, nor does the handy {{translated page}} template destined for the article Talk page. When attribution is forgotten in the original translated edit, then it may be added to the history retroactively following the instructions at WP:RIA.

Note that there is an additional wrinkle that is usually left unaddressed: when content is either copied or translated from S to D, the page at S may no longer be deleted, because its history is required ad infinitum in order to support the attribution requirement; at best, S may be moved elsewhere, like Draft space or some other repository. This is somewhat easier to manage for content copied intrawiki because the link will remain blue as long as it exists, and if it ever turns red, that is a flag that it must be restored. But for translated material, there is no easy method for detecting this, as interwiki links are always blue regardless if the article exists or not. (A template on the S talk page stating that it must not be deleted because of the translation done over at D-wiki might help, but the S-wiki editors might not care or respect that, if an S-Afd nom resulted in deletion at S-wiki.) That's my take; HTH. Mathglot (talk) 06:54, 7 June 2024 (UTC)[reply]

In re this topic is not really subject to consensus from a discussion at Wikipedia, as it is part of the Wikimedia Terms of Use. Whether to comply with the license is not something we get to decide. Which methods are reasonable, and whether we want to exceed the minimum requirements, is something we should discuss. WhatamIdoing (talk) 17:57, 7 June 2024 (UTC)[reply]

I think our existing transwiki attribution standards are sufficient, but I would support adding attribution in a footnote, similar to {{EB1911}} and similar templates. You could do something like:

This article contains content translated from Persian Wikipedia.

However, as Mathglot has mentioned, this is really something that should be discussed with WMF. Occidental𓍝Phantasmagoria [T/C] 07:14, 7 June 2024 (UTC)[reply]

(edit conflict) By the way, if you spot an article that appears to be an unattributed translation, you can either add attribution yourself ex post facto following WP:RIA, or if the source is unclear, you can add {{unattributed translation}} to the article. If you wish, you may also notify the user via {{uw-translation}}. Pro tip: if you want to know the exact text to use to attribute an original translation for a given article, edit the English article, add the Expand language banner for the correct language at the top, and Preview it. For example: for article Martinique, view the {{Expand French}} banner at the top, hit 'show' to expand it, and you will find the exact wording to use to attribute translated content for the article. Mathglot (talk) 07:18, 7 June 2024 (UTC)[reply]

Since the attribution for all other edits is in the page history it makes most sense to me that translations should also be mentioned in the edit summaries so all attribution is in one place. This applies to more than just translations but also any attributable copies from other sources. I do also like to see a talk page template for clarity, but ideally should should say when as it may no longer be true to say it currently is a translation. I personally don't like adding to the article as if feels unclear and possibly misleading to everyday readers: Articles are often started as translations but then some get completely re-writen over time making any "This article contains content translated from ......" statements potentially false. Lastly an edit summary is only removable by a sysop these other templates can be removed (or left incorrectly) by anyone. TLDR IMHO: edit summaries should be mandatory; talk page template recommended; article template discouraged. Cheers KylieTastic (talk) 08:43, 7 June 2024 (UTC)[reply]

@KylieTastic:, That's why the advice at WP:TFOLWP recommends the wording "Content in this edit is translated from..." for the edit summary, which remains true forever regardless what happens afterward. In the case of the (optional) {{translated page}} template, parameter |insertversion= is available to make the timing context clear; see for example Talk:ForGG or any of these transclusions of the template. If the wording is not clear enough for that case, you could raise a discussion at Template talk to request an improvement. Mathglot (talk) 19:50, 7 June 2024 (UTC)[reply]

For interwiki stuff I'll use the trans template on the talk, if a translation is being attempted. Its usually a partial translation with article expansion. I would never remove it even if the article was completely rewritten as they may be a sentence or two in there that needs attributed and that has happened. If on wikipedia, I'll search for the author and put their name in the edit summary. That is important, even though it takes some time. I would never mention attribution in the article for obvious reasons. Talk is ok, but its a boundary case as I'm struggling to think of an instance when you would need it. I agree with Mathglot above, the current arrangement is clear and well understood by everybody. New editors take to it quite quick. I've not seen a trans tag removed from talk at all, not even by a vandal or troll, although it is certainly possible. I've never seen the boundary case described by Mathglot above in action, although it must be possible. scope_creep^Talk 09:52, 7 June 2024 (UTC)[reply]

If you're trying to find the name of the original author, I have had some luck with Wikipedia:Who Wrote That? Run the tool, then click on the bit you're copying/translating. (It doesn't work on all languages.) WhatamIdoing (talk) 18:00, 7 June 2024 (UTC)[reply]

Or WikiBlame, which does work for all languages (even if there's no link to it from the History page). Mathglot (talk) 19:32, 7 June 2024 (UTC)[reply]

This can be a tricky situation, and the question of what is the best guidance for new articles isn't necessarily something that can be or should be attempted to be applied retroactively. Yes anything translated should give credit to the source. Yes, ideally this should be a link in the first edit summary. No, I don't think anything should be in the prose of the article about this. We have a {{Translated page}} template that can be helpful for the talk page for lots of reasons, anyone should feel free to put that on a talk page if it isn't there. Probably making an future edit with an edit summary attributing the remote page and date of the translation would be useful and could satisfy more licensing concerns. In certain cases, we can import the transwiki pre-translated history over, requests can be made at WP:RFPI; xwiki imports can be very messy and once there are overlapping revisions, or very many revisions - are normally a bad idea. — xaosflux ^Talk 18:51, 7 June 2024 (UTC)[reply]