Wikipedia:Village pump (all)

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

(to see recent changes on Village pump subpages)

Village pump sections

Policy

post, watch, search
Discuss existing and proposed policies

Technical

post, watch, search
Discuss technical issues about Wikipedia

Proposals

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

Idea lab

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

WMF

post, watch, search
Discuss issues involving the Wikimedia Foundation

Miscellaneous

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

View all village pump sections at once

Other help and discussion locations

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

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

Policy

Petition to amend ARBPOL to add options for U4C

Should ARBPOL be amended to add appealability and submission of questions to U4C? _signed, SpringProof ^talk 04:31, 23 March 2024 (UTC)

I am hereby petitioning the following two changes to the Arbitration Policy:

A: The following sentence shall be added to WP:ARBPOL#Appeal of decisions:

Questions strictly concerning the Universal Code of Conduct may be severed and appealed to the Universal Code of Conduct Coordinating Committee, which shall decide to hear it or not.

B: The following sentences shall be added to WP:ARBPOL#Policy and precedent:

Prior to publishing a decision, the Committee may refer questions of policy solely regarding the Universal Code of Conduct to the Universal Code of Conduct Coordinating Committee, which shall be required to answer, unanimously or by majority, in a reasonable timeframe.

I am petitioning these amendments in preparation for the upcoming U4C elections, which will establish the U4C. Part of their charter includes the option for projects to submit appeals concerning the UCoC, so I thought that might be helpful to add to ARBPOL.

These amendments are severable and may be adopted by themselves, so I have separated them into A and B.

_signed, SpringProof ^talk 04:31, 23 March 2024 (UTC)

_{Disclosure: I am currently a candidate for the U4C.}

Signatories for A

1. Petitioner, _signed, SpringProof ^talk 04:31, 23 March 2024 (UTC)

Signatories for B

1. Petitioner, _signed, SpringProof ^talk 04:31, 23 March 2024 (UTC)
2. Agree Slacker13 (talk) 13:04, 27 March 2024 (UTC)

General comments (ARBPOL U4C petition)

These proposals misunderstand what the U4C was created to do, and I hope they'll be withdrawn. The charter is very clear that the U4C doesn't generally have jurisdiction "when a NDA-signed, high-level decision-making body exists", and on en-wiki that's ArbCom. ArbCom should be interpreting the UCOC on its own (if necessary, which it rarely is), and the UCOC couldn't even hear appeals from those decisions if it wanted to except in extraordinary cases of "systemic failure". Anything else would be at odds with both the charter and this project's independence. Extraordinary Writ (talk) 05:52, 23 March 2024 (UTC)

@Extraordinary Writ: I understand that the U4C doesn't already constitutionally have jurisdiction over appeals. If there already was, this petitioned amendment would be moot (see above). I think the UCoC involves more disputes than it's chalked up to be. For example, the only open case right now is centered around a UCoC issue (What constitutes paid editing?). Love your name, by the way. :) _signed, SpringProof ^talk 07:38, 23 March 2024 (UTC)

Expanding the U4C's jurisdiction is even more problematic, I think. Even if it could be done without amending the U4C charter (which I doubt), giving the U4C additional authority over ArbCom would be a serious blow to this project's self-governance, and I think it's very unlikely that you'll find 100 editors who'll support doing so. (Paid editing is a Terms of Use issue, not a UCOC issue, by the way.) Extraordinary Writ (talk) 21:03, 23 March 2024 (UTC)

@Extraordinary Writ: You're right, I apologize. Nevertheless, the case also includes an issue of alleged doxing, which is further part of the UCoC. _signed, SpringProof ^talk 05:08, 24 March 2024 (UTC)

• This proposal misses the entire point of the UCOC, which is to provide a method of dispute resolution on projects that don't already have methods; in particular, smaller and newer projects. I fully expect to see medium- to large-sized projects without an arbitration committee creating one so that they don't have to deal with the U4C. Keep in mind that the UCoC itself is largely adapted from English Wikipedia policies and their corollaries on other large projects. This seems like massive overreach. Risker (talk) 23:11, 24 March 2024 (UTC)

  That's what I would like the UCoC to be. However, UCoC is more ambitious about its scope. Its main page claims that it may not be circumvented, eroded, or ignored by ... local policies of any Wikimedia project. It dictates that all who participate in Wikimedia projects and spaces will: [list of demands] and that it applies equally to all Wikimedians without any exceptions. Of course, any attempt to enact such arrogance may see significant numbers of us advise the WMF where to stick its encyclopedia, but those who wrote that text don't seem to be here to play second fiddle to ArbCom. Certes (talk) 23:47, 24 March 2024 (UTC)

Oppose this per others above: this is just more WMF stuff encroaching on enWP's jurisdiction. 🌺 Cremastra (talk) 22:48, 26 March 2024 (UTC)

I also oppose. UCoC may claim precedence over ArbCom, the laws of physics and all major deities, but U4C doesn't and shouldn't. Let us continue to answer to locally elected representatives rather than our new global overlords who have parachuted in uninvited. Certes (talk) 23:09, 26 March 2024 (UTC)

• This isn't useful. For (A) if something is within the scope of UCOC review it doesn't require a local policy to make it as such. For (B) local polices can't make global bodies act. — xaosflux ^Talk 14:21, 27 March 2024 (UTC)

  It seems to be suggesting that ArbCom defer to the U4C, which I suppose ArbCom could do if it wished, but it certainly isn't obliged to and I'd rather it didn't. Certes (talk) 14:30, 27 March 2024 (UTC)

  If I've understood correctly, then (A) would allow users to appeal some arbcom decisions to the U4C, whether to do so would not be a decision arbcom could make. If so then this is pointless as the UCOC and U4C determine whether the latter can hear appeals of ArbCom decisions, not local policy. It also attempts to mandate the U4C making a decision on whether to hear a specific appeal or not - legalistically it can't do that, but in practice the only other option is to ignore the request which I would sincerely hope they wouldn't do.

  (B) is really in two parts. The first part allows (but doesn't require) ArbCom to refer UCOC policy questions to the U4C if they want to. I don't have a problem with this in principle, but whether answering such questions is a function of the U4C is a matter for the UCOC and U4C to decide not en.wp policy, and I also don't think it is something that needs a policy amendment to allow given that ARBPOL doesn't restrict who the committee can consult. The second part attempts to require the U4C to answer arbcom's questions and to answer them in a "reasonable timeframe". English Wikipedia policy has no more ability to do this than it has to require the US Congress to answer arbcom's questions.

  Together that makes this whole thing a mixture of pointless and moot. Thryduulf (talk) 14:54, 27 March 2024 (UTC)

• It's credibly claimed above that in practice, our ArbCom disapplies the UCOC to en.wiki. If so, then we should make a clear declaration of this in a prominent place.—S Marshall T/C 16:00, 27 March 2024 (UTC)

  @S Marshall what doesn't apply to English Wikipedia is the Universal Code of Conduct Coordinating Committee (U4C). The community has never been given a chance to ratify the Universal Code of Conduct (UCoC) itself. This has always struck me as a mistake, though the WMF Board does seem to have the power to make it policy anyway. Either way, the UCoC is a set of minimums and it is my firm judgement that enwiki policies often go far above those minimums and in no place are our policies less than the UCoC. Barkeep49 (talk) 21:57, 27 March 2024 (UTC)

  On the basis of your last sentence, I modify my previous position to: "On en.wiki, our governance and policies make the UCOC nugatory." If that's right, it's rather important, and I do think we should say so.—S Marshall T/C 22:09, 27 March 2024 (UTC)

• This isn't useful. ArbCom is ArbCom. U4C has no supervisory jurisdiction over ArbCom. Stifle (talk) 10:08, 2 April 2024 (UTC)

Preference of using OpenStreetMaps

Dear @User:Shannon1 before reverting my edits please discuss here. These maps are preferred because they are zoomable and rich of metadata. If you disagree please discuss. Hooman Mallahzadeh (talk) 15:19, 29 March 2024 (UTC)

@Hooman Mallahzadeh: Hi, can you link me to the Wikipedia documentation or discussion that indicates the OSM maps are "preferred"? The watershed maps are valuable to river articles because they show key information like drainage basin extent, tributaries and topography. I wouldn't be opposed to including both in the infobox, but there appears to be no way currently to display two maps. Shannon [ Talk ] 15:22, 29 March 2024 (UTC)

I should note that in French Wikipedia it is used correctly for Seine, In Japanese used for Arakawa River (Kantō). This is correct use of maps in the year 2024. Hooman Mallahzadeh (talk) 15:24, 29 March 2024 (UTC)

@Shannon1 Policies doesn't say anything. But I can discuss and defend about their preference. Just compare these images:

Traditional map	New Maps

Which of these maps is more clear? The new or the old? Hooman Mallahzadeh (talk) 15:38, 29 March 2024 (UTC)

I really think that we should create a policy for the preference of OpenStreetMaps over traditional ones. Hooman Mallahzadeh (talk) 15:40, 29 March 2024 (UTC)

I think they serve different purposes, and it would be ideal to have both in the infobox - but there appears to be no way to do this at the moment. The OSM map would be a fantastic replacement for pushpin locator maps like on Walla Walla River. However, it deletes a ton of important information that is displayed in the older watershed map. Can we hold off on any kind of mass replacement until this can be resolved? Shannon [ Talk ] 15:43, 29 March 2024 (UTC)

1. OpenStreetMaps presents the least but most important metadata at each level of zoom.
2. The ability of zooming is only provided by OpenStreetMaps
3. If any change occurs for the river, for example the path changes, this is rapidly applied for OpenStreetMaps
4. language of metadata changes automatically for each Wikipedia
5. and many others. Just let me some time to write them.
6. font-size of text of metadata is automatically adjusted

Hooman Mallahzadeh (talk) 15:44, 29 March 2024 (UTC)

You should have tried to get agreement for that policy before attempting to impose your preference across a large number of river articles. Kanguole 16:09, 29 March 2024 (UTC)

@Kanguole Ok, we are here for agreement about that. Hooman Mallahzadeh (talk) 16:14, 29 March 2024 (UTC)

@Hooman Mallahzadeh: Please revert the map changes you have made, since they have been challenged and there is so far no agreement for them. Kanguole 21:04, 29 March 2024 (UTC)

If it's an article about a river, the traditional map is more informative. 🌺 Cremastra (talk) 21:01, 29 March 2024 (UTC)

@Shannon1 See, we can have both maps by using "Hidden version of maps in infoboxes"

{{hidden begin|title=OpenStreetMap|ta1=center}}{{Infobox mapframe |wikidata=yes |zoom=6 |frame-height=300 | stroke-width=2 |coord={{WikidataCoord|display=i}}|point = none|stroke-color=#0000FF |id=Q1471 }}{{hidden end}}

that is rendered as:

OpenStreetMap

which yields: (here we hide topological and show OpenStreetMap, but the reverse can be applied)

Seine
The Seine in Paris
Topographical map
Native name	la Seine (French)
Location
Country	France
Physical characteristics
Source
• location	Source-Seine
Mouth	English Channel (French: la Manche)
• location	Le Havre/Honfleur
• coordinates	49°26′02″N 0°12′24″E
• elevation	0 m (0 ft)
Length	777 km (483 mi)
Basin size	79,000 km2 (31,000 sq mi)
Discharge
• location	Le Havre
• average	560 m3/s (20,000 cu ft/s)
Basin features
River system	Seine basin
Tributaries
• left	Yonne, Loing, Eure, Risle
• right	Ource, Aube, Marne, Oise, Epte

We can have both maps, one is hidden by default, and the other is shown by default. But I really think that we should show OpenStreetMap and hide others. But in many rare cases that the revert is true, we show topographic map and hide OpenStreetMap. Hooman Mallahzadeh (talk) 15:54, 29 March 2024 (UTC)

We want an edit for Template:Infobox river and use parameters hidddenMap1 and probably hiddenMap2 for implementing this idea. Hooman Mallahzadeh (talk) 16:07, 29 March 2024 (UTC)

I opened a thread on Template talk:Infobox river regarding this. Also pinging @Remsense: who has been separately reverting my edits. Shannon [ Talk ] 16:09, 29 March 2024 (UTC)

I'm merely concerned specifically with the articles I've reverted, I have no opinion on the issue at-large. Remsense诉 16:16, 29 March 2024 (UTC)

@Remsense: I've been on Wikipedia 15+ years and river articles have always used these watershed maps. I'm aware that policies can change but there has been no such discussion at WP:RIVERS or elsewhere. In my view, the watershed map on Yangtze for example is far more informative than the OSM map, which is essentially a better locator map. The Yangtze basin is immense, with dozens of major tributaries, and in this case the OSM map also leaves out the Jinsha that continues for more than 2000 km upstream of Sichuan. (Not because I made the watershed map, necessarily – I just noticed the reversions because of my watchlist.) Shannon [ Talk ] 16:25, 29 March 2024 (UTC)

I'll revert on these pages for now, thank you for the elaboration. Remsense诉 16:35, 29 March 2024 (UTC)

If you really want consistent guidelines (after working out technical issues), put them on WikiProject Geography. A global policy would just be MOS:BLOAT. SamuelRiv (talk) 16:39, 29 March 2024 (UTC)

@SamuelRiv I made a discussion for that here. Thanks, Hooman Mallahzadeh (talk) 16:51, 29 March 2024 (UTC)

@Shannon1:For my final word, I really cann't read the metadata of this map, because text on it is too small:

unless opening it. So its metadata is useless at the first glance, unlike OpenStreetMap.

• Not sure where to put this comment, because this section is broken with huge amounts of whitespace making it almost unreadable. I just want to mention that i have reverted three or four river map changes by Hooman Mallahzadeh, the summary of the diff indicated that the rather ugly and not as useful Open Street Map was preferable; my summary is "By whom is it "preferred"? Don't think there's a policy on this; until any discussion is finished the better map shouldn't be removed." I see now that a discussion (not a vote at all) has been started here. I'd like to suggest that Hooman Mallahsadeh reverts all the changes they have made of this type until this discussion comes to some conclusion. Happy days, ~ Lindsay^Hello 20:26, 29 March 2024 (UTC)

Proposal 1: Render both; prefer OSM; hide others

Ok, please vote for this scenario.

"Both topographic and OpenStreetMaps will be rendered in Infobox, but it is preferred to show OpenStreetMap and hide others by using "Template:Hidden begin" and "Hidden end".

For "vote", I asssume you mean "discuss"? 🌺 Cremastra (talk) 21:04, 29 March 2024 (UTC)

Agree with proposal 1 re OSM

1. Agree Hooman Mallahzadeh (talk) 16:23, 29 March 2024 (UTC)

Disagree with proposal 1 re OSM

1.  Disagree The OS map (in the way it is implemented here; don't know if layers in OS can be switched off for this kind of view) shows too much information that is not relevant for river articles (like roads, for example), and not enough information about what these articles are about - rivers. Plus, the watershed maps are just prettier IMO. Zoeperkoe (talk) 18:08, 29 March 2024 (UTC)
2.  Disagree Some maps are better for some things. For example in river or lake articles, the watershed maps are more helpful, but for city maps OSM is probably better. 🌺 Cremastra (talk) 21:03, 29 March 2024 (UTC)

   @Cremastra@Zoeperkoe Why OSM is preferred? Because it is more abstract, and for solving our problems, it is preferred to move from reality into concept. Please read the article Concept. In fact, we want to solve our problems by concepts that only includes main data and lacks redundant data. So certainly OSM maps are appropriately more abstract and finer concept.

   For example, in this image:

   

   The abstracted version of tree is preferred for many applications (question answering) like addressing and others over Cypress tree.

   So. in river Infoboxes, I even propose to use wider lines to remove elaboration of rivers and make a simpler map for its Infobox at the first glance. Hooman Mallahzadeh (talk) 05:22, 30 March 2024 (UTC)

   As someone who also likes the OSM maps in general cases: "read the Concept article" is not a very compelling argument.

   My argument would be that they are more flexible and more immediately maintainable by editors. We can theoretically better control the level of abstraction or detail we need for a given article. I don't mind cracking open the text editor to edit an SVG, but not everyone wants to do that. I've seen enough infobox crimes to know that dogmatism either for maximum abstraction or concretion is counterproductive. Remsense诉 05:28, 30 March 2024 (UTC)

3.  Disagree For users with Javascript disabled (either by choice or by force), OSM maps are useless. No movement, no zoom, and nothing drawn on top of the base tiles. Also no ability to swap between tiles. Please ensure that whatever choice you make fails safely without scripts. 216.80.78.194 (talk) 11:10, 31 March 2024 (UTC)

   When I disable JS in my browser, the maps above still render with the lines indicating the rivers' courses. They do miss the ability to click to see a larger interactive version, but they're not useless. Anomie⚔ 13:22, 31 March 2024 (UTC)

4. OSM map is much less informative for the topic of rivers. CMD (talk) 06:17, 7 April 2024 (UTC)

   @Chipmunkdavis Being less informative is an advantage. The purpose of an Infobox is providing some general information, not detailed information. In an Infobox, only the most important and most readable data should be shown. Other maps can contain details, not the Infobox map. Hooman Mallahzadeh (talk) 06:52, 7 April 2024 (UTC)

   While I think this position is preferable to the other extreme which is far more common in infobox disputes, I think it's a perspective being wielded too dogmatically here. While it's fun when I say things like "being less informative is an advantage" and there's a real sense where that's true, it also misses the point here that no one size fits all when it comes to presenting key information, and a watershed is important information one would like to know at a glance. It's being mischaracterized in my opinion as a detail, what others are arguing is that it is not so. Remsense诉 07:05, 7 April 2024 (UTC)

   @Chipmunkdavis@Remsense Yes. But the most abstract data version is in the first zoom, if you want more abstract version do "zoom out" and if you need more detailed version, do "zoom in",

   But at the first glance, if is not enough informative, then for example for "watershed", we can use "point locators" on the map. Or for areas we can use area locators. They are added very fast by using new items of Template:Maplink. The same as Shinano_River. Hooman Mallahzadeh (talk) 07:20, 7 April 2024 (UTC)

   I agree it's a potential solution. But we should judge the solution on a case by case basis, rather than making a swap across an entire class of articles now. Remsense诉 07:22, 7 April 2024 (UTC)

   An in this particular case, the watershed and to an extent tributaries is important and immediately visually readable. CMD (talk) 12:29, 7 April 2024 (UTC)

5. Disagree. I have just been reading a river article i happened to come across (River Wyre) which has made me feel so strongly that i have had to return here and protest these OSM maps, though i had planned not to. The map in that particular article, as well as other river articles i have looked at recently, is not sufficient: It gives no idea of the area drained by the river, there are unexplained dotted and faint grey lines all over it which apparently give no information, and (in this particular case) it is huge compared to the other images in the article. I am rather worried by Hooman Mallahzadeh's statement above, [b]eing less informative is an advantage, which i strongly disagree with; we should be giving our readers an abundance of information and allowing them, if they so desire, to choose what they wish to take away. Happy days, ~ Lindsay^Hello 07:42, 7 April 2024 (UTC)

   In the context of an infobox it is understandable what they mean. However, the point here is I think it's perfectly reasonable to display a river's watershed in the infobox. Remsense诉 07:54, 7 April 2024 (UTC)

   @Remsense See French Wikipedia at this page https://fr.wikipedia.org/wiki/Seine . It displays both start and end with pointer and then in the continuum of Infobox, it discusses start and end of the river. I think this convention of French Wikipedia describes rivers (and also Seine river) fantastic. Hooman Mallahzadeh (talk) 09:02, 7 April 2024 (UTC)

   Remsense, i agree that the infobox should contain the watershed ~ the thing is, if it doesn't, the information (presumably in the form of a map) would need to be elsewhere in the article. The infobox is indeed the logical place to look. Happy days, ~ Lindsay^Hello 13:19, 7 April 2024 (UTC)

   @LindsayH Please do not be surprised about my statement! Just see the Occam's razor article, ending line of the first paragraph:

   "The simplest explanation is usually the best one."

   And this sentence:

   In philosophy, Occam's razor (also spelled Ockham's razor or Ocham's razor; Latin: novacula Occami) is the problem-solving principle that recommends searching for explanations constructed with the smallest possible set of elements.

   And this sentence:

   Entities must not be multiplied beyond necessity.

   I don't know what is your major, but this principle is applied to all theories in science. Hooman Mallahzadeh (talk) 08:07, 7 April 2024 (UTC)

   Hooman Mallahzadeh, i think you're possibly misunderstanding Ockham's razor: It says nothing about withholding information to make things simpler, what it means is that given a certain number of observations or facts the simplest explanation which covers them all is to be preferred. So i am still concerned (maybe even more so now) about your desire to give our readers less information. Happy days, ~ Lindsay^Hello 13:19, 7 April 2024 (UTC)

   @LindsayH «Least information» but «most important information», in addition, it should be readable at the first glance, topological maps are usually unreadable at the first glance. Hooman Mallahzadeh (talk) 13:24, 7 April 2024 (UTC)

   My point is that this aphorism has exhausted its usefulness, and that this should be decided case by case, not as a class. Remsense诉 14:28, 7 April 2024 (UTC)

   Occam's razor has to do with problem-solving. If we apply to everything, then we get rid of everything as being too complicated. Cremastra (talk) 01:34, 11 April 2024 (UTC)

   It's always puzzling to me when people bring up Occam's razor as if it lends any credence to a particular philosophical argument, where it universally translates to "the right answer is probably the one that seems right to me". Remsense诉 01:38, 11 April 2024 (UTC)

   I think it's a useful metric when evaluating if an idea has a lot of edge cases or exceptions. If you can find a different idea that covers the topic without edge cases, it suggests that the "edge cases" aren't actually edge cases but rather refutations.

   That being said, I don't see how Occam's rasor applies to the question at hand. 104.247.227.199 (talk) 10:13, 20 April 2024 (UTC)

6. OSM clearly doesn't include the relevant topographic information. Aaron Liu (talk) 15:57, 29 April 2024 (UTC)

Neutral

1. I support the inclusion of both, but there is no need to hide one or the other. See the current documentation of Template:Infobox river. The OSM implementation would be a good replacement for the dot locator map, but it does not at all adequately replace a topographical map showing basin-level details. I am aware of the limits of image maps particularly regarding language, but 1) this is the English Wikipedia and this primarily concerns pages in English; 2) replacing existing .jpg and .png maps with SVG maps would enable maps to be easily edited for translation; and 3) if a map isn't available in a certain language, then just using the OSM version is fine. Shannon [ Talk ] 19:00, 29 March 2024 (UTC)

• Please see WP:NOTVOTE. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:26, 29 March 2024 (UTC)

• Yeah, that isn't how policy decisions are made. AndyTheGrump (talk) 21:32, 29 March 2024 (UTC)

• Im a huge OSM map fan, but to say that a it is preferred OVER a topographical map goes way too far. editorial discretion as always should apply, and blanket 'rules' for things like this almos always backfire. —TheDJ (talk • contribs) 10:19, 20 April 2024 (UTC)

Proposal 2: Include both (OSM and topographic maps) when appropriate

This seems like it best approaches existing consensus:

When appropriate, both a topographic map and OpenStreetMaps should be included in infoboxes.

Remsense诉 01:07, 30 March 2024 (UTC)

@Remsense Just see how beautiful Japanese Wikipedia introduced the river Shinano_River by this code:

{{Maplink2|zoom=8|frame=yes|plain=no|frame-align=right|frame-width=400|frame-height=600|frame-latitude=36.93|frame-longitude=138.48
|type=line|stroke-color=#0000ff|stroke-width=3|id=Q734455|title=信濃川
|type2=line|stroke-color2=#4444ff|stroke-width2=2|id2=Q11655711|title2=関屋分水
|type3=line|stroke-color3=#4444ff|stroke-width3=2|id3=Q11362788|title3=中ノ口川
|type4=line|stroke-color4=#4444ff|stroke-width4=2|id4=Q11372110|title4=五十嵐川
|type5=line|stroke-color5=#4444ff|stroke-width5=2|id5=Q11561641|title5=渋海川
|type6=line|stroke-color6=#4444ff|stroke-width6=2|id6=Q11437096|title6=大河津分水
|type7=line|stroke-color7=#4444ff|stroke-width7=2|id7=Q3304165|title7=魚野川
|type8=line|stroke-color8=#4444ff|stroke-width8=2|id8=Q11587633|title8=破間川
|type9=line|stroke-color9=#4444ff|stroke-width9=2|id9=Q11561259|title9=清津川
|type10=line|stroke-color10=#4444ff|stroke-width10=2|id10=Q11366441|title10=中津川
|type11=line|stroke-color11=#4444ff|stroke-width11=2|id11=Q11674896|title11=鳥居川
|type12=line|stroke-color12=#4444ff|stroke-width12=2|id12=Q11530256|title12=松川
|type13=line|stroke-color13=#4444ff|stroke-width13=2|id13=Q11571106|title13=犀川
|type14=line|stroke-color14=#4444ff|stroke-width14=2|id14=Q11626952|title14=裾花川
|type15=line|stroke-color15=#4444ff|stroke-width15=2|id15=Q11671931|title15=高瀬川
|type16=line|stroke-color16=#4444ff|stroke-width16=2|id16=Q11444998|title16=奈良井川
|type17=line|stroke-color17=#4444ff|stroke-width17=2|id17=Q11563522|title17=湯川
|type18=line|stroke-color18=#4444ff|stroke-width18=2|id18=Q59404662|title18=依田川
|type19=line|stroke-color19=#4444ff|stroke-width19=2|id19=Q59490451|title19=西川
|type20=line|stroke-color20=#4444ff|stroke-width20=2|id20=Q59537584|title20=黒又川
}}

This includes all sub-rivers. I think this type of maps should be a good sample for all other Wikipedia to introduce rivers. Hooman Mallahzadeh (talk) 13:18, 30 March 2024 (UTC)

I personally quite like this, yes. I'm sure if there's some argument against this, we will be hearing it—I like when other editors hone my aesthetic senses. Remsense诉 13:21, 30 March 2024 (UTC)

It looks very useful. I also stumbled across the Syr Darya page which manages to use both types of map in the infobox using the |extra= field. I would say that's a good, clean way to approach it going forward. Again, I think both types of maps are useful in different ways, and I see no reason to take an absolutist stance and say one or the other should be favored in all cases.

To add, I was kind of rubbed the wrong way at the start of this debate by OP's attitude that new and high tech is always better regardless of the context or usage (not to mention inventing an imaginary consensus which totally threw me for a loop), and as others have commented, this isn't how policy decisions on Wikipedia are made. Finally, as someone passionate about river topics, the auto generated maps just don't tell the full "story". It's nuance and individual approach versus cold standardization. Yes, there are a lot of poorly drawn and inaccurate user-made maps out there (including many of my older maps) which could do well with being replaced, but then there are beautiful ones like Rhine, which provide a value much harder to replace.Shannon [ Talk ] 16:53, 30 March 2024 (UTC)

@Shannon1 Even in the article of Rhine and in the selected map of Infobox, the font is too small and we can't read anything. So aside from choosing OSM or not, between existing maps, the second map i.e., File:Rhein-Karte2.png is more appropriate for Infobox map of this article. I think we should make a policy for selecting between maps, the one that is more abstract, i.e. we apply this policy:

The simplest and most abstract map is the preferred one for Infobox of articles

Hooman Mallahzadeh (talk) 17:56, 30 March 2024 (UTC)

I have already made my point, so I'll excuse myself from further argument on this thread. As I've stated, I support applying both maps where possible as I believe that provides the best value for the reader. I don't particularly mind if the OSM or topographic map is placed first or second in the infobox. However, I cannot agree with the assessment that "the simplest and most abstract map is preferred" in the context of rivers, which are complex systems that are much more than a simple blue line. Unless a broader consensus can be reached, I maintain to oppose any removal of useful content that have been considered standard on river articles for years. Shannon [ Talk ] 19:56, 30 March 2024 (UTC)

This seems to be the best of both worlds, clear, readable map, with some information about the watershed. - Enos733 (talk) 19:00, 29 April 2024 (UTC)

Proposal 3: Selection of varous types of "topographical maps" as background for OSM

I think this "alignment scenario" would be perfect:

OSM maps of rivers remains unchanged, but OSM white background could be changed to various topographical backgrounds by users.

Implementing this idea has challenges about setting correct size and challenges of alignment of two maps, but its implementation is not hard. Hooman Mallahzadeh (talk) 10:39, 20 April 2024 (UTC)

I'm sure it can work fine, but I still am not quite understanding why we would need to codify it as policy. Everyone has pretty much re-reiterated their preference for "just figure out what works on a per article basis", and you haven't really articulated why there's anything wrong with that. Remsense诉 10:41, 20 April 2024 (UTC)

@Remsense We should apply a policy is for "the selection of a map between various maps" for Infoboxes, which is for "First Glance Data". Wrong selection could give no data at the first glance. Hooman Mallahzadeh (talk) 10:45, 20 April 2024 (UTC)

I'm not sure I understand. Editors are currently free to decide what is best for each article, as per usual. Unfortunately, I don't think the type of arguments you've made are going to convince other editors that we should restrict editors' flexibility like that. If you want to improve the site, I think working on individual articles and discussing how to improve their maps for each would be more helpful to the site, because I still don't see a need to change sitewide policy. Remsense诉 10:51, 20 April 2024 (UTC)

You said

Editors are currently free to decide what is best for each article, as per usual.

Editors should select what type of map for infobox? In the most cases (over 90%), the «simplest map» is the best for infobox. Do you agree? But in very special cases other maps should be used for Infoboxes. Isn't it better to be a «policy»? Hooman Mallahzadeh (talk) 11:00, 20 April 2024 (UTC)

I don't think so, no. Let editors make their own choices per article. You are working in generally correct principles, but this would be applying them too dogmatically, as mentioned above. Remsense诉 11:02, 20 April 2024 (UTC)

@Remsense But I really think that the selection of File:Bassin Seine.png for Seine river happened in English Wikipedia is wrong. Selection of French Wikipedia for this river is more appropriate, because it provides more data at the first glance. If we apply a «selection policy», such bad selections would not happen anymore. Hooman Mallahzadeh (talk) 11:18, 20 April 2024 (UTC)

...then discuss the merits for that particular map on that particular talk page, like I've suggested several times! That's how Wikipedia generally works. I don't know how else to illustrate that your suggestion seems overly restrictive, and the flexibility seems more worthwhile here, but please try to understand what I'm saying with that, I guess? Remsense诉 12:42, 20 April 2024 (UTC)

How to describe past events on the main page

Currently, the status quo for events listed on the main page is to use the present tense, even if the event in question has definitively ended. I didn't really notice this was an issue until yesterday when I noticed that the main page said that the Solar eclipse of April 8, 2024 is visible through parts of North America. Knowing that it was not currently visible and double checking that the article referred to the event in the past tense, I changed this to was visible. [1] I did not realize that this is against the current consensus at WP:ITNBLURB which says that these events must always be described in the present tense. If one is interested in further background, I encourage them to read this discussion here (scroll down to errors).

I think that this status quo is misleading to readers because it cases like this, we are deliberately giving inaccurate and outdated information. I believe this is a disservice to our readers. The eclipse is not visible anymore, yet we must insist that it is indeed visible. I think that we should also be consistent... If the article for a blurb is using the past tense, we should use the past tense on the main page. Therefore, I propose that events listed on ITN that have definitively ended should be described in the past tense if it would otherwise mislead readers into thinking an event is ongoing. Clovermoss🍀 (talk) 11:33, 10 April 2024 (UTC), edited 17:00, 10 April 2024 (UTC)

Note: Notification of this discussion was left at Wikipedia talk:In the news.—Bagumba (talk) 12:00, 10 April 2024 (UTC)

I propose that events listed on ITN that have definitively ended should be described in the past tense: But any blurb can be written in the past tense, e.g., a country was invaded, an election was won, a state of emergency was declared, etc. So if we did go to past tense, I don't understand why there is a distinction with needing to have "definitively ended".—Bagumba (talk) 12:07, 10 April 2024 (UTC)

I made the distinction because I felt our current approach was the most jarring in situations where we're literally misleading the reader. I don't really have any strong preferences either way on other situations and felt like it'd be for the best to make sure my RfC was clear and not vague. I'm not trying to change every blurb at ITN right now, hence the "definitive end date" emphasis. If someone wants more broader changes to verb tense at the main page, I'd say that warrants its own separate discussion. Clovermoss🍀 (talk) 12:16, 10 April 2024 (UTC)

Note The blurb currently reads A total solar eclipse appears across parts of North America[2]—Bagumba (talk) 12:33, 10 April 2024 (UTC)

I was about to suggest a rewording along these lines… so that the blurb is accurate while maintaining present tense. Blueboar (talk) 12:45, 10 April 2024 (UTC)

It's better than flat out saying visible, but this phrasing still implies that it is visible? Present tense when an event has ended implies that an event is still ongoing. Clovermoss🍀 (talk) 16:22, 10 April 2024 (UTC)

Appear means to start to be seen or to be present.[3] It doesn't say that it continues to be seen. Perhaps the previous blurb's problem was that it resorted to using is, incorrectly implying a continuing state, not that a present-tense alternative was not possble(??)—Bagumba (talk) 06:34, 11 April 2024 (UTC)

To be present is to continue to be seen (by those looking, at least). I think you're misreading that as to start to be seen or present. That second to be matters here (and so it appears bold). InedibleHulk (talk) 22:30, 11 April 2024 (UTC)

Support per nom, see no reason to oppose. Aaron Liu (talk) 13:19, 10 April 2024 (UTC)

Per below, there isn'ta clear way forward for this one. On one hand, "Liechtenstein wins the FIFA World Cup" should definitely remain that way, but this also causes situations like these. Maybe something like unless this wording directly encourages a misleading interpretation that the event is still ongoing., using an earthquake in present tense and this event in past tense as examples. Or maybe we should just IAR such cases. Aaron Liu (talk) 16:30, 10 April 2024 (UTC)

I don't think IAR is going to work as long as we don't have an explicit exemption because it'd be causing someone to explicitly go against consensus for their own ends. I switched the wording to "was visible" out of ignorance in regards to current standards, not because I was deliberately ignoring them. I think there might have been much more ado made about my actions if I had done this with a justification of IAR. I don't have issues with your proposed wording, because again, my biggest issue with all of this is intentionally misleading readers. Clovermoss🍀 (talk) 16:39, 10 April 2024 (UTC)

@Aaron Liu: I've changed the proposal to have "if it would otherwise mislead readers into thinking an event is ongoing". Does that address your concerns? Clovermoss🍀 (talk) 17:03, 10 April 2024 (UTC)

Support, though I find isaacl's alternative of including a time frame intriguing. Aaron Liu (talk) 17:11, 10 April 2024 (UTC)

Comment for a lot of blurbs, the present tense is fine, as it continues to be true. e.g. elections, "X is elected leader of Y" is correct and better than past tense, and same with sports matches that end up on ITN. A blanket change to past tense is disingenuous therefore, although swapping to past tense for events that happened (and aren't ongoing) seems somewhat reasonable. Joseph2302 (talk) 13:55, 10 April 2024 (UTC)

Isn't "Is elected" past tense? Though I agree that for situations where we can use the active voice, "Z legislature elects X as leader of Y" sounds better. Aaron Liu (talk) 14:05, 10 April 2024 (UTC)

"Is elected" is present tense, specifically present perfect. "Elects" is also present tense, simple present. Levivich (talk) 18:14, 10 April 2024 (UTC)

I thought "is elected" is passive voice. Voters are doing the electing, the elected person is passive in this situation. In passive voice "elected" is a past participle (also sometimes called the passive or perfect participle). (Side note: present perfect in English usually takes "have/has" as an auxiliary verb) —⁠andrybak (talk) 23:00, 23 April 2024 (UTC)

I think for time-bound events such as the eclipse, including a time frame would be the best approach to avoid confusion. Additionally, I think using past tense is fine. isaacl (talk) 17:09, 10 April 2024 (UTC)

I am in favor of past tense for everything. "Won the election," or "landslide killed 200" or "eclipse appeared" all read as fine to me. Newspapers using present tense makes sense because they publish every day (or more often). It doesn't make sense for ITN where items stay posted for days or weeks. Levivich (talk) 18:10, 10 April 2024 (UTC)

Something about ITN mostly using present tense just feels... righter. Regardless of staying posted for weeks, they are all quite recent compared to most other stuff we have on the main page. Also see historical present. Aaron Liu (talk) 20:30, 10 April 2024 (UTC)

I'll have what you're having. InedibleHulk (talk) 22:30, 11 April 2024 (UTC)

• Decide case-by-case: we can safely IAR in most cases. Cremastra (talk) 19:43, 10 April 2024 (UTC)
• No special rules for the main page: use the same tense we would in articles. We are an encyclopedia not a newspaper. (t · c) buidhe 20:37, 10 April 2024 (UTC)
• Object The present tense serves us well. It is the standard tense for headlines, certainly within the UK and I believe US too (though some MoS in the US is very different to the UK). I can't see anything in the proposal beyond change for the sake of change. doktorb _words^deeds 22:00, 10 April 2024 (UTC)

  Again, it is confusing to say that the solar eclipse is in the sky. Aaron Liu (talk) 22:05, 10 April 2024 (UTC)

  It would be confusing to switch from "is....was....did....has" in a single box on a typical ITN week. doktorb _words^deeds 22:28, 10 April 2024 (UTC)

  A typical ITN week does not have many blurbs that really need the past tense like the solar eclipse. Aaron Liu (talk) 02:37, 11 April 2024 (UTC)

• We should use the correct tense. Someone does not "wins" an election or sports match, they won it. The eclipse, after it ended, was visible over North America, but "is" visible is factually inaccurate at that point (and before it starts to happen, we should say it will be visible). A political leader does not "makes" a statement, they made it. On the other hand, it may be accurate to say that a conflict is going on, or rescue efforts after a disaster are underway. So, we should use the natural, normal tense that accurately reflects the actual reality, as it would be used in the article. Seraphimblade ^{Talk to me} 06:02, 11 April 2024 (UTC)
• Object I don't think I agree with the premise that ITN blurbs are phrased in the present in the first place. It's in the historical present tense. "A 7.4-magnitude earthquake strikes near Hualien City, Taiwan" doesn't give the impression that the ground is still shaking. Nor does "A solar eclipse appears across parts of North America" read as "a solar eclipse is happening right now." Likewise, "Nobel Prize–winning theoretical physicist Peter Higgs (pictured) dies at the age of 94." doesn't need to be changed to "died at the age of 94", we know it's in the past, we're not under any illusions that he's still in the process of dying. It's phrased in such a way that doesn't really imply either past or present and just kind of makes sense either way. If an event is still happening, the blurb makes sense. And if the event is over, the blurb still makes sense. I think that's intentional.  Vanilla  Wizard 💙 07:33, 11 April 2024 (UTC)

  Actually, I think that "A 7.4-magnitude earthquake strikes near Hualien City, Taiwan" does give the impression that the ground is still shaking, or at least that it was shaking very recently. Even newspaper headlines avoid that, especially after the first day. "Hualien struck by massive earthquake" is a perfectly normal headline style. In fact, I find these actual headlines in the past tense:

  • Taiwan Struck by Deadly 7.4-Magnitude Earthquake
  • Taiwan shaken but unbowed as biggest quake in 25 years spotlights preparedness
  • Taiwan hit by powerful earthquake
  • Taiwan hit by its strongest quake in quarter-century, but death toll is low
  • Earthquake in Taiwan blamed for at least 9 deaths as buildings and roads seriously damaged
  • Taiwan hit by strongest earthquake in 25 years, killing 9

  WhatamIdoing (talk) 01:00, 20 April 2024 (UTC)

• Keep present tense as general recommendation per above. Discuss individual cases when this is too jarring. —Kusma (talk) 07:43, 11 April 2024 (UTC)
• As an encyclopedia rather than a news agency, I would think past tense fits our vibe more. Archives of our frontpage would remain clearly accurate indefinitely. We are not reporting news, we are featuring a newly updated/written encyclopedic article on currently relevant events. ~Maplestrip/Mable (chat) 08:22, 11 April 2024 (UTC)
• Keep present tense. There is a difference between "X is happening" (which necessarily means right now, at this moment) and "X happens" (which os somewhat more vague). We should always use the second form, regardless of precise moment. As stated above, we even have statements like "an earthquake hits..." or "So and so dies", both of which are clearly over by the tine it gets posted. Animal lover |666| 19:12, 11 April 2024 (UTC)
• Object from a wp:creep standpoint To my knowledge there is no rule regarding this and it's just a practice. This would change it to having a rule. North8000 (talk) 19:25, 11 April 2024 (UTC)

  How? The present tense rule was always written down there and this proposal does not make ITN a guideline. Aaron Liu (talk) 19:42, 11 April 2024 (UTC)

• No, it should not – it's unencyclopaedic and ungrammatical. The Simple Present is used to describe habitual or continuous actions or states (the Sun sets in the West; he is a boot-and-shoe repairman; I'm Burlington Bertie, I rise at ten-thirty; Timothy Leary's dead etc). Events in the past are described using the Present Past when when no time is specified (the lunch-box has landed; London has fallen; mine eyes have seen the glory ...). When a time in the past is specified, the Simple Past is invariably used: in fourteen hundred and ninety-two, Columbus sailed the ocean blue, in fourteen hundred and ninety-three, he sailed right back over the sea; today, I learned; well I woke up this morning and I looked round for my shoes. This is not rocket science. Ours is not a news outlet with a profit target to meet, we have no reason to have 'headlines', which are simply bits of news given some kind of extra urgency by being in the wrong tense. "Wayne Shorter dies!" immediately begs the question "really? how often?" So "A total eclipse of the Sun has occurred; it was visible in [somewhere I wasn't] from [time] to [time]". It gives the information, it's written in English, where's the problem? (NB there are two distinct present tenses in English, the Simple Present and the Present Continuous; the latter is used for things that are actually happening in this moment or about to happen in the future (I'm going down to Louisiana to get me a mojo hand; I’m walking down the highway, with my suitcase ...). Justlettersandnumbers (talk) 20:22, 11 April 2024 (UTC)

  @Justlettersandnumbers: Reading your comment makes it sound like it supports of my proposal instead of opposing it? I don't understand the "no, it should not" unless there's something I'm not getting. Clovermoss🍀 (talk) 21:10, 11 April 2024 (UTC)

  @Clovermoss The title of your section begins with "Should the main page continue to use the present tense". Aaron Liu (talk) 22:49, 11 April 2024 (UTC)

  And then the actual RfC itself is my proposal to change that for situations where this would be misleading readers. I'm not sure it's necessarily the best idea to be messing around with section names at this point but I'm open to suggestions that would help make this less confusing for people. Clovermoss🍀 (talk) 22:53, 11 April 2024 (UTC)

  Eh, never mind. I decided to be bold and make it consistent with how CENT describes this discussion. Hopefully that helps things. Clovermoss🍀 (talk) 23:15, 11 April 2024 (UTC)

• Support Given that WP:ITNBLURB currently has the guideline that "blurbs should describe events in complete sentences in the present tense," it does not seem like instruction creep to modify an existing rule. isaacl recommends including a time-frame, but I find this impractical for events that occur over multiple time zones. While this eclipse's article reports the event's span over the overall planet in UTC, this level of detail is too cumbersome for a main page blurb. Clovermoss' proposal limits itself to cases where the present tense would be confusing, which is preferable to an individual discussion for each perceived exception to the current guideline. BluePenguin18 🐧 ( 💬 ) 20:50, 11 April 2024 (UTC)
• Yes, the practice should continue - this is a perfectly normal idiomatic feature of English. Headlines are written in the present tense, just like 'in which...' in the chapter sub-headings of old novels, the summaries of TV episodes in magazines and on streaming services, and lots of other places where a reported past action is summarised. GenevieveDEon (talk) 21:33, 11 April 2024 (UTC)
• How about, "is seen over North America" -- passive with present tense and past participle, anyone? :) Alanscottwalker (talk) 21:49, 11 April 2024 (UTC)

  That's a better solution than ending the practice of using the historical present tense. Though I think that suggestion is more likely to be implemented at WP:ERRORS than through a Village Pump policy proposal. (I'm also not entirely sure why this whole discussion isn't just at the ITN talk page since it doesn't affect any other part of the main page, but it's no big deal)  Vanilla  Wizard 💙 20:10, 12 April 2024 (UTC)

  ERRORS is not the appropriate venue, given that the discussion that was there was removed. As for why it's here specifically, I figured anything regarding the main page was important, that a discussion here would invite more participants, and avoid the possibile issue of a local consensus. Clovermoss🍀 (talk) 20:16, 12 April 2024 (UTC)

  I originally thought this suggestion was sarcastic, given the smiley face. If it is serious, I dislike it because "is seen" is extremely passive voice. Assuming there is a problem (which I don't think there is), the solution is not passive voice. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:22, 12 April 2024 (UTC)

  I don't think passive voices are that bad; while I agree that the active voice is usually preferred, do you really think that "North Americans see a total solar eclipse" is better? Aaron Liu (talk) 21:32, 12 April 2024 (UTC)

  No. I think that the current iteration "A total solar eclipse appears across parts of North America" is perfect. CaptainEek ^{Edits Ho Cap'n!}⚓ 21:37, 12 April 2024 (UTC)

  I was illustrating why the passive voice doesn't deserve to be demonized. Aaron Liu (talk) 21:42, 12 April 2024 (UTC)

  In fairness, that discussion was removed specifically because ITN uses present tense and the discussion was proposing to change that, and ERRORS isn't the place for proposals to change how we do things. Alanscottwalker's suggestion also uses the present tense, so ERRORS would be a fine venue if they really wanted to see that change made. After all, that discussion at ERRORS is what resulted in the language being changed from "is visible" to "appears". I personally think appears is totally fine (I agree with CaptainEek that there is no problem), but if someone prefers "is seen", that's the place to do it.  Vanilla  Wizard 💙 20:33, 12 April 2024 (UTC)

  That discussion only happened because I changed "is visible" to "was visible", prompting an errors report. I'd prefer "appeared" over "appears" since that implies that it is still indeed visible per the above discussion. It's better than "is visible", though. Clovermoss🍀 (talk) 01:07, 13 April 2024 (UTC)

• Keep present tense as ITN is supposed to summarize and collect news headlines and the present tense is standard in headlines. Pinguinn 🐧 00:05, 12 April 2024 (UTC)
• Keep using historical present I think a lot of supporters here are confusing the historical present (often used in news headlines) for the simple present. I would agree that the eclipse would have made sense to be an exception to that general rule, as was the focus in the original proposal here, but I wouldn't change the general rule. Anomie⚔ 12:04, 12 April 2024 (UTC)

  Currently, in this proposal, I see a codified exception for when using the present tense would be confusing that would only apply in cases like the solar eclipse. Aaron Liu (talk) 12:43, 12 April 2024 (UTC)

  @Anomie, the lead of our article on the historical present says the effect of the historical present is "to heighten the dramatic force of the narrative by describing events as if they were still unfolding". I'm not convinced that making things sound more dramatic should be a goal for an encyclopedia, and I would not have guessed that you would support such a goal. Do you? WhatamIdoing (talk) 01:09, 20 April 2024 (UTC)

• Keep historical present tense Headlines are most compelling and appropriate in the historical present tense. The NYTimes provides that "Headlines are written in the historical present tense. That means they written are in present tense but describe events that just happened."
  Out of curiosity, I perused the AP Stylebook (56th edition, 2022-2024), which surprisingly had almost nothing to say on tenses, though its section on headlines is generally instructive.

  "Headlines are key to any story. A vivid, accurate and fair headline can entice people to dig in for more. A bland, vague or otherwise faulty headline can push readers away. Often, a headline and photo are all that many readers see of a story. Their entire knowledge of the piece may based on those elements. Headlines must stand on their own in conveying the story fairly, and they must include key context. They should tempt readers to want to read more, without misleading or overpromising."

  How to best have a vivid headline? Present tense and active voice! One of Wikipedia's most frequent writing errors is using past tense and passive voice out of a misplaced assumption that it is more encyclopedic. But past and passive are weak. Present and active are better, and are what I have been taught in a wide multitude of writing courses and professional spaces. To add to the NYTimes, AP, and personal experience, I consulted my copy of Bryan Garner's Redbook (4th ed.), which while meant as a legal style guide, is useful in other areas. Regarding tense, in heading 11.32, it provides that "generally use the present tense." I then turned to the internet, which backed up the use of present tense in headlines: Grammar expert suggests present tense "Engaging headlines should be in sentence case and present tense." Kansas University on headlines: "Present tense, please: Use present tense for immediate past information, past tense for past perfect, and future tense for coming events."
  Using the historical present is best practice for headlines. That's not to say that there can't be exceptions, but they should be rare. As for the eclipse, it properly remains in the historical present. As a further consideration: if we are updating ITN tenses in real time, we are adding considerable work for ourselves, and we push ourselves truly into WP:NOTNEWS territory. CaptainEek ^{Edits Ho Cap'n!}⚓ 18:35, 12 April 2024 (UTC)

  I don't think we're adding considerable work for ourselves. It takes a second or two in the rare situations that require it, anything else regarding the main page has much more work involved. We already update the articles in question, just not the blurb, which is a bit of a jarring inconsistency in itself. I don't understand the argument that the tense we should be using should be comparable to newspaper headlines because we're NOTNEWS? Could you elaborate a bit on your thinking there? Clovermoss🍀 (talk) 19:43, 12 April 2024 (UTC)

  For the last part: they're mistaken that this proposal would require tenses to be updated to the past tense when any event ends, which is way too much effort to stay current which kinda does fall into NOTNEWS. (Note that this proposal would only require past tense if the historical present causes confusion) Aaron Liu (talk) 19:50, 12 April 2024 (UTC)

  We are NOTNEWS. But as my comment above alludes to, ITN is a de facto news stream. Each entry in ITN is effectively a headline. Why try to reinvent the headline wheel? I'm afraid I have to disagree with Aaron's clarification, because Clover did change the tense after the event ended. It would have been incorrect to say "was" when the blurb first posted...because the eclipse was presently happening at that time. I'll add further that "otherwise mislead readers into thinking an event is ongoing" is an unhelpful standard. I don't buy that the average reader is going to be confused by a historical present headline. We read headlines all the time, and the average reader understands the historical present, even if they couldn't define it. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:18, 12 April 2024 (UTC)

  I have to disagree with you there. I think that when the main page stated that the eclipse "is visible", that was confusing to the average reader. It confused me, prompting me to check that the eclipse wasn't somehow ongoing. We were giving inaccurate information intentionally and I honestly don't see why we do this for the main page. Because it's interesting? Because newspapers do it before an event happens? Once the eclipse ended, newspapers referred to the event in the past tense as well. My decision to change it to "was visible" took one second (so not a considerable time investment, although everything that ensued certainly has been). Clovermoss🍀 (talk) 20:32, 12 April 2024 (UTC)

  Ah, that's my bad, the "is visible" language is also problematic for its passivity. I like the "appears" solution, and thought that was the original wording. But I think it would be improper to say "appeared." I'm not so sure I buy that newspapers were uniformly using past tense; again, the best practice for newspapers is to use the historical present. The time issue is ancillary to the best practice issue, I agree that the real time sink is the discussions that will surely result from implementing this rule. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:42, 12 April 2024 (UTC)

  I could show some examples if you'd like, since you don't seem to buy that newspapers were using the past tense after the eclipse appeared.

  • "A total eclipse of a lifetime appeared for hundreds of thousands of visitors and residents in the Hamilton-Niagara region" – Canadian Broadcasting Corporation [4]
  • "In middle America, the eclipse was a phenomenon" – Washington Post [5]
  • "During the event on April 8, 2024, one of these arcs was easily visible from where I stood, agape beneath our eclipsed, blackened star, in Burlington, VT." – Mashable [6]
  • "The great American eclipse appeared Monday, bringing the nation to a standstill as photographers captured stunning shots of the rare celestial event." – CNET [7]
  • "The total solar eclipse that swept across Mexico, the United States and Canada has completed its journey over continental North America." – CNN [8]

  I think that "appears" is better than saying "is visible" like the previous phrasing was before my intermediate change of "was visible" but it still runs into the issue of implying the eclipse is appearing somewhere. I agree with what InedibleHulk said above To be present is to continue to be seen (by those looking, at least). I think you're misreading that as to start to be seen or present. That second to be matters here (and so it appears bold). Clovermoss🍀 (talk) 21:14, 12 April 2024 (UTC)

  The operative issue is that these are headlines from after the event. But the blurb got posted during the event. CaptainEek ^{Edits Ho Cap'n!}⚓ 21:19, 12 April 2024 (UTC)

  And the blurb stays days or weeks on the main page, where using the past tense would be more accurate than using present tense the entire time. I also think that having a clear exemption clause would prevent time sink discussions like this one, not cause them. It'd prevent us from needing to have a discussion every time something like this happens. Clovermoss🍀 (talk) 21:25, 12 April 2024 (UTC)

  I think that this discussion would prevent some time sink over reluctance to IAR. And again, only a small number of events would need their tense changed. Aaron Liu (talk) 21:34, 12 April 2024 (UTC)

• Drop present tense and use the tense we'd use anywhere else on Wikipedia. Wikipedia is not a newspaper, even on the Main Page, and there's no reason we should obscure the timing of events for stylistic reasons. Loki (talk) 21:18, 12 April 2024 (UTC)

  The tense we'd use anywhere else is, by default, present? WP:TENSE provides that By default, write articles in the present tense. CaptainEek ^{Edits Ho Cap'n!}⚓ 21:22, 12 April 2024 (UTC)

  MOS:TENSE says By default, write articles in the present tense, including those covering works of fiction (see Wikipedia:Writing better articles § Tense in fiction) and products or works that have been discontinued. Generally, use past tense only for past events, and for subjects that are dead or no longer meaningfully exist. We use past tense for past events like we do at the actual article linked in the ITN blurb: Solar eclipse of April 8, 2024. It's just the main page where we make the stylistic choice to not do that. Clovermoss🍀 (talk) 21:31, 12 April 2024 (UTC)

• The present tense makes the main page read like a news ticker, which we are often at pains to explain it is not (e.g. WP:NOTNP). I would favour the past tense for all events that are not ongoing. If we cannot agree on that, I support the proposal to use the past if there might be a misunderstanding (partly in the hope that familiarity will lead to the past tense being used more and more in the future!). JMCHutchinson (talk) 11:06, 13 April 2024 (UTC)
• Support Per WP:NEWSSTYLE, "As a matter of policy, Wikipedia is not written in news style ..." . ITN is especially embarrassing because its blurbs are often weeks old and so its use of the present tense is then quite misleading. It might help if the blurbs were dated to show how old they are. See OTD and the Spanish edition for examples. Andrew🐉(talk) 07:38, 18 April 2024 (UTC)
• Support the thing Clovermoss said we should do (to head off any confusion about whether "support" or "oppose" means to support or oppose making or not making a change, etc). jp×g🗯️ 06:30, 19 April 2024 (UTC)
• Oppose any firm rule. The same style is used in the not-so-current-events sections of year pages, or at least those I've checked so far:
  • From 520: The monastery of Seridus, where Barsanuphius and John the Prophet lived as hermits, is founded in the region of Gaza
  • From 1020: King Gagik I of Armenia is succeeded by Hovhannes-Smbat III.
  • From 1920: A woman named Anna Anderson tries to commit suicide in Berlin and is taken to a mental hospital where she claims she is Grand Duchess Anastasia of Russia.
  • From 2020: A total solar eclipse is visible from parts of the South Pacific Ocean, southern South America, and the South Atlantic Ocean.
• Now maybe I'm being a bit OTHERSTUFFy here and it's year pages that should be fixed, but until that's done, it would seem really weird to describe 1000-year-old events with "is", but events from last week with "was". Suffusion of Yellow (talk) 21:48, 19 April 2024 (UTC)

  None of these except the 2020 one can be mistaken as things that are currently happening. Aaron Liu (talk) 22:20, 19 April 2024 (UTC)

• I think we should use the past tense for some events (e.g., any event that is definitively "finished") and present tense for those that are ongoing. I didn't see a single clear argument above for using the present tense for things that are completely finished [correction: except for CaptainEek, who wants to use historical past for the "vivid" dramatic effect]. There are comments about what label a grammarian would apply to it, and comments saying that this is the way we've always done it, but no comments giving a reason for why it's better for readers if we say that a ten-second earthquake from last week "is" happening instead of that it "did" happen. WhatamIdoing (talk) 00:50, 20 April 2024 (UTC)

  Because the historical present is a convention in English, period. There's also consistency with lists of past events, which also blocks useful things like moving navboxes to the See also. Aaron Liu (talk) 00:53, 20 April 2024 (UTC)

  The historical present is a convention in English. It is not the only convention, which means we could choose a different one. Why should we choose this convention? WhatamIdoing (talk) 01:01, 20 April 2024 (UTC)

  For consistency and compactness. Aaron Liu (talk) 02:51, 20 April 2024 (UTC)

  The amount of compactness is usually one character – the difference between is and was, or elects and elected. In other cases, it's the same or shorter: shook instead of shakes for earthquakes, died instead of dies for deaths. I don't think that sometimes saving a single character is worth the risk of someone misunderstanding the text, especially since we get so many readers who do not speak English natively.

  As for consistency, I think that being easily understood is more important than having parallel grammar constructions across unrelated items. WhatamIdoing (talk) 05:28, 20 April 2024 (UTC)

  The historical present is not the convention anywhere on Wikipedia's main page. Just see today:

  • TFA: "The Nicoll Highway collapse occurred in Singapore...
  • DYK: "...librarian Amanda Jones won an award..."
  • OTD: "South African Airways Flight 228 crashed shortly after take-off ..."

  ITN is the only possible exception and it's not using the historical present because it's not referring to history.

  Andrew🐉(talk) 12:37, 20 April 2024 (UTC)

• I don't think anything needs to be changed here style-wise, we just need to write better ITN blurbs. "Solar eclipse is visible" isn't the historical present and it isn't sensible either. -- asilvering (talk) 06:21, 22 April 2024 (UTC)
• Not sure why this discussion isn't happening at WT:ITN, but stick with simple present as we have done for years. Stephen 09:49, 22 April 2024 (UTC)

  A notification has been at Wikipedia talk:In the news#Blurb tense for a while now. Putting this here attracts more attention.

  Most blurbs will not need to be changed to the past tense. Only things like "is visible" need to be changed. Aaron Liu (talk) 12:54, 22 April 2024 (UTC)

• The historical present should be taken behind the barn, shot, burned, and the ashes scattered to the four winds. --User:Khajidha (talk) (contributions) 14:02, 22 April 2024 (UTC)

Violently expressed dislike is not the same as a reasoned argument. The historic present is used widely in headlines, timelines, and other applications both on this site and elsewhere which are comparable to the ITN headlines. GenevieveDEon (talk) 14:16, 22 April 2024 (UTC)

Using present tense for completed events is ridiculous (which is even worse than wrong), no matter how much it may be used elsewhere. --~ User:Khajidha (talk) (contributions) 15:43, 22 April 2024 (UTC)

But Wikipedia cares about consistency, present tense saves characters, and most events will not be confused as ongoing. Aaron Liu (talk) 15:48, 22 April 2024 (UTC)

As I showed above, the present tense only occasionally saves characters, and the number of characters saved is most often one (1).

In my experience, the English Wikipedia cares more about clarity accuracy than about consistency. There are ~650 pages citing Emerson: "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." (And now there is one more.) WhatamIdoing (talk) 23:30, 22 April 2024 (UTC)

As you've said, I can't really articulate my thoughts on why we should use the historical present. I guess that's because not all grammar rules and conventions make sense either, yet they're usually prescribed. The most sense I could make is sort of "vividness": they emphasize that these events happen in the present day, as opposed to most of our content on the main page.

I also wish that Wikipedia didn't care so much about consistency, but it seems that we do, which has led to navboxes not being moved to the see also section and nearly all of them turned into the standard purple. Maybe that made me think to consistify the consistency. Aaron Liu (talk) 00:01, 23 April 2024 (UTC)

The rest of the main page uses past tense to refer to events that have occurred. The articles use the past tense to refer to past events. In the News isn't an up-to-the-moment news ticker; it points out articles that are related to current events. isaacl (talk) 00:14, 23 April 2024 (UTC)

Past, yes, but as you said they’re related to current events. These events are much more current than the rest of the main page and historical present emphasizes that.

Hopefully we have a rough consensus to at least put “otherwise confusing blurbs can you use the past tense” into the rules. Aaron Liu (talk) 00:17, 23 April 2024 (UTC)

The point is for the main page, using the same tense as the rest of the page, as well as the underlying articles, would be consistent. isaacl (talk) 01:26, 23 April 2024 (UTC)

The main page is just a reflection of the rest of the site. We don't need to force everything on the main page to be the same, and the underlying lists of stuff linked above also use historical present. Aaron Liu (talk) 11:14, 23 April 2024 (UTC)

The main page is just a reflection of the rest of the site. My understanding is that ITN blurbs are literally the only place we enforce this stylistic choice. It's inconsistent with the actual articles linked in the blurb. [9] I can't help but think that if this situation was the other way around (the status quo was to be consistent) that people would find the arguments for this unconvincing. Clovermoss🍀 (talk) 11:19, 23 April 2024 (UTC)

Most of the site doesn't use blurbs, but all the year articles do. See Suffusion of Yellow's comment above. Aaron Liu (talk) 12:27, 23 April 2024 (UTC)

I suppose then my question is if there's a consensus for year pages that things must be done that way then because it's not otherwise a stylistic choice you see outside of ITN blurbs. Clovermoss🍀 (talk) 15:02, 23 April 2024 (UTC)

You brought up consistency as an argument. I feel a reader will notice inconsistency amongst sections of the main page more readily than between the In the News section and the year articles. There's no navigation path between the latter two, but readers can easily jump between sections of the main page. isaacl (talk) 16:26, 23 April 2024 (UTC)

• Retain historical present. ITN blurbs are intentionally written in the style of news headlines, and that makes most sense given global usage on this point. It would be silly for Wikipedia to have a set of news items written differently from how every other outlet writes its news items. Cases like the eclipse can be handled on an individual basis, by rewriting the blurb into an alternative historical present form that removes the implication of ongoing nature. Arguably that blurb was simply badly structured in the first place as a normal headline wouldn't contain the word "is".  — Amakuru (talk) 09:50, 23 April 2024 (UTC)

  Wikipedia is not trying to be a news outlet; it's an encyclopedia. The correct comparison is then with a site like Britannica. Today, this opens with coverage of Passover:

  April 23, 2024
  Different from All Other Nights
  Last night marked the beginning of the Jewish holiday of Passover, which commemorates the Hebrews’ liberation from slavery in Egypt and the “passing over” of the forces of destruction, or the sparing of the firstborn of the Israelites, on the eve of Exodus. This year’s celebration occurs against a backdrop of conflict—today also marks the 200th day in the Israel-Hamas War—and heightened concerns of rising anti-Semitism.

  This makes the temporal context quite clear by dating the item and then using tenses accordingly -- the past tense for "last night" and the present tense for "today". Presumably tomorrow they will have a different item as their lead to reflect the fact that the present has moved on. This seems exemplary -- quite clearly explaining what's happening today specifically.

  Andrew🐉(talk) 11:05, 23 April 2024 (UTC)

  What about the present tense of "occurs"? I don't think a very long holiday is a good example.

  Looking at a few of their MP blurbs, most of them are anniversaries. Hopefully someone can find more examples of current events. Aaron Liu (talk) 11:13, 23 April 2024 (UTC)

  It's just a matter of looking. Today, Britannica has another holiday as its featured article – Arbor Day. But it also has a section Behind the Headlines which is similar to our ITN in covering current affairs. This consistently uses the past tense:

  Question of immunity

  As Donald Trump sat in a Manhattan courtroom for the hush-money case regarding Stormy Daniels, the Supreme Court heard arguments as to whether the former president was immune from prosecution...

  Weinstein trial

  The 2020 rape conviction of Harvey Weinstein in New York was overturned on Thursday...

  Falling down the rat hole

  Chicago’s “rat hole”—a section of sidewalk bearing the imprint of a rat—has been shuttered...

  Andrew🐉(talk) 22:11, 27 April 2024 (UTC)

• Use historical present I don't see why WP:NOTNEWS is being brought up, because in that case surely we should be advocating for the elimination of a section titled "In The News"? If ITN continues to exist, it should use the style common to most respected news publications—the historical present. ~~ AirshipJungleman29 (talk) 16:07, 28 April 2024 (UTC)
• Not broken, don't fix. In the vast majority of cases, the current approach works perfectly fine and without any chance of confusion. In the very few cases where the blurb phrasing is ambiguous, that can be brought up at WP:ERRORS and an appropriate rephrasing found. We don't need a new rule here. Also, this RFC confuses ITN with the Main Page - present tense is only used in one section of the MP. Modest Genius ^talk 12:53, 29 April 2024 (UTC)

  All this does is make the present-tense rule less stringent so that it'd be easily overridden if needed. That's also what this new "rule" says. Aaron Liu (talk) 12:59, 29 April 2024 (UTC)

  ITN is part of the main page. Clovermoss🍀 (talk) 15:51, 29 April 2024 (UTC)

  I think what Modest is getting at is that "on the main page" is too general and may be misinterpreted to be about the entire main page. However, I don't think we should change the section header this far into the discussion either. Aaron Liu (talk) 15:52, 29 April 2024 (UTC)

Upgrade SCIRS to a guideline

Wikipedia:Identifying reliable sources (science) has been stable for years and is widely cited on article and user talk pages. It's in many ways similar to WP:MEDRS, which is a guideline. Isn't it time to bump SCIRS to guideline status too? – Joe (talk) 11:22, 11 April 2024 (UTC)

• I've left notifications about this proposal at the SCIRS talk page, WikiProject Science and WT:RS. Thryduulf (talk) 15:15, 11 April 2024 (UTC)

• I'm in general in favor of it, though it'll probably need some eyes going over it before going to guideline status, especially on cautions about using primary sources. Obviously a little more relaxed than WP:MEDRS, but not carte blanche use or outright encouraging primary sources either.

I have some guidance on my user page in the sourcing section that might be helpful there. In short, primary journal articles have their own mini-literature reviews in the intro and to some degree discussion/conclusions. When you are in a field that doesn't have many literature reviews, etc. those parts of sources can be very useful (e.g., entomology topics for me) for things like basic life cycle or species information. It's a good idea to avoid using a primary article for sourcing content on the findings of the study itself since it's not independent coverage though. That's not meant to be strict bright lines if it becomes guideline, but give guidance on how primary sources are best used if they are being used. If someone wants to use/tweak language from my page for updates, they'd be welcome to. KoA (talk) 16:20, 11 April 2024 (UTC)

I think we could say that in that circumstance, such as a paper is both a secondary source (in its discussion of other literature) and a primary source (in its results). I agree that the section on primary sources could be fleshed out, but I don't think it should be a blocker to giving it guideline status now (guidelines are never complete). – Joe (talk) 06:21, 12 April 2024 (UTC)

My thoughts exactly too in that it's an improvement that can be made independent of guideline or not. It would be a simple addition like you put, but it would also preempt concerns that sourcing would somehow be severely limited, which it functionally would not be.

If anything, much of what I mentioned here or at my userpage already addresses what has been brought up in a few opposes below. KoA (talk) 17:19, 12 April 2024 (UTC)

• Oppose. Maybe it's stable because we are free to ignore it. Maybe any useful advice in it is just what's already in other PAGs. Maybe we already have enough guidelines. WP:MEDRS was a bad idea too but at least had the excuse that dispensing bad health advice could cause legal problems; outdated cosmological theory has a somewhat smaller effect. Peter Gulutzan (talk) 17:51, 11 April 2024 (UTC)

• Support. This is necessary due to the huge and growing problem of the flood of unreliable research. As an engineer I edit scientific WP articles, and I waste an enormous amount of time dealing with noobs who come across some unsupported claim in a paper or sensationalist "science" website and are determined to put it in WP. And more time on pseudoscience advocates who dig up obscure papers that support their delusions. And more time on researchers trying to promote their careers by inserting cites to their own research papers in WP. In science today primary sources (research papers) are worthless, due to p-hacking the vast majority in even top journals are never confirmed. This needs to be reflected in our guidelines. --Chetvorno^TALK 20:51, 11 April 2024 (UTC)

• Support but... So unlike wp:ver & wp:rs (which require certain trappings and not actual reliability) we're going to require actual reliability for science articles? Requiring actual reliability puts it in conflict with wp:Ver and wp:RS.  :-) North8000 (talk) 21:06, 11 April 2024 (UTC)

  It's not my understanding that guidelines create "requirements", just offer best practices supported by consensus (WP:GUIDES). – Joe (talk) 06:09, 12 April 2024 (UTC)

• Support. Many longtime editors do not realize or refuse to acknowledge that primary sources should only ever comprise a small fraction of sourcing for an article. We also regularly have editors insisting various basic biology topics "aren't governed by MEDRS" because they don't have an immediate clinical relevance, and therefore the findings of primary research papers are acceptable. Having an actual guideline to point to that is more explicit on this would be helpful. JoelleJay (talk) 00:57, 12 April 2024 (UTC)

  This is also what I've found WP:SCIRS most useful for over the years. WP:PSTS is established policy, but it's not immediately obvious how to apply it to scientific topics without the extra guidance in WP:MEDRS or WP:SCIRS. We end up with sections that are just runs of "A 2017 study found, ..." then "A 2020 study found, ..." with no information on if any of those findings have achieved scientific consensus, because people see a journal article and assume that because it's reliable you can use it without qualification. WP:SCIRS clarifies which types of journal article are primary and which are secondary, and therefore how we should be using each type. – Joe (talk) 06:16, 12 April 2024 (UTC)

• Oppose Contra Joe Roe above, I think that Wikipedia:Identifying reliable sources (science) isn't an useful guidance on how to use primary vs secondary. In natural sciences, you tend to have articles that include a summary or review of existing science, followed by a paper's own conclusion - which by its very nature cannot say whether its findings have been widely accepted or not. That is, the same source is both primary and secondary, depending on which information you take from it. The essay isn't aware of this point. The problem with popular press isn't secondary/primary, either; rather that it tends to exaggerate and oversimplify i.e a reliability issue. Jo-Jo Eumerus (talk) 06:57, 12 April 2024 (UTC)

  We could just add that point? – Joe (talk) 07:06, 12 April 2024 (UTC)

  That would be a root-and-branch rewrite, as the idea of them being two separate kinds of sources is woven in its entire structure. In general, I think that WP:PSTS is a problem as it takes a concept mostly from history and tries to extrapolate it to other kinds of sources which often don't neatly map on it. Jo-Jo Eumerus (talk) 07:15, 12 April 2024 (UTC)

  If a primary source has a "summary or review of existing science", that existing science will be available in secondary sources, which are what we should use.--Chetvorno^TALK 07:36, 12 April 2024 (UTC)

  I don't see anything in WP:SCIRS or WP:PSTS that precludes a source being primary in some parts and secondary in others? WP:PSTS explicitly acknowledges that a source can be both primary and secondary at the same time: A source may be considered primary for one statement but secondary for a different one. Even a given source can contain both primary and secondary source material for one particular statement.. KoA observed the same thing above. It's a good point, and worth noting, but I think it can be easily achieved with an extra paragraph in WP:SCIRS#Basic advice, no rewrite needed. – Joe (talk) 08:26, 12 April 2024 (UTC)

  Only in well-covered fields. In less well covered ones like remote volcanoes, you often have one research paper that summarizes the existing knowledge before introducing its own point. But this guideline would apply to every field, not just the well-covered ones. ^It's not enough for the guideline to acknowledge the existence of "hybrid" sources; that's still assuming that most aren't hybrids and will mislead people into trying to incorrectly categorize sources. It's an undue weight issue, except with a guidance page rather than an article. Jo-Jo Eumerus (talk) 10:07, 12 April 2024 (UTC)

  I don't think I'm fully understanding you. A volcanology paper that summarizes the existing knowledge before introducing its own point is both a secondary source (in the first part) and a primary source (in the second part). How is this different from other fields? – Joe (talk) 10:20, 12 April 2024 (UTC)

  Sorry, that was addressing Chetvorno. Jo-Jo Eumerus (talk) 10:45, 12 April 2024 (UTC)

  I think the vast majority of people citing primary sources are citing them for their research findings, not their background sections. In the rare cases where they are citing the latter, if the material is contested on SCIRS/PSTS grounds then the editor can just point to where we say otherwise-primary sources can contain secondary info and say that's what they're citing. JoelleJay (talk) 16:18, 12 April 2024 (UTC)

  The trouble with the 'secondary' material in primary sources, is that the authors almost invariably spin it to align with their (primary) research conclusions. It should generally be avoided in favour of dedicated secondary sourcing. Bon courage (talk) 03:23, 16 April 2024 (UTC)

  I'm a bit short on time until next week, but I'd be willing to draft something based on my userpage (though a bit more flexible/advisory) if someone else doesn't get to it. KoA (talk) 17:29, 12 April 2024 (UTC)

• Oppose. <rant>The essay is an example of the primary vs secondary fetish that pollutes much of our policy. Actually there are very few things disallowed for primary sources that are not also disallowed for secondary sources. The rule should be "use the most reliable source you can find and refrain from original research". Instead, endless argument over whether something is primary or secondary replaces rather than informs discussion of actual reliability. So we get editors arguing that a newspaper report of a peer-reviewed journal article is better than the journal article itself, favoring the least reliable source for no good reason. Secondary reports of research are useful, for example they may contain interviews with experts other than the authors, but they are not more reliable than the original on what the research results were. Review articles are great, but rarely available. It is also not true that the existence of secondary reports helps to protect us from false/fake results; actually is the opposite because newspapers and magazines are more likely to report exceptional claims than ordinary claims.</rant> Zero^talk 10:28, 12 April 2024 (UTC)

  Well, it seems this is a common bugbear. Personally I've found the primary vs. secondary distinction very useful in doing exactly that, avoiding original research, but clearly others' mileage vary. Although it should be pointed out that, apart from discussing primary and secondary sources, WP:SCIRS strongly discourages using media coverage of scientific results (Wikipedia:Identifying_reliable_sources_(science)#Popular_press), so someone arguing that a newspaper report of a peer-reviewed journal article is better than the journal article itself would not find support in this essay.

  In any case, isn't the objection you and Jo-Jo Eumerus are articulating really against WP:PSTS, not WP:SCIRS? Not recognising a guideline because it fails to deviate from a policy would be... odd. – Joe (talk) 10:52, 12 April 2024 (UTC)

  If the policy is questionable, making a guideline that emphasizes the problematic aspects in a field where the problematic aspects are particularly problematic is making a problem worse. FWIW, while newspapers aren't my issue with SCIRS, I've certainly seen people claiming that news reports on a finding are secondary and thus to be preferred. Jo-Jo Eumerus (talk) 11:14, 12 April 2024 (UTC)

  And they cite SCIRS for that? It says the opposite. – Joe (talk) 12:21, 12 April 2024 (UTC)

  Joe, you are correct that my main beef is not with SCIRS. I haven't paid much attention to it, though I'd have to if it became a guideline. Mainly I severely dislike PSTS, which is full of nonsense, and I don't want more like it. Almost every word in the "primary source" section of PSTS is also the case for secondary sources. For example, "Do not analyze, evaluate, interpret, or synthesize material found in a primary source yourself" — since when are we allowed to do any of those things to a secondary source? And the only good thing about rule #3 is that it is largely ignored (unless "any educated person" knows mathematics, organic chemistry and Japanese). I could go on....I've been arguing this case for about 20 years so I don't expect to get anywhere. Zero^talk 14:32, 12 April 2024 (UTC)

  Zero0000 re: "...newspapers and magazines are more likely to report exceptional claims than ordinary claims". That is a different problem: what constitutes a reliable secondary source for a given field. SCIRS says: "Although popular-press news articles and press releases may tout the latest experiments, they often exaggerate or speak of 'revolutionary' results" So for scientific topics general newspapers and newsmagazines should not be considered reliable sources on a par with scientific journal reviews. WP:PSTS does not mention this issue; another reason SCIRS should be a guideline. --Chetvorno^TALK 23:32, 14 April 2024 (UTC)

• Oppose. Upgrading the "Identifying Reliable Sources (Science)" (SCIRS) to guideline status risks imposing unnecessary rigidity on topics that straddle the science and non-science boundary, and I believe that WP:MEDRS needs to be downgraded to an essay due to its frequent misapplication to part-biomedical topics, sometimes even in bad faith. As an essay, SCIRS provides useful advice without enforcing a strict approach that may not be suitable for all topics. By making it a guideline, we risk encouraging an overly simplistic distinction between primary and secondary sources, which may not always reflect the complexities and nuances of scientific inquiry, especially in interdisciplinary fields, or in burgeoning areas of research where established secondary sources may not yet exist. Furthermore, this rigidity could be abused, potentially serving as a gatekeeping tool rather than as a guide, particularly in contentious areas that intersect science with social or political dimensions, as seen with MEDRS in various topics. Maintaining the current flexibility that allows for context-sensitive application of source reliability is essential to ensure that Wikipedia continues to be a diverse and adaptable repository of knowledge. FailedMusician (talk) 23:42, 12 April 2024 (UTC)

  We already have flexibility in assessing secondary vs primary coverage within a source, per PSTS. Can you link some examples of MEDRS being misapplied? And if a topic has no secondary coverage at all, whether in review articles/books or in background sections of primary research papers, it certainly should not have its own article and likely isn't BALASP anywhere else either. JoelleJay (talk) 00:48, 13 April 2024 (UTC)

  I believe you are aware of cases where MEDRS has been misapplied. There are instances where primary sources, extensively covered in mainstream media, are challenged by misconstrued higher-quality sources, often to remove contentious content or editors. Introducing a new policy for scientific sources could further stratify our community, complicating contributions and inhibiting constructive dialogue. FailedMusician (talk) 10:14, 13 April 2024 (UTC)

  Where are these cases and why would you think I was aware of them? We haven't edited any of the same mainspace or talk pages or the same topics of any wikipedia- or user-space pages, so I don't know how you would get that impression. The only time I've seen editors claiming primary biomed sources need to be pushed into articles is in support of fringe views like the lab leak conspiracies. JoelleJay (talk) 01:58, 15 April 2024 (UTC)

  Scientific topics often cross multiple disciplines or emerge in fields where extensive secondary sources are scarce. Elevating SCIRS from an essay to a formal guideline could inadvertently restrict the integration of innovative or complex scientific information, making source verification a restrictive rather than supportive process, like in the example you cite. FailedMusician (talk) 23:34, 15 April 2024 (UTC)

  Other disciplines also need secondary sources to comply with NPOV and OR, so I don't see how SCIRS would affect such content negatively. Can you link some examples of disciplines where secondary sources are scarce but which still have DUE content? The example I cite is evidence in support of SCIRS as it would discourage use of unvalidated, potentially fringe research findings outside of medicine. JoelleJay (talk) 00:47, 16 April 2024 (UTC)

• Oppose. Large parts of SCIRS are copy-pasted from (an old version of) WP:MEDRS, but with some words changed. There may be a place for a SCIRS but it would need to be more specific and content-appropriate than this. Bon courage (talk) 03:08, 16 April 2024 (UTC)
• Could support if retitled. I find SCIRS is very useful. In my experience, when articles or sections are rewritten to use mostly SCIRS sources, they get considerably better. I've thought of proposing that this be retitled to "Identifying 'high-quality reliable sources (science)" and then made a guideline. With its current title, I have two concerns. One is the large grey area around what “science” is, which would need to be clarified. Another is the exclusion of factual encyclopedic content that is too new or too obscure to have been covered in secondary sources. Here’s a simple example from Orca: “A 2024 study supported the elevation of Eastern North American resident and transient orcas as distinct species, O. ater and O. rectipinnus respectively.”

I’m very concerned that a guideline would be used to revert any and all additions of content that “fails SCIRS” which is highly discouraging to newbies and would result in the rejection of a lot of good information along with bad.

The value of SCIRS sources is that they indicate the level of acceptance that claims have in the science community. This is useful for assessing controversial claims and for filtering out noise in fields where there are a lot of early-stage technologies clamoring for attention. Secondary sources are invaluable for ensuring NPOV in broad and/or controversial areas. However, I have never bought into the idea that secondary sources are essential for ensuring NOR in the sciences. A primary source in history is by definition written by a non-historian and requires a researcher to interpret it. A primary source in science is usually written by a scientist and summarizing it is not original research. Clayoquot (talk | contribs) 04:24, 16 April 2024 (UTC)

Yeah, but deciding a piece of primary research is worthy of encyclopedic content (i.e. is 'accepted knowledge') is OR. Primary research is really an interchange among researchers, and much of it is faulty/wrong/fraudulent. Wikipedia editors are in no position to pick and chose what's good and what's not. Bon courage (talk) 04:29, 16 April 2024 (UTC)

Clayoquot makes an important point about the uncertainty over what is the "science" as that can be exploited by advocates of certain issues to misrepresent emerging or part scientific topics as being on the fringe. This can impact the reliability and representation of such topics on Wikipedia, potentially either overstating or undervaluing their scientific validity. Therefore, clear guidelines are crucial to prevent the misuse of these definitions. FailedMusician (talk) 07:36, 16 April 2024 (UTC)

WP:FRINGE doesn't just apply to "science", however it is defined. In the humanities the secondary/primary considerations are completely different in any case (you don't get a systematic review of who wrote the works of Shakespeare!). Bon courage (talk) 07:43, 16 April 2024 (UTC)

How scientific aspects of topics are defined is important, especially in the face of editors engaging in strong advocacy on issues, and worse. That's why we need to exercise caution here. FailedMusician (talk) 09:56, 16 April 2024 (UTC)

FYI, SCIRS already addresses the scope in the lead The scope of this page includes the natural, social and formal sciences.

As for something being too obscure, that would indicate a WP:WEIGHT issue with inclusion. If it's too new, weight issues come into play too. For MEDRS topics, that means waiting to see if sources indicate the results are due to include or not, and that's worked well in practice. We don't have a WP:CRYSTAL ball to decide what new or late-breaking news (i.e., WP:RECENTISM) should be included. Generally our WP:PAG have us being behind the ball on new information like that. WP:NOTJOURNAL policy comes into play here too where an encyclopedia is not where we have essentially recent news on primary research like us scientists are used to writing in real life.

Point is, a lot of things being brought up are things we are supposed to be avoiding in existing policy/guideline. SCIRS is just explaining why (or intended to) and how to navigate that with relative flexibility compared to something like MEDRS. KoA (talk) 21:56, 16 April 2024 (UTC)

• Oppose: Like @Clayoquot, I am an active contributor to WikiProject Climate change, and I can say with confidence that certain scientific subjects, such as, in fact, climate change, are so fast-moving that an application of this policy would cripple most of our articles on this topic. Even the primary peer-reviewed papers are, by necessity, several years behind the real-world processes due to the time it takes to first analyze the climate data, and then to get the paper through peer review. To give an example I have had to deal with recently - a research paper (i.e. a primary source) on trends in oceanic carbon storage published in August 2023 was only able to cover trends up to 2014! Yet, if SCIRS were to become a guideline, we would need to exclude it and rely on even older data!

As @Bon courage points out, much of SCIRS stems off MEDRS. Primary research in climate science is in a very different position to primary medical research. It's one thing to p-hack an observational study among a few dozen patients. It's quite another when you have to reserve months of computing time from room-scale supercomputers (lead image here shows what a typical climate model looks like nowadays, for reference) - often multiple ones in different research institutions across the world - in order to be in a position to even test your hypothesis in the first place. Likewise when your primary research involves field work like sending robotic submarines underneath glaciers.

It is actually a lot easier to write a review in climate science if you don't mind about the journal which would accept it - and the current guideline text has very little to say about differences between journals, even ones as obvious as those between Nature and Science vs. MDPI and Frontiers. As best as I can tell, this notorious piece from MDPI would be accepted for inclusion due to being a secondary source, while a paper in Nature like this one would be rejected, if going off SCIRS as currently written. Even if this were amended, a lot of primary climate research is unlikely to make it into reviews for reasons that have nothing to do with reliability. I.e. it's not really realistic to expect that scientific reviews, or even the ~4000-page IPCC reports (published in 7-year intervals) would include every good paper about climate impact on every species that could be studied, or about every geographic locale. For lesser-known species/areas in particular, it would often be primary research or nothing.

Finally, I can only assume that if this guideline were to be applied consistently, then graphics taken from primary sources would be affected as well, wouldn't they? That would be a disaster for so many of our articles, which would stand to lose dozens of illustrations. This is because only a handful of reliable climate journals use the licensing compatible with Wikipedia terms, and those overwhelmingly publish primary research. Secondary scientific reviews tend to either lack suitable illustrations in the first place, or to have incompatible licensing (i.e. the graphics in the IPCC reports). The precious exceptions are nowhere near enough. InformationToKnowledge (talk) 10:54, 16 April 2024 (UTC)

As someone who works in the climate change research realm IRL, this doesn't seem like a very accurate description of the literature in terms of how SCIRS would work in practice. If a late-breaking primary study is important and worth mentioning on Wikipedia, other papers will cite it, even primary ones, and establish due weight for us as well as give us a summary we could use. Climate change is one of the more well published fields, so that won't really be a problem. Even in my main area of entomology, there's a lot of variation, but even the "slower" fields really wouldn't have issues with this. SCIRS is not the same as MEDRS, though like I mentioned above, the essay would benefit from some tightening up I hope to do soon that would make it redundantly clear. At least the intent behind SCIRS really isn't being reflected in the oppose !votes so far, so there's a disconnect somewhere. KoA (talk) 18:15, 16 April 2024 (UTC)

If the intent behind a policy/guideline/essay isn't being reflected in people's comments about it then it's likely that the intent isn't being well communicated, which is an argument against formalising it. Thryduulf (talk) 19:14, 16 April 2024 (UTC)

That's a part of it I mentioned early on where some reworks are likely needed. The other concern I have of that coin is that people are assuming things about MEDRS and applying that to SCIRS rather than focusing on specific parts of what SCIRS actually does say. There's a point where an ungrounded oppose really isn't even opposition to SCIRS.

I was getting a hint of the latter in ITK's comment where they said Yet, if SCIRS were to become a guideline, we would need to exclude it and rely on even older data! in reference to this primary source. Nothing is mentioned about SCIRS specifically there that's at issue though. Normally you'd want to stay away from the results section of such a paper outside of very limited use, but in the absence of full secondary publications, using the introduction there absolutely would not be a problem in a limited fashion. I also see at least 15 papers citing it if you wanted to include WP:DUE information about the results of that paper. There's a lot of flexibility in terms of what SCIRS says right now for that example, so that's why I'm asking for specifics to see where the disconnect is.

I'm personally more interested in fine-tuning SCIRS than guideline promotion right now, so I'm trying to sort out what concrete concerns there may be (that could potentially be worked on) versus assumption. If there's something specifically in SCIRS that's at issue, this would be the place to iron that out, so I'd ask folks to point out specifics in SCIRS. If it's something someone thinks is in SCIRS but isn't, then I don't know what to say. When I see some comments here that basically amount to saying they wouldn't be allowed to do what SCIRS specifically gives guidance on and allows, I have to wonder if it was something they skimmed over, something that needs to be outlined better, etc. rather than jumping to a more extreme conclusion that someone didn't really read SCIRS. Tl;dr, I'd like to see specifics to work on. KoA (talk) 21:39, 16 April 2024 (UTC)

At least the intent behind SCIRS really isn't being reflected in the oppose !votes so far, so there's a disconnect somewhere. - Well, nobody reasonable opposes the intent to make scientific citations more reliable. That does not indicate agreement with the methods used to get there.

There's a lot of flexibility in terms of what SCIRS says right now for that example, so that's why I'm asking for specifics to see where the disconnect is.

Well, here's an example. I also see at least 15 papers citing it if you wanted to include WP:DUE information about the results of that paper. - Firstly, the paper, which I'll link to again only has 5 citations according to CrossRef, which is directly integrated into the journal page itself. Needless to say, SCIRS most definitely does not say anywhere "You should choose Google Scholar over the papers' own preferred citation tools when it comes to assessing notability."

Secondly, there is absolutely nothing in the current text of SCIRS which suggests that ~15 citations is the magic number which would satisfy the "widely cited" part of In general, scientific information in Wikipedia articles should be based on published, reliable secondary sources, or on widely cited tertiary and primary sources. It is left wholly ambiguous what "widely cited" should mean. Who says it's not 30 citations or 50, or perhaps even more? (Papers on certain subjects in climate science can hit such numbers very quickly - here is a research paper which got to 604 citations in less than two years, for example).

At the same time, I think that even if SCIRS did codify the recommended number of citations + the recommended citation tool, that would not be much of a step forward on its own. You may say that SCIRS would allow that AGU Advances paper, for instance, but you seem to concede my other example: As best as I can tell, this notorious piece from MDPI would be accepted for inclusion due to being a secondary source, while a paper in Nature like this one would be rejected, if going off SCIRS as currently written. I don't think it's good practice to effectively say we know better than the editors of Nature flagship journal and effectively impose a freeze on citing their latest research (which, in this case, operates with decades of data and has very important implications for a range of ecosystems) until an arbitrary number of other publishing researchers end up citing it as well.

I'll give one more example of personal relevance for me. This January, I have put a lot of work into cleaning up and generally expanding the Southern Ocean overturning circulation article. It is still far from perfect, but I hope nobody will object to the idea that it is now MUCH better than what it used to be. Yet, the research on ocean circulation is overwhelmingly focused on the Northern Hemisphere, particularly on the AMOC (also rewritten by yours truly the other week, for that matter.) There has been a drought of research on this southern counterpart to AMOC until very, very recently (literally the last couple of years), and the research which is now coming out still has a (relative) difficulty getting cited, because again, AMOC is a much "sexier" research topic. I have a concern that a not-inconsiderable number of papers I used for that article would be considered "insufficiently cited" if the current text of SCIRS were elevated to guideline status, and I really struggle to see how excluding them, even temporarily (but potentially for years) would improve that article.

If I were to name one modification to SCIRS I would want to see the most, it would be de-emphasizing the number of citations of individual papers and emphasizing CiteScore/Impact Factor of the journals which published them. For the flagship journals with absolute highest Impact factors, I don't think any number of citations should be demanded. In contrast, the number of required citations would scale as the impact factor/journal reliability decreases: I might well oppose citing anything from MDPI/Frontiers that has not hit ~50 citations in general and/or a citation in something like an IPCC report or a flagship journal publication. InformationToKnowledge (talk) 23:12, 16 April 2024 (UTC)

I interpreted I also see at least 15 papers citing it if you wanted to include WP:DUE information about the results of that paper as a suggestion to use those citations' descriptions of the paper's results, as those would be secondary. JoelleJay (talk) 16:14, 17 April 2024 (UTC)

Correct, the whole point was that there were plenty of citing papers to potentially use as a secondary sourced content about that example study. Following citations is almost exactly what we do in MEDRS topics too looking for papers that cite a primary research article if someone initially wanted to try to add it, except there we're limited to full secondary sources like lit. reviews or meta-analyses. For a SCIRS topic though, it's much more relaxed. This is illustrating some of my caution I just mentioned about reading what's actually in SCIRS because I'm not aware of anything about citation counts, and that's rightfully left out of both this and MEDRS. As far as I'm aware, only WP:NPROF does anything like that, which isn't without controversy. KoA (talk) 21:34, 17 April 2024 (UTC)

This is illustrating some of my caution I just mentioned about reading what's actually in SCIRS - Have you considered that maybe SCIRS is just poorly written? Reams and reams of passive-voice text, often chock-full of equivocations and qualifiers, and frequently packed into 8-12 line paragraphs that make it hard to pick out the important from the self-explanatory at a glance. SCIRS makes the actual literature reviews look positively exciting and easy-to-read.

Correct, the whole point was that there were plenty of citing papers to potentially use as a secondary sourced content about that example study. Following citations is almost exactly what we do in MEDRS topics too looking for papers that cite a primary research article if someone initially wanted to try to add it, except there we're limited to full secondary sources like lit. reviews or meta-analyses.

So...how do you functionally tell apart an otherwise primary source being used a secondary source for another primary source... from simply a primary source being used as a primary source, when you are an editor reviewing another's edit? This idea seems to fall apart if you think about it for a minute.

In fact, after taking a second look...

what we do in MEDRS topics too looking for papers that cite a primary research article if someone initially wanted to try to add it

So, if applied wiki-wide, that would seem to translate to baby-sitting every single attempt to add a primary paper reference and demand either proof it's an indirect citation for something else or a citation hunt to cite that paper indirectly? All while we still have enormous issues with both unreferenced passages and those relying on deeply obsolete references? That would seem to be incredibly counterproductive.

I'm going to concur with a quote from Peter Gulutzan up above: WP:MEDRS was a bad idea too but at least had the excuse that dispensing bad health advice could cause legal problems I don't see the justification for this additional, stifling layer of Wikibureaucracy where that risk does not exist, and where there is a much greater chance of important context being lost in translation from a full study to a citing sentence. InformationToKnowledge (talk) 04:10, 18 April 2024 (UTC)

So...how do you functionally tell apart an otherwise primary source being used a secondary source for another primary source... Well, you go look at the source of course. That's normally what most of us editors do when we're reviewing any article. If someone isn't checking sources when they make a citation or are verifying content, that's a problem in terms of existing WP:PAG, which is what we based WP:CONSENSUS on. KoA (talk) 04:38, 23 April 2024 (UTC)

@InformationToKnowledge, I appreciate you looking at the practical side here. You might be interested in readhing WP:PRIMARYINPART.

In the MEDRS context, it's usually pretty easy to tell when a primary source (e.g., a journal article whose primary purpose is to report the results of a randomized controlled trial) is being used as a secondary source. The first thing to look for is whether the content comes from an "introduction" or "background" section. Those sections take information from previously published sources, and are selected and combined to present a new(ish) way of looking at the information. So that part of the paper is usually secondary, and the thing for editors to remember is that "Secondary" does not mean "good". Even though there are secondary, they can be somewhat biased (the authors present only the background information that is relevant to or supportive of their specific research, rather than trying to write an unbiased and comprehensive overview – for example, the surgeons only talk about surgery, the drug companies only talk about drugs, etc.). WhatamIdoing (talk) 17:51, 23 April 2024 (UTC)

I interpreted "I also see at least 15 papers citing it if you wanted to include WP:DUE information about the results of that paper" as a suggestion to use those citations' descriptions of the paper's results, as those would be secondary.

I have already written my objections to this idea in the other reply, but I decided I might as well humour this suggestion and see where it takes us. I'll begin with the 5 citations you actually see on the journal page itself, since people will almost certainly do that first, and pull up Google Scholar second (if ever).

Citation 1: Shares some of the same authors - according to the current SCIRS text, that seems to be allowed? (Unless I missed a line tucked away within one of those huge paragraphs which accounts for that.) If it is, that kinda makes one wonder what the purpose of this whole rigmarole is, if the researchers citing their previous work somehow immediately makes it more reliable. Anyway, it cites the study in question (Müller et al., 2023) four times:

Currently, the global ocean takes up 25%–30% of all human-made CO2 emissions (DeVries, 2014; Friedlingstein et al., 2022; Gruber, Clement, et al., 2019; Gruber et al., 2023; Khatiwala et al., 2009; Müller et al., 2023; Terhaar et al., 2022)

Although they contain data from similar GOBMs and pCO2 products, the compiled database of RECCAP2 (Müller, 2023) goes well beyond that used in the framework of the Global Carbon Budget (Friedlingstein et al., 2022).

The RECCAP2 database (Müller, 2023) provides model output from 1980 to 2018 from four simulations (called simulations A, B, C and D) that aim to quantify the different components of the oceanic CO2 flux. (A bunch of equations follows.)

To compare the net sea-air CO2 fluxes from the GOBMs with observation-based estimates, we utilize the RECCAP2 data set of pCO2 products (Müller, 2023), including AOML_EXTRAT, CMEMS-LSCE-FFNN, CSIR-ML6, JenaMLS, JMA-MLR, MPI-SOMFFN, OceanSODA-ETHZ, UOEX_Wat20, and NIES-MLR3 (see Supplementary Table 2 in DeVries et al. (2023) for references and further details).

Citation 2

Multiple lines of observation-based evidence support climate-change effects on the ocean carbon sink (Keppler et al., 2023; Mignot et al., 2022; Müller et al., 2023)

It is unambiguous that the ocean carbon sink has increased over recent decades in line with increasing atmospheric CO2 levels as its primary driver (Ballantyne et al., 2012; DeVries et al., 2023; Gruber et al., 2023; Müller et al., 2023).

Citation 3

This finding agrees with previous studies that find an important role for Pinatubo in preindustrial carbon variability (Eddebbar et al., 2019; Fay et al., 2023; McKinley et al., 2020), and gives us additional confidence that observation-based estimates of changing anthropogenic carbon distribution (e.g., Gruber et al., 2019; Müller et al., 2023); (also Müller, Jens Daniel, Gruber, Nicolas, Carter, Brendan R., Feely et al., Decadal Trends in the Oceanic Storage of Anthropogenic Carbon from 1994 to 2014, in preparation for Authorea) are relatively unaffected by the Pinatubo climate perturbation.

Citation 4 (also involves some of the same authors as the original study)

How is the ocean carbon cycle changing as a consequence of sustained increases in emissions of carbon to the atmosphere? Important steps toward answering this question over the last several decades have been provided via estimates of ocean carbon uptake from both interior hydrographic measurements (Gruber et al., 2019; Müller et al., 2023; Sabine et al., 2004),...

For all of the oceanic studies within RECCAP2, a discrete number of ocean biomes based on Fay and McKinley (2014) are used to facilitate consistent intercomparison between regions (described in the supplement to the Müller (2023) publication of the RECCAP2 data).

Thus, our six aggregated biomes (Table 1 and Figure 1) (their precise boundaries given in Supporting Information S1 of the RECCAP2 data release of Müller, 2023) consist of

Citation 5 (also involves some of the same authors as the original study)

A recent update of the eMLR(C*) results by Müller et al. (2023) resolves decadal trends in the anthropogenic carbon accumulation from 1994 to 2014, but was published after the completion of this study and could thus not be considered here.

Nevertheless, a recent update of the eMLR-C* estimates by Müller et al. (2023) also suggests substantial climate-driven variability in the oceanic storage of anthropogenic carbon similar to that shown in Figure 7f.

None of these citations mention the finding of the original study where carbon storage in the North Atlantic specifically had declined by 20% (at most, you can kinda sorta see a decline in Figure 1 of Citation 4, but you can't really get the specific percentage from there), which is the whole reason why I cited that study in the first place. For that matter, the additional citations from Google Scholar (some of which are either preprints or paywalled) do not do that either. So, if SCIRS were to become a guideline, that specific finding, which, lest we forget, was derived from

the JGOFS/WOCE global CO2 survey conducted in the 1980s and 1990s (Key et al., 2004; Wallace, 1995), the repeat hydrography program GO-SHIP that began in 2003 and is now completing its second cycle (Sloyan et al., 2019; Talley et al., 2016), as well as a number of additional programs, including INDIGO, SAVE, TTO, JOIS, and GEOSECS (Key et al., 2004, and references therein).

Would somehow become too unreliable for inclusion in a Wikipedia article, purely because no other article felt the need mention this particular detail yet, even as they cited the study itself? REALLY?

So, I once again don't understand what this is meant to achieve. If poorly reviewed papers attempting to overturn academic consensus are supposedly the problem, then an Impact Factor bar set at the right level would efficiently block basically all of them without forcing this onerous rigmarole whenever attempting to cite valuable research findings. InformationToKnowledge (talk) 05:16, 18 April 2024 (UTC)

The idea that prestigious journals are more likely to be correct is debatable. See The Economist which explains that there's a winner's curse effect. Prestigious journals like Nature have the most choice and and may publish the papers which are most sensational rather than those which are most accurate. Andrew🐉(talk) 07:57, 19 April 2024 (UTC)

If no academic sources are discussing that particular finding, then neither should Wikipedia. If it's not relevant enough to be mentioned in other studies then it's certainly not at the level of accepted knowledge we need in an encyclopedia. JoelleJay (talk) 08:22, 19 April 2024 (UTC)

I'll echo that too. If someone is opposed to a potential guideline because it won't let them add something that all signs are pointing to not currently being WP:DUE, that's not a good reason to oppose a guideline.

I'm seeing a lot of potential introductions to pull from in general in that little exercise above though. KoA (talk) 04:58, 23 April 2024 (UTC)

The only reason that finding wasn't "due" in those citations is because all those citations to date were focused on the entire World Ocean, so citing certain text about a specific ocean region certainly wasn't relevant in the context of their research - as opposed to our wiki pages on the North Atlantic region or the Atlantic meridional overturning circulation specifically.

The idea that how often a certain paper is cited in general (let alone the general reputation of its publisher and/or research team) does not matter, and specific findings only "become" reliable once another paper happens to have enough overlap with a certain topic to cite not just the paper as a whole, but that specific phrase, is unintuitive and counterproductive and is likely to remain so.

I am still not seeing a good reason for why a combination of (independent) citation count and journal metrics like Impact factor would not be a better alternative for assessing WP:DUE than this proposal. The only counterargument I have seen so far is "big journals make mistakes too" - which is easily countered by how often papers, particularly at bad journals, can be found to mangle their citations, saying something subtly yet significantly different from the original text. At least, when the major journals screw up, it is reasonably likely that there would be pushback in WP:RS, which we can then mention to place the work in context. In fact, it is many times more likely than to see criticism of bad referencing post-publication, so I remain unconvinced this suggestion adds, rather than removes, reliability. InformationToKnowledge (talk) 14:00, 23 April 2024 (UTC)

How would your proposed citation+prestige system work for a paper like the MMR fraud perpetrated by Andrew Wakefield? I'd think it would rate quite highly, even though nearly all of the sources citing it have done so to say that it's a disgraceful fraud. WhatamIdoing (talk) 17:56, 23 April 2024 (UTC)

I don't think that is a very relevant example, for several reasons.

1. That paper had been thankfully retracted for a while.
2. Even if it were hypothetically published now, it would be covered by MEDRS, no? (Almost) nobody here is proposing to overturn MEDRS, so can we stick to non-medical examples?
3. I already wrote the following: At least, when the major journals screw up, it is reasonably likely that there would be pushback in WP:RS, which we can then mention to place the work in context. That would be my preferred approach.

In fact, I'll give a fairly recent example where I have had to make a decision on a similar subject. In July, a paper on the Atlantic meridional overturning circulation came out in the reasonably respected Nature Communications, and made a dramatic claim that the AMOC is likely to collapse in the very near future. It predictably received a lot of coverage (here is one of the more breathless examples), yet many experts were highly critical. The paper was already cited in the article by another editor, and I chose to keep its mention, yet also feature some of the most comprehensive criticism.

Now, would the article have been better off by completely ignoring a publication which had been seen nearly half a million times on its own and whose results were reported in almost 1,000 news articles to date (i.e. to tens of millions more readers), mostly uncritically? I really do not think so: and the fact that one of the paper's two authors ended up attempting to personally whitewash the coverage of the paper in the article (and receiving a topic ban for it) suggests that this decision mattered, and was the right approach to take. InformationToKnowledge (talk) 14:53, 26 April 2024 (UTC)

InformationToKnowledge raises crucial points about the practical implications of applying SCIRS as a guideline to rapidly evolving fields like climate science, especially for non-controversial facts. The concern about excluding valuable primary research due to the proposed guidelines' stringent requirements is well-founded, especially when considering the time lag in publishing comprehensive secondary sources in such dynamic areas. This emphasizes the need for SCIRS to accommodate the unique challenges of different scientific disciplines, ensuring that Wikipedia remains an up-to-date and reliable resource without unnecessarily excluding relevant and recent research findings, observations and commentary. FailedMusician (talk) 01:35, 23 April 2024 (UTC)

I think we're looking at two different problems:

• Primary vs secondary sources: Secondary is not another way to spell "good", and primary is not a fancy way to spell "bad". A source can be primary and be a good source. Whether it's a good source depends partly on the source itself (e.g., is it self-published?), but it also depends significantly on the WP:RSCONTEXT. For example, editors will probably want a secondary source for a statement like "Wonderpam cures _____", but a primary source might be accepted for a statement like "Wonderpam was the first drug in its class" or "Wonderpam has a shorter shelf life than other treatments".
• Strong vs weak sources: Sources need to be strong enough to bear the weight of the claim they're being cited for. Wikipedia:Extraordinary claims require extraordinary evidence. Lightweight claims don't. If a claim is truly non-controversial, then we don't really need a strong source at the end of the sentence. For example, MEDRS accepts WebMD for non-controversial content. It's a secondary source, but it's not a strong source.

The more controversial the claim, the better the source(s) we should be citing. WhatamIdoing (talk) 18:15, 23 April 2024 (UTC)

Honestly FailedMusician, I've read your statement several times now but I can't quite understand what you're trying to say here. I'm sorry if I'm missing something. Are you just repeating what InformationToKnowledge said, but in your own words, so to speak? Again, sorry if I missed something obvious. Alpha3031 (t • c) 14:44, 26 April 2024 (UTC)

Yes. FailedMusician (talk) 15:27, 26 April 2024 (UTC)

• Oppose per WP:CREEP. There's no simple algorithm for determining The Truth and complex advice tends to be so equivocal that it is no help and just results in endless Wikilawyering. Andrew🐉(talk) 08:04, 18 April 2024 (UTC)
• I feel like the various subject-specific RS essays are more in-line with supplement, but I'm not sure it would make much of a difference either way. Alpha3031 (t • c) 13:55, 18 April 2024 (UTC)
• Oppose; people have given a pretty broad range of rationales for opposing this, so not sure that I can contribute a lot. But one thing I will note is that the most recent extremely-high-profile back office brouhaha we had about WP:MEDRS and WP:BIOMED (to wit the giant years-long covid slapfight) did not convince me that having a bunch of additional rules for what sourcing guidelines to use and when to apply them would make it easier to deal with conflict. jp×g🗯️ 06:45, 19 April 2024 (UTC)
• Regardless of which tags end up at the top of the page, I'd like to see the Wikipedia:Identifying reliable sources (science)#Formatting citations section deleted as redundant to Wikipedia:Citing sources. WhatamIdoing (talk) 01:29, 20 April 2024 (UTC)
• Provisionally oppose upgrade, but not use as an essay for now This guideline lacks references to support the claims that it makes. (I accept that WP:V does not necessarily allow me to delete all unreferenced content in the project namespace, but that does not mean that I have to agree to making it a guideline). It tells us to prefer peer-reviewed sources, despite the fact that this is apparently not completely uncontroversial: [10] [11] [12] [13] and all the other sources that come up on a search for "peer review flawed process" and Scholarly peer review#Criticism. It fails to answer the apparent controversy. It fails to consider whether the purpose of peer reviewing is to determine accuracy (which is relevant to reliability) or to determine importance/originality etc (which is not relevant to reliability). (I am under the impression that scientific "proof" consists of being able to reproduce the results of an experiment by repeating it over and over again, and the peer reviewer is presumably not doing this). We are told to use textbooks. I was once told that the average physics textbook is two years out of date the moment it reaches book shops, and that you cannot do physics properly without reading papers. (You'll have to take my word for this for now, as I don't have time to verify it.) James500 (talk) 09:20, 21 April 2024 (UTC)

  I'm among those scientists that think the peer review system is broken and should be thrown out, but that's a red herring here. Peer review is currently the universally-accepted quality control mechanism in academia. There is debate other whether it should continue to be so, but until then tertiary sources like Wikipedia have to rely on peer reviewed literature, because there is simply no alternative.

  With textbooks, Wikipedia is supposed to be at least two years out of date, because our goal is to document and explain major points of view. New research does not become a "major point of view" in science in the first few years after it is published, because the scientific community needs time to assess the arguments and the evidence. In other words, it is impossible to summarise cutting-edge research without falling afoul of WP:SYNTH. We can give readers a summary of accepted knowledge; they should go elsewhere to learn about current debates or the state of the art. – Joe (talk) 09:30, 21 April 2024 (UTC)

  (Answering both James and Joe) Though there are many problems with peer-review, it is correct to treat it as the best process we have because it really is the best process we have. If some better system takes over, we'll adopt that as the gold standard instead. Peer review is about both accuracy and importance, but the degree to which it can address accuracy depends on the field of study. It's true that reviewers are not expected to repeat experiments, but they are supposed to look for flaws in the experimental protocol, check that competing theories are adequately cited, and they are supposed to insist that enough details are given that others can repeat the experiment. In theoretical fields like mine, reviewers are supposed to check calculations, but they are not expected to repeat computer calculations. I strongly disagree that we can't describe recent publications without violating SYNTH. All that's needed is to present the results as a theory proposed by a named person, without making our own judgement of its validity. The only real problem is deciding which of the thousands of new publications to cover, but that's a NOTABILITY problem not a SYNTH problem. I'm sure that many readers visit Wikipedia looking for accessible explanations of new scientific ideas that they saw in the press or somewhere and I believe that one of our roles is to provide them. Incidentally, lots of important science never appears in textbooks and research monographs about them can take much longer than two years to appear. Zero^talk 14:04, 21 April 2024 (UTC)

  You've said it yourself: the problem is selecting which primary findings should be covered. Call it SYNTH or call it OR or call it notability (though that seems a stretch?) – it's a problem. If we don't retain an emphasis on secondary over primary sources, how do you propose that we identify which new papers are "important science" and which are garbage that somehow sneaked through peer reviewer but will be forgotten about in a year, without engaging in original research? – Joe (talk) 15:15, 21 April 2024 (UTC)

  It's absolutely a problem of BALASP and SYNTH to cover the results of primary papers using those papers as sources. If the wider academic community hasn't contextualized it with the existing mainstream consensus, through reviews or at the very least summaries in the background of other, independent, primary research articles, then it does not belong on wikipedia. JoelleJay (talk) 19:00, 21 April 2024 (UTC)

  I don't know how you can match this situation to the definition of SYNTH. There isn't anything necessarily SYNTH about it. We can judge notability by the usual way we judge notability: by the attention something gets in "reliable sources". Arguments about the notability of particular cases will happen but that's true across all fields, not just in science. I'm not saying that we should pick journal articles that are citation orphans and make articles out of them, but once a journal article makes a "splash" we are free to cite it. The suggestion that Wikipedia must be endlessly years out of date is horrifying and definitely was not the intention when the rules were written. Zero^talk 07:04, 22 April 2024 (UTC)

  This is completely unrelated to notability. The problem with covering splashy new science results is that it is not possible to summarize what the scientific community's assessment of them is in relation to the existing understanding of the topic. We are therefore synthesizing its relevance to the topic when we describe it in an article based only on its primary report.
  And we don't necessarily have to be years out of date, but WP definitely is intended to operate as an encyclopedia summarizing accepted knowledge, not as a EurekAlert stand-in. JoelleJay (talk) 17:33, 22 April 2024 (UTC)

  The way to avoid summarizing "what the scientific community's assessment of them is in relation to the existing understanding of the topic" when we have no reliable sources for that assessment is to not do it. To avoid SYNTH, don't violate SYNTH. You have not given a reason why citing a recent publication is necessarily SYNTH. Zero^talk 01:31, 23 April 2024 (UTC)

  You would be engaging in original research as an anonymous editor. In the real world, you generally need a degree in a semi-related field and familiarity with research statistics to interpret the validity of results in the study. None of us are qualified to do that as anonymous editors, even those of us who do have credentials in specific fields IRL. That's what makes using primary research so different here than if you are writing your own summary for work in a research lab. KoA (talk) 04:47, 23 April 2024 (UTC)

  The same argument could be used to eliminate all articles on technical subjects even if all the sources are secondary. Do you think an average editor can understand a graduate textbook in differential geometry or quantum mechanics? The only reason we have many excellent articles on scientific subjects is that we have editors who can understand the sources. You are actually criticising something that nobody has proposed. The role of an editor is to summarise what the researchers (and experts other than the original authors) say about it, not to "interpret the validity" of it. Zero^talk 09:40, 23 April 2024 (UTC)

  The role of an editor is to summarise what the researchers (and experts other than the original authors) say about it, not to "interpret the validity" of it. Exactly. IRL, you are assessing the validity of statements in the results section if you are summarizing them in any way or saying they are worth mentioning. We as anonymous editors don't get such special privileges, so that's why we rely on secondary sources who are qualified to do that for us.

  If I'm reading a primary article IRL and citing the results, I'm supposed to be checking if their methods actually let them say that, the statistical tests are valid, etc. That gets taught pretty early on in introductory college level courses, and especially on how scientific literature is misused when people don't do that. That reality remains regardless of guideline or not. KoA (talk) 16:34, 23 April 2024 (UTC)

  KoA, I think you have the right intuition here, but it's neither OR nor SYNTH.

  First of all, it is actually impossible to violate SYNTH when you are looking at a single source. SYNTH begins with the words Do not combine material from multiple sources. One source is not multiple sources; ergo, SYNTH does not apply.

  Second, deciding that some material is worth mentioning is not an example of material—such as facts, allegations, and ideas—for which no reliable, published source exists – which is our definition of OR.

  I find that understanding the reason that WP:NOR was created helps people understand it. That policy exists because, 'way back in Wikipedia's earliest days, a Usenet personality (read: physics crackpot) thought that Wikipedia would be an excellent place to tell the world about his proof that Einstein was completely wrong. He couldn't get the scientific journals to publish his nonsense, and he got laughed at on Usenet, but he was just so convinced that he had figured out something that nobody else knew, that he really wanted to tell the world. Wikipedia was one of his targets. We didn't accept his nonsense, either, and we wrote NOR to draw a line in the sand, and say to all the other crackpots in the world: if you can't get your idea published in the real world, we don't want it here, either.

  The flipside, which has probably occurred to you, is that if you did get your idea published in the real world (e.g., as a primary source in a scientific journal), then we might want it here. But what's important for this discussion is: If the material in question was actually published in a reliable source, then it's not NOR. It might be a violation of every single other policy and guideline, but it's not NOR.

  I think what you're looking for is Wikipedia:Relevance, or, in the more general case, NPOV. Deciding whether the contents of a source is worth mentioning is fundamentally not about an editor making stuff up, but about an editor finding the right WP:BALANCE in the article. WhatamIdoing (talk) 18:31, 23 April 2024 (UTC)

  No. You're not generally looking at a single source when writing an article, you are looking at multiple sources, and indeed you can imply something about them in the ways you put them together. Alanscottwalker (talk) 18:43, 23 April 2024 (UTC)

  But incorporating material from the primary source into the context of the rest of the article is synthesizing from multiple sources... JoelleJay (talk) 18:53, 23 April 2024 (UTC)

  @Alanscottwalker and @JoelleJay, that isn't what the policy says.

  WP:SYNTH does not restrict itself to primary sources. If you combine any sources to reach or imply a conclusion that does not appear in any source, then you violate SYNTH. Combining two high-quality secondary sources, if you combine them in ways that reach or imply a conclusion that has never been made in a reliable source, is a SYNTH violation.

  For example, this is a N classic SYNTH violation:

  • String theory is correct.^{[excellent source]}
  • Newtonian physics is correct within limits.^{[great source]}
  • Therefore, I say Einstein is wrong!^{[Wikipedia editor's own conclusion]}

  Using two sources next to each other – so long as you are not reaching or implying a conclusion that has never been published in a reliable source – is not a SYNTH violation.

  For example, this pairs two primary sources, and it is Y 100% non-SYNTH and acceptable per policy:

  • Smith stated that Jones committed plagiarism by copying references from another author's book.^{[op-ed in a magazine]}
  • Jones responded that it is acceptable scholarly practice to use other people's books to find new references.^{[Jones' blog]}

  Alan, you're correct insofar as we (and the policy) agree that you can imply something that isn't present in any source, but there is nothing inherent about using a primary source, or using multiple sources in the same article, that means you actually are reaching or implying a previously unpublished conclusion. If you haven't combined multiple sources to create a new conclusion, it's not SYNTH; if everything in the article comes from sources, then it's not any type of OR. WhatamIdoing (talk) 23:33, 23 April 2024 (UTC)

  Joelle, I don't know if the implications of your comment were clear to you – maybe it doesn't say quite what you meant – but if it were actually true that "incorporating material from the primary source into the context of the rest of the article is synthesizing", then WP:PRIMARY would be much shorter, since all it would need to say is "Citing primary sources is banned". Either it's possible to cite a primary source in an article without violating SYNTH, or primary sources are banned by SYNTH. This is a strictly either-or situation; we cannot have it both ways, so that we claim out of one side of our mouths that primary sources are permitted and out of the other that using them is a violation of SYNTH because using them (correctly) is synthesizing their contents into the context of the rest of the article.

  Given that the word primary doesn't appear anywhere in SYNTH, and given that editors cite primary sources every hour of the day, including in Featured Articles, I think it's clear that primary sources are permitted (when used appropriately) and do not violate SYNTH (except when used in ways that would equally violate SYNTH if they were secondary sources). WhatamIdoing (talk) 23:41, 23 April 2024 (UTC)

  What's your point? No one said SYNTH is restricted to primary sources. You were just plain wrong that we are only dealing with one source in almost every case that matters, and yes the implication from the way you combine them is what needs to be looked into, that is SYNTH analysis. -- Alanscottwalker (talk) 23:51, 23 April 2024 (UTC)

  JoelleJay said incorporating material from the primary source into the context of the rest of the article is synthesizing from multiple sources. Note the absence of any restrictive clause like "if that's done to reach or imply a conclusion that is not present in a reliable source". A plain reading of her sentence indicates that she believes using a primary source is a SYNTH violation.

  Do you agree with her that citing a primary source in an article always involves synthesizing it with the other sources in the article? WhatamIdoing (talk) 00:30, 24 April 2024 (UTC)

  It always depends on how you use the source. I understood her point to be you are using more than one source (Though one would surmise, one would need to have a very rigorous explanation for throwing primary info into the middle of secondary analysis, of course). Alanscottwalker (talk) 01:00, 24 April 2024 (UTC)

  Yes, my point was that contextualizing a primary source with the rest of an article is combining multiple sources to reach a conclusion not implied in any of them. "Contextualizing" being a key synonym of "interpreting" or "analyzing" here. JoelleJay (talk) 02:50, 24 April 2024 (UTC)

  All sources can (and must) be cited without "interpreting" or "analyzing" them. You seem to think that merely citing a source involves interpreting or analyzing it, but that is not true. See SYNTH is not mere juxtaposition and other items on that page. Here is a hypothetical example of a properly cited source: "XYZ has proposed that black holes evaporate more quickly than previously assumed.[cite]" If the source satisfies RS, this ticks all the boxes and does not involve any interpretation or analysis, nor does it imply that XYZ is correct. It is mere reporting of what is in a source and there is nothing whatever wrong with it. Zero^talk 03:17, 24 April 2024 (UTC)

  You don't judge SYNTH on one source alone. It remains, primary sources are not interpretation/analysis so therefore you can't use them to recast, remix, redo, update, shade, shape, bolster, critique, bring new contextualization, make new implications, etc., for secondary analysis. Alanscottwalker (talk) 06:34, 24 April 2024 (UTC)

  My point is that content cited to a primary source that has been contextualized with the other material on the page is a) no longer from "only one source" and b) is automatically SYNTH because definitionally primary-cited content can't be contextualized with other material without violating OR.

  Your example, if citable only to a primary source, is still "bringing new contextualization" to the topic beyond the "basic facts" allowed by PSTS. JoelleJay (talk) 00:26, 25 April 2024 (UTC)

  Alan said: one would need to have a very rigorous explanation for throwing primary info into the middle...

  The "rigorous explanations" I've been given for this, by its proponents, is that they want give credit to the original researcher or to make it easy for people (i.e., people who need to give credit in their own papers to that original researcher) to find the original paper. WhatamIdoing (talk) 08:15, 26 April 2024 (UTC)

  If you are talking about highlighting a primary source that's already highlighted in secondary sources, that's probably fine (depending on how long the Wiki article should be) as long as you do it in a similar way to the secondary source(s). (That is, you don't draw anything 'new' from it). Alanscottwalker (talk) 16:13, 26 April 2024 (UTC)

  The biggest problem that I have here is that this essay is a TLDR wall of uncited text. Every time I read it, I find new issues. For example, the section "definitions" contains a link to the article Primary source, which says that it is about "the study of history as an academic discipline". (While the article does contain a one line mention of "scientific literature", it is referenced to a source that is about "research" generally, rather than science). The link to the article is clearly not relevant to the essay and ought to be removed. Another example: The essay tells me to use "reviews published in the last five years or so". Why five years? Is this just a round number? Where has this number come from? Who says five years is up to date? Has this essay been systematically checked for errors? It might be better to start a new proposal from scratch, and build it up one line at a time, carefully checking (and preferably citing) the claims as you going along. James500 (talk) 22:41, 22 April 2024 (UTC)

  the article Primary source, which says that it is about "the study of history as an academic discipline" – Um, no, it doesn't. It says that "in the study of history as an academic discipline", a primary sources is a particular thing. It does not say that the article is about the study of history. (Compare "In the field of medicine, cancer is a disease, but in the field of astronomy, cancer is a constellation".) The link is there to help people who don't know what that jargon means. Reasonable people could disagree over whether it is more useful to link to the encyclopedia article, the policy, or the explanatory essay, but I don't think anyone believes it's best to leave unfamiliar terms undefined.

  For your other questions:

  • Why five years? Is this just a round number? – Three to five years is recommended to medical students based on the length of time it takes for sources to get published in that field. This is based on the idea of a "cycle": You publish your research, I publish my review of your research, and someone else publishes a response to my review. You want the whole cycle to happen. Because it takes weeks or months to write the papers, and months (sometimes, even longer than a year) to get the paper published, it usually takes at least one year, and it often takes three to five years, to get an understanding of how the scientific community has reacted to a paper.
  • Where has this number come from? – Straight out of WP:MEDRS.
  • Who says five years is up to date? – Medical researchers, but as a Rule of thumb, not as an absolute statement that applies in all circumstances. Some information (e.g., names of diseases) rarely changes, and other information changes rapidly.

  WhatamIdoing (talk) 23:55, 22 April 2024 (UTC)

  I don't think it's possible to uncritically apply the norms of the medical research cycle to all science - different disciplines move at different speeds and have different considerations and conventions. Thryduulf (talk) 00:12, 23 April 2024 (UTC)

  And that is why I think citations would be desirable: to avoid the risk of a Wikiality definition of reliability. James500 (talk) 00:22, 23 April 2024 (UTC)

  Citations are typically used in mainspace. Wikispace generally doesn't have citations outside of very specific needs. An essay/guideline not having much for citations is the norm. KoA (talk) 04:53, 23 April 2024 (UTC)

  The rule is at WP:NOTPART.

  Thryduulf, I agree with you. History isn't science, but it makes a good example: their fundamental unit of scholarly output is the book, and the cycle is consequently much longer. I don't expect the hard sciences to be wildly different (anything in the last five years is likely to be reasonably current under normal circumstances in any hard science, no matter how fast it moves, and under abnormal circumstances, sudden shifts can happen overnight even in medicine). I am more concerned about subfields that move more slowly. Sometimes niche information is relevant and appropriate, and the best source is six or ten years old, rather than two or five. WhatamIdoing (talk) 00:24, 24 April 2024 (UTC)

  Indeed, and then you get into fields that don't fit completely into a single box, like the history of science, where you might need to cite decades old research, such as when a mainstream theory is proven incorrect conclusively and repeatedly and so nobody touches it again. Luminiferous aether is the first thing that comes to mind (although probably not the best example as that's been the subject of much ley coverage). Thryduulf (talk) 00:58, 24 April 2024 (UTC)

• I think it's obvious that there isn't consensus to upgrade SCIRS right now, but I'm also not hearing a hard no forever and there's been a lot of potential points of improvement raised. I'll try to summarise those at WT:SCIRS when I get a chance – but if anyone can beat me to it, please be my guest. The trickiest issue seems to disagreement over the desirability of applying WP:PSTS to scientific topics, but since that's already a policy I don't see much room for manouvre. – Joe (talk) 06:40, 23 April 2024 (UTC)

  On the contrary, I do not see any disagreement over WP:PSTS. After all, this is its current first paragraph.

  Wikipedia articles should be based on reliable, published secondary sources, and to a lesser extent, on tertiary sources and primary sources. Secondary or tertiary sources are needed to establish the topic's notability and avoid novel interpretations of primary sources. All analyses and interpretive or synthetic claims about primary sources must be referenced to a secondary or tertiary source and must not be an original analysis of the primary-source material by Wikipedia editors.

  Appropriate sourcing can be a complicated issue, and these are general rules. Deciding whether primary, secondary, or tertiary sources are appropriate in any given instance is a matter of good editorial judgment and common sense, and should be discussed on article talk pages. A source may be considered primary for one statement but secondary for a different one. Even a given source can contain both primary and secondary source material for one particular statement. For the purposes of this policy, primary, secondary and tertiary sources are defined as follows

  A primary source may be used on Wikipedia only to make straightforward, descriptive statements of facts that can be verified by any educated person with access to the primary source but without further, specialized knowledge.

  So, perhaps it is the pro-SCIRS editors here who need to be reminded of the actual PSTS text. They are the ones who are suddenly turning to a lesser extent, on tertiary sources and primary sources into "secondary and tertiary sources only" and arguing that no, primary sources should not be used for straightforward statements of facts, instead proposing an alternative which would often run counter to common sense (I am yet to a see a response to the fairly obvious downsides I identified in an earlier comment here).

  I also want to highlight that this would be a very disruptive change if adopted and there were actually serious attempts to enforce it. To give a personal example: so far, I have successfully nominated a total of three articles for GA. In each case, the article was what I (and apparently, the reviewer) considered to be a healthy mix of primary and secondary sources. Further, each reviewer was a veteran editor with ~67k, ~267k and ~22k edits, and two of them have made extensive contributions both to creating and reviewing GA-class articles. If the people responsible for much of the GA article creation and maintenance are acting counter to the spirit of the policy you propose, you may want to reconsider something. InformationToKnowledge (talk) 13:17, 23 April 2024 (UTC)

  I really thought SCIRS was a low-profile and uncontroversial essay before this – I'm surprised there is already a camp of "pro-SCIRS editors" who need to be reminded of anything! WP:PSTS does indeed say that primary sources can be used, as does WP:SCIRS, under #Respect primary sources: a primary source, such as a report of a pivotal experiment cited as evidence for a hypothesis, may be a valuable component of an article. A good article may appropriately cite primary, secondary, and tertiary sources. When I observed that there is disagreement over PSTS, it is precisely because the rather moderate attempt to apply it in SCIRS (as opposed to say WP:MEDRS, a guideline, which says Avoid primary sources) has provoked such strong reactions. – Joe (talk) 13:43, 23 April 2024 (UTC)

  Well, only a few posts up, multiple editors are telling me that what may appropriately cite in this "Respect primary sources" wording really means is, apparently, "A primary scientific source can only be cited when it cites something else, and never for its own findings." This really is not the way many of us have thought of WP:PSTS before, so I question the idea that this is "moderate". InformationToKnowledge (talk) 14:09, 23 April 2024 (UTC)

  But the purpose of this discussion was to gauge support for upgrading SCIRS to a guideline, not their opinions to a guideline. – Joe (talk) 17:58, 23 April 2024 (UTC)

  In which case, wouldn't this suggest that the SCIRS text needs to be amended to fully clarify that it does not currently endorse such opinions, before it can become a guideline? If some editors appear to intepret the existence of a policy as a mandate for making editorial decisions which are not currently openly endorsed by it? InformationToKnowledge (talk) 15:09, 26 April 2024 (UTC)

  At least for most of us who work on science topics, it generally isn't anything controversial in practice in my experience.

  To be blunt though, this has highlighted how many who would benefit from additional guidance of scientific sources are often opposed to it, so there's a catch-22 there on the wiki-process side of things. Some arguments that have come up here are just plain misconception or just making something simple we normally do when dealing with primary sources seem really complicated somehow. I mentioned earlier too how it's not an uncommon problem for people with a science background to have trouble adjusting to working as an anonymous editor when it comes to using scientific literature, so there are a few systemic things to address.

  That said, SCIRS in concept is fairly well primed to be a guideline, but there is some work to be done on structure, broadening concepts that were addressed in the narrow MEDRS sense, etc. I didn't get around to it yet, but I have a few edits I've been working on putting in that I'll get to soon. KoA (talk) 16:48, 23 April 2024 (UTC)

  I'm with you there. Reading this discussion, I can certainly see where people are coming from with the fear of too harsh a prohibition, but I cannot really imagine my own usual topic area functioning at all if primary and secondary sources were given complete parity. – Joe (talk) 18:00, 23 April 2024 (UTC)

  I cannot really imagine my own usual topic area functioning at all... One thing that seems clear to me but not to everyone in this discussion is that "science" isn't a single topic area. Medicine is different to climate change, both are different to archaeology, and all of them are different to astronomy. They have commonalities, but there are such fundamental differences in the nature of the research, the speed of the field, the conventions, etc. that I don't think it's going to be possible to produce a single guideline that both covers every scientific discipline and has anything useful to say that more general policies and guidelines don't already. MEDRS works because it's focused on a single topic area, but at least some of it's provisions just don't translate to other sciences. Thryduulf (talk) 20:27, 23 April 2024 (UTC)

  SCIRS would be applicable to any field that has primary research papers and secondary reviews/meta-analyses/books. They all would benefit from stronger guidance discouraging inclusion of primary results, as suggested in PSTS, which itself apparently needs to be enforced better in certain topics if editors are routinely citing splashy new papers. JoelleJay (talk) 21:44, 23 April 2024 (UTC)

  I agree and I think that Joe Roe's initial proposal to upgrade SCIRS to a guideline was a commendable effort, but there is a big undercurrent of opposition as it would be subject to abuse, and the project has suffered from that in the past. It would be wielded as a gatekeeping tool by editors experienced in wikilawyering, keeping out new ones with valuable contributions, stagnating the project. The key to Wikipedia's success is open collaboration, as written in the lead sentence of the Wikipedia article. FailedMusician (talk) 01:16, 24 April 2024 (UTC)

  and the project has suffered from that in the past. Citations? JoelleJay (talk) 02:52, 24 April 2024 (UTC)

  The text goes on to say It would be wielded as a gatekeeping tool... and I'm sure you know of relevant incidents yourself. FailedMusician (talk) 23:43, 24 April 2024 (UTC)

  I want to know what you think are examples of the project suffering due to "overzealous" application of MEDRS.

  And again I don't know how you can be sure [I] know of relevant incidents [myself] unless you're an alt account of someone who has actually interacted with me before this thread. Do you have any prior accounts? JoelleJay (talk) 00:40, 25 April 2024 (UTC)

  Every academic subject has primary research and then secondary sources such as books. This includes the Humanities and they can be quite soft subjects such as Harry Potter Studies; Fashion; and Poetry. Science just means knowledge and so is too general a concept to be definitive or helpful. Andrew🐉(talk) 22:33, 27 April 2024 (UTC)

  Not every subject has primary research results published in the form of papers, unless you're stretching the contextual meaning of "results" to include any intellectual work product. JoelleJay (talk) 22:38, 27 April 2024 (UTC)

  For an example, please see The Science Behind the Magic? The Relation of the Harry Potter “Sorting Hat Quiz” to Personality and Human Values. Andrew🐉(talk) 08:13, 28 April 2024 (UTC)

  Can you point me to a diff where anyone spoke of anything resembling complete parity between primary and secondary sources? In my view, the opposing arguments instead are more akin to acknowledging that different sciences - indeed, different research areas of the varying sciences which we would ideally all need to cover - have different publication cycles, a vast difference in complexity of primary vs. secondary studies and last but not least, a different relationship with time and probability.

  Thus, on balance, sometimes the harm of delaying the inclusion of a complex, high-quality primary study in favour of either waiting years for a review which will likely adopt its findings anyway, or settling for a mention in another study's introduction which will likely only cover a fraction of relevant information would exceed the supposed benefits to reliability incurred from doing so. To me, this is where the argument seems to be at - as was already pointed out, the basic point of "prefer secondary sources to primary ones" is already part of WP:PSTS.

  Again, I'll add another example from climate science. One thing which makes it distinctive from most other sciences is not only that much of it deals with the future, but also that it deals with the future as directly shaped by human actions in the present and upcoming days. Besides the WP:NOW implications, this means that climate-related papers routinely make not one prediction but several, in accordance to Representative Concentration Pathways / Shared Socioeconomic Pathways and occasionally other factors (i.e. research on species' vulnerability to climatic risks may include different predictions for the same scenario based on different assumptions about species' dispersal success). This kind of nuance will rarely be seen when the paper is cited in another primary source - in my experience, there'll often just be a reference to paper's finding under the most extreme scenario (something like "up to X million will be affected by year Y", where "up to" conceals the estimates under all the other scenarios.) I believe that any policy which would force us into adopting such framings purely due to citing decisions made for a very different audience (academic readers of climate literature are assumed to be aware of these scenarios and how they affect findings by default, which is obviously not true for the general readers of Wikipedia) would be deeply flawed, so I continue to press this argument.

  Further, I would again emphasize the difference in what can be considered a "primary source". I maintain that an in vitro analysis of drug candidates, an observational study in a couple of hospitals or even a proper RCT are still not the same as field research collected over years by teams living on polar stations for months at a time, or data collected from hundreds of profiling floats or any other such examples. Consider something like a volcanic eruption. Can you imagine restricting coverage on eruptions to secondary sources only? If not, then how different are they, really, from the eroding glaciers or burning forests, or even the slowing ocean currents? InformationToKnowledge (talk) 14:26, 26 April 2024 (UTC)

Support, though I'd be in favor of some tweaks/changes, eg I think it's too long, and should also say more about sources being a mix of primary and secondary (eg a novel study might be a good source for current state-of-the-science background). But the core of it, identifying the difference between primary and secondary in science, would be useful to have as a guideline, particularly to prevent against the misuse or overuse of primary sources, basically the same thing that medrs does for medicine. Levivich (talk) 02:06, 24 April 2024 (UTC)

The analogy between MEDRS and SCIRS has problems, mostly to do with why they exist. MEDRS was invented because we knew that people would read WP for medical advice and we don't want to kill anyone. This gives a very strong motive for strict rules on medicine that does not apply to general science articles. I don't see a strong reason why science is different from, say, history. Zero^talk 02:59, 24 April 2024 (UTC)

These rules aren't very strict IMO and apply to all fields, which to say, lots of fields could use a ___RS. MEDRS to explain different levels of reliability in medical sources, SCIRS for general science sources, I think there should be a LAWRS for legal sources (that would explain about citing court opinions v. treatises, etc.), and yes, a HISTRS for history sources (that would explain about citing historians for history v. non-historian scholars v. news media, for example). (Btw I never bought into the whole people-look-at-WP-for-medical-advice-and-might-die argument.) Levivich (talk) 04:48, 24 April 2024 (UTC)

I don't have a memory any more, but my recollection is that both MEDRS and BLP were more or less forced on us by the higher-ups as they were afraid of being sued. In the early days Wikipedia was not filthy rich like it is now. Zero^talk 04:54, 24 April 2024 (UTC)

Unpopular opinion: at least the money has bought better higher-ups; I think the current management team is the best one so far. Levivich (talk) 05:04, 24 April 2024 (UTC)

@Zero0000 As far as I know, BLP and MEDRS were invented by the English Wikipedia community with no higher-ups forcing us to. In 2009, the WMF board passed a resolution urging all WMF projects to adopt BLP policies. By that time, our BLP policy was already three years old. Clayoquot (talk | contribs) 05:21, 25 April 2024 (UTC)

Looking at its talk page archives, it seems that WP:MEDRS was spun off in an organic, creepy way from WP:MEDMOS. Andrew🐉(talk) 08:20, 28 April 2024 (UTC)

Oppose - I think that even MEDRS is too restricting, although I understand that in that case we need to be concerned about people taking medical advice from Wikipedia (despite Wikipedia:Medical disclaimer, which hopefully prevents any liability but certainly won't stop most people). In the case of science, this concern is irrelevant. Animal lover |666| 07:09, 24 April 2024 (UTC)

Oppose. One of the cornerstones of Wikipedia is verifiability. One problem with using secondary sources is that they often do not cite with enough precision where they got their information from. It might often be from out-of-date or otherwise unreliable sources, but, even if not, you can't always tell. That is why I often prefer a primary source, which anyone can follow up to check the quality of the evidence. Ideally I like to include the primary source together with a recent secondary source so as to demonstrate that the claim in the primary source is still trusted. This is my experience particulary in editing natural-history articles about particular species. So I would like to retain the current ambiguity, that at least allows primary sources even if it does not favour them as much as I would wish. JMCHutchinson (talk) 12:04, 27 April 2024 (UTC)

References

Servant of God and Saint With Respect to WP:N.

Quick question here. Does being Servant of God and Saint count as notable, and if so, should we either add this to outcomes or notability? I can think of roughly three options here. 1. No effect on notability, in addition, consider any coverage of their canonization as WP:1E coverage. 2. No effect on notability, but consider coverage of their canonization as establishing notability. 3. Presumed notable. Allan Nonymous (talk) 20:35, 23 April 2024 (UTC)

Just clarifying, I assume that you mean it by the Catholic Church use of those terms. North8000 (talk) 20:48, 23 April 2024 (UTC)

Nothing the Catholic Church (or any other religious institution - it would be deeply inequitable to distinguish between such institutions and treat them as more of an authority than others in this regard) does directly determines notability, which for this, like anything else, is assessed through the depth of coverage in reliable sources. Our decision, not theirs. AndyTheGrump (talk) 21:24, 23 April 2024 (UTC)

The Catholic Church designating someone a Servant of God or Saint (or other religious institutions doing their equivalent) is a claim of significance for A7 purposes, but it doesn't automatically confer notability. It is one point to consider when determining notability, but do note that the Catholic Church is a reliable but not independent source for Catholic saints. Thryduulf (talk) 21:43, 23 April 2024 (UTC)

@Allan Nonymous, the answer is "it depends". Specifically, it depends on how much coverage the individual(s) have received in reliable sources.

So here's something that sometimes surprises people: According to our rules, the Presidents of the United States are not inherently notable. Every single one of them is obviously notable, but none of them are inherently notable. That's because every single article about every single human has to be justifiable individually, based on coverage. If, over the course of several years, journalists and scholars write thousands of words, across dozens of news articles, about an individual, then that individual is actually notable. If nobody writes anything, then that individual is not notable, no matter how important they are. If we could somehow have a US president with no coverage, then that president would not qualify for a Wikipedia article.

Given that I occasionally see news headlines about the Catholic Church declaring someone to be a saint, I assume that basically all of the individuals canonized in recent years will – like US presidents – turn out to be notable. But it's the media coverage that matters for notability, not why the media coverage happened. WhatamIdoing (talk) 00:03, 24 April 2024 (UTC)

While I'm here: You have nominated many articles for deletion recently, and a larger than usual proportion have been kept. This suggests that your personal views about notability do not align closely with the wider community's views. You are obviously doing a WP:BEFORE search, but it's not helping you avoid incorrect AFD nominations.

I think that it would be helpful for you to reflect on what the Wikipedia:Editing policy says: "Wikipedia summarizes accepted knowledge. As a rule, the more accepted knowledge it contains, the better."

Every deletion makes Wikipedia have less knowledge. Sometimes deletion is necessary or desirable, but usually – as a rule of thumb – the long-standing policy says that more accepted knowledge is better than less. Consequently, if an article appears to be summarizing accepted knowledge, then deleting the article will probably make Wikipedia worse. You might have better results at AFD if you restrict yourself to nominating only articles that do not summarize accepted knowledge. WhatamIdoing (talk) 00:13, 24 April 2024 (UTC)

That's some good advice, thank you! Making my AfD noms more consistent has been a goal of mine, and one I have struggled to meet. Advice like this is always appreciated. I try to keep an open mind on AfD noms and try to be quick to admit mistakes when I make them so when I screw up, it at the very least doesn't waste too much time. Allan Nonymous (talk) 00:27, 24 April 2024 (UTC)

From my experience, I agree with "It depends" above. There isn't a one-size-fits-all. People who have been sainted recently are very likely, practically guaranteed, to have coverage of them. Saints from non-Mediterranean regions in the first millennium tend to be more iffy in terms of coverage, but even this is not a good one-size-fits-all judgement because you have saints like Bede and Boniface. Curbon7 (talk) 01:04, 24 April 2024 (UTC)

Userpage policy in regards to offensive and violence-related quotes

Based on this discussion, there seems to be some disagreement on both the valid interpretation and scope of Wikipedia:UPNOT. The issue itself is resolved, but I believe that an improvement of the guideline (or as a secondary option, a clarification) would be desirable.

Should the policy be stricter/clearer when it comes to content that is likely to cause broad offence, as well as content that justifies, excuses or endorses violent acts (or can be reasonably interpreted as such)? FortunateSons (talk) 13:51, 27 April 2024 (UTC)

My opinion is that we should be much stricter - and disallow ALL expressions of support/opposition for issues unrelated to Wikipedia on our user pages. This isn’t the venue for it. Blueboar (talk) 15:11, 27 April 2024 (UTC)

If this isn't the venue, then what is? starship.paint (RUN) 15:17, 27 April 2024 (UTC)

Reddit, Facebook, Twitter, a personal blog? BilledMammal (talk) 15:21, 27 April 2024 (UTC)

I believe that this is a misunderstanding, which I also had: Blueboar is referring to Wikipedia not being the place for political expression, not that the Village Pump is the wrong place for my suggestion, correct? FortunateSons (talk) 15:23, 27 April 2024 (UTC)

My apologies for the misunderstanding. starship.paint (RUN) 15:26, 27 April 2024 (UTC)

• Exactly what is broadly offensive? Is it "the greatest destroyer of peace today is abortion" or could it be "No woman can call herself free until she can choose consciously whether she will or will not be a mother"? Is it "God has no religion"? starship.paint (RUN) 15:26, 27 April 2024 (UTC)

  That’s a fair point, but also the issue with making any consistent standard. I would go for “likely to be considered inflammatory by a non-insignificant amount of editors“, but that does come with its own issue. Basically “I like this group considered terrorists by many countries” is subject to removal, “I like this goal (assuming it’s compatible with human rights and international law) of said group” is not. For example, supporting many of the goals of Lehi (militant group) shouldn’t be sanctionable, but supporting the group itself should.

  Alternatively, we could pick a country with reasonable hate speech, anti-terrorism ans incitement laws and base our standards on them? FortunateSons (talk) 15:37, 27 April 2024 (UTC)

  Regarding those specific examples, I am honestly not familiar enough with the American political discourse to make a clear judgement. However, generic pro-life and pro-choice statements should be permissible, while “abortion is murder” should not. FortunateSons (talk) 15:39, 27 April 2024 (UTC)

  The notion that women cannot choose offends the pro-choice, and the notion of destroying fetuses offends the pro-life. The notion that God _______ can offend the religious. That's the problem with offense. starship.paint (RUN) 15:54, 27 April 2024 (UTC)

  Is there an alternative approach that you would consider feasible? The current version does not seem to be specific enough to be useful. FortunateSons (talk) 15:57, 27 April 2024 (UTC)

  I am not sure of that myself. starship.paint (RUN) 01:43, 28 April 2024 (UTC)

  @Starship.paint Do you like Stephen Fry? [14] Gråbergs Gråa Sång (talk) 10:22, 28 April 2024 (UTC)

If we want to ditch userpages, fine by me. If we want to keep them, the existing guidelines are sufficient imo. Selfstudier (talk) 15:27, 27 April 2024 (UTC)

I think we have three options:

1. Editors may not express support for any position that is controversial in any part of the world
2. Editors may not express support for any position that is unrelated to Wikipedia
3. Editors may express support for any position that is mainstream in any part of the world. Editors may not express support for violence, regardless of whether the position supported is mainstream.

The current status quo, where what we allow and reject is based on the opinions of whoever turns up at the relevant discussion, is arbitrary and typically contrary to our status as a global encyclopaedia.

I lean towards #1 or #2, but #3 has the benefit of being transparent - if someone wants to tell us they are very biased, perhaps we should let them? BilledMammal (talk) 15:28, 27 April 2024 (UTC)

No controversy means no politics, no social issues, at least. Mainstream, what is that? Is Israel mainstream? Is Palestine mainstream? Is Hamas mainstream? Is North Korea mainstream? Is Iran mainstream? Is Qatar mainstream? starship.paint (RUN) 15:33, 27 April 2024 (UTC)

Yes - if it’s mainstream in Israel, or Qatar, or Palestine, or even North Korea, it would be permitted under #3.BilledMammal (talk) 15:36, 27 April 2024 (UTC)

I think all 3 are valid choices, with a minor caveat that 3 does not have to be exlicit (example: believes that there should be no place for (x ethnic/religious/social group/GSM) in (place) is implicitly violent even if there is no action or policy prescription attached.). FortunateSons (talk) 15:42, 27 April 2024 (UTC)

A hard no to #1. That meant that a simple statement of fact may be seen as controversial in some parts of the world. Ie "Guns are not needed in everyday life." A position valid and practiced in many parts of the world would be deemed as controversial by many in US. – robertsky (talk) 15:47, 27 April 2024 (UTC)

Yes, it would - that would be the idea, we shouldn’t be picking and choosing which positions we accept/reject.

With that said, perhaps we should add exceptions for positions that are genuine and undisputed statements of fact - for example, “the earth revolves around sun”. BilledMammal (talk) 16:02, 27 April 2024 (UTC)

And point 3 is prone to majority capture. Case in point, western powers have had tried to spin the story that there is a genocide in Xinjiang with flimsy proofs at some levels and USA propaganda machine driving behind this as well, and the article was at Uyghur genocide for 3.5 years before the current title. If one believes that there was no genocide and expressed as such on their user page, wouldn't that be condemned as well? – robertsky (talk) 04:51, 28 April 2024 (UTC)

Three should allow editors to express that position, as it is a mainstream position in, at the very least, China. BilledMammal (talk) 04:56, 28 April 2024 (UTC)

Ideal, but practical? People don't always interpret things you want them. The current consensus on RS deprecate many Chinese sources, and may just go 'hey, your position is not based on reliable sources therefore not mainstream'. – robertsky (talk) 12:08, 28 April 2024 (UTC)

My preference is #2, but within reasonable limits Well, I'm conflicted. On one side, I think politics and ethical questions should stay generally stay off userpages, having nothing to do with the project and more often being divisive—for example, a userbox saying "I am Christian/Muslim/Jewish/Athiest/etc." isn't helpful and honestly kind of annoying— but I don't have a problem with, say, a userbox boldly stating that "This user supports Red Dwarf coming back for a fourteenth season", or something like that.

On the other hand, a significant part of me says, "Ah, what the hell, let people say whatever they want on their own userpages".

There's merit to both sides here, so I doubt this discussion will come to any useful consensus. Our current policies are the sort of bland, milquetoast decisions Wikipedia does best. Cremastra (talk) 13:32, 28 April 2024 (UTC)

No. Neither "content that is likely to cause broad offence," nor "content that justifies, excuses or endorses violent acts (or can be reasonably interpreted as such)" are a problem. In the real world, causing broad offense is extremely common: a woman without her face or hair covered will cause broad offense in some places, whereas requiring a woman to cover her face or hair will cause broad offense in other places. Both supporting and opposing gay rights will cause broad offense among different groups of people. In fact, every important issue will cause broad offense in one way or another: climate change, gun control, abortion rights, immigration, poverty, COVID, the definitions of "man" and "woman" and "person" and on and on.

Similarly, violence is sometimes justified, and all humans engage in and depend on it, either directly or indirectly. Pacifism ("violence is never the answer") is naive, our societies are built on violence, our physical safety and comfort are secured by violence. It's an inseparable part of life. "Violence is never justified" is just untrue and easy to disprove, so there is no logic in banning all expressions of justification or support of violence.

I agree with Self: we either have free speech (in userpages) or we don't. Either one is fine with me. But trying to control that speech, especially with unrealistic rules like banning speech that gives offense or justifies/excuses/supports violence, is unrealistic, and attempts to do so offend me :-P Levivich (talk) 16:02, 27 April 2024 (UTC)

I must admit that the last line is funny :/

Having said that, are you then in favor of removing the current version as well? FortunateSons (talk) 16:04, 27 April 2024 (UTC)

Yes, I think I'd be fine with deleting all of UPNOT. This website should have one set of rules about what you can't write here, and it should apply to all pages, and it should be in the TOU, stuff like no threats of violence, no discrimination, no promoting a business/product, no copyright violation, etc. I'm not sure we need anything beyond the TOU, and let the WMF enforce it. So basically the same as every other user generated content website. Levivich (talk) 16:09, 27 April 2024 (UTC)

Ok, let’s add that as #4 FortunateSons (talk) 16:11, 27 April 2024 (UTC)

At the risk of opening up the scope of this, should it apply to userboxes as well? FortunateSons (talk) 16:12, 27 April 2024 (UTC)

Yeah it doesn't matter if the text has a border around it or not :-) Levivich (talk) 16:14, 27 April 2024 (UTC)

Makes sense :) FortunateSons (talk) 16:14, 27 April 2024 (UTC)

To put your position in line with what I say above, would your position be #4 - Editors may express support for any position that is mainstream in any part of the world? (#3 without the exception)

Note that this would include calls for ethnic cleaning, honour killings, etc - forbidding these was why I added the exception to #3. BilledMammal (talk) 16:06, 27 April 2024 (UTC)

No, I'd say editors can express anything that's not a TOU violation. No defamation, copyvio, death threats, discrimination, etc., but unpopular opinions are fine. Levivich (talk) 16:13, 27 April 2024 (UTC)

How would you distinguish between discriminatory and non-discriminatory violence? FortunateSons (talk) 16:14, 27 April 2024 (UTC)

So #4, unless the content violates the UCoC? (The TOS doesn’t talk about violence etc, it refers to the UCoC - although I note that under the UCoC I don’t think expressing support for discrimination would be forbidden, although I may be mistaken) BilledMammal (talk) 16:18, 27 April 2024 (UTC)

I think the relevant passages of UCoC are:

1. Hate speech in any form, or discriminatory language aimed at vilifying, humiliating, inciting hatred against individuals or groups on the basis of who they are or their personal beliefs
2. The use of symbols, images, categories, tags or other kinds of content that are intimidating or harmful to others outside of the context of encyclopedic, informational use. This includes imposing schemes on content intended to marginalize or ostracize.

FortunateSons (talk) 16:21, 27 April 2024 (UTC)

I'm saying don't have an enwiki userpage policy at all, because we already have TOU#4, which incorporates UCOC#3, and those are sufficient, enwiki doesn't need to make separate rules about this. Levivich (talk) 16:30, 27 April 2024 (UTC)

If we don’t have rules - one way or the other - we’ll just continue with our practice of forbidding and allowing based on local consensus, in an arbitrary way that reflects our systematic biases. BilledMammal (talk) 16:33, 27 April 2024 (UTC)

We have rules: TOU/UCOC. Arbitrary local consensus that reflects our systematic biases is called "democracy," and it's the best decision making process we've been able to come up with so far. To put it another way, the place to have rules about what we cannot write on this website is TOU/UCOC. The better approach (IMO) isn't to think about what should we ban on userpages, but what should we allow on userpages that we don't allow on other pages (if anything). And I think we should allow anything on userpages that's compliant with TOU/UCOC. Levivich (talk) 17:01, 27 April 2024 (UTC)

If that’s the route we want to go ("we should allow anything on userpages that's compliant with TOU/UCOC”) I think we should explicitly say that, to minimise the chance of what I describe. BilledMammal (talk) 17:15, 27 April 2024 (UTC)

I'd support revising WP:UPNOT to basically say "see TOU." Levivich (talk) 17:40, 27 April 2024 (UTC)

Suggestions for #4: All content permissible according to ToU and UCoC is allowed on user pages. FortunateSons (talk) 17:44, 27 April 2024 (UTC)

Regardless of what rules are in place, unless there's a change in English Wikipedia's decision-making traditions, enforcement will continue to be done with the current consensus-based methods, and thus will still be determined by whichever editors happen to get involved in any given discussion. Yes, this gives activist editors an outsized voice. But since changing this would require those same editors to relinquish influence, English Wikipedia hasn't reached a consensus to do anything else. isaacl (talk) 17:08, 27 April 2024 (UTC)

Concur with Levivich here. Simonm223 (talk) 17:12, 27 April 2024 (UTC)

Similarly, violence is sometimes justified, and all humans engage in and depend on it, either directly or indirectly. Pacifism ("violence is never the answer") is naive, our societies are built on violence, our physical safety and comfort are secured by violence.

A. This doesn't change the fact that English Wikipedia is an international forum, so actively calling for violence against other humans in any context necessarily means calling for violence against other potential members of the Wikipedia community.

B. violence is sometimes justified is such a short-sighted statement. Once you welcome people to call for violence when it's "justified", the goalpost of what is "justified" will slip right between your fingers towards things you didn't intend. >"Some violence is justified!" >"Wait no not like that"

Either we allow calls for violence by anyone for anyone, or not at all. Welcoming calls for violence "sometimes" will mean that we'll have to start playing a "draw the line" game, which won't end well for this project.spintheer (talk) 17:29, 27 April 2024 (UTC)

You're making a slippery slope argument: that's almost always flawed logic IMO. "Draw the line game" is called "making decisions," and it's what we do as humans, on and off wiki. The lines we draw are called "laws" and "rules," on wiki we call them "policies" and "guidelines" and we have a ton of them and the project would be a lot worse if we didn't have any, or if they said "either everything is allowed or nothing is allowed."

For example, I oppose the violence that the Russian military is perpetrating against Ukraine. I support the violence that the Ukrainian military is perpetrating against the Russian military, to an extent. That extent -- the line that's drawn -- is international law such as the Geneva conventions. I oppose the violence that violates the international laws of war, but I support the defensive violence that is permitted by those laws. That's not a problem, it's not inconsistent, and it's better than either supporting or opposing all violence. This is just one example of defending violence, and it would be easy to come up with others. Levivich (talk) 17:40, 27 April 2024 (UTC)

"Draw the line game" is called "making decisions," and it's what we do as humans, on and off wiki. Of course, this is a general truth that doesn't actually address my point. Of course policies draw lines to balance competing objectives in the best way possible. I'm not saying to stop drawing lines in general. I'm saying that policies are created and lines are drawn in order to serve the long-term productive development of this project. In this specific case, the line drawing would decide what people is it ok to advocate violence against within Wikipedia, and what people you're not allowed to. It would involve deciding in what contexts advocating for brutality is "justified", and when it's not allowed. My point is that making a (inevitably arbitrary) decision in these questions means that it'd always be fair game for debate, which means that we'll regularly revisit this sort of policy, because by definition there'll always be someone who disagrees. Engaging and reengaging in this sort of policy discussion is (a) completely inappropriate and disconnected from improving the encyclopedia and (b) will significantly hurt the English Wikipedia project more than any supposed benefit that it would bring. In the long run, any outcome of such a policy decision would hurt the project and alienate productive members of the community.

Therefore, it's better to prohibit everyone from supporting violence on Wikipedia in any form. Making some support for violence acceptable means that we'll have to revisit this topic, which I believe will inevitably be derailed into places that will fundamentally hurt the project. spintheer (talk) 00:00, 28 April 2024 (UTC)

Best to worry less about what's on an editor's userpage & more about whether or not they're pushing their beliefs on other pages. GoodDay (talk) 16:07, 27 April 2024 (UTC)

This is broadly correct barring explicit hate speech. Simonm223 (talk) 17:13, 27 April 2024 (UTC)

User pages being unowned and not a free speech forum like everything else, here, should remain editable, including sometimes removal of text or pictures (we even do it for user comments, so user pages should be no different) -- sometimes but rarely there will be disagreements, and then just settle it like we do every other disagreement (short version: does this promote the working purposes of the project or not). -- Alanscottwalker (talk) 18:08, 27 April 2024 (UTC)

I'm broadly in agreement with GoodDay and Alanscottwalker and don't see a reason why we should take any action.--Wehwalt (talk) 18:11, 27 April 2024 (UTC)

The question isn't "is it offensive", but "is it disruptive". At best, posting opinions about contentious topics unrelated to Wikipedia's purpose will aggravate other users, impacting our ability to collaborate. At worst, it can actively scare potential editors away—one of the most damaging things you can possibly do to Wikipedia—or create a chilling effect that makes a given group feel unwelcome on the project. Conversely, WP:TIGER applies. If someone feels so strongly about a topic that they have to shout out their beliefs on their user page as if it were a social media page, they are not fit to edit in that area, broadly construed. If there's anyone who should be made to feel unwelcome, it's the tigers, not the people who they oppose. Thebiguglyalien (talk) 23:49, 27 April 2024 (UTC)

Idk, it kinda depends on topic. If it weren't for feeling very strongly about a topic, I would not have spent 100+ hours on Murder of George Floyd or Nakba. What else but strong feelings could possibly motivate anyone to edit about such grim subjects, or any subject? Dispassionate editing is an unrealistic expectation; the best we can do is try to productively channel the passion. If it weren't for tigers, I don't think some articles would exist. (And I bet the museum curators who create tiger exhibits are extremely passionate about tigers.) Levivich (talk) 05:13, 28 April 2024 (UTC)

Yes, exactly. Simonm223 (talk) 10:54, 28 April 2024 (UTC)

Of course we want editors to care about the topics they work on… BUT… they must maintain a level of NEUTRALITY while doing so. That means they must curb their passions. If an editor can’t do that, they probably shouldn’t be editing on that topic. Blueboar (talk) 12:00, 28 April 2024 (UTC)

And what evidence is there for the supposition that having personal beliefs on a user page makes it so that an editor can not edit neutrally? nableezy - 12:04, 28 April 2024 (UTC)

Or they need be passionate about verifiable, neutral, original writing but unoriginal research presentation, with extra care for living person information. Alanscottwalker (talk) 12:14, 28 April 2024 (UTC)

The truth is that every single editor on Wikipedia has strong opinions on the pages they edit. Our agreement to work within a model of consensual collaboration toward neutrality is independent from that truth and my main frustration when editing is not people who argue passionately but rather those who feign dispassion. And it is worth noting that this passion will create points of view especially with regard to reliability and WP:DUE - which is why consensus and neutrality guidelines are critical to the project. Literally 0% of this will change if we censor userpages to create a mask of dispassion. Simonm223 (talk) 12:46, 28 April 2024 (UTC)

• Consensus is messy and not always clear. Sometimes, there is no consensus. That is how it works in a collaborative project with people from all over the world. Written policy here doesn't dictate practice, instead, practice dictates the written policy. Since there isn't a clear consensus for a rule change, I would say no change is needed, and some problems have to just be worked out one at a time. Dennis Brown - 2¢ 12:39, 28 April 2024 (UTC)

Infoboxes and such should be limited to Wikipedia related things. Text in the users own voice is their call. Subject to 1) existing policies and guidelines and 2) the user having to face the fact that others may see them as walking piles of dogshit and treat them accordingly. Free speech does not free you from the consequences of your speech. --User:Khajidha (talk) (contributions) 18:21, 28 April 2024 (UTC)

Let people post their inflammatory/demeaning/promotional/etc. statements on their userpages. Then you know who the problem users are who need extra eyes watching them. 24.24.242.66 (talk) 02:20, 29 April 2024 (UTC)

This is a very important and often overlooked point – but the risk is people may come across the problematic userpages without being clued into this implicit agreement and assume other editors have no issue with their content. There's no way for someone new to the site to tell whether we are pragmatically tolerating these editors for the sake of more easily identifying the bad ones or, you know, actually tolerating them, which leads to the chilling effects Thebiguglyalien mentioned. – Teratix ₵ 06:30, 29 April 2024 (UTC)

If we allow offensive content on user pages, one option would be to allow editors to add a notice to the top saying that these views are solely the views of the individual, and may include views considered abhorrent and rejected by the broader community. Obviously, the editor whose talk page this notice was added to would not be permitted to remove it unilaterally. BilledMammal (talk) 11:43, 29 April 2024 (UTC)

Why isn't that a standard thing anyways? I know that the encyclopedia doesn't do disclaimers, but user pages are (or at the very least are widely perceived as) not really part of the encyclopedia. --User:Khajidha (talk) (contributions) 12:17, 29 April 2024 (UTC)

There is The userpage box (I put it after someone complained my page could be mistaken for a WP page). Maybe could add to it "Please don't complain about anything here". Selfstudier (talk) 12:24, 29 April 2024 (UTC)

• The bare minimum standard for a Wikipedia userpage is it shouldn't be disruptive, go out of its way to offend other editors, or end up provoking massive timesink discussions. If a fellow editor expresses a good-faith complaint about something on your userpage, you're being an anti-social jerk if you insist on digging your heels in and doubling down on retaining it. – Teratix ₵ 06:51, 29 April 2024 (UTC)
• An alternative more fun approach could be to require all editors to include at least some offensive material on their user page, but on the condition that it is material they personally find very offensive. Sean.hoyland (talk) 11:40, 29 April 2024 (UTC)

  I would personally support that option too ;) FortunateSons (talk) 11:47, 29 April 2024 (UTC)

  I like the idea of someone working with an editor for months, finding them very rational etc., then going to their user page and 'yikes, this guy really hates baby animals and canadians. was not expecting that'. Sean.hoyland (talk) 12:11, 29 April 2024 (UTC)

  RfAs will be fun with some tripping over such materials. 😂 – robertsky (talk) 14:34, 29 April 2024 (UTC)

• content that justifies, excuses or endorses violent acts (or can be reasonably interpreted as such) is hopelessly black and white, for a start. What about "I'm proud that my grandfather fought in the Second World War", "This user is a policeman" or "I like my steak rare"? – Joe (talk) 11:51, 29 April 2024 (UTC)

  Or I support Israel's right to defend itself, which is being called genocide in many places. Animal lover |666| 07:38, 30 April 2024 (UTC)

  Assuming you are referring to armed self defence, yes, even in cases were no-one believes it’s genocide. It’s the same as Palestinian right to (violently) resist, an endorsement of use of force. FortunateSons (talk) 08:00, 30 April 2024 (UTC)

• Editors should be allowed say whatever they wish. We can't get into the business of policing speech. But the latter is conditional on use of such quotations being construed as WP:BATTLEFIELD conduct resulting in indefinite topic bans. Coretheapple (talk) 14:07, 29 April 2024 (UTC)

  Which is what we have been doing? What has been broken? – robertsky (talk) 14:36, 29 April 2024 (UTC)

Wikidata Items shown on Wikipedia?

I have come across a template, {{Public art header}}, that has among its far-too-many columns a way to list the Wikidata Item identifier (the number beginning with Q) for all the listed public art installations. It seems to me to be unique; I don't think I have seen a Wikidata Item displayed anywhere else on Wikipedia. Also, I don't think that readers will understand these Q-numbers, and clicking on them doesn't lead to some sort of trove of valuable information. Can this be fixed? Abductive (reasoning) 10:02, 30 April 2024 (UTC)

Is there a reason you've asked this question here rather than at Template talk:Public art row (where the header template talk page redirects), Wikipedia talk:WikiProject Visual arts or Wikipedia talk:WikiProject Visual arts/Public art? It seems that editors familiar with the template are far more likely to see your query there. Thryduulf (talk) 11:24, 30 April 2024 (UTC)

I've left notifications at the first and last of those locations, so hopefully someone with relevant knowledge will see your query. I'm still not sure what the connection to policy is though. Thryduulf (talk) 11:27, 30 April 2024 (UTC)

Technical

No supported authentication methods available when trying to log in to toolforge

I normally log in to toolforge using PuTTY and WinSCP, and a year or two ago I set it up (I don't remember how, except that it was a pain to do) to use a passphrase that checks a local key file on my PC. This has been working fine ever since. Today I got a message from WinSCP on connecting saying that the host key had changed (I forget the exact message). After a bit of research I trusted the host and connected successfully, using the passphrase as usual; I can see the usual directory structure for the tool I run. I then tried PuTTY and got the same message, said yes, and now the host won't let me connect. When I use the saved session I get "No supported authentication methods available" and then "Server refused our key". This surprised me because WinSCP is perfectly happy with the connection. Any help on how to get connected again would be much appreciated. Mike Christie (talk - contribs - library) 01:02, 25 April 2024 (UTC)

Update PuTTY to the newest version and it should be fine again. hgzh 07:00, 25 April 2024 (UTC)

That worked. Should have thought of that myself. Thanks! Mike Christie (talk - contribs - library) 09:55, 25 April 2024 (UTC)

Earlier versions of PuTTY have a security vulnerability [15]. Everybody should update to the latest version. Hawkeye7 (discuss) 11:19, 25 April 2024 (UTC)

Bizarre category order

I just added William Whitehead Watts to Category:Presidents of the Geological Society of London using Wikipedia:HotCat. In the past when I have done this sort of thing the new category appears last in the list of categories at the bottom of the page. For some reason it is displaying as the first on this one. Why is this and how can I stop this unwonted and unwanted behaviour? Browser = Edge on Win 11, skin = Monobook. Thank you, DuncanHill (talk) 13:44, 25 April 2024 (UTC)

That article was already in that category before your changes. It is applied automatically by Template:GLS Presidents. The reason it is listed first is because that template is used before any of the other categories are defined — Martin (MSGJ · talk) 13:49, 25 April 2024 (UTC)

Well that would explain why I didn't see it was in that category, nobody would expect it to be listed before the dates. Is it common for templates to do that? It strikes me as unnecessary and confusing. — Preceding unsigned comment added by DuncanHill (talk • contribs)

WP:TEMPLATECAT says: "However, it is recommended that articles not be placed in ordinary content categories using templates in this way." But there are still many templates doing it. Some of them have a parameter for Wikipedia:Category suppression but not Template:GLS Presidents. You could use {{Suppress categories|{{GLS Presidents}}}} and manually place the category where you want it. PrimeHunter (talk) 14:50, 25 April 2024 (UTC)

DuncanHill, if you manually add the category to each of the pages transcluded by the template, the category assignment code can be removed from the template per WP:TEMPLATECAT. – Jonesey95 (talk) 14:57, 25 April 2024 (UTC)

@PrimeHunter: I tried that and got "template loop detected". @Jonesey95: I'd happily add them to the category, but haven't the faintest idea how to remove the category assignment code from the template. Something to do with includeonly or noinclude? DuncanHill (talk) 15:01, 25 April 2024 (UTC)

@DuncanHill just remove the part of the code that has the category, don't add additional parts to the template. Gonnym (talk) 15:21, 25 April 2024 (UTC)

@Gonnym: so remove all of <includeonly>{{main other|[[Category:Presidents of the Geological Society of London]]}}</includeonly><noinclude> [[Category:Presidents of the Geological Society of London| ]] </noinclude>? DuncanHill (talk) 15:24, 25 April 2024 (UTC)

yes if you want to also remove the template itself from that category. If you want to keep the template in the category leave the noinclude section. Gonnym (talk) 15:26, 25 April 2024 (UTC)

Thank you, DuncanHill (talk) 16:05, 25 April 2024 (UTC)

{{Suppress categories|{{GLS Presidents}}}} is code which can be placed in an article using a template which automatically adds categories. Then the template wouldn't have to be edited, but the code would be needed in all articles where the category is unwanted. PrimeHunter (talk) 16:12, 25 April 2024 (UTC)

Search suggestions seem to be missing obvious choices

Tracked in Phabricator
Task T363516

Earlier today, I went to look up the article on Sonia Sotomayor, a current justice of the US Supreme Court. But to my surprise, as I started typing her name into the search bar, the search algorithm didn't seem to recognize her as a possible destination. By the time I had "Sonia So" typed in, the first suggestion was Sonia Soto (a two-sentence stub about a translator), followed by imperfect matches for the search term; once I'd typed in "Sonia Soto", it only suggested the translator; I didn't get pointed toward Sotomayor's article until I'd typed in her entire name. My first assumption was that the article title had a diacritic or something that would cause Sonia Sotomayor to be a redirect rather than the article title, but that turned out not to be the case.

I was curious whether this was a more widespread problem, so next I searched for Antonin Scalia, and had similar issues (when I typed "Antonin Sca", the first suggestion was Antonio Scarfoglio). Trying again, I searched for Joe Biden; when I typed "Joe Bi", the first suggestion was instead Joe Biden Supreme Court candidates. At this point, my suspicion was that the search algorithm was choosing to suppress the articles of political BLPs specifically - but then I found two counterexamples soon afterward. Bill Clinton showed up successfully as the first suggestion for "Bill C", whereas Reese Witherspoon was nowhere to be found when I typed "Reese With" into the search bar. Searching some other topics shows that it's not limited to biographical articles either: I had similar problems trying to search the articles for All Eyez on Me, Chemistry, and Norway, as well as for more niche topics like alkaline noodles. The search problem isn't universal, but it's affected the majority of the titles I've checked, across various obscurity levels and topic areas.

I've tested this on the desktop site and on the app, and found the same issue occurring on both platforms. I haven't been able to identify any clear commonalities between articles that are affected by this search issue. Does anyone know what might be going on? ModernDayTrilobite (talk • contribs) 15:05, 25 April 2024 (UTC)

Similar, Paula Vennells was raised earlier on the Help Desk. DuncanHill (talk) 15:09, 25 April 2024 (UTC)

FWIW, I am unable to reproduce any of the above problems. When I type the first few characters of the names of any of those people or articles, I get the expected article as one of the first two results (i.e. "chem" shows "Chemistry" as the second result). – Jonesey95 (talk) 16:28, 25 April 2024 (UTC)

I am getting the same problems. Edge on Win 11, Monobook. DuncanHill (talk) 16:46, 25 April 2024 (UTC)

For reference, the hardware I've tested on includes Google Chrome on Windows 7, and the Wikipedia app on an iPhone 13 Mini (running iOS 17.4.1). I just now tested the Wikipedia mobile website (using Safari on the same iPhone) and reproduced the issue there as well. ModernDayTrilobite (talk • contribs) 17:37, 25 April 2024 (UTC)

I'm getting the same behavior both in my Firefox Wikipedia search bar and on the desktop site. Some pages, like Abbott Elementary, don't get suggested unless the full title is typed in with correct capitalization. Jak86 (talk)(contribs) 18:33, 25 April 2024 (UTC)

I'm getting this problem with Duocylinder. TypoEater (talk) 18:59, 25 April 2024 (UTC)

The bug apparently depends on the datacenter you connect to, which depends on your geographical location. Using the WikimediaDebug extension, I can reproduce the problem when connecting to eqiad, but not when connecting to codfw. I filed this as T363516. Matma Rex talk 18:59, 25 April 2024 (UTC)

I am in the UK. I have no idea which data centre that is. DuncanHill (talk) 19:02, 25 April 2024 (UTC)

I am also seeing this: Searching for David Gilmour gives me David Gilmour Blythe, David Gilmour (historian), and David Gilmour (writer) by the time I've typed "David Gilm" but not the Pink Floyd guitarist whose page is just "David Gilmour" until I've typed the entire name, and even then it gives it as "David gilmour". Doc Strange^MailboxLogbook 19:05, 25 April 2024 (UTC)

Happens here too. Also happens with Google, Brazil, United States. All only show as suggestions when typed out in full. – 2804:F1...07:DBA8 (talk) 19:06, 25 April 2024 (UTC)

Now 'sonia sotomay' suggests Sonia Sotomayor, but 'Sonia Sotomay' doesn't. Is that normal? – 2804:F1...07:DBA8 (talk) 21:10, 25 April 2024 (UTC)

Works on the api url Matma Rex used in the report, but doesn't on rest.php, which is what my browser is trying. – 2804:F1...07:DBA8 (talk) 21:20, 25 April 2024 (UTC)

I see the correct results for 'Sonia Sotomay' now, when connecting to either eqiad or codfw, and when using either rest.php or api.php. I think you might have looked when the index was in the middle of rebuilding, and rest.php may be cached more heavily. Can you try again in a private / incognito browser window? Matma Rex talk 21:25, 25 April 2024 (UTC)

I only browse on incognito anyways, but I closed it and reopened it and tried it again on the link I used above, still no results

edit: It's working now... guess it was just more cache.

– 2804:F14:8092:9F01:3468:323E:5807:DBA8 (talk) 21:40, 25 April 2024 (UTC)*edited: 21:57, 25 April 2024 (UTC)

Redlinked category on js page

The latest run of Special:WantedCategories features a nonsense Category:+, generated by the use of [[Category:+]] text in User:HovigTheEditor/common.js — but since I don't have "editing other users' js pages" privileges I can't fix it. And while I don't particularly understand what the code is there for, it might very well be there for a perfectly valid purpose, but would still have to be coded in a way that it isn't causing the js page to become directly filed in a redlinked category itself since the text is obviously not intended to actually categorize things as plus-sign per se. So could somebody with the necessary privileges look into fixing this? Bearcat (talk) 18:00, 25 April 2024 (UTC)

Fixed. * Pppery * _{it has begun...} 18:07, 25 April 2024 (UTC)

Template assistance needed

If any template coding gurus here have the time or desire to assist at Template talk:GTA table#Is this table getting too wide?, it would be greatly appreciated. We have run into a minor formatting concern, and for the most part, have agreed on a new format that will solve the problem. Unfortunately, we need some technical assistance to move forward. Thank you. -- GoneIn60 (talk) 20:41, 26 April 2024 (UTC)

Lua date formats

Hello everyone, does anyone know how to get Lua accepted two date format at the same time? That is. YYYY-MM-DAY and DD-MM-YYYY. I have tried my all to get them both work together at the same time in lua module Wikipedia but that's impossible for me. Only one type of date format can only work at the same time.
Thisasia  ^(Talk) 06:40, 27 April 2024 (UTC)

Accepting a date like 01-02-2020 would not be a good idea at Wikipedia where some would think January 2, 2020 while others would see 1 February 2020. Where is this needed? Johnuniq (talk) 08:09, 27 April 2024 (UTC)

alright thanks for telling me that, I'm build a new dynamic and multipurpose infobox in lua by integrating all functionality in one Template, but the current programed date format is in something like 01-02-2020 so which date format is well acceptable for Wikipedia?
Thisasia  ^(Talk) 09:43, 27 April 2024 (UTC)

YYYY-MM-DD

—Trappist the monk (talk) 11:05, 27 April 2024 (UTC)

See more at MOS:DATEFORMAT. YYYY-MM-DD is the only allowed format using a number for the month. PrimeHunter (talk) 12:04, 27 April 2024 (UTC)

@PrimeHunter noted that, I have changed it, thanks for your reply.
Thisasia  ^(Talk) 12:44, 27 April 2024 (UTC)

Thanks for your reply.
Thisasia  ^(Talk) 12:45, 27 April 2024 (UTC)

Module:Date accepts a variety of dates formats, for example, 2024-04-27 or 27 April 2024 or April 27, 2024 (all allowed at Wikipedia) and only allows valid dates. Johnuniq (talk) 03:47, 28 April 2024 (UTC)

Got it, Thanks very much for pointing out.
Thisasia  ^(Talk) 05:00, 28 April 2024 (UTC)

seconding YYYY-MM-DD which is not only the most logical but also sorts properly and is an international standard jp×g🗯️ 19:00, 28 April 2024 (UTC)

Why are we going through this again when MOS:DATE was settled years ago? We don't use all-numeric dates except in certain special situations, and even then, only CCYY-MM-DD is permitted. If you want that changing, WT:DATE is the place to do it but (i) make sure that you inform WP:VPP; (ii) be prepared for massive kickback. --Redrose64 🌹 (talk) 22:07, 28 April 2024 (UTC)

Ah I see, well I wasn't actually aware of the standard at first I'm now familiarising with the policy.
Thisasia  ^(Talk) 04:49, 29 April 2024 (UTC)

DOI-based unreliable/deprecated tagging error

Resolved

Please see the note I left here; there seems to be an implementation error in the tagging system for deprecated sources based on DOI. 100.36.106.199 (talk) 13:10, 27 April 2024 (UTC)

Strange line breaks in external URL?

I'm seeing external link URLs have line breaks is the middle of the URL. The example shown is from Special:Permalink/1221061666#c-RoySmith-20240427164200-Hawkeye7-20240426124700. The URL is marked up as:

<a rel="nofollow noopener noreferrer" class="external free" href="https://peterbondspace.com/" target="_blank">https://peterbondspace.com/</a>

and the applicable CSS according to Chrome is:

.mw-parser-output a.external.free {
    word-break: break-all;
}

Is there some (good) reason break-all is being used here, or is that just a bug in the CSS? RoySmith (talk) 16:57, 27 April 2024 (UTC)

This is apparently intentional; see phab:T327334. Suffusion of Yellow (talk) 17:22, 27 April 2024 (UTC)

It is to avoid urls from overflowing the viewport and infoboxes etc. This only applies to direct links, with no display contents and without wikicode [] surrounding them. Because we know so little about the length and context of a link (think 140 continuous characters for a link component sometimes), we have to be a bit more forceful with their linebreaking. Normal 'external' wikicode links break on word boundaries, because in those situations people generally have been more deliberate with placement and for display names, words are generally a lot smaller. —TheDJ (talk • contribs) 17:23, 27 April 2024 (UTC)

OK, that makes sense, thanks. RoySmith (talk) 19:04, 27 April 2024 (UTC)

@RoySmith well from what you highlighted, the css style seems to be applied to the url link text and not the url itself otherwise the url won't work nor even be accessible because no gap or space are allowed in the url . The word-break:break-all; in css means that it will adjust every items in their html container once they reach the maximum width limits, thus preventing them from overflowing, as you highlighted here,<a>https://peterbondspac
e.com/ </a> this was treated as the link text and not the url itself
Thisasia  ^(Talk) 17:34, 27 April 2024 (UTC)

Using Firefox 125.0.2 and Windows 10, when logged out, I see the offending wrapping in the example of the original post. This also occurs if I switch skin to legacy Vector (by inserting &useskin=vector into the URL), Cologne Blue or Modern. But if I switch skin to MonoBook (in a similar manner), I then get no wrapping. It's therefore a skin thing. --Redrose64 🌹 (talk) 18:05, 27 April 2024 (UTC)

Graph:PageViews

I have an idea that would remove several thousand talk pages from Category:Pages with disabled graphs, by changing Template:Graph:PageViews to display a link to https://pageviews.wmcloud.org/. If you know how to do (what I think is) straightforward template work or otherwise have views about this, please see Template talk:Graph:PageViews#Change this to a link. WhatamIdoing (talk) 04:19, 28 April 2024 (UTC)

Strange bug on Flag of Russia article

Is anyone else also seeing this bug on Flag of Russia? There are two major headers saying "User:CheezDeez ON TOP" that appear inside the infobox (this user is also blocked for sockpuppetry, but I don't think they have ever edited this article). I can't find anything in the wikitext that might produce this text, and the bug also doesn't show up in preview mode either. Liu1126 (talk) 13:41, 28 April 2024 (UTC)

I was reverting all these edits when it was happening (in this specific case, Special:Diff/1221172528), but it seems this article didn't refresh when I undid the changes. I gave the page a null edit, and the content is fixed again now. Aidan9382 _(talk) 13:44, 28 April 2024 (UTC)

Ah, that explains it. Thanks for reverting! Liu1126 (talk) 13:48, 28 April 2024 (UTC)

Hi! I noticed the same issue in the Haaretz article (Template:Literal translation) and the Tiger article (Template:MirrorH). I see you've already reverted the vandalistic changes to both templates, but the articles I linked don't appear to have been refreshed yet. Could you refresh them as well, or otherwise let me know how I could do that? Thanks! Wavevari (talk) 15:17, 28 April 2024 (UTC)

I've gone ahead and fixed those pages. The process is called a null edit, though purging the page normally would probably also work. Aidan9382 _(talk) 15:26, 28 April 2024 (UTC)

Thank you for the fixes and for the additional information! Wavevari (talk) 15:30, 28 April 2024 (UTC)

It’s the same for the Vagina article. Autisticeditor 20 (talk) 17:40, 28 April 2024 (UTC)

never mind Autisticeditor 20 (talk) 17:42, 28 April 2024 (UTC)

Erroneous page archiving by ClueBot III

ClueBot III (talk · contribs · count · logs · page moves · block log · edit summaries) seems to be occasionally archiving pages incorrectly to Archives/_1 and ignoring the configuration on the page. Examples from various namespaces: 1, 2, 3, 4. This was reported on the ClueBot Commons talk page yesterday by @MrPersonHumanGuy: ping. Other examples can be found in the contributions log. Local Variable (talk) 13:51, 28 April 2024 (UTC)

The four pages have one things in common: inside the {{User:ClueBot III/ArchiveThis}}, the first part of the |archiveprefix= parameter does not begin with the name of the page that is being archived. For three of the four, this is because a page move occurred at some point in the recent past and the archiving config wasn't amended to suit; in the case of User talk:Spiderjiu it's because the archiving was set up badly. The other main archiving bot, lowercase sigmabot III (talk · contribs), guards agains this by refusing to archive a page when the first part of the |archive= parameter does not begin with the name of the page that is being archived. --Redrose64 🌹 (talk) 17:27, 28 April 2024 (UTC)

@K6ka has since updated the docs to advise editors to change the template when moving the page (I'm not overly optimistic editors will heed that warning). Local Variable (talk) 23:26, 28 April 2024 (UTC)

“Request Desktop Site” on IPad does not work

I would like to use Desktop mode while on my iPad (IPad Air gen 4, IpadOS 17 , safari)

Although I have “request desktop site” selected, Wikipedia redirects to Mobile (en.m.wikipedia.org)

How can I use desktop Wikipedia on iPad? Tonymetz 💬 17:22, 28 April 2024 (UTC)

@Tonymetz: "request desktop site" is a feature in some mobile browsers. I don't know whether it's supposed to work with Wikipedia. The normal way to choose the desktop version of Wikipedia is the "Desktop" link at the bottom of pages in the mobile version. The link is made by MediaWiki and not the browser. PrimeHunter (talk) 17:47, 28 April 2024 (UTC)

In fact, the browser feature does not work. phab:T60425 is the task for it. Izno (talk) 18:14, 28 April 2024 (UTC)

Thanks I’ve subscribed. 11 years let’s keep our fingers crossed. Thanks for the tip on the desktop link I see it now. It had been cut off by my iPad keyboard bar. Tonymetz 💬 22:06, 28 April 2024 (UTC)

There are userscripts that will auto redirect you from the mobile to the desktop site, User:Þjarkur/NeverUseMobileVersion for instance. -- LCU ActivelyDisinterested «@» °∆t° 18:24, 28 April 2024 (UTC)

Removing gap between templates

After updating the template styling of my user page, I managed to get most things as I wanted except for a gap between the "Start tab" template and the bordered box that comprises the rest of the page. Is there a way I could put the bordered box into the template, or make an adjustment to how they are configured, to remove the gap between them? -CoolieCoolster (talk) 23:26, 28 April 2024 (UTC)

@CoolieCoolster i have seen your page, are you referring to the gap between the "start tab" and your userboxes section, if so then I can help you with that or can you be more specific and explain properly? You may discuss with me on my talk page if I didn't respond here on time.
Thisasia  ^(Talk) 05:23, 29 April 2024 (UTC)

I meant the thin white line that appears between the template that creates the tabs and the section that encloses the rest of the page's content. As I reused the format on the other three tabs, each one has the same white gap. -CoolieCoolster (talk) 05:26, 29 April 2024 (UTC)

OK the thin whit

line e u are talking abo are you referring the start tab or your userboxe table? t
Thisasia  ^(Talk) 05:29, 29 April 2024 (UTC)

Above that; it splits the dark red section at the top in two.-CoolieCoolster (talk) 05:41, 29 April 2024 (UTC)

Pretty not much clear, but see what I found so far.

• there is a huge gap between the start tab and your userboxes section may be making it look unsatisfying since you applied the same background color to both of them
• there is also a thin line that appears at the start tab when scrolled from either left or right. But except that I couldn't figure anything else.

Thisasia  ^(Talk) 05:54, 29 April 2024 (UTC)

I'm guessing the first issue you described is what it is; both halves using the same color is intentional, as ideally I'd like to find a way for the content of the page to be within the box connected directly to the tabs, but doing so while also having a border around the page seems to be a conundrum. -CoolieCoolster (talk) 06:36, 29 April 2024 (UTC)

Alright I do have solution for that. If you do permit me i will edit your page directly, and after that if that's not what you described we can find further. But first of all, take a look at the top of this page, it has similar start tab as yours and the start tab isn't separated from the rest of the page unlike yours that splits, check and tell if this is actually your point.
Thisasia  ^(Talk) 07:02, 29 April 2024 (UTC)

Move the closing div tag to after the table...then reduce the border width? — GhostInTheMachine ^{talk to me} 07:07, 29 April 2024 (UTC)

Someone did that for me earlier today it seems, so the issue has been resolved, but thanks for the help! -CoolieCoolster (talk) 18:52, 29 April 2024 (UTC)

Curious ephemeral js error

I turned on the "display js errors" gadget a few days ago. Today I got an error something like "unhandled exception missing ) for argument list line 23". Since the gadget pop-up fades away quickly, I refreshed the page a few times to try and select and copy the error. I then took a look at the source: line 23 is (for me) }];});});</script>. After looking at this I tried again to copy the error, but it had gone. I compared the script which runs from line 6 to 23 before an after the error with an on-line diff, no apparent difference.

Anyone know why this might have happened? All the best: Rich Farmbrough 08:34, 29 April 2024 (UTC).

I got it too, so I filed phab:T363701. It happened whenever the CentralNotice banner for the U4C voting was displayed. But it stopped at some point even when I got the banner. I wonder if something was backported and fixed it. Nardog (talk) 22:44, 29 April 2024 (UTC)

The banners are maintained on Meta-Wiki as wiki pages. You can find them on m:Special:CentralNotice, if you can figure out the interface (I struggle with it). I think this was the edit that fixed it: https://meta.wikimedia.org/w/index.php?title=MediaWiki:Centralnotice-template-u4c_election2024_vote2&diff=prev&oldid=26702487 Matma Rex talk 09:18, 30 April 2024 (UTC)

Help with regex statement

Hi, I need help with the following regex, which I did not write and don't understand well enough to fix. That statement is:

(?<!/)(?<!\\?url=)https?://(?:[\\w-]+\\.)*wikisophia[.]org[\\w/.\\-#?&=]*

The intent is to match all URLs such as:

http://wikisophia.org/index.php?title=Constitution_Act,_1871_(annotated)

But not archive URLs such as:

https://web.archive.org/web/20010101010101/http://wikisophia.org/index.php?title=Constitution_Act,_1871_(annotated)

https://webcitation.org/fgT654?url=http://wikisophia.org/index.php?title=Constitution_Act,_1871_(annotated)

Currently the regex is only partially matching and returning:

http://wikisophia.org/index.php?title=Constitution_Act

..anything after the "," is not matched. Same if there is a ":" or other similar characters.

Suggestions? -- GreenC 19:21, 29 April 2024 (UTC)

You need to add the relevant characters (possibly escaped?) to [\\w/.\\-#?&=]. Izno (talk) 19:59, 29 April 2024 (UTC)

Almost any character can appear in a URL, especially after ?title=. It may be better to accept anything except whatever delimits a URL in the relevant context, e.g. for parsing {{cite web|url=http...}} use [^|}]* or for space-delimited [http... Description of page] try \\S*. The former may pick up unwanted spaces unless we complicate it as something like .*?(?=\\s*[|}]) (grab any characters, but as few as possible, as long as optional spaces then | or } follows). Certes (talk) 00:14, 30 April 2024 (UTC)

OK, building on that idea, this solution is imperfect, but it will work in most cases. I'm not using it for critical purposes (log files, counting) so YMMV:

(?<!/)(?<!\\?url=)https?://(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\\-]*[a-zA-Z0-9])[.])*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9\\-]*[A-Za-z0-9])wikisophia[.]org[^\\s\\]|}{<]*[^\\s\\]|}{<]*

The gobbly between https and wikisophia is for matching hostname(s) at multiple levels per this. -- GreenC 05:34, 30 April 2024 (UTC)

How does one correct a citation when the source is listed dozens of times?

In the entry on lyricist Robert Hunter, I noticed that at some point an editor must've accidentally cited another source that's already cited 22 times in the article. There are only three 2015 sources used, so perhaps someone inadvertantly used the wrong one. At any rate I tried to fix it using the visual editor and, while it corrected the citation, it left it with the wrong footnote number still. So I undid my failed correction and left a note on the article's Talk page. Correcting simple sources that are only cited once is pretty straightforward, but when they're used dozens of times it's another (way too intimidating) matter. Or am I simply not able to find "the easy way"? Peterh6658 (talk) 23:22, 29 April 2024 (UTC)

@Peterh6658: I've made the change you wanted, and given a link to how I did it on the article talk page. DuncanHill (talk) 23:33, 29 April 2024 (UTC)

Thanks, Duncan! I hope I wasn't out of line with that crack about the process being way too intimidating. (Another Maxwell Smart catchphrase.) I'm still a relatively new Wikipedian, and can never remember the best shortcut to help me remember that ref name technique. Peterh6658 (talk) 23:51, 29 April 2024 (UTC)

You can make this change in the visual editor too, but it's not very intuitive. There are two ways you could do it:

1. After you select the reference marker (i.e. the "^[5]"), instead of clicking "Edit" in the menu, you can just delete it (press Delete/Backspace on your keyboard), and then copy-paste the right reference marker in its place (i.e. the "^[2]").
2. Or, after you click "Edit" in the reference menu, you can click on "Change reference type" in the bottom-left corner, which will open the "Replace citation" menu – in that menu, go to "Re-use" and choose the correct citation from the list.

Hope that helps in your future editing. Matma Rex talk 10:00, 30 April 2024 (UTC)

Tech News: 2024-18

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

Example of a talk page with the new design, in French.

• The appearance of talk pages changed for the following wikis: Azerbaijani Wikipedia, Bengali Wikipedia, German Wikipedia, Persian Wikipedia, Hebrew Wikipedia, Hindi Wikipedia, Indonesian Wikipedia, Korean Wikipedia, Dutch Wikipedia, Portuguese Wikipedia, Romanian Wikipedia, Thai Wikipedia, Turkish Wikipedia, Ukrainian Wikipedia, Vietnamese Wikipedia. These wikis participated to a test, where 50% of users got the new design, for one year. As this test gave positive results, the new design is deployed on these wikis as the default design. It is possible to opt-out these changes in user preferences ("Show discussion activity"). The deployment will happen at all wikis in the coming weeks. [16]
• Seven new wikis have been created:
  • a Wikipedia in Betawi (w:bew:) [17]
  • a Wikipedia in Kusaal (w:kus:) [18]
  • a Wikipedia in Igala (w:igl:) [19]
  • a Wiktionary in Karakalpak (wikt:kaa:) [20]
  • a Wikisource in Burmese (s:my:) [21]
  • a Wikisource in Malay (s:ms:) [22]
  • a Wikisource in Georgian (s:ka:) [23]
• You can now watch message groups/projects on Translatewiki.net. Initially, this feature will notify you of added or deleted messages in these groups. [24]
• Dark mode is now available on all wikis, on mobile web for logged-in users who opt into the advanced mode. This is the early release of the feature. Technical editors are invited to check for accessibility issues on wikis. See more detailed guidelines.

Problems

• Kartographer maps can use an alternative visual style without labels, by using mapstyle="osm". This wasn't working in previews, creating the wrong impression that it wasn't supported. This has now been fixed. [25]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 30 April. It will be on non-Wikipedia wikis and some Wikipedias from 1 May. It will be on all wikis from 2 May (calendar). [26][27]

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

MediaWiki message delivery 03:31, 30 April 2024 (UTC)

Video viewing stats

Hi, is there a way to know how many readers watched a video in an article? Alaexis_¿question? 06:30, 30 April 2024 (UTC)

Yes, you can look up this data using https://pageviews.wmcloud.org/mediaviews/ (although note that it just counts total views, it doesn't show how many are coming from a specific article). For example, here's a chart of page views for a few movies listed on Public domain film: https://pageviews.wmcloud.org/mediaviews/?project=commons.wikimedia.org&platform=&agent=user&referer=all-referers&range=latest-20&files=Night_of_the_Living_Dead_(1968).webm%7CFear_and_Desire_(1953).webm%7CWings_(1927).webm Matma Rex talk 09:31, 30 April 2024 (UTC)

PETSCan and Images

I am looking to source free images for articles on plant genera that are lacking them. Therefore I was wondering whether it was possible to configure PETScan only to return pages which do not contain images. The closest thing I thought of was to show images from the metadata in the output and then scroll through them, looking for those for which no image is presented. However, that is getting progressively tedious. Does anyone know a more direct way to do this? Felix QW (talk) 09:33, 30 April 2024 (UTC)

Not an answer to your question, but the search facility may help you. A search for plant hastemplate:"automatic taxobox" insource:/image *= * returns 16,436 results with an image parameter in the taxobox. Note, it's not restricted for genera and some may have empty taxobox image parameters. Then a search for plant hastemplate:"automatic taxobox" -insource:/image *= * finds 1,298 results without the image parameter, most of which appear to be genera. The search can probably be refined. —  Jts1882 | talk  10:57, 30 April 2024 (UTC)

Proposals

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.

RfC: Converting all current and future community discretionary sanctions to (community designated) contentious topics procedure

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is a consensus that there should be clarity and consistency regarding general sanctions language, including by using the language of "contentious topics" (CTOP) rather than "discretionary sanctions" (DS). However, as most keep !votes focused on clarity of terminology rather than procedure, no consensus developed to adopt either the particular procedural proposals of this RfC or Barkeep's counter-proposal. Further discussion (and likely a follow-on RfC) is needed to determine: (1) what boilerplate text to adopt for general use in community CTOPs; (2) the proper forum for imposing or modifying community CTOP restrictions; (3) the proper forum for enforcement of community CTOP restrictions; and (4) how to handle potential deviations of community from ArbCom CTOPs. voorts (talk/contributions) 02:13, 20 April 2024 (UTC)

Notes

---

Should all community discretionary sanctions (DS) be updated to use the new contentious topics procedure? Awesome Aasim Refreshed 01:18, 8 March 2024 (UTC) 05:55, 7 February 2024 (UTC)

Background

In late 2022/early 2023, the discretionary sanctions procedure was overhauled by ArbCom and converted to "contentious topics". With now two different processes for two different kinds of sanctions there is now a lot of fragmentation and inconsistency in how contentious topics should be handled, with even conflicting wording. The main goal of this RfC is to unify the procedure used for all areas where general sanctions are in effect with the one designated by ArbCom, going forward.

As proposed at this time, there will be the some similarities and differences between community and arbitration contentious topics, including:

• The imposition of the standard set of restrictions by consensus of administrators in a community designated topic would be at WP:ANI rather than WP:AE.
• Reconsideration of contentious topic restrictions would be done at WP:AN instead of at WP:AE or WP:ARCA.
• Awareness of a community contentious topic would include but not be limited to being mentioned in the discussion closing summary regarding that contentious topic, which is the closest there is to a "final decision".

And of course, ArbCom would be able to convert community contentious topics to those designated by the committee, after which all the ArbCom venues would have to be used from that point forward, though existing restrictions would remain appealable to WP:AN until renewed at ArbCom.

Survey (community contentious topics)

• Support as proposer. It needs to be clear, especially for new editors, what contentious topics are and what the expectations are for editing topics designated as contentious by either ArbCom or the community. A unified procedure will ensure consistency rather than fragmentation and will make editing the list of contentious topics and their restrictions much easier. (I did do a little bit of work in the Module:Sanctions/sandbox adding in support for ArbCom contentious topics, as it would make it so much easier to use the related sanction templates. I also did work in user space to help envision what a unified contentious topics page might look like.) Awesome Aasim 05:55, 7 February 2024 (UTC)
• Strong Oppose The current iteration of WP:CTOP is far too tied in to the Arbitration Committee. The available sanctions and procedures are under the jurisdiction of WP:AC/PR can be modified by the Committee by motion at any time, which in this scenario would be binding on decisions made by the community without community consensus. Additionally, many of the General Sanctions areas have a set of restrictions that either exceed what CTOP would allow, or have a more limited subset of them. The community currently has the flexibility to customize sanctions based on the needs of the individual topic area (similar to how Arbcom can impose their own restrictions either alone or on top of the CTOP designation), rather than relying on a "one size fits all" solution. Regarding the possibility of Arbcom choosing to convert community-based CTOP to Arbitration Enforcement, the Committee already has the power to supercede and convert General Sanctions. They've done so before, in cases including WP:ARBCC and WP:ARBTPM. This proposal as written would reduce the community's autonomy and flexibility for the sake of consistency, and I don't see that as a net positive.
  I would, however, support the community adopting a "standard/default" DS language that could be used when customization isn't needed, and reviewing all the existing GS areas to see if they should be abolished or modernized. Updating our own process, templates, info pages etc to completely separate from the Arbcom version would also accomplish this proposal's goal of reducing confusion and would be better than the current system of sometimes linking to CTOP, sometimes linking DS which redirects to CTOP (when they really mean the older version of DS), sometimes a completely different thing with no consistency. Template:Gs/alert is one example of this, where it links to WP:CTOP even when the actual restrictions are unrelated to that designation. Revamping our own procedures would be a better way to reduce fragmentation and confusion than glomming onto what Arbcom chooses to do. The Wordsmith^{Talk to me} 18:32, 7 February 2024 (UTC)

  I am not exactly seeing how this is a dealbreaker. The CT procedure applies only to designated contentious topics; community consensus or arbitration remedies can always add additional sanctions regardless of WP:CTOP like in WP:ARBPIA. Awesome Aasim 22:13, 7 February 2024 (UTC)

• Support The phrase "discretionary sanctions" is not clear and so the phrase "contentious topics" was introduced as an improvement. We should have clear and consistent language for contentious matters so that discussions and actions are comprehensible. Andrew🐉(talk) 08:57, 10 February 2024 (UTC)
• Support. The "sanctions regimes" are too complex as it is, and we need to use consistent terminology to reduce that complexity when possible.  — SMcCandlish ☏ ¢ 😼  13:03, 21 February 2024 (UTC)
• Support. The contentious topics procedure incorporates all of the improvements from the 2021-22 review of the discretionary sanctions procedure. Compared to the discretionary sanctions procedure, the contentious topics procedure is much easier to understand and follow. For example, many editors currently need to be reminded of topic areas under community sanctions every 12 months to be eligible for certain remedies, which led to complaints in the 2021-22 review. Switching from discretionary sanctions to contentious topics would eliminate this requirement: "Editors no longer need to be alerted every 12 months, as they are presumed to remain aware after their first alert." — Newslinger talk 04:45, 9 March 2024 (UTC)
• Support making the rules clear and consistent to all users. A big part of the problems I've had with DS is that I couldn't tell what was expected of me. No comment on whether this new way of doing things is better or worse than the old one, but it sounds like this isn't that conversation. I 100% support clear and proactive explanations of what Wikipedia does and does not want from its editors. Darkfrog24 (talk) 16:10, 9 March 2024 (UTC)
• Support making the rules clear and consistent for all editors. Let'srun (talk) 19:33, 10 March 2024 (UTC)
• Support standardization — as is, the current discrepancy is an unintended relic, not a feature. Community-imposed vs Arbcom-imposed sanctions is a clerical, technical distinction, and I cannot think of any good reason not to streamline the two into the same concept, for the sake of simplicity and understanding. ~Swarm~ ^{sting} 02:39, 12 March 2024 (UTC)
• Support Contentious topics is confusing enough by itself. Two similar but not identical rules is too much. I support any efforts to standardize our sanction systems. Galobtter (talk) 02:53, 12 March 2024 (UTC)
• Support in the abstract – it might require some case-by-casing, but I think in general, having one set of rules for everyone is much cleaner and easier to understand for those trying to follow the road. theleekycauldron (talk • she/her) 00:00, 17 March 2024 (UTC)
• Oppose (despite abstract support) as ANI has generally been the wrong forum for General Sanctions work. In my mind it should be a pump or AN and ANI should be out of the whole system. I also think it's a missed opportunity to not allow community GS to be heard at AE. There is already the community option for AN but this proposal would have created the option of using AE which is the forum many think about anyway. Outside of these details I'm supportive of the effort (given the fact that amongthe few who have expressed an opinion there seems to be overall support). Barkeep49 (talk) 14:55, 21 March 2024 (UTC)

  Would you support having community contentious topics use the ArbCom noticeboards instead? Awesome Aasim 17:35, 29 March 2024 (UTC)

  That seems like it would be confusing using Arbitration Enforcement, since some sanctions would be relevant to Arbcom and some wouldn't. There's a workable idea in here somewhere, and I think unifying all the sanctions noticeboards into one venue is it. There used to be Wikipedia:Community sanction noticeboard where appeals were heard, before it was retired in 2007 and merged into AN. Having something like a Wikipedia:Sanctions noticeboard that merges General Sanctions enforcement/appeal, requests for new General Sanctions areas that are now at the Village Pump, Arbitration Enforcement/CTOP, and topic ban enforcement into one unified board. The structure of requests there should probably mirror the current AE pretty closely, since that format seems to work better than the free-for-all unstructured discussion at other boards. The Wordsmith^{Talk to me} 18:28, 29 March 2024 (UTC)

  If I recall correctly ArbCom has authorized the use of AE for community general sanctions using DS/CT. Is that still the case or was I wrong the whole time? But that is what I refer to "using ArbCom noticeboards". Awesome Aasim 05:08, 30 March 2024 (UTC)

  When the shift was made to Contentious Topics, the option was made explicitly for the community to use AE if it wished. Barkeep49 (talk) 22:45, 16 April 2024 (UTC)

  My problem with relying on AE for them is that decisions there are ultimately made only by administrators and rely heavily on ArbCom decisions in turn. ArbCom is the last stop for things that the community has failed to handle, and administrators are the second-to-last stop; but for thing like DS/CTOP designations, which can have a sweeping practical impact on editing across a large section of the wiki, the initial decision-making ought to be made by the community as a whole. --Aquillion (talk) 17:45, 17 April 2024 (UTC)

• Oppose Ivan (talk) 20:58, 21 March 2024 (UTC)
• Support - I don't have anything to add beyond what Galobtter said - perfectly expressed. —Ganesha811 (talk) 01:18, 22 March 2024 (UTC)
• Oppose as written but open to most of the content of the proposal, per Barkeep49. _signed, Rosguill ^talk 17:49, 29 March 2024 (UTC)
• Oppose for the exact reasons given by Rosguill. Dennis Brown - 2¢ 23:50, 29 March 2024 (UTC)
• Oppose Wikipedia:Community discretionary sanctions isn't even active, so why would it be merged? — xaosflux ^Talk 17:30, 1 April 2024 (UTC)

  The proposal is for community-authorized discretionary sanctions to be modified to follow the contentious topics procedure. isaacl (talk) 17:39, 1 April 2024 (UTC)

  Thanks, so just a really misleading title. Reaffirm oppose though, we should not abandon a community process further in to arbcom. — xaosflux ^Talk 17:46, 1 April 2024 (UTC)

  My apologies for being overly concise in my previous comment: the proposal isn't to abandon community-authorized discretionary sanctions, but to align its procedures with the contentious topics procedures. It would remain under community control, with the changes to procedure that were introduced as part of contentious topics (such as a standard set of restrictions, sanctions no longer being limited to a year, only one template-based notification required for the first notification about contentious topics). isaacl (talk) 17:57, 1 April 2024 (UTC)

  This is still a very confusing proposal, as it is not very clear about what exactly it wants changed. For example, I can't see why something that has nothing to do with arbcom remedies would need to be recorded at Wikipedia:Arbitration enforcement log (per the WP:CTOP requirements that this proposal appears to to merge in). — xaosflux ^Talk 10:31, 2 April 2024 (UTC)

  Further development of the details do still need to be worked out. Community-authorized discretionary sanctions was defined by pointing to the arbitration committee discretionary sanction pages and saying, like that, but with a few differences. When those pages were renamed, that left a hole. In my view, ideally the community would define its preferred base procedure, and then the arbitration committee could point to it and say like that, but with a few differences. Those differences could include locations of logs and appeals (this proposal does explicitly specify a different location for appeals). I appreciate the viewpoint of those who would prefer to have a separation based on the group responsible for the designation of a contentious topic. But maybe that purpose can be served another way, such as a lookup table with appropriate links to the specifics for each variant. From the perspective of users encountering the concept of discretionary sanctions/contentious topics for the first time, I feel it's confusing to be using both the older version and the newer version of the process simultaneously. isaacl (talk) 15:39, 2 April 2024 (UTC)

  Which is why I'm leaning that this is a bad proposal. It should have been work-shopped more first. Make X like Y, but not really like Y is messy. — xaosflux ^Talk 14:09, 3 April 2024 (UTC)

• Support it will be easier to understand the community-imposed restrictions and could allow the same templates to be used to make the process more unified. Dreamy Jazz ^{talk to me | my contributions} 18:03, 1 April 2024 (UTC)
• Conditional support "Discretionary Sanctions" needs to be deprecated – the phrase is archaic, bureaucratic, and meaningless. However, the noticeboard should not be ANI (per Barkeep), since that place is a mess, whereas sanctions enforcement should be more clear-cut than the usual ANI fare. Toadspike (talk) 09:48, 3 April 2024 (UTC)
• Support unifying community discretionary sanctions under the contentious topics procedure as it promises to significantly simplify Wikipedia's administrative framework, especially for new users. Adopting one coherent, streamlined process will mitigate the confusion and frustration associated with understanding the diverse existing sanctions systems. FailedMusician (talk) 21:48, 12 April 2024 (UTC)
• Support as a starting point, although there are a lot of details to hash out and we should probably approach a community CTOP policy page bit-by-bit rather than trying to create it in one go via an RFC. (I am not sure ANI is the best place for this for reasons I'll get to in a moment, it's just better than what we have.) It's important that there be a way to create or modify CTOPs that the entire community can weigh in on and form consensus around; they can drastically affect editing in an entire swath of the wiki. ArbCom's remit is only to resolve problems that the community has failed to solve, and neither they nor administrators are supposed to be creating or modifying policy by fiat, so given how widespread and central CTOPs have become, it makes no sense for the only way to modify CTOPs to be decision-making processes that go only through administrators or arbcom. In fact I would go a step further (though I think doing this cleanly would require cooperation with ArbCom and agreement on their end to modify existing CTOPs in this regard) and say that a clear, unambiguous community consensus on a particular CTOP ought to be able to move it from ArbCom to community control, since it is an indication that the community can now handle it. CTOPs have grown drastically from their initial origins and affect enough of the wiki (in a way that effectively amounts to an intricate set of policies affecting much of our editing) that it no longer makes sense to leave ArbCom as the final decision-maker regarding them, at least in situations where the community can reach clear and unambiguous agreements. I do agree with some comments above that a noticeboard rather than AN / ANI would be a better place to do things related to CTOPs, though - the whole issue is that CTOPs have grown to the point where they are effectively policy, which means that outside of emergencies or situations where the community has failed to handle one, the first line of control over them should be with the community as a whole, not with administrators or ArbCom. --Aquillion (talk) 17:45, 17 April 2024 (UTC)

Discussion (community contentious topics)

Cooperation of ArbCom

I wonder if adding in stuff to the WP:CTOP page and similar would require the petition and referendum process. If so, then I guess the merging of templates would have to hold off until a former petition and request for amendment actually passes. It is possible ArbCom will green light the merge if this RfC passes, but I do not know. Awesome Aasim 05:55, 7 February 2024 (UTC)

I feel the community should work with the arbitration committee to assume responsibility for the contentious topic process, with a pointer to an arbitration-committee specific page where it can customize the process as it feels necessary. This would bring the process under community control, while still allowing the arbitration committee to adapt it to its needs. (There is no change to arbitration policy and so no need to amend it.) isaacl (talk) 19:07, 7 February 2024 (UTC)

Wouldn't that just be the status quo (or perhaps the old GS/DS) status quo? I think Arbcom is more agile than the community in drafting this kimd language given that passing a motion is easier than an RfC and motions can be adjusted mid vote which is nearly impossible to do with an RfC. Truthfully I think the right place to start is with the standardized language for community GS and perhaps to be more intentional about whether it wants its restrictions to be eligible to be heard at AE, though as The Wordsmith points out there are really good reasons for the community to decide not to do that. Barkeep49 (talk) 04:30, 9 February 2024 (UTC)

The process for authorizing discretionary sanctions was documented by the committee, and then later the community started authorizing discretionary sanctions, with its process pointing to the Arbitration Committee pages and saying, "like that". This resulted in the community's process being coupled to decisions made by the arbitration committee. I'm suggesting the reverse: have the community assume responsibility for the contentious topics process, and then the arbitration committee can point to it and say, "like that, but with our specific customizations". I agree the community can decide on its own on what contentious topic process it wants to create. I think it would be good, though, to check with the committee that it is amenable to adopting the community process as a base, and layering any desired differences on top. isaacl (talk) 04:52, 9 February 2024 (UTC)

That also sounds like a good idea: community authorizes the remedies that are appropriate, ArbCom implements them. If ArbCom were to deviate then they would just need to ask the community whether it is an appropriate deviation or not. Awesome Aasim 17:28, 9 February 2024 (UTC)

The committee doesn't have to be constrained by the community as it is already authorized through the arbitration policy to enact remedies of its devising for matters within its scope. It would be simpler for editors to understand, though, if the arbitration committee version of the process was just a set of differences upon a common process. Differences could include things like additional administrator actions that could be performed, or a specific venue for appeals. isaacl (talk) 18:03, 9 February 2024 (UTC)

I think you know what I mean :)

WP:ARBECR is already used a lot by both the community and by ArbCom, like in WP:RUSUKR and WP:CT/A-I. What I am saying is if ArbCom feels that a specific sanction that there has never been any precedent for is necessary, they should propose it to the community, where there then can be consensus on the exact wording. Placement, enforcement, and appeals are all going to differ though depending on whether the restriction is placed by the community or ArbCom. Awesome Aasim 18:43, 9 February 2024 (UTC)

The community can provide feedback on proposed decisions. I disagree that the committee needs to obtain community consensus on new types of remedies. The arbitration committee is empowered to impose a restriction that community consensus has been unable to reach through prior dispute resolution. If you are referring specifically to the standard set of restrictions that can be imposed for designated contentious topics, I still disagree that community consensus should be mandatory. Typically the committee will provide an opportunity for feedback and the last review of discretionary sanctions illustrates that it strives to lighten the load of enforcing administrators. isaacl (talk) 19:17, 9 February 2024 (UTC)

Regarding the extended-confirmed restriction, it was initially devised by the committee on its own. After taking some time to evaluate its effectiveness, the community chose to adopt it as an available restriction. isaacl (talk) 19:25, 9 February 2024 (UTC)

I agree with isaacl that ARBPOL and CONEXEMPT explicitly mean that the committee does not have to, with-in its scope, get community consensus.

However, ECR is a example of why I think the committee is better placed at the moment to be a leader when it comes to contentious topics. The committee having to deal with the absolute hardest conflicts means there is going to be more of an incentive to try something new and ~15 people are going to have an easier time getting to yes than what is required to get community consensus for that newness. It's also revealing to me that ArbCom gets more requests for us to assume community imposed sanctions (examples: COVID, Horn of Africa as two that the committee did assume and Russia-Ukraine War as one that committee has twice been asked to assume and haven't). I would really love it if the community could, as it does in so many other ways, demonstrate broader capabilities when it comes to general sanctions than it has in the past. And to that end getting consensus for some standard wording would be a great place to start. Barkeep49 (talk) 19:48, 9 February 2024 (UTC)

I agree that the arbitration committee is better positioned to try new approaches (consensus doesn't scale up well, so getting consensus amongst 15 people is definitely easier). In a similar vein as you expressed, I feel it would be ideal for the community to agree on a base contentious topics process, which the committee could extend in new ways that the community could later choose to incorporate back into the base process. isaacl (talk) 19:57, 9 February 2024 (UTC)

• I mentioned this in a big reply below already, but I feel one possible solution to this is to allow the community to take control of ArbCom community sanctions once they're stable (through a clear consensus of editors somewhere), transferring them to community CTOPs. This allows ArbCom to act swiftly and impose CTOPs in situations where the community would inevitably be slow-to-act, and simplifies community decision making because they can just take solutions ArbCom has created and tweak them slightly if necessary; but it avoids the situation we have now where ArbCom functionally takes control of moderation over entire topic areas indefinitely, which IMHO is something we want to avoid. --Aquillion (talk) 18:05, 17 April 2024 (UTC)

• I do agree that it's worth considering ways to transfer more control over the CTOP process to the community; it affects so much of the wiki now, and is so forceful, that it has effectively turned into policy-by-fiat, which ArbCom wasn't supposed to do. But I'm not sure its feasible to simply transfer the entire thing to the community at once. What I would suggest (and suggested above) is the following. First, create a community CTOP page that is totally separate from ArbCom's (aside from maybe mentioning it for historical reasons), and encourage ArbCom to use that as the basis for its CTOPs, in the same way most of the other things ArbCom does relies on community-created policy. Second, establish that a clear and unambiguous consensus among a sizable number of uninvolved editors can transfer an ArbCom CTOP to community control and place it under the community CTOP rules. (This would probably require that ArbCom agree to modify existing CTOPs to add a line about how the community can take control of it in that manner.) The principle here is that ArbCom is only supposed to be handling things that the community can't; declaring that governance of an entire topic area is a problem that the community has failed to handle, indefinitely, seems like it's too much - it's a lot bigger than ArbCom handling just one person's ban! But it is true that sometimes things break down and require ArbCom intervention on a large scale or we wouldn't have CTOPs in the first place. Creating an "escape hatch" for once things settle down that allows things to transfer back to community control would leave ArbCom with the tools it needs for emergency situations that the community has failed to handle, while allowing for a way to smoothly return to community control once ArbCom's solutions have settled things and a consensus has built around that (avoiding the situation we have now where entire topic areas are under ArbCom control indefinitely.) --Aquillion (talk) 17:57, 17 April 2024 (UTC)

  That seems to match my suggestion: make the process a community-defined one, and work with the arbitration committee to define its process as an add-on to the community-defined process. Transferring all of the arbitration committee-designated contentious topics at once to community-designated ones isn't being proposed, and I agree it wouldn't be a desirable approach. isaacl (talk) 18:05, 17 April 2024 (UTC)

  (edit conflict) @Aquillion: Regarding transferring things from ArbCom control to community control. There defacto already is a procedure for this - a request for amendment to the relevant case/motion that authorised the CTOP designation. The request would need to unambiguously state that the intent was to transfer all or part of the topic from ArbCom control to community control to avoid it being confused for a request to remove the designation entirely but other than that wouldn't need to be anything special, although if I were an arbitrator reviewing such a request I'd want to see three things:

  1. Community consensus that such a transfer was desirable
  2. Community consensus that the community does feel able to handle enforcement of it (and no evidence that it can't)
  3. Evidence that CTOP is still required (because it it isn't then it would be preferable to just remove the designation)

  Yes, this does mean that it would be ArbCom giving control to the community rather than the community taking control from ArbCom, but we elect arbitrators to listen to the community desires and not act unreasonably in matters like this. I also see it as a protection against a vocal minority that doesn't have the consensus it claims to. Thryduulf (talk) 18:16, 17 April 2024 (UTC)

In WP:DS2022, one of the changes made was to allow the community to make use of AE. I think we should do so. HouseBlaster (talk · he/him) 03:42, 9 February 2024 (UTC)

I definitely think we should split contentious topics from WP:AELOG. A separate contentious topics log would make restrictions much easier to follow - and, if the restriction is rescinded or converted from community to ArbCom or the other way around - it can be logged as well. Awesome Aasim 21:21, 10 February 2024 (UTC)

Request revision to initial question

The statement all community general sanctions (DS) in the initial question is misleading. "General sanctions" is not synonymous with community authorization for discretionary sanctions. I think the intent should be clarified that the proposal only affects discretionary sanctions authorized by the community, and not all general sanctions. isaacl (talk) 19:03, 7 February 2024 (UTC)

Isaacl Done. Awesome Aasim 20:07, 7 February 2024 (UTC)

Tag Refreshed

I refreshed the RfC tag because there is not enough input to gauge consensus. Could this be because this is uncontroversial or what? Awesome Aasim 19:58, 8 March 2024 (UTC)

Could well be :) Selfstudier (talk) 10:27, 9 March 2024 (UTC)

I think it's because many editors simply don't know what's going on. I didn't know this discussion was taking place. I'm still not sure what the change in policy is, only that, if it has been changed, the system should be clear about it. Are we dissolving Discretionary Sanctions? Is AE not going to be a thing any more? Is it merging with ANI? Darkfrog24 (talk) 22:37, 17 March 2024 (UTC)

@Darkfrog24 The question is really just about making community sanctions use the new contentious topics procedure. Awesome Aasim 23:45, 17 March 2024 (UTC)

Okay. What is the new CT procedure? Do you know how it's different? I just read through one of the links that Newslinger provided above, and I'm having trouble picking out differences. Darkfrog24 (talk) 00:35, 18 March 2024 (UTC)

For full details, see Wikipedia:Contentious topics. It's basically a renamed version of discretionary sanctions, with changes made based on community feedback received during the 2021–22 review of discretionary sanctions. Some highlights: there is a standard set of restrictions that a single administrator can impose on their own discretion. Restrictions outside of these can be imposed by a consensus discussion at the arbitration enforcement noticeboard. Sanctions are no longer limited to one year, but after a year, sanctions that were imposed by a single adminstrator no longer have to be discussed at the arbitration enforcement noticeboard to be modified. Users no longer have to be made aware of each specific topic area. They only have to be notified once using a specific template about the contentious topic system. Striking out inaccurate description. isaacl (talk) 01:56, 18 March 2024 (UTC)

Users no longer have to be made aware of each specific topic area. They only have to be notified once using a specific template about the contentious topic system. That would contradict the CTOP regime. Even among the Arbcom sanctions, editors still have to be notified about topic areas individually. The Wordsmith^{Talk to me} 19:54, 18 March 2024 (UTC)

My apologies; I misspoke. A specific template only has to be used for the first notification about the contentious topic system in general. Subsequently, any form of notification can be used to inform a given user about specific contentious topics. Previously, a specific template had to be used for each affected topic area. isaacl (talk) 21:22, 18 March 2024 (UTC)

Again, not all community sanctions, but community-authorized discretionary sanctions. isaacl (talk) 01:36, 18 March 2024 (UTC)

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

Follow Up Discussion

Firstly, does anyone want to help update all the community "discretionary sanctions" to community "contentious topics" in the relevant terminology? And secondly, what parts of the CT procedure should the community adopt and which ones should the community not? I think community should adopt a contentious topics policy (and the existing WP:CT could be moved to Wikipedia:Arbitration Committee/Contentious topics). It should detail all of the restrictions that may be issued under a CT designation, and when nonstandard restrictions may be used, etc.

I think it would be a good idea to merge Template:Gs/alert with Template:Ct/alert/first (as well as similar GS templates with CT templates) and to have one module for handling both community and arbitration contentious topics. Awesome Aasim 00:45, 21 April 2024 (UTC)

Create an alias for the Template namespace

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

--Task created Cocobb8 (💬 talk • ✏️ contribs) 20:22, 29 April 2024 (UTC)

I am proposing that tp: be added as an alias to the Template: namespace per this discussion.

Note: Though previous aliases were already listed on perennial proposals, it proposed t:, which would have conflicted with some article titles, or be confused with the Talk: namespace. Tp:, on the other hand, wouldn't, and would make it way quicker to look up a template in the search bar.

Edit (during rfc): tp: was not fully supported due to it being confused with "Talk Page", however other options were proposed, like hard coding {{ being replaced by Template: in the search bar, or other aliases like tmp:. Cocobb8 (💬 talk • ✏️ contribs) 15:19, 16 March 2024 (UTC)

• Oppose "Template" is not a long word, and nobody abbreviates it as "tp" these days. This seems pointless. * Pppery * _{it has begun...} 15:27, 16 March 2024 (UTC)

  I just thought it'd make it consistent with wp: for Wikipedia:, which is 10 characters, while Template: is 9 characters. Cocobb8 (💬 talk • ✏️ contribs) 15:29, 16 March 2024 (UTC)

  Nobody abbreviates it as "tp" these days. Even if that is true it is not a reason for us not to do so. Wikipedia is big enough to be making fashions rather than following them. Phil Bridger (talk) 21:16, 16 March 2024 (UTC)

  Well said. — Frostly (talk) 06:28, 5 April 2024 (UTC)

• Support I'd find it useful. It's less effort to type "tp:infobox person" in the search box than "template:infobox person" (which is how I usually navigate to wp: and template: pages). Schazjmd (talk) 15:52, 16 March 2024 (UTC)
• Support per Schazjmd. 🌺 Cremastra (talk) 15:57, 16 March 2024 (UTC)
• Support I'd absolutely love this. I've often wondered if there was some technical problem that was preventing us doing this. Usedtobecool ☎️ 16:00, 16 March 2024 (UTC)
• Support: Pretty nice QOL change. Per Schazjmd. ARandomName123 (talk)^{Ping me!} 16:35, 16 March 2024 (UTC)
• I don't think it's a good idea to create an alias (and implicitly creating more English Wikipedia jargon) just to improve the search function. We should instead improve the search capability directly. isaacl (talk) 17:41, 16 March 2024 (UTC)

  Yeah, but you don't want a casual reader to be confused as to why they ended up on a template page Cocobb8 (💬 talk • ✏️ contribs) 17:42, 16 March 2024 (UTC)

  It would be a lot easier for the casual user to stumble upon a namespace alias, which could happen anywhere they enter an URL that might trigger a browser to launch, than for them to deliberately select the search box and type there. Furthermore, if this isn't intended to be used by a broad audience, then a more targeted solution would be better. Users wanting this functionality can make use of the script to which you were pointed in the previous thread, or they can configure their OS to provide an appropriate macro expansion to shorten the number of keystrokes they use. isaacl (talk) 18:08, 16 March 2024 (UTC)

  For reference, the script seems to be User:Ahecht/Scripts/TemplateSearch. jlwoodwa (talk) 04:53, 18 March 2024 (UTC)

• "tp" seems very easily misconstrued as "Talk Page" at a glance. CMD (talk) 18:12, 16 March 2024 (UTC)

  Good point. Sdkb ^talk 18:22, 16 March 2024 (UTC)

• Support I've been wanting this. It really is irksome to type out "Template:" I since learned today there are scripts, and of course {{tld}} for talk pages, but it would be much cleaner and simpler to have a standard abbrev. and this is technically easy to implement. TP: or T: it doesn't matter they both are fine. I prefer T: -- GreenC 18:56, 16 March 2024 (UTC)
• Comment: Unless I'm missing something, the TP: prefix was proposed in 2015, in a discussion which was closed as no consensus - Wikipedia:Village pump (proposals)/Archive 127#Prefix suggestion: TP: for Template:. All the best. ‍—‍a smart kitten_[meow] 19:00, 16 March 2024 (UTC)
• Oppose For the reasons in WP:PEREN#Create shortcut namespace aliases for various namespaces. In particular, the Template namespace is generally not linked often enough that saving the typing of 6 characters is likely to be at all worthwhile and there's nothing available to use for the corresponding talk pages. Anomie⚔ 20:00, 16 March 2024 (UTC)
  • there's nothing available to use for the corresponding talk pages See Nirvana fallacy. — Frostly (talk) 06:29, 5 April 2024 (UTC)
• The template for linking a template is called {{tl}}. Shouldn't we have some consistency between this and the short-cut? Or is "tl" already used? Phil Bridger (talk) 21:16, 16 March 2024 (UTC)

  @Phil Bridger tl is ISO639 for tagalog. — xaosflux ^Talk 22:20, 16 March 2024 (UTC)

  {{tl}} is short for {{template link}}, so the el doesn't have anything to do with templates qua templates. jlwoodwa (talk) 04:31, 18 March 2024 (UTC)

• Support – While there are helpful template shortcuts, like {{t}} and its siblings, that can be used in discussions, and a script that can be used in the on-wiki searchbox to convert {{ to Template:, a namespace shortcut (tp:) would help in edit summaries and customised browser search boxes. -- Michael Bednarek (talk) 23:55, 16 March 2024 (UTC)
• Oppose Adding layers of obfuscation is not helpful. If I want to refer to {{convert}}, writing Template:Convert is easy and helpful to someone reading my comment. Writing Tp:Convert is unnecessary jargon that saves under a second of typing at the cost of head-scratching for readers. tp would be "talk page" for many. Johnuniq (talk) 01:00, 17 March 2024 (UTC)
• Oppose As someone who has next to no involvement with template editing, I immediately think of 'talk page' when I see 'tp'. It would confuse many people who edit outside of the technical areas of Wikipedia. (Summoned by bot) JML1148 ^{(talk | contribs)} 06:57, 17 March 2024 (UTC)
• Rename the template mainspace from "Template:" to "Plantilla:" and use "Pl:" as a shortcut CactiStaccingCrane (talk) 18:02, 18 March 2024 (UTC)

  That would be quite a big change, but I'm not against it lol Cocobb8 (💬 talk • ✏️ contribs) 19:50, 18 March 2024 (UTC)

  But this is in español ROTFL -- ZandDev 13:45, 20 March 2024 (UTC)

  Yeah there's no way we'll get consensus on that one Cocobb8 (💬 talk • ✏️ contribs) 13:46, 20 March 2024 (UTC)

  Yea, no. Also even on eswiki that uses that namespace name this couldn't happen as Pl is ISO639 for Polish. — xaosflux ^Talk 09:40, 21 March 2024 (UTC)

• Soft Oppose I'd support hard-coding {{→Template: into the search box's autocomplete natively rather than using my script as a hack, but I agree that the widespread use of links like TP:Example are an unnecessary layer of obfuscation/jargon. With the WP prefix, at least the shortcut links are mostly self explanatory, but it wouldn't be obvious to a newcomer what, for example, tp:birds is, or why it's not an article. --Ahecht (TALK
  PAGE) 18:17, 18 March 2024 (UTC)

  @Ahecht Yes, hard-coding that directly could be a great alternative. I just think that we need to find a solution for this, and maybe tp: wasn't the best as others have pointed out. I'll continue gathering some ideas and then conduct a sub-RfC to see what option would be best, as long as the consensus doesn't seem to be oppose. Cocobb8 (💬 talk • ✏️ contribs) 19:52, 18 March 2024 (UTC)

• neutral i could go either way. I like the hard coding option of having 'template' be dropdown option in the menu. Slacker13 (talk) 01:29, 20 March 2024 (UTC)
• Support – I don't think that adding the t: will add an another level of obfuscation. The current method of making interwiki link is already obscure and complicated, specially for newbies, instead a simple alias to the template namespace will be easy and handy in researches. -- ZandDev 13:57, 20 March 2024 (UTC)

  Note that I suggested tp: though, not t: as it was rejected previously: does that work for you? Cocobb8 (💬 talk • ✏️ contribs) 13:58, 20 March 2024 (UTC)

  @Cocobb8: I'm in favor to the proposal of create an alias for the template namespace, but I believe that I, when I would see one of these link, would not associate tp: directly with templates, but with talk pages. -- ZandDev 16:04, 26 March 2024 (UTC)

• Oppose I do work with templates but I feel that this is not an intuitive shortcut and could easily be confused with "talk page". (t · c) buidhe 04:57, 21 March 2024 (UTC)
• Support , I had typed TP: prefix in the past thinking that I would get the template page without success. This would be useful in different scenarios (just like the WP: prefix). And its use is optional, so if someone doesn't like it, they can go with the full Template: as ever. Alexcalamaro (talk) 05:32, 21 March 2024 (UTC)
• Oppose. Unnecessary, and just as with T=Talk, TP=Talk Page. _wjemather^{please leave a message...} 08:01, 21 March 2024 (UTC)
• Neutral Agree with the principle, would prefer access to a shortened version; but also agree that the proposal is too close to talk page. Regards, --Goldsztajn (talk) 22:08, 21 March 2024 (UTC)
• I think supporting {{ in the search bar would be sufficient to support the use case of issue. But beside that, I agree with oppose comments above. Izno (talk) 02:48, 22 March 2024 (UTC)
• Oppose per above. Not intuitive and I'm not convinced this solves a genuine problem -Fastily 21:26, 24 March 2024 (UTC)
• Strong support because I have typed "Twmplate" in the search bar too many goddamn times. Mach61 21:03, 26 March 2024 (UTC)
• Support: I have to do everything on mobile, and am looking up templates all the time. This would make that a significantly less laborious and typo-prone experience. But I'd be happy with some other 2- or 3-letter shortcut if TP: is a problem. No more than 3 letters, though. Also I keep typing TP:, TMP: or TPL: without thinking, expecting them to work. But I only want it for search purposes. I'd be opposed to its use as jargon for referring to templates. — Preceding unsigned comment added by Musiconeologist (talk • contribs) 01:34, 28 March 2024 (UTC)

  To help you out immediately, you can use the text expansion feature or apps on your phone to expand an abbreviated string to a longer one. isaacl (talk) 01:43, 28 March 2024 (UTC)

  Well yes, this is rather basic and I've already got a vast number of shortcuts set up. The one I'd naturally use for templates translates tem into {{|}}. There are two points, though: (i) it's counterintuitive and annoying that the whole word is needed, in contrast to wp: etc.; and (ii) beyond three characters, it stops really being a shortcut because it's only a bit shorter. Part of the annoyance is in having to remember that there isn't a 2-letter prefix to use. Musiconeologist (talk) 00:43, 10 April 2024 (UTC)

• Alias {{ (if technically possible): no ambiguity and concise. Typing {{Rfc should take you to Template:Rfc and so should {{Rfc}}. I'm neutral on aliasing TP as the ambiguity may be balanced out by utility. I like T better despite previous community rejection. — Bilorv (talk) 22:37, 29 March 2024 (UTC)

  It is technically possible for {{ to be implemented, and there already is code for it if you want to try it out. Cocobb8 (💬 talk • ✏️ contribs) 22:41, 29 March 2024 (UTC)

• Support any shortcut except just T. Aaron Liu (talk) 02:00, 30 March 2024 (UTC)
• Support saves me a few characters/seconds when accessing templates through the search bar, might even make up for the seconds wasted to write this comment. Tl, tmp or tpl works for me if people object to tp. Draken Bowser (talk) 21:24, 3 April 2024 (UTC)
• Support, this is an excellent idea. I type "Template:" in the search box a lot and it seems many other users do as well, so it makes sense to add a prefix. Preferably it wouldn't be "TP" if a good amount of people have issues with that; I don't care about what ends up being chosen as it remains relatively short (2 or 3 letters). ― novov (t c) 02:59, 6 April 2024 (UTC)
• Support. Aliasing {{ is less preferable to me because a shortcut would also allow shortening template links in edit summaries, where {{tl}} is unavailable. The particular shortcut used doesn't matter to me, just that I won't have to type "Template:" every time. Nickps (talk) 12:46, 8 April 2024 (UTC)

  Think about the possibility of [[{{example}}]] Aaron Liu (talk) 15:11, 8 April 2024 (UTC)

  No. Why should we introduce a way to link to pages that only works in edit summaries and nowhere else? (Note that using it elsewhere will transclude example instead.) TMP:example on the other hand, will work in Search, in talk pages and in edit summaries and the fact that it's a unified syntax makes it easier for non power users to learn. I'm not opposed to introducing {{ for Search (alongside a regular shortcut) as long as we take measures to make sure that people don't end up on the wrong page. That is, if e.g. {{foo}} exists we should add a {{technical reasons}} hatnote to Template:foo/doc. Nickps (talk) 16:21, 8 April 2024 (UTC)

  @Nickps It's already impossible to start a title with a bracket, see [28] Mach61 12:25, 9 April 2024 (UTC)

  I'm aware. That doesn't mean there aren't topics whose WP:COMMONNAMEs start with {{. Nickps (talk) 12:57, 9 April 2024 (UTC)

• Support. I've been at this for ten years and still hate calling up a template doc because it requires so damn much typing. The more typing, the more opportunity for typos that have to be corrected (and I'm good at typos). No objection to something other than TP, such as TM, although no doubt someone would say that could be confused with something else. The longer it gets (e.g. TMP), the less benefit. Something like this doesn't need to be descriptive, just easy to remember. ―Mandruss ☎ 05:02, 9 April 2024 (UTC)

  Doc pages don't require much more typing - and if four characters is too many, there is always the "view" link top right of the green doc box that is displayed on the main template page. --Redrose64 🌹 (talk) 13:18, 9 April 2024 (UTC)

  I'm talking about calling up template doc when I don't have a link to click, such as {{infobox person}} (I'm looking to read the doc, not edit it, so the transclusion on the "main template page" is all I need). So I'm typing into the search box, and typing nine characters before I even get to the template name. I would dislike three characters (tm:) one-third (3⁄9) as much. My question is: Why NOT do this? Where's the significant downside? ―Mandruss ☎ 19:27, 9 April 2024 (UTC)

  I think Redrose thought that you meant actually manually going to the /doc subpage. Aaron Liu (talk) 20:23, 9 April 2024 (UTC)

  Yeah, I know. Hence my attempt at clarification. ―Mandruss ☎ 20:31, 9 April 2024 (UTC)

  @Mandruss: I highly recommend User:Ahecht/Scripts/TemplateSearch. jlwoodwa (talk) 04:05, 10 April 2024 (UTC)

  Thanks. I prefer solutions that benefit everybody, not just those who are aware of a script and choose to use it. I'm not here just for myself. ―Mandruss ☎ 04:08, 10 April 2024 (UTC)

• Support. Don't get why this hasn't been done already. We have wp: because typing "wikipedia:consensus" is tedious. And I can't spell template—I misspell it tempalte all the time—so an alias would be very nice. Anything four characters or shorter would be fine by me; I especially like the {{ idea. And to those who think that creating an alias will cause confusion—really? Is wp:sectionlink any more confusing than tm:sectionlink or something similar? You'll be lost for all of two seconds, if that. Cessaune [talk] 03:44, 11 April 2024 (UTC)

  omg I thought I had something really wrong with my fingers for always spelling tempalte Aaron Liu (talk) 11:35, 11 April 2024 (UTC)

• Strong Support Been meaning to propose this for a while! Any concerns about confusion can be fixed by an experienced editor spending one minute noticing the new system. — PerfectSoundWhatever (t; c) 02:26, 12 April 2024 (UTC)

Template namespace alias: Second survey

It seems to me we might have wide enough support for this to pass as a general concept. But I think a closer would be unable to decide on the specific alias to use, so we'd be looking at another RfC to decide that (ugh). Therefore a separate survey is in order. Eliminating tp:, I see at least tentative support for t:, tl:, tm:, tmp:, and tpl: (am I missing any?). I don't think this needs ranked voting—the specific choice isn't that critical—so it would be great if editors could just specify their one favorite. ―Mandruss ☎ 22:31, 9 April 2024 (UTC) Redacted 05:55, 14 April 2024 (UTC)

This section is not for opposition to the general concept; see my reply to Anomie's Oppose, below. ―Mandruss ☎ 00:53, 10 April 2024 (UTC)

Notifications. ―Mandruss ☎ 23:25, 9 April 2024 (UTC)

Notification of all participants to date, regardless of the nature of participation; you commented, you get notified. @Aaron Liu, Ahecht, Alexcalamaro, Anomie, ARandomName123, A smart kitten, Bilorv, Buidhe, CactiStaccingCrane, Chipmunkdavis, Cocobb8, Cremastra, Draken Bowser, Fastily, Frostly, Goldsztajn, GreenC, Isaacl, Izno, Jlwoodwa, JML1148, Johnuniq, Mach61, Michael Bednarek, Mir Novov, Musiconeologist, Nickps, Phil Bridger, Pppery, Redrose64, Schazjmd, Slacker13, Usedtobecool, Wjemather, Xaosflux, and ZandDev: ―Mandruss ☎ 23:13, 9 April 2024 (UTC)

• tm: t: ―Mandruss ☎ 22:31, 9 April 2024 (UTC) Redacted 04:50, 12 April 2024 (UTC)
• t: and tm: are no good because they deprive mainspace articles like t:kort of the title they deserve. tl is already in use to refer to the Tagalog Wikipedia. Fine with the others. * Pppery * _{it has begun...} 22:37, 9 April 2024 (UTC) (edited * Pppery * _{it has begun...} 03:05, 10 April 2024 (UTC))

  I struck tl:, it is not valid as it is an ISO language code. — xaosflux ^Talk 23:35, 9 April 2024 (UTC)

  Woops. ―Mandruss ☎ 23:38, 9 April 2024 (UTC)

  I find the "title they deserve" argument uncompelling in the greater scheme. Those wacky norsk and a few others might have to take one for the team. By eliminating t and tm, you're effectively forcing a three-character alias (unless we want to back up and introduce something like te at this late date, which would probably meet with its own opposition anyway). Just for fun, how about an example of a tm-"killer"? ―Mandruss ☎ 03:25, 10 April 2024 (UTC)

  Anomie provided one below. And te is already used for the Telugu Wikipedia. * Pppery * _{it has begun...} 03:28, 10 April 2024 (UTC)

  Told ya. Hell, while you might be able to produce a better example, I wonder if t:kort would survive AFD. ―Mandruss ☎ 03:38, 10 April 2024 (UTC)

  T:kort seems to be the only one for t:, other than some redirects which would work just as well from template namespace. But I think it would survive AfD - why would it be any less notable than anything else in Category:Fare collection systems, keeping in mind WP:Systemic bias and that sources are probably in Norwegian? Since I don't see a compelling reason for this proposal at all you aren't going to be able to convince me to cause a clear harm in the name of a dubious benefit. * Pppery * _{it has begun...} 03:48, 10 April 2024 (UTC)

  Fair enough. Just don't want anybody getting the impression that t and tm are now off the table like tl. The fact that they aren't stricken in the intro should be enough, but ya never know... ―Mandruss ☎ 03:53, 10 April 2024 (UTC)

  On t:kort specifically, which appears to be the only article that starts with T:, I don't think it actually should have that title per MOS:TM. The use of a colon isn't standard Norwegian orthography and the majority of third-party sources appear to call it "T-kort". – Joe (talk) 10:55, 11 April 2024 (UTC)

  And I see you've done that move. Well damn, now I'm tempted to change my vote from tm to t. But then I'd have to re-ping everybody; not sure it's worth it. ―Mandruss ☎ 11:26, 11 April 2024 (UTC)

  There are still some links to the redirect at T:kort and quite a few others. OTOH, I don't understand the objections based ISO language codes. -- Michael Bednarek (talk) 12:07, 11 April 2024 (UTC)

  It's established convention that links prefixed with a language code go to that language's edition. Aaron Liu (talk) 12:38, 11 April 2024 (UTC)

  Only if they exist, like tl:, but not for tpl:, tmp:, tem:. -- Michael Bednarek (talk) 13:06, 11 April 2024 (UTC)

  If a Wikipedia is created for a language, the ISO 639 code will be used in its URL and for its wikilinks (like how de: or es: link to German or Spanish Wikipedias, or how they can link back to us with en:). A namespace alias would conflict with that, preventing linking to that Wikipedia, so such aliases are often preemptively avoided. Anomie⚔ 13:14, 11 April 2024 (UTC)

  Most of those other redirects are cross-mainspace redirects to templates, i.e. using "T:" as a pseudo-namespace. Obviously they wouldn't be affected by this proposal. The exceptions I can see are:

  • T:A → Tribes: Ascend
  • T:DS → Thief: Deadly Shadows
  • T:MP → Talk:Main Page
  • T:SCC, T:TSCC, T: SCC → Terminator: The Sarah Connor Chronicles
  • T:SCC Episodes → List of Terminator: The Sarah Connor Chronicles episodes
  • T: New York Times Style Magazine, T: The New York Times Style Magazine → T (magazine)

  – Joe (talk) 13:30, 11 April 2024 (UTC)

  Of those, Template:A is salted so could be recreated as a redirect to Tribes: Ascend, Template:DS is a pointer to a defunct template so could probably be hijacked as a redirect to Thief: Deadly Shadows, Template:SCC is an unused redirect to Template:Supreme Court of Canada sidebar that could easily be retargeted to Terminator: The Sarah Connor Chronicles, and Template:MP, Template:TSCC, Template:SCC Episodes, Template:New York Times Style Magazine, and Template:Kort are all red. Still opposed to t: since it would cause avoidable confusion, but less strongly so than before. * Pppery * _{it has begun...} 01:36, 12 April 2024 (UTC)

  There's a few more than those, in particular T:APRM→Turbo: A Power Rangers Movie; T:OTD→WP:Selected anniversaries; and T:DYKT, T:TDYK, T:TDYKA, and T:tdyk pointing at Template talk: titles. —Cryptic 12:02, 12 April 2024 (UTC)

  Note that Template:OTD points to Wikipedia:Selected anniversaries/Date. Aaron Liu (talk) 12:47, 12 April 2024 (UTC)

  And Template:DYKT points to a different place than T:DYKT and both are in use. The others are fine: Template:ARPM, Template:TDYK, Template:TDYKA, and Template:tdyk are all red. Template:OTD vs. T:OTD difference seems to be a historical accident not a deliberate difference. * Pppery * _{it has begun...} 17:05, 12 April 2024 (UTC)

• I'd be fine with any of the choices. Schazjmd (talk) 23:18, 9 April 2024 (UTC)

  @Schazjmd: Yeah, this is the kind of "vote" that doesn't get us any closer to consensus. You might as well have saved yourself the trouble. Maybe you could just close your eyes and pick one? ―Mandruss ☎ 23:54, 9 April 2024 (UTC)

• tm: Cremastra (talk) 23:18, 9 April 2024 (UTC)
• T is fine just as we use "h" for help space all over.Moxy🍁 23:36, 9 April 2024 (UTC)
• tm: prefer this than single letter "t" which still retains a "talk" ambiguity. Regards, --Goldsztajn (talk) 23:54, 9 April 2024 (UTC)
• tm: because T: is already used, it's shorter than tpl:, and tmp: is misleading/confusing. -- Michael Bednarek (talk) 00:30, 10 April 2024 (UTC)
• Oppose Since you pinged me, I still oppose the whole idea. I note that "t" could be confused with "talk", as was already noted, "tpl" is the ISO 639 code for Tlacoapa, and "tmp" is a deprecated (but apparently not unassigned) ISO 639 code for Tai Mène. Also of note are articles T:kort and TM:103 Hustlerz Ambition that would be affected by certain of the proposals here (plus a few other redirects starting with "T:", such as T: New York Times Style Magazine). Anomie⚔ 00:40, 10 April 2024 (UTC)

  I pinged you because pinging everybody was a whole lot easier than trying to decide who should be pinged for this section. I might decide wrong and piss somebody off. This section is not for opposition to the general concept; that's the other one. If the general concept doesn't pass, this section will prove a waste of time, but it's still worthwhile. ―Mandruss ☎ 00:43, 10 April 2024 (UTC)

• tm or t8 are fine. The "8" might seem radical, but it's actually a typical method for shortening long words, such as l18n or k8s - eight being a familiar number for this purpose. No matter the choice, there will likely be edge case overlaps. That shouldn't stop it though. There are likely edge cases for WP, File, and whatever else. -- GreenC 01:00, 10 April 2024 (UTC)

  8 is just outside the normal typing zone on a normal keyboard and requires extra clicks to get to on a phone keyboard. I oppose it. Aaron Liu (talk) 01:01, 10 April 2024 (UTC)

  8 is just outside the normal typing zone on a normal keyboard - I don't know, but really? -- GreenC 01:03, 10 April 2024 (UTC)

• I also support tm. Ideally I'd support tp: the most, which also has no usages, and establishing this convention would prevent confusion, but it seems this has been struck down already. Aaron Liu (talk) 01:00, 10 April 2024 (UTC)

  Also support t: per novov. Aaron Liu (talk) 11:45, 12 April 2024 (UTC)

• tm or tp for me. tl would also be OK, and would match the existing {{tl}} template. Musiconeologist (talk) 01:07, 10 April 2024 (UTC)

  Sorry, that seems to have ended up in the wrong place. If anyone feels like moving it properly into the list of replies, please do. I'm hampered by the size of the page. Musiconeologist (talk) 01:10, 10 April 2024 (UTC)

  Done. Protip: Use c:commons:Convenient Discussions. It formats bullet-point replies correctly. Aaron Liu (talk) 01:13, 10 April 2024 (UTC)

  Thanks. We ended up both moving it at the same time! I got an edit conflict, then discovered it was now in the right place anyway. I now know to add a new bullet point, not a new reply via the reply link. Musiconeologist (talk) 01:38, 10 April 2024 (UTC)

  tl is off the table; that's why there's a line through it. See this edit. tp was eliminated because of strong opposition to something that looks like "talk page". It helps to read before posting. We'll assume you like tm, then. ―Mandruss ☎ 01:18, 10 April 2024 (UTC)

  (and as said above tl is off the table because it already refers to the tagalog wikipedia) Aaron Liu (talk) 01:32, 10 April 2024 (UTC)

  I did, then I read considerably more (the whole discussion). It's late at night, I was battling to navigate the page in a tiny window, and I didn't remember that specific detail among all the others. Anyway, tp is my first choice. Musiconeologist (talk) 01:33, 10 April 2024 (UTC)

  Anarchist. ;) ―Mandruss ☎ 01:37, 10 April 2024 (UTC)

  Yes, tm is fine. And my irritability suggests I need sleep, (I find the opposition to tp surprising though. I expect the alias to be a contraction of one word.) Musiconeologist (talk) 01:43, 10 April 2024 (UTC)

  tm is a contraction of template. It just uses the first and second consonants instead of the first and third. ―Mandruss ☎ 01:46, 10 April 2024 (UTC)

  Exactly. Same as tp. I wasn't saying any different. I just meant that I'm surprised people would intuitively interpret tp as talk page rather than template when using acronyms would obviously be a different model. But they do, and that's fine. Musiconeologist (talk) 02:01, 10 April 2024 (UTC)

  I see. Sorry for the misunderstanding. Get some sleep. ―Mandruss ☎ 02:08, 10 April 2024 (UTC)

• TM: , as my prefered TP: has been discarded per above. Alexcalamaro (talk) 01:36, 10 April 2024 (UTC)
• Tem. Still saves a whole plate. Hyperbolick (talk) 04:49, 10 April 2024 (UTC)

  Note "tem" is the ISO 639 code for Temne. Anomie⚔ 11:29, 10 April 2024 (UTC)

  It's so obscure!! Hyperbolick (talk) 09:30, 11 April 2024 (UTC)

  Not to the two million people that speak Temne. – Joe (talk) 11:06, 11 April 2024 (UTC)

  @Joe Roe: Aside that being .00025% of the world, what number of Temne speakers would even know that that’s its abbreviation? Hyperbolick (talk) 02:58, 12 April 2024 (UTC)

  I don't know, I don't speak Temne. But if/when we have a Temne Wikipedia, it'll be how we link to it. – Joe (talk) 06:07, 12 April 2024 (UTC)

• Oppose t, not sold on the concept as a whole but the others don't seem to hold the potential confusion the initial proposal did. CMD (talk) 08:46, 10 April 2024 (UTC)
• {{ is my first choice and t is my second choice (and I don't understand why I have to say it twice). — Bilorv (talk) 09:18, 10 April 2024 (UTC)

  Because to achieve something from this proposal it is necessary to converge to a few and ideally to a single prefix. -- ZandDev 11:25, 10 April 2024 (UTC)

  I'm not sure if a non-alphanumeric namespace alias is possible, but if it is, I suspect {{: would pose a problem for many existing tools and scripts that parse wikitext, including syntax highlighting tools. isaacl (talk) 17:29, 10 April 2024 (UTC)

  Note that the {{ option does not include a : and would require additional programming. Aaron Liu (talk) 17:34, 10 April 2024 (UTC)

  My apologies for being overly concise. I included the : to emphasize that the proposal is for a namespace alias, and not to suggest that there would be a colon in the namespace alias. Yes, the point of my comment was that not only might there be a need for changes to MediaWiki software, but to many existing tools and scripts, including syntax highlighting tools. isaacl (talk) 17:45, 10 April 2024 (UTC)

  The {{ option is not supposed to be a namespace alias that would still require the colon. It's proposed to be what seems to be a searchbar alias plus maybe an edit summary alias. Aaron Liu (talk) 02:38, 11 April 2024 (UTC)

  Yes, it's not necessary to explain proposals that I'm already aware of (as per my previous comments). If someone isn't proposing a namespace alias, then they shouldn't list it as their preferred option in this section. isaacl (talk) 04:51, 11 April 2024 (UTC)

  It also wouldn't really help on mobile, at least with SwiftKey, since accessing the braces entails either a long keypress for each one or switching to symbol layout. Either way it's probably easier to type the whole word than use the alias. Musiconeologist (talk) 17:41, 10 April 2024 (UTC)

• Oppose anything and everything that conflicts with an article, including "T:" and "TM:", I also oppose "tp" as it is more likely to refer to "talk page" than "TemPlate". Neutral on other suggestions. Thryduulf (talk) 11:04, 10 April 2024 (UTC)
• tpl:Slacker13 (talk) 14:12, 10 April 2024 (UTC)

  Immediately comprehensible, easy to remember Musiconeologist (talk) 16:14, 11 April 2024 (UTC)

• tm: for it does not conflict with talk pages in any way, and is the most logical one to me. Would also be fine with tmp: and tpl:. Cocobb8 (💬 talk • ✏️ contribs) 14:21, 10 April 2024 (UTC)
• First choices: t, tp, tm
  Second choice: Aliasing {{
  Last choices: Anything with a number or 3+ letters
  Honestly, I would suggest whoever closes this just narrowes down the 2-3 most viable options, selects one randomly, and comes up with a post-hoc justification. This isn't worth spending a lot of time on Mach61 17:22, 10 April 2024 (UTC)

  tm is also a language code. Aaron Liu (talk) 17:34, 10 April 2024 (UTC)

  I see no problems, tm: isn't a valid interlanguage link. Mach61 17:45, 10 April 2024 (UTC)

  Not sure what I was talking about. Aaron Liu (talk) 02:39, 11 April 2024 (UTC)

  I guess that could work, but to me it looks like tm: is the one gathering the most support so far. Cocobb8 (💬 talk • ✏️ contribs) 20:52, 10 April 2024 (UTC)

• T: is the straightforward and shortest prefix: it does its job better. The main problem is that it could be confused with talk, but I noticed that all here said that 'tp' seems to refer to 'talk page', so why not use it for talk pages? People will adapt to the chosen solution and have to remember it. Also tm is not direct (but for me acceptable). ZandDev 18:09, 10 April 2024 (UTC)

  It's too much work to have everyone adapt to a new thing. Aaron Liu (talk) 02:40, 11 April 2024 (UTC)

Off-topic about namespace aliases for other things. ―Mandruss ☎ 05:13, 11 April 2024 (UTC)

I noticed that all here said that 'tp' seems to refer to 'talk page', so why not use it for talk pages? You're proposing a tp: alias for talk:? Aren't you a bit off topic? Besides, it would save only two characters, not 5–7: a truly negligible improvement. Besides, there are at least two kinds of talk pages, article and user. That's if you exclude other talk spaces, such as this one. If any additional aliases might make sense, they would be atp: for talk: and utp: for user talk:—the words "talk page" can be ambiguous in some contexts, so I try to use those acronyms wherever such ambiguity might exist. Apologies for extending the off-topic; sometimes I can't help myself! ―Mandruss ☎ 05:06, 11 April 2024 (UTC) I agree with you, it isn't worth it to add tp: as an alias to talk:, the latter being already pretty short. However, for whatever ends up being chosen for template:, might it work to add an extra t in that alias for the template talk: namespace? Say, if tm: is the one chose, then tmt: could alias template talk:. Also, a shorter alias for user talk: would be ut:. Cocobb8 (💬 talk • ✏️ contribs) 12:54, 11 April 2024 (UTC) Note "tmt" is the ISO 639 code for Tasmate. Anomie⚔ 13:14, 11 April 2024 (UTC)

• Comment: people realize that t: is the existing psudeo-namespace for templates, as seen at T:CN and T:DYK? That doesn't mean you HAVE to support it, but it makes the arguments that it would be "confusing" stange, as it is already in use. Mach61 12:48, 11 April 2024 (UTC)

  There's also T:MP, and there's no evidence that people not already in the know aren't confused by those. Plus it could turn out to be more confusing once people can use it for every template rather than only the handful of pseudo-namespace redirects that have been allowed. Anomie⚔ 13:14, 11 April 2024 (UTC)

• Comment. Let me see if I understand this. If the colon were removed from the title at TM:103 Hustlerz Ambition (a vanishingly insignificant cost to the project, although some Jeezy fans would disagree), that would create a redirect with the colon that wouldn't work because of a tm: namespace alias? Then we should consider manually changing all existing links to that article (104 entries in that list, although I don't know how many would have to change) and deleting the unusable redirect. Then all we'd have to worry about is the possibility that some obscure Tamboori Wikipedia (e.g.), Tamboori being spoken by 112 people on a remote island in the South Pacific, will be created in the future and somebody at en-wiki will want to link to it. ―Mandruss ☎ 14:23, 11 April 2024 (UTC)

  @Mandruss actually, we could just create a template page and redirect that (see Help:A Day in the Life for an analogous case). The issue is when there is already an existing template with the same name as a mainspace page after the prefix. Mach61 14:27, 11 April 2024 (UTC)

  Hmmm. Well there's something to be said for knowing I don't understand something, since I'll talk less. I don't know how much of an obstacle we're talking about. I do believe that we should be prepared to make some sacrifice to make this work. ―Mandruss ☎ 14:45, 11 April 2024 (UTC)

  Yeah, it's super easy to create an alias template, provided that the alias doesn't conflict with article titles/redirects already. Which is the main issue. Cessaune [talk] 15:55, 11 April 2024 (UTC)

  Also, it seems that Jeezy is a thoughtful Wikipedian, as he chose an appropriate spelling for his 2019 album title : TM104: The Legend of the Snowman, just to avoid conflict :-) Alexcalamaro (talk) 07:44, 20 April 2024 (UTC)

• Tm or Tl Both are close to the colon-key, which is always practical. Draken Bowser (talk) 15:51, 11 April 2024 (UTC)

  @Draken Bowser: tl is off the table, hence the strikethrough in the intro to this section. See previous discussion in this section. ―Mandruss ☎ 16:14, 11 April 2024 (UTC)

• After further consideration, I would probably go for t: or tmp:/tpl:. Any collision with article space can be solved by redirects, similar to Portal:No Escape, given the number of offenders is relatively small. TM: is a non-starter in my opinion since many keyboards auto-correct it to a U+2122 ™ TRADE MARK SIGN, and the point of a shortcut is to avoid difficulty. ― novov (t c) 02:33, 12 April 2024 (UTC)

  Very valid point. However, I've not seen that happen inside search boxes or on Wikipedia as far as I can remember, which are basically the only scenarios in which anyone would be typing template: anyway. Cessaune [talk] 04:15, 12 April 2024 (UTC)

  Unfortunately it does happen for me; afaik it's a default text replacement on macOS. I'd disable it, but I find the ability legitimately useful in other circumstances. ― novov (t c) 07:58, 12 April 2024 (UTC)

• First choice Tm, second choice T: — PerfectSoundWhatever (t; c) 03:11, 13 April 2024 (UTC)

Browser config

I do not know about the rest, but on chrome, using the search engine shortcut feature worked perfectly.

1. Go to chrome://settings/searchEngines
2. Click "Add" that's next to "Site search"
3. Fill out: Name = [Anything], Shortcut = [I picked "tt"] , URL with %s in place of query = https://en.wikipedia.org/wiki/Template:%s

That's it. After that, just type out your shortcut, followed by title, separated by a space/tab, on the address bar and hit enter. Everyone can pick whatever shortcut they like, for all namespaces and even page prefixes of their choice. You can add one for https://en.wikipedia.org/wiki/Wikipedia:Requests_for_adminship/%s to go to RFAs by just typing out usernames, for example. Best, Usedtobecool ☎️ 05:47, 9 April 2024 (UTC)

That's good for an alternative in the meantime! But tp: would make it easier regardless of the platform people use to contribute. Cocobb8 (💬 talk • ✏️ contribs) 11:20, 9 April 2024 (UTC)

You can also use User:Ahecht/Scripts/TemplateSearch to automatically replace TP: and {{ in the Wikipedia search box with Template:. --Ahecht (TALK
PAGE) 16:31, 11 April 2024 (UTC)

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

Suicide hotlines

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

For the proposal see User:TheSpacebook/lifeline

Firstly, is this the correct place to put this? Also, I can’t find this proposal on Perennial proposals. I have concerns about the Suicide methods article. I believe it to be a clear violation of WP:NOTHOWTO. Failing that, the article is just a WP:BADIDEA. The consensus is currently for the page to stay, so for now, possibly the suicide crisis line for the reader could be displayed at the top of the page subtly embedded into the article.

But for now, I’ve spun this up in 15 minutes and sourced the numbers from List of suicide crisis lines. This might have to be expanded, as some lines have opening and closing times, so it can be expanded to display just the emergency telephone number when the number is closed. It relies on one thing though, IP address lookup service ‘ipapi’. There are probably better in-house Wikipedia databases that can do this, for better reliability. But essentially it curls the IP address and returns the ISO 3166-1 alpha-2.

The script is ultra-simplistic as I don't know what the specific technicalities of Wikipedia are, so it's a basic HTML script. If a more advanced tool would be better, point me towards the Wikipedia dev docs for the technical specifications. Also, I can build other tools for Wikipedia by piggybacking off the pre-existing ones.

I imagine that some people who have attempted suicide will probably have the Suicide methods article in their internet history. It should work with HTML, so the quickest solution is to insert the script only on the Suicide methods page. Sort of like an WP:IAR. It will also need to be styled so it looks better on the page.

All the phone numbers should be checked for accuracy, but the raw basic script for HTML can be found here: User:TheSpacebook/Suicide crisis line script. And the full HTML page, if it needs testing, can be found here: User:TheSpacebook/Suicide crisis line script HTML page. Just copy and paste it into a text editor, save it with the extension ".html", and then open it in a web browser. EDIT: I’ve reworked my proposal to be more subtle, it can be found here User:TheSpacebook/lifeline. TheSpacebook (talk) 23:15, 17 April 2024 (UTC)

Technical issues aside, this feels a lot like WP:RIGHTGREATWRONGS to me. * Pppery * _{it has begun...} 23:29, 17 April 2024 (UTC)

For background, see Wikipedia:Village pump (proposals)/Archive 161 § Proposal to add suicidal disclaimer at Suicide and Wikipedia:Village pump (proposals)/Archive 192 § Suicides. isaacl (talk) 23:46, 17 April 2024 (UTC)

Thank you for supplying me with those. However, my proposal is completely different. I’m not arguing for the article to be censored, nor the article to have a disclaimer (or "trigger warning"). I’m proposing that the relevant suicide crisis line to be in the article. This already happens on a different article, Suicide prevention, but it only displays the USA number. Possibly another example of the Western, specifically American, WP:BIAS on Wikipedia? Plus, the numbers already exist on List of suicide crisis lines, I think it would be a good idea to put the specific phone number in the appropriate place. TheSpacebook (talk) 00:45, 18 April 2024 (UTC)

Both discussion threads discussed putting a link to a hotline in articles, targeted to the reader's geographical area. isaacl (talk) 01:57, 18 April 2024 (UTC)

Both of those discussions began to get sidetracked to disclaimers or censorship, and were concluded based on those two. I hope this discussion focuses only on the suicide crisis number. Also the Suicide prevention article has a number, and I said in my other comment how this could be American WP:BIAS on Wikipedia. Something like that, but it changes for the country makes reasonable sense to me. TheSpacebook (talk) 10:51, 18 April 2024 (UTC)

The point of providing background is so the relevant discussion points can be reviewed and taken into consideration, to facilitate moving forward from the previous discussions. Both discussions cover relevant issues. isaacl (talk) 16:17, 18 April 2024 (UTC)

Both of them are arguing for WP:DISCLAIMERS. I have since modified my proposal, to make it clear that I’m not proposing a disclaimer. The text already reads that to prevent suicide they should call a crisis number, so it seems more precise to have the exact number. TheSpacebook (talk) 16:29, 18 April 2024 (UTC)

For instance, the second discussion has a post from a WMF staff member on the database it maintains, and how it would be willing to provide support for any community initiative. I feel this is useful background for your proposal. isaacl (talk) 16:37, 18 April 2024 (UTC)

Thank you again for sending me that, it was an interesting discussion. But it sways into WP:DISCLAIMERS which is not what I’m proposing. The script I made is a basic example, as I don’t have access to any of the backend Wikipedia/WMF tools. Linking it to a backend database that WMF maintains would be better. If the number changes, it only needs to be edited once to reflect immediately. TheSpacebook (talk) 17:03, 18 April 2024 (UTC)

Using an external service is a huge "no" from a privacy perspective. If we were to do this, we'd take up the WMF's offer to to it in-house from Wikipedia:Village pump (proposals)/Archive 192#Suicides. But what has changed since that discussion didn't result in acceptance? Anomie⚔ 01:19, 18 April 2024 (UTC)

All the script needs run is the ISO 2-letter country code. This can easily be supplied in-house at Wikipedia/WMF. I just used an external to show a working example of the script, as I don’t have access to any of the Wikipedia backend tools that can be used instead. In my initial post, I said there are probably better in-house Wikipedia databases that can do this. I’m not suggesting an external service is actually used. TheSpacebook (talk) 01:26, 18 April 2024 (UTC)

The user's assumed country is available using Geo.country in javascript. the wub "?!" 08:55, 18 April 2024 (UTC)

Perfect. What format does that return? Would it be Geo.country_code, as the 2 letter ISO country code, or something else? Now I can take away the fetch part:

const response = await
fetch('ipapi.co/country_code');
const country = await response.text();

and have then replace this part:

const country = await fetchCountry();

with the following:

const country = Geo.country

Anyone is welcome to make amendments to User:TheSpacebook/Suicide crisis line script to make it better. Still need to check the format it returns the country in, however. Is that still not an external package/library? If not, the script now fully works in-house with Wikipedia/WMF, using no external services. TheSpacebook (talk) 11:01, 18 April 2024 (UTC)

I realise that this proposal is slightly different, but the comments that I made at Wikipedia:Village pump (proposals)/Archive 161 § Proposal to add suicidal disclaimer at Suicide and Wikipedia:Village pump (proposals)/Archive 192 § Suicides still stand. Phil Bridger (talk) 11:30, 18 April 2024 (UTC)

I quite plainly believe it is not within Wikipedia's mandate to have this sort of thing on an article. Buddy Gripple (talk) 12:48, 18 April 2024 (UTC)

Suicide prevention already does this, but it only displays the USA/Canada number, which I believe shows Western WP:BIAS. So I could maybe amend my proposal to have that page display the relevant suicide crisis number. TheSpacebook (talk) 13:01, 18 April 2024 (UTC)

No, you should rescind the proposal entirely. This is not something we should be doing AT ALL. Any current examples of such need to be removed. --User:Khajidha (talk) (contributions) 13:08, 18 April 2024 (UTC)

Also, you are wrong about the suicide prevention only showing the US/Canada number. The numbers for the Samaritans (UK) and the Netherlands's crisis line (113) are also present in the images. These images (and the one for the US/Canada number) are present as examples of prevention campaigns, not directory listings. There is, however, an imbalance in that article between US material and other countries. --User:Khajidha (talk) (contributions) 13:22, 18 April 2024 (UTC)

Are you referring to these images in the article? I hardly think they count as anything for this discussion, but the Dutch number is in the caption. Also, is List of suicide crisis lines not a directory listing? But I’m glad we agree that there is an imbalance. Perhaps to redress this, the relevant line is displayed, and not the USA/Canada one for everyone. I don’t see the relevance for it to be on the article for non-USA/Canada readers.

TheSpacebook (talk) 13:28, 18 April 2024 (UTC)

Yes, those images. They show prevention methods in use, just as the image at the top of the article shows a poster used in the US. This is not displaying the US/Canadian line for everyone. Yes, the list of suicide crisis lines is a directory. I also think it should be deleted. --User:Khajidha (talk) (contributions) 14:25, 18 April 2024 (UTC)

I’m confused by This is not displaying the US/Canadian line for everyone, it literally is displaying the number for everyone, no? If List of suicide crisis lines was put up for AfD (which I’d oppose for it even being considered to be deleted), my theory is that it would be 'keeped', as per WP:IAR or some similar exceptional policy. TheSpacebook (talk) 14:29, 18 April 2024 (UTC)

As I said before, this image is present as an example of a prevention campaign not as a "here is the number to call" listing. It's a subtle distinction and I have no objection to removing that image. --User:Khajidha (talk) (contributions) 14:59, 18 April 2024 (UTC)

Can I just clarify, I’m not proposing a banner to be placed on the page, I’m proposing something more subtle. For example, the third paragraph in Suicide methods could easily be reworded to include the script which displays the number, without looking so blatant: (emphasis added) Some suicides may be preventable by removing the means. Making common suicide methods less accessible leads to an overall reduction in the number of suicides. Some method-specific ways to do this include restricting access to pesticides, firearms, and known-used drugs. Other important measures… and calling a crisis hotline. TheSpacebook (talk) 14:23, 18 April 2024 (UTC)

It's not obvious to me that such a banner wouldn't have some unintended consequences. I know search engines and newspaper articles about suicide use them, but all kinds of stuff gets done for herd reasons. How do we know that a big obvious warning box would not itself prompt someone to move from a state of passive information consumption to a state of actively contemplating a personal action? The prompt could trigger the thought that "Someone thinks I might actually do it", which is one hop from "I might actually do it". Barnards.tar.gz (talk) 14:36, 18 April 2024 (UTC)

I’m not proposing a banner. Just something more subtle. A banner would open a Pandora’s box and snowball into other content warnings, erring too close to WP:CENSORED. TheSpacebook (talk) 14:41, 18 April 2024 (UTC)

• So at the very least, this seems to require running a default gadget to change the content of an article in a manner that would be hard to editorially control. That doesn't seem like a good use of technical resources to me, without even getting in to the problems related to invalidating caches or editor issues of having this be interface-admin protection content. — xaosflux ^Talk 17:42, 18 April 2024 (UTC)

  Noted. The aim of this is to subtly include the text in the article. But, I’ll add a 'default text' parameter to display if there isn’t a number available, that can be unique to each use of the script. TheSpacebook (talk) 17:47, 18 April 2024 (UTC)

  I hadn't thought through the techical aspects of this before. The proposal seems to be to present different content to different people. As far as I am aware that is something we stopped doing, for very good reason, about fifteen years ago when we gave up turning linked dates around. Do we really propose to start doing that again? Phil Bridger (talk) 20:01, 18 April 2024 (UTC)

  I’ve completely reworked my proposal, it's vastly different from displaying dates and content warning disclaimers. It can be found at User:TheSpacebook/lifeline. I can’t find anything the exact same as what I’m proposing. Whilst they use geolocation, all previous suggestions seem to be some sort of banner/warning. TheSpacebook (talk) 20:06, 18 April 2024 (UTC)

  But you seem to be suggesting displaying different content to different people based on their location. Phil Bridger (talk) 20:27, 18 April 2024 (UTC)

  Correct. But there isn’t a specific rule against doing it for this tool/template as per WP:5P5. TheSpacebook (talk) 20:42, 18 April 2024 (UTC)

  There isn't a specific rule against me sticking my left index finger in my ear and singing "The Star-Spangled Banner" while drinking a glass of champagne, but that doesn't make it a good idea. Phil Bridger (talk) 20:58, 18 April 2024 (UTC)

  If in the UK, s/Star-Spangled Banner/God Save the King/ ^[1]
  1. except in Wales or Scotland, or for those in Northern Ireland from one community. And republicans, anarchists, and those who switch Javascript off. Those using TOR, VPN, or who have activated add blockers. Sirfurboy🏄 (talk) 06:59, 19 April 2024 (UTC)

It would simply be far better than a script as to have one page, likely in WP space for the purpose, to give the read a list of numbers to contact if they feel suicidal and need help. Not dynamic , but absolutely clear what number they should use by country list. A separate mainspace page that identifies these numbers is also fine, but there's likely a different format and purpose there, to inform, not to urge getting assistance.
Whether to include it on topics that directly deal with suicide, that's a separate issue. I think our disclaimers warn about medical advice and this would seem to fall within it. — Masem (t) 12:17, 19 April 2024 (UTC)

Previous discussions have come out against this type of proposal, because it would be almost impossible to maintain an accurate and up to date list of phone numbers for every country, or to identify with 100% accuracy where the reader was located. This is an idea that is well meaning but is unlikely to work well in real life situations.--♦IanMacM♦ ^{(talk to me)} 15:02, 19 April 2024 (UTC)

I understand all the concerns. Just thought I’d offer up a solution which met in the middle when this issue is raised, and be subtle to avoid a disclaimer. WMF said that they already maintain this database in the previous discussion and have more advanced tools to geolocate users: https://en.m.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_192#Suicides. My proposal is in good faith, the subtle template seems like something WMF could do a lot better with their advanced tools etc. TheSpacebook (talk) 16:51, 19 April 2024 (UTC)

@Masem there is meta:Mental health resources, curated by WMF. — xaosflux ^Talk 15:48, 21 April 2024 (UTC)

• Support-ish but for different reasons: I am pretty sure the suicide prevention hotlines are promoted for legal reasons on various news sources, and not just because they want to. No one wants to be found legally liable for harboring content which promotes or shows instructions on how to do this. This seems like a good application of WP:IAR to WP:NDIA. We are not here to WP:RIGHTGREATWRONGS but we also need to seriously consider the social impact of having such content on Wikipedia. We can prevent auto redirection from search or clicking and direct users to here: m:Mental health resources. Would like to hear input from WMF on this. Awesome Aasim 17:05, 20 April 2024 (UTC)
• Yes, but I support hatnotes that professionals with suicide-prevention training agree will do no harm. I oppose such notes by well intentioned editors without such trainig or experience. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:29, 22 April 2024 (UTC)

  Well, yes. Promoting such crisis lines may prevent a suicide, or may push the reader into it, as Elli says below. I don't think anyone has presented evidence either way. As I said in one of the other discussions about this, human psychology often moves in mysterious ways. Then there is the libertarian argument (to which I do not subscribe, but many on Wikipedia seem to) that we shouldn't do anything that interferes with personal choice anyway. Phil Bridger (talk) 19:35, 29 April 2024 (UTC)

• Oppose we already have a hatnote on the article to Suicide prevention, which is more than we'd do in any other similar situation. Anyone who wants access to a suicide hotline will be readily able to access one already; there is no need to push this in front of people so hard and I doubt it would have any benefit (indeed, I think it might actually push people away from those resources). Not even focusing on the implementation difficulties. Elli (talk | contribs) 19:06, 29 April 2024 (UTC)

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

Allow all autoconfirmed users to move pages without leaving a redirect

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

---

While redirects from page moves are commonly kept, there are reasons why they should not be kept as seen at WP:PMRC. For example, moving an article to draft space or to reverse page moves vandalism. This is common even for those without special tools (such as page mover or admin). This is so that normal users do not have to tag the page to request deletion and saves times for the admins (and users with the page mover tool) to do the work. Obviously this will not be an option for unregistered or new users, or for pages that are already move protected. The 'leave a redirect' button (or something along those lines) will be on by default and users who need to remove the redirect will have to manually press a button to turn it off. JuniperChill (talk) 14:28, 20 April 2024 (UTC)

• Opposed: Being granted pagemover isn't that big a deal, but it does require you to demonstrate that you understand the relevant policies, and a quick look at WP:PERM/PM shows me that most requests are denied. Granting this to all autoconfirmed users with no human review would be unadvisable. RoySmith (talk) 14:57, 20 April 2024 (UTC)

  Per the change in focus, I'm opposed even to making this automatic for all extended confirmed users. If you really need the ability, just apply at WP:PERM/PM when you get the required experience. RoySmith (talk) 19:05, 20 April 2024 (UTC)

• Oppose, I wouldn't feel comfortable with trusting all autoconfirmed users to move a page without leaving a redirect. At the very most, I would slightly support having it for all extended confirmed users (but not autoconfirmed). Cocobb8 (💬 talk • ✏️ contribs) 15:11, 20 April 2024 (UTC)
• Strong Oppose autoconfirmed is trivial, and vandalism of "disappearing" articles (by moving them to say another namespace) can be annoying to fix, can result in patrolling get skipped, and is certainly disruptive to readers. — xaosflux ^Talk 15:49, 20 April 2024 (UTC)
• Oppose for autoconfirmed, support for extended confirmed. A person who games extended confirmed to make vandalistic moves will quickly find that their extended confirmed permission is gone. Awesome Aasim 16:48, 20 April 2024 (UTC)
• Oppose even for extended confirmed - we already have rampant violations of the WP:PMRC criteria by page movers, and don't need to make it worse. * Pppery * _{it has begun...} 16:49, 20 April 2024 (UTC)
• Own comment, I want to change this to all extended confirmed users, but does the discussion above need to be closed and I have to make a separate one below? It will be the same text I said earlier, but with small changes so that it is now all EC users. JuniperChill (talk) 17:14, 20 April 2024 (UTC)

  I don't think that we are so bureaucratic as to require you to start a new discussion, but I guess that if any of the editors who has already commented objects you should. Phil Bridger (talk) 18:19, 20 April 2024 (UTC)

  Yeah I can leave this discussion to be (leave it as it is) because some others have suggested supporting it for EC users instead. JuniperChill (talk) 18:36, 20 April 2024 (UTC)

• Oppose even for extended confirmed. It's not difficult for anyone that needs and can be trusted with this right to apply for it. If they don't need it then it's just hat collecting. Phil Bridger (talk) 18:23, 20 April 2024 (UTC)
• Oppose even for extended confirmed, per Pppery, Phil Bridger and Xaosflux. Most moves should leave a redirect but many people (even some admins) don't understand this, the pagemover right is a necessary (but not sufficient) check to ensure that the relevant policies and guidelines have been read and understood. Thryduulf (talk) 08:19, 21 April 2024 (UTC)
• Oppose even for extended confirmed. It shouldn't be a thing for anyone but trusted users - all it will lead to is disruption. LilianaUwU ^{(talk / contributions)} 05:20, 26 April 2024 (UTC)

• oppose, as this would create many controversial page moves and page-move disputes that are prevented by the existence of a redirect. Uncontroversial page moves can be requested at the tecnical requests page.InTheAstronomy32 (talk) 17:51, 27 April 2024 (UTC)

Weak support for extended confirmed users. As these users are more experienced, aware of the policies and guidelines, I believe that little or no disruption would occur if they could move pages without making redirects, to move pages using the Round-robin method. As we currently have less than 1300 page movers, this would make certain processes (such as moving an accepted draft to mainspace, or reverting page-move vandalism) less bureaucratic and more automatic. I also admit that I never understood why we have a user with the right only to move pages, used by only 1400 editors of which the majority are administrators.InTheAstronomy32 (talk) 17:49, 29 April 2024 (UTC)

Anyone who is autoconfirmed can move pages. The pagemover right lets you delete the redirect that is left behind. Phil Bridger (talk) 19:42, 29 April 2024 (UTC)

• Oppose both (as a pagemover). Solution in search of a problem. The speedy deletion system is perfectly sufficient to delete these errant redirects. Queen of ♡ | speak 06:52, 28 April 2024 (UTC)

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

Post closure comment - Looks like I should have said ECP users, but it looks like the proposal will still not survive regardless. I counted 0/10 support for AC users and 3 for EC users (excluding the proposer). I made this proposal because of the amount of times its useful to not leave a redirect, as stated above but other than that, keep it. Maybe at least from main to draftspace, redirects would be deleted regardless. I didn't think that by this way, non admins could effectively delete the page when it was actually moved elsewhere

(not sure if this is the right place to put post closure comments as it is just below the discussion, just no more support/oppose votes) JuniperChill (talk) 23:18, 29 April 2024 (UTC)

Replace disabled Graphs with other templates that work

So, the Graph extension is not going to be working again for a very long time. Graph was disabled 1 year ago, and they are re building it from the ground up, just starting to gather the people necessary for the project, which the update says will start in July. In my opinion, we need a solution until then. 18,236 pages have disabled graphs, including some very heavy traffic articles. Here is a list with more than 100k total views on my user page. (Here is the full list generated dynamically, but takes a long time and eats a lot of RAM). These include very heavy traffic and important articles such as Facebook, Murder trial of O. J. Simpson, and World War II. All of these articles you could argue are currently incomplete because there is information that is there but can't be displayed to the user.

There are alternative templates that work currently, such as Template:Bar chart,Template:Bar box, Template:Vertical bar chart, Template:Pie chart, Template:Piechart, and various others. There are some that I can't see a currently working template for, such as line, area and map. I don't know much about creating templates, but I think it'd be technically possible to create those. If a map chart template wouldn't be possible or easy, you could also have a bot or human take the map charts, recreate it offline, upload it to Commons, then place the image in the article.

You could put the bar charts and pie charts in the working templates via a bot (the chart wouldn't look exactly the same, but at least the data would be visible). Maybe the bot could be a pending changes bot to make sure it actually displays correctly and accurately. Especially pie charts, as its literally just a circle divided in parts with different colours. For the high traffic or important articles, if you can't replace them via a different template (map charts), you could recreate them manually as an SVG. MarkiPoli (talk) 06:38, 21 April 2024 (UTC)

This means pages like Transportation safety in the United States and road traffic safety is a pain to read because it mostly relies on using its own graphs and not some images. I think pages that mostly rely on the now disabled graphs should have priority because otherwise, it is useless. While far from the most popular, it is still a problemJuniperChill (talk) 10:43, 21 April 2024 (UTC)

Wow, those articles are striking examples... 38 and 16 disabled graphs respectively. As you say, at that point the article becomes borderline useless. It would probably take too long to do manually without a bot though. MarkiPoli (talk) 11:03, 21 April 2024 (UTC)

For articles like this, the problem is that those sections just need to be rewritten. That's not an encyclopedic overview of the topic, it's just a statistics dump. Thebiguglyalien (talk) 17:05, 29 April 2024 (UTC)

Using static images would be an unfortunate backwards step: a big advantage of Module:Graph was that we could including a machine-readable version of the underlying data on Commons, greatly increasing its transparency, usefulness, and ease of editing. But since the WMF have really screwed this one up, we might not have a choice. – Joe (talk) 11:12, 21 April 2024 (UTC)

Existing templates should be used and new templates should be made where possible, and only as a last resort would we use static SVGs. As for machine-readability, I'm not sure exactly how that works, maybe others have more insight MarkiPoli (talk) 11:32, 21 April 2024 (UTC)

This is more idea lab fodder than a proposal, but a sufficiently clever bot might convert data into SVG, checking where repeated work may be necessary because the data has changed more recently than the SVG. Certes (talk) 16:10, 21 April 2024 (UTC)

Should list articles have images

Right now some list articles have images while others have had them removed.

I brought this up at User talk:Jimbo Wales § Do you believe lists of aircraft, tanks, and ships should have pictures? and Jimbo Wales suggested reopening the discussion, so I did so at Wikipedia talk:WikiProject Aircraft § Images on list of aircraft, etc.. But someone said I should've done it here instead for more people to notice. Can people go join the discussion there, or should we just copy over what was said there over here? Dream Focus 03:06, 25 April 2024 (UTC)

Lists can have free images to show what each item on the list looks like, but they cannot have non-free images since rarely the use of non-free images in lists meets all NFC criterion. A header/infobox image may be reasonable in such lists, but definitely not a per-item list. Masem (t) 03:09, 25 April 2024 (UTC)

Some lists do have an image for every entry, e.g. List of London Underground stations. Thryduulf (talk) 08:36, 25 April 2024 (UTC)

Key is, those are all free, and there's no NFC issue to worry about. — Masem (t) 12:30, 25 April 2024 (UTC)

There is a binary assumption here between every item in the list having an image and the List as a whole having no images. There are options in between as well as those two, and a blanket guideline for all lists to pick one of these options seems too broad. CMD (talk) 03:48, 25 April 2024 (UTC)

Each list is different.

• Sometimes no images are possible because there aren't any relevant, e.g. List of exoplanets detected by timing.
• Sometimes no images are possible because there are no free images available, e.g. List of Yu-Gi-Oh! GX characters.
• Sometimes a single header image is best, e.g. List of country calling codes
• Sometimes one image per section of the list works to provide additional context, but no more are possible/needed, e.g. List of railway lines in Great Britain
• Sometimes it's best to illustrate a selection of entries throughout the list, e.g List of rail accidents (2010–2019)
• Sometimes it's good to include an image for all/most entries, although almost only when there is a lot to say about them, e.g. List of London Underground stations
• When the subject of the list is a very visual thing, an image for each entry is near essential, e.g. List of national flags by design.

Which is best suited to a particular list can only be decided in the context of each individual list. Considerations include how long the list is, how much information is provided about each list entry, what free images are available, how large the image need to be to be recognisable, whether images add additional information or context, etc. Thryduulf (talk) 08:36, 25 April 2024 (UTC)

Non-free images can be used where our fair use criteria apply. Paradoctor (talk) 09:06, 25 April 2024 (UTC)

But simply to have an illustration on a list is not a valid reason, per WP:NFLISTS — Masem (t) 12:31, 25 April 2024 (UTC)

The biggest problem with having hundreds of images in an article, is that the browser will request ALL of these images from the server within a short timeframe. As this can overload the servers, especially if some of the thumbnails still need to be generated, some of those images might fail. It also tends to overload the memory of mobile phones, as it needs to load all this stuff into the memory and graphics buffers and mobile phones are limited. So as with so many issues. These are not binary, but SOME constraint is always warranted and where to put that is an editorial decision. But anything that assumes all or nothing is broken by (non)design. —TheDJ (talk • contribs) 09:41, 25 April 2024 (UTC)

Again, the length of the list matters here - illustrating every item in a list of 10 items is different to illustrating every item in a list of 1000 items. Thryduulf (talk) 10:02, 25 April 2024 (UTC)

I believe one of the disputed articles here is List of active United States military aircraft, so at some level the question is "Should this list have 150+ images?" WhatamIdoing (talk) 07:47, 26 April 2024 (UTC)

List_of_Ancient_Greek_temples#List and other list of buildings always have a picture of the building.

What about vehicles though? List of sport utility vehicles and many other civilian vehicles have images of the items on their lists. But list of military vehicles do not, because of a discussion back in 2015 where four people voted to eliminate them, without most people noticing the discussion. They went through and erased them. I believe the list of military aircraft for example, looked better before [29] with images showing the aircraft listed. We need a set policy in place so we don't have small numbers of people deciding things without most realizing what's going on, or arguing over every single article.

Since all of you chose to discuss this here, instead of the other place I linked to, just pointing out what I said there. If people have slow bandwidth they can easily set their browsers to not automatically load images. Any website that has images they want to see, they click the icon at the top of their browser to then load them up. No reason to remove all images simply because some have slow internet. Dream Focus 09:56, 25 April 2024 (UTC)

"they can easily set their browsers to not automatically load images" - only if they belong to the minute fraction of our readership who knows this, and how to do it. Other than loading issues, I see no reason why lists should not have images. The large category of Category:Lists of works of art are rather pointless without them. Johnbod (talk) 10:02, 25 April 2024 (UTC)

If the list item is a blue link then available image(s) of it are only one click away (and in a larger format). Related problems in aviation articles are the addition of large galleries (not advised by WP:GALLERY) and shoehorning multiple images in to articles with little text, add over length infoboxes (museums have a photo/logo and a map) and we have acres of white space above the navboxes. Nimbus (Cumulus nimbus floats by) 10:29, 25 April 2024 (UTC)

(edit conflict) If you believe that a page looked better with images, restore them. The discussion you refer to cannot stop you. I hate to break it to you, but (WP:CREEPily) bringing in a guideline to regulate this extremely situational topic would be the definition of "small numbers of people deciding things without most realizing what's going on". ~~ AirshipJungleman29 (talk) 10:30, 25 April 2024 (UTC)

Then there would be a pointless edit war. At Wikipedia:Articles for deletion/List of Polish military aircraft an editor stated:

we have a consensus to not put aircraft image into the inventory table, and intentionally ignoring the consensus may be considered as disruptive editing.

So I'm hoping far more people participate in this, and we can come to a standard agreement, and either add it to a guideline somewhere, or if nothing more, link to this discussion for the new consensus. Dream Focus 11:11, 25 April 2024 (UTC)

I have no idea what consensus would be applicable, other than "it depends". It's entirely situational whether images should be in any article. Lee Vilenski ^{(talk • contribs)} 11:17, 25 April 2024 (UTC)

I agree that this is too situational for universal guidance. If a prior consensus has determined that a specific list should/should not have images, and you disagree with that determination… remember that “consensus can change”. Go to the article talk page and discuss. Blueboar (talk) 12:27, 25 April 2024 (UTC)

No, it would lead to a discussion, if anyone cares enough to revert you. WikiProject consensuses from nine years ago with five people participating were not binding then, and are still not now. ~~ AirshipJungleman29 (talk) 12:36, 25 April 2024 (UTC)

What an utterly pointless discussion. Given that neither a policy stating that 'no list article shall have images' nor one stating that 'all list articles must have images' would stand the slightest chance of ever gaining acceptance, the 'it depends' status quo is the only possible outcome here. AndyTheGrump (talk) 13:11, 25 April 2024 (UTC)

Totally agree! Just depends on the subject really. There is no need for a overall concensus for all Wikipedia lists. Local concensus can be easily agree on the lists talk page. Davidstewartharvey (talk) 13:54, 26 April 2024 (UTC)

• This is like asking whether lists should have prose or use tables – it obviously depends on the topic. Our best practice can be seen at WP:Featured lists which has relevant criteria: "It has images and other media, if appropriate to the topic, that follow Wikipedia's usage policies, with succinct captions." There don't seem to be many aviation FL but a good example is List of aircraft operated by Scandinavian Airlines which has plenty of pictures and looks fine. Andrew🐉(talk) 13:15, 25 April 2024 (UTC)

Yes, very much horses for courses. Images tend to swell out each item, making it difficult to see much of a long comparative list at any one moment; fifty very similar thumbnails differing only in fine detail are no compensation. Many aircraft lists are of this type. On the other hand, visual features are often important identifiers, as with the List of X-planes. — Cheers, Steelpillow (Talk) 17:29, 25 April 2024 (UTC)

If the number of available sample images is much less than the number of subject items, in each case it might be suitable to provide a hyperlink to a Commons image (or category). One example is List of surviving Douglas A-26 Invaders. PeterWD (talk) 18:43, 25 April 2024 (UTC)

• IMO, Dream Focus exaggerated the initial problem, which was the decision not to include images into aircraft inventory table in articles dedicated to specific air forces or in lists of aircraft belonging to those air forces. However, he expanded the discussion into "Should list articles have images", which is a broader questions. Regarding this broader question, my stance aligns with Lee Vilenski, AndyTheGrump, Andrew, and Steelpillow suggesting it depends on the context. Additionally, Thryduulf has provided excellent examples for each context. Referring back to the initial problem, I believe the decision to not include images into aircraft inventory table aligns with the 5th context outlined by Thryduulf, which states that Sometimes it's best to illustrate a selection of entries throughout the list. Current articles on air forces or lists of aircraft belonging to those air forces do include a selection of images of aircraft, typically positioned beside the inventory table. Ckfasdf (talk) 06:24, 26 April 2024 (UTC)
• Sometimes yes, sometimes no. There is no one image rule you can apply to list articles because list articles aren't all the same. Dennis Brown - 2¢ 07:59, 26 April 2024 (UTC)

  Then its all up to whoever is around at the time to notice and argue about it. Some will go around and erase it unless a set rule is established preventing it. I really wish this conversation was being had all in one place. Wikipedia_talk:WikiProject_Aircraft#Images_on_list_of_aircraft,_etc. shows clearly that some believe in removing all such images, because some of them have slow internet speed and because those using cell phones to access Wikipedia have trouble loading them. They can easily look through the settings of their browsers and set them to not load up images, or use a search engine to find out how. I am curious what sort of articles the cell phone users are accessing. I assume those just looking up a recent news story or celebrity gossip, or information they need at the moment for whatever they are doing. Is there a way to see how many people viewing an article are using a cell phone instead of something else? Dream Focus 11:53, 26 April 2024 (UTC)

We are not going to establish a 'set rule'. It simply isn't possible. There are just far too many factors to consider. And yes, this sometimes means that Wikipedia erases things. Like absolutely any other serious media project, anywhere. This is what is known as editorial judgement. Some of us clearly have it, and understand its purpose, even if you don't... AndyTheGrump (talk) 12:07, 26 April 2024 (UTC)

FWIW… I edit about 50/50 between computer and phone.

As for people removing images, that is allowed. Good Faith Editing involves both adding and removing stuff (that is why we are called “editors” and not “authors”.) There can be valid reasons to do either. If someone else (you) objects, take it to the talk page and discuss. Reach a new consensus and work from there. Blueboar (talk) 12:11, 26 April 2024 (UTC)

• If the image fits the list then fine. Images work well and have since lists were a twinkle in the eyes of Wales/Sanger. Many visual art lists are specifically about the images. This is another example of a theory I've bounced around that Wikipedians, when given limited number of things left to do as the years go by and being accustomed to doing many edits a day/week, will turn to deleting normal components of existing pages. Please be aware of this tendency and take it into account, thanks. Randy Kryn (talk) 14:09, 26 April 2024 (UTC)

Yes of course, and videos, too. They won't slow down or crash mobile phones either, that's outdated info. At worst the images might take a bit to load, which is no reason not to have images at all. Levivich (talk) 14:18, 26 April 2024 (UTC)

This is simply not true. it is very easy to memory overload a low end phone, especially if it's a couple of years old. This is mostly due to layout calculations on very long pages. It also adds additional load serverside, which is not insignificant. There is a reason why anything 'list' that the server generates uses a pager (next page/previous page) and is limited to 50 by default and 500 max. If people throw hundreds of images on a page, it has impact. Can it handle it ? yes, sometimes, sometimes not. Where is the edge ? Somewhere on a curve and the curve ends with a cliff. the exact shape is influenced by hundreds of variables (which is why you can't define a hard limit). —TheDJ (talk • contribs) 17:13, 26 April 2024 (UTC)

You can't define a hard limit, but there are best practices. For anyone reading this who isn't familiar, what we're talking about is called "page weight," which is the total size, in kilobytes (KB) or megabytes (MB) (1 MB = about 1,000 KB), of a web page and all the other stuff that has to be loaded, including images. If the page weight is too big, it'll slow down the browser/device loading it. Of course, desktops can handle larger page weights than mobile devices.

The average page weight for a mobile device nowadays is over 2 MB according to, e.g., [30] and [31]. Now look at Special:Permalink/671675813, an old version of a list that has a lot of images on it -- 170 different images in total. The page weight of that page is 953 KB, a little less than 1 MB according to [32] (you can check any webpage's page weight using tools like the one at https://tools.pingdom.com). So that page has 170 images and it's less than half the average page weight of a mobile page today. (The last time the average mobile page weight was 1 MB was like 2016. So this list page with tons of images would have been a less-than-average-sized page in 2016; it's half the average today.)

And that makes sense because thumbnails are really small. Even though that page has 170 images, it's a total size of 844 KB for all images -- that's an average of about 5 KB per thumbnail image (and yes, almost all of the 1 MB page weight is the images). So with an average mobile page weight of 2 MB, and thumbnails of an average of 5 KB, we can have 400 thumbnails before we hit the average.

So I doubt that there are any significant number of devices in use today that can't handle, like, 50% or 40% of the current average mobile page weight. Even devices from 2016 would be able to handle 1 MB page weight. And adding thumbnails to lists -- at an average of 5 KB each -- is not going to impair the performance of the vast majority of mobile devices, unless the list gets to be over 400 images long. And that tells me why the server max is 500 images, makes sense.

And all that is assuming the mobile browser loads all those images at once, which I don't think it does because of lazy loading, which, according to our article on it, has been the default in browsers since 2020 (and the MediaWiki Lazyload extension is older than that).

DJ, what do I have wrong here? What kind of a mobile device still in use today would have trouble loading a web page that is less than 1 MB? Levivich (talk) 18:26, 26 April 2024 (UTC)

Idea lab

ITN reform

I am opening this discussion to invite suggestions and proposals to reform WP:ITN in anticipation of an RfC. Such reforms are long overdue: ITN has effectively shut itself off from the rest of the site as a walled garden and have developed their own system of rules that conflict with sitewide expectations, creating multiple problems:

• The inclusion criteria are entirely subjective and based on the personal whims and opinions of participants. Editors at ITN routinely use original research to determine "significance", applying their own analysis of each situation. Weight in reliable sources is not a major factor in whether ITN considers something to be "significant".
• ITN flouts community norms around consensus. Discussions are typically closed as head counts, without weighing arguments in regard to the application of policy. "I like it" votes are given equal weight in discussions. The discussions are also closed before consensus has time to develop: no other part of the project would dream of letting a discussion without a clear consensus be closed in under a week, but ITN's nature requires that they be closed in a few days at most. Many discussions are closed after just a few !votes one way or the other.
• ITN requires a fast turnaround, sometimes as short as a few hours. In addition to contradicting WP:DEADLINE, this creates rushed work and prevents in depth review. Nominal quality checks are done to make sure citations are present, but the window is short and most participants only evaluate "significance". This results in articles that are not only not ready for the main page, but ones that are unstable as they are oftentimes recently created, subject to early reporting errors, and undergoing significant changes.
• Since arguments about personal beliefs and opinions are built into ITN's processes, it is inherently less civil than other parts of the project. Over the years, drama at ITN has rivaled most CTOPs, to the point that applying general sanctions to ITN itself has been discussed in the past.
• The arbitrary selection of news stories (with a major systemic bias toward elections, sports, and mass-casualty events) misrepresents the overall state of what's actually in the news. Pushing this bias onto our readers does them a disservice.

These problems are intractable with ITN in its current form. I am asking for suggestions on how it can be reformed, or if that fails and there is consensus to abolish it entirely, how it can be replaced.

Examples of reforms:

• Remove the significance requirement entirely and include any article that is the subject of a recent news event.
• Require that a story receive significant coverage in a certain number of countries or a certain number of newspapers of record
• Promote articles based on trending topics (with oversight to prevent gaming the system)

Examples of replacements:

• Use the space to display several short blurbs for good articles each day, like smaller versions of WP:Today's Featured Article
• Use the space to provide links on how to edit and to help users find where to start in order to recruit more editors
• Move the "Other areas of Wikipedia" section of the main page into the space for easier navigation

These are ideas that have been suggested in the past. This is not an exhaustive list of examples, nor do I personally consider all of them viable. I'm requesting input from the Village Pump so we can develop additional suggestions and get a general idea of what the community thinks about them. Thebiguglyalien (talk) 18:48, 30 March 2024 (UTC)

Two issues with points raised:

• On the fourth point related to arguments: the only time general sanctions have been applied is when the topic itself falls into areas where general sanctions have already been applied (like AP2, etc.) There have not been any sanctions applies for topics outside these areas. So that's just how general sanctions should be applied, and not an ITN issue.
• On the fifth point, WP is not a newspaper and we absolutely should not share topics to match what is big in the news. Not every news story that gets a short term burst of coverage deserves a WP article (per NOTNEWS, WP:N and NEVENT) and ITN reflects that.

Remember that the main page as a whole is meant to showcase articles that represent some of the best of WP. Replacing it with a list of top stories in newspapers or with popular topics won't work at all, because not all those topics meet the main page requirement. — Masem (t) 19:17, 30 March 2024 (UTC)

I would also offer a suggestion that the ITN box include a permalink to the Wikinews sister project, which may be more attractive to those potential editors who get confused or put off in their first reverts that we are WP:NOTNEWS. SamuelRiv (talk) 15:09, 5 April 2024 (UTC)

Back when Wikinews was a news site, we had such a link. Wikinews is far too slow to be useful these days, possibly because of too much focus on quality given the size of the userbase. Overall, Wikipedia is a much better news site than Wikinews ever was, whatever WP:NOTNEWS says. —Kusma (talk) 17:22, 26 April 2024 (UTC)

I wonder if there's even a consensus that ITN needs to be changed, before we even start talking about the specifics of how to reform it. But I do not see any indication on the above thread that such a consensus exists. If there is, please feel free to share the diff, otherwise I feel like this will just go around in circles again as such discussions always do. _{Duly signed,} ⛵ WaltClipper -(talk) 13:13, 8 April 2024 (UTC)

I think that (much like changing the MP) consensus could be obtained for the general idea of changing ITN but it would break down when specific proposals are offered. I now believe that it should function more like RD with a reduced or nonexistent "super notability" significance requirement- but I don't think that would gain a consensus.(I've discusses it here previously) 331dot (talk) 15:12, 18 April 2024 (UTC)

Just a thought on "article quality" as a criteria: maybe it shouldn't be one. Perhaps a purpose of ITN should be to direct readers to articles that are currently hot topics in the hope that the extra attention results in improvements. There's no better opportunity to improve an article than when lots of people are interested in it. Barnards.tar.gz (talk) 14:18, 18 April 2024 (UTC)

Content on the Main Page is supposed to demonstrate high quality articles and some of WP's best work. We can't remove the quality aspect with changing that aspect of Main Page. — Masem (t) 18:59, 18 April 2024 (UTC)

I get that ITN has its problems, but I don't get why it gets singled out so much when the other sections of the main page all have their quirky ways of working. ~~ Jessintime (talk) 17:19, 18 April 2024 (UTC)

ITN has actually been working quite fine recently, in my opinion. I am not sure this is needed anymore. Curbon7 (talk) 18:34, 18 April 2024 (UTC)

I'm still in favor of just removing it (make TFA 2 columns wide on desktop), and then if people want to propose adding something to the main page where it used to be, discussing that separately. I've written enough about why in the previous rounds of this discussion so I won't repeat myself here (tldr: because it's bad at its job, irredeemably and structurally). Levivich (talk) 11:03, 26 April 2024 (UTC)

In-page attribution of authors/contributors

Tracked in Phabricator
Task T120738

Something I've been thinking about for a while is how Wikipedia could provide better attribution for the contributors of its articles. After all, attribution is a key part of our license, but the authorship of an article is very much hidden away out of sight. In order to see the authorship of an article, one first needs to go to the "View history" tab, then click on the "Page statistics" external link, which redirects to an entirely different website, and even then you need to scroll down in the page before seeing authorship details. It also appears to only be visible in the web browser version, while it seems completely absent from the mobile app version. This presents a pretty unintuitive set of hoops for readers to jump through in order to discover (and attribute) the authorship of various articles. Even as a regular contributor, I didn't know this tool existed until a year or so ago.

This means that, to the lay reader or content re-user, all of our articles might as well be written by a monolithic "Wikipedia", or maybe a vague gesture at "Wikipedia contributors". Contrast this with other prominent encyclopedias like Britannica, which display the primary contributors to an article quite prominently beneath the article title and list secondary contributors in an easy-to-find section in the article history.

I was thinking that, either in the main page or at the top of the "View history" tab, it may be worth including such a list of contributors. It could be as simple as listing the primary author (with the most percentage/characters contributed), followed by any secondary contributors (with >10% contributed), followed by an "et al", which could itself link to further information about the article's authorship.

I think this would be a very important fulfilment of our own license's terms of attribution, both for in-wiki use and for anybody that might be reading or thinking about reusing the article's content. It would be a step away from the monolithic conception of "Wikipedia contributors". It could also provide a greater sense of impact for the articles' authors themselves, who would be able to easily see the fruits of their labour on screen. Of course, I understand this may come with its own drawbacks. I know some editors prefer the anonymity, while others may be worried that this could encourage low-effort edits in order to farm credit. But I personally think that the potential benefits of such a credit feature would outweigh the potential costs.

Having looked through the village pump archives, I'm confident this isn't a perennial proposal. I only managed to find one discussion of such a feature, which was opened by @Doc James almost a decade ago, but it didn't seem to gather a clear consensus and I'm not sure if anything ended up resulting from it. If anyone has any comments on this embryonic proposal, I would be happy to hear from you. --Grnrchst (talk) 14:27, 2 April 2024 (UTC)

@Grnrchst as an example, could you produce what you would expect the output of such to look like for this page? — xaosflux ^Talk 14:32, 2 April 2024 (UTC)

It's an odd example, because this is a discussion page, but it would currently be something like "Written by WhatamIdoing, Xaosflux, et al." --Grnrchst (talk) 14:43, 2 April 2024 (UTC)

So you'd be fine ignoring the thousands of other authors on such a byline? — xaosflux ^Talk 14:58, 2 April 2024 (UTC)

I don't think it's feasible nor particularly useful to include every single contributor in a byline, but I don't think they should be entirely ignored either, that's why I've included the "et al." (could also say "and others", or something). The reason I set the byline inclusion at >10% is because that's the rule of thumb used by the good articles project to determine major contributions. I think named inclusion in the byline should be limited to such major contributors, but linking to total authorship in the "et al." would also be useful for showing the full scope of contributions. --Grnrchst (talk) 15:05, 2 April 2024 (UTC)

I don't think there is going to be any good way to programmatically determine those values. In your example above, what calculation did you use to determine that WhatamIdoing and I were >10% contributors for example? This is primarily why the cite this page tool example just says "Wikipedia contributors". (see more below) — xaosflux ^Talk 15:17, 2 April 2024 (UTC)

I was using the "Top editors" section in the Xtools page I linked to in the "et al." As this is a discussion page, rather than a mainspace page, Xtools doesn't show an "Authorship" section in this case (hence why I didn't think it was a good example). Whereas in the one for Morgan Bulkely, there is an authorship section that shows Wehwalt at 79% of authorship, Real4jyy at 6.2% of authorship, etc. The authorship tool on Xtools is apparently powered by WikiWho, which we may be able to use for generating such a byline. --Grnrchst (talk) 15:25, 2 April 2024 (UTC)

As for the "Cite this page" tool, I think this is an example of how just vaguely citing "Wikipedia contributors" is unhelpful and even redundant. Of course it's authored by Wikipedia contributors, it's a Wikipedia article! --Grnrchst (talk) 15:51, 2 April 2024 (UTC)

Another example, using today's featured article Morgan Bulkeley, would read: "Written by Wehwalt, et al." Grnrchst (talk) 14:47, 2 April 2024 (UTC)

I was thinking this "Written by [...]" could go next to the bit where it says "From Wikipedia, the free encyclopedia". --Grnrchst (talk) 14:51, 2 April 2024 (UTC)

In the mobile view, we do advertise the "last" author (e.g. see the bottom of this page) - that could possible be ported to desktop. — xaosflux ^Talk 15:00, 2 April 2024 (UTC)

I think the "latest contribution" is a good measure of recent activity, what I'm aiming at with this proposal is trying to demonstrate a broader scope of total activity. --Grnrchst (talk) 15:07, 2 April 2024 (UTC)

• Note, a feature request that may address this idea is open at phab:T120738. — xaosflux ^Talk 15:18, 2 April 2024 (UTC)
• Note that we currently have https://xtools.wmcloud.org/articleinfo/en.wikipedia.org/C418_discography and Who Wrote That which calculate the percentage, the latter using an API that does it Aaron Liu (talk) 15:20, 2 April 2024 (UTC)

  I think you'd want to use the WhoColor API (which is what mw:Who Wrote That? uses). The other methods tend to overemphasize people who don't actually write any words. For example, if the article has 50 edits total at the time of calculation, and five of them are me blanking the whole article, or changing the whitespace on a template, then I've made 10% of the edits, but I haven't written a single word on the page.

  @Grnrchst, the last time I remember seeing a discussion about highlighting the names of contributors, a jerk who normally edited under his real name created an account with a vulgar username and made one edit, just for the purpose of asking whether we really wanted to have vulgarities displayed in the mainspace. WhatamIdoing (talk) 16:41, 2 April 2024 (UTC)

  And his alt was banned for WP:DISRUPTNAME, right? Aaron Liu (talk) 20:40, 2 April 2024 (UTC)

  Yes, but DISRUPTNAME was declared to be an insufficient reason to revdel or oversight/suppress the change. WhatamIdoing (talk) 02:27, 20 April 2024 (UTC)

  I was having the same thoughts. It should be based on who contributed to what the article as currently displayed. It would be wrong for instance to list the top contributor as someone who hasn't edited the article since it was completely rewritten.
  It might also encourage more competitive editors to try and find ways to boost there standings, without having to do any actually helpful work. -- LCU ActivelyDisinterested «@» °∆t° 15:54, 3 April 2024 (UTC)

  For the reasons mentioned above, I'm not a big fan of crediting whoever ran the link archiver most often as being the "author" of the page. Nor am I fan of being assigned as the author of a page, even if I am indeed the #1 author. The mw:Who Wrote That? extension is excellent and should be promoted, because it allows seeing authorship of words and sentences currently live, which is an excellent (though not infallible) way of tracking down who has added nonsense to an otherwise decent page (caveat lector: sometimes someone who copyedits nonsense will be shown rather than the original nonsense-adder). One thing that may not be widely known is that you can run Who Wrote That? on old versions of pages, making it an arguably more efficient tool than WikiBlame.-- SashiRolls ^{🌿 · 🍥} 18:37, 8 April 2024 (UTC)

  Although XTools is influenced by use of link archiver tools, the underlying WikiWho service provides token-by-token attribution of who added what. This can be used to determine authorship without considering anything between ref tags, as well as other markup that's seen to unfairly influence authorship stats. I have implemented this in SDZeroBot 6 task which makes the bot somewhat smarter about whom to notify about AfDs. – SD0001 (talk) 21:15, 8 April 2024 (UTC)

• I am concerned that this would encourage WP:OWNERSHIP of articles. The entire point of the Wikipedia model is that articles are “authored” by the community, not by individuals. Blueboar (talk) 20:48, 2 April 2024 (UTC)

  This is a completely fair and valid concern. --Grnrchst (talk) 21:54, 2 April 2024 (UTC)

I don't see the need for this. I do get a certain pleasure from seeing how much of the content in an article I have contributed (which I can see at Page Statistics), but I am well aware that no one else really cares, and the future of such content is out of my hands. I am not editing Wikipedia to build my curriculim vitae. Donald Albury 21:41, 2 April 2024 (UTC)

• As someone soliciting donations for your Wikipedia work, is this something you are considering using to attract donors? isaacl (talk) 21:43, 2 April 2024 (UTC)

  No. --Grnrchst (talk) 21:51, 2 April 2024 (UTC)

Personally I strongly dislike the idea of articles where I have primary authorship saying "written by Levivich, et al." or anything like that. That is very much not the kind of attention I want. Also, xtools authorship is not really reliable. For example, I am listed as the #2 author of Alexandria Ocasio-Cortez [33] but that's only because I once ran the archive bot on that page [34], I am not actually anywhere near a top author of the actual prose on that article. Levivich (talk) 17:15, 3 April 2024 (UTC)

If you have a divisive article and then add a note that User X was its most prolific contributor, readers will immediately assume User X holds those divisive views. And all the better if User X is an IP and offended readers can immediately find their location. (Which is already possible, of course, but why place it front and center?)

Speaking of which, how would this even work with dynamic IP addresses? 2603:8001:4542:28FB:25EE:12B6:DCFA:E43E (talk) 18:43, 3 April 2024 (UTC) (Send talk messages here)

I agree with the concerns voiced by Levivich and others. And even if the authorship statistics were 100% accurate I still don't like the idea of omitting certain users; as sappy as it sounds I think every contribution matters. Potentially, we could do something like Based on the contributions of 328 users but even then I think a more appropriate place for this kind of thing would be the footer alongside the last edited date. ― novov (t c) 08:21, 4 April 2024 (UTC)

• I can totally see the issues with this: we'll never have a 100% reliable measure of authorship, you can't include everyone, and we'll probably see a slight uptick in WP:OWNERSHIP and authorship gaming. But overall, I think it would be a nice way to acknowledge our volunteer editors and to communicate to readers "look, this was written by real people – you can join us". And twenty years into the project, with declining editor numbers, increasing restrictions and expectations of those editors that persevere, and donations to "Wikipedia" siphoned off by an organisation that has increasingly little to do with it, I think we really do need to start prioritising looking after our volunteer base over other concerns. Relying on the ideal of the selfless, perfectly-self motivated contributor, happy to work in complete anonymity, was fine in the early days of the project when the internet was the playground of affluent nerds with utopian ideals; those days are long gone. – Joe (talk) 08:56, 4 April 2024 (UTC)

I can see how algorithmically a shortened authorship list would be generated automatically, fine-tuned for a relatively accurate representation. And while anything like that could be gamed by users, that's why we have lots of human eyes to review abuse. I can also see how such a list would be useful to researchers and those making citations. However, were such an authorship list to be implemented, I'd suggest it be hidden out of the way a bit, at least certainly from the front page of the article, and perhaps even completely hidden from UI except as metadata.

I'll give some contrasting examples: Scholarpedia places its curator-authors (respected subject-matter experts) prominently at the top of its articles: non-random example is BCM Theory (SP). By contrast, Internet Encyclopedia of Philosophy has its authors' names and affiliation mentioned simply at the bottom, under "Author information" following the bibliography; while Stanford Encyclopedia of Philosophy has its author even more nondescript, being in a footer at the bottom under a copyright notice, and not implied to be an actual "author" until you click on the "Author and citation info" link on the sidebar. (Again, respected subject-matter experts; random ex.: Gender in Chinese Philosophy (IEP), Plato on utopia (SEP).) Wolfram MathWorld also has authorship given relatively subtly at the bottom of the page -- if it's contributed by someone other than the editor, the contribution note precedes the bibliography; otherwise authorship is indicated only in citation information (ex. Chen-Gackstatter Surfaces (MW)).

Given all this, I don't know what example editors here would want to find themselves compared to, especially since an algorithm listing authors would not distinguish one editor writing 95% of an article immediately preceding GA, from one editor writing 55% of the prose in a B-class, for which others had to find new citations (unless we'd want it to do so, but this would epitomize wp:ownership). SamuelRiv (talk) 15:37, 5 April 2024 (UTC)

It’s really hard to measure the significance of contributions to an article. It’s not just a count of who added the most words, or even of who added the most words that survive into the current version. How should we weigh a user who adds some high word count nonsense to an article, against a user who painstakingly sifts through the garbage, deletes most of it, and copyedits down any remaining kernel of valid content? Or the user who contributes great source analysis to a talk page discussion on a matter which results in a single word changing? Perhaps the article on Antoine de Saint-Exupéry is finished not when there is nothing left to add, but when there is nothing left to take away? Barnards.tar.gz (talk) 18:05, 5 April 2024 (UTC)

This is an excellent point. We don't have any accurate automated way to assess contribution levels, and xtools authorship isn't it (neither is bytes added or edit count). Levivich (talk) 18:56, 5 April 2024 (UTC)

Just because an algorithm isn't currently implemented, does not mean an algorithm doesn't exist. As a rough starting point: authorship+curation can be measured by taking the diffs made by an editor to bring text in line with the current stable state, weighted by time. (For the simplest measure, you can just use edit longevity with hysteresis.) Now, absent some new API properties, this is an expensive calculation to maintain for every article, but it's perfectly technically doable. (Another, more sophisticated method is analogous to a co-authorship network.) Of course this has been done before: Arazy et al 2010; Lanio & Tasso 2011 (citing Biuk-Aghai 2006). SamuelRiv (talk) 19:28, 5 April 2024 (UTC)

No algorithm will be perfect though, and the exact value of things other than clear-cut addition/removal is to some extent subjective. ― novov (t c) 01:57, 7 April 2024 (UTC)

• Fundamentally, I think this is a nice idea and seems like it would be easy to implement since we already track editor contribution metrics, so it would just be a matter of making this visible on the page itself somewhere, maybe in the footer (though, yes, XTools is imperfect and an alternate system would probably be better). That said, I would hope there might be some opt-out system for those of us who don't want any sort of public credit, which includes me. (I never let anyone IRL know what WP articles I've worked on because the layperson assumes that the current status of any given WP article I "created" represents my writing. And, in many cases, I want nothing to do with how an article I "created" has evolved.) Chetsford (talk) 02:07, 7 April 2024 (UTC)
• Much as with the hall of fame suggestion (people really seem to be concerned with credit and recognition, lately), this could go so very badly. Any algorithm that we set up is going to be full of holes. It is simply impossible to represent, with any sort of non-LLM algorithm, the extent to which an edit impacts an article's development and structure for a multitude of reasons. The first reason is the fact that anyone can edit Wikipedia, and edits are happening on a constant, minute-by-minute, second-by-second basis. An article could look one way today and then look totally different the following day, if it gets a massive rewrite. How would one recognize contributions in that scenario? If Editor X wrote the previous version of the article before its replacement, do they lose attribution now that it's been rewritten? Or do they receive attribution for something that no longer resembles their work?

The second reason, for Wikipedia articles, especially larger ones, the whole is greater than the sum of its parts. One can do a massive amount of copy-editing in a large edit, mainly to make stylistic or grammatical corrections, and as a result it would have very little impact on the article's growth but they would be considered an outsized contributor. On the other hand, the addition of a few vital facts or details could contribute heavily to the article's development, ensuring that it's meeting WP:GNG or perhaps even putting it on the road to becoming a WP:GA.

The third reason is that someone will always disagree with the algorithm that determines who is an author. Attitudes on Wikipedia among editors regarding WP:OWNERSHIP are already very fierce. This would exacerbate it to a fever pitch. Or it would simply not be taken seriously, if enough people take umbrage with it. This metric would be divisive at worst, and superfluous at best. If one wanted to track the metrics of the article, the "Statistics" are available for this very reason. They do not attempt to ask the question "who wrote this article?" They simply provide the data. In fact, it's a good rule of thumb - Anytime you ask any sort of question regarding creative or scholarly human impact, the question should always be answered by a human and not by a machine. _{Duly signed,} ⛵ WaltClipper -(talk) 13:20, 15 April 2024 (UTC)

• I've got a slightly different idea that I think gets around Ownership issues and the algorithm not being able to make a perfect summary of "main editors". What if it just counted the contributors, that wouldn't be nearly as expensive a calculation and the text could read:

This article was created by 3,428 volunteer editors. (and you could be one of them).

The number of bot editors would need to subtracted of course. It would serve the purpose of directing anyone who wanted to know all the editors to the right page, and it would both more accurate and more precise than saying "This article was written by a monolithic 'Wikipedia'" And just for fun, there could be a text variant depending on whether the editors of that article includes the logged in user or not, saying:

This article was created by 3,428 volunteer editors. (including you)

I think one line like this could potentially be a lot more informative to a lay reader than the "about" pages that I don't know if anyone actually reads. -- D'n'B-t -- 18:25, 25 April 2024 (UTC)

Like Levivich (talk) 19:25, 25 April 2024 (UTC)

Wikipedia Hall of Fame?

What are your thoughts? Is it going to work? Comment down below. Wolverine XI ^{(talk to me)} 17:28, 8 April 2024 (UTC)

Hall of fame topic; section break 1

• I'll bite. What do I get? Like, a room with a comfy chair? The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons. BD2412 T 17:37, 8 April 2024 (UTC)

  "The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons." That's a good point. Though, IMO, I don't think HOF should be behavior-exclusionary and should be open to anyone who has made an enduring impact on WP, regardless of how they made the impact. For instance, I say induct Jordan French (maybe not in the inaugural cohort, but eventually). Chetsford (talk) 18:47, 8 April 2024 (UTC)

  I agree with Chetsford on this. Wolverine XI ^{(talk to me)} 04:11, 9 April 2024 (UTC)

  French certainly made an impact but then so did many LTA vandals. If this idea is adopted, it seems appropriate to limit membership to those who have shown altruism rather than encouraging those who make Wikipedia worse for personal gain. Certes (talk) 08:24, 9 April 2024 (UTC)

  Never say never. Wolverine XI ^{(talk to me)} 13:16, 9 April 2024 (UTC)

  Yeah, that's a good point, Certes. I think this was intended more as an exaggeration for emphasis that we not be rules-bound for a HOF, but probably not a good example to underscore that! Anyway, I agree with your suggestion. Chetsford (talk) 15:26, 9 April 2024 (UTC)

• We already have a lot of perks for experienced editors (Special holidays, Wikimedian of the Year, Editor of the Week, Service awards, ...), and I honestly don't think we need yet another way to separate "elite" Wikipedians from the rest of us. Chaotıċ Enby (talk · contribs) 18:02, 8 April 2024 (UTC)
• Similar to Internet Hall of Fame, to be serious, there would need to be a reliable advisory board. They can help surface little known but important people from the early founder days. It could be a popular vote nomination process, like the Nobel, but picking the winners would need a small august body, known for deep institutional knowledge and experience. After a few rounds/years of winners, those winners then become members of the advisory board. Overall this is probably something that should be organized by WMF. Or you can just do it, but it will be another "This one is special. This one is also special" award. -- GreenC 18:32, 8 April 2024 (UTC)

  @GreenC, i like the discussion here of this idea, but how about an opposite approach? such as, anyone who wants to be in the hall of fame, can be?? and maybe split it up by topic, so that it would have some actual useful format to make it readable to others? Sm8900 (talk) 20:10, 17 April 2024 (UTC)

• I like it. While we may have a superfluidity of awards, these cost essentially nothing to produce so I'm not sure I ever understand the resistance. All recognition systems are voluntary and those who don't approve can opt-out. Moreover, a HoF -- if managed through some approximation of the way GreenC describes -- would be different from existing accolades which are either interpersonal recognition (editor to editor) or metric-based recognition (e.g. Four Award, etc.). Chetsford (talk) 18:41, 8 April 2024 (UTC)

Hall of fame topic; section break 2

• Of course they "cost nothing to produce", that's not the problem, the problem is that they give one more excuse to divide Wikipedians between "the ones who have power" (i.e. the unblockables) and the plebs like us. Chaotıċ Enby (talk · contribs) 13:36, 10 April 2024 (UTC)

• It might be a good idea. 3.14 (talk) 19:07, 8 April 2024 (UTC)
• The key questions for any initiative is what is the objective, and how helpful is the initiative in achieving this objective? For recognition programs, it's important to also consider how the selection process will work, and whether or not it will create more difficulties than benefits gained. Recognition programs are tricky because the flip side of selecting some is that many others are not selected, and that can result in conflict. isaacl (talk) 02:36, 9 April 2024 (UTC)

  That's how recognition programs work, but I don't think they'll necessarily cause any conflict. Wolverine XI ^{(talk to me)} 04:09, 9 April 2024 (UTC)

  "it's important to also consider how the selection process will work" After the inaugural cohort is selected, maybe it should become self-perpetuating with all prior inductees selecting each subsequent cohort. (Though you'd still need some system to choose the inaugural cohort.) This would mitigate politicization and degradation as inducted members would have a vested interest in maintaining its reputational coherence. Chetsford (talk) 05:37, 9 April 2024 (UTC)

  That would be difficult if they are dead or so long retired from WP they don't give a toss about the place anymore/are out of touch about who is still active and "deserves" a shout. - SchroCat (talk) 07:44, 10 April 2024 (UTC)

  "would be difficult if they are dead" I imagine it would. Chetsford (talk) 08:48, 10 April 2024 (UTC)

  I would object to exclusion of the deceased. There are some amazing editors who left us too soon, but with great work done first. BD2412 T 02:37, 11 April 2024 (UTC)

  We don't mean a blanket exclusion, just that we will ensure that batches of cohorts keep on coming; this line of discussion was about a proposal to have each cohort select the next. Aaron Liu (talk) 02:59, 11 April 2024 (UTC)

  I don't think we'll select a cohort that are all dead or inactive, for the reasons you've mentioned. Aaron Liu (talk) 11:34, 10 April 2024 (UTC)

  I think it best if you don't have any intake at all: voting for one's friends make this an inbred and insular process. As I've said before (as has Chaotic Enby), this is a bad idea - divisive and with the potential for conflict when the "wrong" people are elected and the "right" people over looked. - SchroCat (talk) 12:02, 10 April 2024 (UTC)

• The English Wikipedia Hall of Fame idea sounds peachy keen, as Babe Ruth would say before tying his hands behind his back and hitting a home run with his neck (Ruth is, all kidding aside, the most underrated ballplayer in baseball history). The initial "class" obviously would include J and L, the pioneering heroes of our story, and I can think of several others who would be obvious. That first class probably shouldn't be large, maybe 7 or 8 inductees. Then the rules get tricky, but doable. In a perfect world we'd lock J and L in a room until they get to a place where they can come up with a plan of how to handle this that everyone says "Of course that's how it should be done". But, bottom line, I think an EWHoF is a good idea all around (without WMF involvement). Randy Kryn (talk) 03:22, 10 April 2024 (UTC)
• A second rate popularity contest with ill-defined criteria? What could possibly go wrong. Terrible and divisive idea. You think someone's great - give 'em a barnstar, or, even better, leave them a thank you note, but to 'promote' people who will undoubtedly be divisive to others? That way grief and conflict lies. And this ignores the fact that "hall of fame" is not a worldwide concept that people everywhere readily grasp or buy into.- SchroCat (talk) 07:44, 10 April 2024 (UTC)

  Schro, the procedure is akin to the Wikimedian of the Year, except that it exclusively concentrates on the English Wikipedia. There's a purpose for these initiatives, and I firmly disagree that this is a "bad idea." Wolverine XI ^{(talk to me)} 13:25, 10 April 2024 (UTC)

  You are, of course, entitled to disagree. For what it's worth, I think the Wikimedian of the Year is a fairly crap award too, being a process with no criteria and something else that divides, rather than unites. Most people are happy to do the work for the sake of the work, not to seek vacuously external praise or validation just because they've caught the eye of someone powerful or happen to be pushing a zeitgeist line of thinking. - SchroCat (talk) 14:44, 10 April 2024 (UTC)

  As you haven't yet stated the purpose behind your suggestion, nor proposed a process, there isn't enough info to understand the potential benefits and costs. There's an understandable view that costs quickly outweigh benefits as any process involves more people, adding up to more total effort expended. isaacl (talk) 16:53, 10 April 2024 (UTC)

Hall of fame topic; section break 3

• More awards? At this rate, all our time will be spent giving ourselves pats on the back and giving each other shiny things. While I don't agree with the more extreme anti-award views (take wiktionary for example; wikt:Template:User barnstar has been nominated for deletion twice, and been described as cheesy and gaudy. I don't think we need all that Wikipedia's tinsel to encourage people.), we shouldn't go overboard with this. Cremastra (talk) 22:07, 10 April 2024 (UTC)

  (the correct link is wikt:Template:User Barnstar, with a capital B. Aaron Liu (talk) 01:51, 11 April 2024 (UTC)

  Thanks. Cremastra (talk) 19:39, 12 April 2024 (UTC)

  It's okay if you choose not to participate in the process. Wolverine XI ^{(talk to me)} 04:55, 11 April 2024 (UTC)

  How would one choose not to participate? I would not participate, but saying so would make it look as if I thought I stood a chance of being elected, which I do not. I imagine that most of those who would choose not to participate think the same way. Phil Bridger (talk) 20:07, 11 April 2024 (UTC)

  Maybe. Wolverine XI ^{(talk to me)} 16:07, 12 April 2024 (UTC)

I don't much like anything on Wikipedia which encourages elitism, political campaigns, cliques, inequality, etc. I can imagine that many wiki-politicians would waste a lot of time campaigning to be elected to a HOF and that the results would be divisive. "How come so-and-so got elected, and I didn't?" Smallchief (talk) 21:44, 12 April 2024 (UTC)

• I think this sort of thing is better left to other sites. Maybe the people who hang out at Wikipediocracy would create a Wikipedia Hall of Fame? Or would it become a Wikipedia Hall of Infamy? Phil Bridger (talk) 08:09, 13 April 2024 (UTC)

  I especially don't like the idea of putting infamous characters in a HOF. Follow baseball standards. Pete Rose and Shoeless Joe Jackson are not in the baseball HOF because of scandal, despite being qualified. No bad actors, no matter how famous, in a HOF. Smallchief (talk) 09:04, 13 April 2024 (UTC)

  Good point, but Wikipedia is not baseball. Wolverine XI ^{(talk to me)} 06:57, 14 April 2024 (UTC)

  Indeed. Baseball is a sport where defeating others on the field is encouraged. Wikipedia is a cooperative endeavour where it's frowned on. Certes (talk) 09:48, 14 April 2024 (UTC)

  Yes, this program is designed for honoring purposes rather than competition. I hope that's clear to all. Wolverine XI ^{(talk to me)} 04:41, 16 April 2024 (UTC)

  In that case, it seems the honor should not be of the Wikipedian itself, but of the work that they accomplished in a given area. That's why the Barnstars exist, of course. Just as WP:NPA encourages us to comment on the content and not on the creator, so too should we be aware to not place individual people on a pedestal.

  Frankly I find it disappointing that, in bringing forth the idea, the OP has not brought forth any comprehensive or detailed arguments in support of this idea and in response to the above critique. We are simply discussing a nebulous concept of recognition, which I think Wikipedia already addresses, and which if people really needed to see more of, they could use other websites or mediums for this purpose. _{Duly signed,} ⛵ WaltClipper -(talk) 12:29, 16 April 2024 (UTC)

  And we do celebrate content, quite satisfactorily, with DYK and TFA. So there is no need for a "hall of fame", it's just more self-congratulation. Cremastra (talk) 20:45, 16 April 2024 (UTC)

  how about a lounge for experienced wikipedians? would that be immediately misused, or could it serve a helpful purpose? Sm8900 (talk) 13:41, 17 April 2024 (UTC)

  That would just be a way to create an in-group, and I don't really see how it would help the project. Chaotıċ Enby (talk · contribs) 13:47, 17 April 2024 (UTC)

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

  Who decides who is experienced enough? On what basis? I hope it's not edit count, which can vary enormously between people having the same overall effect. Phil Bridger (talk) 15:48, 17 April 2024 (UTC)

  Like an actual lounge, or some cliquey forum that would do nothing to benefit the project? All these ideas go against our core principles. Cremastra (talk) 19:46, 17 April 2024 (UTC)

  ok, fair enough; all of these points are quite valid. so then, how about a lounge which would be labeled as being open to all experienced wikipedians, plus anyone who wishes to shmooze with them? that way, we are actually opening it to everyone, but giving it an underlying theme for those who are interested.

  to use an analogy, it would be like opening a lounge for woodworkers, or one for musicians, or one for ferryboat drivers, and also admitting anyone interested in that specialty. it would be basically open to anyone, and yet the theme would be clearly stated in terms of the specialty which is its actual focus. Sm8900 (talk) 19:56, 17 April 2024 (UTC)

  can an editor nominate themselves for this "Hall of Fame"? if so, then it might preserve the grassroots nature of wikipedia, and still have a positive effect. kind of like hanging out at the local skateboard park, and popping wheelies to show off one's skills to other fellow aficionados. Sm8900 (talk) 20:08, 17 April 2024 (UTC)

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

  What would actually be the point of having a lounge with this theme? Like, how would it help the project like, say, the Wikipedia:Teahouse, the Wikipedia:Help desk or the Wikipedia:Administrator's noticeboard does? Chaotıċ Enby (talk · contribs) 21:21, 17 April 2024 (UTC)

  The idea of an "experienced user lounge" very much echoes of Wikipedia:Esperanza which, although it did result in useful derivative projects, very much had a problem back in its day with regards to ingroup/outgroup behavior. _{Duly signed,} ⛵ WaltClipper -(talk) 12:58, 18 April 2024 (UTC)

• One downside of this proposal is that it would involve a fair amount of the electorate's time if they are not to just elect people who they already know. That time would be better spent improving the encyclopedia, which is what we are here for (or at least are supposed to be here for). Phil Bridger (talk) 15:48, 17 April 2024 (UTC)

  another idea; how about simply call it something whimsical or jocular, such as "Wikipedia League of Super-friends"? or "league of adventurers"? that way, it still retains the air of a unique league, yet it would be clear it is not anything awarding actual higher privileges here. Sm8900 (talk) 20:15, 17 April 2024 (UTC)

  I still don't see what the actual point is. Even with a funny name, it will still be a pretty divisive thing. Chaotıċ Enby (talk · contribs) 21:22, 17 April 2024 (UTC)

  Divisive programs, like the WP:Editor of the week, already exist. Wolverine XI ^{(talk to me)} 22:41, 20 April 2024 (UTC)

  And that's not an excuse to have more of them. Chaotıċ Enby (talk · contribs) 22:46, 20 April 2024 (UTC)

  OK, if you say so. Let us see if we can reach a consensus. Wolverine XI ^{(talk to me)} 23:10, 20 April 2024 (UTC)

  Editor of the Week was set up with a specific goal in mind: to demonstrate appreciation of specific positive behaviours and collaborative spirit by its recipients, with an explicit disclaimer that it's not intended to be a judgement about their overall characteristics. It was deliberately set up as a no-big-deal award with a very lightweight process, to avoid making it something that people would argue a lot about. The original pool of candidates was lesser-known editors, in order to give them a bit more encouragement to continue contributing, but has since been broadened to anyone. It's basically a slightly fancier barnstar, with some people slapping recipients on the back with a "good job". As a result of this carefully planned design, it hasn't fostered division. isaacl (talk) 02:05, 21 April 2024 (UTC)

Many such award schemes have been previously proposed. Only two, to my knowledge, still function: WP:QAI, because of the dedication of one editor, and WP:EOTW. If you want another one, set it up and run it yourself—if people like it, you can then apply to formalize it as a Wikipedia-wide process. ~~ AirshipJungleman29 (talk) 12:13, 26 April 2024 (UTC)

Timestamp on video references

If a web reference leads to a more than hour-long video, but the citation in question involves a 10-second clip, I believe that could be made more accessible to a reader. I see this being something like an optional field on the web citation, but I’m really not very sure. Aaronlearns (talk) 01:47, 11 April 2024 (UTC)

{{cite video}}? Aaron Liu (talk) 02:59, 11 April 2024 (UTC)

{{Cite AV media}} already has a time parameter. For an example of it being used, see the references section of Half-Life (series). ― novov (t c) 03:02, 11 April 2024 (UTC)

Thank you both for these, sorry to bother.Aaronlearns (talk) 05:38, 11 April 2024 (UTC)

For YouTube videos you could add {{rp}}, as seen at Draft:New York City Jazz Mach61 13:21, 11 April 2024 (UTC)

@Aaronlearns, the |at= parameter works in a lot of the citation templates. It accepts free-form text describing where to find the source. You could easily write something like "starting at 23 minutes, 11 seconds" WhatamIdoing (talk) 02:42, 20 April 2024 (UTC)

Search bars within the article

This is just an idea I had just now that there should be little search bars in different writings such as articles, category pages, lists etc. I feel it would be more effective and easier to use Wikipedia and so you can search for exactly what you want instead of having to scroll for ages, (depending on length). Thoughts?

｡ 🎀 𝒫𝓊𝓇𝓅𝓁𝑒𝓁𝒶𝓋𝑒𝓃𝒹𝑒𝓇𝓂𝒾𝒹𝓃𝒾𝑔𝒽𝓉𝓈 𝟣𝟩 🎀 ｡ (talk) 01:00, 19 April 2024 (UTC)

It's already (kind of) a thing with Ctrl+F! Chaotıċ Enby (talk · contribs) 01:10, 19 April 2024 (UTC)

oh okay ｡ 🎀 𝒫𝓊𝓇𝓅𝓁𝑒𝓁𝒶𝓋𝑒𝓃𝒹𝑒𝓇𝓂𝒾𝒹𝓃𝒾𝑔𝒽𝓉𝓈 𝟣𝟩 🎀 ｡ (talk) 01:52, 20 April 2024 (UTC)

I think we should just leave that to the browser. Aaron Liu (talk) 02:31, 19 April 2024 (UTC)

This discussion is a bit old but I will note that the wikipedia app has a search function, if that's any help. ¿VØ!D? ✨ 19:49, 26 April 2024 (UTC)

As others have said, this can be done with the browser's inbuilt search function. However, very few users seem to know about that feature, which is a problem especially for longer web pages (as many of our articles are). A second, Wikipedia-specific problem is that (by default) it does not work on mobile web because the sections after the lead are collapsed. Regards, HaeB (talk) 21:10, 26 April 2024 (UTC)

Recreating an article that was deleted in 2023

Hi. Am I allowed to try and recreate an article that was (ironically) created by me, but was deleted later, because it didn't have good sources. I'm asking this because I'm not sure if the article will be just automatically deleted. FYI, I have gathered much better references this time, so I was wondering if I could recreate the article with new sources. --Pek (talk) 16:45, 20 April 2024 (UTC)

See WP:REFUND. More specifically it would likely be best to approach the admin that deleted the article and ask that it be recreated in user or draft space, so that you can then add the references. Once you do that, you should then ask that admin if the article is good enough to move back into mainspace. Masem (t) 16:50, 20 April 2024 (UTC)

As Masem said, with the addition that if the article was deleted via the WP:PROD procedure it can be restored to article space, but you may find that it gets nominated for deletion at WP:AFD if you don't add notability-defining sources very quickly. Phil Bridger (talk) 18:36, 20 April 2024 (UTC)

In your place, I would start a new draft, take your time writing it, and when you're done, submit it for review. Gråbergs Gråa Sång (talk) 09:36, 21 April 2024 (UTC)

You can recreate it the day after it's deleted if you want – As long as the content is substantially different and you've made a good faith effort to address the reason for deletion. You can do so via draftspace as suggested above, but you don't have to. Either way, the important things to be aware of are 1) there's also nothing stopping someone else immediately nominating it for deletion again and 2) repeatedly recreating something that other editors don't think should exist is the kind of thing that very quickly exhausts the community's patience. – Joe (talk) 11:16, 21 April 2024 (UTC)

Small utility

https://foundation.wikimedia.org/wiki/Legal:Wikimedia_trademarks/Word_mark_creation contain instructions to correctly create svg wikipedia logo. Is there any chance to create a small utility that contain only 3 fillable fields (first is for project name, second is for slogan and third is for language code) and one button (create svg, which save svg file on desktop), similar to this?

+------------------------------------------------+
|  __________________________                    |
| |__________________________|    ___________    |
|                                |create svg|    |
|  __________________________     -----------    |
| |__________________________|                   | 
|                                                |   
|  __________________________                    |
| |__________________________|                   |
|                                                |
+------------------------------------------------+

The utility could be used for help graphists to make faster the process of logo creation. --93.47.36.228 (talk) 15:00, 23 April 2024 (UTC)

I'm not really into graphics design, but shouldn't there be more to this? The 🏎 Corvette 🏍 ZR1^{(The Garage)} 16:55, 24 April 2024 (UTC)

Cite more articles faster and with better quality sources

Currently we have an embarrassingly large backlog named Category:Articles lacking sources with 94500 articles in it. The WikiProject Unreferenced articles, even with its fairly active membership, can only clear 500 articles every week, which amounts to around 3.5 years to clear the backlog. I'm curious, do you guys have any ideas to accelerate this progress? CactiStaccingCrane (talk) 06:41, 26 April 2024 (UTC)

I looked at a couple dozen articles in Category:Articles lacking sources from March 2024 and I found that more than half of them were incorrectly tagged. Specifically, they didn't have little blue clicky numbers, but they did contain external links that verified some of the content of the article, and one or two had a list of books.

I suspect that the fastest way to reduce the number would be to send a bot through all the articles to replace {{unref}} with {{No footnotes}} if there are any URLs anywhere on the page. It wouldn't catch everything, but it might clear thousands of articles. WhatamIdoing (talk) 08:20, 26 April 2024 (UTC)

That would just push the problem to another backlog, which is bad practice. But you give me an idea... if a lot of these articles already have external links, why not use that to create an inline citation? CactiStaccingCrane (talk) 14:03, 26 April 2024 (UTC)

Triage is not bad practice. Levivich (talk) 14:09, 26 April 2024 (UTC)

I have to agree. CactiStaccingCrane (talk) 14:11, 26 April 2024 (UTC)

I think you're being hard on the Wikiproject if they're clearing 500 articles a week. That's admirable. CMD (talk) 08:29, 26 April 2024 (UTC)

One solution is the “one step back, two steps forward” approach: Delete the existing unsourced articles, and encourage people to create NEW articles on the same topics - this time with proper sourcing. Blueboar (talk) 12:29, 26 April 2024 (UTC)

This is literally Wikipedia:Village_pump_(proposals)#Deprecating_new_unsourced_articles, but the community has rejected this proposal. CactiStaccingCrane (talk) 14:01, 26 April 2024 (UTC)

Yup… but… consensus can change. Not saying it has changed, just that it can. Blueboar (talk) 14:29, 26 April 2024 (UTC)

How about making a proposal to every WikiProjects so that they cite all articles belonging to the Wikiproject with at least one source? We already have the Bambot cleanup listings (click "by cat" then "Cites no sources"). We just need to put it to work. CactiStaccingCrane (talk) 14:43, 26 April 2024 (UTC)

A WikiProject is a group of people who want to work together to improve Wikipedia. They don't own articles, and they aren't responsible for them. WhatamIdoing (talk) 16:16, 26 April 2024 (UTC)

@Blueboar: Highly unlikely that it changed since 10 days ago. Even the month between that and Wikipedia:Requests for comment/Deletion of uncited articles was probably too little time for consensus to have changed. Anomie⚔ 16:29, 26 April 2024 (UTC)

Essentially the reason that the proposal from a few days ago was rejected was because it created a "grandfather clause" where older unsourced articles would be allowed to fester while ones would be stopped at the gate. I would suggest then that any drastic action on unsourced articles should start at the other end of the backlog with articles that have been unsourced for over 15 years. -- D'n'B-t -- 17:52, 27 April 2024 (UTC)

Fun fact: Non-BLP articles are not technically required to name a single source unless there is some specific material that falls into one of the categories listed by WP:MINREF. If you can write an article that avoids those categories (e.g., the content is something like "The capital of France is Paris"), then you are not required to cite any sources. Only the material that fits one of those sources is required to have an WP:Inline citation.

Consequently, if you want to be able to delete non-BLP unsourced articles the way that we currently delete BLP unsourced articles, that requires a change in policy. WhatamIdoing (talk) 16:21, 26 April 2024 (UTC)

Give deletion ability to pagemovers

I believe that the ability of deletion should be extended to pagemovers because there aren't very many of them (405 to be exact) and are probably able to be trusted with the tools. The CSD backlog can be high at times, and there are not very many admins to deal with that issue. 2003 LN6 14:32, 26 April 2024 (UTC)

"Are probably able to be trusted with the tools" is not a great argument given that any admin can add new people as pagemovers, and that the qualifications needed for pagemover are not immediately CSD-related. Plus, giving only one part of the block/protect/delete triad would lead to the law of the instrument. Chaotıċ Enby (talk · contribs) 14:34, 26 April 2024 (UTC)

(Note: Page movers already have the deleteredirect permission, but it is exclusively for moves overwriting previous redirects, and doesn't give them deletion powers outside of the scope of page moving) Chaotıċ Enby (talk · contribs) 14:36, 26 April 2024 (UTC)

One would think that admins were approved by the community because they are trustworthy. Dege31 (talk) 17:50, 28 April 2024 (UTC)

Having only delete but not undelete is pretty bad since mistakes can happen, and WMF wants undelete to only be conferred to those vetted by the community, e.g. admins. Aaron Liu (talk) 15:50, 26 April 2024 (UTC)

It has been years since I last saw a serious CSD backlog (50 pages were normal, and 200 pages were common ten years ago), so I disagree that there is a need for more people at CSD. We generally need more admins for everything, though: those who "are probably able to be trusted with the tools" should just become admins as soon as possible. —Kusma (talk) 17:15, 26 April 2024 (UTC)

As a pagemover I agree, I wouldn't want delete without a way to undo my mistakes, and undelete as it currently exists in the software is not something we should be handing out widely as it can expose plenty of stuff that shouldn't be semi-public. That said, there's no reason that mediawiki couldn't add the ability to view and undelete only pages that you deleted, it would just take community consensus and the WMF to apply time and resources to making it happen. --Ahecht (TALK
PAGE) 17:23, 26 April 2024 (UTC)

This is nontrivial: you should not be able to undelete any revisions except those you have deleted. —Kusma (talk) 17:29, 26 April 2024 (UTC)

@Kusma: Making sure I understand you correctly - if a page that had some revision(s) deleted was then as a whole deleted and then undeleted, you're saying those revdels would be undone? Tazerdadog (talk) 02:34, 27 April 2024 (UTC)

The "undelete" screen shows all deleted revisions. To implement @Ahecht's idea, I think we would need an additional "pagemover-deleted" state that a revision can be in (in addition to visible, deleted and oversighted) and allow pagemovers to see and undelete all pagemover-deleted revisions. —Kusma (talk) 06:33, 27 April 2024 (UTC)

Forgive my ignorance (I'm not an admin) but I wonder whether there is a wider problem here. Putting pagemovers aside for a moment, suppose an admin deletes a page which already had certain revisions deleted. The admin then undeletes the page. Does the admin have to remember to repeat the revdels, or at least deselect them from a list of versions to be restored, or do those revisions stay deleted automatically by default? From an ordinary user's perspective, revision deletion looks different from page deletion. I can see that a deleted revision exists and (unless someone deliberately stops me) see which user contributed it and read the edit summary. For a deleted page that data isn't available without some digging. Certes (talk) 17:55, 27 April 2024 (UTC)

I don't remember how it is with revdel (when I passed RfA, revdel was done by hand, by deletion and selective undeletion, and some people dealt with bad revisions that are nowadays oversighted by a combination of deletion, undeletion and page moves), but if you delete a page, somebody recreates it, then you delete it again (this scenario is more common than undeleting pages that have revdel'd revisions), "undelete" makes no difference between the two sets of page revisions. —Kusma (talk) 18:07, 27 April 2024 (UTC)

Revdelled revisions stay revdelled after a page undeletion. I was pretty certain this was already the case, but I've just confirmed it at User:Cryptic/sandbox4.

What I'd be more concerned about is whether there are old deleted revisions hanging around somewhere at a title that predated the deletion log, which is the only way to find out who deleted it. There don't appear to be any, but revdeletion and oversighting play nasty tricks with what's visible in the toolforge replicas. —Cryptic 20:11, 27 April 2024 (UTC)

Random serendipity. I stumbled across some of those only a few hours ago at XXXDial. But they're just random nonsense that could be made public. Anyway oppose this as having too little to do with page movers' existing rights, but I could be talked into supporting a separate deleter role with many of the same caveats as above. * Pppery * _{it has begun...} 20:15, 27 April 2024 (UTC)

Thanks to you both. I hoped that retaining revdels was too obvious a feature to have been overlooked. Obviously(?) oversight/suppression will be kept too, as most admins won't have the opportunity to restore those revisions in a visible state. Certes (talk) 20:23, 27 April 2024 (UTC)

Oh, duh, I badly bungled my query. Yes, there are lots of these. But on further reflection, I guess it wouldn't matter; since there aren't already any pagemover-deleted deleted revisions to worry about, it could be done by adding a who-deleted-this column to archive. (Not that I think the overall proposal is a good idea either.) —Cryptic 20:26, 27 April 2024 (UTC)

I agree that pagemover is not the ideal role for this, but I think Pppery's deleter role is worth exploring. We could make a role and give it delete. Then we make an adminbot, which will email and/or undelete the page for a deleter on request if and only if they were the most recent person to delete it. This should solve issues with WMF wanting vetting for viewdeleted (the bot only lets you view and undelete stuff you delete), issues with undeleting too much (the bot does the undeletion on the deleters behalf and so can't mess it up), and accountability (the deleter can view their deletions and fix mistakes - there's actually a higher level of accountability than there is for admins, because viewing deleted pages will be logged). This role could get combined with some level of protect/unprotect and block/unblock, but that can be hashed out later. Tazerdadog (talk) 16:03, 28 April 2024 (UTC)

That is an interesting idea, though I still don't see a need for it. Aaron Liu (talk) 16:10, 28 April 2024 (UTC)

There is no need for a separate role. Anyone who wants to be able to delete pages can apply for adminship. The requirements should be the same for deleting articles as for the other parts of the admin package. Phil Bridger (talk) 16:19, 28 April 2024 (UTC)

I think that we can make unbundles that are both useful to the people who recieve them and require a level of trust such that they can be given out at the discretion of a single admin. It would be nice if the RfA process was a good solution, but it is often intimidating or unpleasant. Examples of these unbundles include giving a recent changes patroller the ability to delete a recently created page and use the bot to view/undelete, semiprotect a page temporarily, or block a non-autoconfirmed account temporarily. Alternatively, a regular at AFD who is good at evaluating consensus could be given the delete/use the bot to undelete buttons. AfD is an area where I have noticed significant backlogs. The enforcement on this can be social or technical - giving our AfD regular the full delete permission and a bright line social rule that they don't use it outside of an AfD closure seems perfectly workable to me. Tazerdadog (talk) 16:54, 28 April 2024 (UTC)

Many editors are trusted to behave responsibly but do not claim competence in every single activity that the sysop bit makes possible. Such people are put off applying for RfA but could usefully contribute more if given carefully designed lesser privileges matched to their expertise. Certes (talk) 18:30, 28 April 2024 (UTC)

The ability to delete articles is not a "lesser privilege", but the most powerful part of the admin toolset, because it directly affects what the reader can see. I can't imagine trusting anyone with that power who I would not also trust with blocking and page protection. Phil Bridger (talk) 19:19, 28 April 2024 (UTC)

This bot can't possibly work. As described, it lets you undelete any page: if you weren't the most recent deleter, then you just create it and delete it. It can't even work if you try to make it only allow undelete of pages where you're the only deleter, or only undelete revisions that you deleted: because of the deleted pages from before the deletion log - there are some 70000 of them - it won't even be able to tell that a page had been previously deleted, let alone when or by who. Pages whose deletion logs have been revdelled or suppressed have the same problem. —Cryptic 18:55, 28 April 2024 (UTC)

Wouldn't creating, deleting, and undeleting only show the version of the page one created? Aaron Liu (talk) 19:17, 28 April 2024 (UTC)

I think so too. Any earlier revisions are of a different page that happened to have the same title. Have we missed something? Certes (talk) 19:19, 28 April 2024 (UTC)

That's not how it works. See Kusma's comments above. —Cryptic 19:24, 28 April 2024 (UTC)

1. I'll admit that on re-reading, I don't understand what "no difference between the two sets of page revisions.
2. The user will not have access to the undelete screen; the bot will restore the last version deleted. Aaron Liu (talk) 19:39, 28 April 2024 (UTC)

So if someone replaces, say, Ton with spam, a minideleter deletes it, everyone shows up to his talk page to complain that it was a legitimate page, and he tries to undelete it, he only gets the single revision with spam? And he doesn't even have any way to first check that he's not undeleting spam - or, for that matter, something that should have been oversighted instead of just deleted? That's significantly worse than having no method of undeletion at all. —Cryptic 20:01, 28 April 2024 (UTC)

No. My assumption is that different creations of pages have different histories associated with them, and by "version"' I didn't mean revision, but everything associated with what was deleted by the minideleter (including re-suppressing relevant revisions) Aaron Liu (talk) 20:46, 28 April 2024 (UTC)

Your assumption is incorrect. Once a page is deleted, it's only accessible by namespace+title, and its invididual revisions only by namespace+title+timestamp. This is why history merging works. —Cryptic 22:37, 28 April 2024 (UTC)

The proper amount of history for the bot to restore is everything after the most-recent non-self deletion (i.e. what the minideleter could see when they deleted it). That means that the minideleter should still have the most recent versions of Ton to back up to almost always. The minideleter should be able to have the content eligible for restoration emailed to them, including the history and any revision they could see when they deleted the page, so I'm not worried about that excessively, although it might get annoying if it's complex. The problem is I'm doing basically what @Cryptic: said above - only undeleting revisions the minideleter deleted. Can't an adminbot see revdelled deletion logs? Can a database query get us the 70k pages with deletions that predate the logs? We could just exclude those pages and have the bot tell the minideleter to go get a "real" admin to sort those pages out, or have the bot refuse to restore a revision that predates the deletion log. Are deletion logs actually suppressed, and if they are, doesn't this create a minefield where a normal admin can restore oversighted pages without seeing they can do it? Tazerdadog (talk) 20:49, 28 April 2024 (UTC)

Yes, deletion logs get suppressed all the time, and revdeleted somewhat more rarely - whenever someone puts something suppressible in the page title itself, or in their username. Hiding either part by either method hides the entire log from queries, which means that any way to generate a list of deleted pages without corresponding logs is going to find both the ancient ones and ones where any part of the deletion log had to be removed. There are 1265 such titles in Draft:, for instance, and that's only counting the ones that have at least one deleted revision that hasn't also been revdelled or suppressed. A human will know not to undelete a page titled Draft:Tazerdadog's real name is Aaron Certes and he works for Cryptic Inc., and we can trust them not to because they've gone through seven days of community-wide vetting at RFA. If content like that is only in the page text, the revision will get revdelled/oversighted instead of the log and will remain so even if that revision is undeleted. Admins can see revdelled deletion logs, but have to jump through unintuitive hoops to do so. Forbidding restoration of old-enough revisions isn't a solution either; Wikipedia was already pretty big by the end of 2004, and lots of accidentally-deleteable pages have revisions that old.

This is a complex problem with many, many edge and corner cases, and the places it's most likely to go wrong are the same ones where we can least afford to let it. If we're dead set on doing this - and I don't think it's a good idea even without the technical considerations, at least a quarter of my deletions have to be followed up with a block, salting, blacklisting, or some combination - there are robust ways to do it. An adminbot cludge like this isn't one of them. —Cryptic 22:37, 28 April 2024 (UTC)

Thank you for clarifying. It sounds as if undeletion would be difficult to do correctly and hence unsafe. There's also the issue of undeleting revisions from before a page move, which sounds equally difficult if not particularly unsafe. Certes (talk) 11:55, 29 April 2024 (UTC)

Yep, thank you for the patient explanation Cryptic. I would be interested in hearing what you had in mind as a more robust way to do it - an adminbot was definitely a clunky way to do it, but I didn't expect the level of corner cases. Tazerdadog (talk) 18:45, 29 April 2024 (UTC)

I mentioned one above - add a column to the archive table with the actor_id of the person who deleted each revision. Or add a list of affected revisions to the log_params column of the delete log; that still might break, but doesn't need a schema change, and has the side benefit of making an operation like "undelete all revisions that were deleted by this deletion" possible and be a step toward making history merges less horrific to undo. The common theme is that they fail secure instead of open: if all or some part of the necessary data isn't there, then undeletion is denied. What I don't see is a way to implement this without any change to MediaWiki at all. —Cryptic 19:59, 29 April 2024 (UTC)

After my RfA passed, I quickly became curious about the contents of all the stupid goofy-ass deleted pages over the years, and set about to looking at some of them. Mostly, what I found is that the user interface for undeleting pages is horrifically bad. My hunch for why this is that, while Wikipedia's famous for being difficult to use, most of its features are exposed to hundreds of thousands of people -- whereas the admin-only features are only usable by a few thousand (many of whom have been using them for 15 years and have no desire to see them changed anyway). This means that not a lot of development time is devoted to fixing stuff like undelete, or making it easier to use, and it's not really that much of a priority (seeing as you only get to use the tools if you pass RfA, i.e. are extremely good at following complicated processes to begin with). Deleted revisions are also a total zoo: all sorts of crazy-go-nuts dreck is in there. jp×g🗯️ 04:53, 30 April 2024 (UTC)

No. There is no backlog worthy of the name at CSD. Even though my time zone doesn't match most admins it usually takes no more than a couple of hours for me to get a response. Don't be in such a hurry, and if you want to be able to delete pages then apply for adminship rather than for the pagemover right. Phil Bridger (talk) 19:13, 26 April 2024 (UTC)

WMF

Conversations with the Trustees - next call this Thursday 21st!

Hi all. I just wanted to give you a heads-up, in case you didn’t already know, that there are regular ‘Conversation with the Trustees’ events that you are welcome to attend and ask questions to the Wikimedia Foundation Board of Trustees (who oversee and guide the Foundation). I’m hosting the next one, taking place this Thursday 21st March at 19h UTC and, speaking as a long-time enwiki editor, it would be really nice to see people from here attending and engaging in the discussions. Please see m:Wikimedia Foundation Community Affairs Committee/2024-03-21 Conversation with Trustees for details! Thanks. Mike Peel (talk) 21:51, 18 March 2024 (UTC)

This is good to know about, Mike; thanks for sharing! Sdkb ^talk 18:31, 19 March 2024 (UTC)

Proposal: WMF should hire a full-time developer to do basic maintenance on MediaWiki

I've been disappointed with the state of disrepair of MediaWiki for years, but yesterday I've become aware of an issue that finally drove me to complain: there was a basic SVG rendering bug that has been fixed upstream 4 years ago, but it still torments Wikipedia readers because WMF can't be bothered to install the fixed version T97233. WMF also refuses to switch to a less buggy SVG rendering library T40010 or to let the browsers do the rendering themselves T5593. Other users there expressed skepticism that SVGs would ever work here and we should revert to PNGs instead, as such issues have existed for more than a decade without being addressed.

This lack of basic maintenance is not limited to SVGs. There is also the well-known issue that graphs are "temporarily" disabled, which was triggered by MediaWiki using the Vega 2 library for 6 years after its end-of-life, until this time bomb exploded in their face. It looks like the current "solution" is just disable graphs forever T334940.

Another issue is that MediaWiki still runs on Debian Buster, the Debian stable from two releases ago. Fun fact, it will be end-of-lifed in three months, so we'll have one of the biggest websites in the world running on unsupported software. And these are only the problems I have personally encountered. Other editors tell of many more that I won't list here.

One might think that this situation is due to a lack of funds, but this is not the case. WMF has so much money that it doesn't know what to do with it: Signpost May 2023, Signpost August 2023. That's why I'm launching this proposal to tell it: hire a full-time developer to do at least basic maintenance. It's unconscionable to donate millions of dollars to other charities while your own website is falling apart.

It would be in fact perfectly natural natural for such a wealthy foundation administering such a large website to fix bugs themselves, or even take over development of the libraries it depends upon. I'm not demanding that much. Only to keep the software stack remotely up to date. Right now it's downright archaeological. Our billions of readers are suffering through issues that the rest of the world has long solved. Tercer (talk) 15:56, 23 March 2024 (UTC)

As I understand it, the WMF has hundreds of staff and these include developers. Github has 558 names of such. So, my impression is that there's no lack of staff or other resources. Presumably it's more matter of organisation and fit. I'm guessing that there's a lot of legacy code and technical debt and maybe this is too brittle and rotten to maintain easily. The graph debacle indicates that senior management ought to be getting a grip on this before a more catastrophic gap opens up. Andrew🐉(talk) 17:58, 23 March 2024 (UTC)

Obviously WMF has some developers. Certainly not hundreds, let alone 558. In any case none of them is dedicated to maintenance, otherwise Wikipedia's servers wouldn't be in a worse state than my grandmother's PC. I assume they are working on sexy new features such as the visual editor, the reply function, or the dark mode. Maintenance is boring, and doesn't look impressive in your CV. Nobody wants to do it. That's why I'm proposing a full-time maintainer.

Your alternative theory that they have enough resources but still can't do maintenance can be summarized as rank incompetence, and that's too cynical for my taste. It's also not actionable. What could one propose? "Proposal: WMF should get its shit together"? Tercer (talk) 19:09, 23 March 2024 (UTC)

The WMF does appear to have hundreds of developers and engineers. For example, see Developers/Maintainers which has a specific column documenting maintenance responsibilities. Some of these are the responsibility of entire teams such as Wikimedia Site Reliability Engineering which has a headcount of about 45. There are still clearly gaps in this structure, as shown by the year-long outage of graphs, for example. But the idea that there's nobody currently responsible for maintenance in a general sense seems too simplistic. The problem seems more that there's a complex structure in which it's easy for issues to fall down cracks or for people to pass the buck. Andrew🐉(talk) 21:21, 23 March 2024 (UTC)

I took a look at the gigantic list in Developers/Maintainers; the first two names there are volunteers, not staff, so we can easily discount that as indicating that WMF has hundreds of devs. All the ones I clicked in Wikimedia Site Reliability Engineering, however, are actually staff, so we can take 45 as a lower bound for the number of devs. Fair enough, some of them are responsible for maintenance, but it's clearly not enough. The WMF can easily afford to hire another, and it should urgently do so. Tercer (talk) 23:07, 23 March 2024 (UTC)

I find these threads tiresome. By background, I'm a real software engineer for real money in real life. I do some software development on enwiki-related projects as a volunteer. The pay sucks (but it's no worse than I get paid for editing) but at least I get to pick and choose what I work on, when I want to work on it, and how I want to architect it.

I've found my interactions with the WMF development staff similar to my interactions with any dev group I've ever worked with. Some are good, some not so good. There's a few who are absolute joys to work with. There's a few who are grumps. But then again, you could cross out "WMF developer" and write in (with crayon if you like) "enwiki editor" and you would still have a true statement.

The basic architecture is 25-ish years old. There's a lot of legacy crud. The fact that the core system is written in PHP just boggles my mind. Recruiting must be a challenge. How do you attract top-shelf talent when what you're offering is an opportunity to work on a legacy code base written in PHP and salaries which I can only assume are not competitive with what the Googles and Facebooks and Apples of the tech world are offering. And yes, you are right, doing maintenance work is not what people want to do. If you told somebody, "Your job is to ONLY work on maintaining the old stuff and you'll never get a chance to work on anything that's new and shiny and exciting", I can't imagine you'd get many applications. RoySmith (talk) 23:54, 23 March 2024 (UTC)

And the slow code review process discourages the volunteers who are affected by longstanding bugs from working on fixing them. And of course a company with a known-bad workplace culture.

I think there are people, myself included, who would be willing to work on only fixing bugs rather than building new things in principle, but probably a lot of those people (again including myself) have internally vilified the WMF for exactly this reason so would consider it to morally repugnant to work for them. * Pppery * _{it has begun...} 00:32, 24 March 2024 (UTC)

I am one of those people. The experience described in that link is totally unacceptable and would lead to prosecution in many jurisdictions. I am ashamed to be associated with its perpetrators. Certes (talk) 01:41, 24 March 2024 (UTC)

That's why WMF has to pay them. You'll never get boring infrastructure work done by volunteers. And no, I don't believe you'd have any difficulty finding applicants if you offer a decent salary. Even for working with PHP (it's no COBOL, everybody knows PHP). WMF can afford to pay even a top salary from a tiny fraction of the money it has been setting on fire. Tercer (talk) 10:26, 24 March 2024 (UTC)

Yes, that sounds much more likely to succeed than giving the interesting work to the paid staff and hoping some mug will volunteer to do the grind for free. One option is make dedicated maintenance a role rather than a person, and to allocate it to a different member of staff each month. (Other time periods are available.) That way no one has to do it for long enough to drive them to resignation, and it's a chance to cycle the skill set with e.g. graph maintenance being done when a graph expert is on duty. Certes (talk) 11:44, 24 March 2024 (UTC)

Small bug fixes can be spread out amongst developers. But truly addressing significant technical debt means cleaning up the software framework to be more sustainable. That's not something that can be done effectively by rotating the work. isaacl (talk) 20:49, 25 March 2024 (UTC)

To add a bit to what Roy Smith described about software development: there are failures in managing it throughout the industry, particularly dealing with legacy code bases and a existing user population that generally wants all of their interactions to remain exactly the same. When the software has an associated revenue stream, there's a profit incentive to drive deadlines to be met, but when there isn't, the motivation is to get something that works implemented, as cheaply as possible. That tends to accumulate technical debt that has to be resolved later. One more developer isn't going to have much effect on these problems, which need significant resources working in concert to address. Better project management and setting of priorities is needed, to adequately plan how to transform the code base to a more sustainable state. Note there's a good possibility that would result in a decision to shed functionality currently in use that's too costly or insecure to keep in place, with a plan to re-implement some parts deemed necessary. isaacl (talk) 01:57, 24 March 2024 (UTC)

That's mitigated slightly by the lack of one negative force: MediaWiki has no need to make change for change's sake, just to make Product 2024 look sufficiently different from Product 2021 that users will feel obliged to upgrade. Certes (talk) 11:48, 24 March 2024 (UTC)

I'm a software engineer myself. More specifically I'm an SRE, so I'm typically responsible for the types of tasks you're talking about (server upgrades, etc). Let me give you my perspective:

For most software engineers, the work they do at their job is completely outside of their control. They do what makes their boss happy, and in turn, they do what makes their boss happy, and so on. Thankless work like regular maintenance is often dropped without the proper incentives. For some people, those incentives are the salary to work long hours, but since many American jobs in big tech pay 2x to 5x the salary WMF pays for the same role, That isn't it. Those incentives have to come from the top. An example of what that might look like is a "backlog drive" that employees are required to participate in. But that's pretty rare, because leadership is typically being evaluated on metrics like increasing revenue or visitors to the site, and technical debt doesn't push those metrics. So, asking WMF to hire more people doesn't address the problem. Those new employees, if hired, would just fall into the established system that caused the technical debt to exist in the first place. So the conversation you need to be having is: "How do we convince WMF to invest in technical debt?" I don't know the answer to that question. But focusing on hiring more people doesn't solve anything. Mokadoshi (talk) 03:31, 25 March 2024 (UTC)

That's why the proposal is to hire a dev specifically to work on maintenance. Tercer (talk) 06:51, 25 March 2024 (UTC)

The problem is bigger than just one person working on small bug fixes. The framework needs to be cleaned up to be more sustainable. The third-party software dependencies need to be reconciled across different extensions. This needs co-ordination across multiple development areas, and a lot of automated testing. It needs support from management to push through, rather than to just spend enough to keep the parts working. isaacl (talk) 20:49, 25 March 2024 (UTC)

Been there, done that. Assigning all mainteinance work to a single engineer (or a small group of them) is a really bad idea in practice. It just obfuscates the need to have better mainteinance practices across the whole engineering organization. It isolates "mainteinance folk" from the new developments that they'll eventually move to mainteinance. It leads burns out, and then to a new "mainteinance guy" coming who starts from scratch and cannot tap into institutional knowledge about mainteinance. It is just unsustainable practice. MarioGom (talk) 10:19, 6 April 2024 (UTC)

Yes, investing in technical debt is exactly what's needed, but one reason (or excuse) for not doing that is lack of people. If I gag the cynic in me shouting that any new staff would just be diverted to exciting but unnecessary new chrome, an increase in resource should make it easier to get through the required drudgery. Certes (talk) 09:14, 25 March 2024 (UTC)

The key point is why hasn't the WMF already hired that one more developer, or ten, or fifty? Because it places a higher priority on spending those funds and management resources in other areas. For the development environment to truly improve, the WMF needs to change how it sets its priorities. Echoing what Mokadoshi said, that's the problem that needs to be worked on. isaacl (talk) 20:58, 25 March 2024 (UTC)

Do you have a source that the Wikipedia web servers run on Debian Buster? I thought they ran on Kubernetes? Mokadoshi (talk) 19:03, 25 March 2024 (UTC)

A message just came around on the cloud-announce mailing list saying that all the VPS hosts running Buster need to be upgraded in the next few months. I don't have any insight into what they're running on the production web servers, but I assume if they're migrating the VPS fleet, they're doing the same for production. RoySmith (talk) 19:14, 25 March 2024 (UTC)

Thanks for that link, I'm not in that mailing list so I didn't know. I don't know how WMF runs prod so it very well may be that they are running Buster. But it's important to note that the announcement is for Cloud-VPS which is VPS hosting for the community. It would be common practice to not upgrade Cloud-VPS until the last possible minute so as to minimize disruption for the community. AWS for example does not forcibly upgrade your OS until the last possible day. Mokadoshi (talk) 19:51, 25 March 2024 (UTC)

I wouldn't spend too much time and effort focusing on the Debian Buster thing. That doesn't affect end users in any way that I can see, and it is not end of life'd yet. Let's trust WMF software engineers and SREs to handle those details, and focus on things that directly affect end users. –Novem Linguae (talk) 21:05, 25 March 2024 (UTC)

Where it adds to the technical debt that has to be managed is the work to figure out the third-party software stack required by the extensions used for a given Wikimedia site. I agree that it's not a level of detail that editors should be worried about figuring out, but getting the code base improved so that it's easier to work out is important for long-term sustainability of the software. isaacl (talk) 21:24, 25 March 2024 (UTC)

It's in the discussion of the SVG bug I linked, where they say they will only install the bugfix when it comes with Bullseye, and link to the task for upgrading from Buster to Bullseye. Tercer (talk) 23:33, 25 March 2024 (UTC)

I really don't want to speak for the WMF, but I kind of understand their logic here. One way to manage a fleet of machines is to stick with LTS releases and survive on whatever gets packaged into that. It's certainly possible to built custom installs, but once you start doing that, you're off the LTS train and have to take on a lot more responsibility and overhead. I've lived in both worlds. If you haven't, it's difficult to fully understand just how attractive sticking to the LTS can be. RoySmith (talk) 00:10, 26 March 2024 (UTC)

I suspect WMF SRE would be fine with a newer version of the package, provided that there was a compelling reason (more than just small bug fixes) and a different person/team took full responsibility for what that entailed. Like if WMF multimedia team (staffed in this hypothetical future differently) basically said that this is a critical issue, we need the new version, and we are willing to take responsibility for all that entailed, it would probably happen. But that is not the situation happening here. Bawolff (talk) 15:28, 30 March 2024 (UTC)

This certainly does illustrate the odd relationship that the community has with WMF. In a commercial software shop, there would be meetings between engineering and product managements. The product folks would say, "If this bug isn't fixed, it's going to cost us $X next quarter in lost revenue as customers jump ship". The engineering folks would say, "The only way we can fix this is if we go off the LTS train and that's going to cost us $Y in additional engineering costs, plus some indeterminate $Z in technical risk exposure". The two sides would argue and come to some decision, but at least both points of view would be heard and weighed.

But that relationship doesn't exist here. The customer base is the volunteer community. It's difficult to put a price tag on their labor, and even if you could, they don't have a seat at the table when it comes to making these decisions. Yeah, there's meta:Community Tech and meta:Community Wishlist Survey, but that's not quite the same thing as having the VP of sales in your face about fixing whatever bug is pissing off his biggest customer and threatening his bonus this quarter :-) RoySmith (talk) 17:48, 30 March 2024 (UTC)

I think there is also a problem here in that the community lacks sufficient knowledge into how WMF does things to make effective criticism, and without effective criticism its impossible to hold WMF to account. Take this thread. The proposal is for WMF to hire a single developer to work on maintenance of MediaWiki despite the fact that there is already a lot more than one developer currently working on MediaWiki maintenance and none of the issues mentioned actually are MW maintenance issues. As a proposal it is pretty non-sensical - it is hard to even tell if these are issues the community cares a lot about or just an issue that a few people care about. The community might lack a seat at the table, which is a problem, but the community is also pretty bad at expressing what is important to it in a way you can actually do something with. Bawolff (talk) 18:17, 30 March 2024 (UTC)

You're missing the forest for the trees. I could have phrased the proposal instead as "invest more resources in maintenance" without changing anything else, and your criticism wouldn't apply. Moreover, you're missing the point about "jumping off the LTS train". There is no need to update this package in isolation. If MW had been updated to Bookworm last year, or even Bullseye three years ago, they would have gotten for free the SVG bugfix. No matter which way you look at it, maintenance is lacking. Tercer (talk) 19:16, 30 March 2024 (UTC)

Sure, but would it have been worth it? I also have a long list of things i would like to see fixed. The issue is everyone has a different list. I don't think there is any reason to think that hiring 10 more, or even 100 more devs would neccesarily fix the specific issues you are concerned about. Not all problems can be fixed by just hiring more people. (P.s. my criticism of, well technically this isn't a mediawiki issue, isn't neccesarily directed at you - there is no reason you should know where the boundries between different components lie. I think it is more emblematic of the meta problem where the community lacks the ability to really tell what WMF is doing and hence lacks the ability to really judge it which undermines the community's ability to be taken seriously when lobbying for changes) Bawolff (talk) 21:21, 30 March 2024 (UTC)

Actually, we do have good visibility into what they're doing. The big picture of how they handle OS upgrades is on on Wikitech. And if you're willing to invest some effort looking around on phab, you can find all the details. For example, T355020 talks about upgrading the hosts that Thumbor runs on. RoySmith (talk) 22:06, 30 March 2024 (UTC)

That's funny, it turns out SRE is violating their own policy by hanging on to Buster for so long. Well, I'm glad they agree with me. Tercer (talk) 22:16, 30 March 2024 (UTC)

Yes, it would. Updating Debian is a no-brainer. Very likely it would take care of a large fraction of your list automatically. And it's something you have to do anyway, so there's no benefit from running archaeological versions. Keep in mind that we're talking about Debian stable here, so even the newest version is already old and battle-tested. Tercer (talk) 22:09, 30 March 2024 (UTC)

I disagree. Bawolff (talk) 21:19, 1 April 2024 (UTC)

• From what I am aware of, there is a decent number of employed devs as well as volunteers, so if anything, this is a coordination problem (economical and social) more than anything else. I do have to agree on the point that despite the number of people, some important things don't seem to get done - some of it is primarily because dealing with legacy code is hard, and because hiring quality is hard (this is not to imply at all that current devs are bad) but more exactly that hiring the best devs to work on legacy code is particularly challenging (atleast without paying through the nose). The best way to resolve this is to use the donation war chest and work harder on technical evangelism + hiring on quality over quantity. --qedk (t 愛 c) 22:54, 25 March 2024 (UTC)

  Perhaps WMF can fund the volunteer developers to do basic maintenance, just like the Rapid Fund and the Wikimedia Technology Fund (which is unfortunately permanently on hold)? Thanks. SCP-2000 14:53, 27 March 2024 (UTC)

• Hi all - I'm Mark Bergsma, VP of Site Reliability Engineering & Security at WMF. Thanks for this discussion and the points already raised. I'd like to help clarify a few things: at WMF we do indeed have a few hundred developers/engineers - spread over many teams in the Product & Technology department, which is roughly half of the organization. "Maintenance" is not exclusively done by a few dedicated staff, but is the shared responsibility of most of those teams and staff, for the components they're responsible for. They actually spend a large amount of their time on that, and for some teams it's the vast majority of their work. We do consider that a priority and explicitly make time & space for it (we call it "essential work"), and we aim to carefully balance it with strategic work (like bringing new functionality to users/contributors), as well as needed investments into our platform and infrastructure (e.g. our multi-year project to migrate all our services to modern Kubernetes platforms for easier development/testing/maintenance/developer workflows). Since last year, we've also made MediaWiki and related platform work an explicit priority (WE3), including the establishment of some much needed MediaWiki-focused teams again, and have an explicit annual goal to increase the number of staff and volunteer developers working on MediaWiki, WE3.2), and the new formation of our MediaWiki platform strategy. This will continue going forward (WE5 and WE6 of our draft next-year plan).
  Nonetheless, it's true that we have a big challenge sustaining the large and ever growing footprint of services, features and code we've developed and deployed over the now long history of our projects, at the large scale we're operating at. Compared to that footprint, and considering the very wide range of technologies involved, old and new, different code bases and needed knowledge and skill sets, a few hundred staff to sustain and develop that is not all that much. It involves difficult choices and tradeoffs everywhere - prioritizing between many tasks and projects, all of which seem important. It's something we care about, have done quite a bit of process improvement work on over the past 1.5 year, and have a lot more left to do on. We're planning several related initiatives (e.g. WE5.1, all KRs of PES*) as part of our next annual plan to further improve this. We're also going to communicate more about this sort of work, which has been less publicly visible before.
  But, for something more concrete right now: I've also looked into the situation of the specific issue with SVGs that you raised. That's indeed a problem with an old librsvg library version that is used by Thumbor, our thumbnailing service, which was extensively worked on last year to migrate it to our Kubernetes platform - also for easier/quicker maintenance like discussed here. Further work (including the Thumbor container OS image upgrade and some required Thumbor development for that) then unfortunately got delayed, as the development team then responsible for it needed to be disbanded and reorganized at the time - also to allow us to form the aforementioned MediaWiki focused teams. But, I'm now happy to report that the plan is for the work on the Thumbor upgrade to Debian Bullseye to start soon, in the next few weeks, which when finished should finally address this frustrating issue as well. (And yes, we do normally upgrade before OS releases go out-of-support :)

HTH! -- Mark Bergsma (WMF) (talk) 12:14, 27 March 2024 (UTC)

Thanks for taking the time for such a detailed answer (it seems that Andrew Davidson had a much better grasp of the situation, and I stand corrected). I'm glad to hear that you are aware of the issues, care about them, and there are plans for improvement. In particular, I'm glad that there is a MediaWiki team again and that WE5.1 is an explicit goal. If the state of MediaWiki in fact improves (at least in the issues I'm aware of) I'll resume donating.

It's clear that the answer to my specific proposal is (a quite diplomatic) "no", but I don't mind. I care about the results, and I'm not going to pretend to know better than you how to achieve them. Tercer (talk) 18:44, 27 March 2024 (UTC)

Regarding the broken Graph extension, I have written an overview in the new Signpost that hopefully sheds some light on the situation for those who haven't followed it closely over the past year: Wikipedia:Wikipedia Signpost/2024-03-29/Technology report.

Speaking personally and generally (i.e. not necessarily about the Graph situation in particular), I think people should keep their minds open to the possibility that several things can be true at once: 1) WMF does a lot more maintenance (and other technical) work than some community members give it credit for, 2) many technical issues are trickier to solve that it might appear without detailed knowledge about the situation, but also 3) WMF often has serious problems with assigning resources proportional to impact and 4) there can also sometimes be situations where engineers overcomplicate a problem and let the perfect become the enemy of the good, or lack the expertise to find the most efficient solution. Regards, HaeB (talk) 02:49, 30 March 2024 (UTC)

Thank you @HaeB for your even-handed review of the Graph extension situation, and articulating some real challenges that we all face, contributors and WMF staff. Something that I remind myself daily is that most people are trying very hard to get decisions they think will have a lasting impact right, and it's true that sometimes that can lead to letting 'perfect become the enemy of good.'

I wanted to share a little of my perspective on the maintenance challenge: I've joked that this is my third 20+ year old codebase. Over those years, security, uptime and performance expectations have changed dramatically along with the Internet. We all expect software to be more safe, available and faster than ever before. Wikipedias have the privilege of serving a large user base of readers and editors, who are diverse in their geography, expectations and needs (to name just a few ways!). And often, those who work on the software are trying to keep as much functionality as possible as we modify things, so that as little as possible breaks even as the world changes around us. An imperfect analogy to what's happened might be retrofitting a series of buildings and changing their core purpose from some industry to housing. It's possible to change the purpose of a building without changing any of the internal structure, but over time, that becomes increasingly hard to live with. And now you have tenants, so you can't just send everyone away for a year to upgrade it all!

We have multiple significant maintenance projects underway. One place to hear about a part of this work is in the monthly MediaWiki Insights reports, which describe MediaWiki project progress and plans. Each language wiki and sister project wiki is a separate deployment that also supports a distinct set of extensions, some of which were created and deployed many years ago, under pretty different circumstances than we face today. Following the insights reports may help those interested learn more about what it takes to untangle years of uncoordinated decision making for our most critical software, and what it will require for us to establish a platform that is supportable on a free and open internet by dedicated staff and volunteers, and still enable an open and distributed model for all contributions.

Having volunteers who understand our challenges and then help us think through how to get things right together is super helpful. Thanks again and please keep sharing your thoughts. SDeckelmann-WMF (talk) 19:42, 1 April 2024 (UTC)

Preannouncement of upcoming Movement Charter conversations

I am Kaarel, support staff of the Movement Charter Drafting Committee, working with the Wikimedia Foundation.

I am writing here to let you know in advance that the full draft of the Movement Charter will be published on April 2nd, 2024. This will kick off the community engagement period from April 2nd to April 22nd. Perspectives from the English Wikipedia community would be very valuable for the conversations.

For context, the Movement Charter is a proposed document to define roles and responsibilities for all the members and entities of the Wikimedia Movement, including to lay out a new Global Council for movement governance.

Everyone in the Wikimedia Movement is invited to share feedback on the full version of the Charter draft – this is the last chance to propose improvements before the Charter draft is updated for the ratification vote in June 2024.

Since the last feedback round the drafts have gone through notable changes. I hope many of you will still find it worthwhile to review the drafts and share your perspectives to inform the final version of the text that will be ratified.

How to share your feedback?

• Read the Wikimedia Movement Charter text on Meta (texts will be updated April 2nd!)
• share your message or question on the Movement Charter Talk page;
• attend the community drop-in session on April 4 at 15.00-17.00 UTC (details forthcoming);
• or email movementcharter@wikimedia.org;
• once the texts will be published, we will follow up also here on Village Pump and open a respective feedback thread.

Read the Committee's latest updates for more information. I am truly grateful for your kind attention!

On behalf of the Movement Charter Drafting Committee, --KVaidla (WMF) (talk) 07:38, 26 March 2024 (UTC)

Please remember, when attempting to tie-in and enforce any specific rulings or wording of the document, that this project is Wikipedia (specifically English Wikipedia) and not Wikimedia or an entity called "Wikimedia movement", and its editors are called Wikipedians and not Wikimedians (although some Wikipedians may also want to self-identify as Wikimedians). Thanks. Randy Kryn (talk) 12:27, 27 March 2024 (UTC)

Thank you for this feedback! I would like to understand better the point you are making. The Wikimedia Movement Charter is a high level document defining the future roles and responsibilities of those comprising it. As defined here, on English Wikipedia, "The Wikimedia movement is the global community of contributors to the Wikimedia projects, including Wikipedia." The article further elaborates that "the Wikimedia community includes a number of communities devoted to single wikis", followed by a list, including Wikipedia communities.

In my perspective, this means that following the definitions also in respective article on English Wikipedia, as curated by English Wikipedia community, Wikipedians are part of particular Wikipedia community, who in turn are part of the global Wikimedia community. It does not seem reasonable in a Charter-like high level document to mention all the projects separately, so the term Wikimedia is used. At the same time, I do hear your point about the choice of the term might feel "alienating" (my interpretation, please correct or specify, if not correct) for the contributors of particular projects. What is your positive proposal for terminology considering this?

Thank you for your very kind attention given to the matter! --KVaidla (WMF) (talk) 15:46, 28 March 2024 (UTC)

Hello KVaidla (WMF). The point is quite simple. Wikipedians are people who have edited Wikipedia, the flagship project that WMF was organized to fund and protect. Wikipedians can individually choose to identify as Wikipedians, Wikimedians, or both (irregardless of the language you quote above, remember that Wikipedia cannot be used as a source) and are different groups of people when they identify or identifying them. WMF's funding is primarily based on donations that people think they are donating to Wikipedia when, in fact, Wikipedians have very little to do with deciding where and how much such funding is allotted. Wikipedians, a dictionary term, even used to have an annual award named for them. Wikimedian of the Yearl was named 'Wikipedian of the Year' from 2011 to 2016, when an obvious opportunity not taken arose to create the second award while keeping the first intact.

Since Wikipedians are a stand-alone grouping, they may choose to belong or not belong to what you call the 'Wikimedia movement'. But any rulings or direction which dictates WMF (or "Wikimedia movement") policy onto them, without regard to the separation of the two, should not stand as doctrine or overriding policy but simply as suggestion. Funding of Wikipedia projects, conventions (our Wikimedia conventions, both worldwide and local such as the North American convention, should rival other major corporate and professional conventions in terms of facilities, banquets, sponsorship, etc., with a much greater extension of WMF funding, upwards of 500 scholarships to each, etc. as a major opportunity to celebrate the volunteers), and new ideas should be taken for granted in WMF's yearly budget, with WMF asking "Thank you, what more can we do?". In any case, the elephant in the room is that Wikipedia is the popularly known entity which "brings in" the donations for the movement and WMF operations, and instead of erasing the term 'Wikipedian' (as was done with the annual award) that separation, as well as the partnership and much fuller funding, should be further recognized and encouraged. Thanks for your reply above, and for your work supporting the projects. Randy Kryn (talk) 15:37, 30 March 2024 (UTC)

I am proud to be a Wikipedia editor. I don't really know or care about this "Wikimedia movement" which some marketing genius seems to have plucked out of thin air recently. I associate the term "movement" with promoting some cause or other, whereas I try hard to do the opposite by editing neutrally. If membership of this "Wikimedia movement" is optional, then I opt out. If it's a mandatory condition of remaining a Wikipedia editor, just let me know, and I'll move on and leave you to write your own encyclopedia. Certes (talk) 22:31, 1 April 2024 (UTC)

The “membership” like it pleases you to frame it is optional but certain policies are not. For camper, you may not personally attack other users or perform undisclosed paid editing. Ymblanter (talk) 11:40, 2 April 2024 (UTC)

I haven't done either of those and don't intend to, but I consider myself answerable to the community and not the WMF. I'll continue to behave in a way I feel is reasonable, the WMF (unfortunately) can decide which of us it allows to edit, and I trust the community to react appropriately to any poor or unexplained decisions as we have occasionally had to do in the past. Certes (talk) 11:59, 2 April 2024 (UTC)

Thank you, Randy Kryn, for taking the time to elaborate your point more. clearly. I believe I understand the perspective better and it has sparked further conversation, which can be helpful.

As to separation between Wikipedia communities and Wikimedia movement, I believe that project autonomy and agency of project contributors in policy-making continue to be important aspects of how we function. At the same time, there are already global policies, like the Terms of Use in place, that basically legally enable the functionality of all the projects. The Wikimedia Movement Charter drafting work is based on a hypothesis that there are matters that can be defined universally, so we do not need to revisit these matters project by project. Also it is about having the rights and responsibilities of different stakeholders set in writing for clarity. It would be interesting to hear your further thoughts and insights in relation to what has been suggested in the Movement Charter draft (which is now been published). Thank you again for your time and sharing of your perspective! --KVaidla (WMF) (talk) 12:58, 4 April 2024 (UTC)

Thanks KVaidla (WMF). I think my statement above presents my personal concerns, mainly about full funding of Wikipedia/Wikimedia volunteer projects and the worldwide and regional conferences (where 257 scholarships are given, for example, expanding that to 700, or 800, and assuring that the conferences rival the best corporate or non-profit conferences in keeping with Wikipedia's reputation and, importantly, to thank some of the volunteers who provide both the work product and the incentive for donors) could easily become a key priority of WMF funding. I've been saying that the world's billionaires will, at some point donate up to a billion dollars to Wikipedia and Wikimedia associated projects (Wikipedia's perceived yearly worth per the EMO - the Elon Musk Offer). For both then and now it would be nice to assure that the volunteers fully participate, including widescale funding-decision participation, in everything that dedicated knowledge-sharers can think up and accomplish. Randy Kryn (talk) 14:46, 5 April 2024 (UTC)

The movement

The phrase "Wikimedia movement" is not a recent invention, though it has received more attention in the past couple years. We individual Wikians of course are free to call ourselves proudly as we will but I think the failure a few years ago to rename the outlying and ancillary sites to "Wikipedia [something]" was unfortunate as it would have helped in public recognition. It would help in recruiting; almost all my students have been attracted to our teaching sessions in hopes of writing a new article when really, it would usually be easier for them to learn how to add a new picture. For my own editing, for a decade or more I have been putting about as much effort into Wikimedia Commons and Wikidata as into English Wikipedia. Those sites do a few things but mainly they supply pictures and data (geographical coordinates are one of my specialties) to the hundreds of Wikipedias including English. Even without a common name, I figure there ought to be a common policy structure and general set of guidelines for us all, so the WMF staff don't have to decide so many things for us. Naturally there will be an interest in adding matters that are mainly the concern of only the encyclopedias or of only few of the various other autonomous member sites, who each ought to handle such things by their already established methods. There will be disagreements on such questions, but I'm confident our usual methods of drawing a consensus will prevail. Jim.henderson (talk) 00:16, 4 April 2024 (UTC)

• In short: I'm curious whether you're saying you believe that a difference of one letter (in some cases) constitutes a real detriment to the development of Wikipedia's sister sites? "Wiki" is already very widely associated with Wikipedia by the public, does "Wikipedia Data" being a thing people hear about and are surprised it exists seem much more unlikely than with "Wikidata"?
• I really disagree that even in effect Commons's main function is to act as Wikipedia's image repository. Its use is ubiquitous.

I figure there ought to be a common policy structure and general set of guidelines for us all, so the WMF staff don't have to decide so many things for us.

• I don't really think this structure makes sense. WMF doesn't really make that many choices for us—or at least, I feel part of the process for just about every choice I would like input on. I'm not sure what exactly you would like centralized, the current model seems to work. Do you have specific areas of policy or administration in mind?

Remsense诉 00:39, 4 April 2024 (UTC)

I think it's important to remember that there isn't a "we", strictly speaking. Not all of us are here to be part of a movement or whatever, or even editing for the same reasons; some just want to fxi a tyop that bugged them, others to add information about their favourite volcano. Jo-Jo Eumerus (talk) 07:18, 4 April 2024 (UTC)

I have a great respect for sister projects. I refer to Wiktionary regularly, and I use Commons unconsciously most times I read a Wikipedia article with images, though I've contributed very little to either. I use Wikidata occasionally, and was briefly an enthusiastic contributor; I would use it much more if it had an intuitive user interface. None of this makes me part of a "Wikimedia movement", which I see largely as a political stance shared by some but not all editors. Certes (talk) 09:08, 4 April 2024 (UTC)

The fact that you think the other projects are nothing more than ancillary sites that should be rebranded as under the Wikipedia umbrella is a very, very bad sign. Cremastra (talk) 22:04, 5 April 2024 (UTC)

• I completely understand that Wikipedia editors have a very Wikipedia-centric view of the broader Wikimedia community. It would be nice if everyone had the interest to learn more about the other projects, and how they are used, but I understand that it's not a priority for most Wikipedians, regardless of which language Wikipedia they choose to edit. But I'll just throw in a few tidbits:
• For many mainstream media sources that use images, Wikimedia Commons is often a go-to resource. There isn't a day that I don't find a Wikimedia Commons credit on the series of mainstream media sources I look at.
• Wikidata is used widely as a data aggregator by many other not-for-profit resources.
• Some language editions of Wikisource are the largest repositories of open-source historic documents and literature in those languages
• Some language editions of Wiktionary are having a major impact in preserving dying languages

The 339 Wikipedias, with their collective 62+ million articles, are indeed the major drivers of the Wikimedia family of projects; the largest Wikipedias, especially the English one, have deservedly gained a reputation for accuracy and neutrality in providing the entire world with information. That doesn't mean that the "sister projects" don't make a valuable contribution to the sum of all human knowledge. I will never fault anyone for choosing to focus on one specific Wikimedia project, or even one small aspect of a specific project. We're all better for those contributions. Risker (talk) 08:39, 4 April 2024 (UTC)

• Fearful of being caught beating a dead horse, I'll speak once more and hope to be disciplined enough to hold my peace. Yes, one little letter can indeed make a difference. Besides the local Wikimedia Chapter I am a member of local clubs concentrating on bicycling and astronomy. I'm always nattering to them about how we make Wikipedia and sometimes they actually listen. A couple times, though they did not surrender to my efforts to get them to edit an article or two, they decided that a money contribution would be a good thing. "Eh? The form said 'Wikimedia Foundation'. Is that the same thing, or did someone else sneak in with some kind of Internet scam?" These people had me to make the explanation, unlike most outsiders.
• A common brand can't help us thousands of insiders to understand what we're doing; like other big busy communities we are too complex to be understood with just a few simple labels. However, that's not what brands are for. Brand names are to promote instant understanding among the mass of outsiders, in this case their understanding that this is a big complex of websites with a common theme. We have different detailed policies to handle our specialties, but we are all about Wikipedia's original aim of promoting universal knowledge by organizing it for accessibility.
• I have uploaded thousands of pictures to Wikimedia Commons, and I know of a dozen that are used in news publications, books, and other works. Probably hundreds more are so used; we don't require to be given notice. The usual credit, when given, is "From Wikipedia" or "From Wikimedia Commons" or "by Jim.henderson via Wikimedia Commons". I figure, out of the small minority of their readers who actually wonder where the pictures came from, "From Wikipedia" is the only one that isn't mysterious. Yes, knowledge professionals, most often, know what they are doing but they hope their product will be read by many more people than are composing it; same as we do. They don't expect their readers to learn what it takes to be a knowledge professional.
• Wikidata is indeed used by many knowledge professionals. I am most familiar with the work of librarians since I work with them often, and have a lunch appointment tomorrow with a relative who's in that line of work. They are familiar with the different workings of OCLC, Worldcat, LoC and various local or specialized catalogs, and many of them also use Wikidata to help find their way through and among the others. Haha, a couple years ago I looked at the Wikidata item about me, and it showed my LoC Authority Control Number. What, has my good work come to such high prominence? No, that was another Jim Henderson, so I corrected it. Wikidata is full of dirty data like that, some of it imported from massive outside databases a century old or more. Not a big problem since WD serves people in the database business who are aware. I have also worked with art museum archivists and have no idea whether their old catalogs have as many errors as the databases for community gardens in Brooklyn or defunct restaurants in The Bronx. Hmm, perhaps I have wandered but anyway yes, the question of what brand name Wikidata ought to use is a lot less important than for Wikiprojects that serve a wider direct audience.
• Oh-oh, it seems this paragraph on WD has revealed that I've already gone overboard. So, I'll drop my stick and carefully back away from the dead horse. Jim.henderson (talk) 01:13, 5 April 2024 (UTC)

The full Movement Charter draft awaits your review on Meta

Hello again! I am following up on the pre-announcement from the previous week to let you know that the full draft of the Movement Charter has been published on Meta for your review.

Why should you care?

The Movement Charter is important as it will be an essential document for the implementation of the Wikimedia 2030 strategy recommendations. Participating in the Charter discussions means that you ensure that your voice is heard and your interests are represented in shaping the future of the Wikimedia Movement. As the English Wikipedia community is the largest of the Wikimedia movement, it is essential to have the perspectives from your community presented in the global conversations. I hope many of you will find time to provide feedback, share your thoughts and perspectives!

Community Engagement – April 2nd to April 30th

The Movement Charter Drafting Committee (MCDC) cordially invites everyone in the Wikimedia movement to share feedback on the full draft of the Movement Charter.

Let your voice be heard by sharing your feedback in any language on the Movement Charter Talk page, attend the community session today, on April 4th at 15.00-17.00 UTC, or email movementcharter@wikimedia.org. I will also be monitoring conversations on this talk page, to bring back the summaries to the ongoing global conversations.

You can learn more about the Movement Charter, Global Council, and Hubs by watching the videos that the Movement Charter Drafting Committee has prepared. Read the Committee's latest updates for more information about the most recent activities from the Drafting Committee.

Thank you again for your time and kind attention! I look forward to your input and feedback. Have a wonderful month of April! --KVaidla (WMF) (talk) 13:07, 4 April 2024 (UTC)

Unified enwiki response to the charter

In votes like these a significant issue is that interested editors do not have the time or wherewithal to properly assess the issues or candidates presented and so abstain from the vote. I propose that we attempt to address this, by having more engaged editors consider the proposal carefully and, in consultation with the community though an RfC, issue a recommendation either to support or oppose the change. Specifically, I propose a three-stage process:

1. A pre-RfC discussion where we will write a neutral summary of the proposal.
2. An RfC where we will:
   1. !Vote to approve the summary and its dissemination
   2. !Vote whether we should encourage eligable enwiki editors to vote for or against the change
3. Assuming the summary is approved, a mass message to all eligable enwiki editors providing it. Further, assuming there is a consensus either for or against the change, a recommendation to the editors that they vote in line with that consensus.

Stage one should probably begin soon, in time for a RfC in May; first, however, I wanted a brief discussion of the general idea. BilledMammal (talk) 02:41, 7 April 2024 (UTC)

Thanks for your comment, BilledMammal. This isn't a bad idea, but it is worth noting that the draft charter will be revised in early May following this current feedback round. Although the MCDC (of which I am a a member) does not anticipate making really large changes, I think it would be reasonable to assume that the final version is going to have at least some differences from the current draft. Would it make sense to create a feedback page on this project as a place where interested enwiki editors could flesh out their opinions before the final revision is made? I'd hate to see people investing a lot of time reviewing a draft and proposing a project-wide opinion in an RFC-type format, based on a document that we know will change. There is something to be said for having a local page for comments and suggestions for improvement (and please yes, if someone thinks X is a bad idea, propose an alternative) as long as there's a link to it on the Meta page so that the MCDC will be well-informed of the discussion on this project. (For that matter, it may be a good idea for other projects, and I'm pretty sure some of them are thinking about this too.) Risker (talk) 03:17, 7 April 2024 (UTC)

That's a good point, but we also need to consider that it will take time for the RfC to run. I think we should start drafting the summary based on the current document, and then make any updates that are necessary to align it with the May changes and start the RfC a few days after it is released.

I would also agree that creating a local page where editors can make comments and suggestions for improvements would be useful, although I would suggest just using this page as it isn't as busy as the other village pumps and thus an extensive discussion of the proposed charter won't disrupt other discussions. BilledMammal (talk) 04:59, 7 April 2024 (UTC)

I think mass messaging every eligible voter WP:ACE style might be too many people. Perhaps a watchlist notice, or pinging rfc participants, would be a good compromise. –Novem Linguae (talk) 16:30, 7 April 2024 (UTC)

I don't think that the vote to ratify this charter is less important than the vote to elect the Arbitration Committee. BilledMammal (talk) 16:32, 7 April 2024 (UTC)

Thank you for this initiative, BilledMammal, to approach the Movement Charter conversations in a constructive way! For reference, the timeline for the steps can be found here on meta and you are right, the time is of essence. It has been already pointed out on the meta discussion page that the review of the Charter would benefit from additional contextual materials for informed decision-making. As a supporting staff member to the MCDC I will see what I can do, yet it might take some time. If there are priority areas for further context in the English Wikipedia community, please let me know, so I can focus my work around that and hopefully have respective content available earlier. Also let us know, if we can support the discussions around the Charter in other ways. Looking forward to hearing the perspectives and seeing good participation from en.wp community! --KVaidla (WMF) (talk) 12:47, 9 April 2024 (UTC)

Responding to Katherine Maher / Uri Berliner Story

What is WMF's position on the buzz on X/Twitter over Katherine Maher's ideological beliefs (e.g. with 2 million views) and NPR Veteran Uri Berliner's resignation  ? Are there any efforts to clarify the distinction of those views from WMF and editors at large?

@llywrch raised concern about the transition in January. I worry about unfair attention to implications of Ideological_bias_on_Wikipedia which may trickle over to Wikipedia's editors & patrons.

cc: @I JethroBT (WMF) Tonymetz 💬 18:46, 17 April 2024 (UTC)

In that clip, Maher's not talking about her personal philosophy. She's talking about a principle that's been part of Wikipedia since long before her tenure at the WMF: the distinction between verifiability and capital-T Truth. The idea is that an encyclopedia anyone can edit could not function if it were predicated on a bunch of anonymous users arguing about what The Absolute Truth is. To make this model work, we try to leave The Truth and the beliefs of individual users out of the equation and instead spend our time debating how to effectively summarize what reliable sources outside of Wikipedia say about a subject. Then we cite those sources. As a tertiary source, we can afford to outsource ~truth to journalists, book publishers, academics, and other experts/professionals.
What's going on now is that people are highlighting that clip and similar claims about Wikipedia and making it seem like she doesn't care about what's true in a journalistic sense. It is [ironic] misleading partisan dreck. — Rhododendrites ^talk \\ 19:34, 17 April 2024 (UTC)

That is helpful context thank you. Tonymetz 💬 20:30, 17 April 2024 (UTC)

An example I use is that, at one point, plate tectonics was considered a fringe theory by most of the best and most reliable sources in the field. Had Wikipedia existed at that time, it would have said as much. Now, of course, those who thought it was true actually did the hard work, collected the evidence, did the math, convinced their peers, and today plate tectonics is widely considered correct. So Wikipedia says as much. But Wikipedia isn't out to "scoop" anyone on anything (and indeed, if we ever do, we should not congratulate ourselves, but ask "What went wrong?"). Rather, once the best sources available on a given subject change their consensus, then, and only then, should Wikipedia change to reflect that. We could argue forever over what the truth actually is and never come to consensus on it, so the best we can do is to reflect what the best available sources say on a given subject. If it turns out that they're wrong and that later comes to light, well, articles can be edited after that happens. But only after. Seraphimblade ^{Talk to me} 23:10, 17 April 2024 (UTC)

thanks this helps provide some context on her words. I also want to make sure WMF helps manage the PR . Most patrons, editors and readers will need help understanding WMF & Wikipedia's position Tonymetz 💬 23:12, 17 April 2024 (UTC)

Hi, I am Lauren from the Communications Department at the Foundation. Thank you for letting us know about your concerns. We are following the situation, and our goal as always is to raise understanding of the Wikipedia model. LDickinson (WMF) (talk) 16:51, 19 April 2024 (UTC)

Thank you Lauren for your efforts here. What is the best way for editors to track the Communication Department's efforts as the situation develops? I've noticed the attacks have become more directed toward Wikipedia itself. Tonymetz 💬 17:03, 19 April 2024 (UTC)

We can update you here if there are any new developments. Thanks for being so attentive to this. LDickinson (WMF) (talk) 17:45, 19 April 2024 (UTC)

Are any comms planned? The story seems to be getting more coverage and as an editor I would like to see the comms team defend Wikipedia. Tonymetz 💬 20:49, 21 April 2024 (UTC)

Could we have the comms team hold a Q&A? Some of the claims, particularly around US federal government influence over content (akin to Twitter Files ) are particularly worrisome. It would be nice to see that this matter is being seriously addressed. Tonymetz 💬 20:29, 24 April 2024 (UTC)

@Seraphimblade You too, huh? [35]. Ignaz Semmelweis is a good alternative. Gråbergs Gråa Sång (talk) 18:34, 18 April 2024 (UTC)

When I was writing WP:When sources are wrong, to illustrate a case where we had no choice but to be wrong I used this version of Priming (psychology): We did a good job summarizing a well-respected social science theory. It later turned out that that theory is almost certainly junk, but we still got it right based on the information we had to work with. -- Tamzin^{[cetacean needed]} (they|xe) 18:38, 18 April 2024 (UTC)

it's more honest and straightforward to say "we got it wrong". "getting it right" doesn't mean following the rules — "getting it right" means "getting it right" Tonymetz 💬 18:53, 18 April 2024 (UTC)

In my opinion Wikipedia can't function if people are chasing truth rather than Verifiable content that has a Neutral Point of View based on Reliable Sources. That does mean that we're going to present information that is wrong at times. But does provide a reasonable set of parameters on which editors can more likely find consensus about what content says than if we go after truth. And far more often it means we don't present information that is wrong even if the editor adding it firmly believes its true. Best, Barkeep49 (talk) 19:01, 18 April 2024 (UTC)

In practice, "right" is always relative to something. One can argue that there is such a thing as objective correctness—that's a pretty profound philosophical question, and above my paygrade—but even if there is, only supernatural beings would be privy to such a distinction. For we mere mortal encyclopedists, the best we can do is be "right" relative to the knowledge we have access to. Even now, can we conclusively say we were wrong then and are right now? Science could be wrong twice, unlikely as that may be. From our frame of reference now, our current article is right. (Well, right-ish, it actually hasn't been updated very well.) From our frame of reference in 2012, the article we had then was right. We can't hold ourselves to any higher or lower standard than that. -- Tamzin^{[cetacean needed]} (they|xe) 19:31, 18 April 2024 (UTC)

I am old enough to remember that the views expressed by Maher in this clip were very well represented in the initial iterations of the Wikimedia Strategy 2030 process. I would even say they represent the core of what the Strategy process was meant to produce initially. But there was a big community pushback and all that language got dropped. MarioGom (talk) 13:20, 20 April 2024 (UTC)

Since my name was mentioned, I'll add my two cents. I find the issue that Berliner raises intriguing. While I haven't listened to NPR for something like 30-35 years, I've seen criticism of NPR for being too conservative; this makes me wonder just how accurate Berliner's criticism is. Yet I feel a certain solidarity with his situation at NPR: there are times I feel Wikipedia is increasingly pandering to certain groups at the cost of helping volunteers in general. I can only wonder if this tendency was caused Maher, since I don't remember this happening before her. (I want to emphasize that this is more of a feeling than an accusation.)

But I found more of interest was the PR release announcing Katherine Maher as the new head of NPR, especially about her "achievements" at the Foundation. I'm sure to anyone who wasn't a volunteer at Wikipedia during her tenure it sounds impressive; I can only wonder just how much of these claims she actually believes. (I must admit almost everyone inflates their resume to some degree.) One detail I will comment about, her claim that she "reversed decades-long declines in core contributors": my own opinion is that after Sue Gardner's less than empathetic attitude towards the average volunteer, almost anyone could have been appointed head of the Foundation, & the number of "core contributors" could have only increased. She benefitted by not being Sue Gardner. -- llywrch (talk) 07:19, 18 April 2024 (UTC)

I'm dumbfounded by Katherine Maher's statements directly undermining some of the core principles of Wikipedia: including verifiability and notability through published, secondary, independent, and reliable sources. And linking those to some identitary and racial arguments is appaulling. One other core value of Wikipedia is that editors' identities do not matter: what matters is the quality of their contributions, judged by themselves.

I am a contributor of both my time and my money to Wikipedia/WMF. I have tended not to follow closely the work by the WMF and its leadership. I am appalled by Katherine Maher's statement. How could she been allowed to become the WMF's ED?? That seems gross negligence by the Board of Directors. That all makes me want to stop my monthly donations. I think it would help address this issue if the WMF made a public statement that despite Maher's crazy statement, the WMF stays true to the original core values of Wikipedia and as a consequence does not get involved in identity politics. Thoughts? Al83tito (talk) 14:51, 18 April 2024 (UTC)

Wikipedia has always been a left-wing institution, just as academia has been for decades prior. The ideological bias was baked-in. Why else are supposed right wing sources deprecated here so often? Now the problem for many contributors is that they realize the one party they joined in hope actually eats its own young, and that in the future you guys might not be so safe from your erstwhile allies. If this story reflects on Wikipedia, it is only this realization that the WMF is as much of the pipeline for this ideology as the other parts of Maher's resume. Don't bother trying to distance us from her. Chris Troutman (talk) 15:23, 18 April 2024 (UTC)

I agree that her positions on censorship, truth, the first amendment, and “correcting past wrongs” are a bigger risk to Wikipedia than the degree of her left-leaning beliefs. They threaten Wikipedia’s reputation as a neutral publication. Both her ideology and left leaning views may scare off a good portion of our patrons and editors. It would be good to know exactly how little or how much influence her views have had on Wikipedia. Were there active censorship efforts? How much does WMF influence the senior administrative staff like bureaucrats, stewards, Aprbcom, admins etc. ?

In short, WMF has had a few months to prep for this fallout and there are hundreds (thousands) of volunteers who deserve PR support to protect their hard work on the encyclopedia. Tonymetz 💬 15:55, 18 April 2024 (UTC)

I think most of her personal positions are being overblown and conflated with Wikipedia, but I do disagree with her statement about notability. It's not Wikipedia's responsibility to right great wrongs. She points out that Wikipedia reflects the biases of the world, but that's Wikipedia working as intended. If there is more source content written about Western topics or cultures with written traditions, then Wikipedia is going to have more articles about Western topics or those cultures. Yes, that would mean unequal coverage, but what are we expected to do about it? We follow what sources say, not lead them. ARandomName123 (talk)^{Ping me!} 01:42, 19 April 2024 (UTC)

@Tonymetz: Thanks for your question, Tony. I'm not personally aware of any official statements from the Foundation on these developments at the moment, so I've brought this thread to the attention of the Movement Communications team. I JethroBT (WMF) (talk) 16:13, 18 April 2024 (UTC)

thank you for the quick attention to this post and for escalating it to the appropriate team. I appreciate your help here. Tonymetz 💬 16:33, 18 April 2024 (UTC)

Does Maher have a current role in the WMF? I am unsure why WMF would need to have a position on her statements related to her current role, a few years after she moved on from being WMF CEO. (They certainly should not have a position on X/Twitter buzz.) CMD (talk) 02:20, 19 April 2024 (UTC)

Katherine Maher says that, as CEO of Wikipedia, she "took a very active approach to disinformation," coordinated censorship "through conversations with government," and suppressed content related to the pandemic and the 2020 election.

[36]

More generally, the bulk of the content receiving attention was made during her tenure here (or refers to it).

This is among the top responsibilities of the comms team. Tonymetz 💬 02:33, 19 April 2024 (UTC)

Responding to X/twitter posts should certainly not be among the top responsibilities of the comms team, especially if they're such obviously rubbish tweets. The WMF does not editorially control the various language Wikipedias. CMD (talk) 05:17, 19 April 2024 (UTC)

@Tonymetz: Why do you care what Christopher Rufo has to say about her? Wikipedia says he is a conservative activist and he is certainly not a reliable source. If you want to criticize or analyze her words then why not look at her original words in their original form? and then quote from there not from Rufo. I believe that I've found a video and transcript of what Rufo was referring to. I tentatively plan to watch the video tomorrow, haven't read the transcript yet. Jeremyb (talk) 05:51, 19 April 2024 (UTC)

Why do you care

. I worry about unfair attention to implications of Ideological_bias_on_Wikipedia which may trickle over to Wikipedia's editors & patrons.

I tentatively plan to watch the video tomorrow, haven't read the transcript yet.

do let us know Tonymetz 💬 17:56, 19 April 2024 (UTC)

Precisely. Ymblanter (talk) 06:35, 19 April 2024 (UTC)

What's going on

Pardon the self-indulgent subsection and long post, but this is turning into a real story in right-wing media and it seems useful to pull all the claims together. So here's what's going on, as far as I've seen. (I do not work for or speak for the WMF, just to be clear, and as such don't object if someone wants to move this elsewhere).
It appears to begin with Christopher Rufo, who found in Katherine Maher a new target in a campaign to dig through people's past comments to frame as radical leftists, stoking partisan outrage and eroding trust in institutions he perceives as leaning left. And yet again right-wing media is eating it up while making no effort to verify that the framing is accurate. Ironically, it's terrible journalism about insinuations of bad journalism.
Here's what he found, and the basis for the current hubbub about Maher:

1. Some years-old tweets that make it clear she's a democrat. Yes, she appears to support Biden and doesn't like Trump. Certainly none of the heads of the news organizations picking up this story have expressed political beliefs before, right? IMO it would've been a good idea to wipe her Twitter before jumping into the WMF CEO role and certainly before the NPR role, but none of the tweets were really all that wild. Maybe cause for some light Twitter bashing like we see anytime leaders of companies are found to not be apolitical robots, more or less assuaged with a "I shouldn't have said that on my personal twitter account years ago" apology. The most "scandalous" was one about Trump being racist, which might be jarring if she tweeted it today in her NPR role, but it was six years ago. Also, whether you agree or not, it's hardly a fringe interpretation of his comments/actions. Regardless, these aren't what most people are focusing on.
2. One of the clips going viral is from a TED Talk (here's the full talk) where she's talking about Wikipedia. When you hear someone say something odd about Wikipedia and the truth, they're probably talking about the practical way in which Wikipedia works, not a personal philosophy. Wikipedia works according to verifiability, which is what makes it possible for a bunch of anonymous users to collaborate on a single version of an article. If we were all arguing about things we know to be True, it would be chaos. Imagine writing an article on the Israel-Palestine conflict, for example, based just on what individual people on the internet say is true. It wouldn't work. For some subjects, it's easy to agree on a single truth; in others, we have to figure out how to present multiple perspectives based on good sources and put aside what individual users say is true. That is the kind of truth Maher is talking about, arguing that the "productive friction" of sorting out how to summarize multiple perspectives could be beneficial outside of Wikipedia, too. Her words about Wikipedia, by definition a tertiary source, are being isolated and reframed to make it seem like she's talking about truth in the journalistic sense of NPR. That would be clear to anyone who watches the full talk or puts any effort at all into fact-checking the context. Journalistic outfits that care about truth usually do that sort of thing rather than write a story about a short clip someone posted on X without asking any questions.
3. The "first amendment" clip doesn't even need the jargony context of the Wikipedia-related one -- it just requires listening to the question she's answering. Here's a link that includes the question. She was asked about solutions for dealing with content like misinformation and asked where those solutions will come from: companies, the government, civil society, etc. So she talks about civil society and about companies. As far as government, she says that yeah, if you think the government is going to intervene and do something to address misinformation, the first amendment presents an obstacle. It's just a non-starter. That's.... it. She never says it should change, she never says it should be removed, never says it's bad. She's not even talking about her own opinion -- it's just addressing the government part of the question. She then talks about the importance of the first amendment in giving platforms the ability to moderate content according to their own business interests and values. It's simply misleading to present it as "Katherine Maher is against the first amendment".
4. Some quotes about race, gender, notability, and a "white male Westernized construct". There's a lot to be said about systemic bias on Wikipedia, gender gap on Wikipedia, racial bias on Wikipedia, etc., and a lot of debate over the extent to which systemic bias affects Wikipedia's content, whether it's something to be fixed, how it could/should be fixed, or if it's something simply to understand as a historical reality. The idea is, if demographic surveys show that Wikipedia is written overwhelmingly by men in North America and Europe, that probably affects the content in some way. Our articles on European naval battles, baseball, and Hollywood movies are better than our articles about women's health in Tanzania. So there are efforts to recruit other participants, with the hope that it will increase the overall quality/coverage of the encyclopedia. It's not especially controversial to acknowledge that the historical record of Europe and the US was almost entirely written by and about white men. Again, whether that's something we should look at and say "that happened, and we've come a long way since then" or "that happened, and we haven't done enough to address it" is open to debate, but Maher is basically alluding to these things and saying that the free/open approach of Wikipedia reproduces those biases rather than corrects them. If your perspective is that we should not try to fix these biases, I have good news for you! Those are our policies. We base articles on published sources and whatever biases exist in the body of literature on a subject will typically be reproduced in Wikipedia because we are a tertiary source. During Maher's time at WMF, our rules for notability (how we determine which subjects get articles) got stricter, not more inclusive. That's not specific to Maher -- they've been getting steadily more restrictive for years. The point is, regardless of where you stand on issues of bias, the Wikimedia Foundation and its CEO have no power at all to change anything at all about how Wikipedia writes articles or which articles it covers. The most they can do is decide where to allocate recruitment funds and determine what makes for the best language in fundraising/communications.

TL;DR - Culture warriors on X are isolating clips of Katherine Maher and using a blatantly misleading framing to stoke outrage about NPR and Wikipedia. Maher's statements aren't actually controversial, didn't have anything to do with how articles are written on Wikipedia, and have nothing to do with NPR at all, but yeah she wore a Biden hat and had a nice dream about Kamala Harris (Twitter's a weird place sometimes). Even if they were accurate portrayals of her philosophy, the Wikimedia Foundation does not influence the content of the articles you read on Wikipedia in any way. Any news publication that's actually interested in things like "truth" could've figured out these tweets were misleading with minimal effort. — Rhododendrites ^talk \\ 19:43, 19 April 2024 (UTC)

100% endorse with one quibble. My reading of her answer to the question in the First Amendment clip is that she actually does endorse the First Amendment, even in the context of content moderation on the internet, because it gives platforms the ability to moderate content according to their own interests and values. Small difference, but an important one. Loki (talk) 03:10, 20 April 2024 (UTC)

I don't see that I said something different, but for the avoidance of doubt: yes. — Rhododendrites ^talk \\ 12:34, 20 April 2024 (UTC)

100%. A lot of this is just basic willingness to look beyond what people scream out loud. If people haven’t learned by now that those who yell loudest are generally in it for their own good, rather than the rest of us… well I call that a failure of the educational system. —TheDJ (talk • contribs) 10:36, 20 April 2024 (UTC)

Funny thing is that my criticism of Maher has been independent of whatever this Rufo troll has been writing. (I'd like a reliable source to confirm that he has been the primary instigator.) And I'm annoyed that my criticism about her abilities as a manager is being usurped by one side in the ongoing US culture wars. From what I've read, her political views are very close to mine. Further, the effort to combat systemic bias on Wikipedia started years before Maher's tenure, probably years before she even heard of Wikipedia -- that page was first created 4 October 2004 -- so I'm offended she is taking credit as a major driver in that effort, when I never witnessed her making any significant contributions to solve that serious problem. Flying around the world to hold meetings to discuss how this is a problem & that more meetings are needed doesn't count. Especially when this hasn't generated any of the many needed articles.

My criticism is based on what I've seen while a contributor during her tenure -- especially her clumsy handling of the FRAM incident. In that incident, she was so out of touch with what was happening & obsessed with her own priorities that it required someone to flame her on her preferred social networking platform for her to finally acknowledge that a problem existed needing her attention. (People posting on her talk page over at Meta, asking her to intervene, failed to attract her attention; from other statements she made it would appear that she didn't value the wikiwiki platform that highly.)

As I wrote above, almost everyone inflates their resume to some degree. I found Maher's claims about her accomplishments as CEO of the Foundation was notably inflated. And I am annoyed about that, if not offended. Where was she when I -- or anyone -- needed help with finding materials to write articles to fill gaps in Wikipedia coverage? I have stated elsewhere that I hope she learned from her tenure at the Foundation, & won't repeat the same mistakes at NPR as she did there, but I'm reserving my final judgment on that matter. -- llywrch (talk) 17:38, 20 April 2024 (UTC)

Your comments have been helpful for me to better understand her leadership accomplishments and setbacks. Tonymetz 💬 20:38, 20 April 2024 (UTC)

Given that you think the attack is unfounded -- would you see the need for comms to correct the story and defend against the attack? Tonymetz 💬 18:21, 22 April 2024 (UTC)

Miscellaneous

Will the Met Office logo ever have its copyright expire?

• File:Met Office.svg

The Met Office logo is currently protected by Crown copyright in the United Kingdom, but may not be copyrightable in the United States because it does not meet original standards. The version currently uploaded locally on English Wikipedia is the 2009 version. There may be differences in color matching between this version and the 1987 version. Therefore, the copyright protection period of logos uploaded in different periods will also be recalculated. -Fumikas Sagisavas (talk) 04:09, 14 April 2024 (UTC)

If you don't get an answer here, you might want to try asking at commons:Commons:Village pump/Copyright. —⁠andrybak (talk) 12:53, 21 April 2024 (UTC)

@Fumikas Sagisavas, On English Wikipedia, there is also Wikipedia:Media copyright questions. —⁠andrybak (talk) 14:44, 27 April 2024 (UTC)

Should this be reported to the Administrator's Noticeboard?

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

---

Dalton Tan (talk · contribs) has described misinformation several times in railway-related articles, and it has escalated even if it is warned. Even if I have been warned many times, I don't seem to understand it, so should I report it to the Administrators' noticeboard? --H.K.pauw (talk) 09:55, 17 April 2024 (UTC)

User behavior issues should be posted to WP:ANI. I'd suggest copying this over. It may help to provide WP:DIFFs of misbehavior in your comment. –Novem Linguae (talk) 10:14, 17 April 2024 (UTC)

You would need to give a couple of examples of edits that you believe are a problem and explain why they are a problem in a way that people without inside knowledge can understand. Be brief. Johnuniq (talk) 10:18, 17 April 2024 (UTC)

 information

According to Talk page, it is the next page that is making the misrepresentation.

• Toyoko Line (23:25, 21 February 2024)
• Tokaido Main Line (01:20, 24 March 2024?)
• San'yo Shinkansen (23:17, 18 March 2024)
• Odoriko (10:33, 23 March 2024 ∼ 10:37, 23 March 2024)
• Hankyu Kobe Main Line (13:32, 7 April 2024)

Dalton Tan has listed misinformation in these articles and has been warned four times, but it continues to escalate. --H.K.pauw (talk) 00:00, 20 April 2024 (UTC)

Please do. Their persistence and lack of communication are clearly disruptive – I think a block might be in order. Be sure to provide diffs! XtraJovial (talk • contribs) 20:16, 21 April 2024 (UTC)

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

What redirects here tool?

Is there a function that I can add to the Tools menu that will generate a list of redirects to the current page? I.e. similar to "What links here" but for redirects. I'd like to be able to check for valid anchor points. Thanks. Praemonitus (talk) 15:53, 17 April 2024 (UTC)

@Praemonitus, if you add User:GhostInTheMachine/SortWhatLinksHere to your .js, it will sort redirects first in the "what links here" results. (I find it works if I click "what links here" and then click "500") Schazjmd (talk) 16:03, 17 April 2024 (UTC)

If that user script isn't exactly what you are looking for, there's also WP:US/L and WP:US/R. –Novem Linguae (talk) 17:45, 17 April 2024 (UTC)

Thank you for the suggestions. Praemonitus (talk) 21:36, 18 April 2024 (UTC)

@Praemonitus, why not use Special:WhatLinksHere and then un-tick the boxes for transclusion and regular links? That will leave you with a list of redirects. WhatamIdoing (talk) 02:13, 20 April 2024 (UTC)

Thank you. Praemonitus (talk) 14:44, 23 April 2024 (UTC)

Requesting a Level 2 template

How do I request that a Level 2 caution template be added to the Twinkle notices? This is a long-standing complaint of mine about this particular message, which is copy-pasting a draft by someone else into article space. When I request the history merge to provide attribution, it tells me that I can copy a template onto the talk page of the editor who did the copy. However, the message that it puts on the user talk page of the user who did the copying is mealy-mouthed. I think that something a little stronger is in order. This is an action which, whether intentional or not, creates work for an administrator in order to provide attribution to the editor who really wrote and submitted the draft. It doesn't really say that copy-pasting is discouraged. So how do I request that a message having to do with inappropriate copying within Wikipedia be added to the Warn templates? Robert McClenon (talk) 22:29, 18 April 2024 (UTC)

@Robert McClenon: I don't see why an admin is needed to correct anything. According to WP:CWW, the template {{Copied}} can be added to the article's talk page and anyone can do that. For the other part of your question, you can post your suggestion to Wikipedia_talk:Twinkle RudolfRed (talk) 01:34, 19 April 2024 (UTC)

User:RudolfRed - That's interesting. Are you saying that history merge is not needed in those situations? AFC and NPP reviewers are instructed to request history merge in such situations. Robert McClenon (talk) 02:58, 19 April 2024 (UTC)

@Robert McClenon: I am not familiar with AFC/NPP so I don't know why it would be different, but WP:CWW says that either a link or list of authors is sufficient attribution, per the CC license and Wikipedia terms of use. RudolfRed (talk) 03:09, 19 April 2024 (UTC)

Then what is history merge for? Robert McClenon (talk) 06:11, 19 April 2024 (UTC)

Purely regarding copyright considerations, providing a list of authors is sufficient, and avoids the problem of using a link where the source page for the copied content must continue to exist to preserve attribution. In particular, when there is just one author of the source content, that is an easier approach (as alluded to in Wikipedia:History merging § When not to request a histmerge). A history merge preserves the history of individual edits even if the source page is deleted. This goes beyond what is needed to satisfy Wikipedia's licensing requirements, but can be helpful for editors, keeps all the attribution on the article history page, and doesn't require manually extracting a list of authors for the purpose of attribution. isaacl (talk) 17:02, 19 April 2024 (UTC)

The replies above are technically correct but they miss the point. Copy/pasting someone else's draft to an article is pathetic. Volunteers who create content should be acknowledged in the article history and posting a template on talk as an alternative is just bullshit. Johnuniq (talk) 00:44, 20 April 2024 (UTC)

User:Johnuniq wrote:

Copy/pasting someone else's draft to an article is pathetic. Volunteers who create content should be acknowledged in the article history and posting a template on talk as an alternative is just bullshit.

Exactly, although I think that "pathetic" is not a strong enough rebuke for plagiarizing someone else's draft. That is why I wanted a stronger warning, because I think that usually the editor who copies someone else's draft to an article knows what they are doing, or at least ought to know. Robert McClenon (talk) 01:18, 24 April 2024 (UTC)

In my experience, people who use copy/paste instead of WP:MOVE really don't know what they're doing. WhatamIdoing (talk) 07:53, 26 April 2024 (UTC)

I think the fundamental question here, though, is whether a strongly worded message is more effective than a gentler one. I doubt that it is.

By the way, about ten years ago, an editor changed the {{Uw-c&pmove}} template to say that page history is legally required. If we've been posting this message for a decade, then it's hardly surprising that some editors believe that it's actually required. @Isaacl, what you say aligns with my understanding. Perhaps you'd like to clarify the text of that message? WhatamIdoing (talk) 02:23, 20 April 2024 (UTC)

I don't have a suggestion at this moment, as it's hard to get nuance across in a concise warning message. Page history is the built-in MediaWiki mechanism for maintaining attribution for a given article. There isn't a built-in mechanism for providing attribution for content copied from one page to another, but of course a cut-and-paste move is unnecessary with the page move function now available. So within the context of that specific warning template, the best course is to use MediaWiki's built-in functions to maintain attribution with the page history. isaacl (talk) 04:32, 20 April 2024 (UTC)

I agree that it's the best, but I don't believe that it's actually legally required. (It is required for non-legal purposes, such as Wikipedia:Who Wrote That? and edit counts.) WhatamIdoing (talk) 05:23, 20 April 2024 (UTC)

Sure, I've already agreed. isaacl (talk) 05:52, 20 April 2024 (UTC)

My point was to explain the benefits of history merges, even if there are other ways of satisfying attribution requirements. isaacl (talk) 03:58, 20 April 2024 (UTC)

Concerns about Internet Archive

As I have talked about both in Wikimedia Forum and in the Internet Archive's one, Archive's Wayback Machine, being a very important resource for Wikipedia (it's where many article references come from, and where all references will always be forwarded if the original source some day disappears), can't be taken for granted, because almost all its content is hosted only in an area with great natural risks. It strikes me (negatively) that no one has replied to my post on Archive's forums. Perhaps people are more concerned with day-to-day issues, and dismiss this as long-term paranoia, but I think this is currently the most important issue regarding human knowledge's future. If Archive is eventually lost, Wikipedia and its sister projects, will be even more important than they are now, as the memory of the start of 21st century (and of other previous times), but it would be really sad to lose so much content as Archive has. If there's anyone here that shares my concern, he/she could, if has an Archive account (or wants to create one), and wanted to do it, talk about it in the thread that I opened at Archive's forum. I think that this is a very important issue, for everyone, as persons, but especially as wikipedians/wikimedians. MGeog2022 (talk) 11:36, 22 April 2024 (UTC)

I don't think this is as big of a problem as you think it is. According to the presentation by Jonah Edwards all of their data is in in the Bay Area in at least 4 different data centers (San Francisco, Oakland, Richmond, etc) and data is replicated across multiple data centers. In your post you mentioned the 3-2-1 backup rule, but that rule of thumb doesn't require the data to be replicated to different states or countries. Aside from an event like that from The Day After Tomorrow it is extremely unlikely that anything could cause the data to be lost in all these locations simultaneously. The only real risk is that a power outage can (and has) taken the archive offline. On that risk, I am perhaps less concerned than others as I don't believe an archive needs to have strict availability requirements - libraries and other physical archives close for the night without any problems. Mokadoshi (talk) 17:07, 23 April 2024 (UTC)

@Mokadoshi, thanks for your reply. Power outages aren't a big problem, I wasn't thinking about that (the archive ceases to be online for a time, but the important thing is that no data is lost).

you mentioned the 3-2-1 backup rule: as far as I know (unless I'm missing something), they don't store 3 copies of (perhaps an important) part of their data, so 3-2-1 can't be met then. They have 4 datacenters, but not all data is stored in all of them.

it is extremely unlikely that anything could cause the data to be lost in all these locations simultaneously: I hope so. I do know that 3-2-1 rule doesn't require different states or countries, but I fear that all copies are in an area that can (and will) be hit by a huge earthquake. Perhaps I am overestimating the consequences of such an earthquake, and none will ever cause huge damages both in Oakland and San Francisco at the same time, for example. MGeog2022 (talk) 20:13, 23 April 2024 (UTC)

Why do people like… live in California? Seems like a death trap. Dronebogus (talk) 14:45, 28 April 2024 (UTC)

Sleeper Account Question

A new case request was made in the past 24 hours at the Dispute Resolution Noticeboard with regard to a contentious perennial issue within a contentious topic. I checked on the history of the filing account. What I saw is that the filing account has made 16 edits, between 21 April 2024 and 23 April 2024. That would be a new account, jumping into a contentious topic, which is a little concerning as it is. But the account was created in December 2015. It has been a sleeper for more than eight years. I know that there is a guideline to Assume Good Faith, but should I assume good faith, or is there something that I should do or someone that I should notify? Robert McClenon (talk) 01:29, 24 April 2024 (UTC)

A lot of people make accounts just for watchlisting or setting a skin. ScottishFinnishRadish (talk) 01:32, 24 April 2024 (UTC)

Okay. Then the person got into a quarrel over an issue that has not been resolved in a decade, and asked for moderated discussion, and I declined the request, and gave a contentious topic notification. Robert McClenon (talk) 03:38, 24 April 2024 (UTC)

I sometimes do wish there was a better way to report and request investigations into editors who show WP:DUCK signs of being a possible abusive sockpuppet but where we have no idea who to compare them to; WP:SPI, unfortunately, doesn't accept that AFAIK and it's tricky to raise the issue otherwise while avoiding WP:BITE / WP:ASPERSION concerns. But I'm certain every experienced editor has encountered that situation before, so it would be nice to have a formalized way to say "hey, can someone look into this?" I think we do have a few more tools that can be used to investigate things like that now and produce initial leads for a SPI, such as the edit-similarity detector, but there's no real way that I can tell to request that they be used until / unless you already have a second name. Frustrating. And this is compounded by the fact that, inevitably, the people who look most closely at suspicious possible-sockpuppets are usually those in disputes with them (people simply notice odd behavior by people they're in disputes with). So what we need is something like a formal way to say "hey it might just be my biases talking but does anyone agree that this account is sus?" and to ask other editors to help do at least a basic glance-over for publicly-available evidence leading to a possible SPI, plus possibly asking checkusers to use their tools if they agree it's already a sufficiently blatant WP:DUCK despite the other account not being clear. --Aquillion (talk) 04:16, 24 April 2024 (UTC)

I agree that this question is important and I'm interested in the answers, but sadly I can't provide one. One idea is to consult a sock specialist (probably a checkuser, though they wouldn't be using that privilege to answer) but that raises its own problems. One is that you'd effectively have to say publicly "I think User:Example smells like a sock", which isn't ideal from an AGF/NPA viewpoint. The other is that the knowledge is distributed. I could recognise a few sockmasters' work on sight, but the particular sock you're interested in today is highly likely to be someone I've not seen before. Certes (talk) 20:03, 25 April 2024 (UTC)

In addition to what ScottishFinnishRadish said, a lot of people make accounts and just never get around to editing. Sometimes they just wanted to get in early to reserve the username, other times they might be paranoid about their IP address showing. One thing to definitely check in these cases is CentralAuth and global activity. I'll also just say that sometimes, just sometimes, checkusers see everything. But you can always just poke one if you're being deafened by alarm bells. -- zzuuzz ^(talk) 04:45, 24 April 2024 (UTC)

Thank you. This doesn't really answer my questions. I think that my questions had two parts. First, is there any particular guideline as to when I should be suspicious of a sleeper account that wakes from a long winter's nap? Second, is there any way that I can request a Checkuser to look at a suspicious awakening sleeper account, when I don't have a clue who the sockpuppeteer might be? If there is no answer, there is no answer. I am asking. Robert McClenon (talk) 19:46, 25 April 2024 (UTC)

I think the more important question to ask is, "Are they being disruptive?" If they are being disruptive, then we need to deal with that in some way that makes the disruption stop, regardless of whether they're socking or not. If they're not being disruptive, then I wouldn't get too excited over it.

One thing I might suggest is to check their global contributions. It might be that they're actively editing on other projects and just happened to drop in on enwiki 8 years ago and got an account auto-created that way. RoySmith (talk) 20:03, 25 April 2024 (UTC)

The problem with this way of thinking (which I've often encountered when pushing for stronger measures against sockpuppetry) is that a defining characteristic of "smells like a sock" editors, at least to me, is WP:TEND / WP:CIVILPOV / WP:BATTLEGROUND editing - some of the editors who are most likely to aggressively evade blocks are ones who feel like they have a "mission" here, crusading ones who approach Wikipedia like a battleground. And those are some of the hardest things to prove and to make a case for on WP:ANI or WP:AE; usually it requires an extensive track record and takes a lot of time. Being "the person who constantly brings people who are editing from the same viewpoint to ANI / AE" is also not usually a good look - even if they're all actually the same person, if you can't prove that then you risk looking like you're trying to abuse ANI / AE to selectively remove people with that view from Wikipedia. They're also situations where people are most likely to want to give them WP:ROPE, which means that a sockpuppet who slips back in is often going to be able to edit for a long time, despite fixing none of the problems that got them blocked to begin with, simply because it takes so long to get someone with a newly-clean record blocked for even fairly serious and clear-cut WP:TEND / WP:CIVILPOV issues, especially if they know enough to avoid crossing the few red lines that can lead to faster action. Basically, getting WP:TEND / WP:CIVILPOV / WP:BATTLEGROUND editors blocked is usually time-consuming and exhausting, so naturally editors who suspect sockpuppetry are going to want to start with that - suggesting "oh well if they're disruptive why don't you just get them blocked for that, and if not, what's the problem?" is totally unhelpful when some types of disruption can take months to deal with and massive amounts of effort to build a proper case for. --Aquillion (talk) 22:57, 25 April 2024 (UTC)

Vote now to select members of the first U4C

You can find this message translated into additional languages on Meta-wiki. Please help translate to other languages.

Dear all,

I am writing to you to let you know the voting period for the Universal Code of Conduct Coordinating Committee (U4C) is open now through May 9, 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members were invited to submit their applications for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

Please share this message with members of your community so they can participate as well.

On behalf of the UCoC project team,

RamzyM (WMF) 20:20, 25 April 2024 (UTC)

Windows 11 update (maybe)

I having trouble with my caplock, if I turn it on I have to restart my laptop to get it to turn off, also I now have a screen indicator showing caplock on/off, this has to be in a recent windows update, I did a search for the issue and they want me to uninstall my keyboard driver then re-install it, no way am I doing that, this really sucks. Is there a way to search recent updates, then uninstall the one with the issue? IDK.. - FlightTime (open channel) 21:23, 25 April 2024 (UTC)

Do you have an HP laptop? If so, this thread might help (either the regedit or task manager approach). Schazjmd (talk) 21:27, 25 April 2024 (UTC)

It's not really a Wikipedia issue, but installing a keyboard driver without having a keyboard driver installed could be an interesting challenge. Certes (talk) 21:28, 25 April 2024 (UTC)

@Schazjmd and Certes: Thank you all, yes it's a HP and well I'm sure it has a keyboard driver, but I'm not good enough to even try. Thanx again. - FlightTime (open channel) 22:03, 25 April 2024 (UTC)

The task manager approach worked. Thanx, - FlightTime (open channel) 22:10, 25 April 2024 (UTC)

Whew, glad it helped. Schazjmd (talk) 22:17, 25 April 2024 (UTC)

Abuse of autoblocking

If a user who is blocked takes advantage of autoblocking being enabled for their block to stop other, innocent users from editing by attempting to edit from random IP addresses, what will the administration do about it? By modifying the block to disable autoblocking, this allows the blocked user to evade the block, so will they send a request to a steward on Meta to lock the account to prevent further collateral damage because the account can no longer be logged into if all else fails? Faster than Thunder (talk | contributions) 21:51, 27 April 2024 (UTC)

Has this ever been a problem before? Or are you just telling people how to stuff beans up their noses? * Pppery * _{it has begun...} 21:52, 27 April 2024 (UTC)

If a user is being deliberately disruptive in this way, their account could be locked. — xaosflux ^Talk 22:11, 27 April 2024 (UTC)

KOSA act blackout?

The "Kids Online Safety Act" (KOSA) is a bill introduced in the US Senate by Senators Richard Blumenthal (D‑CT) and Marsha Blackburn (R‑TN) in February 2022 and reintroduced in May 2023; the bill establishes guidelines meant to protect minors on covered platforms. Per Section 3.b of the proposed act, a "covered platform" (defined as "a commercial software application or electronic service that connects to the internet and that is used, or is reasonably likely to be used, by a minor.") has the duty to block a minor's access to content that is deemed harmful to them.

This puts **every** Wikimedia project in danger of being censored by the U.S. government, because not only does it count as a “covered platform” (it is used by students under 16 for study and references), but it may either force the Wikimedia Foundation to ask users to provide personal information about themselves (particularly their age) when creating a new account, or remove encyclopaedic articles under the guise of “ensuring minor safety”. If passed, the KOSA act will put information on Wikimedia projects under scrutiny by the US government, and virtually eliminate the neutrality that has been part of them for years.

Not only does the act create an excuse for information censorship (about things that the US government doesn’t favour), but also the risk of a data leak. If someone has access to the age of every single Wikimedia user, then there’d be a very real possibility that they would be leaked to the public, including those of younger editors.

Therefore, an anti-KOSA blackout should be done to stop the act from being passed (like the last time we did with SOPA and PIPA; all three bills are somewhat related to censorship).

The responsibility of protecting a minor’s information online should be done by, and taught to, the minor’s parent, and not by the government.

tynjee 13:18, 28 April 2024 (UTC)

Well, obviously I oppose censorship, but is the legislation actually in any danger of being passed? Crazy ideas are proposed in parliaments across the world, and although U.S. politics is weirder than most, is there a reasonable chance of that legislature passing such a bill? I mean, is this an actual worry? Cremastra (talk) 13:36, 28 April 2024 (UTC)

@Cremastra i guess it is a worry; this act was introduced way back in 2022 and has 68 cosponsors at the time of writing (see https://www.congress.gov/bill/118th-congress/senate-bill/1409/cosponsors). sure kid safety on the internet is obviously a concern, but i don't see the point in putting an "age" option when creating a new wikipedia account tynjee 14:02, 28 April 2024 (UTC)

Oh, God, no, we don't want an age option, that would privacy invasion and just silly. To be clear, I think this bill has potential for abuse/censorship, although it means well, I'm just assessing whether we really need to be worried here or not. Cremastra (talk) 15:06, 28 April 2024 (UTC)

The definition in the bill of a "covered platform" excludes "an organization not organized to carry on business for its own profit or that of its members" (section 2(3)(B)(ii)). Phil Bridger (talk) 14:02, 28 April 2024 (UTC)

How should we parse that quote? If it's "a commercial (software application or electronic service)" then non-profits should be exempt. If it's "a (commercial software application) or electronic service" then we might not, as we clearly offer an electronic service. Disclaimer: I am neither a lawyer nor an American. Certes (talk) 14:11, 28 April 2024 (UTC)

That comment seems to relate to the OP's quote rather than to mine. The quote I provided is pretty clear that non-profits are not covered by the bill. Phil Bridger (talk) 14:18, 28 April 2024 (UTC)

(edit conflict) If you read things in context it's clear enough. The part you quote is part of the general definition in 2(3)(A), while Phil Bridger's quote is part of a list of specific exclusions from 2(3)(A). Anomie⚔ 14:25, 28 April 2024 (UTC)

So just to make this crystal clear: are non-profits excluded? Dronebogus (talk) 14:43, 28 April 2024 (UTC)

According to one of the sponsors, Blumenthal, non-profits are excluded from KOSA. [37]

Does the Kids Online Safety Act cover platforms run by non-profit organizations?
No, websites run by non-profits organizations – which often host important and valuable educational and support services – are not covered by the scope of the legislation.

Masem (t) 15:22, 28 April 2024 (UTC)

It sounds like Wikipedia and sites like it were explicitly considered and written around. In other words, this has virtually no effect on us. Dronebogus (talk) 04:07, 29 April 2024 (UTC)

The foundation pays lawyers. Have they said anything anywhere about this bill and how it may or may not affect this project? ElKevbo (talk) 15:11, 28 April 2024 (UTC)

I said the same thing at meta. I looked at the foundation website and blog and the answer is seemingly “no”. Dronebogus (talk) 04:06, 29 April 2024 (UTC)

I recall that there were at least some statements made on the matter. This CNBC article from 2022 says: The American Civil Liberties Union, Center for Democracy & Technology, Electronic Frontier Foundation, Fight for the Future, GLAAD and Wikimedia Foundation were among the more than 90 groups that wrote to Senate Majority Leader Chuck Schumer, D-N.Y., Senate Commerce Committee Chair Maria Cantwell, D-Wash., and Ranking Member Roger Wicker, R-Miss., opposing the Kids Online Safety Act.

When I started typing this comment, I would have bet $5 that we'd written about KOSA in the Signpost at some point in the last couple years (and an additional $2 that I was the one who'd written about it), but a search gives me absolutely nothing. It may be that it's hard to distinguish between the Kids Online Safety Act (US) from the Online Safety Act (UK) and the Digital Services Act (EU), even by epicly bigbrained policy wonks and/or journalists. jp×g🗯️ 23:45, 29 April 2024 (UTC)

Is it that time of the year where we discuss a blackout? It was disruptive advocacy in 2012, and it would be disruptive advocacy now. Thebiguglyalien (talk) 17:21, 29 April 2024 (UTC)

It was based, actually. jp×g🗯️ 23:36, 29 April 2024 (UTC)

The SOPA blackout was definitely supported by the community because it 100% threatened the fundamental ability of Wikipedia to operate. (see [38]) This bill, as it appears to be in its language, immediately exempts non-profit organizations and websites they maintain from it, so there is no existential threat to WP. So it would be disruptive advocacy to push for any type of project-level notice. Of course, it still would be best to have WMF Legal to review and make sure we're clear on this. Masem (t) 03:48, 30 April 2024 (UTC)

The UK Online Safety Act 2023 provoked similar recent debate, leading to direct statements from WMF and non-compliance. I would expect more activity than this from WMF if they thought US legislation would have similar impact, and substantially more activity before it becomes an en.wiki issue (the WMF having a broader set of interests than en.wiki). CMD (talk) 05:47, 30 April 2024 (UTC)

Community Wishlist Survey: Template Picker Project

We want editors to find and use templates easily. As such, we have selected two wishes which we are implementing together:

• Wish #1: Quickly add infobox – an easier way for newer editors to find and insert common templates such as infoboxes.

• Wish #2: Quickly add favorite and related templates – a way to show recently used templates and favorited templates for frequent template users.

These wishes ranked 5th and 11th in the Community Wishlist Survey 2023 respectively.

Please read more about the template picker improvements project, and leave any early feedback on the talkpage.

On behalf of Community Tech, –– STei (WMF) (talk) 21:20, 29 April 2024 (UTC)