Wikipedia:Village pump (all)

Coordinates: 49°26′02″N 0°12′24″E / 49.43389°N 0.20667°E / 49.43389; 0.20667
Source: Wikipedia, the free encyclopedia.

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

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)

Village pump sections
post, watch, search
Discuss existing and proposed policies
post, watch, search
Discuss technical issues about Wikipedia
post, watch, search
Discuss new proposals that are not policy-related
post, watch, search
Incubate new ideas before formally proposing them
post, watch, search
Discuss issues involving the Wikimedia Foundation
post, watch, search
Post messages that do not fit into any other category
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)[reply]

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

Disclosure: I am currently a candidate for the U4C.

Signatories for A

  1. Petitioner, signed, SpringProof talk 04:31, 23 March 2024 (UTC)[reply]

Signatories for B

  1. Petitioner, signed, SpringProof talk 04:31, 23 March 2024 (UTC)[reply]
  2. Agree Slacker13 (talk) 13:04, 27 March 2024 (UTC)[reply]

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

@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)[reply]
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)[reply]
@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)[reply]
  • 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)[reply]
    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)[reply]
Oppose this per others above: this is just more WMF stuff encroaching on enWP's jurisdiction.
🌺 Cremastra (talk) 22:48, 26 March 2024 (UTC)[reply
]
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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    @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)[reply]
    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)[reply]
  • This isn't useful. ArbCom is ArbCom. U4C has no supervisory jurisdiction over ArbCom. Stifle (talk) 10:08, 2 April 2024 (UTC)[reply]

Sources: clarify that they may be on a linked page

I wish to seek to change the wikipedia policy WP:SOURCE. Currently this states "Any material lacking an inline citation to a reliable source that directly supports the material may be removed and should not be restored without an inline citation to a reliable source." in the section Responsibility for providing citations. I propose amending this with the additional sentence "Sources may be contained in a linked article."

RATIONAL FOR THE PROPOSED CHANGE

I believe that requiring sources on every page brings a number of problems: 1) it is onerous and inefficient and discourages linking relevant articles to pages, especially for new editors: 2) the relevant article may include more sources, mentions of the article might only include one, so anyone looking for useful information might not see it; 3) in a rapidly moving field sources may be updated in an article but that might be missed on linked pages. In any case it is easy for anyone to click on the link to see the article with all relevant sources. Hewer7 (talk) 13:50, 23 March 2024 (UTC)[reply]

I disagree with this suggestion. If the same information is sourced in a different article, it's much less onerous for the editor to copy the source to the new article than to expect readers to go to other articles to verify the information. And we can't rely on other articles being properly sourced because, too often, they're not. Schazjmd (talk) 14:00, 23 March 2024 (UTC)[reply]
Wikipedia:Wikipedia is not a reliable source. It has been long established that we cannot cite other Wikipedia pages to support content in a Wikipedia article. It may be fruitful to review sources cited in other articles, but Wikipedia:Verifiability#Burden states, The burden to demonstrate verifiability lies with the editor who adds or restores material, and it is satisfied by providing an inline citation to a reliable source that directly supports the contribution. That means that an editor who is using a citation to a source found in another article must have verified that the source does indeed support the content being added. You cannot change just the one policy point you targeting, other points in other policies and guidelines would all have to be changed. Donald Albury 14:10, 23 March 2024 (UTC)[reply]
I am not proposing that wikipedia be used as a source. My proposal is that sources may be contained in a linked article. Hewer7 (talk) 14:42, 23 March 2024 (UTC)[reply]
When you rely on another linked article to have the cited sources to support content, you are indeed using that other article as a source for that content. Donald Albury 18:03, 23 March 2024 (UTC)[reply]
An example of why we don't use WP articles as sources (or rely on sources cited in other articles without verifying their suitability): An article I'm drafting (User:Donald Albury/Trail Ridge) refers to the geological Hawthorn Formation. I found that our article on the Hawthorn Formation was a stub, saying it is a stratigraphic unit in South Carolina. On the other hand, our article on the Hawthorn Group said it was a stratigraphic unit in north Florida. In fact, the Hawthorn Group, formerly called the Hawthorn Formation, is a stratigraphic unit stretching from southeastern South Carolina through coastal Georgia and down the Florida Peninsula. I had to find new sources and cite them to correct that mess. You can only decide that a Wikipedia article is correct if you check out the cited sources, and search for and check out other sources (in case the cited sources are incomplete), and if you do that, you should just go ahead and cite those sources in the article you are working on. Donald Albury 18:28, 23 March 2024 (UTC)[reply]
There is a very simple reason why we require citations to be repeated in every article where information appears… articles can change. The “linked” article may currently contain a citation that supports the information at the article you are working on… but there is no guarantee that this will be the case in the future. The other article might, at some point in the future, be completely rewritten - and in the process the citation that supports what is in your article might be removed. You have to repeat the citation in your article to ensure that the information will always be supported, no matter what may happen at the other one. Blueboar (talk) 14:44, 23 March 2024 (UTC)[reply]
In addition to that (not that that isn't enough, mind you), there's the fact that while most of us most of the time experience Wikipedia online, it's not the only way it can be used. A printed copy of an article that contains proper referencing has those references listed at the bottom of the article. If we switch to relying on the mere fact that there are references on some other page, those references may not accessible to the person using the printed version. -- Nat Gertler (talk) 15:55, 23 March 2024 (UTC)[reply]
I would oppose this change in policy. Besides the other issues mentioned above, this would make it much more onerous and error-prone for a reader to verify content. Suppose there is a sentence containing links to 5 other Wikipedia articles, with no citation. If the reader wants to verify this statement, they would need to click on each of those 5 links, scrutinize the linked article to try to find a similar statement and see if there is a source there. If they can't find such a source after spending 10 minutes or whatever in this process, they still don't know if they have just overlooked the source or if the original statement was simply unsourced. Having the source for a statement at the point where the statement is made is essential.
The OP says that the current process is onerous for editors. That's fine; if there is a part of the process that is onerous, it should be onerous for editors, not for readers. CodeTalker (talk) 20:39, 23 March 2024 (UTC)[reply]
+1 Regards, Goldsztajn (talk) 21:24, 23 March 2024 (UTC)[reply]
  • No, absolutely not. This would invite all sorts of problems. The most obvious one is that it would become easier for a source's meaning to drift via a game-of-telephone; a slight mistake or paraphrase on one article that isn't a problem there could become something drastically divergent from the source on another article that relies on the first one's citation. And worse, it makes it harder to verify - what source in the linked page, exactly, and on what page, do I look at if I'm not sure it's summarized correctly on the second page? Finally, on top of all this, what if the relevant section is edited or removed and the source replaced or removed itself? Someone making that edit may not even know the page that relied on that source existed, so it would quietly become unsourced with nobody realizing that it had happened. We already have a problem with "source drift", especially in uncited lead sections, where text starts out reasonably summarizing the source and yet repeated edits for
    WP:TONE or perceived NPOV issues or the like, each one a reasonable rewording of the phrasing immediately prior to them, collectively cause the text to drift further and further away from what the source actually says. This would make the problem far worse. --Aquillion (talk) 03:55, 25 March 2024 (UTC)[reply
    ]
    +1 I strongly oppose this idea, but Aquillion said it far better than I could.
    🌺 Cremastra (talk) 20:58, 26 March 2024 (UTC)[reply
    ]
This would go against verification, Wikipedia is never a reliable source for verification and there is nothing to say that the details on the other page are reliable or will even stay in the article. -- LCU ActivelyDisinterested «@» °∆t° 21:18, 25 March 2024 (UTC)[reply]
  • Oppose. Sources should be on the page they relate to, so that verifiability can be met. Stifle (talk) 10:09, 2 April 2024 (UTC)[reply]
  • Oppose. I understand where you are coming from, but the information architecture of wikipedia isn't formed to make this a robust option. The longer-term solution, which has been discussed from time to time, would be to create a centralized "citation library" where, for instance, a book referenced by many articles has a central citation which is called from each of the articles using that citation. The only way this would work in practice would be to have a bot-based transfer of citations to the library with in-page replacement. This is a wish and not a reality today. --User:Ceyockey (talk to me) 00:36, 11 April 2024 (UTC)[reply]
  • Oppose. Citing another article is just straight-up using Wikipedia as a source which isn't good. It's also confusing for readers to tell if the claims are cited since now they would have to read another article to verify it themself which may or may not be cited as well.
TheWikiToby (talk) 04:50, 19 April 2024 (UTC)[reply]

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

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

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

Traditional map New Maps
Map

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

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)[reply]
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)[reply]
  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)[reply]
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)[reply]
@Kanguole Ok, we are here for agreement about that. Hooman Mallahzadeh (talk) 16:14, 29 March 2024 (UTC)[reply]
@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)[reply]
If it's an article about a river, the traditional map is more informative.
🌺 Cremastra (talk) 21:01, 29 March 2024 (UTC)[reply
]

@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
Map

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

Seine
The Seine in Paris
Map
Topographical map
Native namela Seine (French)
Location
CountryFrance
Physical characteristics
Source 
 • locationSource-Seine
MouthEnglish Channel (French: la Manche)
 • location
Le Havre/Honfleur
 • coordinates
49°26′02″N 0°12′24″E / 49.43389°N 0.20667°E / 49.43389; 0.20667
 • elevation
0 m (0 ft)
Length777 km (483 mi)
Basin size79,000 km2 (31,000 sq mi)
Discharge 
 • locationLe Havre
 • average560 m3/s (20,000 cu ft/s)
Basin features
River systemSeine basin
Tributaries 
 • leftYonne, Loing, Eure, Risle
 • rightOurce, 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)[reply]

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)[reply]
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)[reply]
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)[reply]
@
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)[reply
]
I'll revert on these pages for now, thank you for the elaboration. Remsense 16:35, 29 March 2024 (UTC)[reply]
If you really want consistent guidelines (after working out technical issues), put them on
MOS:BLOAT. SamuelRiv (talk) 16:39, 29 March 2024 (UTC)[reply
]
@SamuelRiv I made a discussion for that here. Thanks, Hooman Mallahzadeh (talk) 16:51, 29 March 2024 (UTC)[reply]
@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, ~ LindsayHello 20:26, 29 March 2024 (UTC)[reply]

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

🌺 Cremastra (talk) 21:04, 29 March 2024 (UTC)[reply
]

Agree with proposal 1 re OSM

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

Disagree with proposal 1 re OSM

  1. no 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)[reply]
  2. 🌺 Cremastra (talk) 21:03, 29 March 2024 (UTC)[reply
    ]
    @
    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)[reply]
    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)[reply]
  3. no 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)[reply]
    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)[reply]
  4. OSM map is much less informative for the topic of rivers. CMD (talk) 06:17, 7 April 2024 (UTC)[reply]
    @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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
  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, ~ LindsayHello 07:42, 7 April 2024 (UTC)[reply]
    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)[reply]
    @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)[reply]
    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, ~ LindsayHello 13:19, 7 April 2024 (UTC)[reply]
    @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)[reply]
    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, ~ LindsayHello 13:19, 7 April 2024 (UTC)[reply]
    @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)[reply]
    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)[reply]
    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)[reply
    ]
    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)[reply]
    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)[reply]

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)[reply]
  • 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 (talkcontribs) 10:19, 20 April 2024 (UTC)[reply]

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

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

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

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

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

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

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

Note: Notification of this discussion was left at Wikipedia talk:In the news.—Bagumba (talk) 12:00, 10 April 2024 (UTC)[reply]
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)[reply]
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)[reply]
Note The blurb currently reads A total solar eclipse appears across parts of North America[2]Bagumba (talk) 12:33, 10 April 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Support per nom, see no reason to oppose. Aaron Liu (talk) 13:19, 10 April 2024 (UTC)[reply]
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)[reply]
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)[reply]
@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)[reply]
Support, though I find isaacl's alternative of including a time frame intriguing. Aaron Liu (talk) 17:11, 10 April 2024 (UTC)[reply]
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)[reply]
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)[reply]
"Is elected" is present tense, specifically present perfect. "Elects" is also present tense, simple present. Levivich (talk) 18:14, 10 April 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I'll have what you're having. InedibleHulk (talk) 22:30, 11 April 2024 (UTC)[reply]
  • Decide case-by-case: we can safely IAR in most cases.
    Cremastra (talk) 19:43, 10 April 2024 (UTC)[reply
    ]
  • 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)[reply]
  • 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 wordsdeeds 22:00, 10 April 2024 (UTC)[reply]
    Again, it is confusing to say that the solar eclipse is in the sky. Aaron Liu (talk) 22:05, 10 April 2024 (UTC)[reply]
    It would be confusing to switch from "is....was....did....has" in a single box on a typical ITN week. doktorb wordsdeeds 22:28, 10 April 2024 (UTC)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • Keep present tense as general recommendation per above. Discuss individual cases when this is too jarring. —Kusma (talk) 07:43, 11 April 2024 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
    @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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply
    ]
  • 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)[reply]
  • How about, "is seen over North America" -- passive with present tense and past participle, anyone? :) Alanscottwalker (talk) 21:49, 11 April 2024 (UTC)[reply]
    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)[reply
    ]
    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)[reply
    ]
    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)[reply]
    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)[reply]
    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)[reply]
    I was illustrating why the passive voice doesn't deserve to be demonized. Aaron Liu (talk) 21:42, 12 April 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    @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)[reply]
  • 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)[reply
    ]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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.
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply
    ]
  • 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)[reply
    ]
  • Support Per
    OTD and the Spanish edition for examples. Andrew🐉(talk) 07:38, 18 April 2024 (UTC)[reply
    ]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    For consistency and compactness. Aaron Liu (talk) 02:51, 20 April 2024 (UTC)[reply]
    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)[reply]
    The historical present is not the convention anywhere on Wikipedia's main page. Just see today:
    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)[reply]
  • 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)[reply]
  • 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)[reply
    ]
    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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]

Upgrade SCIRS to a guideline

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

  • 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)[reply
]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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. --ChetvornoTALK 20:51, 11 April 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply
]
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)[reply]
FYI, SCIRS already addresses the scope in the lead The scope of this page includes the
formal sciences
.
As for something being too obscure, that would indicate a
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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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
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)[reply]
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)[reply]
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)[reply
]
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)[reply]
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:CONSENSUS on. KoA (talk) 04:38, 23 April 2024 (UTC)[reply
]
@
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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: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)[reply
]
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)[reply]
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)[reply]
I think we're looking at two different problems:
  • Primary vs secondary sources:
    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)[reply]
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)[reply]
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. Zerotalk 02:59, 24 April 2024 (UTC)[reply]
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)[reply]
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. Zerotalk 04:54, 24 April 2024 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]

References

Making COI policy

Please see the discussion I started at

]

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

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

Just clarifying, I assume that you mean it by the Catholic Church use of those terms. North8000 (talk) 20:48, 23 April 2024 (UTC)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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
Boniface. Curbon7 (talk) 01:04, 24 April 2024 (UTC)[reply
]

Technical

Number of watchers

If you go to ?action=info for any page, you will see a table with various statistics, including two lines about how many people are watching the page, e.g.:

Number of page watchers 375
Number of page watchers who visited recent edits 12

For example, https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)?action=info for this page.

I am finding that the ratio shown here is not at all unusual for older articles, but the first line gets more attention from editors. They think "hundreds of editors are watching this page", when they should be thinking "almost nobody is watching this page". Is there a way we could remove/hide the irrelevant number from this info page? Or should we just change MediaWiki:Pageinfo-watchers to something like "Total number of watchlists (includes inactive editors)"? WhatamIdoing (talk) 04:53, 10 April 2024 (UTC)[reply]

I don't think we should localize that message. This topic was recently more broadly discussed in meta:Community Wishlist Survey 2023/Notifications, Watchlists and Talk Pages/Change information about the number of watchers on a page. — xaosflux Talk 09:38, 10 April 2024 (UTC)[reply]
phab:T336250 is open about this. — xaosflux Talk 09:40, 10 April 2024 (UTC)[reply]
@WhatamIdoing: It's certainly possible, the system message is MediaWiki:Pageinfo-watchers. We haven't created this, so we presently use the MW default message. --Redrose64 🌹 (talk) 16:17, 10 April 2024 (UTC)[reply]
I’m one of those who ‘think "hundreds of editors are watching this page", when they should be thinking "almost nobody is watching this page"’ ...
I think we should have that “second line” added to these pages (or replaced the “first line”):
--Dustfreeworld (talk) 18:30, 11 April 2024 (UTC)[reply]
I bet someone here could write a .css script that would blank that out, or rename it to something like "This is the wrong line – ignore it". I checked a bunch of Special:Random pages, and most of them showed no data, due to there being too few people watching the pages. WhatamIdoing (talk) 21:11, 11 April 2024 (UTC)[reply]
For hiding that row on the page information page on Wikipedia, try #mw-pageinfo-watchers { display: none; } in one of the .css files. –Novem Linguae (talk) 22:43, 11 April 2024 (UTC)[reply]
Thanks, @Novem Linguae. That seems to have worked for me. That suggests that iff we ever decided that we wanted to do that globally, it could be done in (e.g.,) global.css. I'm going to try this out for a while. I suspect that I'll like it. WhatamIdoing (talk) 22:32, 12 April 2024 (UTC)[reply]
#til:
If it's on <30 watchlists, no number is given for either item (the second item is simply suppressed).
If it's on ≥30 watchlists, an exact number is given for both items.
If the second number is zero, it says "There may or may not be a watching user visiting recent edits" instead of a second number. WhatamIdoing (talk) 23:53, 10 April 2024 (UTC)[reply]
Is there a way we could remove/hide the irrelevant number from this info page? I would not support removing this. Presenting both numbers, and letting the user decide which they want or need, seems like an acceptable status quo here. The less than 30 thing for non admins is for security reasons. Admins can see both numbers at all times. The linked phab ticket mentions changing the second message to mention 30 days explicitly. I could get behind a change like that. –Novem Linguae (talk) 02:05, 11 April 2024 (UTC)[reply]
Under what circumstances do you think it would it be useful for to you to know that the watchlists associated with 1,991 mostly inactive (and sometimes actually dead) include the defunct Wikipedia:WikiProject Contents?
The number of active editors presently watching that page is a single-digit number. I can understand why that number would be useful to know, but not why the first has practical value. WhatamIdoing (talk) 02:56, 11 April 2024 (UTC)[reply]
As far as I can tell, pages can be watched actively, without the user being considered active there - such as through email or syndication. — xaosflux Talk 08:45, 11 April 2024 (UTC)[reply]
Or by looking at the watchlist but not visiting the links. Nardog (talk) 09:43, 11 April 2024 (UTC)[reply]
I suspect that the scenario Nardog describes is far more common than the one Xaosflux describes. WhatamIdoing (talk) 18:32, 11 April 2024 (UTC)[reply]
That was an argument against hiding the total number of watchers. I was echoing Xaosflux. Nardog (talk) 05:58, 13 April 2024 (UTC)[reply]
I've never spent much time reading about the internal mechanism, but I believe that it works like this:
  • If you have some pages on your watchlist, and then get permanently locked out of your account, you are "a watcher" for all of those pages forever, even though you can't actually watch anything from that account.
  • If you have some pages on your watchlist, go to Special:Watchlist, close the tab without clicking on any link or visiting an article at all, and then get permanently locked out of your account, you are counted as "an active watcher" for all the pages on your entire watchlist for the next 30 days (including pages that did not have any changes made, so they weren't listed at Special:Watchlist on the day that you visited that page).
This means that there are 9 active editors with this page on their watchlist, of which an unknown number – but it is quite possibly zero – actually looked at the page in question during the last month.
So Xaosflux says, yes, there may only 9 editors who have that page on their watchlists and actually went to Special:Watchlist at any point during the last 30 days, but maybe a few more people also get e-mail messages about changes to articles on their watchlist, so the "9" might be a slight undercount.
The scenario you describe – visiting the watchlist but not checking every page – is certainly common. The "9" is probably an overcount, if the goal is to know whether anyone actually checked the specific page. WhatamIdoing (talk) 02:54, 15 April 2024 (UTC)[reply]
WhatamIdoing, I don't believe merely viewing the watchlist makes you an active watcher. — Qwerfjkltalk 07:45, 15 April 2024 (UTC)[reply]
You're correct. The count uses the same "first unseen timestamp" data used for highlighting of unseen edits on the history page. If a revision older than the configured age would be highlighted, the user is not counted as having visited recent edits. Viewing the watchlist or history page doesn't reset that, while visiting the page itself will and viewing old revisions or diffs may. Anomie 11:41, 15 April 2024 (UTC)[reply]
Thanks. I have corrected the errors I introduced last week to Help:Watchlist ("Number of page watchers:  3,644; Number of page watchers who visited recent edits: 29; Number of editors who noticed my error:  0").
The "visited recent edits" should probably be changed to "visited the page recently". I think most editors will interpret this as "checked a diff" (i.e., the edit) instead of "clicked on the article" (e.g., displayed the page via Special:Random). WhatamIdoing (talk) 16:42, 15 April 2024 (UTC)[reply]
Does hovering over the diff with
WP:POPUPS count as "visiting" the edit? I rarely click on anything unless the popups diff is unclear, or I want to investigate the history. Suffusion of Yellow (talk) 16:47, 15 April 2024 (UTC)[reply
]
That doesn't reset the "first unseen timestamp" (a fact that I've found particularly convenient). WhatamIdoing (talk) 17:43, 15 April 2024 (UTC)[reply]
Personally, I would interpret "visited the page recently" to mean "visited the current version of the page recently". I think the natural assumption is that "page" without a qualifier refers to the current version. isaacl (talk) 16:59, 15 April 2024 (UTC)[reply]
Would you feel the same about "visited the page during the last 30 days"? WhatamIdoing (talk) 17:44, 15 April 2024 (UTC)[reply]
I think referring to a time-bound period does change the natural assumption to having viewed the page as it appeared at the time of viewing during the specified period. I don't think it would be interpreted as having checked a diff. isaacl (talk) 16:56, 20 April 2024 (UTC)[reply]
I like the idea of having clarity.
BTW, I'm finding that I'm happy with the script @Novem Linguae wrote for me. I'm still sometimes startled to see that there's only the one line, but it gives me the information that I want, and if for some reason I need to see the number of inactive accounts, it's only one incognito/private window away. WhatamIdoing (talk) 19:11, 22 April 2024 (UTC)[reply]

Why does the talk page visual editor not have a "cite" button?

Am i missing something, or is it impossible to automatically cite urls from the talk page visual editor? Yes, you can use the source editor, but is there a specfic reason why this is? Is there any way to get a more featured editor on the talk page visual editor? MarkiPoli (talk) 12:14, 16 April 2024 (UTC)[reply]

Not sure if it's intentional, but the keyboard shortcut Ctrl+Shift+K (Cmd+Shift+K on macOS) still works for this. the wub "?!" 13:17, 16 April 2024 (UTC)[reply]
Yeah, i noticed that too. Its still annoying not having a full featured editor exactly the same as the main page editor MarkiPoli (talk) 09:39, 17 April 2024 (UTC)[reply]
There's some things that're not allowed there because they don't work well in list-indented discussions, but mostly it's because of space constraints for the toolbar. The compromise is that the things left out are more on the power-user end (e.g. citations are very rarely used in discussions), and we hope that power-users will be able to use keyboard shortcuts and sequence triggers for these things. (You can press ctrl/cmd + ? to see all the options here. Or type \ if you're in visual mode for a nifty command-palette...) DLynch (WMF) (talk) 16:04, 17 April 2024 (UTC)[reply]
Or edit the full page in source mode with all the bells and whistles of course. —TheDJ (talkcontribs) 19:49, 17 April 2024 (UTC)[reply]
Yeah, but they said they already knew about that. :D DLynch (WMF) (talk) 21:05, 18 April 2024 (UTC)[reply]
@MarkiPoli, it's at least theoretically possible. Look at this diff (noting that @DLynch (WMF) has not yet promised to maintain it for the rest of my life). Since we can add a special character button from the visual editor, it should be possible to add other buttons. WhatamIdoing (talk) 19:17, 22 April 2024 (UTC)[reply]
Maybe I'm missing something, but I don't see a need for this. Could you give me an example? Thanks --- thetechie@enwiki: ~/talk/ $ 19:32, 22 April 2024 (UTC)[reply]
If you want to make a citation so that others can easily see it and potentially copy paste it into the article if useful (if its part of a discussion and can't be immediately put in the article for some reason i.e. its contentious). Also, a gaping flaw that's worse in my opinion is there's no real way to even insert templates at all in the replier (it literally says that wikitext is not allowed in the visual reply editor when it doesnt say this in the article editor). Is there any way at all to insert templates in the visual talk page editor without switching to source? MarkiPoli (talk) 19:49, 22 April 2024 (UTC)[reply]

AFD Stats not updating grid templates

AFD Stats not updating on the individual grid templates — Maile (talk) 18:23, 16 April 2024 (UTC)[reply]

@Maile66 It looks okay to me. Can you describe in more detail the problem that you are experiencing? --Ahecht (TALK
PAGE
) 18:33, 16 April 2024 (UTC)[reply]
The top listings are from yesterday, the 15th. I have made two deletes today that are not showing up there. The change is usually instantaneous if I reload the grid page. — Maile (talk) 18:41, 16 April 2024 (UTC)[reply]
@Maile66 Per toolforge:replag, there is currently about 2 hours of lag on the enwiki database replicas that all toolforge tools use, likely related to the database maintenance mentioned in #pagelinks normalization above. --Ahecht (TALK
PAGE
) 19:12, 16 April 2024 (UTC)[reply]
Thanks. I'll just wait out. — Maile (talk) 19:19, 16 April 2024 (UTC)[reply]
And now it's up to over 4 hour lag and my Quarry and bot reports are not updated. I hope this is not a maintenance tasks that takes several days. Work will just pile up. Thanks for pointing out the message from yesterday. I assume this will affect database and bot reports and not article content, right? Liz Read! Talk! 22:03, 16 April 2024 (UTC)[reply]
Yeah, I was just re-checking, and it's now been 4-plus hours for me on the above AFD Stats. — Maile (talk) 22:30, 16 April 2024 (UTC)[reply]
@Liz and Maile66: do you think we start a bug report? Found this thread through my watchlist and looks like it is a bug that should be reported. thetechie@enwiki: ~/talk/ $ 22:32, 16 April 2024 (UTC)[reply]
I think that's a good idea. Do you know how to do that? This might affect even more processes than we've mentioned above. — Maile (talk) 22:36, 16 April 2024 (UTC)[reply]
@Maile66: This page is a good start. You should follow the instructions there to create a Phabricator account, then you can create a bug report. If you need me to, I can, and I can give you the link. If you or Liz does, please put the link in this thread, I'd like to keep track of it. thetechie@enwiki: ~/talk/ $ 22:44, 16 April 2024 (UTC)[reply]
@TheTechie: that would be great if you would start it. — Maile (talk) 22:51, 16 April 2024 (UTC)[reply]
Okay, I will when I can, and will drop the link below. I'll be sure to ping you. thetechie@enwiki: ~/talk/ $ 22:52, 16 April 2024 (UTC)[reply]
Done, see here: https://phabricator.wikimedia.org/T362732 thetechie@enwiki: ~/talk/ $ 23:26, 16 April 2024 (UTC)[reply]
Thanks, TheTechie, for starting this but the bug report just mentions AFD stats, not Quarry queries or any of the bot reports. Liz Read! Talk! 23:31, 16 April 2024 (UTC)[reply]
I edited my original post. thetechie@enwiki: ~/talk/ $ 01:48, 17 April 2024 (UTC)[reply]
 Thanks I added my issue. Seems I already had a Phabricator account. It's been such a long time since I was over there, I had forgetten. — Maile (talk) 23:39, 16 April 2024 (UTC)[reply]
Yes, my primary participation is subscribing and following problems not filing reports. The discussion there goes over my head once it stops being English and starts into code. Liz Read! Talk! 01:15, 17 April 2024 (UTC)[reply]
Looks like it's fixed. Now finally, I can view my mainspace edit count without 1 day of lag. Stay safe, thetechie@enwiki: ~/talk/ $ 00:16, 18 April 2024 (UTC)[reply]
As of today, April 24, the issue has returned. I have filed Phabricator Task T363077, hoping this resolve it once and for all. — Maile (talk) 21:03, 21 April 2024 (UTC)[reply]
This issue cannot be resolve[d] once and for al[l]. There will be spurts of replag lasting a few hours to a day from time to time, for the foreseeable future. * Pppery * it has begun... 21:10, 21 April 2024 (UTC)[reply]
And my understanding is that these Phabricator tasks are not helpful - with only one exception I can think of replag has been due to deliberate database maintenance that the people involved are aware of the impact of, and it will resolve itself when its done. * Pppery * it has begun... 21:15, 21 April 2024 (UTC)[reply]
Thank you. At last, someone has given us some insight on how this works. — Maile (talk) 21:21, 21 April 2024 (UTC)[reply]
Well, looks like I was mistaken and this report was helpful, and this replag instance was a real standalone bug not an expected consequence of database maintenance. So, I guess you can report it, but sometimes you will get "this is a known issue that the DBAs are working on" ("DBA" is an acronym for database administrator). * Pppery * it has begun... 21:29, 21 April 2024 (UTC)[reply]
Thank you for all this insight. I have previously come across "this is a known issue ... " and usually just back off on those types. — Maile (talk) 21:41, 21 April 2024 (UTC)[reply]
As of right now, this has not yet been resolved. — Maile (talk) 11:31, 22 April 2024 (UTC)[reply]
maybe resolved at ~16 UTC. see
talk) 15:27, 22 April 2024 (UTC)[reply
]
thumbs up Great! Wow - it's working today. Thanks. — Maile (talk) 15:53, 22 April 2024 (UTC)[reply]

Database replication lag

Replication lag

The database on which this query was executed has a synchronization delay with the wiki. This can be caused by maintenance or incident on database, and should be resolved soon. The modifications that was made in last 20 hours on the wiki are not taken into account in results bellow.

Just bellowing here to make sure that someone in charge is aware of this, and working to resolve it. Every time I've checked in for the past several hours, the lag has grown longer; there is no sign as yet that it's started to get shorter again. I searched for a Phabricator, and couldn't find any. Would like to have some idea of the meaning of "soon" in this case. wbm1058 (talk) 14:08, 17 April 2024 (UTC)[reply]

@Wbm1058 See the #AFD Stats not updating grid templates discussion above or T352010. Per the phab ticket, it should resolve itself in the next 2-4 hours. --Ahecht (TALK
PAGE
) 14:41, 17 April 2024 (UTC)[reply]
Thanks! Aha, I didn't find this because T362732 "enwiki_p database replica has stopped updating" doesn't match the search string "replication lag".
I was pinged to the #pagelinks normalization discussion, but that discussion did not warn me that the process of "normalizing" pagelinks would temporarily abnormalize database replication. – wbm1058 (talk) 15:03, 17 April 2024 (UTC)[reply]
"normalize" in this context refers to database normalization. * Pppery * it has begun... 15:08, 17 April 2024 (UTC)[reply]
Lag is now 12 hours and rising again. Certes (talk) 10:32, 22 April 2024 (UTC)[reply]
I noticed that too. Also discussed above at #AFD Stats not updating grid templates.
"FWIW, this is a data corruption issue. Last time it happened on sanitarium hosts the whole system went down for a week. I'm trying to figure out if I can avoid re-cloning the whole host (which would take a lot of time, potentially weeks) and only reclone the corrupted table but there is no easy way to do this AFAICS." wbm1058 (talk) 10:51, 22 April 2024 (UTC)[reply]
maybe resolved at ~16 UTC. see
talk) 15:26, 22 April 2024 (UTC)[reply
]

"Reviewed an image suggestion" user log entry

Does anyone know what "reviewed an image suggestion" means and its use? See this user's log for an example. S0091 (talk) 20:35, 17 April 2024 (UTC)[reply]

This appears to be coming from the Android app. I can't find the option to try it out, even in the Alpha version, but at first glance this seems to be a privacy violation. We've never publicly logged pages that people were just viewing (or previewing an edit for) but decided not to edit. Is it being disclosed, up front and clearly, that the choice not to edit will be visible to the whole world? Suffusion of Yellow (talk) 21:03, 17 April 2024 (UTC)[reply]
@DBrant (WMF): How can I try out this feature? All I see under "suggested edits" is "Article descriptions", "Image captions", and "Image tags". And is my assumption correct, that we are logging when someone decides not to edit a page? If so, are they told that their username, along with the page they were viewing, is being publicly logged? Suffusion of Yellow (talk) 21:36, 17 April 2024 (UTC)[reply]
Alright, for some reason it doesn't work for me on the enwiki or testwiki, but I found it on the desktop site at es:Special:Homepage. I was told that Your answers improve future suggestions. but for all I would know, that just means I'm training an AI or something. There was no indication that by clicking "Submit", this log entry would be created, and my name would be publicly recorded. This feature needs to be disabled. Suffusion of Yellow (talk) 23:08, 17 April 2024 (UTC)[reply]
  • This is a "growthexperiment" log type. Pings to @Trizek (WMF) and KStoller-WMF: who can hopefully point to the documentation. Notably, @Suffusion of Yellow: this doesn't say it is about "viewing" but about "reviewing" so I'm assuming there was an affirmative user action performed here other than reading. — xaosflux Talk 00:07, 18 April 2024 (UTC)[reply]
    You're asked if an AI-selected image should be in an article. If you click "Yes", you're given an opportunity to add it. If you click "No", you're asked why, but not told that your "No" is going to be made public. This is equivalent to logging every time someone previews an edit, and then abandons it. Suffusion of Yellow (talk) 00:17, 18 April 2024 (UTC)[reply]
    I think that is a bit of a stretch. Patrolling essentially is similar in nature and we don't warn from the interface that those actions are publicly logged either. I do see however that the barrier to entry is significantly lower here, so some additional caution might indeed be warranted. —TheDJ (talkcontribs) 08:28, 18 April 2024 (UTC)[reply]
    Thanks for the ping! The Android app is indeed using the same underlying API as the Growth team, but their implementation is a little different: Android/Image_Recommendations I'll follow up with that team and ask them to review this discussion. Thanks, - KStoller-WMF (talk) 16:51, 18 April 2024 (UTC)[reply]
Hi @S0091@Suffusion of Yellow@TheDJ and @Xaosflux,
@DBrant (WMF) is under the weather, I think I've coordinated with each of you before at some point, but I am Jaz the PM for the apps.
"Reviewed an image suggestion" means that someone determined that an Machine suggested image for an article is either adequate for an article, and the subsequently adds that image OR the image is not adequate (rejected). The reason it is important to track is so that we can remove bad recommendations from the stack that we share with the Growth experiments. Do we need to publicly log this information? Probably not, I am investigating why we are showing rejecting a suggestion publicly, if there isn't a super compelling reason, I will ensure we suppress the public log but still send the API call that is necessary for the feature.
As far as accessing the feature, you'll need to be:
  • Logged In
  • Set your app primary language as one where you have more than 50 unreverted edits
If you follow these steps and are still unable to see the feature, would you kindly file a task and screen record the steps you are taken, because that would be a bug. The feature is available in both the Beta version of the app and the production version.
The requirement of having over 50 unreverted edits for the language wiki you are using the feature in is the implementation difference that @KStoller-WMF. Under the hood and the flow of the feature is the same, however who has access to it is different. The Growth implementation is available to new editors on select wikis and we use the same API. New editors do not have access to this suggested edit task on the app.
The onboarding and guidance for the feature on Desktop is not the same as on Android. For example, on this screen we do let users know that their answers improve future suggestions.
Once DBrant is back in office (fingers crossed he's feeling better tomorrow) our team will update this thread about removing the rejection log. JTanner (WMF) (talk) 19:05, 18 April 2024 (UTC)[reply]
Thanks. I don't like putting using my main password on my phone, so I had used an alternate account with only a few edits. Honestly I spoke too quickly when I said "this feature needs to be disabled". So long as the messaging is changed to be more like MediaWiki:Thanks-confirmation2 ("Publicly send thanks?") I don't think the log needs to be removed. The problem with "Your answers improve future suggestions" is that it sounds like I'm training an AI ("select all squares containing Sarah Connor"), or taking an anonymous survey. Suffusion of Yellow (talk) 19:42, 18 April 2024 (UTC)[reply]
Thanks @Suffusion of Yellow this is helpful, digging into the code we were able to determine the rejection log is coming from the Growth Experiments API, which means the rejection log publishes for the Growth Experiment implementation as well. We are going to coordinate with them on next steps to see what makes sense regarding the public log. @ARamadan-WMF will follow up with the link to any phab tickets should they be created to make the rejection log private.
In the meantime, I've created task T362935 to update the copy in the UI for the app should the decision be to keep it public. I've subscribed you to it @Suffusion of Yellow, I welcome all of you to subscribe and comment on the proposed language change. JTanner (WMF) (talk) 20:37, 18 April 2024 (UTC)[reply]
Thanks @Suffusion of Yellow and the WMF team for digging into this! S0091 (talk) 15:52, 19 April 2024 (UTC)[reply]
Hello @S0091, @Suffusion of Yellow!
This is Amal Ramadan, I am Sr. Movment Communications Specialist supporting the Mobile Applications team; I wanted to provide you with an update: both the Growth and the Apps teams are going to discontinue publicly logging rejections. If you're interested in following the progress of this change, please subscribe to ticket T363002.
Thank you for initiating and engaging in this conversation.
--ARamadan-WMF (talk) 14:58, 23 April 2024 (UTC)[reply]
Hi @ARamadan-WMF another question. If they add a suggested image, the tag "#suggestededit-add-image-top" is included in the edit summary (example). Are both logging and tagging really needed? It seems like overkill (maybe?). If both are not needed, then I suggest using the edit summary as it is more transparent to editors than it being buried in logs. S0091 (talk) 18:26, 23 April 2024 (UTC)[reply]
Actually, we are aware of this, and actively working on making the change; the work progress on this can be found in this ticket T360164, I tried to sign you up, but couldn't find your account. You can follow to stay updated instead.
--ARamadan-WMF (talk) 08:52, 24 April 2024 (UTC)[reply]

I don't understand these edit summaries

that I've seen pop up recently, like the following:

#talk-full-source-editor and #talk-topic on Talk:Robert E. Lee.

They don't quite make sense to me and don't seem to be telling me anything useful about the edit. Anyone care to explain? Thanks, Shearonink (talk) 19:38, 18 April 2024 (UTC)[reply]

This seems to be more of phab:T361495. — xaosflux Talk 19:57, 18 April 2024 (UTC)[reply]
Oh interesting. So it's the Android and iOS apps appending these strings to the edit summaries? –Novem Linguae (talk) 05:37, 19 April 2024 (UTC)[reply]
The two examples provided by Shearonink can be found in the source code of the iOS app. —⁠andrybak (talk) 12:36, 20 April 2024 (UTC)[reply]

Could there be a stopgap solution for the Graph module until its replacement is developed?

It has been 1 year since Graphs were disabled due to security vulnerabilities in the extension. The update plan as of now is to completely replace the Graph extension, because the other solutions to upgrade it were found to not be feasible. This process has only just started to gather the members necessary and will not start in earnest until July, per the update posted. This extension will then obviously take time to develop. In the meantime, there's 18k articles, per Category:Pages with disabled graphs, with data that is completely inaccessible unless you view the page source. We could either put the data in a table so at least the data is there, in an expando if there are many rows. We could even have a link to an external graphing service that graphs it visually on a separate page (Quickchart.io being an example that works simply, simply putting the data in JSON format in the URL.). Thoughts? MarkiPoli (talk) 15:48, 19 April 2024 (UTC)[reply]

See relevant discussion, including a couple replies from WMF staff, at Wikipedia:Wikipedia Signpost/2024-03-29/Technology report and its talk page. —⁠andrybak (talk) 09:13, 21 April 2024 (UTC)[reply]
Also, the situation with the graphs is mentioned and discussed at the WMF section of the Village pump. —⁠andrybak (talk) 13:30, 21 April 2024 (UTC)[reply]

Help with phabricator ticket -- Unable to login on iPhone with Passkey Enabled

6 weeks ago I did a deep dive for 1-2 days helping to debug, reproduce, identify the root case and help formulate a fix for the following issue. [14] This issue affects any user using webauthn aka 2FA security tokens across wikimedia. @Reedy (WMF) was very responsive and back-ported a fix from another repository. The fix was committed March 5.

Could I ask your help getting more detail on what the next steps are to integrate and deploy the fix? Tonymetz 💬 20:20, 19 April 2024 (UTC)[reply]

cc: @Novem Linguae Tonymetz 💬 20:35, 19 April 2024 (UTC)[reply]

There's nothing anyone on the English Wikipedia can do about problem with webauthn directly. See Help:Two-factor_authentication#WebAuthn. I suggest no one use this method with any account they care about. There is now a ticket open, so some developers may eventually work on phab:T358771. If you want to personally work on this see: mw:How to become a MediaWiki hacker. — xaosflux Talk 21:01, 19 April 2024 (UTC)[reply]
my issue is more about getting help from WMF to deploy the fix that is ready to go. maybe this is better for village pump WMF Tonymetz 💬 21:08, 19 April 2024 (UTC)[reply]
Patches are primarily deployed by volunteer developers not "the WMF". There are currently over 70 tasks open for OATHAUTH alone, most of which are significantly older. This isn't anything specific to the English Wikipedia, so none of our noticeboards are the right venue. You could email the mailing list that has a team of volunteers that look over technical matters relating to MediaWiki software and interface - this team can be reached at mediawiki-l@lists.wikimedia.org. — xaosflux Talk 22:25, 19 April 2024 (UTC)[reply]

Agreed this is the wrong venue, but the fact that patches are as usual not getting reviewed in a timely fashion is ridiculous. * Pppery * it has begun... 21:25, 19 April 2024 (UTC)[reply]

Patches are primarily deployed by volunteer developers not "the WMF". It might be more accurate to say that patches are auto-deployed by the weekly train for most repos. And a combination of volunteers and wmf do both the patch writing and the patch approvals. What's needed here is a patch approval (+2). Which can be a lot of brain power, because it involves wrapping your head around the ticket and the code, reviewing the patch code, and loading up the patch code in a localhost environment and testing it. But sadly, many repos are backlogged or do not have active maintainers or do not have any wmf team currently assigned to them. –Novem Linguae (talk) 22:58, 19 April 2024 (UTC)[reply]
Is there more information on how to apply to be a maintainer? I had assumed we were blocked by WMF. I’m happy to help contribute as a maintainer if it would help. Tonymetz 💬 23:26, 19 April 2024 (UTC)[reply]
First, you'd need to write a bunch of patches in gerrit for the repo you want to apply for. Do you have a gerrit account yet? Then you'd also want to get the support of the existing maintainers. Seems like an existing maintainer is a little frustrated with you in the linked phab ticket, so would need to mend that. Finally, when those two things are looking good, you'd ask the community for +2 of that repo via a Phabricator ticket. Example.Novem Linguae (talk) 23:57, 19 April 2024 (UTC)[reply]
thanks for the guidance and the example that's helpful. i'll look into it. Tonymetz 💬 03:37, 20 April 2024 (UTC)[reply]

Cursor keeps teleporting to the very start of the box I'm editing whenever I press shift

Is there any way to make the cursor stop teleporting to the beginning of the line or paragraph if I press shift? Shadow311 (talk) 00:47, 20 April 2024 (UTC)[reply]

did you think that was enough information for anyone to know what box you're referring to? See
talk) 01:59, 20 April 2024 (UTC)[reply
]
At the same time, maybe the answers at Wikipedia:Village pump (technical)/Archive 208#When editing, pressing shift causes cursor to jumps to start of edit text box are helpful. – 143.208.238.228 (talk) 03:05, 20 April 2024 (UTC)[reply]
@
Jeremyb-phone, literally the box that you type in when you press reply. Shadow311 (talk) 17:08, 20 April 2024 (UTC)[reply
]
also thanks 143.208.238.228, that's what I was talking about. Shadow311 (talk) 17:14, 20 April 2024 (UTC)[reply]
Sounds like mw:Extension:DiscussionTools is the box you're using. According to the linked thread, turning off the GoogleTrans gadget may fix the issue. Can you go ahead and try turning off the GoogleTrans gadget via Special:Preferences and report back? –Novem Linguae (talk) 11:04, 22 April 2024 (UTC)[reply]
@Shadow311, if you didn't have the GoogleTrans gadget enabled, then it might be phab:T316838. Please ping me if that's the case.
If you do have GoogleTrans enabled, and you need to keep it enabled, then there's a chance that you could bypass this bug, in the Reply tool and New Topic tool only (e.g., not in the visual editor, which you don't seem to be using) by going to Special:Preferences#mw-prefsection-editing-discussion and turning off "Enable editing tools in source mode". You'd lose the whole toolbar, including the button to @ ping someone. WhatamIdoing (talk) 22:52, 22 April 2024 (UTC)[reply]

Lua error

i keep getting a Lua error everytime I try to put a picture, is there a way to solve this issue? thanks Cassopeia ...talk?... 18:37, 20 April 2024 (UTC)[reply]

First posted in Wikipedia:Teahouse#Lua error. --Redrose64 🌹 (talk) 19:10, 20 April 2024 (UTC)[reply]
Please always say which page or code a question is about. I guess it's about User:Penny(Cassopeia) where you used {{Portal image banner}}. Like many image-displaying templates, it takes raw file names as parameters and not image code: {{Portal image banner|Zinnia elegans with Bombus 01.JPG|...}}. PrimeHunter (talk) 19:24, 20 April 2024 (UTC)[reply]

Process template parameter in Lua before MediaWiki does its thing

Requesting pictorial, video or tutorial help

  • Request: To provide /update pictorial, video or tutorial help on how to use Template:Citation#Quote.
    • The policy regarding these types of quotes is briefly covered at
      WP:FOOTQUOTE
      .
  • Description: In the visual editor, under the 'cite' button, you first put in the basic parameters (sometimes just a URL is sufficient to get started), then scroll down the list of fields to find the one named 'Quote', which is a text box you can enter the quote into. (This is too verbose does not seem to save first time readers from confusion)
  • Why needed:
as a help in verification if needed

WP:VERIFY
states "..Readers must be able to check that any of the information within Wikipedia articles is not just made up. .."

When we refer to academic sources many times those are not easily accessible to readers / copy editors and also who wish to verify. Specially in contentious topic area providing original quote from the source remains easier for transparency and verification and saves a lot of misunderstanding, stress and time.
When some user urged me to provide quotes from sources it took me months to understand what that user was urging about and how to do that although it is very easily accessible in visual editor.
When I also urge other editors I find they are confused what I am requesting all about.
I do have strong perception that updating related help pages with pictorial, video or tutorial help can save lot of hassle.

Idk if this is the right place to seek help in this respect, if not then please guide me where to make this request.

Bookku (talk) 13:26, 21 April 2024 (UTC)[reply]

@Bookku, I think you need to read Wikipedia:Reliable sources/Cost. We are not required to make it easy to check sources.
Also, quotations are not sufficient. If an editor were willing to put false information in the article, then that editor could just as easily put false information in the quotation field of the template. WhatamIdoing (talk) 22:58, 22 April 2024 (UTC)[reply]
Thanks for introducing me to
WT:REFCHECK
after couple of months since presently I am going bit busy.
I had come with above request with a perception that User interface feature is already available and it is just a matter of improving 'How to manual'. Thanks anyways. Bookku (talk) 01:56, 24 April 2024 (UTC)[reply]

IP Information feature issue on the English Wikipedia on iPhones

When I click on an IP address's contributions and click on the IP information window, it shows The IP information could not be retrieved. even though it works on other wikis, such as the Simple English Wikipedia.

This issue can only affect users who use iPhones and not on computers, so is anybody who uses this beta feature experiencing this issue when using it on their iPhone (including me)? Codename Noreste 🤔 La Suma 03:34, 22 April 2024 (UTC)[reply]

Does the tool work on the Simple English Wikipedia when on your iPhone?
It personally works for me when using my android phone. Dreamy Jazz talk to me | my contributions 10:03, 22 April 2024 (UTC)[reply]
I don't have an iPhone, so I cannot personally test this. The tool displays the The IP information could not be retrieved. error on any kind of "generic" error, which doesn't have a defined message. This could suggest that the request has not been getting through to the servers. Dreamy Jazz talk to me | my contributions 10:06, 22 April 2024 (UTC)[reply]
Yes, it works on simplewiki on my iPhone. Codename Noreste 🤔 La Suma 16:08, 22 April 2024 (UTC)[reply]
Smells like an API error. Are you using a browser on your phone, or the official Wikipedia iOS app? Are you still getting the error right now? Is it one IP only (please share which one if you can), or all IPs you try? –Novem Linguae (talk) 11:00, 22 April 2024 (UTC)[reply]
I am using Safari, and this applies to all IP addresses. Codename Noreste 🤔 La Suma 16:05, 22 April 2024 (UTC)[reply]
Can you provide a screenshot so that we can see your skin, screen size, what page you're on, if you're logged in, and what IP you're trying to view? Also, does the problem go away in WP:SAFEMODE? –Novem Linguae (talk) 20:33, 22 April 2024 (UTC)[reply]

The screenshot is here. About the IP addresses, this do not matter since the error applies to every IP addresses' contribution pages, and for safemode, the issue still persists. Codename Noreste 🤔 La Suma 22:47, 22 April 2024 (UTC)[reply]

information Administrator note: SS removed per WIPTIG. — xaosflux Talk 10:16, 23 April 2024 (UTC)[reply]
@Xaosflux: Which guideline? "IP information" refers to "information obtained through this tool", so nothing covered by the guidelines is disclosed in the screenshot, no? Nardog (talk) 10:21, 23 April 2024 (UTC)[reply]
I second this. If this violates something, we should
WP:IAR here. It's just a screenshot of an error message. –Novem Linguae (talk) 10:22, 23 April 2024 (UTC)[reply
]
Oops, too many screens open, the screenshot with the successful results would have been the problem, but that is in phab not here. — xaosflux Talk 10:25, 23 April 2024 (UTC)[reply]
I've removed it in phab just in case. Should be all set. –Novem Linguae (talk) 10:30, 23 April 2024 (UTC)[reply]
Thanks. I've filed phab:T363118 for you to help get dev attention. They may be able to search server logs to help see what the bad API query is. Please reply to devs if they ask you questions there since they are the most likely to be able to debug this. –Novem Linguae (talk) 23:55, 22 April 2024 (UTC)[reply]
@
iCloud Private Relay? Suffusion of Yellow (talk) 00:07, 23 April 2024 (UTC)[reply
]
To your question, my answer is that I edit from the Safari browser in my iPhone and I don't have iCloud+, so iCloud Private Relay is not enabled for my iPhone. Codename Noreste 🤔 La Suma 00:21, 23 April 2024 (UTC)[reply]
I think SoY's question is if you get a block notice when you try to edit articles on this device. SoY suspects that you might be editing from a blocked IP range and wants to rule it out. –Novem Linguae (talk) 00:22, 23 April 2024 (UTC)[reply]
My other answer would be no, since I'm not currently hardblocked. Codename Noreste 🤔 La Suma 00:26, 23 April 2024 (UTC)[reply]
Someone else in the phab ticket was able to reproduce. Also on iphone and safari. –Novem Linguae (talk) 01:34, 23 April 2024 (UTC)[reply]

Edit summary search

I've been using the standard tool for edit summary search, https://sigma.toolforge.org/summary.py but unfortunately it's not working correctly. For example this search ("timesofindia.indiatimes") returns zero results, even though I made 2,344 edits (eg. Special:Diff/1220101115/1220148337). Are there other similar tools? -- GreenC 13:52, 22 April 2024 (UTC)[reply]

Cryptic 14:05, 22 April 2024 (UTC)[reply
]
Ok that explains it. Thanks. -- GreenC 19:58, 22 April 2024 (UTC)[reply]
@GreenC: You already reported the problem at User talk:Σ#Edit summary search. --Redrose64 🌹 (talk) 19:24, 22 April 2024 (UTC)[reply]

Integrating one template into another

I hope I'm posting this in the right place, I'm happy to repost elsewhere if it would be better. I want to integrate template:Party name with color into template:STV Election box candidate2. This has arisen in, for example, South (European Parliament constituency), where there's a microparty called The Irish People contesting. It's a non-notable organisation, but is registered, so has an entry on Module:Political party/T. It has a disambiguation to distinguish it from various newspapers collected under The Irish People. In tables that use template:Party name with color, its shortname is invoked. See, e.g., List of political parties in the Republic of Ireland#Parties with no elected representation. However, in the election results table at South (European Parliament constituency) or 2024 Kerry County Council election#Kenmare, the disambiguation is visible, because the STV candidate template only uses the shortname if the page actually exists. I think the best solution would be to invoke Party name with color itself in template:STV Election box candidate2, but I'm not sure how best to do that without breaking the code. Thanks for any insights! Iveagh Gardens (talk) 17:32, 22 April 2024 (UTC)[reply]

Would it solve the problem if the STV candidate template used the shortname in all cases? — Martin (MSGJ · talk) 20:24, 22 April 2024 (UTC)[reply]
I tried to do that with this edit, but ended up breaking the links in all cases. Could you see a means to include the shortname linked if there is an article, not linked if there is not? Iveagh Gardens (talk) 06:50, 23 April 2024 (UTC)[reply]
This should do it. I've put that in the sandbox so you can test it before deploying if you wish — Martin (MSGJ · talk) 08:07, 23 April 2024 (UTC)[reply]
Thanks Martin! Iveagh Gardens (talk) 16:34, 23 April 2024 (UTC)[reply]
I have redirected
The Irish People (party) to List of political parties in the Republic of Ireland#Parties with no elected representation. The existence of the page name appears to have solved the issue for this party. I don't know what is supposed to be listed at Module:Political party/T if a party has no page. The documentation doesn't even say that the page name should be given if there is a page, but I guess so based on examples. PrimeHunter (talk) 21:16, 22 April 2024 (UTC)[reply
]
Thanks, that does fix it, although I'm not sure the existence of a page is required. It can be useful for once-off microparties that have become defunct, as with Seniors Solidarity at 2009 Fingal County Council election, to have an entry there, without needing a page. In ten years, if The Irish People is no longer registered, it might not even warrant a redirect. Iveagh Gardens (talk) 06:48, 23 April 2024 (UTC)[reply]

Easier way to mark an edit as minor

The minor edit button is very small and not very mobile or laptop trackpad friendly. Its too bothersome for me to actually use it. I do mark these edits as minor in the edit summary with the letter "m". Leaving "m" in the edit summary should tag the edit as a minor edit. This would encourage use of the minor edit button for minor edits and help declutter the watchlist (for those that filter minor edits from their watchlists). How easy would this be to from a technical standpoint? Schierbecker (talk) 18:33, 22 April 2024 (UTC)[reply]

I can't help with the change you're proposing, but in case it helps, there are actually some more accessible ways to toggle the "minor edit" checkbox: you can click (or tap) its textual label as well, not just the box; or on a laptop, while writing the edit summary, you can press Tab and then Space to move to and toggle the checkbox. This works with all other checkboxes on Wikipedia too, and also in most other websites and apps. Matma Rex talk 21:10, 22 April 2024 (UTC)[reply]
Then there's Alt+⇧ Shift+I. --Redrose64 🌹 (talk) 22:02, 22 April 2024 (UTC)[reply]
Or you could just not use it. Using it is never required. WhatamIdoing (talk) 23:00, 22 April 2024 (UTC)[reply]
I'm rather inclined not to use edit summaries either! Just trust me, bro! Schierbecker (talk) 06:23, 23 April 2024 (UTC)[reply]
Ticking the minor button is a "just trust me" move. Just trust me: it's minor, and nobody with the default watchlist settings needs to pay any attention to this... WhatamIdoing (talk) 19:55, 24 April 2024 (UTC)[reply]

Tech News: 2024-17

MediaWiki message delivery 20:25, 22 April 2024 (UTC)[reply]

Is there a convenient functionality to merge/extend Lua arrays?

I know I could iterate over the second array and append the values at the end of the first array, but I thought "hang on, there must be a closed function/method like Python's list.extend defined somewhere"... Am I right?

ping me] 20:30, 22 April 2024 (UTC)[reply
]

Hahahahaha Lua is not batteries included. You are perhaps looking for Module:TableTools or Module:Set. Izno (talk) 21:54, 22 April 2024 (UTC)[reply]
I had checked Module:TableTools to no avail. I guess I could use the "union" functions from Module:Set, but that seems like overkill as those are not optimized for arrays. I think such simple function should be added to Module:TableTools. Ideally, it should actually be in the standard Scribuntu table library, alongside table.concat...
ping me] 22:26, 22 April 2024 (UTC)[reply
]
That's one of the functions in the Lua standard library, not added by Scribunto. Your other options besides the modules are 1) iterating over table 2 and table.inserting into table 1, or 2) doing it with indices. Izno (talk) 23:11, 22 April 2024 (UTC)[reply]
Well, I've proposed adding it to TableTools
ping me] 00:11, 23 April 2024 (UTC)[reply
]

Anyone know why this is happening?

This isn't really a problem, per se, but I'm just curious if anyone has a similar thing going on. When I go to Template talk:Did you know (and only there; I've tried this on other talk pages of templates as well and all of the other namespaces work fine), my toolbox on the left side of my screen (I use vector legacy dark mode) turns white. I tried switching to light mode, and nothing happens. Is anyone experiencing something similar?

DYKTemplateinVectorLegacyLightMode DYKTemplateinVectorLegacyDarkMode

The image on the left is my screen in light mode, and the image on the right is my screen in dark mode. Relativity ⚡️ 00:13, 23 April 2024 (UTC)[reply]

@Relativity: It's caused by importScript('User:Shubinator/DYKcheck.js') in User:Relativity/common.js. I haven't examined exactly why User:Shubinator/DYKcheck.js has this effect but it only affects users with both that script and dark mode so it's not important when the sidebar is still readable. PrimeHunter (talk) 01:49, 23 April 2024 (UTC)[reply]
@PrimeHunter Thank you. Wow, I never would have guessed. Relativity ⚡️ 23:25, 23 April 2024 (UTC)[reply]

History indexing

I got a revdel request for removal from page history of some relatively innocuous adolescent pranks from a couple of years ago. The requester is concerned that it could be found by search engines. I haven't been able to replicate it, and I seriously doubt that search engines care about history like that. In order to reassure the requester that they can quit worrying about it, can somebody clarify whether and to what extent article histories are or aren't indexed or considered by search engines? Acroterion (talk) 13:49, 23 April 2024 (UTC)[reply]

Nearly everything that starts with /w/ is disallowed to be indexed by search engines in our robots.txt (see what is robots.txt). E.g. google site:en.wikipedia.org inurl:/w/index.php. There could be theoretically ways to circumvent this, but I haven't found any Google results for old versions and diffs. Jack who built the house (talk) 14:07, 23 April 2024 (UTC)[reply]
Diffs and old revisions also have noindex in the HTML so Google and other compliant search engines will not index them if they come across them in other ways at Wikimedia sites. PrimeHunter (talk) 14:44, 23 April 2024 (UTC).[reply]
Thanks, that's what I thought. I'll reassure them, since their request really doesn't meet revdel criteria. It's the kind of silly thing I'd have done at 16 if we'd had an editable online encyclopedia. Acroterion (talk) 15:10, 23 April 2024 (UTC)[reply]

Early access to the dark mode (mobile web, logged-in)

Hi everyone, as announced in November, the Web team at the Wikimedia Foundation is working on dark (sometimes also called night) mode. Now, we have released the feature for logged-in users of advanced mobile mode across all wikis for testing purposes. But don't worry, the new feature is not disruptive! (See the "known limitations" section below.) It's just important for us to work together with you before we release this feature to a wider audience. Our goals for the early rollout are to:

  • Show what we've built very early. The earlier you are involved, the more your voices will be reflected in the final version
  • Get your help with flagging bugs, issues, and requests
  • Work with technical editors to adjust various templates and gadgets to the dark mode

Go to the project page and the FAQ page to see more information about the basics of this project.

Known limitations of the initial release

  • Currently, dark mode is only available on mobile, for logged-in users who have opted into advanced mode, as an opt-in feature.
  • Gadgets may initially not work well with dark mode and may have to be updated.
  • Our first goal is making dark mode work on articles. Special pages, talk pages, and other namespaces have not been updated to work in dark mode yet. We have temporarily disabled dark mode on some of these pages.

What we would like you to do (the broad community)

If you have questions - ask us! Also, where appropriate, consider linking to the Recommendations for dark mode compatibility on Wikimedia wikis. We would like to emphasize that the recommendations may evolve. For this reason, we are not suggesting to create your local wiki copies of recommendations. At some point, the copy could become different from the original version.

What we would like you to do (template editors, interface admins, technical editors)

When most bugs are solved, we'll be able to make the dark mode available for readers on both desktop and mobile. To make this happen, we need to work together with you on reporting and solving the problems.

  1. To turn it on, use the mobile website and go to the settings part of your menu and opt into advanced mode, if you haven't already. Then, set the color to dark. (Later, we will be allowing the device preferences to set dark mode automatically).
  2. Next, go to different articles and look for issues:
    • If you have noticed an issue with a template but do not know how to fix it
      1. Go to the recommendations page and find a relevant example
      2. If no relevant example is available or you're not sure of the fix, contact us
    • If you want to debug many templates in dark mode
      1. Go to https://night-mode-checker.wmcloud.org/ and identify templates that need to be fixed. The tool flags the top 100 most read articles.
      2. Go to the recommendations page and find a relevant example
      3. If no relevant example is available or you're not sure of the fix, contact us
    • If you want to identify problems beyond the top 100 articles.
      1. Install the WCAG color contrast browser extension (Chrome, Firefox) and visit some articles. Use it to identify problems
      2. Go to the recommendations page and find relevant examples
      3. If no relevant example is available or you're not sure of the fix, contact us
    • If you have a bug report for dark mode that is not related to templates
      1. Take a screenshot of what you are observing.
      2. Contact us. If possible, please write down your browser version and operating system version.

Thank you. We're looking forward to your opinions and comments! SGrabarczuk (WMF) (talk) 15:41, 23 April 2024 (UTC)[reply]

Why is USS Triton (SSRN-586) cascade-protected?

Resolved

USS Triton (SSRN-586) is currently showing as cascade-protected, claiming that it is transcluded on the main page and various related pages. While it is linked from Wikipedia:Main Page/Tomorrow, it does not appear to be transcluded anywhere (and pages that are just linked shouldn't be cascade-protected). Is this a known bug of some sort? :Jay8g [VTE] 00:25, 24 April 2024 (UTC)[reply]

Because {{USS}} -> Module:WPSHIPS utilities checks if the page it is linking to is a redirect, which registers as a transclusion. I would not call this a bug - every individual step is working as it should. * Pppery * it has begun... 00:30, 24 April 2024 (UTC)[reply]
It's not any more, that template was unnecessary in that blurb - I've replaced it with wikitext. — xaosflux Talk 00:41, 24 April 2024 (UTC)[reply]

Weird URLs

What causes or is the source of URLs like these? (left side of diff)

192 pages. Looks like a conspiracy of Google and VE but cdn.ampproject.org is involved somehow also. -- GreenC 02:21, 24 April 2024 (UTC)[reply]

It indicates that
MrOllie (talk) 02:29, 24 April 2024 (UTC)[reply
]
Google will sometimes prioritize amp links in mobile search results so I see them being passed around. At least it's easy to find the original URL. Skynxnex (talk) 02:35, 24 April 2024 (UTC)[reply]
Special:Diff/1220148479/1220489087 .. more garbage. 156 pages. 192+156 = 348 pages. I'll check with AWBREQ. -- GreenC 02:39, 24 April 2024 (UTC)[reply]
Someone had been making a bot for this, but it's been a while since their last update: Wikipedia:Bots/Requests for approval#DoggoBot 10. – 2804:F1...E7:923 (talk) 04:31, 24 April 2024 (UTC)[reply]
These query strings are for server-side tracking, usually they may be safely removed. I'm sure that I've seen a bot removing them. I don't think that VE can be blamed at all. --Redrose64 🌹 (talk) 16:52, 24 April 2024 (UTC)[reply]

What am I missing (translcudes redlink that doesn't appear in source text)

I was fixing a few issues on Narendra Modi and noticed that under "Pages transcluded onto the current version of this page" it has Deputy Leader of the House in Lok Sabha (what links here from the target shows the same thing[19]). But I can't find any mention of it in the source text. -- LCU ActivelyDisinterested «@» °∆t° 17:16, 24 April 2024 (UTC)[reply]

It's coming from the infobox for sure, even just this snippet causes that to occur:
{{Infobox officeholder
| office2             = [[Leader of the House in Lok Sabha|Leader of the House, Lok Sabha]]
| deputy2             = anything
}}
xaosflux Talk 18:11, 24 April 2024 (UTC)[reply]
Yeah it's building the link by adding 'Deputy' to the wikilinks. If you put Test in office2 it will try to use Deputy Test. But why does it appear as transcoded? Wikilinks aren't transcoding, and I can't see why it's happening in the infobox code. -- LCU ActivelyDisinterested «@» °∆t° 19:15, 24 April 2024 (UTC)[reply]
There are many layers there, it looks like this is coming from a nested template, that is then using a hack via {{Linkless exists}} to attempt to see if that page exists. In short, you can ignore it or develop an article for that title. — xaosflux Talk 19:47, 24 April 2024 (UTC)[reply]
Fair enough. -- LCU ActivelyDisinterested «@» °∆t° 19:49, 24 April 2024 (UTC)[reply]
It's in Template:Infobox officeholder/office, probably the line which transcludes {{Linkless exists}}.--Redrose64 🌹 (talk) 20:09, 24 April 2024 (UTC)[reply]

Implications of temporary accounts and
sensitive IP addresses

The blocking IP addresses essay was linked from WP:AN recently (for reasons unrelated) and it had me thinking:
How will temporary accounts affect the potential blocking of sensitive IP addresses (i.e. IPs assigned to major government organizations and also 'may be a good idea to notify the committee' IPs like major corporations or ones with technical implications like WMF/WEduF IPs)? To quote that essay, it currently says "If you block an IP address in any of the following ranges, you are required to immediately notify the Wikimedia Foundation Communications Committee."
Is the procedure here going to be that every admin is supposed to check the IP address of temporary accounts to see if it's sensitive when blocking? Or does it not matter too much?

... also, should I have made this in

WP:VPP?2804:F1...7D:5C91 (talk) 22:01, 24 April 2024 (UTC)[reply
]

These addresses are already affected by autoblocks, right? At first glance, I don't see how this would be any different. Suffusion of Yellow (talk) 22:06, 24 April 2024 (UTC)[reply]
Huh. Didn't pause to consider what was done currently with actual accounts using these IPs... right so it's one account per cookie, even if they use the exact same IP... so that means, blocking a temporary account would only affect that device (until their cache was cleared) and autoblock the IP(IPs?) used (I'm not actually sure how long autoblocks keep autoblocking IPs for, but maybe that's intentional).
Not sure if that has public relations implications, I guess not. On that note, maybe if it turns out to be a problem to have temporary accounts (that will be mandatorily/automatically created on editing) using sensitive IPs being blocked then MediaWiki:Block-autoblock-exemptionlist could be used to mitigate that - looks like a lot of WMF/etc IPs are there already. – 2804:F1...7D:5C91 (talk) 22:26, 24 April 2024 (UTC)[reply]
I did not know that page existed. Thanks. Suffusion of Yellow (talk) 22:29, 24 April 2024 (UTC)[reply]
I didn't either, followed the #Shared and dynamic IP addresses section, through the autoblock problem link (the 'Disabling autoblocking' section). – 2804:F1...7D:5C91 (talk) 22:34, 24 April 2024 (UTC)[reply]
I am pretty sure you will only be able to range block temporary accounts by blocking their ranges. So you will still bump into the standard "are you blocking a sensitive range?" Izno (talk) 22:25, 24 April 2024 (UTC)[reply]
I'll stop replying so much, but: The explanatory essay currently says if you block an IP in the ranges you should inform the committee, not if you block the ranges. This is mostly echoed in the actual policy
WP:BP#IP address blocks
.
Though as SoY said, this would already happen with an account (and only a CU with reason to check would know), so maybe this is a non-problem. – 2804:F1...7D:5C91 (talk) 22:42, 24 April 2024 (UTC)[reply]
And the explanatory essay was also written two decades ago. We can adjust as necessary. This is pretty low down on the list of "how do we deal with temporary accounts when that hits us". Izno (talk) 00:42, 25 April 2024 (UTC)[reply]

Why isn't the auto-archive working on this article talk page

Someone please with more mental bandwidth than I have right now, take a look at Talk:Lucille Ball and fix it? Why isn't the bot creating and then archiving to a Page 2? (and when I try to use the archive code-thingy I have installed, Archive 1 instead of 2 comes up...) Thanks, Shearonink (talk) 22:04, 24 April 2024 (UTC)[reply]

The archiving is setup to to archive anything older than 30 days, with a max archive size of 100k, and leaving at least one thread on the talk page (so it doesn't appear blank). There been nothing to archive since April 2022, and the current archive is still smaller than 100k so there's no need for a second archive yet. -- LCU ActivelyDisinterested «@» °∆t° 22:45, 24 April 2024 (UTC)[reply]
Ah ok...I was mis-reading the "page size" stuff then - my bad. Thanks, Shearonink (talk) 02:14, 25 April 2024 (UTC)[reply]

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

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

Do all bots not handle edit conflicts?

Diffs: <archive>, <ANI>. The bot claims it archived 5 sections, and it did do that, but it removed 6 sections (one that had just been created). The post was recreated by the author, so there's no active problem - but is that a problem that happens with bots, or just this one? Or is this just a 'once in a blue moon' event? – 2804:F14:8092:9F01:61D4:EA42:137D:5C91 (talk) 02:58, 25 April 2024 (UTC)[reply]

Bots can detect edit conflicts, by setting baserevid or basetimestamp, see the API documentation. But if a bot only takes a fraction of a second between loading the base revision and making the edit, they can probably "get away" with not doing this before anyone notices a problem; what are the chances of an edit slipping in the gap? That edit was nine seconds after the previous one, so perhaps something was slowing down the bot. Suffusion of Yellow (talk) 03:33, 25 April 2024 (UTC)[reply]
I filtered the contributions of the bot a bit, for the last 50000 edits or so (I lost count, it was 5000 contribs at a time), found 4 other instances:
- 00:00, 18 April 2024: ANI, archive
- 12:00, 9 April 2024: ANI, archive
- 00:01, 4 April 2024: ANI, archive
- 17:10, 10 February 2024: [MediaWiki talk:Watchlist-messages], [archive]
So not that many, but it does happen. Hm. I don't know what to do with this information, but thanks for answering. – 2804:F1...7D:5C91 (talk) 04:31, 25 April 2024 (UTC)[reply]

Proposals

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

Notes

  1. ^ This arguably eliminates the need for the broader language of "general sanctions", which encompasses CTOP and DS, since everything will just be CTOPs.


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

Background

In late 2022/early 2023, the

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:AE
    .
  • Reconsideration of contentious topic restrictions would be done at
    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)

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I think you know what I mean :)
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)[reply
]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    (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)[reply]

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

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

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

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

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

Could well be :) Selfstudier (talk) 10:27, 9 March 2024 (UTC)[reply]
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)[reply]
@Darkfrog24 The question is really just about making community sanctions use the new contentious topics procedure. Awesome Aasim 23:45, 17 March 2024 (UTC)[reply]
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)[reply]
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)[reply]
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 WordsmithTalk to me 19:54, 18 March 2024 (UTC)[reply]
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)[reply]
Again, not all community sanctions, but community-authorized discretionary sanctions. isaacl (talk) 01:36, 18 March 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

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

Create an alias for the Template namespace

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

  • 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)[reply]
    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)[reply]
    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)[reply
    ]
    Well said. — Frostly (talk) 06:28, 5 April 2024 (UTC)[reply]
  • 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)[reply]
  • Support per Schazjmd.
    🌺 Cremastra (talk) 15:57, 16 March 2024 (UTC)[reply
    ]
  • 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)[reply]
  • Support: Pretty nice QOL change. Per Schazjmd. ARandomName123 (talk)Ping me! 16:35, 16 March 2024 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    For reference, the script seems to be User:Ahecht/Scripts/TemplateSearch. jlwoodwa (talk) 04:53, 18 March 2024 (UTC)[reply]
  • "tp" seems very easily misconstrued as "Talk Page" at a glance. CMD (talk) 18:12, 16 March 2024 (UTC)[reply]
    Good point. Sdkbtalk 18:22, 16 March 2024 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply
    ]
  • The template for linking a template is called {{
    Phil Bridger (talk) 21:16, 16 March 2024 (UTC)[reply
    ]
    @
    Phil Bridger tl is ISO639 for tagalog. — xaosflux Talk 22:20, 16 March 2024 (UTC)[reply
    ]
    {{
    el doesn't have anything to do with templates qua templates. jlwoodwa (talk) 04:31, 18 March 2024 (UTC)[reply
    ]
  • 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)[reply
    ]
  • 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)[reply]
  • 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)[reply]
  • Rename the template mainspace from "Template:" to "Plantilla:" and use "Pl:" as a shortcut CactiStaccingCrane (talk) 18:02, 18 March 2024 (UTC)[reply]
    That would be quite a big change, but I'm not against it lol Cocobb8 (💬 talk • ✏️ contribs) 19:50, 18 March 2024 (UTC)[reply]
    But this is in español ROTFL -- ZandDev 13:45, 20 March 2024 (UTC)[reply]
    Yeah there's no way we'll get consensus on that one Cocobb8 (💬 talk • ✏️ contribs) 13:46, 20 March 2024 (UTC)[reply]
    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)[reply]
  • 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)[reply]
    @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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    @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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose. Unnecessary, and just as with T=Talk, TP=Talk Page. wjematherplease leave a message... 08:01, 21 March 2024 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose per above. Not intuitive and I'm not convinced this solves a genuine problem -Fastily 21:26, 24 March 2024 (UTC)[reply]
  • Strong support because I have typed "Twmplate" in the search bar too many goddamn times. Mach61 21:03, 26 March 2024 (UTC)[reply]
  • 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 (talkcontribs) 01:34, 28 March 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
  • Support any shortcut except just T. Aaron Liu (talk) 02:00, 30 March 2024 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support. Aliasing {{ is less preferable to me because a shortcut would also allow shortening template links in edit summaries, where {{
    Nickps (talk) 12:46, 8 April 2024 (UTC)[reply
    ]
    Think about the possibility of [[{{example}}]] Aaron Liu (talk) 15:11, 8 April 2024 (UTC)[reply]
    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 {{
    Nickps (talk) 16:21, 8 April 2024 (UTC)[reply
    ]
    @
    Nickps It's already impossible to start a title with a bracket, see [20] Mach61 12:25, 9 April 2024 (UTC)[reply
    ]
    I'm aware. That doesn't mean there aren't topics whose
    Nickps (talk) 12:57, 9 April 2024 (UTC)[reply
    ]
  • 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)[reply]
    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)[reply]
    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 (39) as much. My question is: Why NOT do this? Where's the significant downside? ―Mandruss  19:27, 9 April 2024 (UTC)[reply]
    I think Redrose thought that you meant actually manually going to the /doc subpage. Aaron Liu (talk) 20:23, 9 April 2024 (UTC)[reply]
    Yeah, I know. Hence my attempt at clarification. ―Mandruss  20:31, 9 April 2024 (UTC)[reply]
    @Mandruss: I highly recommend User:Ahecht/Scripts/TemplateSearch. jlwoodwa (talk) 04:05, 10 April 2024 (UTC)[reply]
    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)[reply]
  • 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)[reply]
    omg I thought I had something really wrong with my fingers for always spelling tempalte Aaron Liu (talk) 11:35, 11 April 2024 (UTC)[reply]
  • 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)[reply
    ]

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

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

Notifications. ―Mandruss  23:25, 9 April 2024 (UTC)[reply]

Notification of all participants to date, regardless of the nature of participation; you commented, you get notified. @

Phil Bridger, Pppery, Redrose64, Schazjmd, Slacker13, Usedtobecool, Wjemather, Xaosflux, and ZandDev: ―Mandruss  23:13, 9 April 2024 (UTC)[reply
]

Off-topic about namespace aliases for other things. ―Mandruss  05:13, 11 April 2024 (UTC)[reply]
  • 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)[reply]
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)[reply]
Note "tmt" is the ISO 639 code for Tasmate. Anomie 13:14, 11 April 2024 (UTC)[reply]
  • Comment: people realize that t: is the existing psudeo-namespace for templates, as seen at
    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)[reply
    ]
    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)[reply
    ]
  • 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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • Tm or Tl Both are close to the colon-key, which is always practical. Draken Bowser (talk) 15:51, 11 April 2024 (UTC)[reply]
    @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)[reply]
  • 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)[reply
    ]
    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)[reply]
    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)[reply]
  • First choice Tm, second choice T:
    PerfectSoundWhatever (t; c) 03:11, 13 April 2024 (UTC)[reply
    ]

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

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

Deprecating new unsourced articles

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.


After the events at Wikipedia:Requests for comment/Deletion of uncited articles and Wikipedia:WikiProject Unreferenced articles/Backlog drives/February 2024, I think there is broad community consensus to not take any policy action against old unsourced articles. However, there should be a process in order to take action against new unsourced articles, because currently there are still new articles that does not have sources attached to it (see the 2023/2024 category at Category:Articles without sources).

I propose that articles that are created after 1st April 2024 and does not have any inline sources to be eligible for

WP:PROD. Such a PROD can only be revoked after an addition of one inline, reliable, third-party source. That source does not need to completely establish the topic's notability (because that will be decided in AfD); its only job is to verify that this topic is not a hoax. CactiStaccingCrane (talk) 06:48, 17 March 2024 (UTC)[reply
]

If this proposal is accepted by the community, it would greatly streamline our efforts to cleanup uncited articles and prevent the growth of the cancerous Category:Articles without sources backlog. In the future, this "imaginary" deadline could be gradually push backwards to tackle older and older articles, until the backlog is fully cleared. CactiStaccingCrane (talk) 06:53, 17 March 2024 (UTC)[reply]
And if we think further in the future, such a process can also be used to tackle Category:Articles with unsourced statements as well. This would be a glorious sight to behold. CactiStaccingCrane (talk) 06:55, 17 March 2024 (UTC)[reply]
Support As I have already said, independent reliable sources are needed to established notability, so such sources should be made explicit by citing them in any new article. As Levivich says, an article with no sources is a blog. Hell, when I was blogging a few years ago, I always included a list of sources at the bottom of a post, so that readers could read more about the subject, if they wanted to. Not providing sources when an article is created is just being rude to other editors who are somehow expected to do the work sourcing the article that the creator could not be bothered with. Donald Albury 20:26, 21 March 2024 (UTC)[reply]

I envision that there will be three things that needs to be done before this proposal can be enforced:

  1. Make a new template similar to {{Proposed deletion}} for this proposal
  2. Communicate to new editors that articles on Wikipedia must have reliable sources cited, and it is strongly encouraged that they find reliable sources before writing the article
  3. A way to tackle editor disputes about what constitutes "third-party" and "reliable".

- CactiStaccingCrane (talk) 07:07, 17 March 2024 (UTC)[reply]

Number two is extremely difficult. Anyone who knows English could be a new editor. There are many hundreds of millions of them.
Phil Bridger (talk) 10:49, 17 March 2024 (UTC)[reply
]
Number 3 is pretty easy, though.
Wikipedia:Third-party sources has been around for years, and we're pretty good at identifying them. WhatamIdoing (talk) 20:43, 24 March 2024 (UTC)[reply
]
We should also find ways to retain new editors if this proposal is enforced, because that would set an even higher barrier for entry for new editors to Wikipedia. This is the reason I why invited
WP:Wikiproject Editor Retention to this topic. CactiStaccingCrane (talk) 07:12, 17 March 2024 (UTC)[reply
]
Do you mean
deprecate? Johnuniq (talk) 07:16, 17 March 2024 (UTC)[reply
]
As in discouraging. It would be bad if we start to vandalize new articles in order to
depreciate them though :) CactiStaccingCrane (talk) 07:19, 17 March 2024 (UTC)[reply
]
New editors are already forced to go through
WP:AfC, which is not going to approve an unsourced article. --Ahecht (TALK
PAGE
) 13:39, 17 March 2024 (UTC)[reply
]
If you think the new editor article-writing experience is so demoralizing, maybe we should just not let new editors create articles in the first place? 2603:8001:4542:28FB:E9B3:2893:5C25:E68F (talk) 07:28, 17 March 2024 (UTC) (Send talk messages here)[reply]
No. We already have the WP:Article wizard to aid completely new editors to create a new article. I think that the wizard should be shown more prominently in "Wikipedia does not have an article with this exact name" notification box, as well as making {{AfC submission/draft}} and {{AfC submission/declined}} easier to understand for new editors. But we need new editors and we MUST NOT make Wikipedia harder for newcomers to contribute. CactiStaccingCrane (talk) 07:33, 17 March 2024 (UTC)[reply]
The fundamental problem for newcomers is that editing Wikipedia is not convenient. It takes a substantial effort to do so. So, one way to make this easier is to improve on the article wizard and ask people to find a few sources before citing them. I imagine that the new article wizard would ask you for URLs/book titles (and pages), and once you create a draft it would show you how to expand these fragments of info into fully-fledged "wikipedia-compliant" citations. CactiStaccingCrane (talk) 08:04, 17 March 2024 (UTC)[reply]
Sorry for the horrendous MS Paint drawing, but this is what I envision it to be like this:
CactiStaccingCrane (talk) 08:13, 17 March 2024 (UTC)[reply]
All of the objections raised to the two similar proposals in the last few months still apply. I really can't be bothered to repeat them again. We're supposed to be building an encyclopedia here. Clearing a backlog is only incidental to this.
Phil Bridger (talk) 08:52, 17 March 2024 (UTC)[reply
]
I like this idea in theory, but will only support it once tools and wording changes for newcomers are instated. The risk of this detracting newcomers is high enough that I think the community should have a consensus that the new wording/templates etc. alleviate harm, and they should be ready to go before any changes are made. ― novov (t c) 09:52, 17 March 2024 (UTC)[reply]
I agree with this. CactiStaccingCrane (talk) 11:27, 17 March 2024 (UTC)[reply]
  • Support per all the arguments I've made before.
    🌺 Cremastra (talk) 12:47, 17 March 2024 (UTC)[reply
    ]
Rather than a PROD, we should really just move new unsourced articles to draft. Lee Vilenski (talkcontribs) 12:56, 17 March 2024 (UTC)[reply]
This again? While
consensus can change, it seems unlikely that consensus will have changed in the month since Wikipedia:Requests for comment/Deletion of uncited articles was rejected. Let's not make this another topic area where people keep pushing essentially the same proposal with slightly different wording until, through tendentiousness and exhaustion, they manage to get something in (and then ratchet and repeat). Anomie 13:38, 17 March 2024 (UTC)[reply
]
This would be a massive change to our inclusion standards. It needs to be properly thought through. – Joe (talk) 07:49, 19 March 2024 (UTC)[reply]
Joe Roe, I think all of these concerns are very valid and thus this proposal is not complete. Should I move this to the idea lab? CactiStaccingCrane (talk) 09:59, 19 March 2024 (UTC)[reply]
Maybe not this specific discussion, which is already quite long. If you want to develop this idea further, I'd suggest going back to basics and asking what encyclopaedic purpose a mandatory citation for each new article would serve (i.e. beyond just removing it from Category:Articles lacking sources). – Joe (talk) 11:29, 19 March 2024 (UTC)[reply]
I wish that the opposers would detail more about what this proposal is missing rather than just regurgitating talking points. CactiStaccingCrane (talk) 17:15, 22 March 2024 (UTC)[reply]
Joe, a third-party source is defined in
Wikipedia:Secondary does not mean secondhand. WhatamIdoing (talk) 20:46, 24 March 2024 (UTC)[reply
]
I'm saying that the potential for confusion is there, not that I'm personally confused. – Joe (talk) 10:05, 10 April 2024 (UTC)[reply]
  • Oppose There is already a process that works (draftification through NPP), there is no need to complicate that. Curbon7 (talk) 09:27, 19 March 2024 (UTC)[reply]
  • Oppose - here are, at time of writing, the latest uncited articles created today which under this proposal would be prodded:
    Henry VI's Conquest of Sicily. I'm not seeing those articles as any more problematic than other similar unsourced articles. I think it is better that we make a judgement about which articles we delete rather than simply sweep away everything that meets a broad criteria. SilkTork (talk) 15:00, 19 March 2024 (UTC)[reply
    ]
    Lake Rabon (South Carolina) is the only article here that currently does not have one inline citation and that should change now. CactiStaccingCrane (talk) 17:17, 22 March 2024 (UTC)[reply
    ]
    So our current system works, no? None of the articles have been prodded, but those which were problematic have been moved to Draft space as appropriate. Some of those may be moved back into main space after they have been worked on. Better to go to Draft than to be deleted. SilkTork (talk) 17:42, 22 March 2024 (UTC)[reply]
  • Oppose. First of all, as one of the patrollers, the flowchart of NPP clearly state that unsourced articles have to be draftified, not PROD-ed. PROD only applies to BLP articles that are unsourced, not other articles. If this is implemented, the procedure of NPP will have to be changed as well which requires further discussion before it can be implemented. We have to also consider
    WP:NEXIST - where the notability is based on the availability of sources, not the current state of the article where it may or may not be sourced. Finally, I think there is no need for this. Sending them to draft is enough for them to fix the article, or if they didn't want to fix it, it will be deleted anyway. ✠ SunDawn ✠ (contact) 16:57, 19 March 2024 (UTC)[reply
    ]
    That's a good point. CactiStaccingCrane (talk) 17:21, 22 March 2024 (UTC)[reply]
  • Support. The first edit to any new page should contain at least one source. One source is the minimum we should require for any page in mainspace. One source is the minimum we should require from anyone creating a new page in mainspace. One source is the minimum required to show that an edit or an article meets
    WP:NOR, our core content policies. One source is not too much to ask. And for this reason, there is little reason to save an unsourced draft. Without a source, a Wikipedia article is meaningless. Levivich (talk) 17:12, 19 March 2024 (UTC)[reply
    ]
    Isn't the reason to draftify an article exactly so that it can be brought up to mainspace standards before living in mainspace? Zerotalk 05:12, 20 March 2024 (UTC)[reply]
    A draft with no sources is useless, it doesn't help anyone start an article, because you need at least one source in order to summarize sources. Also, while a petty concern, the editor who started an unsourced draft shouldn't get article creation credit. The first step of writing an article is to gather sources; people who write stuff off the top of their head are just blogging, not writing a Wikipedia article. Levivich (talk) 15:37, 21 March 2024 (UTC)[reply]
    Just because sources are not explicitly listed does not mean they weren't used when writing the page. Thryduulf (talk) 15:43, 21 March 2024 (UTC)[reply]
    It doesn't matter if they were used or not, if the sources are not listed in the draft, the draft is not helpful to anyone else. Levivich (talk) 15:57, 21 March 2024 (UTC)[reply]
    Firstly that is irrelevant, secondly it's not true. If someone has written an article about a topic but not included sources then another editor can find sources to verify the claims in the article without needing to know the claims (or even the topic) exist. There is no guarantee of course that such claims will present a comprehensive and neutral view of the topic, but that's true regardless of whether all, none or some of the claims are sourced. Thryduulf (talk) 16:01, 21 March 2024 (UTC)[reply]
    Irrelevant? You're the one who brought it up. I agree, it doesn't matter if sources were used or not used in the creation of an article, what's relevant is whether sources are listed in the article or not. If the sources aren't listed in the article, when second editor comes along in order to improve the unsourced article, the second editor has to start by looking at sources and coming up with a summary of those sources. Then the second editor can look at the unsourced draft and yeah, maybe the unsourced draft will magically be a perfect summary of the sources. This is, obviously, highly unlikely. At the very most, in this highly unlikely scenario, the unsourced article would have saved the second editor a bit of typing. But that time saved typing is cancelled out by the time spent reading the unsourced draft and comparing it to the source material to see if it matches. That's a waste of time. I would never read an unsourced draft -- it doesn't matter what the heck is written there if there is no source listed. I would just gather the sources and write my own summary, completely ignoring the unsourced draft. It's useless to an actual article writer.
    And why do some editors spend so much energy defending unsourced articles? FFS, this is Wikipedia, it's coming up on almost 25 years now. The first step in writing an article is to gather not one source, or two, but three high-quality, GNG-compliant sources. If you don't have that, you don't have a notable topic, you aren't verifying what you're writing, you're just blogging, not writing a summary of secondary sources. Writing off the top of one's head about a topic is not the same thing as summarizing sources. And if somebody's off-the-top-of-their-head blog happens to line up with an NPOV summary of high-quality RS, that's just like a freak coincidence, man. That is not what we should be striving for, or even tolerating, on Wikipedia. "But what if the bloggers happens to be right?" is an lol argument.
    If an editor happened to use sources in drafting the unsourced article and just forgot to put them in there, that's easily fixed. When the article is prodded, tagged for CSD, or AFD'd, the editor can add the sources. Heck, even after it's deleted, the editor can get it REFUNDed and add the sources.
    Much more likely, the unsourced article is unsourced because the author didn't summarize sources, they wrote off the top of their head. This is not worth saving, nor is it worth defending.
    Wikipedia articles are summaries of secondary sources. That's what they are, and if they don't summarize secondary sources, then they're not Wikipedia articles, even if they're hosted at wikipedia.org. The starting point for every article and every editor is sources. Anyone who starts anywhere else is doing it wrong.
    Someday, more Wikipedia editors will come to realize this, and eventually Wikipedia will actually as a matter of policy require sources for all statements in mainspace. It's rather an indictment of Wikipedia that this was not the first policy, and that it's still not policy almost 25 years later. Levivich (talk) 16:23, 21 March 2024 (UTC)[reply]
    I wasn't the one to bring this up, you brought it up in response to Zero. I'm not saying that it's not better to have sources in a draft (obviously it is), so most of your arguments are refuting something I'm not claiming. My only point here was that an unsourced draft can be helpful.
    You are entitled to your opinion about how other people's workflows for writing articles is "wrong", but unless and until there is a consensus to modify
    WP:AGF and other core policies you don't get to impose your opinion on the encyclopaedia. Thryduulf (talk) 17:40, 21 March 2024 (UTC)[reply
    ]
    What in the world am I doing that would be considered "imposing my opinion on the encyclopedia"? Comments like this is why I get frustrated discussing things with you. Nobody here is imposing anything on anyone, and this IS an RFC about modifying policy. This IS the right place to express the views I've expressed. Levivich (talk) 17:46, 21 March 2024 (UTC)[reply]
    BTW IMO it doesn't have to be an inline source; a general reference would be fine. Levivich (talk) 00:07, 11 April 2024 (UTC)[reply]
  • Oppose, because this creates a new type of deletion, which makes new page patrol and deletion workflows more complex. I believe that all new deletion proposals should work within our existing types of deletion. I think it would make more sense to expand the scope of BLPPROD, than to add a brand new NOSOURCESPROD that is in addition to the almost obsolete PROD (since folks always just unprod these and they end up at AFD) and BLPPROD. I will also note that many new page patrollers automatically draftify or BLPPROD articles without sources. –Novem Linguae (talk) 21:12, 19 March 2024 (UTC)[reply]
    almost obsolete PROD (since folks always just unprod these and they end up at AFD). Try looking at the evidence rather than repeating silly tropes.
    Phil Bridger (talk) 22:30, 19 March 2024 (UTC)[reply
    ]
    Hi @
    Phil Bridger. I don't think we've interacted before. It's nice to meet you. User:DumbBOT/ProdSummary appears to be a list of current prods. Got any reports that list the outcomes of prods, such as deprod vs delete? My point is that many prods are de-prodded, which then requires the patroller to follow up with an AFD. This is my anecdotal experience with using prod during NPP. Thanks. –Novem Linguae (talk) 23:10, 19 March 2024 (UTC)[reply
    ]
    Nice to meet you too. That link points to many articles where the PROD tag has been there for nearly a week and nobody has removed it, making your claim that that always happens false.
    Phil Bridger (talk) 14:35, 20 March 2024 (UTC)[reply
    ]
  • Oppose if a new article is sent for deletion solely because there are currently no sources, that's a bad rationale for deletion and a failure of
    b} 01:55, 20 March 2024 (UTC)[reply
    ]
    That is a good argument to get rid of
    WP:BEFORE too. The Banner talk 17:09, 21 March 2024 (UTC)[reply
    ]
    @Headbomb (or anyone else who's interested), do you feel the same way about the Wikipedia:Proposed deletion of biographies of living people policy? I think this proposal overreaches in requiring an Wikipedia:Inline citation to a reliable, third-party source, but I don't see why, in principle, a completely uncited new article about a BLP should be subject to deletion after a week's notice but an equally uncited new article about, say, a sports team or a business shouldn't be allowed to follow the same process. WhatamIdoing (talk) 20:35, 24 March 2024 (UTC)[reply]
  • Oppose. Articles on notable topics which would be worth having but don't yet meet mainspace standards (lack of sourcing is only one possible reason) should be draftified. That is a step towards eventually having a good article, while deletion is a step away; I think it is obvious which is better for the encyclopedia. Zerotalk 05:16, 20 March 2024 (UTC)[reply]
    PROD would force that article to be improved or to be moved to draftspace. And frankly, why is it so difficult to cite one source in an article about a notable topic? I don't get the opposers' reasoning here. If there is no source in an article, how could we know that this article is not a total fabrication? CactiStaccingCrane (talk) 17:08, 22 March 2024 (UTC)[reply]
    I am especially opposed to requiring "inline" sources. If there are sources but they aren't inline, that's a case for cleanup, not deletion. Deleting (rather than draftifying) an article only for that reason would be highly counterproductive. New editors often do not know our standards for how to present sources in articles and we should help them learn rather than telling them to fuck off. Zerotalk 02:31, 11 April 2024 (UTC)[reply]
  • Oppose as above, contradicts
    WP:NEXIST; unclear that this necessarily resolves a problem - as the February unreferenced backlog drive showed, even experienced Wikipedians were making mistakes and incorrectly sourcing articles. Regards, --Goldsztajn (talk) 11:00, 20 March 2024 (UTC)[reply
    ]
  • Oppose per other guidelines and many other opposers, that sources existing and existing notability is enough to not use an enhanced PROD process. I am not a very big fan of draft space (I think working in articles space where there's many eyes is often better if it seems notable. And user space or off wiki is better at the stage where notability is unclear or if someone wants to draft an article solo.). However, I could see supporting a properly crafted proposal that articles less than 90 days old and entirely unsourced when draftified with care (so maybe a very weak form of
    WP:BEFORE is done) cannot be moved back to article space without adding at least one source that has a credible claim of at minimum verifying the article. Skynxnex (talk) 15:08, 20 March 2024 (UTC)[reply
    ]
  • MILD SUPPORT I think that any articles without citations should either provide a source or be deleted.
    But there should be a ~month long period to provide sources before deletion occurs.
    Redacted II (talk) 17:51, 20 March 2024 (UTC)[reply]
  • Support I know this is not going to succeed, but ultimately only this approach is consistent with the widespread (and beneficial) practice of improving verifiability by removing unsourced content from articles—which can only be restored if there is a reliable source. (t · c) buidhe 05:00, 21 March 2024 (UTC)[reply]
    I think it's premature to predict the outcome. A straight vote count is running a bit under 40:60 against the proposal, but a number of objections (including my own) are to specific details (e.g., specifically requiring an inline citation instead of a
    general citation) rather than to the overall principle. WhatamIdoing (talk) 20:42, 24 March 2024 (UTC)[reply
    ]
  • Oppose; not sure there is much more to be said about why this would not be a great idea. I think this would go against the spirit of the project, and that it would be a very costly move in return for not much improvement. jp×g🗯️ 05:01, 21 March 2024 (UTC)[reply]
    This is not a "very costly move" as you have said, as multiple editors has pointed out that this is not that much different to how modern Wikipedia processes new unsourced articles. We just don't allow them to come to the mainspace. CactiStaccingCrane (talk) 17:05, 22 March 2024 (UTC)[reply]
    Draftification is done at the discretion of editors and new page patrollers, who like most Wikipedia editors are generally expected to have coherent reason for things that they do. Making it a binding policy would remove this discretion. Either way, it is not good: if it's meant to substantively change the way that article creation works on Wikipedia, it is for the worse, and if it isn't meant to substantively change anything, that is a great reason to avoid making giant disruptions in the public-facing process of a thing that has worked fine for the last 23 years. jp×g🗯️ 07:37, 23 March 2024 (UTC)[reply]
  • Support. I also see this as unlikely to succeed, but I'd prefer to see the project move into this direction. I think it would be an improvement to require that article creators include at least one source, and I do not see current procedure as sufficient to deal with the unsourced article problem. I can understand the objections based on grandfathering, but I would prefer the harms of temporary inequity over the harms of doing nothing. Firefangledfeathers (talk / contribs) 15:43, 21 March 2024 (UTC)[reply]
  • Support. I don't think the citation needs to be inline, but geez y'all, it's 2024, citations are expected in everyday culture now, anyone dumping an unsourced article into mainspace (without followup edits) nowadays is willfully ignoring our requirements and clearly has no plans to join the community. We don't need to protect these precious new editors, and we don't need to retain unsupported information that would be deleted if it was in any other format than a standalone page. JoelleJay (talk) 16:15, 21 March 2024 (UTC)[reply]
  • Support per Levivich. Ajpolino (talk) 19:36, 21 March 2024 (UTC)[reply]
  • Oppose. To be sure, a new, truly unsourced article is very likely to be hit by NPP for draftification, prod, or AFD (perhaps even when it really shouldn't). It's good practice to include at least some references. However, some editors take a narrow view of sourcing and consider implicit sources as "unsourced" when it really isn't (i.e. a newbie editor simply writing out "According to Joe Bloggs, blah blah blah..."). Secondly, the main case where valid "unsourced" articles exist are generally the frontiers that are good to create articles on for
    WP:CSB grounds. These are often translations of other language's wikipedia articles where there very well may be sources, but not ones easily consulted in English. Now, yes, other language Wikipedia editions have weaker notability requirements than enwiki, and yes, some of these are just authentically unsourced in the other language too. But this case is large enough that there will still be cases of plainly notable people who don't have articles yet, and deleting the articles out of misguided "consistency" doesn't make sense. Better to keep the article simple and non-controversial and wait on someone familiar with the foreign language sources, instead. Keeping this situation a valid option for creating an article means opposing the proposal. SnowFire (talk) 20:58, 21 March 2024 (UTC)[reply
    ]
    Do I feel comfortable to say that we tolerate unsourced articles because someday, somebody will magically put a citation into it? No. Without work from the WP:WikiProject Unreferenced articles, Category:Articles lacking sources backlog would now have >150k articles and will keep growing from here. Plus, by de facto standard, we already strongly recommended that new articles should have an inline citation. Why is it so difficult to codify that into policy? If you translate an article from a foreign language to English, then it is very trivial for them to copy the citations to the English version of the article or find one source that verify that this topic/subject actually exist. It's not that difficult. If you want new editors to understand the new PROD criteria, why not being more clear in the Article Wizard that Wikipedia articles need to have sources? And if my proposal sounds BITEy, then that's because the whole PROD/AfD process itself is BITEy. Please, if that's the reason why you opposed my proposal, please suggest changes to PROD and AfD instead. This is not my fault.
    You might ask, why do I demand an inline citation in my proposal? This is because an inline citation helps me to verify a specific statement in the article. If that reference is placed below, a reader would have no idea what is the specific statement that we are referring to. Just to mention this, most new editors nowadays don't start out editing in wikicode, they start out with VisualEditor. When they fire up VisualEditor for the first time there is an explicit instruction dialog hovering below the citation button that instructs you how to make an inline citation. It's really not that hard to do for a beginner. Even if VisualEditor somehow cannot process your URL, you can always type that citation in plain text.
    And why do I ask that citation must come from reliable source? Because we don't want people to write an article about a notable topic with absolutely shitty sources, like Twitter posts, gossip websites, forums, etc. If the whole article is talking about the
    WP:NEXIST
    , but why is it so hard to ask people just cite one of those excellent sources to the first sentence, to verify that this topic actually exists in real life?
    I'm just gonna sum up my proposal as follows. Missing content on Wikipedia is terrible. Having incorrect content masquerading as facts on Wikipedia is much, much worse. CactiStaccingCrane (talk) 17:00, 22 March 2024 (UTC)[reply]
  • Oppose. I would think that if one was going to go through the expense of yet another RFC on the same theme (the third within six months?), it would have at least been better thought out. As Joe Roe and others have highlighted, clearly it is not. Anyway, we should not introduce this new process, subtly different from existing ones yet also similar and overlapping in purpose. I hesitate to expand our assortment of procedural mechanisms for deletion or quasi-deletion, which is already confusing to editors. Adumbrativus (talk) 04:21, 22 March 2024 (UTC)[reply]
  • Oppose
    WP:AFDISNOTCLEANUP, and neither is PROD. InfiniteNexus (talk) 06:32, 22 March 2024 (UTC)[reply
    ]
    It is cleanup, in that a PROD indicates that "this article that does not have inline citations does not belong to Wikipedia". And it is not wrong to do so, because it corresponds to our current best practices. CactiStaccingCrane (talk) 11:05, 22 March 2024 (UTC)[reply]
  • Support There is no excuse for creating an unsourced article in 2024. Unsourced articles cannot be repaired by adding sources; they must be rewritten because without the sources we cannot tell if they are COPYVIO. Hawkeye7 (discuss) 08:20, 22 March 2024 (UTC)[reply]
  • Support. The bar needs to be raised. Stifle (talk) 11:42, 22 March 2024 (UTC)[reply]
    No, this particular bar should not be raised. The proposal is about new unsourced articles and suggests to delete them instead of draftifying as we currently do. This would make our problem of
    WP:BITEing newbies worse and give less feedback on how to write an acceptable article, without any change to the amount of unsourced content in mainspace. The backlog of unsourced articles is completely unconnected to the new articles that this proposal is about. —Kusma (talk) 14:10, 22 March 2024 (UTC)[reply
    ]
How/when would that happen? Due to the backlog due to a handful of active NPP'ers being asked to do too much of the million editors' work and otherwise being too difficult and painful, it won't even get looked at at NPP until after the draftifying time limit runs out. Not that I think that there are very many completely unsourced new articles. The pervasive problem is lack of GNG sources for articles that need those. North8000 (talk) 14:23, 22 March 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Template substitution counter

There is currently no way to track template substitutions without adding code to templates that adds tracking marks to the template's output, and some bot watching for these marks. Aside from all that overhead, these marks may make use of this mechanism impossible in some cases.

Tracking substitutions should be a comparatively simple modification to MediaWiki. When a template gets substitued, just increment the appropriate per-template counter, which could be accessed through a magic word. If you want to get fancy, you can add a list of the substitutions performed for this edit to its page history entry.

Having such a counter would be useful when a template is up for discussion, and to help gage when protection is appropriate. So, why not make a feature request? Paradoctor (talk) 03:02, 6 April 2024 (UTC)[reply]

Support - I can see the use of this when templates are rarely transcluded, but nearly always used by substitution. Cocobb8 (💬 talk • ✏️ contribs) 13:29, 6 April 2024 (UTC)[reply]
What would happen when a template is substituted in one edit, and that edit is subsequently reverted? --Redrose64 🌹 (talk) 13:37, 6 April 2024 (UTC)[reply]
Why should that be an issue? Paradoctor (talk) 13:41, 6 April 2024 (UTC)[reply]
Presumably nothing, if the intent is to understand how often a template is substituted (and thus how "important" a template is, and thus whether it should be protected/watched). That the resulting text was subsequently reverted doesn't change that the substitution happened.
It seems like a slightly useful feature to me.
The only thing I would question is whether we have any evidence of an actual problem that needs solving. I suspect most of the commonly substituted templates are well known, like {{
afd}}, and are already recognised as high risk. Barnards.tar.gz (talk) 12:42, 8 April 2024 (UTC)[reply
]
We have evidence that we don't know. That is the point here. Paradoctor (talk) 14:54, 8 April 2024 (UTC)[reply]
What I mean is that if the important templates were being vandalised, we would probably have noticed that. Barnards.tar.gz (talk) 18:56, 8 April 2024 (UTC)[reply]
Why make editors do guesswork when a machine will do the same far more accurately, for free? Paradoctor (talk) 02:55, 9 April 2024 (UTC)[reply]
I get it, that’s why I said it was slightly useful. It would be a good feature. Just a low priority one unless there’s a material problem that it would fix. Barnards.tar.gz (talk) 07:40, 9 April 2024 (UTC)[reply]
Why not using "What links here"? CactiStaccingCrane (talk) 12:19, 8 April 2024 (UTC)[reply]
I think what is being said here is that when the template is substituted, it isn't being linked or contacted in any way (because its content is being posted). Lee Vilenski (talkcontribs) 12:31, 8 April 2024 (UTC)[reply]
  • @
    feature request upstream for that. Feel free to do so, there are lots of ideas opened that way. — xaosflux Talk 14:39, 9 April 2024 (UTC)[reply
    ]
    why not make a feature request?[21] Sometimes I wonder why I bother to say anything at all. Paradoctor (talk) 15:56, 9 April 2024 (UTC)[reply]
    And? You are asking for reasons why you shouldn't go make a feature request? We didn't come up with any, so go right ahead. While this page's guidelines do ask for Software changes which have consensus should be filed at Phabricator. to be discussed here, what I called out is that this type of software change isn't the type that will require community consensus. It would have no impact on readers, and no direct impact on editors. — xaosflux Talk 23:53, 9 April 2024 (UTC)[reply]
    What's the mechanism by which page saves get run through edit filters? Presumably there is something being carried out there which is capable of evaluating whether a thing's been done or not -- I don't know, maybe it's impossible to detect if template text is being expanded or not, but it seems kind of simple to me. At the very least it shoudl be possible to detect if {{subst: is being added, right? jp×g🗯️ 18:40, 11 April 2024 (UTC)[reply]
  • Well, no bigbrain comments on how this fits into the mw db schema or anything, but one issue with this does jump out to me, which is that this seems like it would fail to reflect if the template were removed later. Like, if there is some template that's getting substed 80 times a day in 2024, then we decide it's inefficient and stop using it completely in 2025, wouldn't a {{TOTALSUBSTCOUNT}} in 2026 be kind of misleading? jp×g🗯️ 18:40, 11 April 2024 (UTC)[reply]
    You just gave me an idea. Let me get back to you tomorrow. Paradoctor (talk) 19:46, 11 April 2024 (UTC)[reply]
  • Is this something we really need to track? Personally, I hate our over-reliance on templates, and would be happy to deprecate all of them. Blueboar (talk) 18:54, 11 April 2024 (UTC)[reply]
    You mean, no templates at all? 🤯 Paradoctor (talk) 19:47, 11 April 2024 (UTC)[reply]

Wikipedia Sandbox

Not sure what happened here Wikipedia:Sandbox? May have been a talk about redoing layout adding tabs? Would have brought this up on its talk but iit is also a sandbox (where to talk about sandbox?).

To thw point..... Not only does it look very bad, but its an accessibility nightmare.

Tabs look horrible...2 tabs are using the strike parameter for those using the strike out usernames gadget...word "sandbox" is reapted over and over making tabs huge for no reason.

Main problem is the accessibility of the sandbox message that is a wall of text that is not clear as to what to click.start. Tabs cause whole page to have vertical scroll bar for some. Why so many sandboxes and some with odd space in naming i.e Wikipedia talk Sandbox? Why link Module:Sandbox that is template editor level protected? Looks messy and a bit overwhelming for new editors Moxy🍁 06:00, 12 April 2024 (UTC)[reply]

The tabs were added in this edit to
Template:Sandbox header by Awesome Aasim. – Joe (talk) 06:41, 12 April 2024 (UTC)[reply
]
I guess that is what
WP:BRD
is for.
I self reverted for now and we can discuss which tabs, if at all, are worth keeping. The perspective for a new user is that there should be a way to jump between the different sandboxes. If you want the tabs to read something else, well... {{sandbox heading/Tabs}}. Awesome Aasim 06:48, 12 April 2024 (UTC)[reply]
2 tabs are using the strike parameter for those using the strike out usernames gadget probably because User:Sandbox and User_talk:Sandbox are both user pages of a blocked demonstration account. It shouldn't be like that; maybe it should only be struck out, etc. in contributions and history pages and not on content pages. Hmm.... Awesome Aasim 06:53, 12 April 2024 (UTC)[reply]
Tangentially related, but I've made a request at
MOS:CONTRAST accessibility guidelines. hinnk (talk) 13:57, 16 April 2024 (UTC)[reply
]

Suicide hotlines

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

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

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

Technical issues aside, this feels a lot like
WP:RIGHTGREATWRONGS to me. * Pppery * it has begun... 23:29, 17 April 2024 (UTC)[reply
]
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)[reply]
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,
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)[reply
]
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)[reply]
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
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)[reply
]
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)[reply]
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)[reply
]
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)[reply]
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)[reply
]
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)[reply]
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)[reply]
The user's assumed country is available using Geo.country in javascript. the wub "?!" 08:55, 18 April 2024 (UTC)[reply]
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)[reply
]
I realise that this proposal is slightly different, but the comments that I made at
Phil Bridger (talk) 11:30, 18 April 2024 (UTC)[reply
]
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)[reply]
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)[reply
]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I’m confused by This is not displaying the US/Canadian line for everyone, it literally is displaying the number for everyone, no? If
WP:IAR or some similar exceptional policy. TheSpacebook (talk) 14:29, 18 April 2024 (UTC)[reply
]
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)[reply]
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)[reply]
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)[reply]
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)[reply
]
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)[reply]
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)[reply]
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)[reply]
@Masem there is meta:Mental health resources, curated by WMF. — xaosflux Talk 15:48, 21 April 2024 (UTC)[reply]

Tagging blocked socks

I have recently noticed that @

6 15:53, 18 April 2024 (UTC)[reply
]

Also pinging @
6 15:57, 18 April 2024 (UTC)[reply
]
How exactly do you mean, "help improve the encyclopedia"? -- zzuuzz (talk) 16:35, 18 April 2024 (UTC)[reply]
@
6 18:55, 18 April 2024 (UTC)[reply
]
So why propose this for just sock blocks if the intention is to save time on finding why a user was blocked? Not that I want it called out on the user page for everybody, but I'm just saying, why stop there if that's the goal? Hey man im josh (talk) 21:33, 18 April 2024 (UTC)[reply]
There's probably an appropriate amount of information on the talk page for that purpose. The global lock reasons also raise significant questions. These tags can sometimes be useful to help locate the correct SPI/LTA page for finding, reporting and actioning repeat customers where it's not entirely obvious (carefully balanced with WP:DENY), but for someone who just made a mistake it's overkill with little utility. Not only might it oversimplify a complex situation, it may even overcomplicate a simple situation. Whatever the case, I don't really see how the tags would really help with anything here. -- zzuuzz (talk) 23:29, 18 April 2024 (UTC)[reply]
Template documentation isn't policy and while non-admins/non-clerks are informally discouraged from tagging socks, in practice most will look the other way if the tagging is reasonable. But there are various situations where we will choose not to tag in the interests of
WP:DENY, discretion, or not oversimplifying a complex situation. I would not have tagged this account and I would suggest you find a more interesting thing to do on Wikipedia than applying tags to user pages. Spicy (talk) 16:54, 18 April 2024 (UTC)[reply
]
(edit conflict) Agreed; there are more productive things for editors to do than go around tagging blocked users' pages. Primefac (talk) 16:58, 18 April 2024 (UTC)[reply]
@
6 18:54, 18 April 2024 (UTC)[reply
]
Making a fuss about blocked users is not helpful. People who deal with socks are quite capable of tagging where they believe there is a benefit. There might be many reasons a particular page is not tagged and discussing details is a waste of time and the opposite of
WP:DENY. One example of why a sock might not be tagged is that we just want them to find another hobby and avoid righting-great-wrongs at Wikipedia. Johnuniq (talk) 23:30, 18 April 2024 (UTC)[reply
]

Thank you for all of your comments. I appreciate the feedback and will conform to these guidelines in the future.

6 19:06, 19 April 2024 (UTC)[reply
]

Allow all autoconfirmed users to move pages without leaving a redirect

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

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

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

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

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)[reply]
Some lists do have an image for every entry, e.g. List of London Underground stations. Thryduulf (talk) 08:36, 25 April 2024 (UTC)[reply]
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)[reply]
Each list is different.
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)[reply]
Non-free images can be used where
our fair use criteria apply. Paradoctor (talk) 09:06, 25 April 2024 (UTC)[reply
]

Idea lab

Onboarding for new users?

This was promted by a wikimedia-l thread

New users are given zero guidance and then get yelled at when the break the rules they didn't know about. Therefore, I propose that, after sign up, we make a page (perhaps something like

H:INTRO
?) that we then direct new signups to

Two questions I have:

  1. Will new users simply click away without learning anything?
  2. How much will this help?

As it stands, the current onboarding procedure is basically nothing: just set them out there and yell at them when they mess up. Something needs to change and I hope my proposal will generate some discussion on how to make the onboarding process better. NW1223<Howl at meMy hunts> 01:37, 7 March 2024 (UTC)[reply]

The current onboarding procedure is to use Wikipedia:Welcoming committee templates and new users also get a newcomer home (see Wikipedia:Growth Team features). I'm pretty sure automatically sending new users welcome templates is at Wikipedia:Perennial proposals. Aaron Liu (talk) 02:00, 7 March 2024 (UTC)[reply]
Wikipedia:Perennial proposals#Use a bot to welcome new users is probably what you were thinking of. Anomie 12:40, 7 March 2024 (UTC)[reply]
Aaron highlighted the Growth team features. To summarize them, new users get Special:Homepage as their base-camp (you might have to activate it in your preferences). There, they have access to selected help links and,
Some wikis also post a message at talk pages. From what I observe*, a successful welcome message requires the following:
  • it is a real message, not a block of links
  • it is clearly signed by a real human
  • it includes a clear indication "contact me if you have any question"
  • they are posted before the user make an edit (so that they can ask a question to the user who welcomed them**).
Messages consisting of blocks of links are not successful (a known issue), in particular when the message look like a banner or something else than a discussion. Signatures have to be clear, as the way we format our messages on wikis is not something the rest of the works is used to.
* Of course, what I observe is not a proof of anything, but I observe a lot of newcomers/experienced users at a lot of wikis since a long time. :)
** This is how Mentorship works: you get a name to contact at Special:Homepage (but unfortunately, at your wiki, not everyone gets one as we don't have enough mentors).
The discussion at wikimedia-l was more focused on explaining the rules while editing, which is also something the Wikimedia Foundation works on.
Trizek_(WMF) (talk) 15:09, 7 March 2024 (UTC)[reply]
Since so many recent changes have the "newcomer task" tag, I think it's enabled by default for newcomers. Aaron Liu (talk) 15:28, 7 March 2024 (UTC)[reply]
It is default for all new accounts, correct.
But Mentorship is only available to 50% of new users for the reasons I explained, and a key feature to discover editing, Add a link, is still missing at your wiki.
Trizek_(WMF) (talk) 16:48, 7 March 2024 (UTC)[reply]
or we could just not yell at them... It is my personal opinion that a lot of our users have themselves forgotten they are on wiki that anyone can edit. —TheDJ (talkcontribs) 21:48, 7 March 2024 (UTC)[reply]
I wish our policies had TL:DR versions of them too because some of them are very lengthy and I have no doubt that that's put some people off from editing here. JCW555 (talk)♠ 22:16, 7 March 2024 (UTC)[reply]
Most policies have {{nutshell}}, a summary, on top, and welcome templates already link many summaries, such as Help:Introduction and Help:Getting started. Aaron Liu (talk) 22:51, 7 March 2024 (UTC)[reply]
Although experienced editors do make mistakes from time to time, in my experience, the vast majority of new editors who get "yelled at" are spammers, self promoters, POV pushers, axe grinders, conspiracy theorists and others whose manifest goals are not in alignment with improving this great encyclopedia. As I see things every day on the firing line, any editor who comes here with a genuine intent to neutrally improve this encyclopedia is almost always welcomed with open arms. So, when an editor puts forward vague assertions of "yelled at", I expect diffs and specific cases. Who in particular got "yelled at", and why? Cullen328 (talk) 09:49, 9 March 2024 (UTC)[reply]
When I see an edit that degrades the encyclopedia, I revert it, and usually use Twinkle to leave a message on the user's page, with or without an additional comment. I think that kind of response is what some are calling "shouting". I will not leave unreverted an edit that damages the encyclopedia, no matter how well intentioned. I think the lowest levels of the Twinkle warnings are benign enough. I use the stronger versions of Twinkle warnings when a user repeats the same kind of edits after being warned. I block users who repeatedly over a short period of time make obviously problematic edits after being warned. It may be that new users don't see messages on their talk pages, but that is not a reason to allow them to continue to make edits that degrade the encyclopedia. Donald Albury 14:13, 9 March 2024 (UTC)[reply]
@Cullen328, how would you describe to an external observer how English Wikipedia welcomes good faith users with open arms? I'm asking it as finding how bad faith users are treated is easy (Donald gave a good example above), but examples of how one deals with good faith users is more difficult to find.
Actually, what I observed over the years is that vandalism or damageable edits get a warning message, while good faith edits are just left as they are, with no message, because they fit what is expected.
Thoughts? Trizek_(WMF) (talk) 15:18, 10 March 2024 (UTC)[reply]
Sometimes they get a thanks and they get a welcome if they're a new user. Aaron Liu (talk) 15:29, 10 March 2024 (UTC)[reply]
And {{cookies}}! Chaotıċ Enby (talk · contribs) 17:59, 10 March 2024 (UTC)[reply]
Yea, that makes sense, especially because then newcomers could fix the typod on articles, like (off-topic warning) how I fixed an typo on the article for WFSU-TV. The thanks option is actually pretty cool. mer764KCTV5 / Cospaw (He/Him | TalkContributions) 16:37, 13 April 2024 (UTC)[reply]
Help Desk where new editors can get assistance, and they are easy to find given the amount of traffic they get. I have over 10,000 edits to the Teahouse and over 1,200 to the Help Desk, so I have considerable experience helping and encouraging new editors. Many new editors come to my talk page asking for advice. and I have 5,600 edits there. I agree that bad edits and those that make them get more attention in general than good editors making uncontroversial typo fixes, converting bare URLs into bibliographic references, and reverting vandalism. If I notice particularly good work from a new editor, I will definitely thank them. I think that a brief, personalized compliment is better than 100 "welcome templates". The analogy that comes to mind is that few people give detailed thanks to people doing routine work. Few people go into a McDonald's and lavishly compliment the people sweeping the floors, taking the orders and packaging up the french fries. We just treat them politely, with a "thanks" to the order taker being about the extent of it. Cullen328 (talk) 20:09, 10 March 2024 (UTC)[reply
]
Phil Bridger (talk) 20:35, 10 March 2024 (UTC)[reply
]
@Aaron Liu, is "sometimes" good enough? :)
@Cullen328, thank you for the details. I think volunteer-me have the same profile as yours, but at my wiki. I don't really count places mike the Help desk or the Teahouse as proofs of being welcomed, as these are places you have to discover (or at least find the link to them). Thanks are apparently only for "particularly good" edits as you said. Messages are often perceived as costly to create. What would you (any of you) do to show a user that they edit is going in the right direction, at low cost?
@
Phil Bridger
, I'd say the bigger the wiki, the more likely it is to attract people. But as I read it quite often, I kind of think there is a perception of a mass of bad faith users that damage things, while only a few users do it right. I'm not sure this is true: maybe there is a perception bias, as badly behaving users are way more visible than users who do things the right way, don't you think?
Trizek_(WMF) (talk) 00:28, 15 March 2024 (UTC)[reply]
I meant that they sometimes get a thanks and nearly always eventually get a welcome. Aaron Liu (talk) 00:31, 15 March 2024 (UTC)[reply]

examples of how one deals with good faith users..

--Dustfreeworld (talk) 02:55, 19 March 2024 (UTC)[reply]
I'm assuming that, in this context, you're using "getting yelled at" not to mean overt incivility (which is against policy), but rather more subtle snubbing, e.g. ignoring messages or responding curtly. I honestly think that this encyclopedia could improve if this just didn't happen at all, regardless of the person. spintheer (talk) 03:43, 27 March 2024 (UTC)[reply]

Trizek (WMF), there used to be a bot called HostBot that would send welcoming Teahouse invitations to new accounts in good standing that had made 10 edits within a few days. Sadly, the bot operator, User:Jtmorgan, is far less active in recent years, and the bot no longer operates. Maybe you can look into that.

If you take a look at the Home Page, you will see that the first prominent word is "Welcome". The prominent phrase "anyone can edit" links to Help:Introduction to Wikipedia. There is a prominent link to Help:Contents on the Home Page, which links to many other help pages. Further down are links to the Community Portal, the Village Pump, the Teahouse, the Help Desk, the Reference Desks, and so on. In other words, the page that new editors first see shouts "Welcome! How can we help you?" I know about banner blindness but I doubt if it would make much difference if we displayed "WELCOME" in bold, bright orange all caps, flashing and flickering. It wouldn't help and it would make us look ridiculous.

Most new accounts do not ever edit. Of those that do, most of those make only a handful of edits and then lose interest. Of those that continue editing, a significant percentage have motivations incompatible with the goals of the project as I described above. Of those who really want to improve the encyclopedia, many are here to create or improve one or two articles about topics of great interest to that person, and then they stop editing. Student editors are here to get a good grade, and only a tiny percentage continue after the course is over. People go to edit-a-thons to satisfy their curiosity, meet cool people and get some free food. Only a tiny percentage keep editing.

I have been wondering for nearly 15 years what the positive psychosocial factors are that separate all those types of people who contribute little or no encyclopedic content from the "rare beasts" who make improving this encyclopedia in countless ways an avocation for many years. I cannot answer that question with confidence although I have my pet theories. I hope that the WMF could make that research happen but I do not know.

As an adminstrator, I believe that blocking bad actors like harassers, vandals, spammers and the like is essential, because showing such people the door makes the editing environment more hospitable. And so I am not ashamed to have blocked nearly 10,000 accounts. I think my work in that area makes Wikipedia a more welcoming place. I think I have said enough so I will stop now. Cullen328 (talk) 02:49, 15 March 2024 (UTC)[reply]

There's been some research on the psychological profile of Wikipedians. I am not sure you would consider the factors to be "positive", but if memory serves, we are above average for neuroticism and below average for agreeableness. In plain English: we start editing because there's a typo, we would rather be right and have an argument than go along with something that's wrong. We also don't like change. This all aligns with my experience. How about you? WhatamIdoing (talk) 01:53, 19 March 2024 (UTC)[reply]
I like change and demand a link to such a study immediately >:( Aaron Liu (talk) 02:05, 19 March 2024 (UTC)[reply]
@Cullen328, thank you for your detailed answer. You describe what I would call "passive welcoming": various signs, at various places that convey the idea of welcoming others. At the opposite, "active welcoming" goes more on the way of telling users personally that you can mentor them, thank users for their edits, etc. This is something you do, and I believe it is super important.
It tights to positive reinforcement: someone getting a positive stimulus on their edits are more likely to continue participating. If that positive discourse comes from a human, it has way more chances to be received and appreciated, compared to one coming from an information message on static page.
Following what @WhatamIdoing said or what @Dustfreeworld illustrated above, we, communities, are apparently very good at saying when something gets wrong. Worse, we are very good at qualifying one edit as not good even if just a part of it is not good. Reverting seems to be sometimes easier than fixing up an edit. And I'm not talking of vandals and trolls there: my focus is on users who genuinely came to fix something and saw "be bold" written at various places.
This topic started with the question of onboarding new users, but it is also on how to keep them editing. As we are in the ideas lab, I'm looking for your ideas: what would you (any of you) do to show a user that they edit is going in the right direction, at low cost? What do you miss to encourage users in an easy way?
Trizek_(WMF) (talk) 16:29, 19 March 2024 (UTC)[reply]
@Trizek (WMF), thanks for the ping :-) I’m not sure if I can give much useful comment about your questions, because I’m facing issues very similar to those described in the “How do we ... “ discussion myself as well… ...
My problem is, there’s a user who really doesn’t like me. It seems that my edits are being watched. When they think there’s an “opportunity”, they will suddenly “jump out”, sometimes just within minutes after my edit, nominate the article I edited for AFD, or have half of an article deleted, or criticise me on talk page and have the thread I opened being closed, or, directly yelling at me that “You’re sprouting ... “, etc. All within a short time / same day, like heart attacks. You can’t feel the stress/threats just from viewing the page history unless you’ve experienced them (and that can only be felt from those notifications popping up). And when I tried to restore the removed content, I faced 3RR and 2 warnings, all within minutes; followed immediately by very unpleasant “discussion”/criticism on the project’s talk page.
When I look up the warning templates pages [22][23], I can’t find the warning template that they used. There is no such (level 4) warning template which says “restoring good-faith content is disruptive” (not to mention those are sourced long-standing content not added by me). It seems that they have “tailor-made”/created their own version of warning message for me.
If I were a new user, I would have been threatened and left already. Definitely, with no doubt. I’m quite sure that they have done similar tricks (3RR + level 3/4 warnings) to other good-faith editors as well. (This differs greatly from most other editors do, like providing a detailed edit summary, just remove one or two sentences/sources at a time unless they are doing a rewrite, tagging it first, try fixing the problem first, discuss civilly on talk page first, and only remove outright contentious bad content like those involving BLPs, etc.)
But I can understand why other users may not notice that or can’t see the problem because one can’t feel the tension just from viewing the page history, or, they might not understand how bad I felt when I saw large amount of valuable content that had been there over a decade was deleted mainly because of me. I came here to improve articles and to add content, not making them vanish. That completely goes opposite with the reasons that I’m here. What they did do affect my editing. I’ve left WP for a few days because of that, but it seems no use. Some of the above happened after I came back. I’ve asked for advice on another editor’s talk page, it seems that I was misunderstood. I was mainly asking for suggestions on the likely animus / uncivil behaviour, not on article’s content. I regret having asked that.. yes, my fault.. it was misunderstood.. and it seems that I’ve put someone in a difficult situation, which is not what I intended ... (As a side note, if we’re talking about content, removing a large amount of content at a time of course is not good. No one knows everything about every subject, and everyone makes mistakes. Removal like that will just increase the risk of mistaken removal, even when done in good-faith, without leaving the chance for correction).
I won’t deny that perhaps some of my edits/comments had irritated that user .. but I don’t think what they did is the way to go. Perhaps they just want to prove that “See? The article has problems that you didn’t notice and I’m correcting them now.”? I hope that can come to an end.. but that kind of behaviour has been lasting for quite some time already, and I’m not that optimistic ….. I choose to speak up here, anyway. What also troubled me is their fluctuating attitude/behaviour. Sometimes they seem to be very civil (mostly to others, but once or twice to me also). But when they are unhappy / don’t like you, it’s just totally different. I’ve been told to “find way” to like them, but it’s just too difficult.. I have tried not to escalate during the discussions (if you are familiar with my edits you’ll know how assertive I can be) but I wonder if that helped. I hope I’ve made it clearer now on why I said “I’ve tried my best already”. It’s not about “discovering the value of others”. Nothing like that. You can’t really like someone if they treat you (and others?) like that, no matter whatever value they have ...
Back to the “How do we welcome new medical editors?” thread at WP:MED talk page.. well, I think that user (one different from the above) has taken some of the advice in that discussion and probably has become more civil (as seen from their comments at least) now. And they have never been uncivil to me, which I really appreciate; despite the fact that I’ve pointed out several times what they shouldn’t have done. I believe that’s an editor with good intention. For that I’ve even given them a barnstar. So, perhaps I should go on and start a new discussion called “How do we work with our newly-joined colleagues?” Do we work with them by ... 3RR … warnings ... following … ?” I don’t think I have the energy (or should spend the time) for that though .. after all, it’s just Wikipedia ..
(N.B. I’m talking to myself and reply is welcome but not absolutely needed.. I’m not providing any diff, because I really don’t want to piss people off… if you know you know, anyway ..) --Dustfreeworld (talk) 18:35, 21 March 2024 (UTC)[reply]
WP:Wikihounding is against policy. You might want to consult someone to see if it fits. Aaron Liu (talk) 18:47, 21 March 2024 (UTC)[reply
]
Thank you for sharing this, @Dustfreeworld. I'm really sorry for your bad experience. First and foremost, as Aaron Lui said, you need to report the behavior you describe.
On your message, I agree regarding the attitude. Welcoming users and providing suggestions to their edits is a positive and active way to have more editors joining. Trizek_(WMF) (talk) 17:47, 26 March 2024 (UTC)[reply]
@Trizek (WMF) The biggest blocker with any active welcoming and mentorship plan is that... They all fail thanks to no longevity plans and too much effort required.
I have never seen
WP:TWA is... I am not even sure if it's alive or not, it's not very easy to see the impact of it there, Growth Team's Mentorship space is currently indecipherable for any veteran editor (I don't even have an enwiki page to link for it), Hostbot is unfortunately inactive (not sure why), WP:Twinkle
welcoming templates are still active.
Of all of these, I'd recommend reviving Hostbot and encouraging more Twinkle Templates for your active welcoming purposes. One is a bot, the other is a simple 2-clicks per user who's already installed Twinkle. Essentially the simpler and lower effort your solution is for everyone, the more impact it'll have overall (because it's much more likely to be used 3 years later instead of 3 months).
I could go in more depth, but essentially I'd like to see WMF dedicate more resources to simple easy to maintain ideas that solve one problem each, instead of overarching mega-goals that fail soon after the "patronship" dries out. Soni (talk) 06:42, 1 April 2024 (UTC)[reply]
There was research that showed people liked TWA but it did not improve editor retention. Not sure what your suggestion about Twinkle is; isn't Twinkle-welcome already working? Aaron Liu (talk) 14:45, 1 April 2024 (UTC)[reply]
Yeah I was pointing out Twinkle-welcome as one of the few "active welcoming" things that do already work; so if I were WMF, I'd focus some resources towards "Can we encourage this more". Right now it's mostly used by veterans who already know what Twinkle is/how to use Twinkle/are used to welcoming via Twinkle often enough. I don't have any specific plans already, but I assume anything that boosts any of those three will increase active welcoming. My point of highlighting Twinkle was "Improve something that works" vs "Make a new project that first crosses the longevity barrier".
I do think there's better avenues to explore, roughly in 'more automated and less heavy on maintenance' things. I'd like Hostbot revived, if only because it'll give us a lot of data on impactful retention. Soni (talk) 18:34, 1 April 2024 (UTC)[reply]
Some kind of encouragement to use Twinkle Welcome messages more might indeed help. After using Twinkle for many years, I only recently realized that I should be using the welcome messages more often when dealing with problem edits from (apparently) new editors. I think part of my problem was that I did not realize that besides the purely welcoming messages I often saw on user talk pages, there are also welcome messages that deal with a subset of problem edits that I can use instead of a pure warning message in many cases. Donald Albury 13:09, 2 April 2024 (UTC)[reply]
Most initiatives to help newcomers in a direct way (not through passive messaging) are time consuming, that's true. In my opinion (which is just an opinion), it is also the price of quality welcoming, to create a new generation of wikipedians. At the moment, the lack of time creates a gap on who will join: only users with "survival" skills will succeed, while less assured people will give up.
What I call "Passive messaging" are user talk page messages, often pre-formatted for a given purpose, often with wiki-jargon, looking like being distributed by a machine and very often with no way to contact the sender. Donald just gave good context about them.
Also, I don't know if Twinkle offer ressources to encourage users of they've done good (or partially good) edits.
@Soni, if I set aside using Twinkle, what are the solutions to welcome and sustain a new generation of editors? Trizek_(WMF) (talk) 16:47, 2 April 2024 (UTC)[reply]
user talk page messages, often pre-formatted for a given purpose, often with wiki-jargon, looking like being distributed by a machine and very often with no way to contact the sender. I actually disagree. I get the main point you're making, but in practice, I find Template:Welcome cookie to be strictly better than literally everything (including Special:Homepage). There are a lot of worse templates, agreed, but tweaking to adjust the templates to better serve your purpose (A simple message saying "You can contact me at [my talk page]")
Also, I don't know if Twinkle offer ressources to encourage users of they've done good (or partially good) edits. That's why I mentioned Snuggle from earlier. If you specifically want "Let us encourage editors who made good editors recently" you may be better off partially or completely reusing codebase that should already exist from before. The project had an interface like WP:Huggle and pointed out newer editors with "good" edits that I could then send welcome messages to. It just was a separate interface that editors had to get used to using, so ended up not actually being used much (IIRC).
if I set aside using Twinkle, what are the solutions to welcome and sustain a new generation of editors? Like I tried to mention earlier, I think this problem is best solved by breaking down each subproblem separately. I think reviving Hostbot could be good for "Identify lots of promising editors, send them to pipeline of "editors training others". I think Growth homepage is good for "Every new editor sees this" but it needs severe updates to allow experienced editors to interact or help (Teahouse and a bunch of onwiki resources are still not added, there's no enWiki landing page or talk page, there's no WP project page with simple "Here's example screenshots of how the growth page looks", all of those will allow veterans to point out specific things that can be improved). I think there is room for space to grow "Mentor and retain editors who are promising (100+ good edits)", probably an evolution of
WP:EotW
folks". Those have done excellent work in retaining promising veterans from burnout, simply by encouragement. So I can totally see something similar working for newcomers).
In essence, I'm recommending "Iterate and improve on every subproblem" as a way. "Will veterans use and maintain this space 2 years later" can be very hit-or-miss, but my best guess for increasing those odds involve asking a few Wikiprojects, then improving the projects they are most excited by/most likely to use. Soni (talk) 17:56, 2 April 2024 (UTC)[reply]
Interesting thoughts, thank you. They will feed into my work on mentoring and how to help communities in this area.
Regarding pre-formatted messages, my definition may not apply to some messages, but the majority of them are actually not that good across wikis. Even the Welcome cookie one could be improved for the benefit of new users. It is a problem in itself. :)
Anyway, to be continued, probably somewhere else. Trizek_(WMF) (talk) 19:01, 3 April 2024 (UTC)[reply]
My favorite welcome template is {{w-graphical}}, which neatly categorizes the links. Aaron Liu (talk) 19:06, 3 April 2024 (UTC)[reply]
Oh I completely agree that things could always be improved, I just think the improved templates are really "solid" and cover a lot of useful ground consistently (even if a bit impersonal). I also like automation because I treat this process as a scaling problem.
We probably have thousands of new editors monthly who make a useful edit, a few hundred who stick around for 10 edits, and probably dozens who I'd call "promising" (>20% odds of editing 1 year later, say). Each group requires a different approach to maximise our "odds", simply because otherwise you'd spend a lot of time personalising messages that might never be ever seen.
The more we can accurately go "Okay we have 20 new editors with 50 unreverted edits made over the last month", the more we can focus vet effort on personally interacting/encouraging/mentoring those. And the "They made 2 edits that weren't flagged as vandalism" folks can be handled by automated/semi-automated systems to get them to "Okay this is what talk pages are, also ask questions on this link" levels Soni (talk) 19:50, 3 April 2024 (UTC)[reply]
@
WP:Helpdesk, Wikipedia:IRC/wikipedia-en-help regulars as well. Both locations deal with large volumes of newcomers constantly, so the vets there would know exactly the things that would smoothen their mentoring curve. Soni (talk) 19:54, 3 April 2024 (UTC)[reply
]
You know that we don't have a common definition of a "useful edit"? The one used is based on reverts: a non-reverted edit after 3 days. We have data about this.
Regarding automated system providing guidance, they could work, but human-to-human interactions are way better to improve retention. We are working on the Wikimedia Foundation's annual plan, and it has a question regarding how we can distinguish ourselves from other platforms. I think the human factor is important there. It doesn't mean that we should not use any form of semi/automated ways of helping users (like we plan to do with Edit check), but we can make a difference on how we encourage new users with a more human -centered approach. Again, it is still a question with no proper answer. Yet!
Trizek_(WMF) (talk) 14:15, 4 April 2024 (UTC)[reply]
Oh I completely understand, I'm just making sure to emphasise making it sustainable for human volunteers. The last time I checked the Growth dashboard (6 months ago?) my realisation was that most of the human effort on veterans' end was fairly wasted. You do not want to burn out all your experienced editors trying to reply to everything when it's way more important for the "promising newcomers" (People who have already shown they understand Wikipedia basics AND are sticking around for more than 1-2 days) to get that interaction. I do not believe the latter is happening at all (or enough) right now, so I feel former (Spreading out volunteer attention to everyone) is not helpful enough.
You know that we don't have a common definition of a "useful edit"? I don't know if this is the biggest problem to solve, but I'm fairly confident I've seen something like this before. Snuggle, Huggle, mw:ORES all have some way of judging the quality of edits. I know I've seen this in my Watchlist as well. This is a perfect usecase for this or similar tooling: Decent accuracy but sorts through everything. Soni (talk) 14:33, 4 April 2024 (UTC)[reply]
I've often written about the inefficiencies of Wikipedia's discussion processes, and combined with the realities of most volunteer recruiting, where the vast majority of people stopping by aren't going to commit to staying around, agree that recruiting is costly. (There's a commonly used solution for that, but it's not one that I feel the English Wikipedia community is ready to accept: have paid staff do the welcoming and hand-holding.) That being said, I think that's just something that has to be paid to feed the pipeline for maintaining English Wikipedia at its current scale. While I also agree that having tools to help identify promising newcomers would be helpful to target them for retention, I additionally feel we need to work on ways to get more editors to the point where their promise can be evaluated. As others and I have previously suggested, perhaps there should be recruiting initiatives targeting groups whose interests align well with the idea of volunteering to write encyclopedia articles. This can be on a one-on-one personal level (current editors reaching out to people they know who would be interested) and on a higher level, such as trying to get history buffs involved. isaacl (talk) 15:34, 4 April 2024 (UTC)[reply]
@Soni, well the sustainability of any program that involve humans to help new users feeling welcomed and capable of editing is precisely the challenge.
My realisation was that most of the human effort on veterans' end was fairly wasted -- could you elaborate on this?
Regarding the quality of edits, there are two different cases: ORES can give a prediction of the intent or the level of damage. It is a possibility to guess if the edit is useful, but it is not qualifying as such for sure. Some obvious cases are immediately identified, but the grey area between vandalism and constructive edits is left to humans' appreciation. If we had a proper definition of a useful edit, the prediction models (ORES or its replacement) would work differently.
Regarding assigning a mentor to active users who already shown apetite for Wikipedia by a few edits could be a mistake. Being a mentor myself at my wiki, I often get questions from users who aren't sure if they can change something on a page. Their very first edit is a question to me. If i put aside
SPAs
, the majority of them are now active users (even if not regularly).
@Isaacl, if you have any link to your writings at hand, I'm curious to read about welcoming new users.
The Growth team worked on a tool to identify promising users, so that their mentor can encourage them. We tested it at a few wikis, but it is not ready at all for a larger release. We also have plans to assign mentors to newcomers who match their interests, but it is not on Growth's scope for now. Trizek_(WMF) (talk) 14:13, 5 April 2024 (UTC)[reply]
I think it's a good idea to try to match mentors to new editors based on common interests, as well as directing new editors towards active groups of editors with matching interests. Unfortunately, many WikiProjects no longer have high levels of engagement on their talk pages, which makes it harder.
I don't think I've written much about welcoming new users. I once wrote down some quick thoughts on active mentorship for new editors. At the editor retention WikiProject talk page, I have discussed selective recruitment and challenges in understanding how to make English Wikipedia more attractive for new generations to edit. (I do not remember where I discussed recruiting from historians/history buffs.) On the general theme of trying to attract people to help out, I've floated an idea for volunteer weeks, where editors host "open house" activities to recruit potential volunteers for specific initiatives. (If you're asking about something else, you might find something relevant on my "Community" user sub-page.) isaacl (talk) 18:08, 5 April 2024 (UTC)[reply]
could you elaborate on this? We've actually discussed exactly this last year. I noticed that the Growth dashboard was casting too wide a net, so I got 10 mentees who had never made an edit (and never would again). I don't believes any changes were made from there. And the dashboard continues to not be clear on what "level of editors" you'll get questions from. Veterans are a 'non-renewable resource' so I always prefer them fully knowing what they're signing up for and/or being tapped after there's already a "filter" applied on their potential mentees.
Their very first edit is a question to me I guess we disagree. I would like those editors to also get some assistance, but I personally believe it's way more important to first build a sustainable structure at the "higher levels of the pyramid". That is currently missing, so in my opinion, you are giving good human support to a few thousand editors who edit once, but have nothing for few dozens/hundreds who are already super likely to stick around.
I would rather Growth team's efforts be on building the "newbie to experienced editor" mentorship pipeline for all levels of newcomers, than focus all new initiatives trying to redo fancy new ideas but only for the newest editors. The reason I suggested ORES is because it probably isn't perfect but it's definitely "good" as a starting point. The scale at which enWiki operates, I'll rather have an existing tool that's 70% accurate in iding newcomers, than a tool that comes a few months later. I'd rather WMF spent more resources improving current tooling and reviving good projects with promise, than continue churning out newer plans every few months. Soni (talk) 18:14, 5 April 2024 (UTC)[reply]

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

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)[reply]
I would also offer a suggestion that the ITN box include a permalink to the
WP:NOTNEWS. SamuelRiv (talk) 15:09, 5 April 2024 (UTC)[reply
]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

In-page attribution of authors/contributors

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

@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)[reply]
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)[reply]
So you'd be fine ignoring the thousands of other authors on such a byline? — xaosflux Talk 14:58, 2 April 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply
]
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)[reply]
Another example, using today's featured article Morgan Bulkeley, would read: "Written by Wehwalt, et al." Grnrchst (talk) 14:47, 2 April 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
  • Note, a feature request that may address this idea is open at phab:T120738. — xaosflux Talk 15:18, 2 April 2024 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    And his alt was banned for
    WP:DISRUPTNAME, right? Aaron Liu (talk) 20:40, 2 April 2024 (UTC)[reply
    ]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    This is a completely fair and valid concern. --Grnrchst (talk) 21:54, 2 April 2024 (UTC)[reply]
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)[reply]
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 [24] but that's only because I once ran the archive bot on that page [25], I am not actually anywhere near a top author of the actual prose on that article. Levivich (talk) 17:15, 3 April 2024 (UTC)[reply]
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)[reply]
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)[reply]
  • 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)[reply
    ]
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:
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)[reply
]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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: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)[reply
]

Wikipedia Hall of Fame?

What are your thoughts? Is it going to work? Comment down below. Wolverine XI (talk to me) 17:28, 8 April 2024 (UTC)[reply]

Hall of fame topic; section break 1

  • I'll bite. What do I get? Like, a room with a comfy chair? The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons. BD2412 T 17:37, 8 April 2024 (UTC)[reply]
    "The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons." That's a good point. Though, IMO, I don't think HOF should be behavior-exclusionary and should be open to anyone who has made an enduring impact on WP, regardless of how they made the impact. For instance, I say induct Jordan French (maybe not in the inaugural cohort, but eventually). Chetsford (talk) 18:47, 8 April 2024 (UTC)[reply]
    I agree with Chetsford on this. Wolverine XI (talk to me) 04:11, 9 April 2024 (UTC)[reply]
    French certainly made an impact but then so did many
    LTA vandals. If this idea is adopted, it seems appropriate to limit membership to those who have shown altruism rather than encouraging those who make Wikipedia worse for personal gain. Certes (talk) 08:24, 9 April 2024 (UTC)[reply
    ]
    Never say never. Wolverine XI (talk to me) 13:16, 9 April 2024 (UTC)[reply]
    Yeah, that's a good point, Certes. I think this was intended more as an exaggeration for emphasis that we not be rules-bound for a HOF, but probably not a good example to underscore that! Anyway, I agree with your suggestion. Chetsford (talk) 15:26, 9 April 2024 (UTC)[reply]
  • We already have a lot of perks for experienced editors (
    Editor of the Week, Service awards, ...), and I honestly don't think we need yet another way to separate "elite" Wikipedians from the rest of us. Chaotıċ Enby (talk · contribs) 18:02, 8 April 2024 (UTC)[reply
    ]
  • Similar to Internet Hall of Fame, to be serious, there would need to be a reliable advisory board. They can help surface little known but important people from the early founder days. It could be a popular vote nomination process, like the Nobel, but picking the winners would need a small august body, known for deep institutional knowledge and experience. After a few rounds/years of winners, those winners then become members of the advisory board. Overall this is probably something that should be organized by WMF. Or you can just do it, but it will be another "This one is special. This one is also special" award. -- GreenC 18:32, 8 April 2024 (UTC)[reply]
    @GreenC, i like the discussion here of this idea, but how about an opposite approach? such as, anyone who wants to be in the hall of fame, can be?? and maybe split it up by topic, so that it would have some actual useful format to make it readable to others? Sm8900 (talk) 20:10, 17 April 2024 (UTC)[reply]
  • I like it. While we may have a superfluidity of awards, these cost essentially nothing to produce so I'm not sure I ever understand the resistance. All recognition systems are voluntary and those who don't approve can opt-out. Moreover, a HoF -- if managed through some approximation of the way GreenC describes -- would be different from existing accolades which are either interpersonal recognition (editor to editor) or metric-based recognition (e.g. Four Award, etc.). Chetsford (talk) 18:41, 8 April 2024 (UTC)[reply]

Hall of fame topic; section break 2

  • Of course they "cost nothing to produce", that's not the problem, the problem is that they give one more excuse to divide Wikipedians between "the ones who have power" (i.e. the unblockables) and the plebs like us. Chaotıċ Enby (talk · contribs) 13:36, 10 April 2024 (UTC)[reply]
  • It might be a good idea. 3.14 (talk) 19:07, 8 April 2024 (UTC)[reply]
  • The key questions for any initiative is what is the objective, and how helpful is the initiative in achieving this objective? For recognition programs, it's important to also consider how the selection process will work, and whether or not it will create more difficulties than benefits gained. Recognition programs are tricky because the flip side of selecting some is that many others are not selected, and that can result in conflict. isaacl (talk) 02:36, 9 April 2024 (UTC)[reply]
    That's how recognition programs work, but I don't think they'll necessarily cause any conflict. Wolverine XI (talk to me) 04:09, 9 April 2024 (UTC)[reply]
    "it's important to also consider how the selection process will work" After the inaugural cohort is selected, maybe it should become self-perpetuating with all prior inductees selecting each subsequent cohort. (Though you'd still need some system to choose the inaugural cohort.) This would mitigate politicization and degradation as inducted members would have a vested interest in maintaining its reputational coherence. Chetsford (talk) 05:37, 9 April 2024 (UTC)[reply]
    That would be difficult if they are dead or so long retired from WP they don't give a toss about the place anymore/are out of touch about who is still active and "deserves" a shout. - SchroCat (talk) 07:44, 10 April 2024 (UTC)[reply]
    "would be difficult if they are dead" I imagine it would. Chetsford (talk) 08:48, 10 April 2024 (UTC)[reply]
    I would object to exclusion of the deceased. There are some amazing editors who left us too soon, but with great work done first. BD2412 T 02:37, 11 April 2024 (UTC)[reply]
    We don't mean a blanket exclusion, just that we will ensure that batches of cohorts keep on coming; this line of discussion was about a proposal to have each cohort select the next. Aaron Liu (talk) 02:59, 11 April 2024 (UTC)[reply]
    I don't think we'll select a cohort that are all dead or inactive, for the reasons you've mentioned. Aaron Liu (talk) 11:34, 10 April 2024 (UTC)[reply]
    I think it best if you don't have any intake at all: voting for one's friends make this an inbred and insular process. As I've said before (as has Chaotic Enby), this is a bad idea - divisive and with the potential for conflict when the "wrong" people are elected and the "right" people over looked. - SchroCat (talk) 12:02, 10 April 2024 (UTC)[reply]
  • The English Wikipedia Hall of Fame idea sounds peachy keen, as Babe Ruth would say before tying his hands behind his back and hitting a home run with his neck (Ruth is, all kidding aside, the most underrated ballplayer in baseball history). The initial "class" obviously would include J and L, the pioneering heroes of our story, and I can think of several others who would be obvious. That first class probably shouldn't be large, maybe 7 or 8 inductees. Then the rules get tricky, but doable. In a perfect world we'd lock J and L in a room until they get to a place where they can come up with a plan of how to handle this that everyone says "Of course that's how it should be done". But, bottom line, I think an EWHoF is a good idea all around (without WMF involvement). Randy Kryn (talk) 03:22, 10 April 2024 (UTC)[reply]
  • A second rate popularity contest with ill-defined criteria? What could possibly go wrong. Terrible and divisive idea. You think someone's great - give 'em a barnstar, or, even better, leave them a thank you note, but to 'promote' people who will undoubtedly be divisive to others? That way grief and conflict lies. And this ignores the fact that "hall of fame" is not a worldwide concept that people everywhere readily grasp or buy into.- SchroCat (talk) 07:44, 10 April 2024 (UTC)[reply]
    Schro, the procedure is akin to the Wikimedian of the Year, except that it exclusively concentrates on the English Wikipedia. There's a purpose for these initiatives, and I firmly disagree that this is a "bad idea." Wolverine XI (talk to me) 13:25, 10 April 2024 (UTC)[reply]
    You are, of course, entitled to disagree. For what it's worth, I think the Wikimedian of the Year is a fairly crap award too, being a process with no criteria and something else that divides, rather than unites. Most people are happy to do the work for the sake of the work, not to seek vacuously external praise or validation just because they've caught the eye of someone powerful or happen to be pushing a zeitgeist line of thinking. - SchroCat (talk) 14:44, 10 April 2024 (UTC)[reply]
    As you haven't yet stated the purpose behind your suggestion, nor proposed a process, there isn't enough info to understand the potential benefits and costs. There's an understandable view that costs quickly outweigh benefits as any process involves more people, adding up to more total effort expended. isaacl (talk) 16:53, 10 April 2024 (UTC)[reply]

Hall of fame topic; section break 3

I don't much like anything on Wikipedia which encourages elitism, political campaigns, cliques, inequality, etc. I can imagine that many wiki-politicians would waste a lot of time campaigning to be elected to a HOF and that the results would be divisive. "How come so-and-so got elected, and I didn't?" Smallchief (talk) 21:44, 12 April 2024 (UTC)[reply]

The
Developing Countries WikiContest

Several editors on the

don't get enough attention. We aim to make this a three-month event running from July through September. Ixtal and Sawyer-mcdonell have volunteered as coordinators, and they're looking for a third! The organizers are also seeking feedback from the wider community, particularly from editors with experience running wiki-events. Please leave comments, questions, and suggestions below, or sign up here. Thanks! TechnoSquirrel69 (sigh) 05:27, 9 April 2024 (UTC)[reply
]

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

{{
cite video}}? Aaron Liu (talk) 02:59, 11 April 2024 (UTC)[reply
]
{{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)[reply]
Thank you both for these, sorry to bother.Aaronlearns (talk) 05:38, 11 April 2024 (UTC)[reply]
For YouTube videos you could add {{rp}}, as seen at Draft:New York City Jazz Mach61 13:21, 11 April 2024 (UTC)[reply]
@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)[reply]

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

It's already (kind of) a thing with Ctrl+F! Chaotıċ Enby (talk · contribs) 01:10, 19 April 2024 (UTC)[reply]
oh okay 。 🎀 𝒫𝓊𝓇𝓅𝓁𝑒𝓁𝒶𝓋𝑒𝓃𝒹𝑒𝓇𝓂𝒾𝒹𝓃𝒾𝑔𝒽𝓉𝓈 𝟣𝟩 🎀 。 (talk) 01:52, 20 April 2024 (UTC)[reply]
I think we should just leave that to the browser. Aaron Liu (talk) 02:31, 19 April 2024 (UTC)[reply]

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

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)[reply
]
As Masem said, with the addition that if the article was deleted via the
Phil Bridger (talk) 18:36, 20 April 2024 (UTC)[reply
]
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)[reply]
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)[reply]

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

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

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

This is good to know about, Mike; thanks for sharing! Sdkbtalk 18:31, 19 March 2024 (UTC)[reply]

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
That's why the proposal is to hire a dev specifically to work on maintenance. Tercer (talk) 06:51, 25 March 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I disagree. Bawolff (talk) 21:19, 1 April 2024 (UTC)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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

The movement

The phrase "Wikimedia movement" is not a recent invention, though it has received more attention in the past couple years. We individual Wikians of course are free to call ourselves proudly as we will but I think the failure a few years ago to rename the outlying and ancillary sites to "Wikipedia [something]" was unfortunate as it would have helped in public recognition. It would help in recruiting; almost all my students have been attracted to our teaching sessions in hopes of writing a new article when really, it would usually be easier for them to learn how to add a new picture. For my own editing, for a decade or more I have been putting about as much effort into Wikimedia Commons and Wikidata as into English Wikipedia. Those sites do a few things but mainly they supply pictures and data (geographical coordinates are one of my specialties) to the hundreds of Wikipedias including English. Even without a common name, I figure there ought to be a common policy structure and general set of guidelines for us all, so the WMF staff don't have to decide so many things for us. Naturally there will be an interest in adding matters that are mainly the concern of only the encyclopedias or of only few of the various other autonomous member sites, who each ought to handle such things by their already established methods. There will be disagreements on such questions, but I'm confident our usual methods of drawing a consensus will prevail. Jim.henderson (talk) 00:16, 4 April 2024 (UTC)[reply]

  • In short: I'm curious whether you're saying you believe that a difference of one letter (in some cases) constitutes a real detriment to the development of Wikipedia's sister sites? "Wiki" is already very widely associated with Wikipedia by the public, does "Wikipedia Data" being a thing people hear about and are surprised it exists seem much more unlikely than with "Wikidata"?
  • I really disagree that even in effect Commons's main function is to act as Wikipedia's image repository. Its use is ubiquitous.

I figure there ought to be a common policy structure and general set of guidelines for us all, so the WMF staff don't have to decide so many things for us.

  • I don't really think this structure makes sense. WMF doesn't really make that many choices for us—or at least, I feel part of the process for just about every choice I would like input on. I'm not sure what exactly you would like centralized, the current model seems to work. Do you have specific areas of policy or administration in mind?
Remsense 00:39, 4 April 2024 (UTC)[reply]
I think it's important to remember that there isn't a "we", strictly speaking. Not all of us are here to be part of a movement or whatever, or even editing for the same reasons; some just want to fxi a tyop that bugged them, others to add information about their favourite volcano. Jo-Jo Eumerus (talk) 07:18, 4 April 2024 (UTC)[reply]
I have a great respect for sister projects. I refer to Wiktionary regularly, and I use Commons unconsciously most times I read a Wikipedia article with images, though I've contributed very little to either. I use Wikidata occasionally, and was briefly an enthusiastic contributor; I would use it much more if it had an intuitive user interface. None of this makes me part of a "Wikimedia movement", which I see largely as a political stance shared by some but not all editors. Certes (talk) 09:08, 4 April 2024 (UTC)[reply]
The fact that you think the other projects are nothing more than ancillary sites that should be rebranded as under the Wikipedia umbrella is a very, very bad sign.
Cremastra (talk) 22:04, 5 April 2024 (UTC)[reply
]
  • I completely understand that Wikipedia editors have a very Wikipedia-centric view of the broader Wikimedia community. It would be nice if everyone had the interest to learn more about the other projects, and how they are used, but I understand that it's not a priority for most Wikipedians, regardless of which language Wikipedia they choose to edit. But I'll just throw in a few tidbits:
  • For many mainstream media sources that use images, Wikimedia Commons is often a go-to resource. There isn't a day that I don't find a Wikimedia Commons credit on the series of mainstream media sources I look at.
  • Wikidata is used widely as a data aggregator by many other not-for-profit resources.
  • Some language editions of Wikisource are the largest repositories of open-source historic documents and literature in those languages
  • Some language editions of Wiktionary are having a major impact in preserving dying languages

The 339 Wikipedias, with their collective 62+ million articles, are indeed the major drivers of the Wikimedia family of projects; the largest Wikipedias, especially the English one, have deservedly gained a reputation for accuracy and neutrality in providing the entire world with information. That doesn't mean that the "sister projects" don't make a valuable contribution to the sum of all human knowledge. I will never fault anyone for choosing to focus on one specific Wikimedia project, or even one small aspect of a specific project. We're all better for those contributions. Risker (talk) 08:39, 4 April 2024 (UTC)[reply]

  • Fearful of being caught beating a dead horse, I'll speak once more and hope to be disciplined enough to hold my peace. Yes, one little letter can indeed make a difference. Besides the local Wikimedia Chapter I am a member of local clubs concentrating on bicycling and astronomy. I'm always nattering to them about how we make Wikipedia and sometimes they actually listen. A couple times, though they did not surrender to my efforts to get them to edit an article or two, they decided that a money contribution would be a good thing. "Eh? The form said 'Wikimedia Foundation'. Is that the same thing, or did someone else sneak in with some kind of Internet scam?" These people had me to make the explanation, unlike most outsiders.
  • A common brand can't help us thousands of insiders to understand what we're doing; like other big busy communities we are too complex to be understood with just a few simple labels. However, that's not what brands are for. Brand names are to promote instant understanding among the mass of outsiders, in this case their understanding that this is a big complex of websites with a common theme. We have different detailed policies to handle our specialties, but we are all about Wikipedia's original aim of promoting universal knowledge by organizing it for accessibility.
  • I have uploaded thousands of pictures to Wikimedia Commons, and I know of a dozen that are used in news publications, books, and other works. Probably hundreds more are so used; we don't require to be given notice. The usual credit, when given, is "From Wikipedia" or "From Wikimedia Commons" or "by Jim.henderson via Wikimedia Commons". I figure, out of the small minority of their readers who actually wonder where the pictures came from, "From Wikipedia" is the only one that isn't mysterious. Yes, knowledge professionals, most often, know what they are doing but they hope their product will be read by many more people than are composing it; same as we do. They don't expect their readers to learn what it takes to be a knowledge professional.
  • Wikidata is indeed used by many knowledge professionals. I am most familiar with the work of librarians since I work with them often, and have a lunch appointment tomorrow with a relative who's in that line of work. They are familiar with the different workings of OCLC, Worldcat, LoC and various local or specialized catalogs, and many of them also use Wikidata to help find their way through and among the others. Haha, a couple years ago I looked at the Wikidata item about me, and it showed my LoC Authority Control Number. What, has my good work come to such high prominence? No, that was another Jim Henderson, so I corrected it. Wikidata is full of dirty data like that, some of it imported from massive outside databases a century old or more. Not a big problem since WD serves people in the database business who are aware. I have also worked with art museum archivists and have no idea whether their old catalogs have as many errors as the databases for community gardens in Brooklyn or defunct restaurants in The Bronx. Hmm, perhaps I have wandered but anyway yes, the question of what brand name Wikidata ought to use is a lot less important than for Wikiprojects that serve a wider direct audience.
  • Oh-oh, it seems this paragraph on WD has revealed that I've already gone overboard. So, I'll drop my stick and carefully back away from the dead horse. Jim.henderson (talk) 01:13, 5 April 2024 (UTC)[reply]

The full Movement Charter draft awaits your review on Meta

Hello again! I am following up on the pre-announcement from the previous week to let you know that the full draft of the Movement Charter has been published on Meta for your review.

Why should you care?

The Movement Charter is important as it will be an essential document for the implementation of the Wikimedia 2030 strategy recommendations. Participating in the Charter discussions means that you ensure that your voice is heard and your interests are represented in shaping the future of the Wikimedia Movement. As the English Wikipedia community is the largest of the Wikimedia movement, it is essential to have the perspectives from your community presented in the global conversations. I hope many of you will find time to provide feedback, share your thoughts and perspectives!

Community Engagement – April 2nd to April 30th

The Movement Charter Drafting Committee (MCDC) cordially invites everyone in the Wikimedia movement to share feedback on the full draft of the Movement Charter.

Let your voice be heard by sharing your feedback in any language on the Movement Charter Talk page, attend the community session today, on April 4th at 15.00-17.00 UTC, or email [email protected]. I will also be monitoring conversations on this talk page, to bring back the summaries to the ongoing global conversations.

You can learn more about the Movement Charter, Global Council, and Hubs by watching the videos that the Movement Charter Drafting Committee has prepared. Read the Committee's latest updates for more information about the most recent activities from the Drafting Committee.

Thank you again for your time and kind attention! I look forward to your input and feedback. Have a wonderful month of April! --KVaidla (WMF) (talk) 13:07, 4 April 2024 (UTC)[reply]

Unified enwiki response to the charter

In votes like these a significant issue is that interested editors do not have the time or wherewithal to properly assess the issues or candidates presented and so abstain from the vote. I propose that we attempt to address this, by having more engaged editors consider the proposal carefully and, in consultation with the community though an RfC, issue a recommendation either to support or oppose the change. Specifically, I propose a three-stage process:

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

Thanks for your comment, BilledMammal. This isn't a bad idea, but it is worth noting that the draft charter will be revised in early May following this current feedback round. Although the MCDC (of which I am a a member) does not anticipate making really large changes, I think it would be reasonable to assume that the final version is going to have at least some differences from the current draft. Would it make sense to create a feedback page on this project as a place where interested enwiki editors could flesh out their opinions before the final revision is made? I'd hate to see people investing a lot of time reviewing a draft and proposing a project-wide opinion in an RFC-type format, based on a document that we know will change. There is something to be said for having a local page for comments and suggestions for improvement (and please yes, if someone thinks X is a bad idea, propose an alternative) as long as there's a link to it on the Meta page so that the MCDC will be well-informed of the discussion on this project. (For that matter, it may be a good idea for other projects, and I'm pretty sure some of them are thinking about this too.) Risker (talk) 03:17, 7 April 2024 (UTC)[reply]
That's a good point, but we also need to consider that it will take time for the RfC to run. I think we should start drafting the summary based on the current document, and then make any updates that are necessary to align it with the May changes and start the RfC a few days after it is released.
I would also agree that creating a local page where editors can make comments and suggestions for improvements would be useful, although I would suggest just using this page as it isn't as busy as the other village pumps and thus an extensive discussion of the proposed charter won't disrupt other discussions. BilledMammal (talk) 04:59, 7 April 2024 (UTC)[reply]
I think mass messaging every eligible voter
WP:ACE style might be too many people. Perhaps a watchlist notice, or pinging rfc participants, would be a good compromise. –Novem Linguae (talk) 16:30, 7 April 2024 (UTC)[reply
]
I don't think that the vote to ratify this charter is less important than the vote to elect the Arbitration Committee. BilledMammal (talk) 16:32, 7 April 2024 (UTC)[reply]
Thank you for this initiative, BilledMammal, to approach the Movement Charter conversations in a constructive way! For reference, the timeline for the steps can be found here on meta and you are right, the time is of essence. It has been already pointed out on the meta discussion page that the review of the Charter would benefit from additional contextual materials for informed decision-making. As a supporting staff member to the MCDC I will see what I can do, yet it might take some time. If there are priority areas for further context in the English Wikipedia community, please let me know, so I can focus my work around that and hopefully have respective content available earlier. Also let us know, if we can support the discussions around the Charter in other ways. Looking forward to hearing the perspectives and seeing good participation from en.wp community! --KVaidla (WMF) (talk) 12:47, 9 April 2024 (UTC)[reply]

Responding to Katherine Maher / Uri Berliner Story

What is WMF's position on the buzz on X/Twitter over

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

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)[reply
]
That is helpful context thank you. Tonymetz 💬 20:30, 17 April 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply
]
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)[reply]
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)[reply]
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)[reply]
@Seraphimblade You too, huh? [26]. Ignaz Semmelweis is a good alternative. Gråbergs Gråa Sång (talk) 18:34, 18 April 2024 (UTC)[reply]
When I was writing
they|xe) 18:38, 18 April 2024 (UTC)[reply
]
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)[reply]
In my opinion Wikipedia can't function if people are chasing truth rather than
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)[reply
]
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. --
they|xe) 19:31, 18 April 2024 (UTC)[reply
]
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)[reply]


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

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)[reply]
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)[reply]
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
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)[reply
]
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
not lead them. ARandomName123 (talk)Ping me! 01:42, 19 April 2024 (UTC)[reply
]
@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)[reply]
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)[reply]
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)[reply]
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.
[27]
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)[reply]
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)[reply]
@
talk) 05:51, 19 April 2024 (UTC)[reply
]

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)[reply]
Precisely. Ymblanter (talk) 06:35, 19 April 2024 (UTC)[reply]

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

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)[reply]
I don't see that I said something different, but for the avoidance of doubt: yes. — Rhododendrites talk \\ 12:34, 20 April 2024 (UTC)[reply]
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 (talkcontribs) 10:36, 20 April 2024 (UTC)[reply]
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)[reply]
Your comments have been helpful for me to better understand her leadership accomplishments and setbacks. Tonymetz 💬 20:38, 20 April 2024 (UTC)[reply]
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)[reply]

Miscellaneous

Will the Met Office logo ever have its copyright expire?

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

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

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

User behavior issues should be posted to
WP:DIFFs of misbehavior in your comment. –Novem Linguae (talk) 10:14, 17 April 2024 (UTC)[reply
]
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)[reply]
 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)[reply]
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 (talkcontribs) 20:16, 21 April 2024 (UTC)[reply
]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

@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)[reply]
If that user script isn't exactly what you are looking for, there's also
WP:US/R. –Novem Linguae (talk) 17:45, 17 April 2024 (UTC)[reply
]
Thank you for the suggestions. Praemonitus (talk) 21:36, 18 April 2024 (UTC)[reply]
@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)[reply]
Thank you. Praemonitus (talk) 14:44, 23 April 2024 (UTC)[reply]

Talk page subscriptions

Is there (or can there be) a bot to remove archived or stale talk page subscription from Special:TopicSubscriptions, or maybe there's a way to condense the page manually? I have not been able to find any documentation on this issue. - FlightTime (open channel) 20:53, 18 April 2024 (UTC)[reply]

@FlightTime, you have to manually click the red "Unsubscribe" item for each entry that you want to remove.
@Trizek (WMF), you might want to include this in the documentation at mw:Help:DiscussionTools#Topic subscriptions. WhatamIdoing (talk) 02:17, 20 April 2024 (UTC)[reply]

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

@
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)[reply
]
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)[reply]
@
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)[reply
]
Then what is history merge for? Robert McClenon (talk) 06:11, 19 April 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Sure, I've already agreed. isaacl (talk) 05:52, 20 April 2024 (UTC)[reply]
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)[reply]

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

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

Sleeper Account Question

A new case request was made in the past 24 hours at

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

A lot of people make accounts just for watchlisting or setting a skin. ScottishFinnishRadish (talk) 01:32, 24 April 2024 (UTC)[reply]
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)[reply
]
I sometimes do wish there was a better way to report and request investigations into editors who show
WP:DUCK despite the other account not being clear. --Aquillion (talk) 04:16, 24 April 2024 (UTC)[reply
]
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)[reply]