Wikipedia:Village pump (proposals)

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
Proposed policy changes belong at Village pump (policy).
Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
Proposed new wikis belong at meta:Proposals for new projects.
Proposed new articles belong at Wikipedia:Requested articles.
Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
All cleanup actions are logged to all the pages they affect. Aaron Liu (talk) 18:32, 20 November 2024 (UTC)[reply]
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)[reply]
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)[reply]
... 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)[reply]
... 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)[reply]

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

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

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)[reply]
There are times where those traces aren't left. Aaron Liu (talk) 13:51, 21 November 2024 (UTC)[reply]
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)[reply]

(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)[reply]
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)[reply]
Indeed. This is a prime example of an unintended undocumented feature. Graham87 (talk) 08:50, 22 November 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Yeah, revision move would be amazing, for a start. Graham87 (talk) 15:38, 21 November 2024 (UTC)[reply]
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)[reply]
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)[reply]
Option 1b seems like the one with the best transparency to me. Thanks. Huggums^{537_voted! (sign🖋️|📞talk)} 06:59, 25 November 2024 (UTC)[reply]

Discussion: Log the use of the HistMerge tool

I'm noticing some commentary in the above RfC (on widening importer rights) as to whether or not this might be useful going forward. I do think that having the community weigh in one way or another here would be helpful in terms of deciding whether or not this functionality is worth building. — Red-tailed hawk _(nest) 15:51, 20 November 2024 (UTC)[reply]
WP:VPT notified. — Red-tailed hawk _(nest) 16:01, 20 November 2024 (UTC)[reply]
This is a missing feature, not a config change. Aaron Liu (talk) 15:58, 20 November 2024 (UTC)[reply]
Indeed; it's about a feature proposal. — Red-tailed hawk _(nest) 16:02, 20 November 2024 (UTC)[reply]
As many of the above, this is a feature request and not something that should be special for the English Wikipedia. — xaosflux ^Talk 16:03, 20 November 2024 (UTC)[reply]
See phab:T341760. I'm not seeing any sort of reason this would need per-project opt-ins requiring a local discussion. — xaosflux ^Talk 16:05, 20 November 2024 (UTC)[reply]

True, but I agree with Red-tailed hawk that it's good to have the English Wikipedia community weigh on whether we want that feature implemented here to begin with. Chaotic Enby (talk · contribs) 16:05, 20 November 2024 (UTC)[reply]
Here is the Phabricator project page for MergeHistory, and the project's 11 open tasks. – wbm1058 (talk) 18:13, 21 November 2024 (UTC)[reply]
I agree that this is an odd thing to RFC. This is about a feature in MediaWiki core, and there are a lot more users of MediaWiki core than just English Wikipedia. However, please do post the results of this RFC to both of the phab tickets. It will be a useful data point with regards to what editors would find useful. –Novem Linguae (talk) 23:16, 21 November 2024 (UTC)[reply]

Revise Wikipedia:INACTIVITY

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

Endorsement/Opposition (Admin inactivity removal)

Support as proposer. Mztourist (talk) 07:47, 4 December 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Oppose There's no indication that this is a problem needs fixing. ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 00:55, 5 December 2024 (UTC)[reply]
Support Admins who don't use the tools should not have the tools. * Pppery * _{it has begun...} 03:55, 5 December 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. Ϣere SpielChequers 07:43, 15 December 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Why is it "completely inadequate"? Thryduulf (talk) 10:32, 6 December 2024 (UTC)[reply]
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)[reply]

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

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

Sounds reasonable on its face. Gatoclass (talk) 23:24, 9 December 2024 (UTC)[reply]

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

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

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

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

Category:Scheduled sports events
Category:Current sports events
Category:Recent sports events can be a suitable addition to those two. Edin75, you are also interested in categories and sporting events; what is your opinion? Maiō T. (talk) 18:14, 16 December 2024 (UTC)[reply]

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

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

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

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

Though simple information isn't copyrightable, if it's sufficiently visually similar I suppose that might constitute a copyvio. Jay Cubby 02:32, 13 December 2024 (UTC)[reply]

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

The Syrian map (right) seems quite respectable being based on the work of the Institute for the Study of War and having lots of thoughtful process and rules for updates. It is used on many pages and in many Wikipedias. There is therefore a considerable consensus for its use. Andrew🐉(talk) 11:33, 18 December 2024 (UTC)[reply]

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

@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[1]. Where is that info coming from? Der Wohltemperierte Fuchs ^talk 23:10, 19 December 2024 (UTC)[reply]

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

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

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

Allowing page movers to enable two-factor authentication

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. JJP_{Mas_ter} (she/they) 20:29, 12 December 2024 (UTC)[reply]
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)[reply]
For the record, I do have 2FA enabled. JJP_{Mas_ter} (she/they) 21:47, 12 December 2024 (UTC)[reply]
Oops, that says you are member of "Two-factor authentication testers" (testers = good luck with that). Johnuniq (talk) 23:52, 14 December 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. Jay Cubby 02:30, 13 December 2024 (UTC)[reply]
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)[reply]
- Because the recovery process if you lose access to your device and recovery codes is still "contact WMF Trust and Safety", which doesn't scale. See also phab:T166622#4802579. Anomie ⚔ 15:34, 14 December 2024 (UTC)[reply]
  We should probably consult with WMF T&S before we create more work for them on what they might view as very low-risk accounts. Courtesy ping @JSutherland (WMF). –Novem Linguae (talk) 16:55, 14 December 2024 (UTC)[reply]
  
  No update comment since 2020 doesn't fill me with hope. I like 2FA, but it needs to be developed into a usable solution for all. Lee Vilenski ^{(talk • contribs)} 00:09, 15 December 2024 (UTC)[reply]
  I ain't a technical person, but could a less secure version of 2fa be introduced, where an email is sent for any login on new devices? Jay Cubby 01:13, 15 December 2024 (UTC)[reply]
  Definitely. However email addresses also get detached from people, so that would require that people regularly reconfirm their contact information. —TheDJ (talk • contribs) 11:01, 18 December 2024 (UTC)[reply]
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)[reply]
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. House Blaster (talk • he/they) 07:19, 14 December 2024 (UTC)[reply]
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)[reply]
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)[reply]
@Hawkeye7, Lee Vilenski is correct. This would merely provide page movers with the option to enable it. JJP_{Mas_ter} (she/they) 00:28, 15 December 2024 (UTC)[reply]
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)[reply]
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)[reply]
Wait, so why is 2FA not an option for everyone already? – Closed Limelike Curves (talk) 01:15, 18 December 2024 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
Support; IMO all users should have the option to add 2FA. Stifle (talk) 10:26, 19 December 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
But this isn't about Google Authenticator. Johnuniq (talk) 02:58, 22 December 2024 (UTC)[reply]
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)[reply]
But (I believe), it is not available for use at Wikipedia. Johnuniq (talk) 07:27, 22 December 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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"[2] because he would travel to third-world countries to have sex with women in brothels, and also paint pictures of them[3][4]. 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. [5][6][7]).

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. gnu 57 18:29, 16 December 2024 (UTC)[reply]

@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. JJP_{Mas_ter} (she/they) 23:12, 16 December 2024 (UTC)[reply]

@JJPMaster: I am fine with moving the discussion elsewhere, if you think it more suitable. gnu 57 02:16, 17 December 2024 (UTC)[reply]

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

@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. gnu 57 02:16, 17 December 2024 (UTC)[reply]

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

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

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

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

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

I think we already tried this. It was called Myspace ;) —TheDJ (talk • contribs) 11:51, 21 December 2024 (UTC)[reply]

See Help:User style for information on creating your own stylesheet. isaacl (talk) 18:03, 21 December 2024 (UTC)[reply]

@Gnu779: You have successfully nerd-sniped me, so I’m gonna work on a user script for this. JJP_{Mas_ter} (she/they) 22:54, 26 December 2024 (UTC)[reply]

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

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

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