Jump to content

Wikipedia:Village pump (policy)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Lurking shadow (talk | contribs) at 06:24, 20 October 2022 (→‎Draftify things, or improve-in-situ: Reply). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The policy section of the village pump is used to discuss already proposed policies and guidelines and to discuss changes to existing policies and guidelines.

Please see this FAQ page for a list of frequently rejected or ignored proposals. Discussions are automatically archived after remaining inactive for two weeks.


WP:proportion and terminology

Some terms used in a title of an article receive different definitions by different sources, but yet there is no fundamental disagreement between the sources, because there is an easy translation from one source to the other. For example, traditionally in science, "heat" was often used to mean the internal energy of the medium responsible for its temperature or, depending on the context, it could also traditionally mean the amount of energy transferred that cannot be explained by macroscopic work. More recently, a tendency can be observed to only use "heat" with the second meaning, but it's not universally adopted. For example, Nobel laureate Steven Weinberg is not strict about the use of the term "heat" in his recent 2021 book The foundations of Modern Physics, that is, he adopts the traditional approach in science. However, again, this is very superficial. I suspect Weinberg himself would find this issue completely unimportant, as long as it's clear what the term "heat" means in each context. I mention this, because then it does not seem appropriate to insist that both terminological approaches are presented in respect of WP:proportion, say in the article Heat, because, if we start to do that, then we start to discuss an issue that is not even discussed in the literature, because it's not important. Therefore, it should be acceptable in Wikipedia to agree among editors for a particular terminological approach and simply adopt it, even though it's not the unique approach used in the literature, that is, we can ignore WP:proportion for these terminological issues. Dominic Mayers (talk) 18:14, 3 October 2022 (UTC)[reply]

@Dominic Mayers, this is not a Wikipedia level policy consideration. If you want a wider view than you are getting at Talk:Heat raise the issue at Wikipedia talk:WikiProject Physics. StarryGrandma (talk) 00:02, 4 October 2022 (UTC)[reply]
I asked the question here, because I don't think the issue is specific to heat or even to physics. It's a very general fact that a word in a title can have different meanings (i.e., be given different definitions) in different sources, but it's nothing very deep, not as if it corresponds to different points of view : it's only a superficial change in definitions and one can easily translate from one source to another. They say the same thing in different languages. Still, in these cases, one definition for the term has to be used and editors can have to decide among them. It's a general policy consideration. In particular, I do not think that WP:proportion is a consideration in these cases. The specific definition attributed to the term should be chosen on the basis of other considerations, such as how easy it is for a general audience to understand the definition. However, of course, you are right if you meant to say that the specific case Heat can not be resolved here. I do not hope to resolve the Heat case here. That's not the goal. No, the goal here is only to consider whether or not, in general, WP:proportion is a strict criterion to apply in these cases. This would not resolve the specific case Heat, but it will be helpful in the process and not only for the Heat case. Dominic Mayers (talk) 01:00, 4 October 2022 (UTC)[reply]
I realize that the issue was not properly described. So, I retract the question. I will ask another question that hopefully would describe the issue more clearly. Dominic Mayers (talk) 00:34, 6 October 2022 (UTC)[reply]

Forcefully silently taken editorial decisions.

At several occasions I met a situation where editors must make a choice, say regarding a choice of terminology or regarding the scope of the article or any other consideration that is not uniquely determined by the sources and do not need to be verifiable. Of course, one cannot use a term that is not used in the sources, but when different sources use different terms interchangeably, then the editors must pick one of them. Similarly, the scope of an article is not uniquely by the sources. The exact scope of an article can be decided among the editors. There is no need to have a source that has the exact same scope. The most recent case is the article Heat. Some sources are picky about heat being defined as a special way of transferring energy and not as something that a medium can have. Other sources are less picky about this. However, no sources discuss that : it just a different technical way to use the term heat without any change in the underlying concepts. The details are not important. The point here is only that editors have to take a decision regarding the definition of heat in this case. It seems problematic that Wikipedia policy does not allow the editors to somehow describe the choices that have been made to write the article. Other encyclopedia are not so strict about that. The author of the encyclopedic article often describes that a particular terminology is used or that the scope was restricted in some way, etc. Why is this not possible in Wikipedia? Dominic Mayers (talk) 00:57, 6 October 2022 (UTC)[reply]

Keeping with your example, why not present the various ways heat is described in the various sources? If there is, as you say, no change in the underlying concept, then proceeding from the various descriptions should be no problem. I personally can't see the use of describing, in the article, how the article came to be written. Am I missing something? Primergrey (talk) 03:07, 6 October 2022 (UTC)[reply]
But at some point, to avoid confusing the reader, we would have to say that we picked one approach among the two terminological approaches. Otherwise, the reader would be left with a question in his mind : what approach will be used for the remainder of the article? As you suggest, this seems to be against policy, because we describe an editorial choice that was made. I feel that it should not be against policy to do that. Unless you suggest that we keep using both approaches for the entire article, but that would make the text very heavy. Note that I refer to approaches instead of definitions, because one approach is to be not so picky regarding the definition of heat and let the context determines in each case what is meant by heat. This is what is done traditionally. The other approach insists that heat must always be used to mean a particular way to transfer energy. So, it's not really possible to use both approaches anyway : we are picky or we are not. Dominic Mayers (talk) 03:58, 6 October 2022 (UTC)[reply]
Articles should be defining their scope early on in the lead section, including if the subject is based on usage in a specific field, or is covering usage across different fields. Often in the first case, the title will be refined to reflect this. In the case of the "Heat" article, the first sentence is defining the scope (with additional emphasis provided by the disambiguation note). isaacl (talk) 15:49, 6 October 2022 (UTC)[reply]
Can you give other examples besides the Heat article in which the scope, the terminological approach or another aspect of the article is clearly a choice made by the editors and the lead describes this choice, because the title and the disambiguation note are not sufficient. In the case of the Heat article, the first sentence is

Heat is energy in transfer to or from a thermodynamic system, by mechanisms other than thermodynamic work or transfer of matter (e.g. conduction, radiation, and friction).

It fails to describe a choice. Instead, it states in Wikipedia's voice one definition as if it was the unique possible definition, despite the fact that some sources are not so strict about this definition. I don't think this is appropriate. It violates neutrality, because it makes Wikipedia state in its own voice a definition that is not universally adopted in the literature. However, let's not focus too much on the article Heat here. It's the general case in which readers should be informed of an editorial decision (made by the editors) that should be discussed. Therefore, if you have examples where this issue shows up and was successfully addressed by the editors, which I believe is not the case in the Heat article, that will be good. Dominic Mayers (talk) 17:10, 6 October 2022 (UTC)[reply]
Scope is implied by the disambiguation note. Having the title limit scope would be more clear, as is done, for example, with the various articles listed under Engineer (disambiguation), or Identity. Two of the articles for "Identity" explicitly describe the scope in the lead sentence by starting with "In (field X)", which is a reasonable approach. isaacl (talk) 20:28, 6 October 2022 (UTC)[reply]
In the case of the Heat article, the issue is not the scope, but the definition of heat. The scope and the definition of heat are two separate things. Moreover, it's the general issue that must be discussed here. It's not the place here to focus too much on the Heat article. It's a good case, because an editorial decision is taken to use a particular definition, but nothing more than that. Dominic Mayers (talk) 20:50, 6 October 2022 (UTC)[reply]
Words can have multiple definitions which are used by people in different contexts. I used "scope" to mean the context in which the subject of the article is being discussed. I agree the definition is not the same as the context. isaacl (talk) 23:17, 6 October 2022 (UTC)[reply]

I'm sorry, but what policy is being discussed here? So far I just see a bunch of content dispute about Heat. --Golbez (talk) 21:48, 6 October 2022 (UTC)[reply]

  • In general, when sources use different terminology there is a reason why they do so. There may be an underlying controversy that we need to explain to the reader. So… Part of our job is to lay out for the reader: a) who uses the various terms, and b) why they do so. Blueboar (talk) 22:03, 6 October 2022 (UTC)[reply]
    Assuming it's relevant. The Brits add some extra vowels into various terms (foetal, leukaemia), and I never feel any need to explain why. WhatamIdoing (talk) 22:49, 6 October 2022 (UTC)[reply]
  • The nature of a Wikipedia article sometimes means that we cannot follow the structure of our sources. The scope of an article is a common editorial decision. So too is many aspects of its eg whether to use a chronological or topical approach. Other editors may make different editorial choices than I would make, and there is nothing wrong with that. You're quite right in that these are generally implicit, and usually non-controversial. Where the matter deserves discussion, the talk pages are there for that purpose. Hawkeye7 (discuss) 22:19, 6 October 2022 (UTC)[reply]
  • If you start by identifying the three (or five or ten or however many) best sources for the article, all the other questions will be answered. If you start by trying to write the article first and then backfilling sources, you run into these problems. To take the Heat example: what are the three best books about heat, and how do they define it? Levivich (talk) 22:40, 6 October 2022 (UTC)[reply]
    • And, more to the point, which sources will allow you to write an article that is accessible to most people? I am an educator, and regularly have to caution my students to not use Wikipedia for technical subjects. Consider, for example, USB or WiFi which make the subject far less understandable than would normally be the case from a "standard" encyclopedia. And let's not start on mathematical subjects... Black Kite (talk) 22:51, 6 October 2022 (UTC)[reply]
  • I think Dominic Mayers is basically correct. You can't always write an article based on using the exact language in the sources. Sometimes the language in the sources is too technical. Sometimes it's too slangy. Sometimes it uses the "wrong" WP:ENGVAR. There's also the problem – see Heat, apparently, but see also Ketogenic diet and many others – of the Wikipedia:Article titles and scopes process not being obvious, so people turn up on the talk page demanding that my subject be recognized as the One True™ Subject for this name, because the Ghits for this word are talking about my thing, so my thing belongs at this title, and who cares about your stuffy old contents? Heat is obviously supposed to be about what keeps my house warm during the winter, and the keto diet is the thing my bodybuilder friends do. Similar problems can be seen at most contentious discussions about WP:COMMONNAME.
    Our advice on this subject mostly comes from WP:FIRST, which advises editors to follow the example set by FAs in similar subject areas. I would be happy to see this expanded upon, perhaps in NOR's WP:STICKTOSOURCE section, to say that there is no substitute for knowing what the sources mean when they use a term, and being able to translate that into clear, informative English. That might (eventually) discourage people from saying that Truck needs to wobble confusingly between truck and lorry and vehicle depending on which source happens to be at the end of the sentence. "Stick to the individual source" or "Stick to the use in most sources currently cited in this article" can be abused to push a POV, especially for shorter articles (which is most of them: the median article is a stub). We do not want to set up rules that would make it easy for someone to replace most of the sources in our articles about Ukrainian cities with sources that "just accidentally happen to use" the Russian spelling for the city, and then say "Oh, but I have to spell it the Russian way, because Policy Says™ I have to stick to the terminology in the sources". WhatamIdoing (talk) 23:24, 6 October 2022 (UTC)[reply]

Edit conflict: I haven't read the comments that follow the comment of Blueboar. @Golbez: Blueboar has understood the policy that is at stake here. He says that the issue (whether it is about scope, terminology or any other aspect) must be discussed by the sources. The policy is verifiability or any other policy that implies that we cannot have a content that is not verifiable in the sources. The problem is that often it would be useful to describe an editorial decision, but an editorial decision is formulated in a way such as "Some authors use this approach. Other authors use this other approach. In this article, the approach of X is adopted." This is not something that can be verified, because it is a decision local to Wikipedia. Perhaps the last sentence can be considered verified, but the description of the decision must go beyond that. It must make clear that a decision was taken. It seems against neutrality to take this decision silently as if it was the unique possible choice, as for example, it is done in the Heat article. Instead, what seems more neutral is to mention the different choices and say some thing like "This article adopts the definition of X" and the readers will understand that a choice had to be made. I would like that an approach of this kind to be considered valid in Wikipedia. A key point here is that WP:proportion or anything like that are not the concerns here, at the least, not the unique ones. No, the editors can take the decisions because of aspects unique to Wikipedia, the fact that the context is different, etc. Yet, the readers must be informed that a decision was taken. These decisions cannot always be taken silently. Dominic Mayers (talk) 23:15, 6 October 2022 (UTC)[reply]

@WhatamIdoing: What you are discussing is important, but my point is more basic here. I am not discussing whether an editorial decision is better than another one. I am just saying that, at the least, the reader should be informed that an editorial decision was taken with some context that allows this reader to understand that, for example, a more technical definition was adopted than one would expect. At the least, he will know that and he will be less lost. Dominic Mayers (talk) 23:34, 6 October 2022 (UTC)[reply]

We do that, sometimes, in a few articles. Consider these:
Search for the words "this article" in each of these. WhatamIdoing (talk) 23:45, 6 October 2022 (UTC)[reply]
I searched for other articles (excluding list articles) that also use "This article" with a similar purpose:
Editorial decisions are indeed some times described in the article. This appears to violate the principle that a WP article should only say what the sources say : no source will describe a decision taken by editors in the WP article, for the obvious reason that it is a choice specific to the WP article. Therefore, many editors, not just me, might feel that they should not do that. However, this is a valid exception and it should be stated explicitly in WP policy that this is fine. Dominic Mayers (talk) 15:34, 7 October 2022 (UTC)[reply]
Taking a quick look at these, and the presence of "this article" is a code smell that indicates the article needs to be improved. If the subject is ambiguous, that's what disambiguation pages are for. If you don't want to handle other aspects (like ŁKS Łódź) then that should either call for an expansion request or a red link to a future article for the other sports. So I disagree that it needs to be stated explicitly that it's fine. It's not. --Golbez (talk) 17:07, 7 October 2022 (UTC)[reply]
I agree that editorial decisions can be wrong. They can create a bias, lack of neutrality, etc. It can even be the case in some of the examples provided. I did not filter them. But, I disagree that it is possible to never take editorial decisions. I certainly disagree that when they are taken, they must always be taken silently. On the contrary, it's more transparent and informative for the readers when they are not taken silently. Dominic Mayers (talk) 17:16, 7 October 2022 (UTC)[reply]
The use of "this article" in an article indicates a problem with the article. Levivich (talk) 18:33, 7 October 2022 (UTC)[reply]
Wikipedia:Manual of Style/Self-references to avoid#This Wikipedia article discusses ..., While Wikipedia is not a ..., Edit this page ... disagrees. * Pppery * it has begun... 18:50, 7 October 2022 (UTC)[reply]
Indeed, thanks * Pppery *, the guideline says clearly that an article can refer to itself. It says "... articles may refer to themselves ...". The context is that an article cannot refer to the Wikipedia's rules, because it prevents its use outside Wikipedia, but the article can refer to itself. Dominic Mayers (talk) 19:33, 7 October 2022 (UTC)[reply]
While an article can or may refer to itself, it shouldn't. Levivich (talk) 21:11, 7 October 2022 (UTC)[reply]
This is not what the guideline says. It contrasts two cases: a reference to the article itself and a reference to Wikipedia's rules. It says while the first case may happen, the second case should not happen. Dominic Mayers (talk) 22:15, 7 October 2022 (UTC)[reply]

Email policy?

An issue recently came up (discussed off-wiki, details not important) where somebody was using Special:EmailUser to send a messages to a large number of users on a topic which was marginally related to enwiki but basically WP:NOTHERE and WP:PROMO. As far as I can tell, we don't have any policy with explicitly prohibits that. WP:EMAIL (which isn't even policy) mostly talks about privacy concerns. All the other policies I can find are concerned with things that happen on-wiki.

I think we need an explicit policy statement which says: "The wikipedia email facility is intended to support the goal of building an encyclopedia. Use of this facility for any other purpose constitutes abuse and is prohibited". Or do we already have such a statement and I just haven't found it yet? -- RoySmith (talk) 17:09, 7 October 2022 (UTC)[reply]

I haven't found anything relevant on en.wp. The terms of use prohibit
  • Engaging in harassment, threats, stalking, spamming, or vandalism; and
  • Transmitting chain mail, junk mail, or spam to other users.
Which the preceding issue at least arguably comes under (especially given the volume), but might not in all cases so I think having something along the lines you suggest would be good. The one caveat to that is that it should be enforced with common sense giving established users a little leeway in the same spirit we allow them use of userspace for occasional small-scale off-topic matters as long as they don't take the piss. Thryduulf (talk) 17:36, 7 October 2022 (UTC)[reply]
As far as the "large numbers" part - there should be a throttle on this action, depending on your definition of "large". — xaosflux Talk 18:00, 7 October 2022 (UTC)[reply]
I've added this text to WP:EMAIL. That should cover it. -- RoySmith (talk) 21:23, 8 October 2022 (UTC)[reply]
That's a good and well worded addition that I agree covers everything. Thryduulf (talk) 22:28, 8 October 2022 (UTC)[reply]
I don't exactly disagree, but I expect that to produce complaints when editors have differing views about what supports the goal of building an encyclopedia, and what constitutes "substantial". There is a throttle in place; I think it's only possible to send 20 e-mail messages per day. WhatamIdoing (talk) 19:38, 17 October 2022 (UTC)[reply]

Fractions

I'm unsure if this is the right place to raise this topic, so if it isn't, my apologies in advance. Some time ago I noticed that a fraction was used in an article (e.g. 12). The fraction affected the line spacing, so I replaced it with ½, because ½ is in the list of symbols. However, the change was quickly reverted. (There are other symbols for ¼, ¾, and eighths.) Is it Wikipedia policy not to use the symbols that are readily available? Prisoner of Zenda (talk) 00:05, 8 October 2022 (UTC)[reply]

Might I suggest that WT:MOS would be a better place for a question of this nature. -- RoySmith (talk) 00:13, 8 October 2022 (UTC)[reply]
You'll also want to see MOS:FRAC. -- RoySmith (talk) 00:14, 8 October 2022 (UTC)[reply]
Thanks, @RoySmith. MOS:FRAC has "If ¼, ½, and ¾ are the only fractions needed, they may be used in an article body, article title, or category name, maintaining typographical consistency within an article where possible." Since the changes I made (on 23 July 2021) were to 212 and 112 (to 2½ and 1½ respectively), and they were the only fractions in the article, they shouldn't have been reverted. Maybe the bot was given a clip over the ear, because my change to 34 on 7 Jan. was not reverted. :) Prisoner of Zenda (talk) 09:27, 16 October 2022 (UTC)[reply]
@Prisoner of Zenda None of your edits were reverted by bots, they were reverted by other human editors. Your edit on the 23rd was probably reverted because you replaced the conversion templates with hardcoded unit conversions in addition to adding precomposed fractions. 192.76.8.81 (talk) 14:41, 16 October 2022 (UTC)[reply]
Thanks, 192.76.8.81 - but ½ was the only fraction in the article, so I figured it complied with MOS:FRAC (see extract above). Apparently not; can you enlighten me? Even if I did transgress by replacing "the conversion templates with hardcoded unit conversions in addition to adding precomposed fractions", that didn't change the sense of the article one iota. Prisoner of Zenda (talk) 01:23, 20 October 2022 (UTC)[reply]

Georgia v. Public Resources.org and {{PD-EdictGov}}

I am posting this here, instead of on WP:CP or WP:CQ, since it's not about a specific file, but a template that states copyright policy.

The {{PD-EdictGov}} template, while not wrong, and used across multiple wikis in the exact same form... is bad. It doesn't actually explain anything, or tell you "why": it only refers to the Compendium. Old conversations, linked from the talk pages of this template across multiple wikis, make it clear that questions about "why", since it's not stated in 17 USC, and "what does this actually mean", since it's buried in the depths of history, and "why are we listening to the Compendium about something that isn't in 17 USC", abounded, and were never really answered.

The decision in Georgia did not change this rule. What the Supreme Court did, in Georgia, is to validate a argument that actually places the "government edicts principle" on a basis that isn't buried in the depths of 200+ year old legal trivia...it instead divorces the "government edicts principle" from the vague "for reasons of public policy" justification, and places it on the grounds of fundamental copyright principles; giving us, in a way, a test that is actually usable, instead of just having to know "what is or is not an edict" and requiring a knowledge of the incredibly obscure history to actually get it.

Edicts of government are basically the same thing as monkey selfies.

To actually understand this.... unfortunately, the Compendium, and the Georgia decision, and even the English Wikipedia article on "edicts of government" don't give the needed context, which gets into obscure facts of history and the way copyrights actually came into being in the US: the history of "common law" in the US, and the exact intention of Congress when passing the Copyright Act of 1790.

I have started a discussion, on the English Wikipedia, at w:Talk:Edict of government#Georgia v. Public.Resource.Org Inc. and the public policy argument, with what is essentially a long screed, explaining what the Court was telling us in Georgia, what they were actually telling us about this in Wheaton v. Peters, back in 1834, when actually first validating the "government edicts principle" as law in the US, and giving the "common law in the US" context to understand why it's not written down.

I'm mentioning this here, and intend to post this message across multiple wikis, to attract interested editors.... not to canvass for a discussion there, to change the article, but to achieve a consensus there, about rewriting that article so that it is based on something other than "the Compendium says so", that it can be used (the article, and the consensus) to rewrite this template on every wiki so that it actually says something useful, instead of the just "because the USCO says so" that seems to have been the conclusion of most discussions about this subject.

As a footnote, this doesn't apply to most edicts of the US federal government... since the definition of "works of the US Government" specifically says "prepared by", and doesn't require authorship, it includes such edicts. They are denied protection separately. Jarnsax (talk) 23:49, 8 October 2022 (UTC)[reply]

Regular users threatening others with bans

On any other website out there, if a regular user threatens another user with a ban, they would get chewed out for impersonating a mod and overstepping boundaries. Users who do not have the ability to ban users should not be permitted to leave threatening ban warning messages. That is a job for mods and/or people who actually have the ability to hand out the ban. I have seen countless instances of users with no administrative power whatsoever handing out these ban messages like candy to anyone they're in a disagreement with. It's fear-mongering towards inexperienced users, and it's just disingenuous in my opinion.

Ban warnings should only be given out by people who can actually ban you. This prevents them from being misused. (inb4 someone uses the ban warning I was just given as justification, as if that's the ONLY time this issue pops up) 2604:3D08:7481:AF00:9C4C:1DD6:DE9D:5241 (talk) 02:49, 9 October 2022 (UTC)[reply]

Wikipedia works on the principle that if someone sees a problem they should try to fix it. If a non-admin user sees someone making edits that violate policy, the user should let the person know what the problem is. The alternative of interrupting an admin and requiring that they intervene would be too cumbersome and unable to scale to deal with the many problems. Johnuniq (talk) 03:01, 9 October 2022 (UTC)[reply]
Furthermore, contrary to the OP's claims otherwise, the talk page messages and edit summaries used by this IP were personal attacks / incivility that definitely merited at least a warning [1] [2] [3] and they were not being warned as "fear-mongering" or because they were in disagreement with another editor. 163.1.15.238 (talk) 17:03, 10 October 2022 (UTC)[reply]
  • Warning a disruptive editor that they might be banned is not a “threat”. It is a courtesy, giving them a chance to change their behavior. Blueboar (talk) 17:23, 10 October 2022 (UTC)[reply]
  • IP, should you believe you have seen cases where a non-admin editor is handing out unjustified warnings that would be unjustified even if an admin did them then you should first communicate with the editor or, if a recurring issue, raise with an admin or on ANI. If you see cases where a non-admin is handing out warnings that would be justified if an admin did them then there's no issue. — Preceding unsigned comment added by Nosebagbear (talkcontribs) 09:28, 12 October 2022 (UTC)[reply]
  • I think there's an important distinction to be made here between a warning ("You may get banned") and a threat ("I will ban you"). The former is commonly used, also by non-admins, and is not a problem. The latter is, I think, inappropriate for non-admins to use. --rchard2scout (talk) 16:50, 12 October 2022 (UTC)[reply]
  • I agree with Johnuniq, Blueboar and Nosebagbear. I think there may be confusion between a block, which can only be imposed by an administrator, and a ban. The authority to ban resides with the community, ArbCom and WMF. They are the only people with the ability to hand out bans. However, all three can delegate that authority to impose bans on such terms and conditions as they see fit, and there is nothing to stop it being delegated to non-admins. It has long been accepted that non-admins have the ability to ban editors from their own talk pages. Hawkeye7 (discuss) 19:53, 12 October 2022 (UTC)[reply]
  • But it doesn't matter whether it's a block or a ban. As Blueboar says, a warning of either is a warning, not a threat, so anyone receiving one should be grateful rather than complain about it. We shouldn't care about what other web sites might do, because Wikipedia is a work place to create an encyclopedia, which "any other website out there" is not. Phil Bridger (talk) 20:36, 12 October 2022 (UTC)[reply]
For reference, here is the current template for the strongest vandalism warning:
Stop icon This is your only warning; if you vandalize Wikipedia again, you may be blocked from editing without further notice.
Notice that even it does not say who the block will come from; just that the block may happen (and strongly implying that it will). When used properly, this is correct even if the user leaving the warning has no authority - I'm not a cop, but I can tell my friends "if you rob a bank, you may get arrested". It's just a warning that their actions will have consequences, and if they wish to avoid those consequences, they should stop. WPscatter t/c 16:28, 16 October 2022 (UTC)[reply]

Article title of Religion Nisei

Recently the new article Religion Nisei was created and I don't think the title to properly conforming to our Wikipedia:Naming conventions (use English) guideline. "Nisei" (二世) is a transliteration (romaji) of the Japanese term which means the "second generation". According to the English versions of few reliable Japan's media, "second generation" is exactly used instead of the transliteration,[1][2][3] but the article creator user:Penerrantry believes otherwise. I'd like more opinions from other editors who are familiar with Japan-related articles on English Wikipedia. -- Sameboat - 同舟 (talk · contri.) 06:24, 11 October 2022 (UTC)[reply]

I believe that the word "nisei" has become incorporated in the US English lexicon. A simple search of Google News finds thousands of uses of "nisei" in news stories in publications across the country, especially in outlets on the US West Coast. I also note that "Nisei" does not appear as a misspelled word in many word processing applications, including Wikipedia's text editor. - Enos733 (talk) 15:43, 12 October 2022 (UTC)[reply]
@Enos733 and Penerrantry: My problem is that nisei seems to only denote "second generation of Japanese migrant (in the US)". It is the "migrant" part that I am having trouble with because "religion nisei" has nothing to do with "migrant" at all. Also I checked the online version of Oxford and Cambridge English dictionaries which don't have the "nisei" entry. Both dictionaries have entries from modern culture like mod, so I am not so sure how incorporated "nisei" has become in the English lexicon. Leaving "nisei" untranslated in "religion nisei" seems to do more harm. -- Sameboat - 同舟 (talk · contri.) 00:36, 13 October 2022 (UTC)[reply]
I would also like to point out that there is a Wikipedia article on Nisei. While there may be some differences with this particular article, I believe our community has accepted "nisei" into our lexicon. - Enos733 (talk) 02:15, 13 October 2022 (UTC)[reply]
"Nisei" may be accepted in the American English lexicon, but "religion nisel" is a totally different story. There are only 8 results of "religion nisei" from my google search, so it's safe to say that we are inventing a new term by ourselves when the major English media sources avoid leaving it as is, including BBC[4]. I really want you to give further consideration in this regard. -- Sameboat - 同舟 (talk · contri.) 02:26, 13 October 2022 (UTC)[reply]
I believe the current title likely fails Wikipedia's policy on neologisms. As mentioned, the term Nisei generally refers to first-generation immigrants in the English context. As most news organisations translate the term in this context (I can't find a reliable English-language source that doesn't), I think this should be renamed. -- QueenofBithynia (talk) 22:08, 18 October 2022 (UTC)[reply]

References

I just created Wikipedia:Impersonating an administrator (it is still rather stubby) as an essay, and I am actually rather surprised that I was unable to find a policy page saying that a non-administrator pretending to be an administrator is not okay. If I'm missing something, please point me to it, but this should actually be a policy. BD2412 T 05:09, 12 October 2022 (UTC)[reply]

Wary of WP:BEANS. I'd assume handling impersonation would be common sense and akin to WP:MISLEADNAME.—Bagumba (talk) 07:21, 12 October 2022 (UTC)[reply]
I'm not quite as WP:BEANS-wary—it's pretty easy to see if someone claiming to be an admin is or is not one. BD2412 T 15:29, 12 October 2022 (UTC)[reply]
I'm sure it's easy for experienced editors & admins like you two "to see if someone claiming to be an admin is or is not one", but the most useful content in the essay would be to explain exactly how to do this, which the essay doesn't address at all! Johnbod (talk) 15:34, 12 October 2022 (UTC)[reply]
@Johnbod: Good point. BD2412 T 19:22, 12 October 2022 (UTC)[reply]
  • I have a quibble with one of your examples in the essay… saying “I will block you” or “I will delete this article” isn’t necessarily an assumption of Admin power. It’s more a mid-statement of procedure. We have mechanisms in place, after all, where non-admins can get someone blocked, or can get an article deleted. Ok, technically They need to involve actual admins to push the button, but when there is a serious issue, actual admins are happy to oblige. Blueboar (talk) 19:55, 12 October 2022 (UTC)[reply]
    • @Blueboar: You are, of course, welcome to edit the essay to clarify this, but there is a clear distinction in my mind between an "I will block you" kind of statement and an "I will get you blocked" kind of statement. BD2412 T 20:03, 12 October 2022 (UTC)[reply]
    I think it would be nice to warn against that kind of language without suggesting it's always impersonation. It is reasonable to conclude that someone saying either phrase has the ability to follow through single-handedly. On a related not, I'd like to see the essay/policy/guideline explicitly endorse the continued use of templated warnings, many of which say something like "You may be blocked from editing if ...", as I do see new editors every now and then upset that non-admins have posted such warnings. If not addressed, I think we'll see such editors citing WP:FAKEADMIN. Firefangledfeathers (talk / contribs) 20:07, 12 October 2022 (UTC)[reply]
  • Wikipedia:Talk page guidelines § Behavior that is unacceptable states the following: Do not claim to be an administrator or to have an access level that you do not have. User access levels can always be verified at Special:ListUsers. isaacl (talk) 21:27, 12 October 2022 (UTC)[reply]

Multiple data points in a single table cell

This is something I've long been in disagreement with the community so to get me to shut up, I'd like to have this decided. So. In list tables for politicians, the trend appears to be towards including more information about them, rather than less; I say this damages accessibility, semantics, and adds little information to the article.

Here are two sample entries from List of Governors of Alabama:

Governors of the State of Alabama
No. Governor Term in office Party Election
13 Reuben Chapman
    July 15, 1799 – May 17, 1882   
(aged 82)
December 16, 1847

December 17, 1849
(lost renomination)
Democratic 1847
13 Reuben Chapman December 16, 1847

December 17, 1849
(lost renomination)
Democratic 1847

The first row contains multiple datapoints: Name, lifespan, and age on death. To accomplish this requires extra formatting, such that the using of ! to begin a table cell to emphasize it as the scope of the row, as per Help:Table: "Row headers are identified by ! scope="row" | instead of |". The second row has how I think it should be, for the focus of the row: Just the name. My complaints go past the accessibility issues to the fact that I don't feel the lifespan adds anything to an understanding of the subject, which, in this specific case, is "list of governors of Alabama." Getting deeper info on a governor, beyond that which is immediately relevant to them being on the list of governors, is as easy as clicking their name. But, the accessibility issue is a bigger concern than me saying "i don't like it".

(note: yes, the next column also contains two datapoints, and I'd be willing to discuss that too if necessary, but my point here is that the governor, the scoped cell of the row, is one where we want to be as clear to the reader (and their tools) what the datapoint is, right?)

If there's a better place to discuss this please point the way, but it's time for my one-man crusade to end, one way or another. I think the method used in the first row is unsound, and I would like to know how the community feels. I figure this could go to an RFC but I wanted to check here first to see if I am just completely off base and not even go that far. --Golbez (talk) 20:29, 12 October 2022 (UTC)[reply]

I've no objections to removing the governors birth & death dates. GoodDay (talk) 21:44, 12 October 2022 (UTC)[reply]
I would object to removal, as this will likely impact all lists like this. I supported the initial proposal to add these dates to the List of presidents of the United States, and it's based on the reasoning I gave there that I oppose this here. - wolf 22:08, 12 October 2022 (UTC)[reply]
Support, oppose - who said anything about a vote? This is about factfinding. If the first one is in fact inaccessible, then it doesn't matter how much you support it, it shouldn't happen. --Golbez (talk) 04:11, 13 October 2022 (UTC)[reply]
Thanks for the link, @wolf. I notice several supporters at that discussion clearly wanted it limited to year and not full DOB: birth and death year in small text, Year only, to avoid cluttering, more is better, unless it's too much. ⁓ Pelagicmessages ) 23:51, 14 October 2022 (UTC)[reply]
I would consider the first example to be unnecessarily confusing. It is not at all obvious that a date range in a list of holders of some particular office is their lifespan; it might alternatively be their term in office. In this particular example, the fact that the date range is 82 years wide suggests that it is in fact a lifespan, but parsing that requires extra mental overhead. If lifespans are useful information in this kind of table, I would think it makes much more sense to list it as a separate column of the table (which would also have the benefit that it could be sorted on in a sortable table). If it's not important enough to get its own column, is it important enough to list in the table at all? Caeciliusinhorto-public (talk) 15:43, 13 October 2022 (UTC)[reply]
@Caeciliusinhorto-public: It's clearer on the List of presidents of the United States; the column heading is "Name (Birst - Death)", and the next column is "Term" so, no confusion, just readily visible and useful information. (fyi) - wolf 16:21, 13 October 2022 (UTC)[reply]
I would agree that the example at List of presidents of the United States is clearer, both because the table heading explicitly says what the dates are and because the age at death isn't also included as a third data point in the same cell. I still think that it's clearer for each column to cover one piece of information. Caeciliusinhorto-public (talk) 08:18, 14 October 2022 (UTC)[reply]
If you have to have birth and death dates (which I don't understand) then it should be in a separate column. Just saying it's a lot of work to fix doesn't make it suitable to retain. This table is against WP:ACCESS for many different reasons. Lee Vilenski (talkcontribs) 10:31, 14 October 2022 (UTC)[reply]
MOS:DTAB (and its how-to MOS:DTT) is generally quite clear on how data tables should be formatted for screen readers (which is the WP:ACCESS issue I am assuming you are referring to). You need a good reason to do something that fails WP:ACCESS, saying that, multiple data points in a single field is not in itself anti-accessibility providing the table is formatted correctly. What is the exact accessibility issue here? Is the first not rendering correctly for screen readers? Only in death does duty end (talk) 11:00, 14 October 2022 (UTC)[reply]
I don't know, I don't have one; that's why I'm asking. One thing I do know is that the first one lacks scope=row, which would seem to be less accessible; and a screenreader would presumably say that the 13th governor of Alabama was Reuben Chapman July 15 1799 May 17 1882 aged 82. But I don't use one so I don't know. --Golbez (talk) 13:16, 14 October 2022 (UTC)[reply]
First of all, this is a sortable table with three things it could be sorting for. Why wouldn't you have a column for the dates? Why do you require more than one piece of information in a cell? Lee Vilenski (talkcontribs) 20:04, 14 October 2022 (UTC)[reply]
Governors of the State of Alabama
No. Governor Born Died Age at death Start of Term in office End of Term in office Party Election
13 Reuben Chapman
July 15, 1799 May 17, 1882 82 December 16, 1847 December 17, 1849
(lost renomination)
Democratic 1847

(Reply here for lvl-1 indent with reply tool) ⁓ Pelagicmessages ) 22:33, 14 October 2022 (UTC)[reply]

Instead of more data in few columns, the third option is more data in more columns. This helps column sorting and copy-paste reuse, at the expense of readability and layout. I think the data-oriented table goes against the spirit of a "list article". ⁓ Pelagicmessages ) 22:33, 14 October 2022 (UTC)[reply]
More specifically, for people, I don't mind years as qualifiers Reuben Chapman (1799–1882): that's done a lot in art-gallery and library cataloguing, and is easily parsed out. The full date of birth and death seem off-topic for a list of governors, though. ⁓ Pelagicmessages ) 22:33, 14 October 2022 (UTC)[reply]
Agreed. - Enos733 (talk) 21:09, 15 October 2022 (UTC)[reply]

For the record, this is an example of an entry at List of US Presidents;

List of presidents of the United States from 1789 – till date.
No. Portrait Name
(Birth–Death)
Term Party Election Vice President
1 Painting of George Washington George Washington
(1732–1799)
April 30, 1789

March 4, 1797
Unaffiliated 1788–89

1792

John Adams

Unlike the Governor's table being debated above, there is no detailed birth and death dates, just the years, and there is no age at death. I'm not sure there is a need for such details, but I am sure there is no need to create three extra columns just to include such details. - wolf 23:15, 14 October 2022 (UTC)[reply]

(ec, or rather simultaneous post) Indeed, I replied to similar effect further up. Apologies for forking. :) ⁓ Pelagicmessages ) 00:18, 15 October 2022 (UTC)[reply]

So does no one here really know about the accessibility issues in removing scope=row and adding multiple data points in a cell? --Golbez (talk) 13:33, 17 October 2022 (UTC)[reply]

A very wide table has a different sort of accessibility problem: it's very difficult to read on a smartphone. WhatamIdoing (talk) 19:46, 17 October 2022 (UTC)[reply]
Okay but I didn't ask about a wide table. --Golbez (talk) 19:52, 17 October 2022 (UTC)[reply]
@Golbez: For accessibility, so that non-visual browsers correctly understand the table, each row in a table should have one cell that is marked as a header cell (with !scope=row). Those cells should be the "primary" column of the table, e.g. it should "define" the row and you shouldn't be seeing a lot of duplicates. So, in the Governor example, is that the row about Reuben Chapman? Or is it the row about the 13th Governor? Either is fine. Ideally, the primary cell should also be the first cell, but it doesn't have to be. It does look better that way, though.
In regards to multiple data points, for non-visual accessibility just read it out to yourself (or if you have a mac, command-F5 to turn on voiceover. "Governor. Reuben Chapman July 15, 1799 May 17, 1882 aged 82". Is that enough context, on its own, that you knew what was said? I think it's almost fine- what's missing is what's in the President list, the (birth-death) line in the header, which would make it "Governor birth death. Reuben Chapman July 15, 1799 May 17, 1882 aged 82".
There's also the concern of it being cluttered, which can be an accessibility problem for people with poor eyesight or just visually overwhelming for anyone. Consider doing what the President list did, and making the birth-death bit just (1799-1882), and leaving the details up to the article. --PresN 14:33, 19 October 2022 (UTC)[reply]
Yes, I agree, there should be a scope=row, which is not possible unless we want the entire lifespan bolded, which is a bit much.
I would say the row is about Reuben Chapman, who was the 13th governor. Put in another example, Grover Cleveland properly shows up twice in a list of US presidents, and both times it is he who is the scope of the row, not the number of his presidency. However, I could see arguments both ways; as you said, there shouldn't be many duplicates, and if we are being strict about "list of presidents" and not "list of presidencies" then yes, one could suggest that he only appear once, and a list of presidencies/presidential terms would include him twice, with the number as the scope cell. And that's a viable discussion but beyond the scope of this one I think.
As for that, okay, so a screen reader will read this (without knowing it's the primary cell, mind you) and that seems like really poor form. Why is it that every other column should get clean data but the governor column, the primary column, throw three facts at the reader?
I consider the "what should we do otherwise" to be outside the scope of this, but, eh, this discussion is dying and I'm too lazy to make an RFC so why not: Why do we even need to include their lifespan to begin with? It adds absolutely nothing to an understanding of the subject, adds maintenance concerns, and opens the door to other pieces of info like spouse, birthplace, etc., which have similarly zero to add to the understanding of the subject. --Golbez (talk) 16:32, 19 October 2022 (UTC)[reply]

TechConductCommittee acts like a cabal.. sanctions?

The TechConductCommittee blocks users from technical spaces without providing sufficient information on why exactly. See this topic about MZMcBride's block by Liz and the warning I got. It's like a small scale Framgate.
This kind of, to quote Anomie, secret court ultimately ends up being harmful for this project too. If users get blocked without sufficient information and/or warnings, that's a serious problem. English Wikipedia (and all other projects) are interwoven with the technical spaces. We need each other. Secret courts with zero accountability have no place in that.
After thinking about this, I was only able to come up with one solution: block all members of the TechConductCommittee from English Wikipedia. I know that sounds ludicrous, but sadly I am dead serious in thinking that's the only way up. An unaccountable secret court is a threat to this project. This block would not be punitive: once they reform they can be unblocked.
It would be nice if someone else could come up with an equally effective but less rigorous method, but I sure can't think of any. I'd really wish I could, especially considering it seems doubtful this idea would garner much support. But discussing this might lead us somewhere.Alexis Jazz (talk or ping me) 15:45, 16 October 2022 (UTC)[reply]

The Tech Conduct Committee is a secret tribunal, a star chamber for sure, as you can see on the MZMcBride topic thread, where we have been assured that there is plenty of damning evidence, but the only links to evidence provided thus far have shown low-grade to moderate incivility that would result in a level-one warning (accompanied by links to diffs!) here at en.WP. If en.WP chooses to pursue a conditional block of those editors, what would the policy or guideline rationale be? If we choose to follow the path of evaluating a potential block, we should certainly act with integrity and transparency by using one of our established processes, notifying all affected parties, citing relevant policies or guidelines, and presenting relevant evidence. – Jonesey95 (talk) 00:31, 17 October 2022 (UTC)[reply]
TechConductCommittee is a role account for a wiki that is not this one. Well i have my own objections to the whole thing, it is for mw.org to figure out how we want to be governed not en-wikipedia. If you somehow think its contrary to the principles of Wikimedia, you could start a discussion on meta, but it is not any of english wikipedia's business. Bawolff (talk) 01:59, 17 October 2022 (UTC)[reply]
Jonesey95, the rule might be something like "If you serve in a function on a Wikimedia project where you block users or otherwise restrict their access to parts of Wikimedia, you must always provide the blockee with the exact links or quotes of their offenses that are the rationale of their block. Your process must also include that the community can overturn any block for which no charges were pressed with the authorities of the relevant government."
Well i have my own objections to the whole thing, it is for mw.org to figure out how we want to be governed not en-wikipedia. If you somehow think its contrary to the principles of Wikimedia, you could start a discussion on meta, but it is not any of english wikipedia's business.
Unfortunately, it is. We can pretend to be isolated islands, but we're not. They don't want to be blocked from enwiki any more than we want to be blocked from the technical spaces. English Wikipedia can't decide how mediawiki.org governs itself. I doubt anyone can, even if the community there collectively voted to dissolve the TechConductCommittee, I don't believe they would go down without a fight. But we can decide what's acceptable. And if anyone decides to harm Wikimedia as a whole, even if they don't do it on enwiki specifically, we could decide that's not OK. MediaWiki suffers from severe survivor bias, it's unlikely that community can reform itself at this point without outside help.
There is actually a kind of precedent for this: m:Requests for comment/Global ban for Kubura. Kubura created such extreme survivor bias on hrwiki as a corrupted admin and crat that they couldn't be blocked on hrwiki. So they got globally banned.Alexis Jazz (talk or ping me) 03:28, 17 October 2022 (UTC)[reply]
Jonesey, let's not hold up English Wikipedia's enforcement of our policy on civility as the shining example to compare TCC to. While there are some valid criticisms (transparency dominant among them - I share no love for the TCOC and its committee), that's not the one we should want to chase.
To some degree, there is hope on the transparency front: the UCOC will bring the TCOC under its umbrella (maybe even cause the TCOC to go away) and the expectations for the assorted committee should provide good cause for that group to adjust. And if they don't, that can be heard by the U4C (systemic issues). Izno (talk) 17:17, 19 October 2022 (UTC)[reply]

BLP: Replacement of images at subject's request

EDIT: Thanks to suggestions in the replies here, I have written this proposal into an essay. It is accessible at Wikipedia:I look ugly in this! with shortcuts WP:ILOOKUGLY and WP:BADHAIRDAY. — Preceding unsigned comment added by Wpscatter (talkcontribs) 08:58, 19 October 2022 (UTC)[reply]

Failing to find policy that addresses this specific case, I would like to propose one.

In the case that the subject of a BLP article wishes to have their photo removed from the article, we can use that as sole justification to replace it, regardless of the subject's reasoning, provided:

  • The new photo is also freely licensed,
  • The new photo is generally representative of the subject, and
  • The new photo is suitable for the article, equally or more so than the original.

If the subject suggests a particular image to use instead, we should make an effort to use it provided it meets the above criteria.

I am not proposing any of the following:

  • That we should remove images which BLP subjects oppose without replacement,
  • That we change policy regarding the removal of article content the subject opposes, nor
  • That the quality of an article should be sacrificed to please its subject.

In fact, this policy would not explicitly allow anything that isn't already allowed. However, codifying it would stop comments such as "is this really a good reason to change the image?", and lengthy discussions under it, in cases where there is no other justification to make the change.

There is precedent for a subject to have direct control of information that appears in an article, though for different reasons: see WP:DOB. See also WP:BLPKINDNESS.

There is a short discussion about this situation at WP:BLPN#Hasan Minhaj, but no real consensus was reached. WPscatter t/c 16:42, 16 October 2022 (UTC)[reply]

Yeah that's the rub, if the person wants to present an airbrushed picture say. However, I haven't seen that very much. If both pictures are OK but the one the subject wants makes him look somewhat better, but no less like he really looks than the existing picture... it's fine. Which is most cases. Per the spirit of BLP, we should lean over backwards as far as reasonably possible to accomodate the subject. (But then there is also the question of the person requesting being the actual subject, or her agent, if there's no OTRS ticket). Anyway, we have too many rules already, and rules are supposed to codify existing procedure, not be mandated from above. An essay would be good tho. Herostratus (talk) 23:23, 16 October 2022 (UTC)[reply]
  • Support. Where the subject's preferred photo is appropriately licensed and equally good or better then I can see absolutely no reason why we wouldn't use their preferred photo. If the image is overly promotional then it is worse than the current image and so this wouldn't apply. If someone's face is notably asymmetric (or has some other notable feature) then there should be reliably sourced content in the article supporting that. If that content is in or near the lead then a photo that doesn't show that aspect isn't equally as good as one that doesn't. If the content is lower down the article then use the original photo adjacent to that content and the preferred photo in the lead. If there is no relevant reliably sourced content in the article then the preferred picture not showing that is not a reason to regard it as worse than the current one. In all cases though it is perfectly acceptable to discus which photo is better any why, the only changes would be (1) that one photo being the preferred photo of the subject is not a reason why it is worse than the previous one and (2) no consensus (or consensus they are equally good) defaults to using the preferred photo. Thryduulf (talk) 11:02, 17 October 2022 (UTC)[reply]
  • Oppose - if the subject has a better photo to offer, the relevant fact is that it is a better photo. Not that it is from the subject. We aren't part of their social media presence, their likes and dislikes are no concern of ours. --User:Khajidha (talk) (contributions) 14:07, 18 October 2022 (UTC)[reply]
  • Comment. Individual cases should be considered on their merits. It may be appropriate to take the subject's personal preferences into consideration, but trying to make this into some sort of policy makes no sense, given the multitude of other possible factors that may be relevant. AndyTheGrump (talk) 14:16, 18 October 2022 (UTC)[reply]
  • I dislike the proposal's wording, because it says "sole justification" and then goes on to list three non-trivial requirements that the preferred photo must satisfy, which is a little contradictory. However, I do support the general idea of using the subject's wishes as a tiebreaker in "no consensus" scenarios, as opposed to defaulting to the status quo as we usually do. There is precedent for this type of action, cf. WP:BLPREQUESTDELETE. -- King of ♥ 16:22, 18 October 2022 (UTC)[reply]
    Thanks for bringing up the "tiebreaker in case of no consensus" idea, since I think that's an important point and I hadn't thought of it. I've incorporated it into the essay I wrote on the topic. WPscatter t/c 09:03, 19 October 2022 (UTC)[reply]
  • Support I used to deal with this a lot. I fully appreciate that many people dislike poor-quality or embarrassing images of themselves like mug shots. A particular problem is when a person derives income from their appearance and therefore prefers the airbrushed publicity photo. Given that our definition of free is "free as in free enterprise", prioritising the interest of corporations over those of the encyclopaedia, I am generally willing to accommodate this. Hawkeye7 (discuss) 18:16, 18 October 2022 (UTC)[reply]
  • The important question is: is the proposed new image better than the current image (both in terms of quality and our rules)? It does not matter who proposes it. Blueboar (talk) 18:24, 18 October 2022 (UTC)[reply]
    That's a fair point, and really I suppose the only thing this proposal would change is the case where the new image is of approximate equal quality or no consensus can be reached. WPscatter t/c 09:02, 19 October 2022 (UTC)[reply]
  • Support wholeheartedly. Typically, a Wikipedia photo represents a person across the Internet whenever you search for them: it is deranged for us to insist on using terrible photos because using good ones would somehow be capitulation. I mean, the same argument could be applied to any insulting thing: what if we added a sentence to every BLP saying "there is no evidence that John Smith is not a pedophile"? And then we could preen ourselves about how we didn't cave in to the demands of subjects by removg it. And it would even be true, technically speaking! But it would also be pointlessly mean moustache-twirling vindictiveness. jp×g 19:19, 19 October 2022 (UTC)[reply]

Articles written as school projects should be banned

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.



I have come across a lot of these lately, and they are uniformly awful. They quote huge chunks verbatim from official sources, have superficial understanding of the subject, use jargon and buzzwords, and are not logically constructed. Most are completely uncritical of the subject. It proves two things: 1) Kids are being taught by imbeciles who think they are clever 2) They are being taught how to write advertising copy instead of critical thinking skills.

I realize WP in general suffers from the same problems, but this is where they start. Put a stop to it I say, nip it in the bud. Demand better. Make a stand against the ever growing tide of verbal sewage.--ෆාට් බුබුල (talk) 05:34, 17 October 2022 (UTC)[reply]

You've just described a lot of things that are already against policy - copyvio, promo etc. I'm not sure what a blanket ban on articles written as part of courses would do to help, nor how it would be policed.Lee Vilenski (talkcontribs) 08:01, 17 October 2022 (UTC)[reply]
Actually its already policed to an extent, We often have school groups get hit by blocks when they do a project. If we wanted to we could just... not unblock them and make it easier to block obviously groups of people editing in a substandard way, while tightening up the allowed education/outreach groups. Only in death does duty end (talk) 09:21, 17 October 2022 (UTC)[reply]
No changes are needed here. Bad articles are bad regardless of how or why they are written and good articles are good regardless of how or why they are written. You've just described characteristics of bad articles (NPOV, copyvio, promotional, buzzwords, etc) that, as you say, originate from both school projects and other articles, and these should be cleaned up or deleted as appropriate. However if someone writes a decent article as part of a school group we should welcome it with open arms - the encyclopaedia has benefited and by being encouraging towards the creator we stand a much better chance of them becoming a Wikipedian and generating more benefit to the encyclopaedia. Thryduulf (talk) 11:07, 17 October 2022 (UTC)[reply]
We could just put in a "no new editors, ever" rule. That would save us from people who are still learning best practices. Now let me think whether there might be any downside to that... --Nat Gertler (talk) 12:17, 17 October 2022 (UTC)[reply]
Maybe such a rule should have been in place when Wikipedia started. That way we would have no problematic articles. Phil Bridger (talk) 12:52, 17 October 2022 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Draftify things, or improve-in-situ

I am opening this as a discussion-place following yet another big dispute arising at ANI [4] concerning (1) whether recently-created articles that still lack adequate sourcing should be draftified; (2) and if so, how long should be left between their creation and draftification as grace for the original editor to make a cup of tea and continue with their work? Is it acceptable to write articles in main-space directly, with the inevitable consequence that for a period, main-space contains an imperfect article? Related to this is (3) the question of whether poorly-sourced articles from the past should be deleted, draftified or merely tagged as in dire need of sourcing, and (4) the question of whether a likely-true-but-unsupported edit should be reverted, or tagged as needing a source.

My viewpoint is that this is a fundamental clash between two important concepts in Wikipedia. On the one hand, we believe strongly that all information in Wikipedia should be reliable, and therefore we want reliable sources. On the other hand, it has always been accepted that Wikipedia is a work in progress, and that it will always improve: we write articles on the understanding that they will not be perfect, and others will build on our work and improve it. Poor can become Good via Mediocre.

This clash leads to a lot of arguments at ANI, but more importantly, to lost editors, editors who leave the project in frustration, or editors who lose the will to edit in main-space because it's a lot harder than piddling around writing proposals at the village pump. I think it would be very helpful if we could have some community debate on the relative merits of deletion/draftification versus tagging/improvement in main-space, perhaps leading to some better guidelines on when each is appropriate. Elemimele (talk) 16:31, 19 October 2022 (UTC)[reply]

Poor can become Good via Mediocre, but a text without basic verification is not an article but a draft. At least the notability of the article's subject has to be verified. Editors who create a new article always read the following sentence on their screen: "Before creating an article, please read Wikipedia:Your first article." I am not sure that those who are unable to read our relevant policies before starting an article are able to add value. Borsoka (talk) 17:12, 19 October 2022 (UTC)[reply]
Editors who create a new article always read[citation needed] the following sentence on their screen: "Before creating an article, please read Wikipedia:Your first article." ~ ONUnicorn(Talk|Contribs)problem solving 19:12, 19 October 2022 (UTC)[reply]
Sorry, I do not understand your message. Try to create a new article and you will read the text on your screen: this is the first sentence above the editing box. Borsoka (talk) 02:35, 20 October 2022 (UTC)[reply]
  • I think the elephant in the room here is that currently almost all draftifications rely on a degree of IAR. There is no clear policy basis for the majority of them. And so when one person says "that draftification has no basis" and the other says "but it made the encyclopedia better", it's possible that they're both right. But it's not a great status quo. Some parts of the project run fine on IAR and common sense. Deletion policy and anything related it tend to not be one of those parts. Perhaps we're overdue for formalizing draftification into something more akin to CSD. (Consider more niche draftification scenarios that are currently entirely IAR, like WP:NFF fails.) -- Tamzin[cetacean needed] (she|they|xe) 17:20, 19 October 2022 (UTC)[reply]
  • More in line with the specific query, currently the official or official-ish rules on time before permittable draftification is either 15 minutes or 1 hour. I don't think it should become too long, but we could expand it to 4 hours without significant issue (CSDs still apply, though A7 and its ilk perhaps should still wait). Nosebagbear (talk) 17:28, 19 October 2022 (UTC)[reply]
  • I waiver on this myself. Sometimes I think draftification is a great idea, sometimes I think it's a terrible idea. It think it's a good idea for some articles and some editors, and it's really hard to know before doing it which is which. I'd like to see it used less, but I still want it to be a tool in the box. ~ ONUnicorn(Talk|Contribs)problem solving 19:22, 19 October 2022 (UTC)[reply]
  • This is a good discussion to have. Because of __NOINDEX__, I'm not quite as concerned about subpar articles in mainspace. If it's not CSDable, and it's not something super controversial that will attract gobs of page views, just leave it for a couple days. I usually leave a talk page message in this case, and sometimes it ends up with the article consenting to a draftification so they can work in peace (e.g. User talk:Mitch199811). Ovinus (talk) 20:15, 19 October 2022 (UTC)[reply]
  • I agree with Tamzin that we lack a specific policy or guideline about draftification. We do have Wikipedia:Drafts but that is an essay and I agree with much of it while disagreeing with some of it. I know that many editors may disagree with my view of this, but I believe that all unreferenced articles, even those written one minute ago, violate our core content policies. By their very nature, they violate Verifiability because the reader has no way to verify the assertions. They violate the Neutral point of view because our articles are supposed to summarize what a range of reliable sources say about the topic, and an unreferenced article reflects the point of view only of its author. They violate No original reasearch because an unreferenced article reflects only the personal knowledge of its author. We have personal sandbox space and draft space for a reason. Those spaces allow editors to develop acceptable encyclopedia content at their leisure, which is six months for drafts and indefinite for personal sandboxes. I believe quite strongly that content should only be added to the main space of the encyclopedia when it arguably complies with the core content policies, and an unreferenced article by definition does not comply. I understand that that this style of article creation was probably necessary in the very early days of this encyclopedia, but the project is 22 years old and we are at the point where new article quality is much more important than new article quantity. I have never written an unreferenced stub in main space and would be ashamed to do so. I do not think other editors should be permitted and implicitly encouraged to do so. Cullen328 (talk) 00:56, 20 October 2022 (UTC)[reply]
    • A zero-tolerance approach like that would be very alienating, especially with the vague and aloof user talk templates in common use. Ovinus (talk) 04:21, 20 October 2022 (UTC)[reply]
      • Ovinus, how would draftifying alienate any editor who is truly here to write articles that comply with our core content policies? Such editors would have the opportunity to improve the draft until it complies with core content policies. Draftification is not deletion. If editors determined to ram and jam non-compliant articles into the encyclopedia right now are alienated, then I consider that a beneficial thing in every way. If they reform their thinking, they can return at that time. Cullen328 (talk) 06:22, 20 October 2022 (UTC)[reply]
      That's a great argument for fixing the problem with user talk templates and then coming back to that approach. We could require that drafitification also requires a message to the creator explaining the issues with the draft in detail. Lurking shadow (talk) 06:24, 20 October 2022 (UTC)[reply]

RFC: change "verifiable" to "verified"

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Which of these two statements for the lead of WP:V ("verifiable" or "verified") is better?

  1. (status quo) All material in Wikipedia mainspace, including everything in articles, lists, and captions, must be verifiable.
  2. All material in Wikipedia mainspace, including everything in articles, lists, and captions, must be verified.

RFC advertised at WT:V and WP:CENT, and launched at 16:50, 19 October 2022 (UTC)

  • Support #2 (as proposer RFC initiator). It's time for us to make this change. English Wikipedia is now at the top of Google search results, and our content is reproduced by Google, Amazon Alexa, Siri, and elsewhere, which we are encouraging with Wikimedia Enterprise. English Wikipedia is, generally, the anglophone internet's first stop for information. Our most important duty is to not misinform readers. The use of Wikipedia to spread misinformation and disinformation is a serious threat: see, for example, this study from 17 Oct 22 (and this article about it)--the latest of many such studies and articles.

    In the early days of Wikipedia, it made sense to allow unsourced mainspace articles, under the rationale that by putting them into mainspace, they would be more likely to be improved. As long as the information in the articles was verifiable, there was no risk of misinforming the reader. Today, with over 6.5 million articles (6,849,666 to be exact), we do not have enough editors to check or monitor each and every article. We've added over 500,000 new articles in less than two years (WP:6M was reached in Jan 2020). Category:All articles lacking sources contains over 136,000 articles. It is unrealistic to expect that we can have unsourced information in mainspace and not misinform our readers, and in 2022, the risks of misinformation and disinformation are too high. Wikipedia is too important, too widely-read, too much relied-upon, to risk it.

    If this proposal passes #2 is preferred, enforcement policy text changes of the "verified" requirement would be a separate issue, beyond the scope of this RFC. (I note that "verified" does not mean "must have an inline citation": general references can provide verification.) What to do with existing unsourced articles, and new unsourced articles, are nuanced and complex questions, but the first step towards answering those questions is to all agree -- to come to global consensus -- that mainspace articles should be verified, not just verifiable. If this much has consensus, then I expect future RFCs will be launched to explore what other changes should be made to policy to implement this change (e.g., renaming the "WP:Verifiability" policy to something like "WP:Verification"). But it's time to make this change: it's time to ditch verifiable, and agree on verified. Levivich (talk) 16:50, 19 October 2022 (UTC)[reply]

  • Oppose (will return with reasoning) Beyond My Ken (talk) 16:56, 19 October 2022 (UTC)[reply]
  • Oppose. The policy relies throughout on the current wording. Changing that one word makes the policy self-contradictory on many levels. As an example, the change would require that common knowledge, such as universally-accepted everyday orders that are taught in early elementary school, be, at a minimum, be looked up in a general reference while writing an article. Nobody would do this, so it would make all editors rule-breakers. Making everyone a rule-breaker devalues all rules. Jc3s5h (talk) 17:05, 19 October 2022 (UTC)[reply]
    I reaffirm my opposition after the changes by User:Levivich at 17:15, 19 October 2022 (UTC). The burden of looking up well-known information before writing it in an article would be so burdensome that it would be impossible to maintain one's train of thought. To borrow and modify a thought from Edsger Dijkstra "The use of COBOL the policy change cripples the mind; its teaching the policy change should, therefore, be regarded as a criminal offense.[reply]
    Source: https://quotepark.com/quotes/1816853-edsger-w-dijkstra-the-use-of-cobol-cripples-the-mind-its-teaching-s/ Jc3s5h (talk) 17:23, 19 October 2022 (UTC)[reply]
  • Comment. What's the goal of this proposal? Is this an oblique way to try to get a certain behavior to change as well? Forgive me, but I am not clear on this after reading the proposal and first !vote. –Novem Linguae (talk) 17:10, 19 October 2022 (UTC)[reply]
    • Since we're still in the first half hour of the RFC, I've changed the RFC statement to clarify. The goal is to determine if the community prefers "verified" to "verifiable" as the guiding WP:V principle. Pinging Beyond My Ken, Jc3s5h and Novem Linguae to let them know of the change. Levivich (talk) 17:15, 19 October 2022 (UTC)[reply]
      @Levivich, I read your statement, and I repeat the question from @Novem Linguae: What are you trying to accomplish? I know what (un)cited material is. I know what (un)verifiable material is. But I can't make out from your description what "verified" material is. Usually, when people talk about whether content is verifiED, they're talking about the actions they took immediately before slapping a {{failed verification}} tag on it.
      Here are some questions that might help me understand your proposal:
      • Do you mean that there must be at least one source named somewhere in the Wikipedia article?
      • Do you mean that there must be at least one source named somewhere in the Wikipedia article, and no content in the Wikipedia article that isn't also in one of the sources named in the article?
      • Do you mean that I need to check a source before I add basic information like "Joe Film is an actor", because I might have misremembered that, but citing the source would be optional (unless WP:MINREF applies, as it very often does)?
      • Do you mean that if I add basic information like "Joe Film is an actor", that someone else needs to check to see whether Joe Film really is an actor?
      • Do you mean that editors should be systematically checking articles to see whether they contain content that requires citations but doesn't have them?
      If the answer to the first question is "yes", then I think you'll want to withdraw this RFC and try again with a proposal that the WP:BLPPROD rules should be extended to everything. That has a chance of being accepted, possibly even with enthusiasm. WhatamIdoing (talk) 00:57, 20 October 2022 (UTC)[reply]
      • Yes
      • Yes
      • Yes on checking first, but citing a source should not be optional, the source should be cited somewhere in the article (not necessarily inline)
      • No, the person adding the information should continue to have the WP:BURDEN (and WP:ONUS, etc.)
      • No, although I think some already do, and it's good for that verification work to continue
      I've already changed this from a proposal to a broader question, and I don't think I'd support expanding BLPPROD to everything. Levivich (talk) 01:11, 20 October 2022 (UTC)[reply]
      It sounds like you want editors to take a hardcore Wikipedia:Amnesia test approach to writing articles: Forget everything you ever knew, because you can't even be trusted to correctly remember that water is wet. It'll be a tough row to hoe in terms of marketing, but if you want to get to that place in the end, I think you'll have better luck with a frog boiling approach than a single massive change. The first baby step might be getting a simple glossary installed in WP:V, to differentiate between verifiable, sourced, and cited. From the comments below, they're not going to let you call your idea verified, but you might get agreement to call it sourced, and leave the term cited for inline citations. WhatamIdoing (talk) 01:30, 20 October 2022 (UTC)[reply]
      Yup, I agree, "sourced" is the next logical question. Levivich (talk) 02:22, 20 October 2022 (UTC)[reply]
  • (edit conflict)Oppose - these are two vastly different things. The current means that if someone sees something uncited, they can leave a [citation needed] tag. If this were to change, literally anything that was uncited should be deleted. This feels like it goes against WP:SODOIT Lee Vilenski (talkcontribs) 17:22, 19 October 2022 (UTC)[reply]
    Requiring content to be verified does not also require unverified content to be deleted. For example, the rule could be that before deleting unverified content, an editor must make a good-faith search for a source, similar to WP:BEFORE. Another possible rule is that unverified content can only be deleted if it's had a {{cn}} tag for a certain amount of time. A third possible rule is that unverified content should be moved to the talk page, or only moved to the talk page after a {{cn}} tag has been applied for a certain amount of time. There are many different ways to enforce a verification requirement (WP:NOCITE lists several), but requiring content to be verified doesn't mean literally anything that was uncited should be deleted. While I support #2, I would oppose any such draconian enforcement measures. Levivich (talk) 17:30, 19 October 2022 (UTC)[reply]
  • Oppose - would make it so any reversion of say a 10k vandalism removal of material requires the editor to themselves verify the content to restore it. As far as the reasons to make the change, WP has been the top google result and had its material reproduced by google longer than Ive been here, so I fail to see what has changed to require such a wide scoping change in our core policy. nableezy - 17:23, 19 October 2022 (UTC)[reply]
  • Hizzell to the nizzo. There is NO WAY this is a good idea. Verified means that someone official has done some kind of confirmation, and signed off that the material matches the source. Verifiable means that any reader could do that by themselves. Verified carries the notion of official approval. Wikipedia does not operate on that model. Material needs to be verifiable, which means that I, as a reader, can check sources myself and confirm it. The current wording is not just arbitrary, it literally matters to how Wikipedia works, and changing it fundamentally changes the whole ethos behind Wikipedia. No way. --Jayron32 17:33, 19 October 2022 (UTC)[reply]
    Verified doesn't mean that someone official has done some kind of confirmation, and signed off that the material matches the source, it means there is an WP:RS cited as a reference (not necessarily inline; general references are already permitted). Levivich (talk) 17:37, 19 October 2022 (UTC)[reply]
    Once you start the RFC, it's up to the community to decide what the language of the RFC means. Just cuz you proposed it doesn't mean you get to decide what it means. I say it means exactly what Jayron32 says it means. Jc3s5h (talk) 17:40, 19 October 2022 (UTC)[reply]
    The applicable guideline is WP:CITE, and the sections WP:CITETYPE and WP:WHYCITE cover how/when/why to cite sources. Changing "verifiable" to "verified" in WP:V wouldn't change anything in WP:CITE. Complying with WP:CITE already complies with the "verifiable" requirement (as well as in the case of challenged content, per WP:BURDEN); complying with WP:CITE would also comply with a "verified" requirement. We don't have "someone official" on Wikipedia who verifies content; any editor can do that. Levivich (talk) 17:45, 19 October 2022 (UTC)[reply]
    Good rule of thumb… when proposing a change in policy wording (even minor changes) ask: “how might some other person misinterpret the language I am proposing?” Don’t assume your intent is clear to others. Blueboar (talk) 18:22, 19 October 2022 (UTC)[reply]
  • Oppose I agree that things ought to be cited maybe more than they are but I think this is not the way to encourage that.Selfstudier (talk) 17:43, 19 October 2022 (UTC)[reply]
  • Oppose What will this actually achieve? Forests of tags, and random removals. In my experience, "referenced" material is often little more accurate than referenced stuff. Johnbod (talk) 17:52, 19 October 2022 (UTC)[reply]
  • Oppose In addition to concerns already raised there are also problems with things like SKYISBLUE. I presume we wouldn't expect people to cite that Paris is the capital of France but this change suggests we would. In margin cases it would suggest that facts that are grayish blue would need to be removed if the original editor incorrectly felt they were blue enough. The current wording allows for content to be retained when it falls into these edge cases. That's probably better than the alternative. Springee (talk) 17:53, 19 October 2022 (UTC)[reply]
  • Oppose per Springee and others. This change will not improve Wikipedia. Thryduulf (talk) 17:56, 19 October 2022 (UTC)[reply]
  • I believe it's snowing here. nableezy - 17:58, 19 October 2022 (UTC)[reply]
  • Oppose - impracticable notion with a possible significant consequence if adopted. (The more I think about it, the more I'm sure that this is not a good idea. (See opposing notes above) - GizzyCatBella🍁 18:11, 19 October 2022 (UTC)[reply]
  • Readers, and the editors who write for them, should be credited with a modicum of intelligence when it somes to deciding what needs to be verified. Phil Bridger (talk) 18:19, 19 October 2022 (UTC)[reply]
  • Oppose per Jayron32. The point of verifiability is that I as a reader of an article can verify it by checking whether the source says what the article says it says. "Verified" means that someone has already done that and confirmed it (so I do not have to do it anymore, or have to be able to). That means that there has to be a system in place that ensures that before a user adds text and a source, they have to submit it to another user (not of their choice) for checking whether the source actually says that. Only after that check, the text can be added. That would be too much bureaucracy and would contradict the Wiki principle. Without that bureaucracy, the word "verified" would be a dishonest boast. --Hob Gadling (talk) 18:54, 19 October 2022 (UTC)[reply]
  • Strong Oppose I would be in favor of requiring all articles to cite at least one source; but a sourcing requirement of some sort is a far cry from requiring a citation for every fact in an article. The change proposed in option 2 would logically lead to a requirement for a citation for the assertion that "the sky is blue". Just as an experiment, I hit the random article button and got Guy-Michel Nisas, a stub about a Martiniquais football manager. That stub currently cites 3 sources for its 2 sentences. I count 6 distinct facts in those 2 sentences - if option 2 passes I would expect that article to need footnotes by each of those 6 facts. ~ ONUnicorn(Talk|Contribs)problem solving 19:03, 19 October 2022 (UTC)[reply]
  • Hizzeck to the nizzo, per above: while the large-scale removal of uncontroversial content pursued as an alternative to simple verification is certainly a phenomenon that happens here, I do not think we need to have more of it endorsed by policy. jp×g 19:11, 19 October 2022 (UTC)[reply]
  • Oppose Utterly impractical. I recognize that standards are ever rising, but this is too sudden. {{Citation needed}}, {{Dubious}}, and {{Better source needed}} tags alert readers to potential issues of accuracy. Article-quality processes already require "verified" status. Aggressive removal of uncontroversial but unsourced information is a common form of biting the newbies and has drives away potentially highly skilled writers. I would argue that experienced editors should follow this as if it were policy, but that is a matter for their respective user talk pages. Ovinus (talk) 19:30, 19 October 2022 (UTC)[reply]
  • Oppose to match wording of article title/topic is “verifiability” the text should be about “verifiable”. A “verified” is an inappropriate term as that would indicate some third party checking cites against text and recording the check. Cheers Markbassett (talk) 19:36, 19 October 2022 (UTC)[reply]
  • Oppose for many of the reasons stated by others here, but also because WP:WIP. This change is more likely to lead to reliable, informative (albeit lacking an inline source) content being purged rather than improved. —Carter (Tcr25) (talk) 19:45, 19 October 2022 (UTC)[reply]
  • Support. Editors should only add material when they have a source supporting that material, as otherwise they are engaged in WP:OR. Since they must already have the source, it is reasonable and efficient to require them to provide the source when adding the material.
For editors worried about 10k vandalism, there is a difference between adding and restoring material. BilledMammal (talk) 19:49, 19 October 2022 (UTC)[reply]
I can't agree. I can add "The capital of France is Paris" to an article without a citation, and without "having" a source, and I will not be engaged in OR according to the second paragraph of that very policy, which gives that exact sentence as an example of content that is never an OR violation regardless of whether it's sourced.
Also, BURDEN explicitly applies to anyone "who adds or restores material" and says that challenged material "should not be restored". There is presently no difference between adding and restoring material. WhatamIdoing (talk) 01:08, 20 October 2022 (UTC)[reply]
  • Oppose - “Verified” is inaccurate and an entirely different, unrealistic standard. — Preceding unsigned comment added by Swarm (talkcontribs) 20:09, 19 October 2022 (UTC)[reply]
  • Oppose Besides the fact that verified and verifiable mean two different things, I can see the clear intent this RfC is trying to greenlight. Curbon7 (talk) 20:34, 19 October 2022 (UTC)[reply]
  • Comment despite the so-far solid opposition to this proposal, it is actually merely attempting to ratify a point of view that many Wikipedians already hold. At the moment we're in a very unsatisfactory situation: we have guidelines that say don't knee-jerk delete unsourced stuff unless it's wrong or got BLP issues: instead first look for a suitable source or consider a citation-needed tag. But we also have a clear statement that if you choose to ignore this advice and delete it anyway, no one can put it back without a source. No one is ever going to get sanctioned for deleting unsourced information, so in effect, we already have a "must-be-verified" policy, wherever anyone chooses to enforce it. Logically it's like saying you can't pinch someone's chocolate, but if you do, they're not allowed to ask for it back. I welcome this discussion - the topic is very close to that which I raised just above - because I think it's a huge chasm between two groups of Wikipedians and needs sorting out. But I also prefer "verifiable"; deleting probably-correct information is disruptive, and makes articles less readable. It's lazy. It's much better to assess whether the information is verifiable, and if it is, verify it. Elemimele (talk) 20:48, 19 October 2022 (UTC)[reply]
    There is nothing murky about the way things are. Any editor is free to challenge uncited material, and any challenged material requires a citation be provided. If that is not done then challenged material can be removed and should not be restored without a citation directly supporting it. Needlessly challenging material just because there is no citation may however be treated as disruptive. If you think something is wrong, ask somebody for a source to prove it. If they dont, remove it. nableezy - 21:09, 19 October 2022 (UTC)[reply]
  • Oppose per the many statements above and this should be SNOW closed. Andre🚐 20:52, 19 October 2022 (UTC)[reply]
  • Oppose because Wikipedians are first and foremost encyclopedia writers and not blind citers of content. While citations are important, requiring citations of everything would bog down our editors and readers alike. Per User:Novem Linguae, this sounds like a proposal that was made in order to discretely stop a behavior that they don't like. JuxtaposedJacob (talk) 23:10, 19 October 2022 (UTC)[reply]
  • Oppose. Verified is a goal everyone should strive towards in the long term, but making it an essential prerequisite would be catastrophic to the model we work on here. I've done some work on unsourced articles and I'd say at least 90% of the content is correct and readily sourceable with the growth of online access, especially the recent Wikipedia Library expansion. Espresso Addict (talk) 23:22, 19 October 2022 (UTC)[reply]
  • Oppose— the big problem, if this were passed, is who will do the verification? As I read the proposed text, verified would imply that someone has actually, well, verified the content added by others. That would imply all articles, new or existing, would have to have Pending Changes protection enabled to allow someone to verify edits before content appears to our readers. That also brings up another issue: not all of our sources are accessible online. Some are locked behind geofences, some behind paywalls, and some are locked in print in libraries requiring physical access. Instead, we operate on a principle of verifiability, meaning that readers should be able to verify the content they read, either through supplied references, or through their own research. (In the latter case, one would hope they'd give back by supplying a reference for previously uncited content.) Imzadi 1979  00:07, 20 October 2022 (UTC)[reply]
    "Verified" might mean that the editor adding content has looked in some source to verify it, and made sure the source is at least listed as a general reference in an article, if not an inline citation. But when working in an advanced article, even that is an unacceptable burden. For example, Date of Easter is a fairly advanced article, and it uses the word "remainder", referring to the arithmetic operation of division. Sorry, but when I finished fourth grade, the teacher collected my text book, so I no longer possess a book to cite on how to do long division. Even if I did, I shouldn't have to interrupt my thinking to bother with stuff like that. Jc3s5h (talk) 00:19, 20 October 2022 (UTC)[reply]
    That's certainly another interpretation, but if we start advertising that we have a policy that our content is verified, a very reasonable interpretation by the general population would not include such self-verification. Either way, a verification requirement, not a verifiability requirement, would fundamentally alter how people can contribute with a variety of poor consequences. Imzadi 1979  00:47, 20 October 2022 (UTC)[reply]
  • Oppose. By aiming for "verified", we're saying "trust us, we checked", and barring some major change to how Wikipedia is edited, we can never be that trustworthy, because you always might get to the article after someone has added something inaccurate. "Verifiable" sets the goal of having a reference so that the reader can check some more structurally reliable source; they don't need to trust us. --Nat Gertler (talk) 00:36, 20 October 2022 (UTC)[reply]
  • Oppose impractical and poorly thought out. If you want to throw away every single uncited thing by bot, be my guest, but that seems irresponsible to me. --Rschen7754 01:01, 20 October 2022 (UTC)[reply]
  • Oppose. While I see where the proposal is coming from, who will be the arbiter of what is a verified source? –Fredddie 01:23, 20 October 2022 (UTC)[reply]
  • Oppose. Would raise the bar for editing to a ridiculously high level. Also, it's snowing in October.pythoncoder (talk | contribs) 01:32, 20 October 2022 (UTC)[reply]
  • Support the idea behind this (we should more aggressively remove unsourced content), but agree with everyone above that the specific wording proposed here is unworkable. * Pppery * it has begun... 01:38, 20 October 2022 (UTC)[reply]
  • Oppose Wikipedia should never be the "fact checker" by claiming that all its contents are "verified". To my limited knowledge, "verifiable" means that the editor is expected to verify themselves as the content can be verified, while claiming "verified" means that we claimed that it has been vetted and should not be checked anymore, placing Wikipedia to be on a similar level with "truth checkers" which in my opinion, is not the goal of this project. ✠ SunDawn ✠ (contact) 03:15, 20 October 2022 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.