Jump to content

Wikipedia:Village pump (proposals)/Archive 216

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Photographs by Peter Klashorst

Back in 2023 I unsuccessfully nominated a group of nude photographs by Peter Klashorst for deletion on Commons. I was concerned that the people depicted might not have been of age or consented to publication. Klashorst described himself as a "painting sex-tourist"[1] because he would travel to third-world countries to have sex with women in brothels, and also paint pictures of them[2][3]. On his Flickr account, he posted various nude photographs of African and Asian women, some of which appear to have been taken without the subjects' knowledge. Over the years, other Commons contributors have raised concerns about the Klashorst photographs (e.g. [4][5][6]).

I noticed recently that several of the Klashorst images had disappeared from Commons but the deletions hadn't been logged. I believe this happens when the WMF takes an office action to remove files. I don't know for sure whether that's the case, or why only a small number of the photographs were removed this way.

My proposal is that we stop using nude or explicit photographs by Klashorst in all namespaces of the English Wikipedia. This would affect about thirty pages, including high-traffic anatomy articles such as Buttocks and Vulva. gnu57 18:29, 16 December 2024 (UTC)

@Genericusername57: This seems as if it's essentially a request for a community sanction, and thus probably belongs better on the administrators' noticeboard. Please tell me if I am mistaken. JJPMaster (she/they) 23:12, 16 December 2024 (UTC)
@JJPMaster: I am fine with moving the discussion elsewhere, if you think it more suitable. gnu57 02:16, 17 December 2024 (UTC)
@Genericusername57: I disagree with JJPMaster in that this seems to be the right venue, but I also disagree with your proposal. Klashorst might have been a sleazeball, yes, but the images at the two listed articles do not show recognizable subjects, nor do they resemble “creepshots”, nor is there evidence they’re underage. If you object to his images you can nominate them on Commons. Your ‘23 mass nomination failed because it was extremely indiscriminate (i.e. it included a self portrait of the artist). Dronebogus (talk) 00:30, 17 December 2024 (UTC)
@Dronebogus: According to User:Lar, Commons users repeatedly contacted Klashorst, asking him to provide proof of age and consent for his models, but he did not do so. I am planning on renominating the photographs on Commons, and I think removing them from enwiki first will help avoid spurious c:COM:INUSE arguments. The self-portrait you are referring to also included another naked person. gnu57 02:16, 17 December 2024 (UTC)
@Genericusername57: replacing the ones at vulva and buttocks wouldn’t be difficult; the first article arguably violates WP:ETHNICGALLERY and conflicts with human penis only showing a single image anyway. However I think it’s best if you went to those actual articles and discussed removing them. I don’t know what other pages use his images besides his own article but they should be dealt with separately. If you want to discuss banning his photos from Wikimedia in general that’s best discussed at Commons. In all cases my personal view is that regardless of whether they actually run afoul of any laws purging creepy, exploitative pornography of third-world women is no great loss. Dronebogus (talk) 01:16, 18 December 2024 (UTC)
I have to confess that I do not remember the details of the attempts to clarify things with Peter. If this turns out to be something upon which this decision might turn, I will try to do more research. But I’m afraid it’s lost in the mists of time. ++Lar: t/c 01:25, 24 December 2024 (UTC)
Note also that further attempts to clarify matters directly with Peter will not be possible, as he is now deceased. ++Lar: t/c 15:45, 24 December 2024 (UTC)
Several issues here. First, if the files are illegal, that's a matter for Commons as they should be deleted. On the enwiki side of things, if there's doubt about legality, Commons has plenty of other photos that can be used instead. Just replace the photos. The second issue is exploitation. Commons does have commons:COM:DIGNITY which could apply, and depending on the country in which the photo was taken there may be stricter laws for publication vs. capture, but it's a hard sell to delete things on Commons if it seems like the person in the photo consented (with or without payment). The problem with removing files that may be tainted by exploitation is we'd presumably have to remove basically all images of all people who were imprisoned, enslaved, colonized, or vulnerable at the time of the photo/painting/drawing. It becomes a balance where we consider the context of the image (the specifics of when/where/how it was taken), whether the subject is still alive (probably relevant here), and encyclopedic importance. I'd be inclined to agree with some above that there aren't many photos here that couldn't be replaced with something else from Commons, but I don't think you'll find support for a formalized ban. Here's a question: what happens when you just try to replace them. As long as the photo you're replacing it with is high quality and just as relevant to the article, I don't think you'd face many challenges? — Rhododendrites talk \\ 16:20, 24 December 2024 (UTC)

Category:Current sports events

I would like to propose that sports articles should be left in the Category:Current sports events for 48 hours after these events have finished. I'm sure many Wikipedia sports fans (including me) open CAT:CSE first and then click on a sporting event in that list. And we would like to do so in the coming days after the event ends to see the final standings and results.

Currently, this category is being removed from articles too early, sometimes even before the event ends. Just like yesterday. AnishaShar, what do you say about that?

So I would like to ask you to consider my proposal. Or, if you have a better suggestion, please comment. Thanks, Maiō T. (talk) 16:25, 9 December 2024 (UTC)

Thank you for bringing up this point. I agree that leaving articles in the Category:Current sports events for a short grace period after the event concludes—such as 48 hours—would benefit readers who want to catch up on the final standings and outcomes. AnishaShar (talk) 18:19, 9 December 2024 (UTC)
Sounds reasonable on its face. Gatoclass (talk) 23:24, 9 December 2024 (UTC)
How would this be policed though? Usually that category is populated by the {{current sport event}} template, which every user is going to want to remove immediately after it finishes. Lee Vilenski (talk • contribs) 19:51, 11 December 2024 (UTC)
@Lee Vilenski: First of all, the Category:Current sports events has nothing to do with the Template:Current sport; articles are added to that category in the usual way.
You ask how it would be policed. Simply, we will teach editors to do it that way – to leave an article in that category for another 48 hours. AnishaShar have already expressed their opinion above. WL Pro for life is also known for removing 'CAT:CSE's from articles. I think we could put some kind of notice in that category so other editors can notice it. We could set up a vote here. Maybe someone else will have a better idea. Maiō T. (talk) 20:25, 14 December 2024 (UTC)
Would it not be more suitable for a "recently completed sports event" category. It's pretty inaccurate to say it's current when the event finished over a day ago. Lee Vilenski (talk • contribs) 21:03, 14 December 2024 (UTC)

Okay Lee, that's also a good idea. We have these two sports event categories:

I don't have any objection to a Recent sports events category being added, but personally, if I want to see results of recent sports events, I would be more likely to go to Category:December 2024 sports events, which should include all recent events. Edin75 (talk) 23:30, 16 December 2024 (UTC)
Did this get the go-ahead then? I see a comment has been added to the category, and my most recent edit was reverted when I removed the category after an event finished. I didn't see any further discussion after my last comment. Edin75 (talk) 09:37, 25 December 2024 (UTC)

Change page titles/names using "LGBTQ" to "LGBTQ+"

Please see my reasoning at Wikipedia talk:WikiProject LGBTQ+ studies#LGBTQ to LGBTQ+ (and please post your thoughts there). It was proposed that I use this page to escalate this matter, as seen on the linked talk page. Helper201 (talk) 20:42, 23 December 2024 (UTC)

Snowclose - As mentioned in that discussion, there was a decision on this topic not long ago based on ngram data which lead to the LGBT -> LGBTQ rename. It hasn't been long enough for consensus to substantially change, and the ngram dataset hasn't been updated since that previous proposal. BugGhost 🦗👻 10:00, 26 December 2024 (UTC)
Agree with BugGhost; I also personally think this topic area (LGBTetc. acronyms) can lean uncomfortably close to WP:GREATWRONGS and WP:TOOSOON. People who by contemporary westernized standards would not be considered “hetero-typical” or “cis-typical” have always existed; the current terminology around them is extremely young. Dronebogus (talk) 14:05, 26 December 2024 (UTC)

User-generated conflict maps

In a number of articles we have (or had) user-generated conflict maps. I think the mains ones at the moment are Syrian civil war and Russian invasion of Ukraine. The war in Afghanistan had one until it was removed as poorly-sourced in early 2021. As you can see from a brief review of Talk:Syrian civil war the map has become quite controversial there too.

My personal position is that sourcing conflict maps entirely from reports of occupation by one side or another of individual towns at various times, typically from Twitter accounts of dubious reliability, to produce a map of the current situation in an entire country (which is the process described here), is a WP:SYNTH/WP:OR. I also don't see liveuamap.com as necessarily being a highly reliable source either since it basically is an WP:SPS/Wiki-style user-generated source, and when it was discussed at RSN editors there generally agreed with that. I can understand it if a reliable source produces a map that we can use, but that isn't what's happening here.

Part of the reason this flies under the radar on Wikipedia is it ultimately isn't information hosted on EN WP but instead on Commons, where reliable sourcing etc. is not a requirement. However, it is being used on Wikipedia to present information to users and therefore should fall within our PAGs.

I think these maps should be deprecated unless they can be shown to be sourced entirely to a reliable source, and not assembled out of individual reports including unreliable WP:SPS sources. FOARP (talk) 16:57, 11 December 2024 (UTC)

A lot of the maps seem like they run into SYNTH issues because if they're based on single sources they're likely running into copyright issue as derivative works. I would agree though that if an image does not have clear sourcing it shouldn't be used as running into primary/synth issues. Der Wohltemperierte Fuchs talk 17:09, 11 December 2024 (UTC)
Though simple information isn't copyrightable, if it's sufficiently visually similar I suppose that might constitute a copyvio. JayCubby 02:32, 13 December 2024 (UTC)
I agree these violate OR and at least the spirit of NOTNEWS and should be deprecated. I remember during the Wagner rebellion we had to fix one that incorrectly depicted Wagner as controlling a swath of Russia. Levivich (talk) 05:47, 13 December 2024 (UTC)
Oppose: First off, I'd like to state my bias as a bit of a map geek. I've followed the conflict maps closely for years.
I think the premise of this question is flawed. Some maps may be poorly sourced, but that doesn't mean all of them are. The updates to the Syrian, Ukraine, and Burma conflicts maps are sourced to third parties. So that resolves the OR issue.
The sources largely agree with each other, which makes SYNTH irrelevant. Occasionally one source may be ahead of another by a few hours (e.g., LiveUaMap vs. ISW), but they're almost entirely in lock step.
I think this proposal throws out the baby with the bathwater. One bad map doesn't mean we stop using maps; it means we stop using bad maps.
You may not like the fact that these sources sometimes use OSI (open-source intelligence). Unfortunately, that is the nature of conflict in a zone where the press isn't allowed. Any information you get from the AP or the US government is likely to rely on the same sources.
Do they make mistakes? Probably; but so do all historical sources. And these maps have the advantage that the Commons community continuously reviews changes made by other users. Much in the same way that Wikipedia is often more accurate than historical encyclopedias, I believe crowdsourcing may make these maps more accurate than historical ones.
I think deprecating these maps would leave the reader at a loss (pictures speak a 1,000 words and all that). Does it get a border crossing wrong here or there? Yes, but the knowledge is largely correct.
It would be an absolute shame to lose access to this knowledge. Magog the Ogre (t • c) 22:59, 19 December 2024 (UTC)
@Magog the Ogre WP:ITSUSEFUL is frowned upon as an argument for good reason. Beyond that: 1) the fact that these are based on fragmentary data is strangely not mentioned at all (Syrian civil war says 'Military situation as of December 18, 2024 at 2:00pm ET' which suggests that it's quite authoritative and should be trusted; the fact that it's based off the ISW is not disclosed.) 2) I'm not seeing where all the information is coming from the ISW. The ISW's map only covers territory, stuff like bridges, dams, "strategic hills" and the like are not present on the ISW map[7]. Where is that info coming from? Der Wohltemperierte Fuchs talk 23:10, 19 December 2024 (UTC)
The Commons Syria map uses both the ISW and Liveuamap. The two are largely in agreement, with Liveuamap being more precise but using less reliable sources. If you have an issue with using Liveuamap as a source, fine, bring it up on the talk pages where it's used, or on the Commons talk page itself. But banning any any map of a conflict is throwing out the baby with the bathwater. The Ukraine map is largely based on ISW-verifiable information.
With regards to actual locations like bridges, I'm against banning Commons users from augmenting maps with easily verifiable landmarks. That definition of SYN is broad to the point of meaningless, as it would apply to any user-generated content that uses more than one source. Magog the Ogre (t • c) 23:50, 20 December 2024 (UTC)
WP:ITSUSEFUL is a perfectly valid argument in some circumstances, like this one. Wikimedia Commons exists to hold images that are useful for the encyclopedia. The only reason to keep an image is if it's useful for articles. (I feel like the whole "Arguments to avoid" essay needs to be rewritten, because almost every argument on that list is valid in some contexts but not others.) – Closed Limelike Curves (talk) 18:45, 27 December 2024 (UTC)
Weak Oppose I've been updating the Ukraine map since May 2022, so I hope my input is helpful. While I agree that some of the sources currently being used to update these maps may be dubious in nature, that has not always been the case. In the past, particularly for the Syria map, these maps have been considered among the most accurate online due to their quality sourcing. It used to be that a source was required for each town if it was to be displayed on these maps, but more recently, people have just accepted taking sources like LivaUAMap and the ISW and copying them exactly. Personally, I think we should keep the maps but change how they are sourced. I think that going back to the old system of requiring a reliable source for each town would clear up most of the issues that you are referring to, though it would probably mean that the maps would be less detailed than they currently are now. Physeters✉ 07:23, 21 December 2024 (UTC)
  • Oppose The campaign maps are one of our absolute best features. The Syrian campaign map in particular was very accurate for much of the war. Having a high quality SVG of an entire country like that is awesome, and there really isn't anything else like it out there, which is why it provides such value to our readers. I think we have to recognize of our course that they're not 100% accurate, due to the fog of war. I wouldn't mind if we created subpages about the maps? Like, with a list of sources and their dates, designed to be reader facing, so that our readers could verify the control of specific towns for themselves. But getting rid of the maps altogether is throwing out the baby with the bathwater. CaptainEek Edits Ho Cap'n!⚓ 23:33, 22 December 2024 (UTC)
  • Oppose, but I do think we need to tighten up the verifiability standards, as @CaptainEek suggests in their spot-on comment :) Maps need to have citations, just like articles do, so readers can verify how reliable the information is. – Closed Limelike Curves (talk) 18:40, 27 December 2024 (UTC)
  • We usually expect articles to use more than one source to help with NPOV. Relaxing that standard for maps does not sound like a particularly good idea. —Kusma (talk) 19:15, 27 December 2024 (UTC)

I wished Wikipedia supported wallpapers in pages...

It would be even more awesome if we could change the wallpaper of pages in Wikipedia. But the fonts' colors could change to adapt to the wallpaper. The button for that might look like this: Change wallpaper Gnu779 (talk) 11:02, 21 December 2024 (UTC)

I think we already tried this. It was called Myspace ;) —TheDJ (talk • contribs) 11:51, 21 December 2024 (UTC)
See Help:User style for information on creating your own stylesheet. isaacl (talk) 18:03, 21 December 2024 (UTC)
@Gnu779: You have successfully nerd-sniped me, so I’m gonna work on a user script for this. JJPMaster (she/they) 22:54, 26 December 2024 (UTC)
Heh heh, great idea! Gnu779 (talk) 10:33, 28 December 2024 (UTC)

Why does the account go out?

Moved to Wikipedia:Village pump (technical) § Why does the account go out?
 – Aaron Liu (talk) 00:29, 29 December 2024 (UTC)

discussion page for reverted articles not talking page on article

If you are making edits with sources an individual disagrees but just reverts with can not be bothered to read sources it would be nice to have somewhere to have a further discussion on the article that isn't the talk page. If you ask for information on the individuals talk page and it's not reply to. You add the information on the articles talk page and ask for a consensus but it's not replied to as it's not looked at a lot. It would be nice for there to be somewhere to discuss the article. I have been asking where to go if articles are being stonewalled. There doesn't seem to be somewhere to bring up the behaviour Sharnadd (talk) 07:15, 30 December 2024 (UTC)

Political bio succession boxes, need streamlining

My goodness, I went through some American politician bios (didn't check other countries) & there's a lot of trivial info added to succession boxes. So called "Honorary titles" - like "Longest living U.S. Senator", "Earliest living American governor", etc. PS - I think these should be deleted. What would be added next? "Tallest Speaker of the House"? GoodDay (talk) 00:50, 31 December 2024 (UTC)

I delete those on sight and you should too. --Surtsicna (talk) 19:06, 31 December 2024 (UTC)

RfC: Enable override-antispoof for importers

QoH has withdrawn the RfC as Graham87 has been granted the account creator permission. Involved closure; if someone objects, reopen this discussion. HouseBlaster (talk • he/they) 04:36, 1 January 2025 (UTC)

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.

Should the override-antispoof permission be enabled for the importer group? charlotte 👸🎄 18:44, 28 December 2024 (UTC)

Support (override-antispoof for importers)

  1. Similar to the RfC on mergehistory for importers from last month, importers sometimes have to create accounts when importing old edits, and those are occasionally too similar to existing users or trigger filter 890 (hist · log) (which I coded a workaround into). Currently, the only rights that have override-antispoof are account creator and sysop; the one non-admin importer, Graham87, had account creator revoked because he was not a member of the account creation team, and override-antispoof would prevent him from having to ask an admin each time. charlotte 👸🎄 18:44, 28 December 2024 (UTC)
  2. Support in principle as the affected user, but I'm also open to less drastic solutions. See below. Graham87 (talk) 07:19, 29 December 2024 (UTC)

Oppose (override-antispoof for importers)

  1. This is too far off from the single-responsibility principle for my taste, especially given that a solution already exists. * Pppery * it has begun... 19:21, 28 December 2024 (UTC)
  2. per Pppery Feeglgeef (talk) 19:52, 28 December 2024 (UTC)
  3. Nah, non-admins that need to create odd accounts could just become account creators, Wikipedia:Account creator isn't a hard policy, it is descriptive. If there is community support for someone not working on the ACC project to have this access, they should be able to hold it. — xaosflux Talk 16:41, 29 December 2024 (UTC)
  4. While I trust Graham to use this power, edit filter 890 already doesn't run on importers, and for the only other scenario—where it's too close to an existing account name—I don't want to risk giving all importers the power to impersonate. As xaosflux said, prospective importers should be able to apply for account creator separately. Aaron Liu (talk) 16:52, 29 December 2024 (UTC)
  5. Oppose Unlike importing and history merging, the link between importing and creating accounts with usernames similar to existing ones is tenuous at best. There is already a solution for importers who genuinely need to do that—the account creator group—and we should not turn the importer group into nothing more than a "Graham87 group." JJPMaster (she/they) 14:31, 31 December 2024 (UTC)

Discussion (override-antispoof for importers)

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.

RfC: Log the use of the HistMerge tool at both the merge target and merge source

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.

Numerically, option 1a has 6 !votes in its favor (4 if we don't count second-choice !votes (Graham87 and Abzeronow), 0 if we only count exclusive !votes), 1b has 10 (7 exclusive), and option 2 has 4. Most of the !votes in support of option 1a were cast early into the RfC before experienced history mergers expressed concerns about how the creation of dummy edits might disturb page histories. No proponent of option 1a replied to these objections, and many later proponents of 1b cited them as justification for not supporting 1a. Thus, option 1a is rejected. Next, we will consider option 2. Proponents of this option primarily cited the purported need for history merging to be seamless, and a dummy edit would disrupt that fact; the aforementioned objection to 1a. However, only one of the proponents of this option attempted to object to 1b specifically (that is, the need for a log entry at the target page), saying that page moves similarly only log at the source page. Proponents of option 1b convincingly replied to this objection by noting that that is less problematic because of the fact that page moves produce a dummy edit, unlike history merges. One additional proponent of option 2 asserted that no MediaWiki developers would be interested in this project. However, this is not a sufficiently strong argument to outweigh those made by proponents of option 1b. The primary argument by its proponents was that the current system wherein history merges are logged only at the source page was confusing, since it requires having access to the source page's title, which is not always the case. Some proponents of opt. 2 objected that you can look at abnormalities such as "Created page with..." edit summaries in the middle of a page history or unusual byte differences to determine that a history merge occurred at the target page. However, this undermines the most common argument for option 2; namely, that history merging ought to be seamless, since only the "seams" left behind by the process can show that a history merge occurred while looking only at the destination page. Thus, I see consensus to request that the developers adopt option 1b. The Phabricator tickets will be updated accordingly. JJPMaster (she/they) 16:38, 29 December 2024 (UTC) I added four words to this closure per phab:T118132#10424866. JJPMaster (she/they) 03:10, 2 January 2025 (UTC)

Currently, there are open phab tickets proposing that the use of the HistMerge tool be logged at the target article in addition to the source article. Several proposals have been made:

  • Option 1a: When using Special:MergeHistory, a null edit should be placed in both the merge target and merge source's page's histories stating that a history merge took place.
    (phab:T341760: Special:MergeHistory should place a null edit in the page's history describing the merge, authored Jul 13 2023)
  • Option 1b: When using Special:MergeHistory, add a log entry recorded for the articles at the both HistMerge target and source that records the existence of a history merge.
    (phab:T118132: Merging pages should add a log entry to the destination page, authored Nov 8 2015)
  • Option 2: Do not log the use of the Special:MergeHistory tool at the merge target, maintaining the current status quo.

Should the use of the HistMerge tool be explicitly logged? If so, should the use be logged via an entry in the page history or should it instead be held in a dedicated log? — Red-tailed hawk (nest) 15:51, 20 November 2024 (UTC)

Survey: Log the use of the HistMerge tool

  • Option 1a/b. I am in principle in support of adding this logging functionality, since people don't typically have access to the source article title (where the histmerge is currently logged) when viewing an article in the wild. There have been several times I can think of when I've been going diff hunting or browsing page history and where some explicit note of a histmerge having occurred would have been useful. As for whether this is logged directly in the page history (as is done currently with page protection) or if this is merely in a separate log file, I don't have particularly strong feelings, but I do think that adding functionality to log histmerges at the target article would improve clarity in page histories. — Red-tailed hawk (nest) 15:51, 20 November 2024 (UTC)
  • Option 1a/b. No strong feelings on which way is best (I'll let the experienced histmergers comment on this), but logging a history merge definitely seems like a useful feature. Chaotic Enby (talk · contribs) 16:02, 20 November 2024 (UTC)
  • Option 1a/b. Choatic Enby has said exactly what I would have said (but more concisely) had they not said it first. Thryduulf (talk) 16:23, 20 November 2024 (UTC)
  • 1b would be most important to me but but 1a would be nice too. But this is really not the place for this sort of discussion, as noted below. Graham87 (talk) 16:28, 20 November 2024 (UTC)
  • Option 2 History merging done right should be seamless, leaving the page indistinguishable from if the copy-paste move being repaired had never happened. Adding extra annotations everywhere runs counter to that goal. Prefer 1b to 1a if we have to do one of them, as the extra null edits could easily interfere with the history merge being done in more complicated situations. * Pppery * it has begun... 16:49, 20 November 2024 (UTC)
    Could you expound on why they should be indistinguishable? I don't see how this could harm any utility. A log action at the target page would not show up in the history anyways, and a null edit would have no effect on comparing revisions. Aaron Liu (talk) 17:29, 20 November 2024 (UTC)
    Why shouldn't it be indistinguishable? Why it it necessary to go out of our way to say even louder that someone did something wrong and it had to be cleaned up? * Pppery * it has begun... 17:45, 20 November 2024 (UTC)
    All cleanup actions are logged to all the pages they affect. Aaron Liu (talk) 18:32, 20 November 2024 (UTC)
  • 2 History merges are already logged, so this survey name is somewhat off the mark. As someone who does this work: I do not think these should be displayed at either location. It would cause a lot of noise in history pages that people probably would not fundamentally understand (2 revisions for "please process this" and "remove tag" and a 3rd revision for the suggested log), and it would be "out of order" in that you will have merged a bunch of revisions but none of those revisions would be nearby the entry in the history page itself. I also find protections noisy in this way as well, and when moves end up causing a need for history merging, you end up with doubled move entries in the merged history, which also is confusing. Adding history merges to that case? No thanks. History merges are more like deletions and undeletions, which already do not add displayed content to the history view. Izno (talk) 16:54, 20 November 2024 (UTC)
    They presently are logged, but only at the source article. Take for example this entry. When I search for the merge target, I get nothing. It's only when I search the merge source that I'm able to get a result, but there isn't a way to know the merge source.
    If I don't know when or if the histmerge took place, and I don't know what article the history was merged from, I'd have to look through the entirety of the merge log manually to figure that out—and that's suboptimal. — Red-tailed hawk (nest) 17:05, 20 November 2024 (UTC)
    ... Page moves do the same thing, only log the move source. Yet this is not seen as an issue? :)
    But ignoring that, why is it valuable to know this information? What do you gain? And is what you gain actually valuable to your end objective? For example, let's take your There have been several times I can think of when I've been going diff hunting or browsing page history and where some explicit note of a histmerge having occurred would have been useful. Is not the revisions left behind in the page history by both the person requesting and the person performing the histmerge not enough (see {{histmerge}})? There are history merges done that don't have that request format such as the WikiProject history merge format, but those are almost always ancient revisions, so what are you gaining there? And where they are not ancient revisions, they are trivial kinds of the form "draft x -> page y, I hate that I even had to interact with this history merge it was so trivial (but also these are great because I don't have to spend significant time on them)". Izno (talk) 17:32, 20 November 2024 (UTC)

    ... Page moves do the same thing, only log the move source. Yet this is not seen as an issue? :)

    I don't think everyone would necessarily agree (see Toadspike's comment below). Chaotic Enby (talk · contribs) 17:42, 20 November 2024 (UTC)
    Page moves do leave a null edit on the page that describes where the page was moved from and was moved to. And it's easy to work backwards from there to figure out the page move history. The same cannot be said of the Special:MergeHistory tool, which doesn't make it easy to re-construct what the heck went on unless we start diving naïvely through the logs. — Red-tailed hawk (nest) 17:50, 20 November 2024 (UTC)
    It can be *possible* to find the original history merge source page without looking through the merge log, but the method for doing so is very brittle and extremeley hacky. Basically, look for redirects to the page using "What links here", and find the redirect whose first edit has an unusual byte difference. This relies on the redirect being stable and not deleted or retargetted. There is also another way that relies on byte difference bugs as described in the above-linked discussion by wbm1058. Both of those are ... particularly awful. Graham87 (talk) 03:48, 21 November 2024 (UTC)
    In the given example, the history-merge occurred here. Your "log" is the edit summaries. "Created page with '..." is the edit summary left by a normal page creation. But wait, there is page history before the edit that created the page. How did it get there? Hmm, the previous edit summary "Declining submission: v - Submission is improperly sourced (AFCH)" tips you off to look for the same title in draft: namespace. Voila! Anyone looking for help with understanding a particular merge may ask me and I'll probably be able to figure it out for you. – wbm1058 (talk) 05:51, 21 November 2024 (UTC)
    Here's another example, of a merge within mainspace. The automatic edit summary (created by the MediaWiki software) of this (No difference) diff "Removed redirect to Jordan B. Acker" points you to the page that was merged at that point. Voila. Voila. Voila. – wbm1058 (talk) 13:44, 21 November 2024 (UTC)
    There are times where those traces aren't left. Aaron Liu (talk) 13:51, 21 November 2024 (UTC)
    Here's another scenario, this one from WP:WikiProject History Merge. The page history shows an edit adding +5,800 bytes, leaving the page with 5,800 bytes. But the previous edit did not leave a blank page. Some say this is a bug, but it's also a feature. That "bug" is actually your "log" reporting that a hist-merge occurred at that edit. Voila, the log for that page shows a temp delete & undelete setting the page up for a merge. The first item on the log:
    @ 20:14, 16 January 2021 Tbhotch moved page Flag of Yucatán to Flag of the Republic of Yucatán (Correct name)
    clues you in to where to look for the source of the merge. Voila, that single edit which removed −5,633 bytes tells you that previous history was merged off of that page. The log provides the details. – wbm1058 (talk) 16:03, 21 November 2024 (UTC)
    (phab:T76557: Special:MergeHistory causes incorrect byte change values in history, authored Dec 2 2014) — Preceding unsigned comment added by Wbm1058 (talk • contribs) 18:13, 21 November 2024 (UTC)
    Again, there are times where the clues are much harder to find, and even in those cases, it'd be much better to have a unified and assured way of finding the source. Aaron Liu (talk) 16:11, 21 November 2024 (UTC)
    Indeed. This is a prime example of an unintended undocumented feature. Graham87 (talk) 08:50, 22 November 2024 (UTC)
    Yeah. I don't think that we can permanently rely on that, given that future versions of MediaWiki are not bound in any real way to support that workaround. — Red-tailed hawk (nest) 04:24, 3 December 2024 (UTC)
  • Support 1b (log only), oppose 1a (null edit). I defer to the experienced histmergers on this, and if they say that adding null edits everywhere would be inconvenient, I believe them. However, I haven't seen any arguments against logging the histmerge at both articles, so I'll support it as a sensible idea. (On a similar note, it bothers me that page moves are only logged at one title, not both.) Toadspike [Talk] 17:10, 20 November 2024 (UTC)
  • Option 2. The merges are already logged, so there’s no reason to add it to page histories. While it may be useful for habitual editors, it will just confuse readers who are looking for an old revision and occasional editors. Ships & Space(Edits) 18:33, 20 November 2024 (UTC)
    But only the source page is logged as the "target". IIRC it currently can be a bit hard to find out when and who merged history into a page if you don't know the source page and the mergeperson didn't leave any editing indication that they merged something. Aaron Liu (talk) 18:40, 20 November 2024 (UTC)
  • 1B. The present situation of the action being only logged at one page is confusing and unhelpful. But so would be injecting null-edits all over the place.  — SMcCandlish ☏ ¢ 😼  01:38, 21 November 2024 (UTC)
  • Option 2. This exercise is dependent on finding a volunteer MediaWiki developer willing to work on this. Good luck with that. Maybe you'll find one a decade from now. – wbm1058 (talk) 05:51, 21 November 2024 (UTC)
    And, more importantly, someone in the MediaWiki group to review it. I suspect there are many people, possibly including myself, who would code this if they didn't think they were wasting their time shuffling things from one queue to another. * Pppery * it has begun... 06:03, 21 November 2024 (UTC)
    That link requires a Gerrit login/developer account to view. It was a struggle to get in to mine (I only have one because of an old Toolforge account and I'd basically forgotten about it), but for those who don't want to go through all that, that group has only 82 members (several of whose usernames I recognise) and I imagine they have a lot on their collective plate. There's more information about these groups at Gerrit/Privilege policy on MediaWiki. Graham87 (talk) 15:38, 21 November 2024 (UTC)
    Sorry, I totally forgot Gerrit behaved in that counterintuitive way and hid public information from logged out users for no reason. The things you miss if Gerrit interactions become something you do pretty much every day. If you want to count the members of the group you also have to follow the chain of included groups - it also includes https://ldap.toolforge.org/group/wmf, https://ldap.toolforge.org/group/ops and the WMDE-MediaWiki group (another login-only link), as well as a few other permission edge cases (almost all of which are redundant because the user is already in the MediaWiki group) * Pppery * it has begun... 18:07, 21 November 2024 (UTC)
  • Support 1a/b, and I would encourage the closer to disregard any opposition based solely on the chances of someone ever actually implementing it. —Compassionate727 (T·C) 12:52, 21 November 2024 (UTC)
    Fine. This stupid RfC isn't even asking the right questions. Why did I need to delete (an expensive operation) and then restore a page in order to "set up for a history merge" Should we fix the software so that it doesn't require me to do that? Why did the page-mover resort to cut-paste because there was page history blocking their move, rather than ask a administrator for help? Why doesn't the software just let them move over that junk page history themselves, which would negate the need for a later hist-merge? (Actually in this case the offending user only has made 46 edits, so they don't have page-mover privileges. But they were able to move a page. They just couldn't move it back a day later after they changed their mind.) wbm1058 (talk) 13:44, 21 November 2024 (UTC)
    Yeah, revision move would be amazing, for a start. Graham87 (talk) 15:38, 21 November 2024 (UTC)
  • Option 1b – changes to a page's history should be listed in that page's log. There's no need to make a null edit; pagemove null edits are useful because they meaningfully fit into the page's revision history, which isn't the case here. jlwoodwa (talk) 00:55, 22 November 2024 (UTC)
  • Option 1b sounds best since that's what those in the know seem to agree on, but 1a would probably be OK. Abzeronow (talk) 03:44, 23 November 2024 (UTC)
  • Option 1b seems like the one with the best transparency to me. Thanks. Huggums537voted! (sign🖋️|📞talk) 06:59, 25 November 2024 (UTC)

Discussion: Log the use of the HistMerge tool

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.

Allowing page movers to enable two-factor authentication

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Tracked in Phabricator
Task T382879
Resolved
Consensus to assign oathauth-enable to the (extendedmover) group, giving page movers the option to enable two-factor authentication. SilverLocust 💬 11:43, 2 January 2025 (UTC)

I would like to propose that members of the page mover user group be granted the oathauth-enable permission. This would allow them to use Special:OATH to enable two-factor authentication on their accounts.

Rationale (2FA for page movers)

The page mover guideline already obligates people in that group to have a strong password, and failing to follow proper account security processes is grounds for revocation of the right. This is because the group allows its members to (a) move pages along with up to 100 subpages, (b) override the title blacklist, and (c) have an increased rate limit for moving pages. In the hands of a vandal, these permissions could allow significant damage to be done very quickly, which is likely to be difficult to reverse.

Additionally, there is precedent for granting 2FA access to users with rights that could be extremely dangerous in the event of account compromise, for instance, template editors, importers, and transwiki importers have the ability to enable this access, as do most administrator-level permissions (sysop, checkuser, oversight, bureaucrat, steward, interface admin).

Discussion (2FA for page movers)

  • Support as proposer. JJPMaster (she/they) 20:29, 12 December 2024 (UTC)
  • Support (but if you really want 2FA you can just request permission to enable it on Meta) * Pppery * it has begun... 20:41, 12 December 2024 (UTC)
    For the record, I do have 2FA enabled. JJPMaster (she/they) 21:47, 12 December 2024 (UTC)
    Oops, that says you are member of "Two-factor authentication testers" (testers = good luck with that). Johnuniq (talk) 23:52, 14 December 2024 (UTC)
    A group name which is IMO seriously misleading - 2FA is not being tested, it's being actively used to protect accounts. * Pppery * it has begun... 23:53, 14 December 2024 (UTC)
    meta:Help:Two-factor authentication still says "currently in production testing with administrators (and users with admin-like permissions like interface editors), bureaucrats, checkusers, oversighters, stewards, edit filter managers and the OATH-testers global group." Hawkeye7 (discuss) 09:42, 15 December 2024 (UTC)
  • Support as a pagemover myself, given the potential risks and need for increased security. I haven't requested it yet as I wasn't sure I qualified and didn't want to bother the stewards, but having oathauth-enable by default would make the process a lot more practical. Chaotic Enby (talk · contribs) 22:30, 12 December 2024 (UTC)
    Anyone is qualified - the filter for stewards granting 2FA is just "do you know what you're doing". * Pppery * it has begun... 22:46, 12 December 2024 (UTC)
  • Question When's the last time a page mover has had their account compromised and used for pagemove vandalisn? Edit 14:35 UTC: I'm not doubting the nom, rather I'm curious and can't think of a better way to phrase things. JayCubby 02:30, 13 December 2024 (UTC)
  • Why isn't everybody allowed to enable 2FA? I've never heard of any other website where users have to go request someone's (pro forma, rubber-stamp) permission if they want to use 2FA. And is it accurate that 2FA, after eight years, is still "experimental" and "in production testing"? I guess my overall first impression didn't inspire me with confidence in the reliability and maintenance. Adumbrativus (talk) 06:34, 14 December 2024 (UTC)
    For TOTP (the 6-digit codes), it's not quite as bad as when it was written, as the implementation has been fixed over time. I haven't heard nearly as many instances of backup scratch codes not working these days compared to when it was new. The WebAuthn (physical security keys, Windows Hello, Apple Face ID, etc) implementation works fine on private wikis but I wouldn't recommend using it for CentralAuth, especially with the upcoming SUL3 migration. There's some hope it'll work better afterward, but will still require some development effort. As far as I'm aware, WMF is not currently planning to work on the 2FA implmentation.
    As far as risk for page mover accounts goes, they're at a moderate risk. Page move vandalism, while annoying to revert, is reversible and is usually pretty loud (actions of compromised accounts can be detected and stopped easily). The increased ratelimit is the largest concern, but compared to something like account creator (which has noratelimit) it's not too bad. I'm more concerned about new page reviewer. There probably isn't a ton of harm to enabling 2FA for these groups, but there isn't a particularly compelling need either. AntiCompositeNumber (talk) 12:47, 19 December 2024 (UTC)
  • Support per nom. PMV is a high-trust role (suppressredirect is the ability to make a blue link turn red), and thus this makes sense. As a side note, I have changed this to bulleted discussion; # is used when we have separate sections for support and oppose. HouseBlaster (talk • he/they) 07:19, 14 December 2024 (UTC)
  • Oppose As a pagemover myself, I find pagemover is an extremely useful and do not wish to lose it. It is nowhere near the same class as template editor. You can already ask the stewards for 2FA although I would recommend creating a separate account for the purpose. After all these years, 2FA remains experimental, buggy and cumbersome. Incompatible with the Microsoft Authenticator app on my iphone. Hawkeye7 (discuss) 23:59, 14 December 2024 (UTC)
    The proposal (as I read it) isn't "you must have 2FA", rather "you have the option to add it". Lee Vilenski (talk • contribs) 00:06, 15 December 2024 (UTC)
    @Hawkeye7, Lee Vilenski is correct. This would merely provide page movers with the option to enable it. JJPMaster (she/they) 00:28, 15 December 2024 (UTC)
    Understood, but I do not want it associated with an administrator-level permission, which would mean I am not permitted to use it, as I am not an admin. Hawkeye7 (discuss) 09:44, 15 December 2024 (UTC)
    It's not really that. It would be an opt-in to allow users (in the group) to put 2FA on their account - at their own digression.
    The main reasons why 2FA is currently out to admins and the like is because they are more likely to be targeted for compromising and are also more experienced. The 2FA flag doesn't require any admin skills/tools and is only incedentally linked. Lee Vilenski (talk • contribs) 12:58, 15 December 2024 (UTC)
    Wait, so why is 2FA not an option for everyone already? – Closed Limelike Curves (talk) 01:15, 18 December 2024 (UTC)
    @Closed Limelike Curves the MediaWiki's 2FA implementation is complex, and the WMF's processes to support people who get locked out of their account aren't able to handle a large volume of requests (developers can let those who can prove they are the owner of the account back in). My understanding is that the current processes cannot be efficiently scaled up either, as it requires 1:1 attention from a developer, so unless and until new processes have been designed, tested and implemented 2FA is intended to be restricted to those who understand how to use it correctly and understand the risks of getting locked out. Thryduulf (talk) 09:36, 18 December 2024 (UTC)
  • It probably won't make a huge difference because those who really desire 2FA can already request the permission to enable it for their account, and because no page mover will be required to do so. However, there will be page movers who wouldn't request a global permission for 2FA yet would enable it in their preferences if it was a simple option. And these page movers might benefit from 2FA even more than those who already care very strongly about the security of their account. ~ ToBeFree (talk) 03:18, 15 December 2024 (UTC)
  • Support and I can't think of any argument against something not only opt-in but already able to be opted into. Gnomingstuff (talk) 08:09, 15 December 2024 (UTC)
  • Oppose this is a low value permission, not needed. If an individual PMV really wants to opt-in, they can already do so over at meta - no need to build custom configuration for this locally. — xaosflux Talk 15:06, 18 December 2024 (UTC)
  • Support; IMO all users should have the option to add 2FA. Stifle (talk) 10:26, 19 December 2024 (UTC)
  • Support All users should be able to opt in to 2FA. Lack of a scalable workflow for users locked out of their accounts is going to be addressed by WMF only if enough people are using 2FA (and getting locked out?) to warrant its inclusion in the product roadmap. – SD0001 (talk) 14:01, 19 December 2024 (UTC)
    That (and to @Stifle above) sounds like an argument to do just that - get support put in place and enable this globally, not to piecemeal it in tiny batches for discretionary groups on a single project (this custom configuration would support about 3/10ths of one percent of our active editors). To the point of this RFC, why do you think adding this for this specific tiny group is a good idea? — xaosflux Talk 15:40, 19 December 2024 (UTC)
    FWIW, I tried to turn this on for anyone on meta-wiki, and the RFC failed (meta:Meta:Requests for comment/Enable 2FA on meta for all users). — xaosflux Talk 21:21, 19 December 2024 (UTC)
    Exactly. Rolling it out in small batches helps build the case for a bigger rollout in the future. – SD0001 (talk) 05:24, 20 December 2024 (UTC)
    I'm pretty sure that 2FA is already available to anyone. You just have to want it enough to either request it "for testing purposes" or to go to testwiki and request that you made an admin there, which will automatically give you access. See H:ACCESS2FA. WhatamIdoing (talk) 23:41, 21 December 2024 (UTC)
    We shouldn't have to jump through borderline manipulative and social-engineering hoops to get basic security functionality.  — SMcCandlish ☏ ¢ 😼  04:40, 22 December 2024 (UTC)
  • Oppose. It sounds like account recovery when 2FA is enabled involves Trust and Safety. I don't think page movers' account security is important enough to justify increasing the burden on them. —Compassionate727 (T·C) 14:10, 21 December 2024 (UTC)
    Losing access to the account is less common nowadays since most 2FA apps, including Google Authenticator, have implemented cloud syncing so that even if you lose your phone, you can still access the codes from another device. – SD0001 (talk) 14:40, 21 December 2024 (UTC)
    But this isn't about Google Authenticator. Johnuniq (talk) 02:58, 22 December 2024 (UTC)
    Google Authenticator is a 2FA app, which at least till some point used to be the most popular one. – SD0001 (talk) 07:07, 22 December 2024 (UTC)
    But (I believe), it is not available for use at Wikipedia. Johnuniq (talk) 07:27, 22 December 2024 (UTC)
    That's not true. You can use any TOTP authenticator app for MediaWiki 2FA. I currently use Ente Auth, having moved on from Authy recently, and from Google Authenticator a few years back.
    In case you're thinking of SMS-based 2FA, it has become a thing of the past and is not supported by MediaWiki either because it's insecure (attackers have ways to trick your network provider to send them your texts). – SD0001 (talk) 09:19, 22 December 2024 (UTC)
  • Support. Even aside from the fact that, in 2024+, everyone should be able to turn on 2FA .... Well, absolutely certainly should everyone who has an advanced bit, with potential for havoc in the wrong hands, be able to use 2FA here. That also includes template-editor, edit-filter-manager, file-mover, account-creator (and supersets like event-coordinator), checkuser (which is not strictly tied to adminship), and probably also mass-message-sender, perhaps a couple of the others, too. Some of us old hands have several of these bits and are almost as much risk as an admin when it comes to loss of account control.  — SMcCandlish ☏ ¢ 😼  04:40, 22 December 2024 (UTC)
    Take a look at Special:ListGroupRights - much of what you mentioned is already in place, because these are groups that could use it and are widespread groups used on most WMF projects. (Unlike extendedmover). — xaosflux Talk 17:22, 22 December 2024 (UTC)
    Re That also includes [...], file-mover, account-creator (and supersets like event-coordinator), [...] and probably mass-message-sender. How can in any way would file mover, account creator, event coordinator and mass message sender user groups be considered privileged, and therefore have the oathauth-enable userright? ToadetteEdit (talk) 17:37, 24 December 2024 (UTC)
  • Comment: It is really not usual for 2FA to be available to a user group that is not defined as privileged in the WMF files. By default, all user groups defined at CommonSettings.php (iirc) that are considered to be privileged have the oathauth-enable right. Also, the account security practices mentioned in wp:PGM are also mentioned at wp:New pages patrol/Reviewers, despite not being discussed at all. Shouldn't it be fair to have the extendedmover userright be defined as privileged. ToadetteEdit (talk) 08:33, 23 December 2024 (UTC)
    Regardless, I will support per the above comments. Page mover rights are sensitive and can disrupt the encyclopedia (though not as large as template editor/administrator would). I do see people supporting the idea of 2FA for all, but I think this needs to be reconsider in another discussion because it was discussed a lot previously and never gain implementation. ToadetteEdit (talk) 18:12, 28 December 2024 (UTC)
  • Support. Like SMcCandlish, I'd prefer that anyone, and particularly any editor with advanced perms, be allowed to turn on 2FA if they want (this is already an option on some social media platforms). But this is a good start, too.
    Since this is a proposal to allow page movers to opt in to 2FA, rather than a proposal to mandate 2FA for page movers, I see no downside in doing this. – Epicgenius (talk) 17:02, 23 December 2024 (UTC)
  • Support this opt-in for PMs and the broader idea of everyone having it by default. Forgive me if this sounds blunt, but is the responsibility and accountability of protecting your account lie on you and not WMF. Yes, they can assist in recovery, but the burden should not lie on them. ~/Bunnypranav:<ping> 17:13, 23 December 2024 (UTC)
    What about users who are unable to enable 2FA, which requires either multiple devices or fancy gizmos? Cremastra 🎄 u — c 🎄 17:33, 28 December 2024 (UTC)
    @Cremastra I have mentioned to give the choice to turn 2FA on for everyone. No comments to mandate it for PMs.
    Also, 2FA is easy to enable on every mobile phone (which is not a fancy gizmo, I believe everyone here has access to one?). ~/Bunnypranav:<ping> 07:16, 29 December 2024 (UTC)
    Then what do you mean by "everyone having it by default"? Cremastra 🎄 u — c 🎄 16:20, 29 December 2024 (UTC)
    Everyone has the ability to turn it on ~/Bunnypranav:<ping> 10:46, 30 December 2024 (UTC)
    Okay, sorry. I misread your comment as everyone having it [2FA] by default, not everyone having it [opt-in to 2FA] by default.
    Happy new year, Cremastra 🎄 u — c 🎄 19:53, 31 December 2024 (UTC)
  • Allow 2FA for en-wiki users with verified emails. I can't think of any other website that gates 2FA behind special permissions - it's a bizarre security practice. I hear the concerns about T&S needing to get involved for account recovery, but if the user has a verified email address that shouldn't be necessary. – Anne drew 15:43, 27 December 2024 (UTC)
  • Oppose security is good, but pagemoving isn't an area where increased security will lead to any sort of improvement. I'm a pagemover and I certainly don't want to go through that hassle everytime I log in, which can be several times a day because I edit from different (at home) devices. Headbomb {t · c · p · b} 19:43, 31 December 2024 (UTC)
    The proposal is for allowing page movers to enable 2FA, not forcing them to do so. – SD0001 (talk) 21:37, 31 December 2024 (UTC)
  • Support as an option, sure, seems beneficial. Those who are against it can simply opt out. – Aza24 (talk) 22:02, 31 December 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Appearance setting to hide all inline notes from articles

While disabled by default, enabling it would hide all those [1][2][3], [a][b][c] and even [citation needed][original research?] inline notes from all articles, which makes reading Wikipedia more clearer, especially when reading about controversial topics. Those citation notes can be a distraction for some, so that's why i am proposing such a feature like this. 176.223.184.242 (talk) 12:37, 30 December 2024 (UTC)

Adding sup { display: none !important; } to your user CSS should do the job! (see also WP:CSSHIDE) Chaotic Enby (talk · contribs) 12:49, 30 December 2024 (UTC)
Yep. I'd oppose making it a default setting, though. I don't want to dictate to the IP how they should use Wikipedia or discount their experience, but those notes are vital for information literacy. If the IP is reading about controversial topics without them, they're risking exposing themselves to misinformation. Sdkb talk 17:18, 30 December 2024 (UTC)
Agreed! If anything, it is far more vital to have those inline references/citations when reading controversial information. This is even more critical for tags like citation needed/OR/etc because without them the reader is likely to take the statement as generally accepted fact instead of with the grain of salt that should be applied when such a tag has been added. TiggerJay (talk) 17:31, 30 December 2024 (UTC)
This reminds me of proposals made long ago to move all maintenance templates to the talk pages so that readers wouldn't be exposed to how messy and unreliable article content actually is. Donald Albury 19:57, 30 December 2024 (UTC)
I'd personally advise against enabling this, IP. Things tagged with [citation needed] may be just flat-out wrong. Cremastra 🎄 u — c 🎄 19:57, 31 December 2024 (UTC)
What about a third option to keep citation needed tags while hiding actual citations?
  • Show all inline notes
  • Show only inline maintenance notices
  • Hide all inline notes
176.223.186.27 (talk) 21:58, 1 January 2025 (UTC)
To build on what Donald Albury is saying, I think the readers should be reminded of how messy Wikipedia is. I just added a citation this afternoon, not only because I want the article's regulars to find an additional source but also because I want the readers to see the tag and know that the content is not sufficiently sourced at this time. (I believe in general that people should be more vigilant about assessing the reliability of what they read, and not only here on the Wiki.) If anyone does donate their time and trouble to make a way for readers to opt out of seeing ref tags and maintenance tags, I would oppose making it the default. Darkfrog24 (talk) 22:31, 3 January 2025 (UTC)

Collaboration with PubPeer

Dear all, Over the past few months, I have been in contact with the team managing PubPeer - a website that allows users to discuss and review scientific research after publication, i.e. post-publication peer review - to explore a potential collaboration with Wikipedia. After reviewing some data regarding citations (e.g., the DOIs cited in English (20%), Spanish, French, and Italian Wikipedia), they agreed, in principle, to share data about papers with PubPeer comments that are also used as sources in Wikipedia. From our calculations on a sample of 20% of the citations in enwiki, we estimate that there are around 5,000 unique DOIs cited in Wikipedia that may have PubPeer comments. This message is intended to brainstorm some possible ways to use this data in the project. Here are some of my initial ideas:

  1. Create a bot that periodically (weekly? monthly?) fetches data about papers cited in Wikipedia with PubPeer comments and leaves a note on the Talk page of articles using these sources. The note could say something like, "There are PubPeer comments related to articles X, Y, Z used as sources in this article."
  2. Develop a gadget that replicates the functionality of the PubPeer browser extensions.

Let me know your thoughts on these ideas and how we could move forward. --CristianCantoro (talk) 00:02, 29 December 2024 (UTC)

How would this be valuable to Wikipedia? Izno (talk) 00:45, 29 December 2024 (UTC)
PubPeer is a post-publication peer review forum. Most of the discussions over there report issues with papers. Knowing that a paper that is used as a source has comments on PubPeer is very valuable, IMHO, as It would be useful for editors to evaluate the quality of the source and decide if it makes sense to keep using it. Paper retractions are also reported on PubPeer (see an example), and the PubPeer extension marks retracted papers in red. Basically the idea is to replicate the functionality of the PubPeer extension for editors that don't have it. Furthermore, PubPeer IDs are registered in Wikidata. --CristianCantoro (talk) 18:14, 29 December 2024 (UTC)
But we cite information from reliable sources. I don't see why we'd want a list of people saying they don't think a publication is good, we'd want those sources addressed, surely? Lee Vilenski (talk • contribs) 18:28, 29 December 2024 (UTC)
I think the point is that an article with a lot of PubPeer commentary is quite likely not to be a reliable source. – Joe (talk) 20:55, 29 December 2024 (UTC)
@Lee Vilenski, PubPeer is exactly a forum where issues with papers are raised, and the authors also have the opportunity to address the concerns. While a source such as a well-established scientific journal is generally reliable, we do not know anything about the quality of a specific paper. To me, knowing that there are comments on PubPeer about a paper is valuable because, in general, those comments are not just about "I like/dislike this paper;" instead, they usually raise good points about the paper that I think would provide valuable context to a Wikipedia editor who is trying to determine whether a given paper is a good source or not. PubPeer is regularly used by the community of "scientific sleuths" looking for manipulated or fabricated image and data as you can read in this press article: "A once-ignored community of science sleuths now has the research community on its heels" (there are many other examples) --CristianCantoro (talk) 21:26, 29 December 2024 (UTC)
This does seem like it could be very useful for users interested in the quality of research. I think a gadget highlighting DOIs would be most useful, but using a bot to tag affected pages with a template that adds them to a maintenance category (like this one) would also be a great idea. Toadspike [Talk] 22:35, 29 December 2024 (UTC)
I think this is a great idea. A bot-maintained notification and maintenance category would be a great starting point. As for a gadget, there are already several tools aimed at highlighting potential reliability issues in citations (e.g. User:SuperHamster/CiteUnseen, User:Headbomb/unreliable) so I think it would be better to try and get PubPeer functionality incorporated into them than start a new one. – Joe (talk) 10:13, 30 December 2024 (UTC)
Respectfully, I don't really think that collaborating with a website and using its number of user-generated comments to decide of the reliability of our sources is the best idea. While being informed of comments that have been made on the articles could be helpful, placing every article whose source have PubPeer comments in a maintenance category amounts to saying these sources are automatically a problem to be fixed, and that shouldn't be a call left to commenters of another website. Chaotic Enby (talk · contribs) 11:57, 30 December 2024 (UTC)
Why not? I don't think there's any realistic prospect of doing it internally. – Joe (talk) 12:32, 30 December 2024 (UTC)
Putting an article in a maintenance category because a user-generated review website made comments on a source is clearly not the level of source assessment quality we're striving for. Plus, there's the risk of things like canvassing or paid reviews happening on that other website, as they don't have the same policies that we do, but impact the (perceived) article quality here by tagging these sources as problems to be fixed. Chaotic Enby (talk · contribs) 12:39, 30 December 2024 (UTC)
I believe the proposal is to add the talk page to a category (because it's attached to a talk page message), and not to do any tagging, so this would be pretty much invisible to readers. It would just be a prompt for editors to assess the reliability of the source, not a replacement for source assessments. PubPeer is also not really a "review" website but a place where people (in practice mostly other scientists) can comment on potential errors and misconduct in scientific papers, so the risk of abuse, while present, seems very slight. Who would benefit from it? – Joe (talk) 14:06, 30 December 2024 (UTC)
That does make sense, thanks. I thought there could be cases where competing research teams might try to use it to discredit their opponents' papers, especially if it leads to visible Wikipedia messages, but if it is only a category on the talk page that is invisible for the readers, that sounds like a quite sensible idea. Chaotic Enby (talk · contribs) 17:45, 30 December 2024 (UTC)
Hi @Chaotic Enby, the idea is to have the information readily available in the talk page, and that would make our editors' life easier. In the end, it is just a matter of having some links in the talk page that an editor can check, if they want. Furthermore, I second the comment above from @Joe, PubPeer is very much used to report serious flaws with studies: a study from 2021 analyzed around 40,000 posts about 25,000 publications and found that "more than two-thirds of comments are posted to report some type of misconduct, mainly about image manipulation.". Take a tour on PubPeer and see for yourself. --CristianCantoro (talk) 15:40, 30 December 2024 (UTC)
I often cite scientific studies when I'm writing Froggy of the Day. It sounds like it would be remotely possible to make a bot or tool that could flag sources that have > howevermany comments on Pub Peer.
I often think about Wikipedia's mission to curate rather than create knowledge in terms of the sugar vs fat debate in nutrition. At the time Wikipedia was founded, the prevailing idea was that fat was more fattening in sugar with respect to human beings gaining or losing weight. In the years since, much of that was found to have been a promotional campaign by the sugar industry. It is not Wikipedia's place to contradict established scientific information even when individual Wikipedians know better but rather to wait until newer and better reliable sources are published. Such a tool could help us do that more quickly. Darkfrog24 (talk) 22:38, 3 January 2025 (UTC)
I think some sort of collaboration might be useful, but I don't want talk page notices clogging up my watchlist. Perhaps something that can complement existing userscripts that highlight source reliability would be good. voorts (talk/contributions) 00:39, 4 January 2025 (UTC)

Remove Armenia-Azerbaijan general community sanctions

Opening this discussion is itself a violation of GS/AA, as SimpleSubCubicGraph is not extended-confirmed. Initial response from community members with standing to discuss these topics has been unanimously opposed so I see no reason to leave this open. signed, Rosguill talk 01:25, 4 January 2025 (UTC)

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

I believe Armenia and Azerbaijan sanction is now outdated and useless. I propose that the sanction on the two nations be removed permanently unless another diplomatic crisis happens between the two countries. My reasons are: A recent statement was made by Armenia offering condolences to Azerbaijan which has almost never happened, I believe that Armenia and Azerbaijan related pages blanket protection of Extended Confirmed should be lowered to Autoconfirmed protection, with the exception of the wars between the two sovereign nations. Additionally, relations are getting better between the two countries. For nearly 30 years, relations were rock bottom, diplomats were not found in Azerbaijan nor Armenia and tensions were at an all time high. However ever since the 2020 war the two nations have started to make amends. This first started with the peace deal ending the war between the two nations. Turkey whom is a staunch ally of Azerbaijan has started to resume direct flights from Yerevan, the capital of Armenia and Istanbul, the largest city in the Republic of Turkiye. In 2023, Armenia and Azerbaijan entered into extensive bilateral negotiations as well as a prisoner exchange between the two countries, and Armenia supported Azerbaijan for being the host of the UN climate change forum. Finally, last year the two countries solved many border issues and created a transport route between the two countries which is a symbol of peace. The two nations are much better off now than they were just 4 years ago and can be seen as having a cooperative/reconciling attitude. That is why I propose an amendment that will immediately downgrade all protections (from ECP to ACP) for all Armenia-Azerbaijan related pages. SimpleSubCubicGraph (talk) 00:31, 4 January 2025 (UTC)

  • Notified: Wikipedia:Administrators' noticeboard. voorts (talk/contributions) 00:53, 4 January 2025 (UTC)
  • Oppose. This statement does not provide an adequate or relevant reason for vacating WP:GS/AA's ECR remedy. Community sanctions are related to the conduct of editors on Wikipedia, not the conduct of international affairs. Since page and editor sanctions are regularly issued pursuant to GS/AA and CT/A-A, there is still a clear need for ECR. voorts (talk/contributions) 00:46, 4 January 2025 (UTC)
    @Voorts Response Well I believe that the editors that cause edit conflicts and wars are mostly Armenian, Azerbaijani, or Turkish. They feel patriotic of their country and their side and have vilified the other side in their head, but with calming geopolitical tensions I believe that these editors will no longer feel the need to edit war on wikipedia. Its the same reason why you do not see British people edit warring on the page for the United States of America over the loss in the Independence War. Geopolitical relations between Great Britain and the United States of America are good. SimpleSubCubicGraph (talk) 00:52, 4 January 2025 (UTC)
    But you do see Armenian/Azerbaijani people edit warring on pages about Armenia/Azerbaijan still. JJPMaster (she/they) 00:56, 4 January 2025 (UTC)
    To add further context, you're correct that we don't have any sanctions regarding the US War of Independence. However, we do have sanctions regarding other historical topics, including anti-Semitism in Poland around World War II (WP:APL) and The Troubles (WP:CT/TT). As such, just because country leadership may communicate a lack of conflict doesn't mean editors on Wikipedia immediately edit within policy and treat each other with civility. Significa liberdade (she/her) (talk) 01:24, 4 January 2025 (UTC)
  • Per Voorts, GS/AA is enacted in response to the actions of editors. Real world diplomatic activity is not directly relevant. CMD (talk) 01:01, 4 January 2025 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Revise Wikipedia:INACTIVITY

There is consensus against this proposal. JJPMaster (she/they) 17:48, 4 January 2025 (UTC)

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.

Point 1 of Procedural removal for inactive administrators which currently reads "Has made neither edits nor administrative actions for at least a 12-month period" should be replaced with "Has made no administrative actions for at least a 12-month period". The current wording of 1. means that an Admin who takes no admin actions keeps the tools provided they make at least a few edits every year, which really isn't the point. The whole purpose of adminship is to protect and advance the project. If an admin isn't using the tools then they don't need to have them. Mztourist (talk) 07:47, 4 December 2024 (UTC)

Endorsement/Opposition (Admin inactivity removal)

  • Support as proposer. Mztourist (talk) 07:47, 4 December 2024 (UTC)
  • Oppose - this would create an unnecessary barrier to admins who, for real life reasons, have limited engagement for a bit. Asking the tools back at BN can feel like a faff. Plus, logged admin activity is a poor guide to actual admin activity. In some areas, maybe half of actions aren't logged? —Femke 🐦 (talk) 19:17, 4 December 2024 (UTC)
  • Oppose. First, not all admin actions are logged as such. One example which immediately comes to mind is declining an unblock request. In the logs, that's just a normal edit, but it's one only admins are permitted to make. That aside, if someone has remained at least somewhat engaged with the project, they're showing they're still interested in returning to more activity one day, even if real-life commitments prevent them from it right now. We all have things come up that take away our available time for Wikipedia from time to time, and that's just part of life. Say, for example, someone is currently engaged in a PhD program, which is a tremendously time-consuming activity, but they still make an edit here or there when they can snatch a spare moment. Do we really want to discourage that person from coming back around once they've completed it? Seraphimblade Talk to me 21:21, 4 December 2024 (UTC)
    We could declare specific types of edits which count as admin actions despite being mere edits. It should be fairly simple to write a bot which checks if an admin has added or removed specific texts in any edit, or made any of specific modifications to pages. Checking for protected edits can be a little harder (we need to check for protection at the time of edit, not for the time of the check), but even this can be managed. Edits to pages which match specific regular expression patterns should be trivial to detect. Animal lover |666| 11:33, 9 December 2024 (UTC)
  • Oppose There's no indication that this is a problem needs fixing. ⇒SWATJester Shoot Blues, Tell VileRat! 00:55, 5 December 2024 (UTC)
  • Support Admins who don't use the tools should not have the tools. * Pppery * it has begun... 03:55, 5 December 2024 (UTC)
  • Oppose While I have never accepted "not all admin actions are logged" as a realistic reason for no logged actions in an entre year, I just don't see what problematic group of admins this is in response to. Previous tweaks to the rules were in response to admins that seemed to be gaming the system, that were basically inactive and when they did use the tools they did it badly, etc. We don't need a rule that ins't pointed a provable, ongoing problem. Just Step Sideways from this world ..... today 19:19, 8 December 2024 (UTC)
  • Oppose If an admin is still editing, it's not unreasonable to assume that they are still up to date with policies, community norms etc. I see no particular risk in allowing them to keep their tools. Scribolt (talk) 19:46, 8 December 2024 (UTC)
  • Oppose: It feels like some people are trying to accelerate admin attrition and I don't know why. This is a solution in search of a problem. Gnomingstuff (talk) 07:11, 10 December 2024 (UTC)
  • Oppose Sure there is a problem, but the real problem I think is that it is puzzling why they are still admins. Perhaps we could get them all to make a periodic 'declaration of intent' or some such every five years that explains why they want to remain an admin. Alanscottwalker (talk) 19:01, 11 December 2024 (UTC)
  • Oppose largely per scribolt. We want to take away mops from inactive accounts where there is a risk of them being compromised, or having got out of touch with community norms, this proposal rather targets the admins who are active members of the community. Also declining incorrect deletion tags and AIV reports doesn't require the use of the tools, doesn't get logged but is also an important thing for admins to do. ϢereSpielChequers 07:43, 15 December 2024 (UTC)
  • Oppose. What is the motivation for this frenzy to make more hoops for admins to jump through and use not jumping through hoops as an excuse to de-admin them? What problem does it solve? It seems counterproductive and de-inspiring when the bigger issue is that we don't have enough new admins. —David Eppstein (talk) 07:51, 17 December 2024 (UTC)
  • Oppose Some admin actions aren't logged, and I also don't see why this is necessary. Worst case scenario, we have WP:RECALL. QuicoleJR (talk) 15:25, 17 December 2024 (UTC)
  • Oppose I quite agree with David Eppstein's sentiment. What's with the rush to add more hoops? Is there some problem with the admin corps that we're not adequately dealing with? Our issue is that we have too few admins, not that we have too many. CaptainEek Edits Ho Cap'n!⚓ 23:20, 22 December 2024 (UTC)
  • Oppose: I'm not seeing this as a real issue which needs to be fixed, or what problem is actually being solved. Let'srun (talk) 21:17, 28 December 2024 (UTC)
  • Oppose per all the good points from others showing that this is a solution in search of a problem. Toadspike [Talk] 21:57, 29 December 2024 (UTC)
  • Oppose The current wording sufficiently removes tools from users who have ceased to edit the English Wikipedia. Darkfrog24 (talk) 22:28, 3 January 2025 (UTC)

Discussion (Admin inactivity removal)

  • Making administrative actions can be helpful to show that the admin is still up-to-date with community norms. We could argue that if someone is active but doesn't use the tools, it isn't a big issue whether they have them or not. Still, the tools can be requested back following an inactivity desysop, if the formerly inactive admin changes their mind and wants to make admin actions again. For now, I don't see any immediate issues with this proposal. Chaotic Enby (talk · contribs) 08:13, 4 December 2024 (UTC)
  • Looking back at previous RFCs, in 2011 the reasoning was to reduce the attack surface for inactive account takeover, and in 2022 it was about admins who haven't been around enough to keep up with changing community norms. What's the justification for this besides "use it or lose it"? Further, we already have a mechanism (from the 2022 RFC) to account for admins who make a few edits every year. Anomie⚔ 12:44, 4 December 2024 (UTC)
  • I also note that not all admin actions are logged. Logging editing through full protection requires abusing the Edit Filter extension. Reviewing of deleted content isn't logged at all. Who will decide whether an admin's XFD "keep" closures are really WP:NACs or not? Do adminbot actions count for the operator? There are probably more examples. Currently we ignore these edge cases since the edits will probably also be there, but now if we can desysop someone who made 100,000 edits in the year we may need to consider them. Anomie⚔ 12:44, 4 December 2024 (UTC)
    I had completely forgotten that many admin actions weren't logged (and thus didn't "count" for activity levels), that's actually a good point (and stops the "community norms" arguments as healthy levels of community interaction can definitely be good evidence of that). And, since admins desysopped for inactivity can request the tools back, an admin needing the bit but not making any logged actions can just ask for it back. At this point, I'm not sure if there's a reason to go through the automated process of desysopping/asking for resysop at all, rather than just politely ask the admin if they still need the tools.
    I'm still very neutral on this by virtue of it being a pretty pointless and harmless process either way (as, again, there's nothing preventing an active admin desysopped for "inactivity" from requesting the tools back), but I might lean oppose just so we don't add a pointless process for the sake of it. Chaotic Enby (talk · contribs) 15:59, 4 December 2024 (UTC)
  • To me this comes down to whether the community considers it problematic for an admin to have tools they aren't using. Since it's been noted that not all admin actions are logged, and an admin who isn't using their tools also isn't causing any problems, I'm not sure I see a need to actively remove the tools from an inactive admin; in a worst-case scenario, isn't this encouraging an admin to (potentially mis-)use the tools solely in the interest of keeping their bit? There also seems to be somewhat of a bad-faith assumption to the argument that an admin who isn't using their tools may also be falling behind on community norms. I'd certainly like to hope that if I was an admin who had been inactive that I would review P&G relevant to any admin action I intended to undertake before I executed. DonIago (talk) 15:14, 4 December 2024 (UTC)
  • As I have understood it, the original rationale for desysopping after no activity for a year was the perception that an inactive account was at higher danger of being hijacked. It had nothing to do with how often the tools were being used, and presumably, if the admin was still editing, even if not using the tools, the account was less likely to be hijacked. - Donald Albury 22:26, 4 December 2024 (UTC)
    And also, if the account of an active admin was hijacked, both the account owner and those they interact with regularly would be more likely to notice the hijacking. The sooner a hijacked account is identified as hijacked, the sooner it is blocked/locked which obviously minimises the damage that can be done. Thryduulf (talk) 00:42, 5 December 2024 (UTC)
  • I was not aware that not all admin actions are logged, obviously they should all be correctly logged as admin actions. If you're an Admin you should be doing Admin stuff, if not then you obviously don't need the tools. If an Admin is busy IRL then they can either give up the tools voluntarily or get desysopped for inactivity. The "Asking the tools back at BN can feel like a faff." isn't a valid argument, if an Admin has been desysopped for inactivity then getting the tools back should be "a faff". Regarding the comment that "There's no indication that this is a problem needs fixing." the problem is Admins who don't undertake admin activity, don't stay up to date with policies and norms, but don't voluntarily give up the tools. The 2022 change was about total edits over 5 years, not specifically admin actions and so didn't adequately address the issue. Mztourist (talk) 03:23, 5 December 2024 (UTC)
    obviously they should all be correctly logged as admin actions - how would you log actions that are administrative actions due to context/requiring passive use of tools (viewing deleted content, etc.) rather than active use (deleting/undeleting, blocking, and so on)/declining requests where accepting them would require tool use? (e.g. closing various discussions that really shouldn't be NAC'd, reviewing deleted content, declining page restoration) Maybe there are good ways of doing that, but I haven't seen any proposed the various times this subject came up. Unless and until "soft" admin actions are actually logged somehow, "editor has admin tools and continues to engage with the project by editing" is the closest, if very imperfect, approximation to it we have, with criterion 2 sort-of functioning to catch cases of "but these specific folks edit so little over a prolonged time that it's unlikely they're up-to-date and actively engaging in soft admin actions". (I definitely do feel criterion 2 could be significantly stricter, fwiw) AddWittyNameHere 05:30, 5 December 2024 (UTC)
    Not being an Admin I have no idea how their actions are or aren't logged, but is it a big ask that Admins perform at least a few logged Admin actions in a year? The "imperfect, approximation" that "editor has admin tools and continues to engage with the project by editing" is completely inadequate to capture Admin inactivity. Mztourist (talk) 07:06, 6 December 2024 (UTC)
    Why is it "completely inadequate"? Thryduulf (talk) 10:32, 6 December 2024 (UTC)
    I've been a "hawk" regarding admin activity standards for a very long time, but this proposal comes off as half-baked. The rules we have now are the result of careful consideration and incremental changes aimed at specific, provable issues with previous standards. While I am not a proponent of "not all actions are logged" as a blanket excuse for no logged actions in several years, it is feasible that an admin could be otherwise fully engaged with the community while not having any logged actions. We haven't been having trouble with admins who would be removed by this, so where's the problem? Just Step Sideways from this world ..... today 19:15, 8 December 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

ITN Nominators

I believe we should add a small section which includes all of the nominators who have made it onto In The News. I think this would be just a polite way of saying thank you for your proposal. SimpleSubCubicGraph (talk) 05:15, 4 January 2025 (UTC)

I will just note that we do not do that for nominators for any other elements on the main page. We don't use bylines in Wikipedia. Anyone who cares enough about who did what for an article can examine the page history. Donald Albury 15:16, 4 January 2025 (UTC)
Disagree, that would just incentivize many people to try to get their name on the Main Page for millions of readers to see, leading to more competition and less constructive contributions. Chaotic Enby (talk · contribs) 15:51, 4 January 2025 (UTC)
A small section where? Obviously not on the main page, as the previous replies have been assuming. But if someone wanted to maintain some sort of list at Wikipedia:In the news/Contributors and link it from WP:ITN, 🤷. We have Wikipedia:List of Wikipedians by number of DYKs that is something similar for DYK. Anomie⚔ 16:01, 4 January 2025 (UTC)
That would be a much better idea indeed! Chaotic Enby (talk · contribs) 16:20, 4 January 2025 (UTC)
I agree! SimpleSubCubicGraph (talk) 18:18, 4 January 2025 (UTC)
Draft:In the news/Contributors I created a page if anyone wants to edit it. SimpleSubCubicGraph (talk) 18:21, 4 January 2025 (UTC)

Emptying Category:Wikipedians

Hello, I am bringing a proposal here as I have received conflicting advice at the original discussion (perhaps due to an incorrect usage of {{edit request}} by me?). I propose the category is either unmarked as a container, or the existing top-level user pages are sorted/removed (with possible exception of historical users?). Tule-hog (talk) 20:28, 6 January 2025 (UTC)

This comes up periodically when someone notices the container cat filling up with new users.
Just follow the normal process of removing the users. Leave them a note to add themselves to some more appropriate subcat, if you wish. - jc37 20:43, 6 January 2025 (UTC)
Perhaps important context is that the categorization of Wikipedians is a minefield that has led to a lot of spilled ink and anger. If you dig in the archives you can find the discussions. Spending a lot of times to make those categories look nice does not help us achieve our goal of writing an encyclopedia, and therefore it may be considered a waste of time by some. See also Category:Wikipedians who retain deleted categories on their userpages. {{edit request}} is for when you can't make the edit so someone else has to do it for you (e.g. if you need an admin to edit a page you can't edit because it has been protected). Polygnotus (talk) 20:48, 6 January 2025 (UTC)
Did we finish the encyclopaedia? If nit surely there's some reader-facing makework we could do? HJ Mitchell | Penny for your thoughts? 20:51, 6 January 2025 (UTC)
How are we ever supposed to finish when you keep writing new articles? You are part of the problem! I propose we get rid of all articles, except horse, and then we replace the content with a single sentence. Polygnotus (talk) 20:57, 6 January 2025 (UTC)

The use of AI-generated content

As of late, the use of AI has caused controversy. As it currently stands, the only thing we have on AI generated content is WP:LLM which is more of an essay and not a policy/guideline.

This lack of AI-generated content guideline is baffling considering the increasing prominence of AI in our daily lives. We don't have any form of guideline for such.

As such I wanted to bring up that there should be a guideline and recommend a few things:

1. As someone who uses a second language, I heavily rely on AI assistance, however, I do not believe all the content on Wikipedia should be AI-generated as such, I recommend the limitation of AI generated content which is as follows:

a. While Wikipedia does not prohibit Wikieditors from using large language models to plan their contributions, the Wikieditor must personally check and take responsibility for every word and every fact.
b. It cannot be used in talk pages or any form of communication. This is because AI-generated content with headlines are a mess already, and we don't need clutter on the talk pages. Plus existing guidelines require competence and communication is a social skill that is important anyways.
c. If it is AI-generated or any form of it is, in the edit summaries, it must be disclosed. This should not be used against the editor in any form unless somehow it becomes an issue.

2. You are responsible for making sure the content generated by AI follows the guidelines and policies. You cannot make the old "oh but AI generated it, not me, so I'm not responsible." excuse. This clause is being added to avoid that excuse from causing headaches that could already be avoided in the beginning.

Many of the ideas that already exist at WP:LLM I can see also being part of the guideline. What are your thoughts on making an official policy on this. This means that the policy would rely on other policies and if the policies change, it must keep in mind about the AI policy.

As it currently stands, essays and information pages are not POLICIES & GUIDELINES so we desperately need one for the sanity of everyone here working on Wikipedia.

Pinging @Giant Snowman as I find he would be interested in adding some stuff regarding the creation of this policy.

Sincerely,
Reader of Information (talk) 01:06, 6 January 2025 (UTC)

By byte count, 71.38% of WP:VPP is currently taken up by discussions about AI. Why don't you join one of those discussions? Anomie⚔ 02:20, 6 January 2025 (UTC)
In this case, that wouldn’t be possible as what I’m requesting is a formal policy and guideline that actually explains what AI use is allowed and what isn’t.
From what I understand, the other threads are asking for clarification on if AI is allowed in a certain circumstance NOT a guideline.

Cheers,
Reader of Information (talk) 11:17, 6 January 2025 (UTC)
what I’m requesting is a formal policy and guideline That's two separate things and...where is the proposal? Selfstudier (talk) 11:22, 6 January 2025 (UTC)
Whoops! I thought that it was obvious that was what I meant when I said “I recommend a few things… as follows:”. That is my fault and I’m glad I was able to clarify!

Cheers,
Reader of Information (talk) 11:31, 6 January 2025 (UTC)
A guideline won't happen without those threads being solved. I would recommend not using AI for second-language writing, translate in small chunks if needed, and it's likely closer to what you want to say. CMD (talk) 11:30, 6 January 2025 (UTC)
I disagree. I can write in English easily when it’s what I’m expressing in terms of what I’m thinking that’s easy.

However, whenever I write something with a lot of guidelines, I end up tensing up and my brain cannot create it completely from scratch without having random words in front of it. If random words are written already and all I need to do is revise it so it makes sense, that’s where I am able to be successful. I do this to avoid WP:MADEUP as that’s not what the Wikipedia project is for. That’s how I’m able to make constructive edits that contribute to Wikipedia as a whole. That’s also how I avoid the misuse of AI as it’s a godsend for me as someone who always tenses up when I’m writing something within guidelines and restrictions.

Of course I believe I need to clarify, I completely revise the text to the point none of the words from the AI is in the final version.

Cheers,
Reader of Information (talk) 11:41, 6 January 2025 (UTC)
That doesn't address my suggestion, which was using translation software that isn't designed to generate extra content. The idea that "none of the words from the AI is in the final version" is not believable, English is varied but generally there are some standard common words. CMD (talk) 11:44, 6 January 2025 (UTC)
Oh! I COMPLETELY misunderstood. I don’t translate it whatsoever. The only way I translate anything is through DeepL or Google Translate. If it’s worth anything my first language is sign language so you can’t really translate that language with the use of AI.

Cheers,
Reader of Information (talk) 11:51, 6 January 2025 (UTC)
Thank you, that's very helpful clarification. I'd like to know more, I'll take to the user talk. CMD (talk) 11:58, 6 January 2025 (UTC)
I'd broadly support a proposal like this. If I'm being (very) nitpicky, I'd say we shouldn't include must contain no words that were initially created by the AI, as this implies literally every word needs to be re-written, which might not be feasible (nor would it significantly impact AI-generated detector tools in the case of simpler phrases). — Czello (music) 11:46, 6 January 2025 (UTC)
What would an alternative be? I’m more than open to a different way of applying it. Reader of Information (talk) 11:51, 6 January 2025 (UTC)
Whoops, I need to reclarify what I meant. I meant to say:
Do you have any suggestions on an alternative for that part of the policy? I’m open to any ideas.

Cheers,
Reader of Information (talk) 11:52, 6 January 2025 (UTC)
"While Wikipedia does not prohibit Wikieditors from using large language models to plan their contributions, the Wikieditor must personally check and take responsibility for every word and every fact." How's that? If someone's little brother etc. gets into their account and violates policy, the person who holds the account is held responsible. Of course, that always involved the assumption that the user was lying about a little brother... Darkfrog24 (talk) 13:11, 6 January 2025 (UTC)
That seems reasonable to me. I’ll edit it to include that. Reader of Information (talk) 13:15, 6 January 2025 (UTC)
Isn't that already the case? LLMs do not exempt anyone from the responsibility of their edits. Chaotic Enby (talk · contribs) 23:51, 6 January 2025 (UTC)
Can someone here move this to idea lab, it’s clear this needs more improvement and is not ready to be implemented as I previously thought. Reader of Information (talk) 13:17, 6 January 2025 (UTC)
As I've previously discussed, I think any guidance should not refer to specific technology, which changes rapidly and has many uses. isaacl (talk) 15:53, 6 January 2025 (UTC)
I'm sympathetic to this argument but in reality we do this all the time. This isn't a perfect analogy (i.e., if you nitpick it, then I am probably already aware of what you are nitpicking) but WP:RSN and by extension WP:RSP are both extremely useful resources about any given media outlet, and also something that lags behind how reliable they are now, as opposed to when someone brought them up.
(that is, if it wasn't just wrong from the outset; there are one or two cases where I literally know the guy employed as a fact-checker at publications people claimed were unreliable for not fact-checking) Gnomingstuff (talk) 18:36, 7 January 2025 (UTC)
We have an information page regarding AI usage on Wikipedia, see Wikipedia:Artificial intelligence. Some1 (talk) 02:07, 9 January 2025 (UTC)
The original poster was suggesting that there be a guideline on AI; since that's an info page, I don't think it fits the bill w/r/t what OP was looking for. —pythoncoder (talk | contribs) 05:20, 9 January 2025 (UTC)
Pythoncoder explained it well. Sorry. I didn’t see this message. My apologies. Reader of Information (talk) 11:15, 9 January 2025 (UTC)
The community held an RfC back in October 2023 regarding the promotion of WP:LLM to policy status, but it failed to gain consensus: Wikipedia talk:Large language models/Archive 6#RfC: Is this proposal ready to be promoted?. (There was another similar RfC afterward, but unfortunately, I can't remember what it was called.) To quote the close: The most common and strongest rationale against promotion ... was that existing P&Gs, particularly the policies against vandalism and policies like WP:V and WP:RS, already cover the issues raised in the proposals.
I think the best approach now would be for editors to initiate community-wide RfCs focused on specific uses of AI on Wikipedia, such as what I did with Wikipedia:Village pump (policy)#BLPs, and work on integrating the consensuses of those RfCs into the existing policy pages themselves (the RfC consensus of that discussion, for example, is currently reflected in WP:BLP, WP:NOR, WP:IMAGEPOL). I would also suggest adding the RfCs to Wikipedia:Artificial intelligence#Discussion timeline to make it easier for readers and editors to find and read past AI-related discussions and their outcomes. Some1 (talk) 12:41, 9 January 2025 (UTC)
I disagree with that statement in all honesty.
I can be empathetic to the idea of having it into existing policies, but should we be really putting it into already existing policies and then making it more confusing for people looking for the AI aspect’s when it could be in just one page. I don’t know, as logistically, it doesn’t add up in my opinion. Reader of Information (talk) 13:55, 9 January 2025 (UTC)
Sure, the issues raised are covered but its covered for normal human interaction not AI, AI is whole different ball game and it’s advancing to the point where it might even pass off as human eventually. Reader of Information (talk) 13:57, 9 January 2025 (UTC)

Sections

I noticed that some sections are written like: == xxxxx == and some are written like ==xxxxx==. Some have gaps and some do not. Won't it be better if it was standardized? I prefer the one without gaps because it should save space. TrueMoriarty (talk) 06:47, 10 January 2025 (UTC)

Such a proposal is infeasible, as we have over 6 million articles in a mix of both styles. Although a script would probably handle 90% of them there'd be heaps of edge cases among the remaining ones to consider. Also that's assuming that editors would actually agree on a single style; given our track record with such things I think that's unlikely.  novov talk edits 09:03, 10 January 2025 (UTC)
Yes, or shall we have an inconclusive discussion that lasts for months and involves hundreds of editors? Phil Bridger (talk) 09:14, 10 January 2025 (UTC)
What else is Wikipedia for?--3family6 (Talk to me | See what I have done) 14:25, 10 January 2025 (UTC)
That means only 700,000 articles would be left. New editors can fix the others as a beginner's task.
TrueMoriarty (talk) 12:20, 10 January 2025 (UTC)
So Wikipedia adopts a novitiate/apprenticeship system? I like the idea of that, so long as it's not mandated at all but voluntary. I don't think this particular task would be of any help or use, though. It really doesn't matter.--3family6 (Talk to me | See what I have done) 14:25, 10 January 2025 (UTC)
Istruggletothinkofabiggerwasteoftime,thoughofcourseweshouldalldoourparttosavespace.– Joe (talk) 09:15, 10 January 2025 (UTC)
Joe, where should I send the the 0.00000004 cents that it would cost for you to use spaces? Phil Bridger (talk) 09:21, 10 January 2025 (UTC)
This would fall under WP:COSMETICEDIT, because the spaces (or lack thereof) has no change in visual output. It's not worth our time to fix something that has no real effect on pages, flooding watchlists and annoying people in the process. Also, ironically, the heading for this thread is written with spaces. —k6ka 🍁 (Talk · Contributions) 12:52, 10 January 2025 (UTC)
That is likely because as far as I've seen most of the software and scripts add spaces. CMD (talk) 13:59, 10 January 2025 (UTC)
It's potentially worth making a call on what's considered ultimate best practice, just so that the software and scripts can be aligned. But agreed that this is far too cosmetic to be worth changing, even within something like the GENFIX set. Sdkb talk 23:03, 10 January 2025 (UTC)

Update image of Template:Template category

Proposal to update image used in Template:Template category:

Currently it looks like this:

I propose we change the image to:

-- waddie96 ★ (talk) 22:26, 13 January 2025 (UTC)

This is too big a venue for this discussion. In any case, I don't think it's an improvement — better to keep it simple. Sdkb talk 03:06, 14 January 2025 (UTC)

RSS feed for Portal:Current events

An admin suggested that I make this a proposal here so here it is:

Unlike other Main page sections such as On this day (RSS) or Featured article (RSS), daily entries from Portal:Current events do not yet have an RSS feed. This has been requested several times on the Portal's talk page over the years, but never gained traction: 2006, 2010, 2013, 2020.

Adding a feed via MediaWiki's FeaturedFeeds extension should be relatively straightforward (for an admin with access to extension settings):

  1. Create the feed page under MediaWiki:Ffeed-currentevents-page ("currentevents" would be the feed's name). Requires admin access.
  2. Add the following as the page's source: Portal:Current events/{{#time:Y F j|-1 day}} (This should set yesterday's current events to today's feed entry.)
  3. Configure the new feed in Wikipedia's FeaturedFeeds settings (adapting from extsting settings from other existing feeds like On this day). I'm not sure exactly what access is required here, or whether this can only be done by a WMF staff member.

I may be biased, but I don't see any good reason not to provide Current events as an RSS feed: it simply gives users another way to access this fantastic content using their favorite feed reader. Thoughts? Robinmetral (talk) 08:09, 12 January 2025 (UTC)

Makes a lot of sense to me. Feels like it should be doable but phab:T160561 gives me pause. I would drop a link here at WP:VPT to get some technical eyes on this that can make sense of exactly how to implement. Trialpears (talk) 01:56, 14 January 2025 (UTC)
Thank you for the ref to phab:T160561! I agree that it might make more sense to move this over to WP:VPT by now, since there doesn't seem to be anyone opposing this in principle. I just reached out on the ticket thread to see if anyone involved in this at the time still remembers what happened. If there doesn't seem to be any technical blockers, I'll move this proposal to WPT to hopefully find someone who can implement it. Robinmetral (talk) 04:03, 14 January 2025 (UTC)

Good Article visibility

I think it would be a good idea to workshop a better way to show off our Good, A-class and Featured articles (or even B-class too), and especially in the mobile version, where there is nothing. At present, GA icons appear on the web browser, but this is it. I think we could and should be doing more. Wikipedia is an expansive project where page quality varies considerably, but most casual readers who do not venture onto talk pages will likely not even be aware of the granular class-based grading system. The only visible and meaningful distinction for many readers, especially mobile users, will be those articles with maintenance and cleanup tags, and those without. So we prominently and visibly flag our worst content, but do little to distinguish between our best content and more middling content. This seems like a missed opportunity, and poor publicity for the project. Many readers come to the project and can go away with bad impressions about Wikipedia if they encounter bad or biased content, or if they read something bad about the project, but we are doing less than we could to flag the good. If a reader frequents 9 C-class articles and one Good Article, they may simply go away without even noticing the better content, and conclude that Wikipedia is low quality and rudimentary. By better highlighting our articles that have reached a certain standard, we would actually better raise awareness about A) the work that still needs to be done, and B) the end results of a collaborative editing process. It could even potentially encourage readers who become aware of this distinction to become editors themselves and work on pages that do not carry this distinction when they see them. In this age of AI-augmented misinformation and short-attention spans, better flagging our best content could yield benefits, with little downside. It could also reinject life and vitality into the Good Article process by giving the status more tangible front-end visibility and impact, rather than largely back-end functionality. Maybe this has been suggested before. Maybe I'm barking up the wrong tree. But thoughts? Iskandar323 (talk) 15:09, 11 January 2025 (UTC)

With the big caveat that I'm very new to the GA system in general and also do not know how much technical labor this would require, this seems like a straightforwardly helpful suggestion. The green + sign on mobile (and/or some additional element) would be a genuinely positive addition to the experience for users - I think a textual element might be better so the average reader understands what the + sign means, but as it stands you're absolutely right, quality is basically impossible to ascertain on mobile for non-experts, even for articles with GA status that would have a status icon on desktop. 19h00s (talk) 16:43, 11 January 2025 (UTC)
While GA articles have been approved by at least one reviewer, there is no system of quality control for B class articles, and no system to prevent an editor from rating an article they favor as B class in order to promote or advertise it. A class articles are rare, as Military History is the only project I know of that uses that rating. Donald Albury 17:16, 11 January 2025 (UTC)
I totally agree we should be doing more. There are userscript that change links to different colours based on quality (the one I have set up shows gold links as featured, green as GA, etc).
If you aren't logged in and on mobile, you'd have no idea an article has had a review. Lee Vilenski (talk • contribs) 20:15, 11 January 2025 (UTC)
A discussion was held on this about two years ago and there was consensus to do something. See Wikipedia talk:Good Article proposal drive 2023#Proposal 21: Make GA status more prominent in mainspace and Wikipedia:Good Article proposal drive 2023/Feedback#Proposal 21: Make GA status more prominent in mainspace. Thebiguglyalien (talk) 04:20, 12 January 2025 (UTC)
@Thebiguglyalien: Is that feedback discussion alive, dead, or just lingering in half-life? It's not obviously archived, but has the whole page been mothballed? So basically, there's community consensus to do something, but the implementation is now the sticking point. Iskandar323 (talk) 04:57, 12 January 2025 (UTC)
Basically, most of the progress made is listed on that feedback page and the project has moved on from it. There were a few options, like the visibility one, where it was agreed upon and then didn't really go anywhere. So there are some ideas there, but we'd basically need to start fresh in terms of implementation. Thebiguglyalien (talk) 05:16, 12 January 2025 (UTC)
  • Tracked in Phabricator
    Task T75299
    You're barking up exactly the right tree, Iskandar323. Regarding showing the icons on mobile, that's a technical issue, which is tracked at phab:T75299. I highlighted it to MMiller (WMF) when I last saw him at WCNA, but there's ultimately only so much we can push it.
    Regarding desktop, we also know the solution there: Move the GA/FA topicons directly next to the article name, as was proposed in 2021. The barrier there is more achieving consensus — my reading of that discussion is that, while it came close, the determining factor of why it didn't ultimately pass is that some portion of editors believed (wrongly, in my view) that most readers notice/know what the GA/FA symbols mean. The best counterargument to that would be some basic user research, and while ideally that would come from the WMF, anyone could try it themselves by showing a bunch of non-Wikipedian friends GAs/FAs and asking if they notice the symbols and know what they mean. Once we have that, the next step would be running another RfC that'd hopefully have a better chance of passing. Sdkb talk 06:50, 12 January 2025 (UTC)
    It's great that I've got the right tree, since I think that's a village pump first for me. It seems that the proposer of that original 2021 discussion already did some basic research. Intuitively, it also seems just obvious that an icon tucked away in the corner, often alongside the padlocks indicating permission restrictions, is not a high visibility location. Another good piece of final feedback in the GA project discussion mentioned earlier up this thread by TBUA is that the tooltip could also been improved, and say something more substantial and explanatory than simply "this is a good article". On the subject of the mobile version and the level of priority we should be assigning to it, we already know that per WP:MOBILE, 65% of users access the platform via mobile, which assuming a roughly even spread of editors and non-editors, implies that 2/3 of contemporary casual visitors to the site likely have no idea about the page rating system. Iskandar323 (talk) 07:31, 12 January 2025 (UTC)
    my reading of that discussion is that, while it came close, the determining factor of why it didn't ultimately pass is that some portion of editors believed (wrongly, in my view) that most readers notice/know what the GA/FA symbols mean This is not my reading of the discussion. To me it looks as though a major concern among opposers is that making GA/FA status more prominent for readers is likely to mislead them, either by making them think that GAs/FAs are uniformly high-quality even for those which were assessed many years ago when our standards were lower and have neither been maintained or reassessed, or by making them more doubtful about the quality of articles which have never gone through the GA/FA process but are nonetheless high quality. By my count at least ten of the 15 oppose !voters cite this reason either explicitly or "per X" where X is someone else who had made this point. Caeciliusinhorto (talk) 16:18, 12 January 2025 (UTC)
    I've also encountered a fair few instances of older, lower standard GA articles. But I also think greater visibility (effectively also transparency) could also benefit in that area as well. If GA status is more prominent, it provides greater cause to review and reassess older GAs for possible quality issues. Also, most of the worst GAs I have seen have come from around 2007, so it seems like one sensible solution would be for GA status to come with a sunset clause whereby a GA review is automatically required after a decade. Maybe I'm getting a little sidetracked there, but this sort of concern is also exactly what I mean by greater visibility potentially reinjecting life and vitality into the process. Iskandar323 (talk) 17:15, 12 January 2025 (UTC)
    I think you're right about that being the most major source of opposition, but most major is different than determining — I don't think those !voters will be open to persuasion unless the quality of GAs/FAs improves (which, to be fair, it definitely has somewhat since 2021). But the "they already know" !voters might be more persuadable swing !voters, and it would have passed with their support. Sdkb talk 19:02, 12 January 2025 (UTC)
    @Sdkb: So, is there any way to poke the mobile issue a little harder with a stick? And do you think it is worth re-running the 2021 proposal or a version of it? What format should such a discussion take? Is there a formal template for making a proposal more RFC-like? Iskandar323 (talk) 12:59, 20 January 2025 (UTC)
    @Sdkb: I see that it got moved to "Incoming" after you flagged it to Miller, but then it got sent back to the "Freezer", and yesterday shunted altogether: Per the web team's quarterly grooming, these tasks are being removed from the team's backlog. Iskandar323 (talk) 12:46, 24 January 2025 (UTC)
    @MMiller (WMF) and @Jdlrobson, can you explain? Sdkb talk 00:32, 25 January 2025 (UTC)
    I think that's a fair reading of the discussion. But, I suppose the best way to be more transparent is to tell a user that it has been rated GA after a peer review, but that doesn't mean that the article is perfect... Which is what GA (and FAs) also say. Lee Vilenski (talk • contribs) 19:54, 12 January 2025 (UTC)
  • My radical proposal would be to get rid of the whole WP:GA system (which always came across to me as a watered-down version of WP:FA). Some1 (talk) 16:31, 12 January 2025 (UTC)
    Why? TompaDompa (talk) 16:38, 12 January 2025 (UTC)
    It is a watered-down process from an FA, but it is also the first rung on the ladder for some form of peer-review and a basic indicator of quality. Not every subject has the quality sources, let alone a volunteer dedicated enough, to take it straight from B-class to Featured Article. Iskandar323 (talk) 17:17, 12 January 2025 (UTC)
    That's literally the point of it. Lee Vilenski (talk • contribs) 19:52, 12 January 2025 (UTC)

Redirects not mentioned in the articles

I have proposed expanding the directions at the top of Category:Redirects to an article without mention. Please see Category talk:Redirects to an article without mention. WhatamIdoing (talk) 06:41, 27 January 2025 (UTC)

Forbid Moving an Article During AFD

There is currently a contentious Deletion Review, at Wikipedia:Deletion_review/Log/2025_January_19#Raegan Revord, about an article about a child actress, Raegan Revord. Some editors think that she is not biographically notable, and some editors think that she is biographically notable. There is nothing unusual about such a disagreement; that is why we have AFD to resolve the issue. What happened is that there were a draft version of her biography and a mainspace version of her biography, and that they were swapped while the AFD was in progress. Then User:Liz reviewed the AFD to attempt to close it, and concluded that it could not be closed properly, because the statements were about two different versions of the article. So Liz performed a procedural close, and said that another editor could initiate a new AFD, so that everyone could be reviewing the same article.

This post is not about that particular controversy, but about a simple change that could have avoided the controversy. The instructions on the banner template for MFD are more complete than those on the banner template for AFD. The AFD template says:

Feel free to improve the article, but do not remove this notice before the discussion is closed.

The MFD template says:

You are welcome to edit this page, but please do not blank, merge, or move it, or remove this notice, while the discussion is in progress.

Why don't we change the banner template on an article that has been nominated for deletion to say not to blank, merge, or move it until the discussion is closed? If the article should be blanked, redirected, merged, or moved, those are valid closes that should be discussed and resolved by the closer. As we have seen, if the move is done in good faith, which it clearly was, it confuses the closer, and it did that. I have also seen articles that were nominated for deletion moved in bad faith to interfere with the deletion discussion.

I made the suggestion maybe two or three years ago to add these instructions to the AFD banner, and was advised that it wasn't necessary. I didn't understand the reason then, but accepted that I was in the minority at the time. I think that this incident illustrates how this simple change would prevent such situations. Robert McClenon (talk) 06:06, 20 January 2025 (UTC)

  • Seems like a reasonable proposal. Something similar occurred at Wikipedia:Articles for deletion/2025 TikTok refugee crisis. AfD was initiated, then the article was renamed, an admin had to move it back, and now it has been renamed again while the AfD is still ongoing. Some1 (talk) 06:32, 20 January 2025 (UTC)
    • Thank you for the information, User:Some1. Both my example and yours are good-faith, but taking unilateral bold action while a community process is running confuses the community. I have also, more than once, seen bad-faith moves of articles during AFD. An editor who is probably a COI editor creates an article that is poorly sourced or promotional. A reviewer draftifies it. The originator moves it back to draft space. Another reviewer nominates it for deletipn, which is the proper next stop after contested draftification. The originator then moves it back to draft space so that the AFD will be stopped. Sometimes an admin reverses the move, but sometimes this stops the discussion and leaves the page in draft space. I think that any renaming should be considered within the AFD. Robert McClenon (talk) 06:52, 20 January 2025 (UTC)
      • "Renaming" and "draftifying" may be technically the same operation, but they are quite different things. I don't mind outlawing draftify during AFD, as it pre-empts the outcome, but fixing a nontrivial typo or removing a BLP-noncompliant nickname from a page title should be done immediately by anyone who notices the problem, independent of whether the page is at AFD or not. —Kusma (talk) 09:15, 20 January 2025 (UTC)
  • Oppose. Improving an article during AfD is encouraged and we must resist anything that would make it harder. Following the proposal would have meant a cut and paste move/merges would have had to happen in order to use the existing draft, making the situation more difficult to understand than a clear page swap. —Kusma (talk) 06:49, 20 January 2025 (UTC)
  • Support, the AfD deals with notability, and moving can impact the scope and thus the notability. In that specific case, during the AfD, sources from both could've been considered, as AfD is about the sources that exist rather than the current content of the article. Not sure how a merge would've made it more difficult to understand than what actually happened. Chaotic Enby (talk · contribs) 06:55, 20 January 2025 (UTC)
    • It would have hidden the actual revision history for no benefit whatsoever. —Kusma (talk) 07:25, 20 January 2025 (UTC)
      • When merging, the other article's history should be linked in the edit summary for attribution anyway. The benefit of avoiding the massive confusion for the closer (and the later deletion review) far outweighs the need for a few more clicks to find the history. Chaotic Enby (talk · contribs) 07:41, 20 January 2025 (UTC)
        • If people are discussing version A before 13 January and version B after 13 January, this may result in confusion for the closer. But the confusion arises from people discussing two different versions of the article. I am all for clearly stating in the AFD when anything like moving or merging has happened, but outlawing moves is not solving the unsolvable problem that articles can change during an AFD. —Kusma (talk) 09:11, 20 January 2025 (UTC)
Comment: In this case the AFD was closed when the content swap happened. And since people already before it made sure to say "please do include the draft text in your consideration" the swap was universally welcomed (both !deleters and !keepers agreed the draft article was far superior to the mainspace article). I would argue nobody was confused that the swap had happened when the AFD was reopened. (The impetus for this proposal is based on wrong facts. That doesn't mean the proposal in itself is bad, so do carry on) Cheers CapnZapp (talk) 12:27, 27 January 2025 (UTC)
  • Inclined to support as a draft swap seems rare, and seems somewhat at odds with the stated principle that AfD is about notability, which would not differ between a mainspace article and a draft article. In situations when there is a draft, the AfD could come to consensus to use the draft, or to keep on the topic and the draft can be moved in post-AfD. That said, regarding blanking, I have seen articles at least partially blanked due to BLP or copyright concerns. Those seem correct actions to take even during an AfD, and I suspect other instances of blanking are rare enough, and likely to be reverted if disruptive. CMD (talk) 09:31, 20 January 2025 (UTC)
  • Weak oppose forbidding the kind of move made here. We encourage improving an article during the AFD, and separately it is often said during AFDs that an article should be TNT'ed and started over. Replacing the article with a new version, whether through moving a draft or simply rewriting it in place, is a valid (if hamhanded) attempt to do both of those things to save an article from deletion. Support forbidding moving the article to a new title with no content changes, as that could be disruptive (you'd have to move the AFD for one, and what if it gets reverted?). Pinguinn 🐧 10:57, 20 January 2025 (UTC)
    • You do not have to move the AFD (and you should not, it is unnecessary and causes extra work). All you need is to make a note on the AFD what the new page title is. Of course you should almost never suppress the redirect while moving a page that is at AFD. —Kusma (talk) 14:06, 20 January 2025 (UTC)
  • @Robert McClenon Look at the timeline again, in the Revord case it did not happen while the AFD was in progress. The swapping happened while the afd was closed keep. The afd was then reopened. Gråbergs Gråa Sång (talk) 10:58, 20 January 2025 (UTC)
  • I can see the benefit of forbidding moving between namespaces, but this proposal would also catch simple renames. I've seen plenty of deletion discussions for articles with simple typos or spacing errors in their titles, where the nominating user has not corrected things before nominating. We should not forbid moving them to the correct title. Phil Bridger (talk) 13:49, 20 January 2025 (UTC)
  • I don't see the benefit of retaining poorly worded article titles for seven days or more. I'd support against moving namespaces during an AfD, but not all renaming.
  • This could actually cause an issue if someone was to move an article to a title that someone else wants to move an article to (in case of an obvious PRIMARY TOPIC/Dab change). Lee Vilenski (talk • contribs) 14:57, 20 January 2025 (UTC)
  • Oppose There are some rare cases this is a problem, but I have seen many/most cases it is helpful. In the given example, let's say the move was disallowed and the article was deleted. Now wait a few weeks and make the article again with the new content. People will complain no matter what. You've got to be reasonable. If there was a major effort to redo the article it should be discussed during the AfD. -- GreenC 18:27, 20 January 2025 (UTC)
  • Based on the comments above I think the best we can get will be a policy that requires any change of title be clearly and explicitly noted in an AfD, supplemented by a guideline that discourages controversial and potentially controversial changes in title while discussion is ongoing. Any change that would alter the scope of the article or which has been rejected by discussion participants (or rejected previously) is potentially controversial. On the other hand, a suggested change that has significant support and no significant objection among discussion participants is usually going to be uncontroversial. Thryduulf (talk) 19:02, 20 January 2025 (UTC)
  • How about we limit such moves to admins? If there is an overriding good reason to move a page as part of editing and improvement of the encyclopedia, it should be movable. BD2412 T 22:20, 20 January 2025 (UTC)
    • Not sure that restricting editorial/content choices to the discretion of admins is a good thing. While it will definitely help in case of overriding good reason, it also means an individual admin can enforce a potentially controversial choice of page title for their own reasons, and can't be reverted by another editor. And, of course, there's the wheel-warring aspect to that.
      An alternative could be to limit such moves to closing the discussion with a consensus to move – that way, we still limit spurious moves even more, but the editorial choices are still made by the community. Chaotic Enby (talk · contribs) 22:29, 20 January 2025 (UTC)
    • Would the described swap be possible without special tools? I know that the title of this thread is "move", but that was more (and much harder or impossible for a regular editor to undo) than a move. North8000 (talk) 22:34, 20 January 2025 (UTC)
  • Comment. I would be chary of preventing this completely. There are quite a few cases where it rapidly emerges that the article is clearly at the wrong title (eg a transliteration error or a woman who exclusively publishes under another form of her name) so that the results of searches for sources are completely different between the two titles; moving the article even mid-AfD might be a good response in such cases. Espresso Addict (talk) 05:33, 21 January 2025 (UTC)
    • I note that the text of the AfD notice used to read "Feel free to improve the article, but this notice must not be removed until the discussion is closed, and the article must not be blanked. For more information, particularly on merging or moving the article during the discussion, read the guide to deletion." until it was shortened in March 2021 by Kusma and then further shortened by Joe Roe in October 2023. Espresso Addict (talk) 05:47, 21 January 2025 (UTC)
      • If you can find a concise replacement for the text that actually gives pertinent information, please do edit the notice. —Kusma (talk) 08:31, 21 January 2025 (UTC)
        • I think sometimes clarity is more important than concision. Espresso Addict (talk) 09:44, 21 January 2025 (UTC)
          • If the text is restored, the guide to deletion should feature the promised information more prominently. —Kusma (talk) 10:02, 21 January 2025 (UTC)
            • Given that the current basis for the recommendation against moving is the relatively weak wording in WP:AFDEQ (While there is no prohibition against moving an article while an AfD or deletion review discussion is in progress, editors considering doing so should realize such a move can confuse the discussion greatly), highlighting this specifically in the template seems out of proportion. Perhaps we could revisit that if the consensus here is to strengthen the guidance, which would also allow us to be more concise (i.e. "do not move this page"). – Joe (talk) 18:37, 21 January 2025 (UTC)
              • It might be beneficial to tighten up that wording; something like An article should not generally be moved while an AfD or deletion review discussion is in progress, as it can confuse the discussion greatly. However articles may exceptionally be moved if a clear consensus emerges during the discussion to change the title. Espresso Addict (talk) 00:09, 22 January 2025 (UTC)
  • Oppose. Moving an article to a new title can be confusing during an AfD, but otherwise good edits are good edits. In particular rewrites or replacements by drafts to address concerns raised in the discussion shouldn;t wait because they can make clear that a reasonable article can be (because it has been) created. Eluchil404 (talk) 06:09, 21 January 2025 (UTC)
  • Weak support I think this should be formally discouraged, but I don't think we should ban it entirely. Certainly some moves during an AfD may be tendentious. SportingFlyer T·C 06:11, 21 January 2025 (UTC)
  • Strong support This has been a problem for years. The solution is simple, there is no requirement to make such moves during an AfD duration, there is no downside to this proposal. Andy Dingley (talk) 19:30, 21 January 2025 (UTC)
  • Oppose as a blanket rule, and strongly oppose this wording. Even if it is not intended as a blanket rule, and even if there are "obvious exceptions" as detailed above, wording like this will cause people to interpret it as one even when those "obvious exceptions" apply. "Well damn looks like the New York Times just reported that the shooting of Dudey McDuderson was a hoax, but sorry, we can't fix the title, template says so." (Example chosen since it's a plausible WP:NOTNEWS AfD.) Gnomingstuff (talk) 19:46, 21 January 2025 (UTC)
    • If it's that clear and obvious that something needs to be fixed, then obtain consensus for it at the AfD (and if you can't, then it's not "clear and obvious"), speedy resolve it (close and re-open as needed, or even some sort of partial consensus for one aspect) and then do it. But we still can't do renames when we don't yet have agreement as to need and new target. Andy Dingley (talk) 20:12, 21 January 2025 (UTC)
      • What I am saying is that wording like "please do not blank, merge, or move it, or remove this notice, while the discussion is in progress" will result in people arguing "the template says don't move it so don't move it, no exceptions allowed." Gnomingstuff (talk) 00:08, 22 January 2025 (UTC)
        • The problem is less moving things during an AfD as moving them unilaterally, without consensus. We can surely demonstrate that during an AfD, or quickly, in order to resolve and close it, if it's that clear. Andy Dingley (talk) 12:03, 22 January 2025 (UTC)
          • Yes, I agree. But that's not what the proposed wording says. The wording proposed is "please do not blank, merge, or move it, or remove this notice, while the discussion is in progress" (bolding mine), not "please do not move it unless you have consensus or it's obvious." There are no carve-outs in the wording and so the wording is bad. Gnomingstuff (talk) 01:37, 26 January 2025 (UTC)
  • Oppose (except as to unilateral draftification). Renaming should be left to editors' judgment. This includes their judgment of whether the new name is likely to be controversial, or whether any past or present discussion is actually related to the new name and shows opposition to it. In other words, ordinary principles of WP:BOLDMOVE apply. There should not be a general prohibition or consensus-in-advance requirement, nor should editors revert moves solely "procedurally" because of AFD. (Editors can of course revert if they disagree on the merits of the name.) Reader-facing improvement efforts should not be held back by an overriding concern for internal administrators' confusion. That's getting priorities backward. Adumbrativus (talk) 01:21, 22 January 2025 (UTC)
  • Hard cases make bad law. I don't know if that's always true, actually, but this discussion does strike me as an overreaction to an extremely unusual set of facts. --Trovatore (talk) 04:44, 22 January 2025 (UTC)
  • Qualified support. I generally agree that editors who move pages in the middle of a consensus-building discussion should be trouted, but there can be good reasons to perform such a move. We should prohibit only controversial moves during an AfD/RM/etc., while allowing uncontroversial moves. This is the same framework used at WP:RM/TR, where it works well. Toadspike [Talk] 09:13, 24 January 2025 (UTC)
  • Definitely and most emphatically not. I have addressed deletion concerns by renaming and refactoring articles during discussion many times over the past two and a bit decades, and as the person who wrote much of the guidelines on this stuff, including helping on the AFD notices, I can report that it is perfectly fine and a practice that has worked for decades. It has happened many times, entirely uncontroversially, and not just when done by me (although I've often wikignomed the links in the AFD discussions to follow the page moves, as people forget that part).

    Years ago, I used to put a horizontal rule and a small note when doing rewrites and refactors, to mark the point in the discussion where the article changed. But I reduced to just the horizontal rule and sometimes stopped doing even that when people started recognizing my name and stopped checking things for themselves once my name came up. (The name recognition might have dropped off a bit, nowadays. I could probably get away with the horizontal rules again.) I recommend that others simply mark where a rewrite or a page move has happened, in the discussion. I didn't have trouble with that before the name recognition set in, and you probably will not either. And please make my life (on AFD patrol) and those of closing administrators easier by remembering to fix the page title links in the discussions, because the real problems for closing administrators are what the target edit history to delete or not delete is, which remains clear as long as the discussion continues to point to the same edit history that it pointed to at nomination. Edit histories are not titles, and it is the edit history that gets deleted with the administrator deletion tool.

    Uncle G (talk) 09:39, 26 January 2025 (UTC)

Replace abbreviated forms of Template:Use mdy dates with full name

I propose that most[a] transclusions of redirects to {{Use mdy dates}} and {{Use dmy dates}} be replaced by bots with the full template name.

Part of the purpose of {{Use mdy dates}} is to indicate to editors what they should do. Thus, readability is important. I propose all of these redirects be replaced with their target which is:

  1. More easily understood even the first time you see it.
  2. Standardized, and thus easier to quickly scan and read.

The specific existing redirects that I suggest replacing are:

  1. ^ I would probably leave alone the redirects that differ only in case, namely {{Use MDY dates}} and {{Use DMY dates}}, which are sufficiently readable for my concerns.

Daask (talk) 20:30, 18 January 2025 (UTC)

In principle I like this idea (noting my suggestion to bring it here). My only concern would be about watchlist spam, given that, while this may not technically be a cosmetic edit, it's only a hair above one. But there's only a few thousand transclusions of these redirects, so if the bot goes at a rate of, say, one per minute, it'd be done in a few days. -- Tamzin[cetacean needed] (they|xe|🤷) 21:09, 18 January 2025 (UTC)
It looks like most or all of these are already listed at Wikipedia:AutoWikiBrowser/Template redirects, so whenever anyone edits an article with AWB, they'll already be replaced. No strong view about doing so preemptively.
However, if our goal is to ensure that these templates are actually meaningfully used, then we have some bigger fish to fry. First of all, even the written-out form isn't sufficiently readable/noticeable — many newcomers may not know what it means, and many experienced editors may miss it if they aren't happening to look at the top of the article. Ideally, we would either offer to correct the date format if anyone enters the incorrect one via mw:Edit check (task) or we'd include it in an editnotice of some sort.
Second of all, roughly 2/3 of all articles still don't have a date tag, so we need to figure out better strategies for tagging en masse. There are surely some definable groups of articles that are best suited to a particular format (e.g. all U.S. municipality articles I'd think would want to use MDY) that we could agree on and then bulk tag. Sdkb talk 21:50, 18 January 2025 (UTC)
Ideally, we would either offer to correct the date format if anyone enters the incorrect one via mw:Edit check (task) or we'd include it in an editnotice of some sort.
This could also feasibly be done with a regex edit filter, which is better than Edit check in that specific case as the latter doesn't work with the source editor as far as I know. Chaotic Enby (talk · contribs) 07:01, 20 January 2025 (UTC)
However it's done technically, it will need human supervision as some instances shouldn't be change, e.g. in quotes and the titles of sources. Thryduulf (talk) 07:08, 20 January 2025 (UTC)
A filter could only flag an issue, not fix it. And any time a user gets a warning screen when they click "publish", there is a significant chance they will abandon their edit out of confusion or frustration, so we should not be doing that for a relatively minor issue like date format. -- Tamzin[cetacean needed] (they|xe|🤷) 07:11, 20 January 2025 (UTC)
I do believe that just flagging it would be better than giving an explicit warning (that might scare the user) or automatically fixing it (which, like Thryduulf mentioned, might not be optimal for direct quotes and the likes). Chaotic Enby (talk · contribs) 07:17, 20 January 2025 (UTC)
Concur with Tamzin — the main point of Edit Check is to introduce an option to alert an editor of something without requiring a post-edit warning screen, which is all edit filters can do. The ideal form would be a combo of a flag and an automatic fix — for instance, dates not detected to be within quotes would be highlighted, clicking on it would say "this article uses the MDY date format; would you like to switch to that? learn more convert". Sdkb talk 16:38, 20 January 2025 (UTC)
That could be great indeed! Chaotic Enby (talk · contribs) 22:14, 20 January 2025 (UTC)
Courtesy pinging @PPelberg (WMF) of the Edit Check team, btw, just in case you have anything to add. Sdkb talk 05:11, 21 January 2025 (UTC)
To be doubly sure I'm accurately understanding the behavior y'all are trying to promote, @Sdkb, can you please give the below a read and share what I might be missing/misunderstanding?
Many Wikipedia articles include templates that specify the format that dates present within them are written in. To increase the likelihood that people follow these guidelines (on a per article basis), we propose that when people fail to format dates in the way the consensus specifies, Edit Check presents them with a suggestion that invites them to convert the date they've written into the desired format.
And hey, I'm glad you pinged, @Sdkb! PPelberg (WMF) (talk) 21:59, 24 January 2025 (UTC)
Yes, that's correct! And no problem! Sdkb talk 23:42, 24 January 2025 (UTC)
Excellent – documented! PPelberg (WMF) (talk) 22:01, 27 January 2025 (UTC)
It's definitely a cosmetic edit, in that it only changes the wikitext without changing anything readers see. But consensus can decide that any particular cosmetic edit should be done by bots. As proposed, there are currently 2089 transclusions of these redirects, 1983 in mainspace. Anomie⚔ 14:21, 19 January 2025 (UTC)
Agree with this. Also regarding many newcomers may not know what it means (in reference to the full template names): as a reminder, we do have to opt in to display maintenance categories, many of which are far less scrutable to the uninitiated. Categories can be clicked on for explanation.
As to the proposal itself, I don't really see the value in bypassing a bunch of redirects. Redirects exist to be used, and there's nothing wrong with using them. Blowing up people's watchlists for this type of change seems inconsiderate.
Articles without a prescribed date format are a non-issue. There's no need to implement any standard format at every article, and I augur that an attempt to do so would create far more problems than it would solve. Folly Mox (talk) 16:15, 21 January 2025 (UTC)
It is a problem (albeit a small one) if an article has some dates MDY and others DMY or YMD, per MOS:DATERET, since it introduces inconsistency. Tagging the article with its preferred format helps retain it, so it's something we should ultimately strive for (particularly at GAs/FAs, but also in applicable categories as I suggested above). Sdkb talk 17:14, 21 January 2025 (UTC)
Knowing how much each is transcluded, and relative to the most-used cousins, would be a valuable point to include in this discussion.
The more valuable change of sorts with respect to these templates is that they're clearly metadata. It would be great if we could move them over to mediawikiwiki:MCR, though IDK how much effort it would take to get that done. (And perhaps along with the settings for citations and English variety.) Izno (talk) 22:32, 23 January 2025 (UTC)

Transclusion of peer reviews to article talk pages

Procedural closure as an involved editor. This proposal has received unanimous support and an implementation is already being discussed at BRfA. —TechnoSquirrel69 (sigh) 23:31, 27 January 2025 (UTC)

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.

Hello,

First time posting here.

I would like to propose that peer reviews be automatically transcluded to talk pages in the same way as GAN reviews. This would make them more visible to more editors and better preserve their contents in the article/talk history. They often take a considerable amount of time and effort to complete, and the little note near the top of the talk page is very easy to overlook.

This also might (but only might!) raise awareness of the project and lead to more editors making use of this volunteer resource.

I posted this suggestion on the project talk page yesterday, but I have since realized it has less than 30 followers and gets an average of 0 views per day.

Thanks for your consideration, Patrick (talk) 23:07, 2 January 2025 (UTC)

I don't see any downsides here. voorts (talk/contributions) 01:55, 4 January 2025 (UTC)
Support; I agree with Voorts. Noting for transparency that I was neutrally notified of this discussion by Patrick Welsh. —TechnoSquirrel69 (sigh) 21:04, 6 January 2025 (UTC)
So far this proposal has only support, both here and at the Peer review talk. Absent objections, is there a place we can request assistance with implementation? I have no idea how to do this. Thanks! --Patrick (talk) 17:23, 13 January 2025 (UTC)
It might be useful to have a bot transclude the reviews automatically like ChristieBot does for GAN reviews. AnomieBOT already does some maintenance tasks for PR so, Anomie, would this task be a doable addition to its responsibilities? Apart from that, I don't think any other changes need to be made except to selectively hide or display elements on the review pages with <noinclude>...</noinclude> or <includeonly>...</includeonly> tags. —TechnoSquirrel69 (sigh) 17:28, 13 January 2025 (UTC)
Since ChristieBot already does the exact same thing for GAN reviews, it might be easier for Mike Christie to do the same for peer reviews than for me to write AnomieBOT code to do the same thing. If he doesn't want to, then I'll take a look. Anomie⚔ 22:41, 13 January 2025 (UTC)
I don't have any objection in principle, but I don't think it's anything I could get to soon -- I think it would be months at least. I have a list of things I'd like to do with ChristieBot that I'm already not getting to. Mike Christie (talk - contribs - library) 22:54, 13 January 2025 (UTC)
I took a look and posted some questions at Wikipedia talk:Peer review. Anomie⚔ 16:14, 18 January 2025 (UTC)
Support -- seems like a good idea to me. Talk pages are for showing how people have discussed the article, including peer review. Mrfoogles (talk) 20:51, 23 January 2025 (UTC)

Support. This would be very, very helpful for drafts, so discussions can be made in the Talk pages to explain a problem with a draft in more detail rather than only showing the generic reason boxes. Hinothi1 (talk) 12:56, 18 January 2025 (UTC)

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

Pages (non-articles) that are not neutral must have a template disclosing of their non-neutrality

Essays already have the requisite tags, the OP would be best to consider how many times they're going to start these types of discussions on the same subjects over and over again, before someone gets bored of it. Black Kite (talk) 18:10, 30 January 2025 (UTC)

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.

Articles have to be neutral, however essays and other pages do not have to be neutral. While I think opinions should have a place on Wikipedia, people should be aware that the page they are looking at has opinions and does not follow a neutral point of view. The most popular essay that I can think of that is opinionated is WP:Trump. Obviously, wikipedians who support Trump will not like this essay and think "how could this be on the site after all these years?". They may blank the page, then nominate it for deletion believing it to be an attack page. That is why I propose that a template be created informing new Wikipedians that non-articles on Wikipedia do not have to follow NPOV and can contain opinions. If the article has the humor template, the template I am proposing does not need to be added. SimpleSubCubicGraph (talk) 00:44, 27 January 2025 (UTC)

What is "non-neutral" about WP:Trump? O3000, Ret. (talk) 01:05, 27 January 2025 (UTC)
@Objective3000 Did you even click the wikilink? These revisions: https://en.wikipedia.org/w/index.php?title=Wikipedia:Not_every_single_thing_Donald_Trump_does_deserves_an_article&oldid=1266665671 and the current WP:NTRUMP are very opinionated and that is why I request a template to be created that informs the wikipedian of non neutrality. SimpleSubCubicGraph (talk) 01:08, 27 January 2025 (UTC)
that informs a wikipedian that essays and other non-articles don't need to be neutral.* SimpleSubCubicGraph (talk) 01:08, 27 January 2025 (UTC)
That's what the essay tag already on the page is for. MrOllie (talk) 01:12, 27 January 2025 (UTC)
@MrOllie The essay tag just says, this is a wikipedia policy from an editor that has not been thoroughly vetted by the community. This does not say that essays don't have to be NPOV. SimpleSubCubicGraph (talk) 01:17, 27 January 2025 (UTC)
What it says is This page is not an encyclopedia article, nor is it one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints.. There is no need to list every policy that it hasn't been vetted to follow. MrOllie (talk) 01:25, 27 January 2025 (UTC)
The essay tag does not say "this is a wikipedia policy". And if you read WP:NPOV, you'll see it's about articles. Gråbergs Gråa Sång (talk) 09:36, 27 January 2025 (UTC)
Of course I clicked on the link you provided. No, I didn't look at every previous version of the essay. And as MrOllie says, essay is the key. Essays are opinions by definition. O3000, Ret. (talk) 01:17, 27 January 2025 (UTC)
Uh, why would "wikipedians who support Trump" think this? The WP:TDS essay is very clearly suggesting not to fill Wikipedia with reflexive anti-Trump outrage cycles. Is this something "wikipedians who support Trump" think should happen? It's even acronymed "trump derangement syndrome"! CMD (talk) 01:52, 27 January 2025 (UTC)
@MrOllie @Objective3000 Well some people don't know this, I certainly didn't. That is why I nominated for MfD. SimpleSubCubicGraph (talk) 03:54, 27 January 2025 (UTC)
What exactly didn't you know? CMD (talk) 05:06, 27 January 2025 (UTC)
@SimpleSubCubicGraph: not knowing something is a really bad motivation for then taking action "against" the target of your ignorance or to even criticize it. You are acting from a position of ignorance, and your inexperience here is quite evident. I suggest you follow some very experienced editors and make a habit of asking (not accusing) them about things you don't understand. Even your use of "neutral" (referring to NPOV policy) reveals you don't know that we do not mean it in the normal sense. Feel free to ask me about things on my talk page. -- Valjean (talk) (PING me) 17:52, 30 January 2025 (UTC)
The {{essay}} tag already says that essays don't necessarily represent the views of the community. I suggest you drop the stick regarding the Trump essay. voorts (talk/contributions) 05:22, 27 January 2025 (UTC)
@Voorts I'm not mad that i wasnt able to get a consesus on deleting the WP:NTRUMP article, it was just a good example for the proposal I am making. SimpleSubCubicGraph (talk) 05:48, 27 January 2025 (UTC)
@SimpleSubCubicGraph, were you surprised when you originally discovered that essays (i.e., ones not tagged as being humorous) did not have to comply with NPOV? WhatamIdoing (talk) 23:28, 27 January 2025 (UTC)
@WhatamIdoing Of course I was. I thought I was on a fake version of Wikipedia when I first saw it. SimpleSubCubicGraph (talk) 03:43, 30 January 2025 (UTC)
If I had not stopped and looked around I would have probably been blocked for edit warring. SimpleSubCubicGraph (talk) 03:44, 30 January 2025 (UTC)
Well, I'm glad that you stopped and looked around, then. We need to think about how people learn about Wikipedia, because it's pretty complicated.
As a step towards gathering information, perhaps you'd like to think about your overall experience, and post it at User:Clovermoss/Editor reflections. This is a page where we're trying to collect information about the differing experiences that a wide variety of editors have had. You're coming up on your two-year anniversary, so I think you'd be a perfect candidate: new enough to remember what your first edits felt like, but experienced enough to have seen some of the back end. WhatamIdoing (talk) 04:23, 30 January 2025 (UTC)
@SimpleSubCubicGraph: above you wrote: "on deleting the WP:NTRUMP article". Even in this discussion about that ESSAY!!!, you call it an article. Learn the difference. Essays are not bound by the NPOV policy (except the BLP part of it) or many other policies and are not even part of the encyclopedia. While the public can access them, they are more like inhouse communication between editors. It's one way we share our opinions with each other. -- Valjean (talk) (PING me) 18:01, 30 January 2025 (UTC)
The kind of person who's going to blank a Trump page isn't going to care about the notice. If anything it might make them more likely to, because now we're suppressing ideas and freedom of speech blah blah blah. It's like putting notices on every article reading "please don't vandalize this" and expecting people to go "oh golly gee I was going to vandalize this page but now I know not to, thanks!" Gnomingstuff (talk) 03:20, 29 January 2025 (UTC)
Is this a follow-up to WP:VPI § Ban mainstream media, two days prior? I'm not sure what this kind of activity is supposed to indicate, but {{essay}} works fine outside mainspace. Maybe I'm just grumpy, but also maybe you could get a better feel for the community and our processes before opening more threads at the Villages Pumps. Folly Mox (talk) 13:34, 29 January 2025 (UTC)
@Folly Mox It is not. "Ban mainstream media" is entirely separate from this one. I just figured a tiny update to the template of essays disclosing on non neutrality would be good to not catch newer editors off guard. SimpleSubCubicGraph (talk) 03:44, 30 January 2025 (UTC)
To be fair, the essay template does say It contains the advice or opinions of one or more Wikipedia contributors. [...] Some essays represent widespread norms; others only represent minority viewpoints. Do you have a rewording in mind to emphasize more that essays might follow a particular point of view that isn't consensus?
"Not neutral" is a bit of a clumsy wording for essays about, say, writing advice. They aren't necessarily a part of a wider debate with opposing sides in which we could be meaningfully talking about "neutrality" like in a political controversy. Even then, "neutrality" could give an impression that there is a need for a false balance between opposing sides, rather than norms being a question of community consensus. Chaotic Enby (talk · contribs) 04:28, 30 January 2025 (UTC)
No it's a follow up to SSCG trying to get the page deleted at MfD and since that didn't work, they're now trying to get it censored. voorts (talk/contributions) 13:40, 30 January 2025 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal to prohibit the creation of new "T:" pseudo-namespace redirects without prior consensus

Alright; as the discussion is waning down, there haven't been many objections towards the prevention of new "T:" titles. Therefore, I'm going to enact the suggested remedies as stated in the opener. Regarding all remaining "T:" titles that currently exist, these may continue to be discussed and deliberated on a case-by-case basis, in follow-up discussions, if desired. I will go ahead and remove "T:" from the WP:PNR shortlist, and re-describe the titles at WP:Shortcut indicating that new "T:" pseudo-namespace redirects should not be created without prior consensus. Thank you for your time everyone! Utopes (talk / cont) 20:40, 31 January 2025 (UTC)

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.

Around this time last year in 2024, the phabricator ticket T363757 created a brand new alias for the template namespace. From this point on, it is possible to get to any template by appending the letters "TM:" to any search. If I wanted to reach the centralized discussion template, I could always type TM:CENT and it works like a charm, for all templates on the site. Back in the day though, typing in 8 characters to reach a page became somewhat exhausting, especially for titles that might need to be navigated to frequently. As a helpful tool, a pseudo-namespace called "T:" was deployed, to quickly let people reach pages in the template namespace. (Nevermind the fact that "T" apparently ALSO stands for the talk namespace (T:MP) and template talk namespace (T:DYKT)). Regardless, in practice, pseudo-namespaces are great tools for navigation, but they have a flaw in the fact that the software does not really support them. All pseudo-namespace redirects occupy mainspace, which means that any PNRs which exist should be maintained with care and diligence, to avoid interfering with regular readers searching for articles.

Anyway, among the four PNRs currently in use today, "T:" has been, by-and-large, the most controversial among the rest. While CAT:, P:, and H: all have some usage in different circumstances, according to WP:Shortcut#Pseudo-namespaces, "T:" titles are for "limited and specific uses only". Generally speaking, the only reason to justify the creation of a T: title, is for a template that sees regular use and maintenance by members of the project. If it's not a template one would need to return to on a regular basis, there's no need to occupy mainspace with a "T:" title, further adding to the obfuscation of other genuine articles that also start with "T:", such as T:kort, T: The New York Times Style Magazine, and many others according to Special:PrefixIndex/T:.

In regards to controversy, T: titles have been the subject of persistent RfDs since 2009, with variable results. Several RfCs have been held relating to pseudo-namespace redirects, including one from 2014 that suggests that "new T: titles should be generally discouraged", in Wikipedia:Village pump (policy)/Archive 112#RFC: On the controversy of the pseudo-namespace shortcuts. Yet, despite the multiple RfCs and RfDs, new "T:" titles continue to crop up regardless. Whether that be from people who mis-interpret or misunderstand pseudo-namespaces, or for anyone that might not've noticed WP:Shortcut saying "T:" titles are for "limited uses only", these are frequently monitored and the number always grows.

In any case, with the advent of the [[TM:]] alias, there is little to no need for new "T:" titles. It is not important enough to shrink a two-letter namespace, into a one-letter namespace, so there's really no reason to have NEW titles that start with "T:". In 2022, the "WikiProject:" pseudo-namespace was added to the disallow-list for new article titles. I don't think that "T:" as a starter should be added to such a list, but I don't think there should be any new ones of this type now that [[TM:]] is a safer alternative that works for 100% of all templates, and doesn't affect mainspace searches.

I propose that on WP:Shortcut, "T:" is moved to a new classification indicating that new titles should not be created without prior consensus, and/or that "new titles do not enjoy broad community support", i.e. the category that the WikiProject prefix is listed at currently. (For that matter, I think that the WikiProject prefix should be removed from Shortcuts because no pages contain that prefix anywhere on Wikipedia; at least not any from the last 3 years). I also propose that "T:" be removed from the shortlist on WP:PNR, because I feel that contributes to the creation of new T: titles, and we should not encourage the creation of T: titles when TM: now exists. Utopes (talk / cont) 22:17, 20 January 2025 (UTC)

Question: Is Special:PrefixIndex/T: all there is? I support at least a moratorium (consensus needed) for creating new T:, and also reeval existing T: in light of the new TM: alias. -- GreenC 14:45, 21 January 2025 (UTC)
Yes, that's all there is. —Cryptic 23:22, 22 January 2025 (UTC)
I would also support a moratorium outside of the DYK space. I note other main page uses are currently up for discussion at Wikipedia:Redirects for discussion/Log/2025 January 16#T:Pic of the day and etc., which would leave just DYK. Ideally if T: is deprecated, the DYK instructions would shift to TM: as well. I'll create a note at WT:DYK pointing to this proposal. CMD (talk) 15:57, 21 January 2025 (UTC)
We have managed a rapid consensus at WT:DYK to shift to TM as well, so my proposed exception is moot. CMD (talk) 01:15, 26 January 2025 (UTC)
  • Support I've always found "T:" titles confusing. In particular, I never understood why sometimes it worked (i.e. T:DYK) and sometimes it didn't (T:Cite journal). At some point I gave up trying to figure it out and just resigned myself to typing out "template" all the time (and occasionally typing "templare" by accident). I wasn't even aware that TM: existed.
    It's absurd that there should be namespaces, aliases, pseudo-namespaces, all of which have slightly different behaviors (not to mention Help:Transwiki). You should be able to understand what something is by looking at it, i.e. if it has a ":" after it, it's a namespace. So yeah, I wholeheartedly support getting rid of T. Getting rid of the existing T links may be painful, but it's pain we will endure once and be done with. That's better than continuing to have something that's inconsistent and confusing forever.
I ran into this recently when writing some code that handles matching template names. It turns out that if I give you a link foo:bar, you can't know if the "foo" part is case sensitive or not if you don't know what namespaces are configured on the particular wiki it came from. That's just stupid. RoySmith (talk) 16:25, 21 January 2025 (UTC)
PS, as a follow-up to You should be able to understand what something is by looking at it, I suggest people watch Richard Feynman's comments on this subject. When I'm seeking wonder and amazement at discovering a deeper understanding of the world around me, I can turn to quantum mechanics. I'd prefer wiki-syntax to be a bit less wonderous. RoySmith (talk) 16:49, 21 January 2025 (UTC)
Support – if we already have TM: as a perfectly functional pseudonamespace alias that automatically redirects to Template:, we don't need to encourage the use of T: which only works for hardcoded redirects and adds another level of confusion. After the moratorium, we can leave DYK some additional time to shift to TM: if needed. (edited 15:14, 22 January 2025 (UTC): mixed up alias and pseudonamespace again) Chaotic Enby (talk · contribs) 17:10, 21 January 2025 (UTC)
  • Oppose. "TM:" is not an intuitive redirect for "template", and longstanding usage - which I use frequently - is for "T:", e.g. T:ITN, T:DYK etc. If need be, we should tell the software to use "T:" universally for templates rather than "TM:". Using it for "Talk:" doesn't really make sense either, it's very rare to need a shortcut to a talk page, whereas templates are frequent targets. We should also add "TT:" for template talk. Editors drive how we work on the project, not suits at the Wikimedia Foundation.  — Amakuru (talk) 19:49, 21 January 2025 (UTC)
    Despite your claim, the decision wasn't made by suits at the Wikimedia Foundation, but by this very community here at VPP (link), where "TM:" was chosen over "T:". Chaotic Enby (talk · contribs) 20:15, 21 January 2025 (UTC)
    Even the code patch was written by a enwiki volunteer and the deployment was done by another volunteer developer lol. The claim of suits at the Wikimedia Foundation has no basis here. Literally nobody from the WMF was involved in this. Sohom (talk) 06:15, 23 January 2025 (UTC)
    And I'm not entirely sure there's any basis in the assumption the programmers at WMF are wearing suits. CapnZapp (talk) 13:01, 31 January 2025 (UTC)
    What one person finds intuitive isn't always necessarily what another person finds intuitive. But the link Chaotic Enby posted above shows there's a consensus that TM: is a suitable alias, so I don't think we should reinvigorate that debate. The question here isn't whether we like TM, it's whether we should get rid of T now that we have TM. Cremastra (talk) 20:56, 21 January 2025 (UTC)
Technically, the proposal doesn't say anything about getting rid of existing T's. It only proposes curtailing new ones. CapnZapp (talk) 13:02, 31 January 2025 (UTC)
Support. As Utopes points out, the advantage from writing "t" compared to "tm" is one character, however, the cons far outweigh them. Gonnym (talk) 09:22, 22 January 2025 (UTC)
@Wbm1058: You correctly note that the number has indeed gotten smaller. The explanation for the decrease is that a minimum of 7 pages have been deleted. The exact number should not actually matter though, given that this proposal seeks to formally prevent new titles, so any such database wouldn't register an increase if they get sent to discussion as soon as they are spotted, hence this discussion. This doesn't seek to rid the existing titles that have been around. But if you would like examples of discussions that ended in deletion, see Wikipedia:Redirects for discussion/Log/2025 January 3#T:Partner, Wikipedia:Redirects for discussion/Log/2025 January 3#T:WPBIO, Wikipedia:Redirects for discussion/Log/2025 January 9#T:Uw-move3, Wikipedia:Redirects for discussion/Log/2025 January 9#T:, Wikipedia:Redirects for discussion/Log/2025 January 16#T:Pic of the day and etc., which have cumulatively deleted ten redirects, three of which were brand new since your last assessment, which is perhaps why you noticed such a decline in pages. Utopes (talk / cont) 20:03, 27 January 2025 (UTC)
I see, Utopes, thanks. You're continuing to knock off a few of these, here and there. Alas, it's difficult to legislate away the constant arrival of disruptive editors like this guy (I know we should assume good faith, but editors like these stretch the limits of my assumptions). They're not gonna bother reading whatever laws you add to the policy pages. You're still going to need to occasionally deal with them, and it seems you've been doing a good job or handling it. The goal here is another criterion for speedy deletion, so you won't need to take the trickle of new ones to RfD as they drift in? wbm1058 (talk) 22:37, 27 January 2025 (UTC)
@Wbm1058: I don't think the rate of new titles is enough to justify a speedy-deletion criterion. 😅 Currently it's averaging "one new T: title a month", which thankfully is fairly manageable. That being said though, the text of WP:Shortcut and WP:PNR I think gives a bit too much validity towards T: titles.
"T:" is currently listed front and center as one of the "four PNRs" on WP:PNR, which gives people the idea of making T: titles for their favorite templates, despite them not being necessary in the year 2025 with the advent of the TM alias. Taking T:Uw-move3 as an example, the creator said the reason they created it was because "'T:' is listed at WP:PSEUDONAMESPACE". I think that removing the mention of "T:" from guideline pages such as WP:Shortcut and WP:PNR will be helpful in discouraging editors from making these, and will help diminish the new ones specifically while we work to resolve the older titles. Utopes (talk / cont) 22:48, 27 January 2025 (UTC)
  • Support. The pseudo-namespaces overall should be deprecated, as these pages bring nothing but future technical debt, but especially in case where the community agreed on a similar alias, the existing pages should just be fixed to match it and ideally removed altogether. I would note that the Big WMF does not actually prohibit T: prefix for template namespace, as it already exists fine in Russian Wikipedia (but we thankfully never adopted enWP’s practice of solving namespace aliases with futile manual labour, so we never had to deal with something like phab:T363538). stjn 16:09, 26 January 2025 (UTC)
    They're actually more than technical debt. They're an attractive nuisance. Most things on the wiki happen by cargo culting. You see something that does what you want and you copy it. That's why new ones keep popping up. Only a very very small number of the technical cognoscenti understand how a namespace differs from an alias differs from a pseudonamespace. As long as there's bad examples around for people to copy, they will do so. RoySmith (talk) 21:14, 27 January 2025 (UTC)
  • Support. But the proposal is so hair-splitting I don't think we really needed a central-notice discussion to decide it. I've seen much, much, more significant guideline changes get boldly implemented, in the project's history. – wbm1058 (talk) 23:38, 28 January 2025 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I have added "T:" prefix to the title blacklist, so only template editors, page movers, and admins can create new redirects with it. * Pppery * it has begun... 22:50, 31 January 2025 (UTC)

@Pppery: Why? The discussion above mostly does not discuss title blacklisting, but from those comments that mention it there seems to be a slight consensus against. Thryduulf (talk) 02:58, 1 February 2025 (UTC)
After taking a closer look at the discussion I've reverted that, but it seems absurd to me to set a rule like this and then refuse the obvious method of enforcing it - of course if T: redirects shouldn't be created it should be added to the blacklist, anything else is silly. * Pppery * it has begun... 03:03, 1 February 2025 (UTC)
I agree that blacklisting was not part of the consensus, but also agree that it's absurd :-) Perhaps some kind of filter could be created which detects and flags any new creations for human review? RoySmith (talk) 03:14, 1 February 2025 (UTC)
Not too sold on this, as the discussion showed that there were other existing T: redirects that didn't use it as a pseudonamespace, but just as the abbreviated form of a mainspace article title. Agree with @RoySmith that an edit filter could work, shouldn't be too hard to code one. Chaotic Enby (talk · contribs) 03:15, 1 February 2025 (UTC) 
page_namespace == 0 &&
page_title rlike "T:.*" &&
page_age == 0
Chaotic Enby (talk · contribs) 03:26, 1 February 2025 (UTC)
I'll admit to raising an eyebrow when I saw the edit to the blacklist, but didn't think it worth reverting. There's enough legitimate mainspace titles starting with T: that it made sense not to make that the alias for Template:, but not enough that we can't handle new ones with edit requests (bear in mind that blacklisting is much more permissive than salting; pagemovers and template editors can create these titles as well). What this really called for was a custom blacklist message. —Cryptic 03:32, 1 February 2025 (UTC)
That could also work. For the edit filter side, I've posted the proposal at WP:EFR so we can have more eyes on that option too. Chaotic Enby (talk · contribs) 03:34, 1 February 2025 (UTC)
I've added filter 1342 (hist · log) based on Chaotic Enby's request at EFR. Currently it very simply checks (log only) for any new page in the T: namespace. It would be fairly trivial to add a check whether it's a redirect to a template, so I'm here to seek clarification on whether that's what's really wanted, whether there should be a warn action/message, and if so whether anyone would like to write the purported message. -- zzuuzz (talk) 22:56, 1 February 2025 (UTC)
I suspect these are created infrequently enough that worrying about whether it's a redirect or not is not necessary, as long as this gets the attention of one or more humans who can look at it. If I understand the situation correctly, this will probably trigger once a month or so? RoySmith (talk) 23:08, 1 February 2025 (UTC)

US cabinet nominees

Which is the better format for using "Nominee"?

Pam Bondi
United States Attorney General
Nominee
Assuming office
TBD
SucceedingMerrick Garland
Pam Bondi
United States Attorney General
Nominee
Assuming office
TBD
SucceedingMerrick Garland

The first example doesn't use the 'status' bar, where's the second example does. GoodDay (talk) 17:33, 1 February 2025 (UTC)

Contacting @TimeToFixThis, Mazerks, and Tomrtn:, who've also edited this area of the infoboxes-in-question. GoodDay (talk) 17:39, 1 February 2025 (UTC)

I don't see any reason for it to not go in the status bar, as the title bar simply displays the title of the person's office they are being nominated to, are assuming or hold. Putting nominee in the status bar seems reasonable to me as it distinguishes from the person being an incumbent, acting or interim official. Mazerks (talk) 18:16, 1 February 2025 (UTC)
So… Suppose a nominee isn’t confirmed by the Senate… would we put “failed confirmation” in the status bar or something? Blueboar (talk) 18:29, 1 February 2025 (UTC)
As far as I am aware they would still be considered the nominee until the president removes the nomination or picks someone else. Don't take my word as fact though. TimeToFixThis (talk) 03:22, 2 February 2025 (UTC)
As TimeToFixThis said, if the President withdraws the nomination or they fail the senate, they no longer have any relation to the position and it simply comes off of their page, as happened with Matt Gaetz. Mazerks (talk) 19:48, 2 February 2025 (UTC)
The first one seems better visually for readers; the separate shaded boxes in the status bar example look clunky and disconnected, and like really old web design. If the status bar didn't have the same shading and was just text like the rest, it would be fine. Schazjmd (talk) 18:34, 1 February 2025 (UTC)
I can see that perspective but to me it makes sense to utilize the status bar. When they are the incumbent it is disconnected also, so I don't know. TimeToFixThis (talk) 03:20, 2 February 2025 (UTC)
I would disagree with your view that it makes the web design look old, personally I think it's more aesthetic to use the status bar. Mazerks (talk) 19:49, 2 February 2025 (UTC)
Readers don't know that's something we call a "status bar". They just see two gray boxes. Schazjmd (talk) 21:04, 2 February 2025 (UTC)
I have been in support for the second option since these edit wars started. It makes sense to utilize the status bar - why else would it be there if not for that. When I started to edit these pages as more nominees were announced, I was thwarted by some editor who seemed very convinced it had to be the first option. I forget what his name was. He said initially because they were "presumptive nominees", but never made a good argument as to why they couldn't be in the status bar. He went and changed all of the presumptive nominees info box to the first option and I figured he new what he was talking about, so I just started editing them just like that.
If there is not rule on this I'd vote to use the second option. TimeToFixThis (talk) 03:16, 2 February 2025 (UTC)
I don't know about the "presumptive nominee" bit. The first option is best, as it's more compact. GoodDay (talk) 19:09, 2 February 2025 (UTC)
That is a fair opinion. I will ask though, for arguments sake, if it is better because it is more compact, why don't we keep that same rational for when they are the incumbent? So we maintain the same aesthetic. TimeToFixThis (talk) 05:13, 3 February 2025 (UTC)
Why about the latter? We've read of "Attorney General nominee", "Secretary of the Treasury nominee", etc. But, how often do we read about "Attorney General incumbent" or "Secretary of the Treasury incumbent", etc? GoodDay (talk) 05:17, 3 February 2025 (UTC)
GoodDay That is actually a really fair point, and is probably the rational for it being the status quo. TimeToFixThis (talk) 00:01, 4 February 2025 (UTC)
I like the former option, because the nominee is not the attorney general: the qualification "nominee" is essential. This is in contrast to when the are the incumbent. CapitalSasha ~ talk 11:29, 3 February 2025 (UTC)
Neither. They should not have such a box until they actually assume office. --User:Khajidha (talk) (contributions) 13:07, 3 February 2025 (UTC)
I agree with Khajidha on this… since nominees can be rejected (ie not confirmed) the box itself is inappropriate. The office is temporarily vacant. Blueboar (talk) 13:18, 3 February 2025 (UTC)

Baghdad

I have just tried to add a comment to the Talk page for Baghdad but I was prevented by a warning message about blocked external links. My comment however did not include any link of any kind. Is there something wrong with the page? My comment was about the info box pictures that someone proposes to put on the Baghdad page. Spinney Hill (talk) 15:48, 5 February 2025 (UTC)

I've occasionally encountered that message when a blacklisted url is already on a page that I try to edit, but I just tested on Talk:Baghdad and didn't trigger it. I suggest posting at WP:TEAHOUSE for help (this page is for suggesting proposals). Schazjmd (talk) 16:43, 5 February 2025 (UTC)
Looking at what happened, the link that apparently triggered the spam blacklist actually came from a 2019 talk page section (Talk:Baghdad#Addition by User:Ghalibrev, second to last link), not sure how it got registered by the filter today. Chaotic Enby (talk · contribs) 17:13, 5 February 2025 (UTC)

Thanks. I have asked the question there as wellSpinney Hill (talk) 17:13, 5 February 2025 (UTC)

Producing data dumps with only a subset of article history

Currently, there are, basically, 3 types of dumps (more information here):

  • Current revisions only, no talk or user pages.
  • Current revisions only, all pages (including talk). It's over 19 GB compressed (expands to over 86 GB when decompressed).
  • All revisions, all pages (these files expand to multiple terabytes of text).

I propose creating a fourth type of dump: it would be "One revision per year only, no talk or user pages", with only the first version of each year, for each article (obviously, for articles that have no changes in a given year, no version would be included for that year).

There is no doubt that the full, multi-terabyte dump is useful for many purposes, and it is great that it's being produced (and I hope that it never ceases to be produced, since I'm sure that some obscure bit of knowledge will only be available in an article version that lasted only for a few days).

But, from a purely encyclopedic point of view, I think that smaller dumps containing only a small subset of version history are desired. The sum of human knowledge that Wikipedia is, is not only in the last version of all articles. It's also in the article version for that city as it was 15 years ago, with the population and features that it had at that time, and that have changed since then. It's also in that good paragraph that was rewritten from scratch, with good intentions and a better result than the previous paragraph was, but that is missing that detail that the old one covered. Past revisions need to be considered in dumps made to download that knowledge, not only in those whose main purpose is (I think, since they also include talk and user pages) to analyze Wikipedia's own evolution.

The main target of this proposal is to have dumps that include the minimum content needed to show the evolution of the world and of Wikipedia itself, but without going into unnecessary details at this level.

Finally, if those dumps are eventually implemented, maybe additional mirrors could be contributed by third parties, to provide the dumps of all types but the biggest one ("All revisions, all pages"). I think the current number of mirrors is too small, specially if compared with, for example, the list of mirrors of Debian Linux distribution (and Debian mirrors also need a really huge amount of disk space).

Please note that I'm talking only about data dumps, available for download, not about online browsable Wikipedia content. Also, please note that I'm only proposing a new type of dump, not replacing any of the already existing dumps. MGeog2022 (talk) 14:26, 4 February 2025 (UTC)

Support, as proposer. MGeog2022 (talk) 14:28, 4 February 2025 (UTC)
That might have license/attribution problems. Consider:
  • Alice creates the page.
  • Bob tweaks the formatting, and his edit gets picked up as the lone "2023" revision.
  • Chris massively expands the page.
  • David makes a small edit, and his edit gets picked up as the long "2024" revision.
When you do a diff between 2024 and 2023, it'll look like David wrote everything. Chris won't get any credit for their work. WhatamIdoing (talk) 07:39, 5 February 2025 (UTC)
@WhatamIdoing, easy solution: no mention to users in the revisions of such dumps. Revisions in such dumps would be only something like "article content as of 2 February 2021". My proposal is not about who edited what, for that we have the full dumps. It's about having knowledge about:
  • obsolete information from the past, if it was replaced by a newer one, but such information, while not notable enough to have it in any current article, is also interesting for historical purpose (for example, population of a small village 10 years ago).
  • content that was replaced when a paragraph or section was rewritten. New content is good, even better than previous one, but it's missing some interesting detail.
MGeog2022 (talk) 12:52, 5 February 2025 (UTC)
That is not a solution to WhatamIdoing's objection. According to our licence any Wikipedia content must say who the writer is. Phil Bridger (talk) 14:05, 5 February 2025 (UTC)
@Phil Bridger, then, 2 of the 3 currently existing types of dump (both that include "Current revisions only") would also have the same supposed problem mentioned by WhatamIdoing. And all ZIM files distributed by Kiwix project would also be breaching the licensing terms, if that was the case, since they make no mention to individual authors, and they distribute, in many cases, the full content of Wikipedia. But, as you can see in the official policy about it, it's enough to mention the license and to cite that the content comes from Wikipedia. Then, the reuser can go to the article's version history at Wikipedia website, and see the individual contributors, or even download the full dump (the one with full revision history) to do the same. In summary, if both Kiwix ZIM files and the 2 already existing dump types that don't include article history, are not breaking any license policy, the new type of dump that I proposed would not do so either. MGeog2022 (talk) 19:57, 5 February 2025 (UTC)
In any case, if I'm missing something, and the "Current revisions only" dumps include the full list of authors of each article in some way, the same could be applied to the new dump (at the article level, or at the article revision level). MGeog2022 (talk) 20:05, 5 February 2025 (UTC)

An RfC for whether to call Kash Patel a conspiracy theorist in the first sentence

Kash Patel has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Wikieditor662 (talk) 00:08, 6 February 2025 (UTC)

Let's talk about Pending Changes

I've done a little bit of research into English Wikipedia's use of pending changes in light of some commentary I've been hearing in the broader wiki-world about the use of flagged revisions. For those of you who are newer here, pending changes is an enwiki-specific variation of the general flagged revisions extension of MediaWiki. At present, there is nobody (volunteer or WMF staff team) responsible for the continuing maintenance of this extension, nor has there been for many, many years. Periodically, it's received a bit of work. Right now a few folks from the WMF are looking at the underlying flagged revisions extension (see phab:T381044 for the current discussion), and are in the "gathering information" phase.

I personally undertook to do some serious looking at the pages we on this project currently have on PC protection. Here are some stats:

  • Approximately 4000 pages use PC. Of those pages, the types of pages with PC protection break down roughly as follows (all numbers are rough as my classification process is not failsafe).
    • Biographical articles (living or dead) - 1450
    • Articles about colors - 50
    • Articles specific to a date/year - 375
    • Articles about events/occurrences - 85
    • List-type articles - 180
    • Articles about places - 280
    • Articles about sciences/medicine - 250
    • Articles about sports and entertainment - 550
    • Articles about other topics - 740
    • Pages in Wikipedia space - 30
  • Around 5% of these articles have an expiry date on their PC protection

More information would be useful to analyse whether or not PC makes sense either generally or for each of these individual articles. This would require looking at each of the articles and also looking at the flagged revisions themselves; I'd suggest looking at only the last 24 months of revisions since so many articles have had PC on for a decade or more. For example:

  • Research on when PC was applied to pages.
    • I did a random check of 50 of the articles and this ranged from 2014 to November 2024, with most of them pre-2020.
  • Research how many edits required PC review in the last XX months (I'd be inclined to look at the last 2 years)
    • What percentage was accepted/declined
    • What percentage was obvious vandalism
    • What percentage simply did not meet the standards for the article (e.g., requiring that the edit subject already has an article to be included in a list-type article)
    • What percentage were inappropriately accepted/declined
    • Whether declined reversions were (or should have been) revdeleted and/or suppressed (especially on BLPs)

Ultimately, with this information, we should be able to determine which types of pages *should* and *should not* have PC on them, whether semi-protection might be better (if all the flagged revisions are being declined, then that's an argument for semi-protection), and we should probably change expectations so that PC is applied for a specific period, just as we do for full or semi-protection. But before we do that, we need the data.

I do have the lists of pages involved, divided up into article type, if others would like to help work on this. Risker (talk) 18:49, 4 February 2025 (UTC)

Noting here that Ladsgroup made many improvements to the technical state of the extension from 2021 to 2024. Risker (talk) 18:57, 4 February 2025 (UTC)
Great post and great listing of data points (and potential data points) about pending changes. One positive I see about pending changes is that it's a very low bar to granting which can be useful for editor retention/motivation. Best, Barkeep49 (talk) 22:29, 4 February 2025 (UTC)
seen PC-protected pages, but generally haven't interacted too much.
questions:
  • how long does a revision stay on average before being accepted or declined?
  • is there a way to integrate PC system into other pages such as EC/semi-confirmed now that its been round for a decade or so? editrequests are fine, but a bit clunky to deal with. would be much easier to let folks do edits on revised versions of articles.
Bluethricecreamman (talk) 01:34, 5 February 2025 (UTC)
Someone stated below that I believe the average review time on English Wikipedia is somewhere near 20 minutes –Novem Linguae (talk) 05:01, 5 February 2025 (UTC)
Special:ValidationStatistics provides a few high level statistics about pending changes usage, and says that the average review delay is just under 24 minutes. It's not particularly clear how that number is generated, though, the page says it's both the "average review delay", and "measures how long the oldest pending edit has gone unreviewed", which sound like two different things to me. Sam Walton (talk) 10:32, 5 February 2025 (UTC)
Number of pending changes page protections and unprotections by year
Some quick data on PC page protections and unprotections can be found in the chart to the right. The number of PC protections seems to have decreased over the years since around 2017, from over 2000 per year to 500-1000. The number of page protection actions has also generally decreased, but not by as much. The percentage of page protection actions that are Pending Changes has decreased from around 7.5% in 2014-2019 to under 5% by 2022. Sam Walton (talk) 20:56, 4 February 2025 (UTC)
Just an anecdote, but I've always noticed that the PC backlog is always very low. If 95% of the PC protections are indefinitely applied, and the number of pages with PC protections are increasing (albeit at a slower rate), are PC protections discouraging new/unregistered editors to edit those pages? — hako9 (talk) 23:13, 4 February 2025 (UTC)
They can still make their edits. Their edits just don't show up to logged out readers until checked by a pending changes reviewer. –Novem Linguae (talk) 23:26, 4 February 2025 (UTC)
Ofcourse. But they still see the editnotice saying their edits are subject to review prior to publication. That's an extra step. Why to put in the effort towards something that may not be published. That could be a deterring factor. What's the reason for permanent PC protection anyway? — hako9 (talk) 23:37, 4 February 2025 (UTC)
Frequent problematic edits that the protecting admin determines need review so that some don't slip through the cracks. –Novem Linguae (talk) 23:40, 4 February 2025 (UTC)
How does an admin conclude that the frequent problematic edits will persist indefinitely? — hako9 (talk) 23:56, 4 February 2025 (UTC)
There is no good answer to that question, because a lot of the articles that currently have PC protection have had it for so long that we really have no good idea of whether or not there is a persistent problem with editing by unregistered and newly registered accounts. Thus why I've proposed some data collection, which probably needs eyes-on reviewing. Risker (talk) 00:01, 5 February 2025 (UTC)
Do you also have stats on avg expiry time of semi-protected pages and number of indefinite semi protected pages? — hako9 (talk) 00:21, 5 February 2025 (UTC)
@Hako9 If my queries are correct: Of the currently 65,407 semi-protected pages, 3,461 (~5%) have no expiry (query). Limited to the article namespace, this is 3,216 out of 17,976 (~18%) (query). Average expiry times are a bit harder to calculate. Sam Walton (talk) 11:02, 5 February 2025 (UTC)
I've had the chance to talk to people who work primarily on Wikipedias where every article has flagged revisions protection. On some projects, almost all edits are reviewed so quickly that there is hardly a lag; on others, there has been history of days/weeks/months before edits get reviewed. This seems most closely correlated to the number of reviewers on that particular project, and to some extent to the percentage of the community that is able to review edits. What isn't clear is whether the change in ethos from having an edit immediately visible to one that has to be reviwed has anything to do with declines in editing and editorship on at least some of the projects with flagged revision applied to all articles; while there's some correlation, we all know that correlation is not causation. It's not something we can really measure on this project, given the minuscule number of pages with any form of protection here. I do recall that research shows the majority of English Wikipedia editors made their first edit before they registered an account.

Getting back to your original point, unregistered and newly registered editors can edit pages with PC protection, but their change won't be publicly visible to people who aren't logged in (i.e., readers) until they have been reviewed. Any edits made by anyone other than a person with reviewer permissions will also not be publicly visible to people who aren't logged in, until a reviewer comes and reviews the page. (There are some exceptions to that.) I believe the average review time on English Wikipedia is somewhere near 20 minutes (there are stats somewhere...), which is far better than most projects. Risker (talk) 23:59, 4 February 2025 (UTC)

I think the main thing you really need to know about using Flagged Revisions on all articles is what you see in this chart. The peak for the number of registered editors (i.e., making an edit) at the German-language Wikipedia was 2007. Their downhill slide started when Flagged Revisions became available, and it hasn't stopped since. The obvious conclusion is that using Flagged Revisions by default is bad for the community. WhatamIdoing (talk) 07:52, 5 February 2025 (UTC)
If memory serves, there are two ways to run Flagged Revisions. One is the way the German-language Wikipedia does it: Your edit is hidden until manually approved by a trusted user.
The other way shows the edits right away, but basically functions as a way to make sure every edit gets checked (at least) once. This results in more efficiency (if Alice accepts the edit, it's no longer in the queue for Bob, Chris, David, etc. to look at) and fewer missed edits (it stays in the queue until someone accepts it).
I could imagine these two methods having different results. WhatamIdoing (talk) 07:56, 5 February 2025 (UTC)
@WhatamIdoing my understanding is that both edits are visible for any logged-in users, and not visible for logged out users. But on German Wikipedia the edits apply to every single new user's edits, whereas here it applies to specific articles for newer users. People who log into Wikipedia likely spend more time on the site and understand that anyone can edit it, versus say someone perusing the content via Google search preview. ~ 🦝 Shushugah (he/him • talk) 08:46, 5 February 2025 (UTC)
Have a look at ruwiki's w:ru:Special:PendingChanges. w:ru:Военная кафедра hasn't been checked since 2013. Open it once while logged in and once in a private/incognito window. Compare them against the most recently checked/approved version. With their config, you're seeing the most recent automatically. It's not just if you're logged in. WhatamIdoing (talk) 00:08, 6 February 2025 (UTC)
I think FlaggedRevs basically has 3 modes: override, protection, or neither. Enwiki uses protection. Dewiki uses override. Ruwiki uses neither. I have some notes about this at User:Novem Linguae/Essays/Docker tutorial for Windows (WSL)#FlaggedRevs. –Novem Linguae (talk) 08:58, 5 February 2025 (UTC)
@WhatamIdoing Although there is certainly a correlation here, I don't think we can conclude there is a causation. The timeframe during which FlaggedRevs was introduced was roughly the same at which English Wikipedia also started seeing a decline in editor numbers from its peak, but we didn't introduce it here in the same way. Recent research looked at 17 Wikimedia projects which introduced FR, and did not find strong evidence of a negative impact on editor numbers - "Our findings imply that concerns regarding the major negative effects of prepublication moderation systems on contribution quality and project productivity may be overstated". Sam Walton (talk) 10:36, 5 February 2025 (UTC)
I agree to a significant extent; the decline also matches the rise of our (in)famous "the impersonal wall of semi-automated rejection", and dewiki would have been just as strongly interested in control as we were.
But unlike dewiki, our decline plateaued for several years. WhatamIdoing (talk) 23:54, 5 February 2025 (UTC)
1) Would this be a better fit for village pump idea lab, since there is no proposal yet? 2) I'm not sure we should spend a lot of time reviewing or trying to reform the pending changes system. It appears to be working fine, is not inconvenient to readers or editors, and does not appear to be broken. –Novem Linguae (talk) 05:03, 5 February 2025 (UTC)
Given that no one is voting here, I don't mind this being here, but someone could boldly move it if they wanted. Idea Lab and Proposals are separated to prevent people from voting and amending proposals halfway through. ~ 🦝 Shushugah (he/him • talk) 08:43, 5 February 2025 (UTC)
  • Just noting that I put it here (on the suggestion of a few others) because I do propose something: that we actively pursue further data points on the use of PC and whether it is having the intended effect. That is step 1 in reviewing the overall PC processes and policy. Is it working better on list articles than BLPs? Would BLPs be less vulnerable with semi-protection? Are we rejecting edits that are good except for a minor point? We haven't done a serious review for many years. Risker (talk) 17:24, 6 February 2025 (UTC)

I was pinged so I try to give my 2c. PC has its own limited use case for small set of important articles, in my wiki it's on good and featured articles or extremely sensitive ones. But as pointed out, enabling it for all pages will lead to decline in user retention. What could truly help English Wikipedia IMHO is enabling RC patrolling which has proven to be useful in many many large and small wikis. I wrote in details in Wikipedia:Village_pump_(proposals)/Archive_209#c-Ladsgroup-20231010173900-Enable_RC_patrolling_(aka_patrolling_for_edits) Ladsgroupoverleg 13:24, 7 February 2025 (UTC)

Trump, Cleveland, etc

Should we have Trump's infobox read as 47th & 45th President & Cleveland's infobox read as 24th & 22nd President? So as to line up with the order of their tenures of office? This has been brought up at Talk:Donald Trump#Infobox: 45th & 47th, or 47th & 45th? & more input would be appreciated. It should concern infoboxes of all office-holders, who've served non-consecutive terms. GoodDay (talk) 19:08, 7 February 2025 (UTC)

Yes. Corresponding to the order in which the info is presented is more important than stating two numbers in ascending numerical sequence. And I believe there is a fairly consistent site-wide convention to present the info in "most recent first" order. ―Mandruss ☎ IMO. 19:26, 7 February 2025 (UTC)
Not super sold on the idea, as we might want to present key information in chronological order. From a non-recentist perspective, there's no reason to mark Cleveland's second term as more important than his first, and having them in chronological order is more natural for the reader. Chaotic Enby (talk · contribs) 20:21, 7 February 2025 (UTC)

For a further example: This would change Luiz Inácio Lula da Silva's infobox to 39th & 35th President of Brazil. GoodDay (talk) 19:34, 7 February 2025 (UTC)

I think I would leave it as 22nd & 24th, which is probably how it is expressed elsewhere more often, then start with the most recent, which I suspect would look strange to the reader. Thus, Patrick Henry would be 6th and 1st governor of Virginia in his infobox if we adopted this. I'd leave well enough alone. Wehwalt (talk) 22:25, 7 February 2025 (UTC)
I would agree, the numbers represent the standard presentation of things occurring chronologically. I would note that Trump's own White House profile states "45th & 47th President of the United States". BD2412 T 22:50, 7 February 2025 (UTC)

...to "Edit history", "Edit stats", or similar. "Edit count" is highly misleading. ―Mandruss ☎ IMO. 05:32, 4 February 2025 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_216&oldid=1276562262"