Wikipedia:Village pump (proposals)/Archive 186#rfc%3A shall we update cs1%2F2%3F

This is your emergency broadcast system announcing the commencement of the Annual Purge, sanctioned by the U.S. Government Wikimedia Foundation. Commencing at the siren, any and all crime, including murder, will be legal for 12 continuous hours. Weapons of class 4 and lower have been authorized for use during the Purge. All other weapons are restricted. Police, fire and emergency medical services will be unavailable until tomorrow morning at 7 am. "'']] Beeblebrox (talk) 20:21, 11 December 2021 (UTC)|status=NO PURGE}}

Hello,

As a suggestion to raise awareness of the benefits of Wikipedia and to encourage donations, I think it would be beneficial to implement "Useless Information Day". One day a year, users are allowed to make changes to any Wikipedia page without moderation. (Obviously, obscene or violent or otherwise harmful changes would not be allowed.) Basically, users would be allowed to vandalize any page for the entire day for the purpose of creating jokes, etc. which are normally corrected fairly quickly. Especially interesting edits would gain news or viral interest. The unreliability of information on Wikipedia on this day would highlight the need for the service and hopefully encourage donations.— Preceding unsigned comment added by Jeepnut1 (talk • contribs) 12:13, 8 December 2021 (UTC)

:That could lead to readers being seriously misled. There is also the problem of reverting the joke edits whilst retaining useful changes after the event. There is limited tolerance for jesting outside article space on April 1 each year, but even that is controversial. For those of us who fight vandalism, every day is Useless Information Day. Certes (talk) 12:47, 8 December 2021 (UTC)

: I thought about that. I don't have enough Wikipedia knowledge to know what's possible and what isn't, so I can't speak to the difficulty of reverting. I assumed, possibly incorrectly, that everything could just be reset to what it was before the day started and that during the event, large banners could be placed at the top of the page to alert users to the fact that today, the information of Wikipedia should not be trusted and to donate to secure the future of the service.— Preceding unsigned comment added by Jeepnut1 (talk • contribs) 12:54, 8 December 2021 (UTC)}

::Donations are paid to the WMF rather than to Wikipedia. The volunteers who detect and remove incorrect information are all unpaid. Certes (talk) 12:59, 8 December 2021 (UTC)

:As stated above, this doesn't seem like all that good of an idea as it'll make users think that it's ok to vandalize Wikipedia which, if it were implemented, wouldn't be true. In fact, it basically goes against WP:DENY. If we were to dedicate an entire day on Wikipedia to allow users to vandalize we would be feeding any new trolls that come to Wikipedia on that day. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 17:46, 8 December 2021 (UTC)

{{archive bottom}}

:It’s just a “proposal” (ie someone’s suggestion). It is unlikely to be approved or implemented. Blueboar (talk) 15:17, 7 December 2021 (UTC)

::Pinging @SGill (WMF) Whatamidoing (WMF) (talk) 19:13, 7 December 2021 (UTC)

:::Hello everyone, I am advising on this project in my volunteer capacity. My username has been changed to my volunteer account on the proposal itself.Also, this project is not about writing the policy by one person but rather helping coordinate with the community and experts to co-create various policies. Workshops with other community members to educate them about the policies and organizing further events is a major component of this project. Satdeep Gill (talk • contribs 10:50, 14 December 2021 (UTC)

:What price index should be used for the conversion? 65.88.88.76 (talk) 19:14, 14 December 2021 (UTC)

:The {{tlx|inflation}} template can be used for this. clpo13_(talk) 19:20, 14 December 2021 (UTC)

{{Closed rfc top|1=After 22 days, I think it's time to close this one. First, I want to say a big thank you to everyone who participated—I learned a lot about accessibility and formatting throughout the process and particularly by reading all of your comments. I think it's fair to say that the general consensus was the proposal's clunkiness and bureaucracy outweighed possible accessibility upsides, given the prevalence and improvement of screen reader technology. Accessibility, to all who might not consider reading the best form of digesting information (including, but also supersedind, blind people), is a super important topic for the encyclopedia to address and I can't wait to see where we go to address it. Here's to the sparks of new ideas and to [https://www.senate.gov/artandhistory/history/minute/Senate_Created.htm the saucer that cools the coffee]—Cheers, everyone! theleekycauldron (talk • contribs) (they/she?) 06:56, 8 December 2021 (UTC)}}

Should the Today's featured article section of the Main Page allow for spoken recordings of its blurbs? theleekycauldron (talk • contribs) (they/them) 06:53, 15 November 2021 (UTC)

:Proposal: In every nomination template for TFA, there should be an optional "narration" parameter that allows the nominator, or any other interested editor, to add a spoken recording of the blurb that is to appear on the Main Page. A sample narration on a past iteration of the Main Page can be found here to roughly illustrate how this may look and feel, although this will be changed as more experienced template editors than myself fiddle with the idea. No nomination will be required to contain a narration, but any recording that is attached to the nomination must be reviewed by an admin according to the guidelines laid out by WikiProject Spoken Wikipedia for technical quality, clarity, and accuracy before the recording can accompany the nomination to the Main Page. This proposal has the potential to help thousands in accessing the articles that Wikipedia is most proud of. Thanks for your time, and I hope I can count on your support! theleekycauldron (talk • contribs) (they/them) 06:54, 15 November 2021 (UTC)

:@User:Dege31Speculation. I believe there's only one way to find out, and that's to give it a try for a week or so, and then have people weigh in on the tangible results.Gallomimia (talk) 17:38, 28 November 2021 (UTC)

• Oppose. Project Spoken Wikipedia, while done out of good faith, was largely a misguided way to direct volunteer time, and doing the same for blurbs would have the same problems. Most blind people who wish to listen to an article would actually rather hear the up-to-date version spoken by a controllable machine reader which can go at the desired pace, accent, and so on of the listener, not a snapshot made three years ago by an unknown speaker. I suppose the risk of "vandalism" would be less for the front page version, but this seems like misspent effort - very, very, very few people would be interested in this, yet it wouldn't really achieve much for accessibility. And unlike article recordings, these front page blurbs would be used one day and then never again. SnowFire (talk) 19:23, 18 November 2021 (UTC)
• Agree with SnowFire. ProcrastinatingReader (talk) 02:58, 21 November 2021 (UTC)
• I don't see why this is better than using a screen reader. User:力 (powera, π, ν) 01:38, 21 November 2021 (UTC)
• Oppose—a screen reader would be preferable as SnowFire explains. Imzadi 1979 → 03:10, 21 November 2021 (UTC)
• Oppose: I am not too familiar with this area and it seemed like a grand idea --- until --- issues were brought to light that derailed it. Unless there was some compelling solution to issues mentioned by Wehwalt then I can see some corrections not being updated in the audio resulting in "variances" as mentioned by Sdkb. I would imagine an editor making last-minute changes could (a stretch) simply remove the audio but consistency and convenience would seem to mandate it should be there all the time or not at all. -- Otr500 (talk) 03:31, 22 November 2021 (UTC)
• Support (with caveats) - Wikipedia is one of the least accessible websites there is, making it more accessible is always a good thing. When I visit other websites, and they have a "Listen to this article" option, I always always use it rather than my screen reader. For me, a human voice is preferable over a machine translation. But, here's my caveat, if it's not going to be consistent on a day to day basis, what's the point? Readers shouldn't land on the main page one day, and see this new feature and think, oh wow, look at Wikipedia stepping up their game, and then come back the next day and not find it, thinking, I knew it was too good to be true. Be consistent or don't do it at all. This is good advice for the whole project, [https://niemanreports.org/articles/audio-articles-are-helping-news-outlets-gain-loyal-audiences/ audio articles help retain readers]. Isaidnoway (talk) 13:57, 26 November 2021 (UTC)
• Support - Volunteer I put forward that none of us will really know whether it is a great idea or a terrible idea until we get a few blurbs read aloud and hear them, gauge how much work is involved, and compare this to the benefits reaped. I thus volunteer to do several blurbs, as I have found this work very beneficial to myself personally. If it's no better than a screen reader, we can discontinue.Gallomimia (talk) 17:35, 28 November 2021 (UTC)
• Oppose based on considered feedback of several above. First, if Graham87 doesn't see it as helpful, that is huge in my estimation. Second, the concerns raised by Wehwalt are very real and serious ... the blurb is changing even as it is on the mainpage, so this could be a very difficult wrinkle, and the TFA/mainpage/FA editors don't need another wrinkle to deal with on mainpage day. And I agree that doing all of this for a one-day event is misspent effort. Third, I agree that Spoken Wikipedia is well intended but quite misguided; I note how often even Featured articles have links to dated spoken versions on the article page. In the medical realm, this is really troubling, when we are linking to outdated info. So, I'm not really inclined to do something to advertise a project that isn't working as well as hoped. I could be persuaded otherwise if I thought this move would really benefit the visually impaired, but with Graham87 not on board, that pushes me definitively to oppose. SandyGeorgia (Talk) 17:47, 28 November 2021 (UTC)
• Oppose. Better to rely on text-to-speech tech, in which big corporations are investing millions of dollars. Adds a lot of complexity to the TFA process which, while I'm not personally familiar with it, I don't think is a walk in the park. Also sharing {{u|Sdkb}} about diverting editors' attention away from more central missions of the project. JBchrch talk 22:23, 3 December 2021 (UTC)
• Oppose as someone who makes Spokens. I would prefer only a few select ones that can be updated as time goes on for each user, of a high quality. Each blurb would most likely be rapidly made and quickly be outdated. I think Spoken Wikipedia may not serve an accessbility purpose anymore, as Graham has pointed out, but as just another format to absorb Wikipedia. If they are not of the quality and close to the date of the article it corresponds to, it really isn't useful to any listeners. And as a small tangent; SandyGeorgia, a lot of why the articles are old and outdated is that the project was dormant for a long time. I hope to get around to them at some point, but it is a serious problem. If they are that outdated, feel free to remove them I guess. Sennecaster (Chat) 19:19, 6 December 2021 (UTC)

{{Closed rfc bottom}}

I a not a scientific but it is possible to have two articles. Cosmic Dawn matches several and many more results in Google in English. The french translation of Cosmic Dawn i.e Aube Cosmique matches more and more results. I will reading you. Thank's and best regards, Mike Coppolano (talk) 14:41, 12 December 2021 (UTC)

:As that seems to be a question of content, the place to talk about this Talk:Reionization. This page is about suggestions for larger changes. I suspect I am not the only one here who would have absolutely no idea about the appropriateness of splitting that article. — JohnFromPinckney (talk / edits) 19:26, 12 December 2021 (UTC)

:: Thanks ! Have a good day, Mike Coppolano (talk) 05:04, 21 December 2021 (UTC)

• This probably should go in VPI for further fleshing out, as it doesn't propose a methodology, or how to handle cases where a source has heavily mixed reliability statuses, but would be an interesting add-on. Nosebagbear (talk) 09:15, 13 December 2021 (UTC)
• You might be interested in the CiteUnseen user script. – Joe (talk) 10:27, 13 December 2021 (UTC)
• Or WP:UPSD if you're interested in finding out about bad sources. Highlighting "good" sources in green is problematic, because no source is always reliable for all information. Headbomb {t · c · p · b} 00:40, 14 December 2021 (UTC)
• :No source is always reliable, and no source is always unreliable, because reliability always depends on the relationship between the source and the material you're supporting. There are sources that have a very high (or low) probability of being reliable for typical statements that editors might use them for, but even the most unlikely sources – self-published, non-expert, non-independent, and primary – can be reliable for certain statements. See just about everything using Template:Cite tweet or Template:Cite instagram for proof. WhatamIdoing (talk) 01:39, 14 December 2021 (UTC)
• ::In addition, even the sources that are blacklisted are sometimes (albeit rarely) appropriate to use, for example in an WP:ABOUTSELF manner, and while you could hazard a guess that if the name of the source matches the name of the article that it's being used in that manner this isn't always the case, nor is that the only place ABOUTSELF may be used. Thryduulf (talk) 03:07, 14 December 2021 (UTC)

:This is a very interesting idea, which is essentially asking for WP:RefToolbar to have some some (un)reliable source detection. The good part is that RefToolbar is a community-maintained gadget and so it can be implemented without any changes in mediawiki software (which are well known to take a lot of time to be implemented and approved). Any colour indicators would only indicate likely reliability or unreliability, so I don't see exceptions and edge cases as being problematic. – SD0001 (talk) 06:53, 14 December 2021 (UTC)

:There is no source that is a priori reliable. There are sources with a history of prior reliability. This is entirely irrelevant when it comes to supporting a new wikitext claim. The fact that certain sources have been historically reliable in no way elevates reliability of a new, particular claim backed by the same source. Reliability trends do not predict the reliability of individual new claims any more than they predict the next outcome of a coin toss. And every citation must be reliable in its context. The aggregate or average or trend being "generally reliable" just won't cut it. Every wikitext claim must be reliably proven. A "reliability list" or "reliability algorithm" or "reliability bot" will not do. This is too important to be relegated. If you want to help the project, you, personally, have to do the work. There is an exception: when the exact same claim has been made in the past, and has been unambiguously proven correct using the exact same source. For that case only, the particular source is {{em|currently}} (per the available information) considered reliable. Until perhaps contrary information emerges. 74.64.150.19 (talk) 12:59, 14 December 2021 (UTC)

::I think the OP has only suggested colour indicators to highlight general reliability status of the source. No one has suggested blocking inclusion of such sources by the software or bot. – SD0001 (talk) 14:20, 14 December 2021 (UTC)

:::There can be no such thing. As noted above, the reliability of the source is relative to the context of the citation and the corresponding claims made in wikitext. This is not a one-to-many relationship. Apart from the exception, also noted above, of a repeated claim supported by the same citation. 65.88.88.47 (talk) 15:21, 14 December 2021 (UTC)

::::Even if we all agree that the tool will "only indicate likely reliability or unreliability", it will be enforced by POV pushers and others as an absolute thing. Headbomb has spent put a lot of effort into the UPSD script, several of us have helped to make the documentation as clear as we can, and he still has to tell far too many experienced to stop blindly rejecting everything that the script highlights in its "50–50 chance" category. WhatamIdoing (talk) 21:54, 14 December 2021 (UTC)

:::::Agreed. But I would tweak the terminology. There are sources proven reliable after the fact and sources likely unreliable before, with varying degree of unreliability. For any given citation, only unreliable sources have degrees or likelihoods. And for any given citation, reliable sources are just that. They are no more or less likely to be what they are. 71.105.141.131 (talk) 02:30, 15 December 2021 (UTC)

::::::This basically isn't true. RSP says that the Associated Press is generally reliable, right? But if you cite any newspaper article from that highly reputable, officially-generally-reliable news source to support a sentence like "25% of cigarette smokers get lung cancer", then you'll be reverted because news media are not reliable sources for biomedical information. You can't say whether a source is reliable until you know what the Wikipedia content is. WhatamIdoing (talk) 19:04, 17 December 2021 (UTC)

:::::::The phrase "generally reliable" does not help one bit in elevating any citation. It means nothing, because the citation in question may not fall under such a "general" case, and there is no proper criteria to measure what constitutes "general" reliability. Past performance in no way guarantees the specific reliability of the next citation, unless one is gullible. You just have to work at it carefully, each time. Take a sentence like "25% of cigarette smokers get lung cancer" in wikitext. First, if it depends on a news source, it should be made clear. Say it is published in a general-interest high-circulation newspaper like the New York Times. Is this part of an opinion piece, an analysis, or is it straight reporting? Different types of news stories may employ different sources. A straight report may be based on an interview with a known, published expert in the field. A news analysis may be sourced from an official medical report. This is easy. You can easily ascertain whether the New York Times is reliable in this case, all you have to do is look at the primary source (assuming it is publicly accessible). You can do that in a million articles and prove the NYT reliable, and still, the next analysis/report may get the numbers or the quotes or the context wrong. If you state in wikitext "according to a New York Times analysis/report based on official medical records/interview with this expert etc. etc." this is a conditional statement, not a positive one. You give the wiki reader the option to accept it as relevant or accurate or neither, but it may be important in showing how general mass media may present the subject. Such a citation can be produced (and verified) easily. The gist of it is, "generally reliable" is a meaningless statement. Unlike say, "generally unreliable", which is a good starting point. 65.88.88.93 (talk) 20:25, 17 December 2021 (UTC)

:::::::In addition to WAID's points, we have sources listed at WP:RSP whose reliability varies by context, e.g. Fox News should only be used "with caution" for politics and science where it is regarded as a biased source, it is regarded as generally reliable for other news topics, and its talk shows "should not be used for statements of fact but can sometimes be used for attributed opinions." I don't know how any automated tool could correctly label a citation to FoxNews. The RSP entry for China Daily is going to be even trickier for a bot to parse let alone implement. Thryduulf (talk) 16:06, 21 December 2021 (UTC)

::::::::WP:RSPSS is worthless as a reliability predictor. It is a list based on historical data that assigns reliability based on past experience but also other considerations that are largely opaque to the reader. Its existence may induce confirmation bias in cases where editors 1. rely on it instead of doing proper context-based research of the source for a specific citation or 2. rely on it to engage in improper presentation. Any news organization that covers politics may have a declared or implied bias when it comes to such coverage. Mass commercial media such as CNN or Fox News cater to specific population segments representing opposing political opinions. This built-in bias is enough to make both likely unreliable in this area. This reliability-diminishing bias has to be made clear in wikitext describing political coverage: "according to liberal-leaning CNN/conservative-leaning Fox ..." etc. That is not to say that non-commercial political news sources are a priori reliable or unbiased. On the contrary. 65.88.88.47 (talk) 16:32, 21 December 2021 (UTC)

:::::{{tq| it will be enforced by POV pushers and others as an absolute thing}} That's a problem with the POV pushers. Every kind of technology can be abused. It's like saying we should not use the internet because hackers will then find ways to attack us. – SD0001 (talk) 17:53, 15 December 2021 (UTC)

::::::It's also like saying that before we create and deploy a tool that we already know has a high potential for abuse, we should figure out whether it's going to cause more problems than it's worth. WhatamIdoing (talk) 18:59, 17 December 2021 (UTC)

:::::::The rationale regarding the tool's creation is wrong, not its usage. Proof of reliability is not conducive to automation. The proposal seems to treat sources as static items with uniform fixed qualities. This approach is already suspect, as one inviting confirmation bias. 65.88.88.93 (talk) 20:37, 17 December 2021 (UTC)

::::::::The IP is right. We have sources whose reliability depends upon the context in which it is used. Others are considered reliable up to a certain date. We have unreliable papers in reliable publications, or unreliable books published by reliable publishers. Doug Weller talk 14:29, 22 December 2021 (UTC)

:::::::::We also have reliable sources published in unreliable publications (most commonly self-published subject matter experts). Thryduulf (talk) 16:34, 22 December 2021 (UTC)

::::::::::What the people above me say. There are very few sources that are never appropriate to use in a cite web template; even something super unreliable like Breitbart can be useful as a source in particular circumstances. The reverse, too - super reliable sources sometimes are wrong in a given instance. Even aside from editors who may not draw the appropriate distinctions, automation bias will induce a lot of people to take the "reliability" the tool suggests as gospel even when it isn't correct. Jo-Jo Eumerus (talk) 16:45, 22 December 2021 (UTC)

:::::::::::We already have that happening with the Wikipedia:Unreliable/Predatory Source Detector. Since Wikipedia:Nobody reads the directions, it doesn't matter how much we explain at the top of Wikipedia:WikiProject Academic Journals/Journals cited by Wikipedia/Questionable1 that you still need to use judgment. There's always going to be some guy who says "Oh, hey, that's flagged as needing manual review – well, that means it's bad, so I'll just revert that." WhatamIdoing (talk) 19:46, 22 December 2021 (UTC)

::::::::::::Perhaps it would be better to replace the term "reliable sources" (relative to citations) with "currently reliable instances" (relative to specific citations). It is an ugly term, but just an idea.

::::::::::::The following is a likely example.

::::::::::::In December 2020, wikitext discusses the rate of mutation the Covid19 virus, stating "… the mutation characteristics of Covid19 are …" etc. The claims are backed by a recent official medical document. This is a verifiable claim from a reliable source.

::::::::::::In December 2021, the same wikitext is no longer true. The underlying official source has in fact been proven wrong. Recent official medical reports contradict the original report’s findings. There are several ways to handle this: the first is, throw out the original citation and wikitext. Rewrite with correct wikitext and citation. The second is more convoluted and involves discussing the evolution of medical ideas about the subject: "according to then-prevailing medical opinion, in December 2020 the mutation characteristics of the Covid19 virus were thought to be X." This is not good enough. You have to add the current prevailing opinion if you are to impart useful encyclopedic knowledge: "however this was wrong (avoid evasions such as "incomplete" or "superseded" or "amended" and call an apple an apple) - based on currently available data, the official medical opinion in December 2021 was that the mutation characteristics were Y". This should be good ... until the next official report. 65.88.88.93 (talk) 19:56, 22 December 2021 (UTC)

:::::::::::::Add to above: notice that in the discussion of the evolving medical opinions, the wikitext relies on reliable sources for each claim: it is true that the December 2020 official report is a reliable source in discussing contemporary (late 2020) ideas about Covid19. It is also true that the December 2021 official report is also a reliable source in its context. 65.88.88.93 (talk) 20:12, 22 December 2021 (UTC)

:::::::::::::: There's a major problem with this, which is why I really don't like the idea of this in article text: reference sections are a common place for sneaky undetected vandalism, even in high-profile articles. This would become a ticking time bomb. Gnomingstuff (talk) 00:21, 24 December 2021 (UTC)

1. There is no way to identify whether removal of a tag is an objection to the proposed deletion. Sometimes with PRODs I see a contributor make a bold edit and remove the PROD tag. It could be because of edit conflicts or it could be because the removal was by mistake.
2. There is no way to see the reason an editor objects to a deletion. Sure some editors use the edit summary to discuss objections to proposed deletion.

I think the following should change:

1. An objection to PROD should be clear. Some new creators may inadvertently remove the PROD tag without giving a reason for why they are removing it.
2. An objection to PROD should turn the PROD into an XfD. This kind of happens but not always.
3. Maybe the PROD templates are unnecessary. We could completely remove those templates and replace PROD with "listing at XfD, waiting for seven days to see if there are any objections to deletion to allow for debate, and then determining consensus". Aka merge PROD with the XfD process.

What do you think? Aasim (talk) 19:00, 29 December 2021 (UTC)

• I'm not sure what changes you're proposing, but the ones I think you're proposing are ones I do not like. The editor who makes a PROD nomination is responsible for watching if there are objections, and nominating an AFD if they are not convinced by the objections. This works and there is no need to complicate it further. If you're suggesting completely removing the PROD process, you will need a clearer proposal. User:力 (powera, π, ν) 19:10, 29 December 2021 (UTC)
• I think that WP:PROD is one of our processes that works very well. It leads to a lot of crap being deleted, but ensures that there is a discussion if there is any doubt about whether it is uncontroversial. I would urge the original poster to show evidence that the suggested changes would be improvements. Phil Bridger (talk) 19:42, 29 December 2021 (UTC)
• {{tq|An objection to PROD should turn the PROD into an XfD}} That should not happen. If I remove a PROD because I don't think that the deletion is uncontroversial, I am very likely not going to be able to provide a good rationale at AfD, other than what was provided in the PROD, which I disagree with. For example, If I de-PROD Jean Emile Oosterlynck, which has been nominated as "No evidence of notability found" but I happen to know that this is the same person as Jean Oosterlynck, who has an entry in [https://doi-org.wikipedialibrary.idm.oclc.org/10.1093/benz/9780199773787.article.B00133169 Benezit], then I don't want to AfD that article. Vexations (talk) 21:21, 29 December 2021 (UTC)
• Conversely, sometimes the de-PROD-er makes a solid argument and/or adds a number of sources, which will convince the PROD-er not to go to AfD. In other words, there's sometimes a good reason why an objection to a PROD does not result in an AfD nomination. JBchrch talk 21:33, 29 December 2021 (UTC)
• I object to these changes because I feel they increase the administrative burden of the PROD process, and I do not see what benefit that is supposed to bring. Also I think the new labor proposed would fall to the person objecting to PROD, when instead I feel that the most labor and responsibility should fall to the person nominating the article for PROD. I support changes which assist anyone in transitioning a PROD to an AfD, but I like PROD for what it is now and AfD for the different thing that it is now. I do not wish to make PROD more like AfD. I do agree with the nominator that I wish we more often had easily accessible records of why users post PRODs or remove them, and I support changes which increase users giving this information, but I do not want users to feel additional pressure to use the process. Blue Rasberry (talk) 21:28, 29 December 2021 (UTC)
• For the newer editors here, we don't want to make the learning curve to operate here even more difficult. Also we don't need to increase the overhead work. SO I am not supporting the suggested proposals. One possible idea if a prod is removed without an edit summary is to put up a special pop up saying that the editor remove a proposed deletion template, and asking them why they did that, with a box for a better edit summary. (maybe edit filters can do this). Graeme Bartlett (talk) 21:45, 29 December 2021 (UTC)
• :I'm going to use an extreme example just to demonstrate the point. Let's say Donald Trump gets PRODed; he is obviously notable via multiple criteria, including WP:NPOL and WP:GNG among others. It would thus be rightfully contested. Why would we thus waste everyone's time by sending it to AfD? Merging PROD with AfD is fundamentally flawed, will be extremely difficult to implement, and will just increase administrators' workload. And in response to you 1st proposed changed for rationale, while we all wish all dePRODers use the edit summary, there is no functional way of enforcing this function. C'est la vie. Curbon7 (talk) 21:56, 29 December 2021 (UTC)
• This proposal seems born out of a misunderstanding of what PROD is for. It is for uncontroversial deletions. It is deliberately designed to be easy to object to. If the PROD is removed, the burden is on the PROD proposer to decide whether to proceed to AFD. Merging the two processes is therefore a terrible idea. Beeblebrox (talk) 22:43, 29 December 2021 (UTC)
• :Good to see some feedback. I also see it as a way for uncontroversial deletions, but one of the problems I have seen with PROD is that I cannot identify whether a removal of a PROD template is an objection or the result of something else like an edit conflict or vandalism or what. Policy does not make this clear.
• :As for point #2 which I made earlier, I am also starting to see why it may be kind of a bad idea, but at the same time, the point of AfD is to discuss whether an article should be deleted or not, which is of course the reasonable next step after a proposed deletion.
• :And for adding something to the abuse filter, that is actually not a terrible idea. Although I am not sure if the filter will pop up in an edit conflict. That prob fixes point #1.
• :It is possible I posted in the wrong subforum, in which case someone is free to move it to idea lab or policy. Aasim (talk) 05:34, 30 December 2021 (UTC)
• ::Even after your clarifications I'm strongly opposed. If the PROD template is removed and it isn't absolutely clear that the removal was vandalism then you must assume that the removal was an objection. A reason for objecting to a PROD is not required, nor should it be required. If you still think that the article should be deleted then you are the one who is responsible for listing it at AfD, it is not reasonable to require this of someone who does not think that article should be deleted. Thryduulf (talk) 12:48, 30 December 2021 (UTC)
• ::The policy on removal of the tag is crystal-clear. It says, "If an editor's intent is unclear, an objection should be assumed." This is simply a procedure for deleting articles that everyone accepts should be deleted without a full discussion, an application of WP:BRD to deletion. If anyone objects then discuss, just as for any other change. Phil Bridger (talk) 19:46, 30 December 2021 (UTC) P.S. And please don't start a discussion somewhere else if you don't like the outcome of this one. Here is fine, and forum shopping is frowned upon. — Preceding unsigned comment added by Phil Bridger (talk • contribs) 19:52, December 30, 2021 (UTC)
• ::Agreed. These are simply not viable proposals. A PROD is supposed to be a low overhead deletion process for uncontroversial deletions. Curbon7's "Donald Trump" example is a perfect counterexample to explain some of the inherent issues with the proposals. We should not be creating a backdoor method for users to effortlessly nominate things for XFD. Vandals would just love that. Meters (talk) 20:07, 30 December 2021 (UTC)
• :::Agree with this. Gråbergs Gråa Sång (talk) 19:47, 1 January 2022 (UTC)

:The Wikipedia community has no control over the fundraising banners, they are run by the Wikimedia Foundation (WMF). You can raise concerns at Wikipedia:Village pump (WMF) or :meta:Talk:Fundraising. --Ahecht (TALK
PAGE) 16:17, 12 December 2021 (UTC)

:Regarding the general principle of providing customized experiences for readers who are not logged in, there is a significant number of people who dislike being tracked in this manner. In theory it could be used solely to disable fundraising banners, but I suspect the resistance to IP tracking will continue to be a barrier for acceptance. isaacl (talk) 16:35, 12 December 2021 (UTC)

::I agree that tracking IPs and donations would be a bad idea, but couldn't we use a browser cookie to track dismissals like we do for watchlists notices? Imagine how pissed off someone needs to be in order to track down the village pump and post this; I think it might be worth figuring out a way to make the banners slightly less annoying for readers. — Wug·a·po·des​ 00:42, 24 December 2021 (UTC)

:::The underlying technology is basically the same: using data in a cookie to correlate your past behaviour with your current action. In theory, maybe people could be convinced that this is only being used to disable fundraising banners. In practice, I'm dubious. isaacl (talk) 21:59, 29 December 2021 (UTC)

::::We already do that right ? At least that is how it used to work for years (can't check, I'm not in the geozone, but if someone else can, plz do check). I think Ppl are just complaining more this year because of increased privacy guards in various browsers blocking the cookies. I suspect. Or they just can't find how to dismiss, because the UX of the banners is so F'ed up? —TheDJ (talk • contribs) 13:59, 3 January 2022 (UTC)

:Adding onto the above, if you don't already know, one easy way to disable the banners is to just create an account and log in, since they're not shown to logged in users. Cheers, {{u|Sdkb}} ^talk 21:07, 13 December 2021 (UTC)

::Well, my understanding is that some fundraising banners are still displayed to logged-in users—to disable them for good, there is a preference in Special:Preferences#mw-prefsection-centralnotice-banners. See also Wikipedia:Suppress display of the fundraising banner. Mz7 (talk) 00:00, 14 December 2021 (UTC)

• We have a template for this.

Welcome and thank you for your question about donations! To hide the fundraising banners, you can create an account and uncheck {{myprefs|Banners|uncheck=Fundraising}}. The Wikimedia Foundation does not track the identity of IP addresses, so it doesn't know your age, income level or whether you donated in the past.
None of the Wikipedia volunteer editors here who add and improve content in articles receive any financial benefit. We all simply contribute our time because we care about building a great encyclopedia for you and innumerable others around the world to use.
If you cannot afford it, no one wants you to donate. Wikipedia is [https://www.dailydot.com/debug/wikipedia-endownemnt-fundraising/ not at risk of shutting down], and the Wikimedia Foundation, which hosts the Wikipedia platform and is asking for these donations, is [https://news.ycombinator.com/item?id=29528791 richer than ever].
We are led to believe that users who allow cookies are less likely to see these banners on repeat visits (further information is available here), and you are welcome to communicate directly with the donor-relations team by emailing donate@wikimedia.org. Thank you!

Beeblebrox (talk) 22:39, 29 December 2021 (UTC)

:Relevant wikitext: {{subst:WikiDonation}}. Certes (talk) 22:47, 29 December 2021 (UTC)

Qwerfjkltalk 19:09, 4 January 2022 (UTC)}}

Sitting on the edge of a policyproposal I do think it belongs here though.

Wikipedia is said to be an unbiased, non-reliant and objective source of information. Yet it follows the remnant of 'our' (I'm European) religious and colonial past by presenting the years as BCE/BC and CE/AD. Wikipedia should be an inclusive platform, for all human knowledge, without a bias towards Christianity and its systems introduced often by means of oppression. Only about a third of all humans consider themselves Christian according to the wikipedia page on World Religion. More than half the population in my home country (The Netherlands) consider themselves as non-religious according to official CBS statistics in 2020. With the start of the new year 12022 HE I wanna start the discussion of introducing the Holocene calendar on wikipedia worldwide, as default yearnumbering system with the local dominant system only presented in between brackets if dates are named in an article. Let Wikipedia be a forerunner in the introduction of an inclusive calendar reform. What are your thoughts on this?

Grifo (talk) 13:29, 3 January 2022 (UTC)

: Wikipedia follows the sources, it doesn't lead them. Convince most of the English-speaking world to start using a new Common Era and Wikipedia will follow. As it is, why should we use the "Holocene calendar" (which itself seems to be off by ~300 years) rather than declaring the current year as −72 BP? And why not rename the months to not be mostly named after old Roman gods and numbers that are off by two? Anomie⚔ 13:51, 3 January 2022 (UTC)

::Can you define 'the sources' please? I thought Wikipedia was about following reliable, unbiased sources. Not some 6th century monk (Dionysius) who erroneously placed the birth of his religious frontfigure randomly along a timeline, which was applied as yearnumbering system ever since due to the makeup of contemporary society.

::I'm ok with the BP calendar, but the HE is more practical. The years the Holocene calendar might be off compared to the assumed real onset of the Holocene is a minor issue. We will never know the exact year the Holocene started, nor will there ever be an historical neolithic event dated so precisely that the HE calendar needs a reform to allow that event to be fixed inside the calendar.

::The 'standardized' Roman/Germanic name of months and days doesn't render the same effect of applying value to certain historic events likr yearnumbering does (i.e. before time began or after a certain local and subjective event took place: after time began), implying less importance to the events prior to year 1. With either the BP or the HE calendar, such exclusive subjectiveness of implied value of events is removed and is instead replaced by an objective marker having the same value for all citizens of the world as the event (Holocene/Nuclear Era) was omnipresent. Grifo (talk) 15:42, 3 January 2022 (UTC)

:::It seems there are several incorrect assumptions above. To see what Wikipedia actually is fundamentally, start with Wikipedia:General disclaimer. Then proceed to something like WP:NOT which, even though not as embedded as the first, is also pretty basic. And so on. What "Wikipedia should be" is an opinion, which anyone may embellish with moralizing of one sort or another without in any way affecting its factual validity. Other than that, I've no idea if what you suggest is technically actionable. 65.88.88.201 (talk) 16:01, 3 January 2022 (UTC)

:::This isn't about when Jesus was born, or even whether he existed. (There's at least as much doubt that the changes marking the Holocene epoch occurred in precisely 10,000 BCE.) The important thing is the WP:COMMONNAME of the current year, and most English speakers seem to call it 2022. Any campaign to change that should not start at Wikipedia. Certes (talk) 17:24, 3 January 2022 (UTC)

• {{u|Grifo}} As noted, you are going to need to launch a worldwide campaign to persuade governments and people to adopt your preferred calendar, before Wikipedia can do so. 331dot (talk) 16:05, 3 January 2022 (UTC)
• I have many articles about archaeological sites and cultures on my watchlist, many of which use BCE/CE. I see far more users who are not familiar with our guidelines trying to convert BCE/CE to BC/AD, than the other way round (and I don't recall anyone trying to convert the era designation to HE or BP). Even if there were a consensus to ignore the sources (overturning some core Wikipedia policies), I doubt there would be any consensus to use anything other than BC/AD as the default era designation. - Donald Albury 17:35, 3 January 2022 (UTC)
• Civil calendar states that most civilizations use the CE/BCE system with the Gregorian calendar - so even outside of what the sources may document dates in, it is the reference frame that English literate readers of our encyclopedia would expect when reading articles. — xaosflux ^Talk 18:34, 3 January 2022 (UTC)
• {{tq|More than half the population in my home country (The Netherlands) consider themselves as non-religious...}} but what calendar do they actually use? The Gregorian calendar. The vast majority of countries use the Gregorian calendar for at least some purposes and the few countries which don't will nevertheless be familiar with it. This is particularly true for English speakers, which are the target audience of the English Wikipedia. Switching to an alternative such as the Holocene calendar would just confuse people who aren't familiar with that calendar. Wikipedia generally follows the rest of the world (or at least English speakers) in matters like this, you should try convincing others first. Hut 8.5 12:59, 4 January 2022 (UTC)

::But how to convince others when something grassroots like Wikipedia follows the dictate of past colonial society which implemented the Gregorian Calendar worldwide, disregarding any cultural heritage of oppressed peoples? Where to start when even Wikipedia does not follow its own standards? Wikipedia is based on reliable sources. The Monk I mentioned is not a reliable source at all, yet Wikipedia follows his yearnumberingsystem everywhere. I am NOT opposing the Gregorian Calendar though, I'm opposing the starting point of it. The starting points of the Holocene Calendar or the Carbon Dating Calendar (BP) are much better, much more inclusive, much more reliable, much less subjective to pre-Christian times and have a worldwide recognisable starting point. Something an encyclopedia should prefer, despite the inconveniance this might result in to alter all dates.Grifo (talk) 16:33, 4 January 2022 (UTC)

:::Apart from all other arguments against this given above; you are aware that the Holocene calendar is "directly" based on the same BC/AD calendar, but simply moves it back exactly 10,000 years? If you want to get rid of the influence of Christianity or the calculations of a monk, then using the Holocene calendar is not the solution at all. Fram (talk) 16:42, 4 January 2022 (UTC)

::::perhaps Stardate.... — xaosflux ^Talk 16:55, 4 January 2022 (UTC)

:::Because it would confuse the hell out of just about everybody. Everybody knows that it this year is 2022, and would think that {{#expr:10000+{{CURRENTYEAR}}}} HE is a typo. And just think for a moment about having to change almost every citation. Vexations (talk) 16:57, 4 January 2022 (UTC)

• Let me ask a related question: "Isn't writing this in English a vestige of European colonialism?" The only reason a lot of people in the world speak English today is because a few hundred years ago, the English built boats and sailed to other continents where they conquered the native populations. The Spanish, French, Portuguese, Dutch, etc did a lot of that too. The only reason I speak English is because my great-grandparents left their homes and came to the United States, where they learned English (but didn't convert to Christianity). Isn't continuing to use those languages to write encyclopedias just following the remnants of our colonial past? Well, yeah, but as noted above, wikipedia's job is to collect and document information, not to be a leader for sweeping social change. We use CE dates not because we think they're best, but because that's what most of our sources use, and what our readers are used to. Looking at the home pages of the zh, hi, ar, and he wikis, I see they all use CE dates. Surely if CE dates are good enough for those wikis, it's good enough for enwiki. -- RoySmith (talk) 17:25, 4 January 2022 (UTC)
• Not going to happen, nor should it. Time to stop wasting time discussing it. Johnbod (talk) 17:57, 4 January 2022 (UTC)

{{archive bottom}}

Proposal: Should we establish new tags (list) that automatically appears on edits made by revealed sockpuppets? And another tag for edits made by users who are currently blocked for reasons like vandalism, disruptive editing, multiple test editing, etc. This would help editors skimming through edit history of a page identify potential problematic edits made by users who are blocked for violating WP rules. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 22:32, 4 January 2022 (UTC)

:It's not a bad idea. There are user scripts that automatically flag blocked accounts a number of ways with colors or strikethroughs. These should be standard IMO. -- GreenC 22:38, 4 January 2022 (UTC)

::Special:Preferences#mw-prefsection-gadgets has "Strike out usernames that have been blocked". Is that what you mean? Vexations (talk) 23:11, 4 January 2022 (UTC)

:markblocked, which you can enable in preferences, accomplishes roughly the same thing (you can hover over the blocked editor's username to see the block reason). Using tags to do this doesn't seem like a good idea. AFAIK this would require an admin (or adminbot) to add the tags whenever someone gets blocked, and remove them if they successfully appeal; the script, on the other hand, requires no additional maintenance work. The whole business of blocked users, sockpuppetry, etc. is also largely irrelevant to the average user, who only comes here to fix a typo once in a while. I think it's best to leave it as an optional gadget for those interested. Spicy (talk) 23:28, 4 January 2022 (UTC)

::It doesn't require an adminbot. The bot usergroup has the changetags userright, so any bot account can do this. ProcrastinatingReader (talk) 02:13, 5 January 2022 (UTC)

:markblocked or similar sounds like a better idea, as it will update automatically whenever the [ir]responsible editor is blocked and unblocked. Tags are for properties of an edit, whereas this proposal is about the properties of a user. Good users occasionally make bad edits, and vice versa. Certes (talk) 02:18, 5 January 2022 (UTC)

About [https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets Preference, Gadgets]: four codes are listed and described in the

Gadget legend: (D), (E), (S), (U). The descriptions appear in the list as {{tl|abbr}} like ^{({{abbr|D|Emabled for everyone by default}})}, OK. Now, between the four the period (full stop) is alternating missing/present in the abbr tooltip text. Maybe could be smoothed?

(I personally do not think for this issueette the Project should be restarted from 20 year ago, but I do like to take my examples from high end quality webpages ;-) ). -DePiep (talk) 06:58, 7 January 2022 (UTC)

:{{ping|DePiep}} I'm closing this section as this is a very minor tweak that shouldn't require a community proposal. See MediaWiki_talk:Gadgets-prefstext#Tool_tips and feel free to just open an edit request there for any sorts of minor updates you would like made on the labels. — xaosflux ^Talk 11:28, 7 January 2022 (UTC)

{{archive bottom}}

| status =

| result =

There is support for most changes proposed, and they may be rolled out. There is also support for the idea that most typical changes to cs1/2 are uncontroversial and don't need to undergo routine VPR RfCs to be rolled out.

The crux of the opposition, aside from the comments about the nature of the all-or-nothing RfC, centred on the removal of deprecated parameters. Although the argument in later comments, that we don't generally support old historical revisions, is strong in the context of TfD, its application to citation templates was disputed in the widely-attended Monkbot 18 RfC. So I think there is no consensus on removal of deprecated parameters in this discussion, and further discussion will be necessary to roll that part out. ProcrastinatingReader (talk) 16:45, 15 January 2022 (UTC)

}}

Yes or No. Shall the Citation Style 1 / Citation Style 2 (cs1/2) Lua module suite be updated to reflect the changes that have accumulated in the module-suite's sandboxen?

This is an all or nothing rfc. In the event of a draw, cs1/2 shall be updated. §list of prospective changes gives brief descriptions of the individual changes and links to related discussions.

—Trappist the monk (talk) 23:11, 28 November 2021 (UTC)

{{collapse top|list of prospective changes|bg=#E5E4E2}}

changes in Module:Citation/CS1/sandbox

• detect generic author, editor, etc names; discussion
• emit error when {{para|first}} is wikilinked; discussion
• add {{cl|CS1 tracked parameter: $1}} properties tracking category; discussion
• revise how date month-name auto-translation is enabled; discussion and discussion
• add support to allow editors to see citations that emit properties cats; discussion
• {{para|url-status}} without {{para|archive-url}} maint cat: {{cl|CS1 maint: url-status}}; discussion
• more consistent support of {{para|type}} with {{tlx|cite speech}}; discussion
• check all but url-holding and insource-locator parameters for inappropriate urls; discussion
• recognize stand-alone {{para|script-chapter}} in {{tlx|cite encyclopedia}}; discussion
• fix flaw in ref-duplicates-default detection; discussion
• added error summary preview; discussion
• reworked error messaging; discussion
• fix {{para|archive-url}} preview url; discussion
• tweaked IETF-like language handling; discussion
• changed formatting of volume and issue for non-journals; discussion
• moved hyphen_to_dash() to ~/Utilities; discussion
• detect leading '=' as extraneous punctuation; discussion

changes in Module:Citation/CS1/Configuration/sandbox

• detect generic author, editor, etc names
• add Category:CS1 tracked parameter: $1 properties tracking category
• remove support for unused {{para|isbn13}} and {{para|ISBN13}}; discussion
• remove support for previously deprecated parameters {{para|booktitle}}, {{para|chapterurl}}, {{para|episodelink}}, {{para|mailinglist}}, {{para|mapurl}}, {{para|nopp}}, {{para|publicationdate}}, {{para|publicationplace}}, {{para|serieslink}}, {{para|transcripturl}}
• add support for nrf-gg, nrf-je language codes; discussion
• revise how date month-name auto-translation is enabled
• add support to allow editors to see citations that emit properties cats
• removed reliance on .error; discussion
• {{para|url-status}} without {{para|archive-url}} maint cat: Category:CS1 maint: url-status
• add support for {{para|ssrn-access}}; discussion
• add ab to script_lang_codes{};
• more consistent support of {{para|type}} with {{tld|cite speech}}
• check all but url-holding and insource-locator parameters for inappropriate urls
• add yue to script_lang_codes{};
• added bogus name "Verfasser" to the list; discussion
• add keyword "deviated" to {{para|url-status}}; discussion
• added preview error summary
• added 'Login • Instagram' to generic titles;
• removed crh, nrg-gg, and nrf-je from language override
• added comma between volume and number; discussion
• added Mr. Privacy Statement, Ms. Cookie Policy and Dr. Submitted Content to list of bogus names; discussion
• revise kerning; discussion
• i18n {{para|script-<{{var|param}}>}} error message supplements; discussion
• added 'Usurped title' to generic titles; discussion
• added add bogus names: 'author', 'collaborator', 'contributor', 'editor', 'interviewer', 'translator'; discussion

changes in Module:Citation/CS1/Whitelist/sandbox (last update 2021-05-25)

• removed deprecated parameter {{para|transcripturl}}
• deprecated {{para|lay-date}}, {{para|lay-format}}, {{para|lay-source}}, {{para|lay-url}}; discussion

changes in Module:Citation/CS1/Date validation/sandbox

• extend allowed dates in {{para|pmc-embargo-date}} validation to two years; discussion
• revise month-name validation;
• add support to allow editors to see citations that emit properties cats;

changes in Module:Citation/CS1/Identifiers/sandbox

• add support for {{para|ssrn-access}};
• reworked error messaging;
• fix false positive doi error detection; discussion
• strip accept-this-as-written markup from all identifiers for metadata; discussion

changes in Module:Citation/CS1/Utilities/sandbox (last update 2021-01-09)

• add support to allow editors to see citations that emit properties cats;
• reworked error messaging;
• added hyphen_to_dash() moved from main module;

changes in Module:Citation/CS1/COinS/sandbox

• strip accept-this-as-written markup from {{para|title}};

changes in Module:Citation/CS1/sandbox/styles.css (last update 2021-01-09)

• Removed reliance on .error;
• Removed extra kerning classes;
• Removed unused cs1-subscription/registration styles;
• Moved .citation styles from MediaWiki:Common.css;
• Removed <code> selector;

{{collapse bottom}}

—Trappist the monk (talk) 23:11, 28 November 2021 (UTC) 23:25, 3 December 2021 (UTC) {{small|(update link)}} 17:42, 23 December 2021 (UTC) {{small|(update links)}}

|add {{cl|CS1 tracked parameter: $1}} properties tracking category; discussion (My observation: this doesn't actually add any new tracking categories, but merely adds code to populate such tracking categories if they are later needed)

| added error summary preview; discussion

| remove support for previously deprecated parameters {{para|booktitle}}, {{para|chapterurl}}, {{para|episodelink}}, {{para|mailinglist}}, {{para|mapurl}}, {{para|nopp}}, {{para|publicationdate}}, {{para|publicationplace}}, {{para|serieslink}}, {{para|transcripturl}}.

}}. Overall, I question whether it's appropriate to remove (or to have deprecated in the first place) unhyphenated parameter aliases given the result of Wikipedia:Village pump (proposals)#RFC: Citation Style 1 parameter naming convention. Despite Trappist the monk's framing of the issue as all-or-nothing, the rest of the update is not in some way dependent on those changes, and it is anyway not sufficient to convince me not to support this update. * Pppery * _{it has begun...} 23:31, 28 November 2021 (UTC)

• :FWIW, the deprecation of the above parameters happened in February 2021, more than nine months ago, all of the parameters were updated shortly thereafter, and any stray instances of those parameters have been generating error messages (and have been quickly fixed) since April 2021. This update would change the error message from "deprecated" to "unsupported" in the very rare instance that someone used one of these long-gone parameters. This change should not be confused or conflated with the objected-to deprecation of {{para|accessdate}}, which is still in wide use. – Jonesey95 (talk) 17:08, 29 November 2021 (UTC)
• ::How long have they been used and how many old revisions will be broken by removal of these parameters? And what is gained by removing them? —Kusma (talk) 09:38, 30 November 2021 (UTC)
• :::These parameter aliases were not commonly used. Hyphenated versions of them have been the standard since 2014. Dozens of unhyphenated multi-word parameters have been deprecated and removed from the CS1 citation templates over the past seven years with a minimum of drama (until the final six were proposed for deprecation back in April 2020, which is not something that is happening in this RFC). – Jonesey95 (talk) 14:19, 30 November 2021 (UTC)
• ::::That does not answer any of Kusma's questions. Thryduulf (talk) 17:54, 30 November 2021 (UTC)
• ::: I'll make an attempt to answer some of Kusma's questions. Per User:Monkbot/task 18: cosmetic cs1 template cleanup#hyphenate cs1{{pipe}}2 parameter names, before Monkbot 18 ran:
• :::# {{para|booktitle}} was used 3,345 times
• :::# {{para|chapterurl}} was used 17,289 times
• :::# {{para|episodelink}} was used 2,539 times
• :::# {{para|mailinglist}} was used 379 times
• :::# {{para|mapurl}} was used 81 times
• :::# {{para|nopp}} was used 2,902 times
• :::# {{para|publicationdate}} was used 542 times
• :::# {{para|serieslink}} was used 5,042 times
• :::# {{para|transcripturl}} was used 910 times
• ::: That totals 33,029 pages (which is an overestimate, as some pages likely used more than one such parameter). * Pppery * _{it has begun...} 22:36, 1 December 2021 (UTC)
• ::::For a sense of scale, :Module:Citation/CS1 is used in just over 5,000,000 pages. 33,000 pages was a little less than 0.7% of the total page usage. That is why it was so straightforward and easy to deprecate and update the above parameters, as opposed to the six remaining unhyphenated parameters, which are more widely used. – Jonesey95 (talk) 23:00, 3 December 2021 (UTC)
• :::::OK, so the damage is middle sized (17000 broken chapterurls will create some annoyance). But removing these aliases still doesn't have any obvious advantages over not removing them. —Kusma (talk) 16:40, 7 December 2021 (UTC)
• {{Tq|In the event of a draw, cs1{{!}}2 shall be updated.}} This isn't normally something an editor opening an RfC can unilaterally declare, nor is an RfC's all-or-nothing status. Per WP:Consensus, if there's no consensus, we generally retain the status quo. {{u|Sdkb}} ^talk 23:33, 28 November 2021 (UTC)
• :It is totally inappropriate, and whoever closes this should ignore this made-up rule that has no policy-based support whatsoever. In the event of "no consensus overall", the changes that are supported by consensus should be applied and the changes not supported by consensus not applied. —Kusma (talk) 09:36, 30 November 2021 (UTC)
• Waste of time RFC it's utter nonsense that we have to wait for months for CS1|2 updates to be rolled out, it's even more utter nonsense that we need RFCs to roll them out. If they're ready and have consensus, roll them out as soon as they've been tested in the sandbox and confirmed as working as intended. Don't delay, and don't plague us with pointless RFCs. If a particular issue is contentious, have an RFC on that issue, don't hold the rest of the updates hostage. Headbomb {t · c · p · b} 00:45, 29 November 2021 (UTC)
• I don't like the format of this RfC. It would be better done by a different method: {{olist|Propose these changes and see if anyone opposes one or more of them. {{ulist|Unopposed (uncontroversial) changes can be immediately implemented or held until after the second part.|Opposed (controversial) changes would need consensus in part 2.|Obviously uncontroversial changes don't need to be included.}}|Open a multi-section RfC with a section on each controversial change, and let each section gain consensus individually.|Implement changes that were either uncontroversial in part 1 or gained consensus in part 2.}} I don't think that the RfC should be closed as flawed, but it should be evaluated based on consensus for each of the proposed changes rather than "all or nothing", and no consensus should lead to retaining the status quo. Tol (talk | contribs) @ 21:57, 30 November 2021 (UTC)
• Why is this an all or nothing? Why will it pass in the case of a tie? Dege31 (talk) 18:24, 3 December 2021 (UTC)
• :The cynical view is because that's the only way the proposer(s) do not wish to test the consensus of the changes individually, possibly because some of the desired changes may not pass. You are not the first to ask the question, but none of the responses have provided a plausible alternative view, although malicious intent has been denied. Thryduulf (talk) 21:31, 3 December 2021 (UTC)
• :
• :Changes to cs1|2 are not made secretly behind a veil; all editors are welcome, encouraged, to participate in the discussions about cs1|2 at Help talk:Citation Style 1. There is no need to re-discuss that which has already been discussed (see the discussion links in the collapsed box at {{slink||list of prospective changes to the cs1/2 module suite}}). Except for the most minor of changes, all changes to cs1|2 are always discussed, mostly at Help talk:Citation Style 1 and sometimes, at other locations (Help talk:CS1 errors and Template talk:Citation are common alternate-discussion locations).
• :
• :In my experience – yours may be different – inconclusive RFCs result in the question: 'now what?' To avoid the 'now what?' question, I defined an action to be taken in the event that the community's opinion is not definitive. So now you know. The answer to the 'now what?' question for this RFC is: update.
• :—Trappist the monk (talk) 23:25, 3 December 2021 (UTC)
• ::{{tq|There is no need to re-discuss that which has already been discussed (see the discussion links...}} But not all of those discussions reached a consensus in favour of the proposed changes. That suggests that either they do need to be re-discussed, or they should be removed from the proposal. Nikkimaria (talk) 00:03, 4 December 2021 (UTC)
• ::{{replyto|Trappist the monk}} {{tpq|inconclusive RFCs result in the question: 'now what?'}} This could not have been an inconclusive RfC - either there is consensus for the changes or there is no consensus for the changes. In the first case the changes are implemented, in the second case they aren't. If the changes did not get consensus there is nothing stopping anyone who understands why they failed to get consensus addressing the reasons and asking the community about the revised proposal. Everywhere else on Wikipedia changes for which there is no consensus do not get implemented, and there is no reason for this to be any different. Thryduulf (talk) 11:32, 4 December 2021 (UTC)
• :::
• :::The question asked by this RFC is simple: {{tq|Yes or No, shall we update?}} If the community's answer as determined by the closer is predominantly Yes then we update; if the community's answer as determined by the closer is predominantly No, then we do not update. If the community's answer as determined by the closer is inconclusive then we update and avoid the 'what now?' question. Because it is stated in the question, all respondents to this RFC know what to expect in the event of a tie.
• :::—Trappist the monk (talk) 13:34, 4 December 2021 (UTC)
• ::::Lol ttm like that would ever fly. The initiator of this RFC knows what to expect if updates are pushed without consensus. Levivich 14:06, 4 December 2021 (UTC)
• ::::If the answer as determined by the closer is "inconclusive" then anywhere else on Wikipedia the status quo would apply, which in this case would mean "we do not update". You have not explained why this RfC should be different to everywhere else. Thryduulf (talk) 18:06, 4 December 2021 (UTC)
• How much of a maintenance burden would it be to keep the deprecated parameters around? I sometimes worry that while the desire to keep old revisions working is reasonable, keeping the old parameters around might create extra work when updating/maintaining/adding new functionality to CS1/2 templates and we might be neglecting this extra work. Jo-Jo Eumerus (talk) 10:42, 4 December 2021 (UTC)
• :In the last RFC, which found "There is a rough consensus that non-hyphenated parameters should not be deprecated in citation templates" (emphasis in original) the maintenance burden was brought up multiple times, but nowhere in the discussion could I find anywhere that detailed exactly what that burden is or why it is so significant that it was more important than the various benefits of keeping them around (not breaking old revisions, editor familiarity, ease of use, etc). Certainly none of the arguments about maintenance burden convinced people in opposition to deprecation to change their minds. Thryduulf (talk) 11:43, 4 December 2021 (UTC)
• Some think it's okay to remove old parameters and some think we should keep them to preserve page history. Personally I do not think it is possible or needed to make sure that a page history will work forever. But I agree that it would be good to preserve page history for some time. So perhaps as a compromise there could be some time limit so parameters used on less than 1k pages could be removed faster than pages used on 1M+ pages? --MGA73 (talk) 23:33, 27 December 2021 (UTC)
• I've requested closure of this RfC. Tol (talk | contribs) @ 20:59, 9 January 2022 (UTC)

{{closed rfc bottom}}

(talk • contribs) 19:09, 12 January 2022 (UTC)

:I think that the Wikipedia search function is pretty useless on many counts as well as this one, so it is better to perform a site search with your favourite search engine anyway. This is just one of the features that would be useful to readers of this site and wouldn't cost much to implement, but the WMF prefer to spend the vast amounts of money that they receive from the public on expansion of their role and self-perpetuation. Phil Bridger (talk) 19:27, 12 January 2022 (UTC)

::In the particular regard of the search bar, I think there is more of a persistent fear to do anything with it. The knowledge project had such dramatic outcomes that I suspect it's poisoned the well in terms of additional search functionality expenditure. Nosebagbear (talk) 13:41, 13 January 2022 (UTC)

:This would be better to suggest at :meta:Community Wishlist Survey 2022. --Ahecht (TALK
PAGE) 18:43, 13 January 2022 (UTC)

:This idea has been investigated in the past, but the implementation wasn't completed: T138958. Matma Rex talk 22:24, 18 January 2022 (UTC)

: .... 0mtwb9gd5wx (talk) 07:44, 9 January 2022 (UTC)

::I have no opinion as yet on whether this would be a good change, and am unlikely to form one unless you say why you are proposing it. Phil Bridger (talk) 08:24, 9 January 2022 (UTC)

:Set index articles are not dabs, because dabs are not articles. However, they have many features in common and some SIAs might work better as dabs. (For example, Ministry of Defence is denied the benefit of our dab maintenance tools because its meanings happen to form a set.) It might be useful if some or all SIAs were more dab-like in ways that I'm struggling to define. Perhaps that means creating maintenance category(s) which include {{cl|All disambiguation pages}} and some or all SIAs, such as {{cl|Pages which should have no direct incoming links}}, and encouraging {{tl|R from disambiguation}} redirects to its SIAs. Alternatively, it might mean allowing certain lists to be formatted as dabs instead of SIAs. I would also be interested to see more specific proposals. Certes (talk) 14:29, 9 January 2022 (UTC)

:Set index articles exist as a concept distinct from disambiguation pages because there are topics/titles that need disambiguation but which cannot be made to fit within the strict formatting requirements of disambiguation pages (or the reader otherwise benefits from a different format). Given that the rigidity of the disambiguation page formatting seems to be desired by those who maintain the pages, I don't foresee any likelihood of a merge gaining consensus soon. Thryduulf (talk) 15:21, 9 January 2022 (UTC)

:: An important feature of Set index articles is that they may consist of redlinks, whereas dabs can not. For example, this set index article is certainly useful, since it contains a list of all localities with this name (and can be used, for example, to choose proper name for new articles and even for redlinks). If converted to dab, it is amenable to speedy deletion, since there is nothink to disambiguate. I have such articles on my watchlist being nominated for speedy deletion by users who do not understand the difference.--Ymblanter (talk) 19:04, 9 January 2022 (UTC)

• No. Disambiguation pages are lists of articles. SIAs are lists of actual things. Shhhnotsoloud (talk) 15:18, 18 January 2022 (UTC)
• :I think there are (at least) two cases here. On the one hand, HMS Nonsuch is an SIA, a list of actual things, some of which have no article and even no WP:DABMENTION. It doesn't meet our standards for a dab and shouldn't be changed to comply with them because it is not a dab. (However, it is of use to someone who wants to read one article about a ship of that name and doesn't recall enough detail to guess its exact title.) On the other hand, Ministry of Defence acts as both a list and a dab; the only thing preventing it from being a dab is the unwritten rule that at least one dab entry must be unlike the others. (So if someone wrote Ministry of Defence (film), we could list it and call the page a dab.) Certes (talk) 16:53, 18 January 2022 (UTC)
• No. Disambiguation pages are lists of articles with similar titles, which could describe different types of thing. e.g. St. Helen. Set Indexes are lists of things of the same type with similar names, some of which may never have articles, e.g. List of lakes named McArthur. Not the same at all. Aymatth2 (talk) 17:10, 18 January 2022 (UTC)
• Leaning oppose. A set index can be a title to which a link is intended to point in reference to the things listed on the page. A disambiguation page is supposed to have no incoming links, except links with (disambiguation) in the title to signify that the link intends to point to the disambiguation page, for the purpose of indicating that it is a disambiguation page. BD2412 T 07:36, 19 January 2022 (UTC)

• This is common when the name implies the type of thing, e.g. Round Lake or Big Mountain. If you have a list of things of the same type with the same or similar names, and they all have articles, disambiguation is the most common choice. If you want to add things that do not have articles to the list, or add some structure, make it a set index. Aymatth2 (talk) 18:11, 18 January 2022 (UTC)

About 200 infoboxes have a {{para|native_name}} parameter, sometimes accompanied by a {{para|native_name_lang}} parameter. There include widely used infoboxes such as {{tl|infobox settlement}}, {{tl|infobox person}} and {{tl|infobox river}}. Validation and formatting is inconsistent, particularly when there is no {{para|native_name_lang}} parameter. Users struggle when there is more than one native name.

Examples:

:|native_name =Firenze

:|native_name = Dakȟóta itókaga{{spaces|2}}(Sioux)

:|native_name = {{nobold|Јосип Броз Тито}}

:|native_name = {{lang|fr|Société des Nations}}

:|native_name = Ḫa-at-tu-ša / 𒄩𒀜𒌅𒊭

: |native_name = {{plainlist|1=

::* {{lang|it|Repubblica dell'Isola delle Rose}}}}

:|native_name = {{native name|la|Regnum Hierosolymitanum}} {{native name|fro|Roiaume de Jherusalem}}

This has been discussed at Wikipedia talk:WikiProject Infoboxes#native name parameters, where the subject was brought up by {{u|Trappist the monk}} and comments were given by {{U|Ineffablebookkeeper}}, {{U|Gonnym}}, {{U|Moxy}}, {{U|MB}} and {{U|Jmcgnh}}. There was agreement that something should be done to make handling of native names more consistent across infoboxes and to improve validation. {{u|Trappist the monk}} has begun working on changes to a few of the infoboxes. This is to ask for comments in the correct approach from the broader community before we change a great many articles.

Two alternatives are described below, both of which would be implemented using standard code in all infoboxes that support {{para|native_name}}, with the validation and formatting code buried in templates such as {{tl|native name}}, {{tl|native name list}} or a new {{tl|format native name}} so that global improvements can be made later. Aymatth2 (talk) 13:42, 16 January 2022 (UTC)

• Remove the {{para|native_name_lang}} parameter from infoboxes that support it, such as {{tl|infobox settlement}}, {{tl|infobox person}}
• Require that {{para|native_name}} always be entered as

:::|native_name ={{native name|lang|name}}

:or

:::|native_name ={{native name list||tag1=lang|name1=name|tag2=lang|name2=name...}}

• When rendering the result, display an error message if the {{para|native_name}} parameter does not appear to be correctly formatted

• Add the {{para|native_name_lang}} parameter to those infoboxes that do not support it

:::|native_name =

:::|native_name_lang = <!-- 2–3 digit ISO code, e.g. de, fr -->

• When rendering the result,
• If {{para|native_name_lang}} has been specified, render {{native name|{{{native_name_lang}}}|{{{native_name}}} }}
• Check for unlikely characters in {{{native_name}}} such as "(" or ":" and place the article in a hidden error category if found.
• Otherwise render {{{native_name}}}, which the editor may have formatted using {{tl|native name}} or {{tl|native name list}}
• Check that the rendered name appears to be correctly formatted using {{tl|native name checker}}, and place the article in a hidden error category if not

::We have examples of infoboxes that do not have a {{para|native_name_lang}} parameter such as {{tl|infobox French commune}} (where native language may be br, oc, co, de, etc.) and of templates that have the parameter such as {{tl|infobox settlement}}. It would be interesting to check the percentage of malformed native names with these different templates. If the quality is significantly better for the infoboxes with a {{para|native_name_lang}} parameter, it is surely wrong to remove it. Aymatth2 (talk) 15:30, 17 January 2022 (UTC)

There seem to be no strong feelings that supporting {{para|native_name_lang}} will cause more problems than it solves, and two out of four are very positive about it, so at this stage it seems that we should go ahead with ALT2. Aymatth2 (talk) 18:13, 19 January 2022 (UTC)

1. All infoboxes that accept native name, including {{tl|infobox settlement}} and {{tl|infobox person}} will be modified to use the new parameters and formatting / validation logic
2. The template's usage notes will show:
3. :|native_name{{space|5}} = {{space|10}}<!-- If more than one, use {{tl|native name list}} -->
4. :|native_name_lang = {{space|10}}<!-- Use ISO code, e.g. "fr" for French -->
5. The standard rendering logic will look something like
6. : |label5 = Native name
   |data5 = {{native name checker |{{{native_name}}} |{{{native_name_lang}}} |errordisp=cat |multi=yes}}
7. {{tl|native name checker}} will check to see if {{{native_name}}} has a validly formatted {{tl|native name}} or {{tl|native name list}} result, and if so will ignore {{{native_name_lang}}}
8. Otherwise, {{tl|native name checker}} will check the syntax of {{{native_name}}}, and then format using {{native name |{{{native_name_lang}}} |{{{native_name}}} }}. The syntax checks are to catch common problems like names coded as {{para|native name|San Lorenzo (Italian)}}
9. If {{para|errordisp|cat}}, {{tl|native name checker}} will present errors or warnings as (e.g.) Category:Native name contains unusual characters. This is for use during the transition, to avoid flooding existing articles with red error messages. Once the bulk of the errors in the hidden categories have been cleared, the template can be changed to |errordisp=strict. {{tl|native name checker}} will now generate red error messages like {{native name|French|Saint Laurent}}, so editors see their mistake at once.
10. The parameter {{para|multi|no}} may be needed to suppress support of multiple names in some infoboxes. {{tl|Infobox settlement}} defines {{para|native_name}} as "Name in the official local language, if different from name, and if not English." This seems to imply that only one official name is allowed.
11. Before starting to convert articles using the major infoboxes, we should confirm on their talk pages that the overall approach is acceptable, and specifically that multiple names are allowed.

Aymatth2 (talk) 18:13, 19 January 2022 (UTC)

::Fair enough. But {{tl|Infobox settlement}} does not seem to do anything with {{para|native_name_lang}} apart from putting the name in a <div> with {{para|lang|"{{{native_name_lang}}}"}}, which presumably has something to do with non-Latin characters. So we should check with the experts on {{tl|Infobox settlement}} to make sure they are o.k. with the change in appearance. Aymatth2 (talk) 19:09, 19 January 2022 (UTC)

: {{re|Wjohns19}} Ask at WP:MCQ, where users knowledgable in copyright answer questions. RudolfRed (talk) 03:33, 22 January 2022 (UTC)

Also, please recreate the neels temperature page. (I think Linus Torvalds was being extra special again).

Add seebeck coefficient to all the metals' wiki page.

Err... Add curie temp or Neel temp too.

Redirect quantum physics pages to relevant particle physics/nuclear physics pages.

And niobium has been removed from the curie temperature page? It was the most significant metal on that page because of super conductors.

:{{Reply|ElSeaLC}} Very interesting, but I must digress from the topic you mention: {{ping|El_C}} FYI, seen this before? Mako001 (C)  (T)  04:03, 23 January 2022 (UTC)

::Wait, now I have variances? Damn you, pocket dimensions! El_C 14:09, 23 January 2022 (UTC)

: Not sure if we should be splitting the discussion from there to here, but I'll go ahead and repeat what I just wrote there: I agreed with Rusalkii that instead of having a bot outright decline unsourced submissions, let's have the bot list such submissions on a page so that human reviewers can more easily identify them to be declined. Mz7 (talk) 10:11, 23 January 2022 (UTC)

::Ideally a bot that does that and pings the article creator going "This aint going to pass without sources". Only in death does duty end (talk) 12:30, 23 January 2022 (UTC)

:::The AfC submission script already does that (see [https://en.wikipedia.org/w/index.php?title=Wikipedia:Articles_for_creation/Submitting&withJS=MediaWiki:AFC-submit-wizard.js&page=Draft:Sandbox]), even before the draft gets submitted. – SD0001 (talk) 15:51, 23 January 2022 (UTC)

::::{{re|SD0001}} That's very cool! I'd certainly support making that warning message a little bolder, though (maybe make it orange or red, not just yellow, and add a box). {{u|Sdkb}} ^talk 06:30, 24 January 2022 (UTC)

Example, for {{cl|Rivers of Pennsylvania}}:

{{Parent cat |child_level=county |metacategory=Rivers of Pennsylvania by county‎‎ |type= |main=List of rivers of Pennsylvania |child_scan=21288815 |child_no_parent=21288629 |parent_no_child=21288821}}

At time of writing,

• The parent category held 1,276 pages, including 4 like Class A Wild Trout Waters that do not belong in a county-level category.
• The list in [https://petscan.wmflabs.org/?psid=21288815 All county-level articles for this parent] had 1,278 results
• The list in [https://petscan.wmflabs.org/?psid=21288629 county-level articles not in parent category] had 17 results. E.g. Bentley Run is not in {{cl|Rivers of Pennsylvania}}, but should be.
• The list in [https://petscan.wmflabs.org/?psid=21288821 Parent articles not in county-level category] had 8 results. E.g. Deer Creek (Maryland) is not in {{cl|Rivers of York County, Pennsylvania}}, but should be

The first list is mainly useful if the template is put at the top of a diffused category, where it could replace a {{tl|Category diffuse}} template. In theory, the query results should be exactly the same as the contents if the parent category were not diffused. For a diffused category such as {{cl|Rivers of England}} it would look like:

{{Parent cat |child_level=county |sample_child=Rivers of Bedfordshire‎‎ |type=empty |main=List of rivers of England |child_scan=21289948}}

For non-diffused categories, the "child not in parent" and "parent not in child" lists can be used by any editor who wants to do category maintenance. They may not know how write PetScan queries, but they can review and correct anomalies, an ongoing process.

Comments? Aymatth2 (talk) 13:28, 22 January 2022 (UTC)

:Seems like a good idea to me. Readers who are unsure if they are really looking at every article subcategorized under a parent category, could use the link to help find what they're looking for. For editors like me, who hadn't heard of the tool until recently, we can now easily use the tool to help find items missing from categories they should belong to (or remove ones that don't). DB1729 (talk) 15:04, 22 January 2022 (UTC)

:Good idea. We could even have a bot to populate the parent from the children (are sort codes a problem?), though probably not vice versa. Can we improve the wording to clarify that pages like Class A Wild Trout Waters belong in the parent category only? {{tq|Populated with the same pages as the child categories}} might be misinterpreted to imply {{!xt|...and no other pages}}. Certes (talk) 15:13, 22 January 2022 (UTC)

::I have tweaked the wording to "{{tq|It should hold all the pages in the child categories, and may hold other pages such as lists.}}" A bot to add the parent category to all child pages seems possible. I don't see a sort problem if the child pages use DEFAULTSORT... but a bot is a different discussion. Aymatth2 (talk) 15:58, 22 January 2022 (UTC)

:::Aymatth2. In my experience, many pages in the types of categories we've mentioned, do not use DEFAULTSORT because many are custom sorted differently for each category they're in. List of rivers of California is an interesting example. Despite it (redundantly) containing a DEFAULTSORT, every category it is in has a custom sortkey overriding the default.

::::I suppose there are problems like Thames River / River Thames. If a bot were developed, it would have to decide on an approach. Aymatth2 (talk) 17:18, 22 January 2022 (UTC)

:::Also just to clarify, I'm understanding it would replace the existing {{tl|All included}} or {{tl|Category diffuse}} template banners on the category pages. This change will be done on large categories only, correct? How large? Is there a threshold you had in mind? DB1729 (talk) 16:53, 22 January 2022 (UTC)

::::I would see {{tl|Parent cat}} replacing {{tl|All included}} or {{tl|Category diffuse}} to avoid clutter, but only where someone has taken the time to write the queries. They are mostly simple enough though. I did not see any particular lower or upper size limit. I suppose the larger the parent category the more likely it is to drift out of sync. With {{cl|Rivers of the United States}} (which is diffused) PetScan returns only the first 10,000 pages to the browser, although it will generate a complete file for download. Aymatth2 (talk) 17:18, 22 January 2022 (UTC)

:I'm not involved enough with categories to weigh in on the details here, but we should absolutely have an automated system (probably a bot) handling category diffusion. It doesn't seem very complicated from a technical standpoint.

:I'm glad to see that the discussion above is taking into account that category pages are (at least ostensibly) reader-facing. {{u|Sdkb}} ^talk 06:23, 24 January 2022 (UTC)

::{{anchor|abc123}}A version of PetScan could present results of the "all child" query in a format identical to Wikipedia. Perhaps a template like {{unite|metacategory}} could automatically generate the list of child pages when the parent category is displayed, or when the reader clicks on a Show/hide sub-pages button, which would solve the maintenance problem. This may be a small step in that direction. Aymatth2 (talk) 13:40, 24 January 2022 (UTC)

• Comment – Parts of articles are increasingly transcluded into other articles using {{tl|Excerpt}} (examples). However, that doesn't make template protection appropriate, as they are still articles rather than templates. Transcluded text typically appears in only a few articles, whereas template protection is typically applied to pages with thousands of transclusions, such as Template:Excerpt itself. Certes (talk) 01:29, 26 January 2022 (UTC)
• {{re|Vitaium}} Why do you think this is some sort of problem that needs an RFC? As of this posting there are exactly [https://en.wikipedia.org/wiki/Special:ProtectedPages?namespace=0&type=edit&level=templateeditor&size-mode=min&size= zero] articles template protected. — xaosflux ^Talk 02:00, 26 January 2022 (UTC)
• If an article were excerpted into enough articles that it would qualify for template protection if it were a template, then it should be template protected. But I fail to see how that situation could possibly occur. Let's close this speculative RfC and cross that bridge when we get to it. * Pppery * _{it has begun...} 02:15, 26 January 2022 (UTC)
• I see there are some template-protected move articles in :Category:Wikipedia template-protected pages other than templates and modules. Vitaium (talk) 02:28, 26 January 2022 (UTC)
• {{re|Vitaium}} there are like three of them, and that's probably just due to misclicks. I really don't see why this needs an RfC, so I'm going to remove the RfC tag as none of the steps that are usually taken prior to a policy-changing RfC have been followed here. Elli (talk | contribs) 02:36, 26 January 2022 (UTC)
• I went through and reset many of the levels from that page. — xaosflux ^Talk 11:38, 26 January 2022 (UTC)

:No. This information (assuming it is entered correctly & justifiably) has semantic significance in verification. Both online sources and their online archives may be subject to change. These values are the only indicators of the consulted versions in Wikipedia's Citation System 1/2, and they should be evident. 68.173.76.118 (talk) 12:50, 19 January 2022 (UTC)

::Wouldn’t it be possible to retain that semantic information but not display it, at least in certain circumstances? Example: certain site themes (e.g. mobile), or display via JS/CSS as a tooltip type display (similar to ‘efn’ popups?) Jim Grisham (talk) 12:47, 27 January 2022 (UTC)

Wikipedia:List of policies

Should this link/text be changed, and what to? – AssumeGoodWraith (talk | contribs) 10:57, 26 January 2022 (UTC)

Nice catch. I’ve been a casual editor for 15+ years now, and I can still get lost in the policies / docs / essays trying to find things… can’t even imagine coming in from scratch trying to get bearings.

: (One of these days, I might make good on my threat to write a proposal for a global draft / clipping namespace, not tied to any one user and with no deletion time limit… a safe incubator for anonymous collaboration, like in the old days - it could be filtered out of normal maintenance tooling so as to not affect backlog, and maybe avert some issues like this as well)

Okay, a few actual ideas / thoughts:

:* maybe it could point less to a single link / page, but more of a tree or a FAQ-type document / set of documents.

:** Something like a chat bot flow, perhaps, (but less reductive)?

:* It’s probably worth asking someone who’s never edited Wikipedia before what questions they might have in this sort of situation… perhaps a retired middle-school language teacher, then a middle schooler herself.

:* Perhaps we could survey new editors after their first 1, 5, 10 edits, and after deletions?

:** (but not via User:Talk page templates or notifications, please - that’s another learning curve all together!)

:* An infographic or graphic novel policy introduction?

:* (Finally, it shouldn’t need to be said, but experienced Wikipedia editors are probably poorly-suited for this kind of task.)

:* Compare Wikipedia:List of policies and Wikipedia:Policies and guidelines. Now do the same thing from a smartphone browser. Jim Grisham (talk) 14:04, 27 January 2022 (UTC)

:Maybe it should link to Wikipedia:Core content policies instead.

:Also, "speedy deletion" is confusing jargon. Perhaps explain that it is "deletion without waiting for a discussion"? WhatamIdoing (talk) 02:12, 28 January 2022 (UTC)

::Not too sure about "speedy deletion" being that confusing; it would be like calling "vandalism" confusing. It is, in fact, deletion which is speedy. – AssumeGoodWraith (talk | contribs) 09:39, 28 January 2022 (UTC)

:::Speedy deletion is not always speedy, and is not required to be speedy. WhatamIdoing (talk) 19:03, 28 January 2022 (UTC)

: {{re|Alex Mitchell of The Goodies}} ask at WP:MCQ where editors versed in copyright answer questions like this one. RudolfRed (talk) 00:24, 30 January 2022 (UTC)

What I hereby propose is take a look at it, see for yourself, maybe suggest some improvements (maybe colouring would like to improve, overall styling, etc.), and decide wether this infobox is worth the inclusion in English Wikipedia. If not, I can simply remove the content in it and archive the page. — Polda18 (talk) 18:01, 31 January 2022 (UTC)

:You should take into account that there is quite a general Template:Chembox. Ruslik_Zero 20:00, 31 January 2022 (UTC)

::I looked at it, and according to link for Czech Wikipedia counterpart, it is used mainly for chemical compounds. An alloy isn't actually a chemical compound, it is mixture of different chemical elements or compounds, typically metals. For example Bronze is an alloy of Copper and Tin for the most part. Copper and Tin do not actually form a chemical compound together, they're still forming standalone structures, it's just it's a mixture of microscopic metal crystals of both types giving it the properties of Bronze. — Polda18 (talk) 07:47, 1 February 2022 (UTC)

:I think that a vast majority of en-wiki infoboxes don't have colors for the labels & data, though a coloring for headings exist. I don't know if there's some kind of guideline on it or not. Otherwise, it looks really good & useful. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 20:36, 31 January 2022 (UTC)

::I can remove the colouring of labels and data (we do occasionally use them on Czech Wikipedia in some infoboxes, not all though), but I'd like to keep the colouring on sections heading and the infobox header itself. — Polda18 (talk) 07:37, 1 February 2022 (UTC)

In 1992, the North Korean government sent a document containing official guidelines for romanization of the (North) Korean language to the United Nations. 29 years have passed, and Wikipedia is still using the 1939 McCune–Reischauer romanization for romanizing all things about North Korean.

Even though both Koreas have had their own romanization system, why do we still use the old romanization for North Korean when we use the new revised romanization for South Korean? 펑홍한talk 04:50, 1 February 2022 (UTC)

:I can't answer your question, and have no opinion on the proposal, but I've left a note about this section at Wikipedia talk:WikiProject Korea where knowledgeable and interested Wikipedians are most likely to see it. Thryduulf (talk) 08:44, 1 February 2022 (UTC)

Darcourse (talk) 07:36, 30 January 2022 (UTC)

:There is: wikipedia:Dark mode (gadget). ― Qwerfjkltalk 08:45, 30 January 2022 (UTC)

:See also meta:Community Wishlist Survey 2022/Larger suggestions/Dark mode. Thryduulf (talk) 14:57, 30 January 2022 (UTC)

:I made a Solarized skin for Vector (the default Wikipedia skin), which is here and looks like this. Perhaps you would find it helpful. jp×g 07:35, 1 February 2022 (UTC)

:I find it absolutely astounding that anyone finds these "dark" or "solarized" modes to be "easy on the eyes". I find it nearly impossible to make out the text on those. --User:Khajidha (talk) (contributions) 03:26, 3 February 2022 (UTC)

:Dammit, am I in the wrong place? valereee (talk) 22:19, 24 January 2022 (UTC)

::Wrong place or not, I agree. The issue is that the edit request queue is set up so it's supposed to be used only as a way to action resolved matters, not to prompt discussion. Maybe we could add a stage to the process that instead summons people to the discussion, and then if there's agreement, flip a parameter to turn it into a formal request in the queue. {{u|Sdkb}} ^talk 05:33, 25 January 2022 (UTC)

::Well, as someone who works the ER queue frequently, it depends what they are asking for. The ER process serves as an important check on the protection system. ER's that are not controversial (which are many of them) don't normally need a showing of consensus first. So perhaps updating the directions to give better guidance would suffice? — xaosflux ^Talk 11:39, 25 January 2022 (UTC)

:::The requested edit could have been made by any editor with ten edits. Answering an edit request shouldn't be gatekeeping. Answering an edit request should be, "If this edit had been boldly made by someone with 10,000 edits, would I even question it? Done." valereee (talk) 11:58, 25 January 2022 (UTC)

::::{{Re|Valereee}} that's what I was saying - for uncontroversial edits (e.g. not an edit about content that is currently in dispute that led to the current protection) I assume the edit request is step one of WP:BRD and will make it, if in reviewing I think something is bad about it that I would have reverted on review, I decline and let the requester know that they are now at step three in BRD. But if the edit is about content in current dispute, that means that the material should already be in step 3 of BRD and a showing of consensus should accompany the immediate edit request. — xaosflux ^Talk 14:26, 25 January 2022 (UTC)

:::::Ah, sorry, I didn't read you correctly! :) valereee (talk) 14:35, 25 January 2022 (UTC)

::Edit request procedures are usually discussed at Wikipedia talk:Edit requests (see Archive 1 for prior discussions). If the discussion stays here then a notification should be posted there. PrimeHunter (talk) 11:57, 25 January 2022 (UTC)

:::Sorry about that. Whichever is better is fine by me. valereee (talk) 12:01, 25 January 2022 (UTC)

::::Specifically the discussion at Wikipedia talk:Edit requests/Archive 1#Requiring verbatim suggestions where there was discussion about elaborating on the templates used for answers. In the George Floyd instance, {{tq|Also a second "needs consensus" reply that specifically states The subject of this article is controversial and content may be in dispute. As such this edit request will require consensus before being made. Or something along those lines. There's quite a few I've closed as needs consensus because I know the article is controversial and I don't think an edit request patroller who likely has no meta-knowledge of the article should be on the hook for the contents of the edit.}} would apply. Expecting patrollers to know all the discussions on the lead of an incredibly contentious article is unrealistic. The talk page watchers were still able to respond back to the edit request, and it appears there was no consensus for inclusion. [https://en.wikipedia.org/w/index.php?title=Talk:Djibouti&diff=prev&oldid=1067844461&diffmode=source Here's] one I closed today, and added the mention that it would be a contentious change. ScottishFinnishRadish (talk) 15:22, 25 January 2022 (UTC)

:::::Wow, this is actually tangential to something that came up a while back, I think at this very article. If an article is currently being actively edited and has hundreds of watchers, should patrollers even be patrolling that talk page? SFR, you answered that edit request ten minutes after it was made. There are nearly 300 watchers, over 50 of whom visited recent edits. Why not let someone who is familiar with the page respond to that request? Pinging {{u|EEng}}, with whom I discussed this at least a year ago. valereee (talk) 15:28, 25 January 2022 (UTC)

::::::Would there have been a different outcome? Did my closing prevent any of the 300 talk page watchers from responding, or implementing the edit on their own? It didn't prevent them from discussing it, and establishing there was no consensus. It was poorly written, per {{u|Cullen328}}, {{tq|If I am correct, then I oppose this proposed change, since that three word phrase "his dying words" already appears in the lead section. Once is OK but twice comes off as hackneyed and clichéd.}}

::::::If a patroller reads an edit request, and believes that it's not an improvement, is that enough to close as "establish consensus?" Additionally, the template instructions explicitly state to close edit requests when there is discussion on-going, or the request is waiting on editor input. ScottishFinnishRadish (talk) 15:36, 25 January 2022 (UTC)

I've been completing COI edit requests on-and-off for about a year. I think the theory when edit request was created was that an editor would make a request, then other editors would discuss the edit request like an RFC. In reality, there's over 150 requests in the queue, some from almost a year ago, so now one editor is determining if the request is implemented. I don't think editors should decline any edit request as "get consensus first" because most edit requests are not going to generate discussion. Instead, editors evaluating requests should decide if they want to add it themselves or if they want to reject it for not fulfilling Wiki-policy and guidelines. If a request is closed with "get consensus first", then the closure should be reverted and another editor can evaluate the request. Z1720 (talk) 15:20, 25 January 2022 (UTC)

:Is there a reason ER patrollers aren't answering old requests instead of new ones? valereee (talk) 15:34, 25 January 2022 (UTC)

::For the semi and extended queues, the older ones likely need some specialized knowledge to verify, or a fair amount of research to verify. Talk:Rus%27 people#editsemiprotected and [Talk:Bioidentical hormone replacement therapy#editsemiprotected] are good examples of aging ones. Every week or two I try to go through all of the aging ones that will take some time, and do the research necessary to close them. Or, if they deal with a rewrite or prose change, I'll often close them as consensus needed at that time, because after a week, if no one has made the edit then there is an implicit consensus against the change. ScottishFinnishRadish (talk) 15:42, 25 January 2022 (UTC)

:::Well, we can't really know, because if someone gets to an edit and sees it's been handled by an experienced editor, how closely do they even check the requested edit? In this case it took a bit of reading and comparing, because the editor had included too much of the content. I skipped reading it myself when I first saw it. It wasn't until just now that I bothered to actually read and respond. ETA: Not sure I agree that after a week there's an implicit consensus against, but if that's settled policy, why not wait a week to respond to the ER? valereee (talk) 16:20, 25 January 2022 (UTC)

::::The one week thing is not settled consensus, it's just generally how I handle it. There's actually not much "settled consensus" as far as handling edit requests. I operate off the assumption that the templates used for closes, and the wording of the edit request templates themselves, enjoy consensus.

::::This general discussion has happened on a few occasions, but never seems to come to anything definite. Wikipedia talk:Edit requests/Archive 1#Requiring verbatim suggestions is really worth a read, as we're just rehashing that conversation with fewer people at this point. ScottishFinnishRadish (talk) 16:34, 25 January 2022 (UTC)

:::SFR, just to be clear, I am not intending a criticism of your work. I'm questioning our standard operating procedure on this. valereee (talk) 16:24, 25 January 2022 (UTC)

::::No criticism taken. I think that expanding the templates used for responses could go a long way to help. If the George Floyd request had been closed as {{tq|The subject of this article is controversial and content may be in dispute. As such this edit request will require consensus before being made.}} with a yellow icon, instead of red, I don't think we'd even be having this conversation. ScottishFinnishRadish (talk) 16:37, 25 January 2022 (UTC)

:{{Re|Z1720}} - think this varies by queue, the process for COI may need to vary from the FPROT queue (I don't work COI queue - but am all over FPROT queue). — xaosflux ^Talk 16:32, 25 January 2022 (UTC)

:I agree with this general concern but don't have any immediate thoughts on how to fix it. But I support doing something {{smiley}} KevinL (aka L235 · t · c) 16:43, 25 January 2022 (UTC)

::I think an expanded amount of templated responses would be the easiest to address some of the concerns. I'd like to know how often there are closes that anyone objects to, as well. I'd hate to see us come up with wait times and such around edit requests for what amounts to less than 5% of closures. ScottishFinnishRadish (talk) 16:51, 25 January 2022 (UTC)

:The change I'd like to see in the Edit Request process is to stop "declining" edit requests that need more discussion and start "rescheduling" them. A desire for an empty queue can result in rejecting viable edit requests. Perhaps whatever code puts AFD pages into the correct date category after 7 days' wait could be adapted to this purpose. WhatamIdoing (talk) 23:44, 25 January 2022 (UTC)

::As it stands, the edit request template instructs editors to close the request while waiting for editor input. From the last discussion I took part in dealing with edit requests there seemed to be a reasonable consensus that edit requests are specifically for edits that are ready to be made, rather than for discussion. Regular talk page discussion doesn't need an edit request template.

::Again, I think a lot of the concerns could be mitigated with better wording in the response templates, and some additional templates to cover more cases. ScottishFinnishRadish (talk) 00:05, 26 January 2022 (UTC)

:::I do not think that's sufficient. We need to actively ask people not to rush to answer edit requests at pages they're unfamiliar with. There is no reason any edit request needs to be answered in five minutes by someone who is not familiar with that page. After a week, sure. But it's actually unhelpful for people not familiar with a page that has 500 watchers, 300 of whom have visited recent edits, to answer edit requests at that page with a canned edit request. valereee (talk) 21:03, 3 February 2022 (UTC)

Should we prevent new/unregistered users from editing featured article and featured lists? Because I see in the last month, many featured articles were vandalised by newcomers and IPs. Vitaium (talk) 23:54, 3 February 2022 (UTC)

• Oppose If an individual featured article is being vandalized, you can make a request at requests for page patrol. --I dream of horses (Contribs) (Talk) 00:42, 4 February 2022 (UTC)
• Oppose vandalism is usually swiftly reverted on such articles, as they tend to have a high number of pagewatchers, and if if not, WP:RC has really good vandalism filters now, so they're much more detectable. This is a non-issue. Curbon7 (talk) 02:07, 4 February 2022 (UTC)
• Oppose: Wikipedia prides itself on being editable by anyone. How would it look if our most important and highest quality articles didn't even stick to the core of Wikipedia? bop34 • talk • contribs 03:23, 4 February 2022 (UTC)
• Oppose and suggest snow close; this is a non-starter contrary to our philosophy. {{u|Sdkb}} ^talk 03:45, 4 February 2022 (UTC)
• Oppose. FAs on the main page are supposed to be editable, despite the number of test edits they routinely attract. Guettarda (talk) 04:15, 4 February 2022 (UTC)
• Oppose for all the reasons given above. --Bduke (talk) 04:22, 4 February 2022 (UTC)

{{archive bottom}}

• Good idea. An argument against it might be the front page is not for highlighting problems with Wikipedia, or to pull readers into helping. But why not? The front page might be used as a recruitment tool to encourage fence sitters to become editing heroes. Granted such articles will need to be watched since new users will do strange things, but the project could have editors willing to adopt articles, like lifeguards. -- GreenC 00:39, 3 February 2022 (UTC)
• :Some of these are just ridiculous, like look at this:
• :* {{icon|C}} War of 1812
• :* {{icon|start}} Genus
• :* {{icon|C}} The arts
• :* {{icon|Stub}} Tax return
• :* {{icon|c}} Voting
• :* {{icon|start}} Home
• :* {{icon|Start}} Man
• :* {{icon|C}} Soil
• :* {{icon|Stub}} Flesh
• :* {{icon|stub}} Credit limit
• :The 2nd, 4th and last one especially, I'm surprised Genus isn't already a GA or FA. These are incredibly important to daily life and yet they are complete crap. Lallint⟫⟫⟫Talk 01:24, 3 February 2022 (UTC)
• :: This was tried and rejected before. See Wikipedia talk:Articles_for improvement/Archive 5#Failure * Pppery * _{it has begun...} 02:32, 3 February 2022 (UTC)
• :::Sure it was, 8 years ago. Can't we try again? It doesn't even have to be the main page, why not Wikipedia:Cleanup, or Wikipedia:To-do list? Why do you always shoot me down whenever I say something? Lallint⟫⟫⟫Talk 17:09, 3 February 2022 (UTC)

{{collapse top|Off-topic. * Pppery * _{it has begun...} 19:23, 3 February 2022 (UTC)}}

:::::Plus, GreenC has been on Wikipedia for 18 years, while you've only been for 5. Lallint⟫⟫⟫Talk 17:16, 3 February 2022 (UTC)

:::::: Wikipedia is not a Gerontocracy, so the amount of time I've been editing is irrelevant. And it's not the case that {{tq|[I] always shoot [you] down whenever [you] say something}}, instead that you keep doing things that come to my attention. Nor am I really shooting you down here, as my comment was purely factual and did not imply anything about my position on this proposal. * Pppery * _{it has begun...} 17:29, 3 February 2022 (UTC)

:::::::Yeah i'm sorry just it seems like every time i say something its always you, tamzin, or Rosquill that replies Lallint⟫⟫⟫Talk 17:37, 3 February 2022 (UTC)

::::::You know, Lallint, proposing a change to the Main Page and immediately personalizing the dispute with the first person to disagree is a pretty generous interpretation of what Rosguill intended by {{tq|Block converted to partial block to allow for participation in RfD}}. Or, maybe it isn't. I wouldn't want to speak for them. But either way you should not be editing disruptively while still actively blocked for disruptive editing. -- Tamzin^{[cetacean needed]} (she/they) 17:33, 3 February 2022 (UTC)

:::::::Yeah i'll stop now Lallint⟫⟫⟫Talk 17:36, 3 February 2022 (UTC)

::::::I don't think years editing matters to much. I do agree that it was 8 years ago and things can change in 8 years, so it would be logical to at least try again (possibly do something a bit different). It appears it failed 8 years ago because the articles just weren't being edited. From what I"m reading it's because there wasn't anything encouraging the articles to be edited. Maybe awarding barnstars to users who help improve the articles would help (similar to the back log editing drives done by some WikiProjects)? The editing drives some WikiProjects do seem to be successful so maybe we could try and figure out what makes them successful and implement that into this. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 17:39, 3 February 2022 (UTC)

:::::::Also, the reason some people always seem to reply when you say something might just be coincidence, and also possibly the fact that you're currently partially blocked and are wanting to make sure you aren't doing anything to violate your block. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 17:40, 3 February 2022 (UTC)

::::::::That also could be true Lallint⟫⟫⟫Talk 17:44, 3 February 2022 (UTC)

:::::::Don't mean to support people who agree with me and not support people who don't like some freedom of speech advocating little b-boy, but this guy logics. Lallint⟫⟫⟫Talk 17:43, 3 February 2022 (UTC)

::::::::I'm just a logical kind of person. It's kinda how I work. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 17:45, 3 February 2022 (UTC)

:::::anyway so as i was saying Lallint⟫⟫⟫Talk 17:51, 3 February 2022 (UTC)

::::::I agree with 420 Blaze Wolf above, perhaps we could use a positive reward system for doing good on one of those pages instead of rollbacking every edit they made after they accidentally made a typo then indefinitely banning them and accusing everyone with more than 2 letters similar to their name as a sockpuppet Lallint⟫⟫⟫Talk 17:53, 3 February 2022 (UTC)

:::::::Maybe with a beginners barnstar or something? Lallint⟫⟫⟫Talk 17:53, 3 February 2022 (UTC)

::::::::now that I think about somebody's probably actively refreshing this thread with a bag of popcorn waiting for something to happen again Lallint⟫⟫⟫Talk 17:55, 3 February 2022 (UTC)

:::::::Do we know whether such barnstars, or similar, would incentivise more editing? Dege31 (talk) 18:17, 3 February 2022 (UTC)

:::::::::Well, barnstars appear to be rewards for the editing drives some WikiProjects do and those appear to be successful. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:19, 3 February 2022 (UTC)

::::::::::Sure, but I wouldn't say new editors, the apparent target group, are WikiProject members? There is, also, already an Articles for Improvement barnstar. Dege31 (talk) 18:31, 3 February 2022 (UTC)

:::::::::::That would be perfect then Lallint⟫⟫⟫Talk 18:33, 3 February 2022 (UTC)

:::::::::::That would be a barnstar we could give users. I see your point in giving new users a reason to edit. It's kinda hard to give new users a reason to edit because, well, they're new users. And as I"m thinking about this a bit more, if it were on the main page it might just attract vandals to those articles instead of new users wanting to improve them. Maybe it could be integrated into the new user homepage? I'm trying to think of some reward that would appeal to new users. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:35, 3 February 2022 (UTC)

::::::::::::I think in order to come up with a reward for new users, we would have to figure out what appeals to constructive new users the most and causes them to stay. Obviously we can't just make it "If you help edit these pages you won't get blocked!" because if it's a vandal then they will get blocked and that will be shown to be a false statement. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:39, 3 February 2022 (UTC)

:::::::Whenever someone makes a mistake (such as a typo) I am usually just able to revert with the edit summary of it being in good faith and with an explanation as to why I reverted (and we definitely don't accuse everyone with more than 2 letters similar to their name as a sock, or at least, we don't block them, one of my friends here on Wikipedia had an SPI made against them because someone managed to get a character that looked exactly like a letter in the english alphabet and replaced that letter with the character, making it look like it was the same username). Barnstars are a good idea, although a human should give them out because if it were a bot, then it would probably function like this: Bot sees user has made an edit to article on list, bot awards user barnstar. The bot can't check to see if the edit is constructive or not (or at least, not reliably. we could use something similar to ClueBot NG, however there are false negatives and awarding a user for bad behavior isn't all that constructive) so if a human were to award the barnstars it could be a good system. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 17:59, 3 February 2022 (UTC)

::::::::Again, this guy logics. The typo part was a joke though lol Lallint⟫⟫⟫Talk 18:07, 3 February 2022 (UTC)

{{collapse bottom}}

• When I first read this idea, my initial reaction was that I rather liked it. However, I can see the following problem. Wikipedia: Main Page is probably one of the most viewed pages in the encyclopaedia (indeed, if you just Google "Wikipedia", you will instantly be taken to the Main Page) and if the first thing that one reads on the Main Page is that there are articles needing improvement, it may put readers off the Wikipedia project. I guess that what I am saying is that there could be problems of putting "Articles for improvement" on a page with too much traffic. That said, tonight I looked at the category called "Articles needing improvement from the Bioguide" and had a look at two articles in this category - that on James Budd and that on Henry P. Haun. It was not clear from these articles in themselves that they needed improvement, that was just mentioned on their talk pages. I agree that we should place notices that articles need improvement in more prominent positions, so how about having a tag at the top of the article saying it needs improvement, just below its title? The article on James Budd is headed by a tag saying that its lead may not summarize its key points adequately. If it were also heading by a tag saying that it needs improvement, that may make more Wikipedians aware of how it needs attention.

YTKJ (talk) 21:56, 4 February 2022 (UTC)

:The main page has an "Other areas of Wikipedia" section with links to editor-facing areas such as the Teahouse. That might be a good place to link to a list of articles for improvement. Certes (talk) 23:43, 4 February 2022 (UTC)

Many fields in mathematics such as number theory and geometry are not likely to change over time even as the content and presentation and clarity and layout of the article is improved.

For example, ellipses will mostly be the same geometrically and so some parts of the article will be less likely to change.

I think its good that articles on developing events include disclaimers on the current status of the article but think it would be helpful to include an opposite notice that for example Maxwell's Equations is invariant.

ScientistBuilder (talk) 02:23, 5 February 2022 (UTC)

:This is interesting, but the way I understand it, you seem to mean that the source information upon which an article is based is not likely to change, not the article itself. I don't know if such a metric is entirely pertinent or relevant to Wikipedia. Current events have very fluid verifiability characteristics, and the warning is relevant. If such a metric is applicable and desirable it should apply to the article as a whole. If applied to parts of articles would probably be too cumbersome for editors and confusing for readers. And first, is it so? Something like "A's equation" obviously is set for posterity, and there is no need to proclaim the fact. One may add to it, but then it is no longer A's equation, it is "B's enhancement of A's equation". However the viability/applicability of any equation may change. Perhaps after the next hypothesis and its related experimentation. 65.88.88.71 (talk) 16:20, 5 February 2022 (UTC)

:Wikipedia is a work in progress and most articles on number theory and geometry are incomplete, contain errors or misleading implications, are suboptimally comprehensible to laypeople, and could be re-organised or give a different balance of subtopic coverage to more properly represent the research area. A page is likely to change if an editor becomes interested in it, and unlikely to change if editors are not. There are trends that can create interest: for instance, news coverage, sudden social media interest or a major update to the topic. However, other trends are less predictable: if I bring 15 Black Mirror episodes to good article status then it becomes a lot more likely that the others will soon follow suit, but if I create a few Rick and Morty episode articles then I might stop with five still missing. I can think of one particular mathematician whose retirement from Wikipedia would dramatically decrease the likelihood of upcoming improvements to any particular mathematics article. — Bilorv (talk) 00:08, 6 February 2022 (UTC)

: {{re|ScientistBuilder}} A few questions:

:* You said, {{talk quote|on how likely a page is to change}} did you mean:

:** How likely it ought to change, because we're not expecting a new Mersenne prime anytime soon, and there's not much else important to say about it; or,

:** How likely the article about it changes based on analysis of the revision history (five changes in January, five in December, seven in November)

:* What would you do with this metric, if it were in place now?

: Thanks, Mathglot (talk) 00:03, 8 February 2022 (UTC)

::When I use Wikipedia to learn math and science topics I would like to know which subjects will be less likely to change in 10 years. For example, I want to work through all the articles on electromagnetism and am interested in which articles are not culture specific and more broadly applicable. ScientistBuilder (talk) 02:12, 8 February 2022 (UTC)

:::That seems like something that would be hard to determine. I don't think anyone here on Wikipedia can see into the future and know what topics aren't going to change for a while. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 20:53, 8 February 2022 (UTC)