Jump to content

Wikipedia:Village pump (proposals)/Archive 217

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, 217

Enable Meta:CampaignEvents feature on English Wikipedia (2nd attempt)

Tracked in Phabricator
Task T386290

5-months ago I requested to enable Meta:CampaignEvents. There were a number of questions, that I believe were addressed, but the request got archived. This feature is enabled for 10-language editions of Wikipedia. It is still not [enwp] community configurable yet (for an admin to configure on the fly), but that may change in the future. Some tools have been expanded since, notably Invitation List. Currently enabling this would allow three tools, which I'll summarize:

  • Event Registration Tool: Keep track of event participants and contributions for an edit-a-thon or event.
  • Collaboration List: Events can be promoted across all Wikis that enable Meta:CampaignEvents
  • Invitation List is newest feature, and you can find Users based on how they contribute to specific articles. Great for recruiting people for existing WikiProjects, Backlog drives or general subject experts.

If there's consensus here, I will create a Phabricator ticket to enable it for English Wikipedia. We already have WP:Event coordinator permission request system, which someone needs if they want to create events. All users would be able to sign-up/participate. ~ 🦝 Shushugah (he/him • talk) 23:37, 6 February 2025 (UTC)

  • Support this. * Pppery * it has begun... 00:09, 7 February 2025 (UTC)
  • Support based on my understanding of the previous discussion, which is that enabling the feature still leaves the individual tools toggleable. I think the tools should be tested as well, but that flexibility is there in case of concerns. CMD (talk) 03:34, 7 February 2025 (UTC)
    Hi @Chipmunkdavis - Quick clarification: We don’t have Community Configuration integration (though we may explore it in the future), so there isn’t a way to toggle on/off features, but there are other ways to opt into features. Here’s how:
    • Invitation List (demo video): This has a feature flag, so it can be turned on/off by the engineers on the team. You would just let us know what you want.
    • Event Registration (demo videos): This has no feature flag, but all of the functionality is invisible until admins grant the Event-Organizer right to users. So, admins essentially “opt in” when they begin granting the right. Note that Event Registration and Invitation List use the same right, but we could create a separate right for Invitation Lists, if English Wikipedia wanted one feature but not the other.
    • Collaboration List: This has no feature flag, but it’s probably the least risky feature. It’s a read-only page, and there are no special rights needed to access it. It simply lists information that is already available on the wikis (see example on Meta-Wiki). However, if a wiki does not want to have it, we could implement a feature flag to hide it.
    Generally, we have seen that wikis opt to use all 3 features. The exception is wikis that do not focus on generating content (like affiliate wikis), which may not need Invitation Lists.
    Finally, you can test all of the features on testwiki, test2wiki, and the beta cluster (where all users have the Event-Organizer right). Additionally, Event Registration and the Collaboration List are available on Meta-Wiki, so you can get the Event-Organizer right on that wiki and then create a test event in your sandbox, if you want (see how to request the right on Meta-Wiki). Test events will not show up in the Collaboration List (since we allow users to specify if events are live or test). Hope that provides some clarity; thanks! IFried (WMF) (talk) 18:45, 7 February 2025 (UTC)
    Thanks for the clarifications, sounds like that achieves similar goals. CMD (talk) 03:53, 8 February 2025 (UTC)
  • Support Right now this tool mostly affects in-person Wikimedia community organizing, like the hundreds of New York City events listed at Wikipedia:Meetup/NYC/Event_archive, but the dream for like 20 years has been that eventually we would have the technical and social infrastructure to consistently set up virtual spaces where groups of like-minded people would find it easy enough to meet online and coordinate to edit Wikipedia articles together. The WMF development team who set this up has presented at Wikipedia community events, like WikiConference North America. I organize in-person and online events, I have seen these tools, and I think they align with both the way Wikipedia outreach volunteers do things and also with expectations how editors want events organized. I know that intervening with tools like this creates new social situations but I do not see this tool causing disruption. I expect that the early users of the tool will likely be people who already organize Wikipedia events, and this should make advertising those events and reporting outcomes easier. Yes let's enable this. Bluerasberry (talk) 19:17, 7 February 2025 (UTC)
  • Support WikimediaNYC used the Meta:CampaignEvents feature for a couple events last year. The biggest hurdle was that it was not on enwp and first time editors had to go to Meta to sign-in. I would like to see it enabled on English Wikipedia. -Wil540 art (talk) 03:31, 10 February 2025 (UTC)
  • Support - speaking as an event organizer, this would be a very useful addition. Right now, event organizers use a smorgasbord of tools for event organizing. The most common ways to acquire sign-ups is a mix of on-wiki signatures (limited utility), pointing users to the Outreach Dashboard (great tool, but requires going to a separate site), or using off-site registration tools like Eventbrite (potential privacy problems, may or may not be open source depending on platform). A comprehensive on-wiki suite to create, track, and promote events in a privacy-friendly way is sorely needed. Especially excited by the m:Special:AllEvents page for filtering and finding events. ~SuperHamster Talk Contribs 09:02, 12 February 2025 (UTC)
  • Support We used it for various events in Canada. Enabling this tool here is an improvement over what we previously had (either an off-site registration page or sending users to register on Meta, which confuses new editors). The tool still needs some additional functionalities though (e.g. waitlisting, "maybe"s). OhanaUnitedTalk page 22:10, 12 February 2025 (UTC)
  • Comment Phabricator ticket T386290 is created. ~ 🦝 Shushugah (he/him • talk) 01:15, 13 February 2025 (UTC)
    We'll need to hatnote and update Event (disambiguation) to reference a future new Event namespace I suppose. ~ 🦝 Shushugah (he/him • talk) 14:34, 19 February 2025 (UTC)
  • Support Useful for our event organizing, and very helpful to keep the documentation of events directly on English Wikipedia itself.--Pharos (talk) 18:23, 14 February 2025 (UTC)
  • Support With my volunteer editor hat on, I can really see the usefulness of these tools for topic-specific organising (Invitation list in particular!), and (for full transparency) with my user:Sara Thomas (WMUK) hat on, I can see the potential for helping to support existing editors in the community. Lirazelf (talk) 12:08, 24 February 2025 (UTC)

Would it be a good idea to build a scraper and a bot that scrapes tweets and then replaces the link to the tweet to a link to a site populated with scraped tweets? That way we don't send traffic to Twitter or whatever its called these days. Polygnotus (talk) 00:38, 22 January 2025 (UTC)

  • Wouldn't scraping be a copyright violation? —Jéské Couriano v^_^v threads critiques 00:48, 22 January 2025 (UTC)
    • @Jéské Couriano: I do not know (I am not a lawyer). I do know Google cache and the Wayback Machine and various other services that would also infringe on copyright, if that is copyright infringement. If the Wayback Machine can archive tweets, we could ask it to index every tweet and then remove every direct link to twitter. Maybe meta:InternetArchiveBot can do this and we only have to supply a list of tweets and then replace the links? Polygnotus (talk) 00:52, 22 January 2025 (UTC)
  • No. Wikipedia is not the place to try to attempt to voice your concerns with Elon Musk. Unless or until the site becomes actually harmful itself, more than others (i.e. scraping user data or similar), then there is no need to replace those links. Nobody is advocating for replacing links to Reuters, which requires you to sign up for an account and accept email ads/etc. to read articles for free. -bɜ:ʳkənhɪmez | me | talk to me! 01:00, 22 January 2025 (UTC)
    • until the site becomes actually harmful itself, more than others It is already, right? WP:RGW is about WP:OR and WP:RS, so it is unclear why you linked to it and it appears to be offtopic. Reuters, which requires you to sign up for an account and accept email ads/etc. to read articles for free. It does? I have never seen that (but I am using ublock and pihole and various related tools). Polygnotus (talk) 01:05, 22 January 2025 (UTC)
      • Why should Wikipedia be concerned what websites get traffic? If it's about the political views or actions of its owner or its userbase, then that's absolutely against the spirit of "righting great wrongs" in a literal sense, even if it's not what's specifically covered in WP:RGW. Thebiguglyalien (talk) 05:00, 23 January 2025 (UTC)
        • We already do apply, and for a long time have applied, this concept of concerning ourselves about the behaviour of the target site, to external hyperlinks that lead to copyright violating WWW sites. See Project:External links#Restrictions on linking. So the question becomes one of whether we should start concerning ourselves with behaviours other than copyright violation, spam, and harassment. I think that the answer is that no, we should not start concerning ourselves with sending traffic, especially as we had that discussion years ago when MediaWiki was changed to tell WWW browsers to not automatically pre-load the targets of external hyperlinks. Rather we should concern ourselves with whether we should be hyperlinking to Twitter posts, copied elsewhere or no, at all. That is a source reliability issue, and we already have the answer at Wikipedia:Reliable sources/Perennial sources#Twitter. Given that the blue checkmark is no longer a marker of account verification, and that it is possible to impersonate people who have since left Twitter since wholly deleted account names become available for re-use, what is said there about the problems confirming the identity of the author is now an even greater factor in source unreliability than it was a few years ago. Then there's what has been pointed out in this discussion about archiving services being unable to archive much of Twitter now. Uncle G (talk) 09:56, 25 January 2025 (UTC)
        Even if the less than alleged fascism is not enough reason for his private platform to be redirected, I would ask myself if his current rampage against "wokepedia" as he has taken to calling it wouldn't merit an additional layer of security. The guy is trying to alter the workings of Wikipedia itself to introduce a right-wing bias. The guy is a troll and it would certainly be on brand for him to censor dissent, alter URLs or edit content in what is (I must insist) his private social media platform. Xandru4 (talk) 09:16, 25 February 2025 (UTC)
  • ~~Agree that it's better not to send traffic to Twitter, but I don't know if Twitter is exactly getting a lot of traffic through Wikipedia, and in any case linking to the actual tweet (the actual source) is important.~~ Other users suggested archives. I oppose replacing links with links to a scraper, but I wouldn't oppose replacing links with links to the Internet Archive, for example -- something reputable. Mrfoogles (talk) 21:22, 22 January 2025 (UTC)
  • The disagreement of some editors with Twitter and Elon Musk do not constitute a reason for getting rid of it.--Wehwalt (talk) 22:33, 22 January 2025 (UTC)
  • Was this idea prompted by the banning of Twitter/X links by subreddits on reddit? https://www.theverge.com/2025/1/22/24349467/reddit-subreddit-x-twitter-link-bans-elon-musk-nazi-salute I'm not opposed to the idea of doing this on Wikipedia (replacing the links with an archived version of the tweets), but it does come off as somewhat like virtue signalling, considering that links to Twitter/X aren't commonly found on Wikipedia. Some1 (talk) 00:04, 23 January 2025 (UTC)
    • Personally I'm not sure it's a good idea, but I don't think it's just "virtue signaling". Obviously the effect will not be enormous, but it will help slightly (all the subreddits together, even though they're small, have some effect) and it's good to have sort of statements of principle like this, in my opinion. As long as the goal is to actually not tolerate Nazism, rather than appear to not tolerate Nazism, I don't think it's virtue signaling. Mrfoogles (talk) 20:48, 23 January 2025 (UTC)
  • @Polygnotus what is the specific reason you are suggesting this is something that should be implemented? I'm a terrible mind reader, and wouldn't want to make presumptions of your motives for you. TiggerJay (talk) 01:21, 23 January 2025 (UTC)
  • There is clear and obvious value in ensuring all {{cite twitter}} or {{cite web}} URLs have archive URLs, what with Musk's previously shortly-held opinion about the value of externally accessible URLs. Other than that, I see little reason to "switch" things. Izno (talk) 22:23, 23 January 2025 (UTC)
    • There is also the fact that for the past two and a bit years there has been a movement amongst erstwhile Twitter users to delete all of their posts. So ignoring whether the URLs become walled off behind a forced site registration, there's the fact that they might nowadays point to posts that no longer exist, the same issue that we have with link rot in general. And others have observed in this discussion that archiver services do not ameliorate this, as they have various difficulties themselves with Twitter, which they themselves report. Twitter militates against archive services. In the end, I doubt that any sort of newly grown archiving service could do better, as it would be quickly discovered and countered by Twitter as the existing ones already are. Uncle G (talk) 09:56, 25 January 2025 (UTC)
  • Most archiving services don’t work with Twitter anymore. Archive.org doesn’t and archive.is does it poorly. The only one that works consistently is GhostArchive which has been removed before over copyright concerns. For similar reasons, existing Twitter mirrors like Nitter are either defunct or broken. This would amount to removing all Twitter links then. PARAKANYAA (talk) 22:35, 23 January 2025 (UTC)
    • This however wouldn't be terrible. Simply removing all links to Twitter would be valuable for multiple content reasons in the direction of WP:WEIGHT, WP:OR, and so on. Izno (talk) 22:38, 23 January 2025 (UTC)
      • There is already tight guidelines on where and how tweets can be used in articles, and I don't think that it is any more prevalent than it is from any other primary source website. While the use of such primary sources need to be closely monitored in any article, there are places where its inclusion is appropriate and helpful, but it certainly is on the rare side of things. I also would proffer that if the main reason to prevent having links directly to twitter is some sort of virtue signaling we're going to get into a world of problems as the values and moralities of people in Wiki differ greatly. Should we then drop all links to Russian websites to support Ukraine? What about when it comes down to PIA issues or other areas of great contention? This would be murky waters that is best avoided all together. TiggerJay (talk) 22:47, 23 January 2025 (UTC)
      • Unless you want to remove WP:ABOUTSELF broadly I don’t see the reason to apply it to Twitter instead of every other social media website there is. PARAKANYAA (talk) 22:48, 23 January 2025 (UTC)
  • Having to build and maintain our own scraping service would have high costs in terms of software engineers to build the service, then software engineers to maintain it forever. We'd also basically be reinventing the wheel since FOSS organizations like Internet Archive already do scraping. Would recommend continuing with the status quo, which is linking to Twitter, and having Internet Archive do the scraping in case the main link dies. –Novem Linguae (talk) 00:34, 24 January 2025 (UTC)
    • Note what is written above about archivers not working with Twitter. Various archiving services themselves have warning about their greatly limited abilities or even outright inability to archive Twitter nowadays. See Blumenthal, Karl. "Archiving Twitter feeds". archive-it.org. for one example, where an archive services notes that it is greatly limited to archiving only what can be seen by people without Twitter accounts. Uncle G (talk) 09:56, 25 January 2025 (UTC)
  • I think we need to be taking a harder line on citations and external links to Tweets, but not because of any recent actions by its owner. I rarely come across citations/links to tweets that aren't flagrant violations of WP:RSPTWITTER, WP:SPS, WP:ABOUTSELF and WP:TWITTER-EL. If recent events give impetus to a crackdown on overuse of tweets, I won't be opposed to it. But scraping and changing links, when there's not yet been any indication of an urgent need to do so (unlike, say, with THF), then I think that would be a bit overkill. --Grnrchst (talk) 10:36, 25 January 2025 (UTC)
  • Archive URLs are helpful, and removing original URLs is destructive. ꧁Zanahary꧂ 22:40, 11 February 2025 (UTC)

Why in the world would we do this? Sure, Twitter/X is routinely not a good source, but that's because of WP:ELNO on blogs (remember, it's a micro-blogging site) and WP:RS in general, not because of some problem with the site itself. Citing a Twitter/X post by an account verified to belong to a prominent person is a great way to verify the statement "Prominent person said such-and-such on Twitter/X". Worse, it would cause major issues in places where a Twitter/X link is important to the article, e.g. Social media use by Barack Obama, which covers Obama's use of Twitter, or NJGov, which is about the official Twitter account of the state of New Jersey. For the latter item, WP:ELOFFICIAL is unquestionably applicable; it would be preposterous for an article about a Twitter account not to link the account in question. Nyttend (talk) 20:24, 29 January 2025 (UTC)

@Nyttend: If those are the best examples you can find we perhaps need to block all mentions of twitter in mainspace. Polygnotus (talk) 20:39, 29 January 2025 (UTC)
Why should an encyclopedic topic not be mentioned at all just because its CEO is an awful person? Chaotic Enby (talk · contribs) 20:55, 29 January 2025 (UTC)
@Chaotic Enby: What I mean is that those articles are not great. Polygnotus (talk) 20:58, 29 January 2025 (UTC)
NJGov is a good article. Since there aren't many articles of this sort, probably there aren't any featured articles about social media accounts or "so-and-so on social media". Nyttend (talk) 21:22, 29 January 2025 (UTC)
Agreed. It contains only 2 twitter refs, and both could be replaced with a link to an archived copy of that tweet without any problem. Polygnotus (talk) 22:02, 29 January 2025 (UTC)
What about the official URL link in the infobox and in the external links section? The only way we should serve archived pages in external links is if the official link doesn't exist anymore. Official links are exempted from many external-links requirements because they should always be included if possible. We shouldn't be imposing technical prohibitions that get in the way of such official links. Nyttend (talk) 10:25, 31 January 2025 (UTC)
Yeah I wasn't really talking about external links, only references. And a single external link on a single article is not very important. Polygnotus (talk) 13:50, 31 January 2025 (UTC)
You talked about avoiding sending traffic there, which happens when we serve an external link. And from your words it sure sounds like you're attempting to enforce a subtle non-neutral point of view. We all have our own points of view, but if you attempt to drive the site toward yours, it's not acceptable. Nyttend (talk) 09:12, 1 February 2025 (UTC)
  • No. While the site has fallen far from what it used to be, it's not serving malware or anything harmful like that which would support automatically removing all links, and replacing links to archives is problematic as already noted. It may be (likely is) collecting user data for nefarious purposes, but so do many sites we use as sources anyway, and there's only so far we can go to protect readers from the internet before we're righting great wrongs instead of making an encyclopedia. But maybe it's a good idea to add code to {{cite tweet}} so that all uses of Twitter in citations are flagged with a {{better source needed}} or {{unreliable source?}} tag, so that editors are prompted to review and replace links that are problematic? We really shouldn't be relying on Twitter or any social media as citations - if something said on Twitter needs to be used as a citation we should look for a proper reliable source quoting it, rather than linking to it directly. That's been the case since twttr first launched, but definitely more of a problem since 2021. Ivanvector (Talk/Edits) 20:57, 29 January 2025 (UTC)
    Are you sure that hate is not more harmful than malware? Polygnotus (talk) 20:59, 29 January 2025 (UTC)
    In the context of the external links guideline, absolutely yes. Wikipedia is not the Thought Police. Ivanvector (Talk/Edits) 21:04, 29 January 2025 (UTC)
    Yes. ꧁Zanahary꧂ 19:11, 12 February 2025 (UTC)
  • No. We are not reddit, mercifully. — Czello (music) 13:55, 31 January 2025 (UTC)

I concur with Uncle G on the value of archiving Tweets given migration out of Twitter, account deletion removes material from the record and that is particularly unhelpful for Twitter. Two other concerns: (1) Twitter content looks very different to Twitter users than to people who don't have accounts, so an [old tweet of mine https://x.com/CarwilBJ/status/1126300200212021255] appears in the context of a thread to signed-in users, but as a disconnected solo tweet to those who aren't logged in. This could easily generate confusion both for editors seeking to add material and to readers. (2) Numerous government accounts reset when there is a change of government, taking thousands of tweets offline. Standard practice for this case is to use an archive.

Some thoughts:

  • The Library of Congress has a complete archive of public tweets from 2006 to 2017.[1] I'm not sure if this is in a linkable format, but it is likely to endure.
  • The Chicago Manual of Style has as standard practice (18th Ed., 14.106: Citing social media content ) to cite the entire text of tweets in the bibliographic reference. We could make it Wikipedia policy to do so as well.
  • The Internet Archive still seems committed to this work, see [this https://help.archive.org/help/how-to-archive-your-tweets-with-the-wayback-machine/].

--Carwil (talk) 17:24, 1 February 2025 (UTC)

  • No, not until we know twitter is doing something weird with wikipedia or abusing linking or links somehow User:Bluethricecreamman (Talk·Contribs) 00:47, 11 February 2025 (UTC)
  • This seems to be a WP:RIGHTGREATWRONGS proposal. No thanks. Blueboar (talk) 01:59, 11 February 2025 (UTC)
  • As others have stated, we're not here to right great wrongs. Along those lines, we should also remember to WP:NOTLEAD. We are, by design, supposed to be "behind the curve". So let's not get ahead of ourselves. Kerdooskistalk 18:02, 17 February 2025 (UTC)
  • Probably this won't happen. But we should consider even further discouraging Twitter/X as a source. It was already a marginally-reliable primary source pre-Musk, and since his takeover it has a) become even less accessible (now you need an account to read most posts), b) even less widely archived (see above) and c) arguably less like to continue existing in the long term. It's not a question of righting wrongs but doing sensible source analysis; we were too quick to accept Twitter as a source in the last decade, overlooking the fact that it was and is a closed, proprietary social media service rather than a true publisher and giving it inappropriate and unencyclopaedic special treatment with things like {{Tweet}}. – Joe (talk) 10:06, 25 February 2025 (UTC)

Reviving / Reopening Informal Mediation (WP:MEDCAB)

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.
(tldr: Outcome is Not to revive a separate process, and implement two track process in WP:DRN) The proposal was to revive the WP:MEDCAB process for mid-level mediation of disputes. At first glance, consensus seemed hard to determine as while there does not appear to be a strong consensus for implementing the proposal as written, a large majority of contributors also did not want to keep the status quo, the usual outcome of a "no consensus." There are four view points expressed in the discussion: 1) those who opposed the change, 2) those who are in favor of implementing certain aspects of MEDCAB it into WP:DRN, 3) those who support the change as written, and 4) those who would be in favor of implementing the change under a trial period. It appears to me that at least several of those originally in category 3 are comfortable with some kind of compromised implementation of a process for more in-depth mediation into WP:DRN including the author of the proposal and the editor who is most active in the DRN process, to whom other editors in 3 & 4 deferred. Most proponents did not have a strong opinon about creating a new process but rather argued that DRN as it's currently structured is inadequate o adress more complicated questions. Therefore, consensus seems to be not to revive MEDCAB, but to implement a process within WP:DRN for mid-level informal mediation, possibly by using subpages as suggested by Arcticocean. — Preceding unsigned comment added by Lenny Marks (talk • contribs) 17:34, February 27, 2025 (UTC)

OK, so this is a little bit of a long read, and for some, a history lesson. So, most of my time on Wikipedia, I've been involved in our dispute resolution processes, including MedCab, talk page mediation and other works. Back in June of 2011, I created the dispute resolution noticeboard, which I proposed in this discussion. I designed this as a lightweight process to make dispute resolution more accessible to both volunteers and editors, providing a clearer entry point to dispute resolution, referring disputes elsewhere where necessary.

For a time, this was quite effective at resolving content disputes. I stayed involved in DR, eventually doing a study on Wikipedia and our dispute resolution processes (WP:DRSURVEY), and out of that, high level, we found that too many forums for dispute resolution existed, and dispute resolution was too complex to navigate. So, out of that, a few changes were made. Wikipedia:Dispute resolution requests and the associated guide was created to help editors understand the forums that existed for resolving disputes, and a few forums were closed: Wikiettiquite assistance was closed in 2012, and as many now found MedCab redundant to the lighter-weight DRN and formal mediation, it sparked a conversation on the MedCab talk page and Mediation Committee talk page in favour of closing. This is something, as one of the coordinators of MedCab at the time, that I supported. It truly was redundant to DRN and there was some agreement at the time that more difficult cases could be referred to MedCom.

However, back in 2018, MedCom was closed as the result of a proposal here, with the thought process that it was perhaps too bureaucratic and not very active/did not accept many cases, and its effectiveness was limited, so it was closed. While RFCs do exist (and can be quite effective), the remaining dispute resolution forum (DRN) was never designed to handle long, complex disputes, and had to be shifted elsewhere. This has, in some ways, required DRN to morph into a one-size fits all approach, with some mediations moved to talk pages (Talk:William Lane Craig/Mediation, Wikipedia:Dispute resolution noticeboard/Autism) among others. The associated complexity and shift away from its lightweight original structure and ease of providing assistance on disputes has had an impact on the amount of active volunteers in dispute resolution, especially at DRN.

So, my thoughts boil down to a review of Wikipedia dispute resolution and where some sort of structured process, like mediation could work. My initial thoughts about how content DR could work is:

  • Third opinion - content issue between 2 editors on a talk page, limited responses on the talk page by a third party
  • Dispute resolution noticeboard - Simple content disputes between editors that can generally be resolved in ~2 weeks
  • Mediation: Complex content disputes where assistance from a DR volunteer/mediator can help resolve the issues, or on occasion, frame the issues into a few cohesive proposals for further community input / consensus building
  • WP:RFC: Where broader community input is required, generally on a well defined proposal (and the proposal may have come organically, or formed as a result of another dispute resolution process)

The idea would be that DRN would be returned to its lightweight, original format, which could encourage its use again (as there's been feedback that DRN is now also too bureaucratic and structured, which may discourage editors and potential volunteers alike) and informal mediation (or MedCab - name I'm not decided on at this stage) could take on the more complex issues. While RFCs have value, not every dispute is suitable for an RFC, as guidance on some disputes is needed to form cohesive proposals or build consensus. Having mediation as an option, historically, was a benefit, with many successes out of the processes. I think it's time for us to consider reviving it. Steven Crossin Help resolve disputes! 09:57, 25 January 2025 (UTC)

  • Oppose. The proposal is unclear and DRN is already the dispute resolution venue based on the idea that "assistance from a DR volunteer/mediator can help resolve the issues, or on occasion, frame the issues into a few cohesive proposals for further community input / consensus building".—Alalch E. 17:23, 25 January 2025 (UTC)
    The header on DRN was changed over time with little discussion. It was originally quite barebones, and is one of the items that will be changed back to how it was originally (see User:Steven Crossin/DRNHeader for an example. I’d encourage you to read over the history of informal mediation (MedCab) as it will give some context to how it worked (it was closed quite some time ago). The proposal is to simplify DRN to its original design - lightweight with simple processes and minimal structure, and re-establish our informal mediation process. MedCab was quite successful as a process back in the day, but DRN performs the role of complex dispute resolution poorly - a noticeboard was never going to be the best way to handle these sorts of disputes (and as such, is why DRN was intended to be lightweight). Steven Crossin Help resolve disputes! 23:19, 25 January 2025 (UTC)
  • Support as a working mediator at DRN. This idea can be seen as defining two tracks for content disputes, a lightweight track and a somewhat more formal track for more difficult disputes. I do not really care whether we have one name for the forum for the two weights of content disputes or two names, but I think that it will be useful to recognize that some cases are simpler than others. It is true that the parties and the volunteer may not know until starting into a dispute whether it is simple or difficult, so maybe most content disputes should start off being assumed to be simple, but there should be a way of changing the handling of a dispute if or when it is seen to be complex. This proposal is a recognition that content disputes are not one size, and one-size-fits-all dispute resolution is not available. Robert McClenon (talk) 03:58, 26 January 2025 (UTC)
  • Support per Steven and Robert. My outsider's perspective of DRN is that it is very bureaucratic, but also not great at handling complex, intractable cases, especially where animosity has built up between involved editors. (Please correct me if this assessment is inaccurate.) I think it makes sense to "split" it into two venues as proposed. Toadspike [Talk] 09:48, 26 January 2025 (UTC)
    I do see that it can be perceived as a bit bureaucratic, yes, and can struggle with some more difficult disputes. It used to be much more simple and less rules focused - ideally re-establishing MedCab would allow DRN to return to it simple origins, perhaps even allowing DRNs simplified structure to be more conducive to new volunteers participating. A possible style of how a dispute at DRN could look, with perhaps even less structure, is Wikipedia:Dispute resolution noticeboard#Jehovah's Witnesses (which, full disclosure, is one that I handled and is an example of my style of dispute resolution). Steven Crossin Help resolve disputes! 09:58, 26 January 2025 (UTC)
    How you handled that dispute does not require a new project page for a new process. Everything can take place at the existing WP:DRN. The DRN volunteers can opt for the less or more formal process upon their discretion. Just like you did here. —Alalch E. 13:04, 26 January 2025 (UTC)
    No, it didn’t. This is a simple one. But disputes like Talk:William Lane Craig/Mediation and some others that were forked/moved away from previous DRN discussions would benefit from this revived forum (as a noticeboard is not conducive to dispute resolution for drawn out, complex issues. How disputes are handled on DRN is open for interpretation by the volunteers, but there’s agreement among at least Robert and I (two of the main DRN volunteers) that having distinct dispute resolution process for simple versus complex disputes would be of benefit. Steven Crossin Help resolve disputes! 13:10, 26 January 2025 (UTC)
    I agree that the dispute that was processed there was a complex one, but so is Wikipedia:Dispute resolution noticeboard/Autism. So, here, we are discussing two approaches to resolving complex disputes. The approach exhibited in your example is like a three-sided peer review (similar to Wikipedia:Peer review, except it isn't just the requester and the reviewer, there's also the "other side"; but the reviewer does indeed break content down sentence by sentence as in a peer review, and make editorial assessments), and the approach taken by Robert McClenon is more like a formal debate. Do you think there's something wrong with the ongoing autism dispute resolution? Can both methods not coexist as different approaches to problems of similar complexity? —Alalch E. 14:11, 26 January 2025 (UTC)
  • Oppose, I guess? Frankly, I don't think structured mediation works on Wikipedia. What I have seen work (constantly) is: 1) talk with the other editor, but not uncommonly people will just have fundamentally different views. 2) if so, advertise to a noticeboard to get more editors to weigh in. If a specialised noticeboard captures the dispute, then any of: WP:FTN, WP:NPOVN, WP:BLPN, etc; otherwise WP:3O. That seems to work for most small to medium trafficked articles. 3) Failing that, WP:RFC.
    I can't remember when I last saw a dispute that mediation resolved. I mean, here's a random DRN archive: Wikipedia:Dispute_resolution_noticeboard/Archive_252. The discussion closures are: "opened by mistake", "premature", "withdrawn by filer", "not an issue for DRN", "closed - RFC is being used", "closed - not discussed in the proper forum", "participation declined by one editor, withdrawn by filer", "closed - one participant is an IP editor with shifting IPs", "closed as abandoned", "closed due to lack of response", "filed in wrong venue", "closed - pending at ANI", "closed as pending at WP:RSN", "closed as DRN can't be helpful here", "other editor hasn't replied", "apparently resolved - one editor has disappeared", "premature", "wrong venue", ... I kid you not, I haven't skipped any sections out, I just went off the top of the archive. Given this, it's hard to seriously say that mediation works. And it sort of lines up with my anecdotal experiences: it's pretty common for editors to never really come to a compromise agreement that all parties are happy with. Ultimately, a lot of content disputes are decided by '(maybe some compromise) and majority wins' or 'one participant disappears / gives up' or 'some compromise and universal agreement'. Though, the cases where 'some compromise and universal agreement' works appears so much like a discussion that we wouldn't even call it a dispute, and I think any cases that could be successful through mediation, the editors could've just figured it out among themselves anyway. ProcrastinatingReader (talk) 18:16, 26 January 2025 (UTC)
    I wish mediation would work more effectively in more complex disagreements on English Wikipedia. Unfortunately, as I discussed elsewhere, it doesn't scale up well to handle disputes with a lot of participants (in the real world, the mediation participants are limited to representatives for the relevant positions), and it requires sustained participation over a substantial period of time, which doesn't work well with Wikipedia's volunteer nature. For mediation to work, the community has to be willing to change something in its decision-making approach to overcome these challenges. For better or worse, I don't see sufficient signs of desire to change in this manner. isaacl (talk) 18:41, 26 January 2025 (UTC)
    My limited experience with 3O is that it's a very nice idea, but very rarely actually resolves the dispute. I've handled two, and I don't think I did a particularly bad job, but this one looks like it was solved by itself/by other uninvolved editors and this one was the typical outcome, where the 3O outcome was simply not accepted and the dispute remained unresolved. Another example (not handled by me) ended up at DRN regardless. And in all of these examples, the editors were acting in good faith. Toadspike [Talk] 09:57, 27 January 2025 (UTC)
  • Support - Informal mediation takes away the heavy bureaucracy costs with wikipedia and can lead to faster resolution. SimpleSubCubicGraph (talk) 00:32, 27 January 2025 (UTC)
  • I've no strong feelings about how we organize mediation, though I've recommended DRN to editors and I have participated in the current /Autism case at DRN. However, I do strongly believe that when editors say that something isn't working for them, especially when they're the main editors running the process in question, we should believe editors. If they think that splitting complex cases off into a separate process would help, then we should let them. WhatamIdoing (talk) 17:29, 27 January 2025 (UTC)
  • Ambivalent - I was very active on MedCab and briefly chaired MedCom, but that was 15 years ago. Me and Steve (and of course others, but just speaking from experience) have been on-and-off, come-and-go in the intervening years. Since then we've been reduced to one long-running mediator on the whole project: Robert McClenon. So you can imagine the problem this poses if we introduce another project and it comes down to mainly Robert again. Mediating is frustrating, requires a ton of patience, and it's subject to rapid burnout. Props to him; his endurance is incredible.

    But let's say that this doesn't happen, that reopening MedCab brings in a bevy of new volunteers (a big if). Now let's say there's some big dispute somewhere, and it's filed at DRN. The volunteers at DRN say "this is too big for us, file it at MedCab". OK, so we have two filings now - and these are annoying to file: there's a lot of boilerplate, and even the way you file one is different from the way you file the other. But OK fine, they're filed. Now this is a particularly difficult dispute, and one or two editors says "no, I don't want to be involved in this mediation". MedCab didn't have a policy for what to do in this situation (unlike MedCom, and that policy absolutely was its death knell), but some MedCab volunteer comes along and closes it anyway because there's no consensus for mediation. What now? Well, you could refile at DRN (a third filing) and maybe a volunteer there suggests that an RfC is maybe the way to go. So that's four filings. tbqh, this might actually resolve the dispute, from the burnout of the filer alone.

    I'm marking this as ambivalent because I preferred the way MedCab handled DR. To me, a lot of this "DRN is too bureaucratic" talk is just a symptom of all of DRN being on a single page; MedCab/Com subpaged its cases, so it wasn't obvious how bureaucratic they could be. How (eg) Robert currently mediates is not very different from what a typical MedCab or (especially) MedCom case looked like; it just wasn't out in the open.

    I do not see why we can't formally change DRN's mandate to include lengthier mediation, and possibly subpage those cases that are more complicated. I say "formally change" because DRN already does lengthier mediations and has done so for years, it being the only option once MedCab closed and MedCom accepted zero cases for literal years.

    Anyway, in conclusion: MedCab is just DRN with subpages, and I'm not convinced this doesn't solve a seeming bureaucracy with an actual one. Xavexgoem (talk) 20:49, 27 January 2025 (UTC) I'm also marking this "ambivalent" because I like the name The Mediation Cabal. I honestly believe (don't laugh) that we'd have more volunteers not because we've made another process that better suits certain editors, but because that process would be called The Mediation Cabal. It's what drew me in, anyway.

    I'd say that dispute resolution on Wikipedia can be what we as volunteers make it. Part of the idea of reviving MedCab is to give dispute resolution some distinction - make DRN for the easy stuff and informal mediation for the complex. The rationale behind this has a few reasons - the perceived bureaucratic, structured nature of DRN could likely hinder participation by other volunteers (I base this mostly on anecdotal feedback I've received, reviewing talk page discussions and the fact that DRN had more volunteers historically when it was largely unstructured - and while I realise that correlation doesn't always equal causation, its a factor). This doesn't necessarily mean that editors would have to re-file at MedCab if DRN volunteers decided it was better suited to MedCab - early on when DRN was instituted, there was an idea that DRN volunteers could refer cases to MedCab/MedCom, minimising that work for the editors involved. Mediators can and should help editors draft an RFC if that's an intended way to resolve the dispute (and sometimes, that's what mediation can be - helping participants boil down the issues into a few structured proposals for an RFC) - which is something I've done in the past with good outcomes. And while mediation is voluntary, Wikipedia's always had the idea that if there's one editor that refuses to participate or work with others to form a consensus (and then comes back and says "no I disagree with you ten editors, I'm gonna edit war my way out of this" then that becomes a conduct issue). MedCab doesn't necessarily need to have all the boilerplate it did in the past - as I said we can make DR what we want. But I do see the value in trying to split out the processes, to allow us to emphasise the intended lightweight nature of DRN (and then hopefully allowing volunteers to get involved i.e. "That just looks like a normal noticeboard discussion, I'll chime in etc") but keeping a venue for those challenging disputes, and is why I think just subpaging cases we decide are challenging later isn't the right approach. Steven Crossin Help resolve disputes! 21:05, 27 January 2025 (UTC)
    Very basically, I don't think we have the resources or volunteers to spare to make this process smooth from the outset. I do not understand this want to return to something more "ideal" -- as you had envisaged -- so far into the lifespan of this particular project.
    My above comment was too wordy. I'll reiterate: MedCab is just DRN with subpages. Does that serve the initial purpose of DRN? No. Is it years and years later? Yes. Xavexgoem (talk) 06:02, 1 February 2025 (UTC)
  • Disclosure that I was invited to participate here.
    Weak oppose but support iterative improvements to DRN to make it easier to use. It's true that DRN started as a triaging process, with the secondary objective of resolving simpler disputes. Doing mediations under a separate project page might make them seem more structured/less off-the-cuff/whatever, but I'm not convinced that this is worth administering a whole separate process. Nor will removing mediation likely improve DRN. The trend has been towards consolidating processes (MedCab, MedCom, WA, and more having fallen away over the years). That should not be reversed without good reason. I do think that DRN should move mediations off the main noticeboard and onto subpages. Some of the mediations are also very difficult to follow, with threaded statements in the style of ArbCom and the adoption of rules like a tribunal's rules of procedure. The noticeboard instructions could be slimmed too. I would support those iterative improvements. I'm not absolutely opposed to starting a new mediation process – I just don't think it matters too much. Where the best result of a change is likely to be the same number of successful cases/editors volunteering to mediate/users agreeing to participate in mediation, the status quo should probably default.

    I also support the underlying enthusiasm to get more users doing mediation. I am unconvinced by the argument that because something like 0/20 DRN threads show a successful mediation, we shouldn't do mediation at all. Almost no disputes will be suited to mediation; it's a niche solution for use where a dispute has not been resolved by the ordinary wiki way (which includes attrition, disinterest, or removing the bad actors). Mediation can do what perhaps only a structured community RFC can achieve, and for a fraction of the time cost. arcticocean ■ 10:21, 28 January 2025 (UTC)

    Arcticocean, thanks for your comments here (and for disclosure to others, I notified them of this discussion to see if they were interested in providing their thoughts, due to their role as a former chair of the Mediation Committee, and that they were involved, on and off in Wikipedia dispute resolution for as long as I have been). I'm not opposed to the idea of trying to see if slimming down DRN's main structure and paring down the rules would have an impact, but subpaging cases we decide need mediation (or just, longer disputes). I'm just not sure about how to provide visibility of those disputes on the main DRN page, or just being able to still track the progress of them (as at present, if we subpage the dispute and it completely disappears into the ether) - and this was part of the reason why I thought splitting these two different dispute resolution styles would make the most sense. But I'm not overly fussed on the where, just the how. Do you (or others here) have any ideas on how we could implement this two-track system on the one forum? Steven Crossin Help resolve disputes! 11:12, 28 January 2025 (UTC)
    What about this, which doesn't need much to be changed…? If a dispute regarding Moon is at DRN and enters mediation, then:
    1. At WP:DRN, under the header == Moon ==, replace the noticeboard discussion with a link to the mediation page: [[/Mediation/Moon]].
    2. On the case status tracker, update the status to "in mediation".
    That would allow DRN volunteers to deliver a full mediation service where appropriate, while allowing DRN to continue functioning as a noticeboard (providing basic advice, signposting, and assistance to disputants). If I've picked you up correctly, this addresses your concerns that the noticeboard has become bloated and that delivering full mediation through it has become difficult. arcticocean ■ 11:56, 28 January 2025 (UTC)
    See, this is why I was hoping to get your thoughts. This I think is a great idea. We could even have a short blurb on the /Mediation page for reference. I’ll possibly start working on some draft amendments as I’d like the DRN bot to still
    be able to handle tracking them. @Robert McClenon: - do you think this approach could work? Steven Crossin Help resolve disputes! 12:36, 28 January 2025 (UTC)
    User:Steven Crossin, User:Arcticocean - I am not sure, but I think that either I do not understand the question or I agree with the idea. As I have said earlier, I do not have a strong opinion as to whether MedCab, or something similar to it, should have a separate door from DRN or be something that is entered via DRN. I think that it is important that we have a streamlined procedure for handling simple issues and a more structured procedure for handling more complex or more stubborn issues. Now: What was the question? Robert McClenon (talk) 20:31, 28 January 2025 (UTC)
    What was the question? It's "do you think this approach could work?" And the 'approach' is right above that question, in my comment (11:56, 28 January 2025 (UTC)). In short, when a DRN case gets referred to mediation, the discussion would move onto a subpage of DRN and the DRN report would be replaced with a link to the subpage. arcticocean ■ 08:35, 31 January 2025 (UTC)
  • Support Med Cab was awesome, especially in the quality of facilitators it attracted. A successful mediation generally takes the form of whittling down the issues through discussion, gathering 'evidence' that each side looks at critically and often comes to agreement on (at least as to it being decent evidence on the issue) -such deep dives even changes minds(!) sometimes, and constructing really useful RfC's (often with reference to evidence) through discussion/monitored drafting for what remains to be determined.

    As a side benefit, if there are behavioral issues 1) the presence of the mediator often cabins it, and 2) it regularly becomes clearer for the entire project what the problem behavior is (even if its just failure by one side to even try to work it out in good faith) Alanscottwalker (talk) 16:34, 28 January 2025 (UTC)

  • Support per Robert McClenon and Toadspike. JJPMaster (she/they) 21:48, 28 January 2025 (UTC)
  • Support. I think there is a place for something like this to exist. I think DRN and RFCs have limitations. Andre🚐 09:53, 31 January 2025 (UTC)
  • Questions from a content editor Why would DRN now be limited to disputes of a (seemingly arbitrary) time period? You don't know how long a debate will last at the outset. Further, this solution seems like it would add another rule, another layer of complexity, to our on-wiki processes, whereas I like the simplicity of our current processes. JuxtaposedJacob (talk) | :) | he/him | 16:12, 31 January 2025 (UTC)
    I also think that arcticocean makes a good point regarding the trend being towards the consolidation of processes; this community consensus exists for good reason. JuxtaposedJacob (talk) | :) | he/him | 16:13, 31 January 2025 (UTC)
  • Why do we always immediately jump to voting? Perhaps the reason dispute resolution is difficult on Wikipedia is because our first instinct in a discussion is to create and affiliate with factions? Anyway, I think revisiting and discussing where our dispute resolution processes succeed and fail is a good first step to improving them. My thoughts fall somewhere between Whatamidoing and ProcrastinatingReader: I think we should trust editors active in an area to iterate on processes, but I worry that a solution based on more bureaucracy could create more problems than it solves. To me that suggests a trial period would be useful to get more info and keep iterating. — Wug·a·po·des 18:59, 31 January 2025 (UTC)
    That might not be a terrible idea, but it might be useful to have some specific metric or thing that you judge success by -- like, how would you tell if it worked or not? Otherwise, it'll be the same argument afterwards. Mrfoogles (talk) 05:26, 7 February 2025 (UTC)
  • Support As a former MedCab Coordinator (and briefly a member of MedCom), I've long thought that we consolidated mediation too far. At one point we had a variety of different forms of mediation to suit different needs that were more or less active. Now, there's just one Robert trying to be everything. I think the result of that has been less compromise on-wiki as it's been replaced with an adversarial system of noticeboards and RFCs to determine which side is right, rather than coming up with something all sides can mostly agree with. There's no harm in at least trying it. The WordsmithTalk to me 05:03, 7 February 2025 (UTC)
  • Comment: To be honest I'm not completely sure what the correct solution is, but I did want to say if I remember correctly the "person who thinks about helping at DRN but doesn't because it's too formal and involves too much bureacratic responsibility" is me, so it does happen. I might participate in some form of DRN where you can just drop in without having to sign up to mediate something actively for 2 weeks (e.g. talk page argument level of commitment), otherwise it's not as interesting. I don't know about other people. Mrfoogles (talk) 05:25, 7 February 2025 (UTC)
  • Oppose. MEDCAB and some similar things failed for real reasons, chief among them the very lack of formality, i.e. the lack of any rules (short of site-wide policy like WP:NPA) regarding input, and lack of any enforcement ability. The only way a mediation committee sort of thing could work is if it were imposed (by the community or by WMF) as being enforceable along similar lines to ArbCom. Work instead toward improvements to existing WP:DR processes.  — SMcCandlish ☏ ¢ 😼  04:25, 8 February 2025 (UTC)
    They did not fail for the reasons you have stated. Medcab closed because there was a vote to dissolve it after DRN made it seem redundant. Medcom was closed when it was pointed out that they hadn't accepted any cases for years. Xavexgoem (talk) 07:50, 8 February 2025 (UTC)
  • Support a trial period of one year In principle this would be good, but as always, in practice this needs volunteers ready to go until the process becomes self-sustaining. If at the end of one year the process is regularly accepting and solving disputes then sure, let it continue. If all the volunteers have disappeared and the backlog is long and stagnant let it die a natural death. ~~ AirshipJungleman29 (talk) 20:13, 13 February 2025 (UTC)
  • Support trying this. There's no shortage of chronic content questions which need resolving, and maybe this will be the thing that solves some of them. We don't know until we try. And ultimately, if Robert McClenon thinks this would help improve DRN, I am inclined to believe him. HouseBlaster (talk • he/they) 03:45, 16 February 2025 (UTC)

Addressing Two Concerns

I will try to address the comments of User:Alalch E. and of User:ProcrastinatingReader separately, since they seem to have separate, almost opposite issues. In particular, one of them seems to be saying that content dispute resolution is working reasonably well and should not be changed, and the other one is saying that content dispute resolution works poorly, and is not worth improving.

First, I am not sure whether I understand the concerns of User:Alalch E., but I think that they are saying that DRN is currently where editors go when they have content disputes, and should continue to be able to go to DRN when they have content disputes. That will still be possible after MedCab is restarted. I do not have a strong opinion on whether DRN should be the front door to MedCab, or whether MedCab should have its own front door. However, DRN is able and will be able to refer disputes to appropriate forums. DRN sometimes refers issues to the Reliable Source Noticeboard if they are questions about the reliability of sources, and sometimes refers issues to the biographies of living persons noticeboard if BLP violations are the main concerns. If MedCab is a separate dispute resolution service, a DRN volunteer will be able to send a case to MedCab if it is either too complex for a lightweight process or the editors are too stubborn to use a lightweight process. I will point out that if the users are stubborn, the dispute is likely to go to an RFC after mediation. Although I close a dispute that ends with an RFC as a general close rather than as resolved, I consider the dispute resolution a success. The dispute likely would not have gone to an RFC in an orderly fashion without volunteer assistance.

Perhaps Alalch E. is saying either that a one-stop approach to resolution of content disputes will work better, or that there is no need for a two-track approach to content disputes, or that defining two tracks will interfere with dispute resolution. If so, I would be interested in the reason. My opinion is that the current one-size-fits-all approach works about as well as one size of clothing. On the one hand, some users have said that DRN is too bureaucratic. Moving the complex or difficult cases to another forum will allow DRN to be more informal. On the other hand, I have found the statement that DRN is mostly for cases that will be resolved in two to three weeks inconsistent with some of the more difficult cases that we have had. I would prefer not to have to ignore a guideline or to develop a special procedure for difficult cases, and those cases would fit better in MedCab.

Second, ProcrastinatingReader appears to be saying either that mediation does not work well in Wikipedia, or that content dispute resolution does not work well in Wikipedia. I may have misunderstood, but they seem to be saying that the state of dispute resolution in Wikipedia is so hopeless that it is not worth trying to improve. I will comment briefly that I consider some of the closures that they cite as successes rather than failures. An RFC resolves a content dispute. A referral to the Reliable Source Noticeboard resolves the question of reliability of a source. I am aware that content dispute resolution does not always work. I think that recognizing that there are at least two tracks for content disputes, a lightweight track and a more formal track, will improve its functioning. Also, some of the disputes that were closed as not having met preconditions might have been able to be helped if DRN were made more lightweight by transferring the responsibility for difficult cases to MedCab. I think that ProcrastinatingReader may have showed that some of those disputes could have been handled somehow if dispute resolution were improved, and I think that the two-track concept outlined here is likely to result in improvement.

These two comments appear to be almost opposite reasons for disagreeing with the plan. I have tried to address both of them. Robert McClenon (talk) 05:39, 27 January 2025 (UTC)

Thanks Robert. I'll briefly summarise my thoughts on some of the comments here. As someone that's been involved in Wikipedia content dispute resolution for over a decade, I know it's not perfect. Some disputes get logged at DRN that might be better suited for another forum, or might merit further discussion at the talk page. Some editors might decide not to participate, and that's fine - participation on Wikipedia is voluntary. DRN was never designed to be able to fix every single content dispute on Wikipedia - the original proposal was to handle lightweight content disputes, or act as traffic control for a dispute that might be better suited to somewhere like RSN or BLPN, and in my mind, that's completely fine. Does DRN close disputes a little early sometimes, where perhaps we could have helped the dispute a little better? I'm sure that's happened. But again, we're acknowledging improvements are needed and proposing change.
Mediation, both informal and formal, was never perfect either, and indeed had cases that were not successful. But it also had its successes, just as DRN does, such as this recent example that I handled, and there are others in archives too. MedCab had its share of successes, as did MedCom. And every mediator has their own style of handling disputes - mine is often more freeform, others implement a bit more structure. The discussion here is not a suggestion that mediation is the magic bullet that will fix all of Wikipedia's dispute resolution problems, or that DRN is a complete mess - it all needs improvement. One of the primary reasons I decided to return to Wikipedia after more than 2 years away is because I saw how dispute resolution is on Wikipedia, and decided it was to do something about it. Re-establishing informal mediation as a process would allow DRN to return to its lightweight original style, likely encouraging new, uninvolved editors to participate and volunteer, but provide the structure that's sometimes needed for more difficult content disputes that can benefit from an experienced hand to guide editors towards a consensus. As one of the people that pushed to close MedCab as a redundant process (which at the time, I was one of the co-ordinators), I agreed back then, it wasn't needed. But there's now a gap that I think it could fill. Heck, it could even be re-established on a trial basis. DRN was started as a one-month trial 14 years ago, and it endures today. It needs improvements. Everything on Wikipedia does. I think with many of the dispute resolution volunteers willing to try, it's worth giving it a crack. Steven Crossin Help resolve disputes! 09:51, 27 January 2025 (UTC)
The former - that mediation doesn't work well in Wikipedia. I'm not quite a nihilist :) -- I think dispute resolution in Wikipedia is a bit counter-intuitive, but I do think it works. IME it works the way I outlined, and further I do think outcomes like "one party gives up and disappears from the dispute" is a form of "dispute resolution", in that the dispute ends. I'm not sure if it's for the better, but oftentimes in these cases, another editor will asynchronously pick up where the first left off, so the end result is more or less the same. I think the (long) comment isaacl linked above has some truth in it, particularly (for this context) the comments regarding the effects of the volunteer nature of Wikipedia.
There are certainly shortcomings in dispute resolution here that can be improved, but I don't think it's through mechanisms like expanding voluntary mediation, which has (IMO) proven not to work here. I think we need to start with acknowledging how dispute resolution actually works on this site, and thus what works here and in communities like this one, as opposed to how dispute resolution works in the office.
I agree that referrals to RSN are good at solving the issue. But in this case, DRN is just acting as a very longwinded redirect, perhaps primarily useful for newer editors who aren't familiar of noticeboards here. An experienced WP:3O volunteer could've also just told the parties "hey, go to RSN for this", and it'd be much smoother. ProcrastinatingReader (talk) 09:57, 27 January 2025 (UTC)
I wonder how often DRN gets disputes involving two editors. Wikipedia:Arbitration/Requests/Enforcement has just been reduced to reports of two editors in Wikipedia:Arbitration/Requests/Case/Palestine-Israel articles 5#AE reports limited to two parties. (If you need to complain about three people, you have to file three separate reports.) This was because multiparty reports were complicated. BRD (in its original version, not Wikipedia:What editors mean when they say you have to follow BRD) similarly recommended one-on-one negotiations instead of trying to talk to a bunch of people at once. It's easier for "you and me" to agree on something than for "you and me and him and her and them", because in larger groups, one unreasonable person could prevent everyone else from discovering that they could reach an agreement. Does DRN have the same struggle? WhatamIdoing (talk) 23:26, 27 January 2025 (UTC)
Correction: AE will only consider reports about one person. The second person being considered is the filer. Best, Barkeep49 (talk) 11:20, 31 January 2025 (UTC)

Just a minor take on the relative success of mediation: A lot of the value of mediation, imo, is retention. Mediators can exercise some control on participants' behavior, which can keep them from getting blocked. You can argue that, well, maybe these people should be indef'd or banned or whatever; but we're so frequently dealing with complicated, hot-under-the-collar issues that require from some people just a capital-G Godly amount of patience. I would in general prefer editors not be blocked if despite their civility problems they are otherwise contributing solidly to the project. So it's not just the success of the case. We are never going to have, say, an Israel-Palestine case get marked "resolved" without simultaneously winning a Nobel. Xavexgoem (talk) 21:05, 27 January 2025 (UTC)

Can folks link to some recent success stories at DRN? Especially where, say, an RfC failed to resolve something but DRN succeeded? I know MedCom had some successes by virtue of its binding nature, but it sounds like that's not on the table at the moment. There's a lot not to like about defaulting to RfCs (like what Wugapodes said), but my sense is that most people feel like they work well enough that a more time-consuming, labor-intensive, structured process isn't likely to succeed that much mroe often. But perhaps I'm just not the audience, or maybe my efforts are in topic areas that don't really benefit? Is it mostly newbies? There's absolutely something to be said for mediation, and I have a lot of appreciation for people willing to put their mediation skills to use here. I just don't know how often I've seen formal-but-voluntary mediation work in practice. All of this is to say, if we're effectively talking about extending DRN, it would be nice to see what we're extending (saying this with ignorance more than skepticism). — Rhododendrites talk \\ 16:27, 9 February 2025 (UTC)

I'm not familiar enough with DRN to answer, although it's a good question – we need that data. I would just raise concern about the notion that a mediation is labour-intensive relative to an RFC. A mediation is essentially the method of DR that requires the least community effort while still escalating the matter and involving someone other than the article editors. The best mediations build up their own steam and don't even need much input from the mediator, let alone anyone else in the community. An RFC, by comparison, is a highly inefficient way of resolving disputes, although often a very effective one. arcticocean ■ 20:17, 9 February 2025 (UTC)
Just regarding being time-consuming, for most people in most RfCs, you articulate an argument, hit save, and then your participation is done. DR you're signing up for a longer discussion both in terms of output and time. (Though, yes, I know sometimes people get very involved in an RfC and spend time on it the whole time it's open ... that's usually not ideal, though). — Rhododendrites talk \\ 13:17, 10 February 2025 (UTC)
Bump to prevent archival. * Pppery * it has begun... 18:07, 25 February 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.

Mentioning UNDUE on Template:Primary sources

I've opened a discussion at Template talk:Primary sources#Adding a note about due weight about whether WP:UNDUE should be mentioned in the template. Thebiguglyalien (talk) 🛸 04:44, 27 February 2025 (UTC)

Allow file movers to upload files locally that share a name with a file on Commons

TLDR: Grant the File movers group the reupload-shared permission.

Rationale: Currently, only admins have the reupload-shared permission, which allows a user to upload a file here that has the same name as a file on Commons. As a Commons admin, I occasionally delete files there (for being non-free) which are in use here. To move the file here, I have to 1) upload it here under a temporary name, 2) delete the file on Commons, 3) move the file to the correct name here, and then 4) request speedy deletion of the redirect I've left behind. (I prefer not to delete the file on Commons until after I complete the local upload, both because it makes the process of filling out the local upload form easier, and because it means I don't have to undelete the file if the local upload goes wrong). This wastes both my time as the uploader and an admin's time deleting the redirect. When I was discussing file migration options in the admin channel of the Wikimedia Community Discord yesterday, a local admin suggested this idea. reupload-shared and movefile seem to me to require a similar level of trust, and expertise in the same namespace.

  • Support as proposer. The Squirrel Conspiracy (talk) 02:57, 19 February 2025 (UTC)
  • Support * Pppery * it has begun... 05:50, 19 February 2025 (UTC)
  • Support ~ 🦝 Shushugah (he/him • talk) 06:24, 19 February 2025 (UTC)
  • Support, seems to require the same levels of trust/competence. CMD (talk) 07:48, 19 February 2025 (UTC)
  • Support Sensible idea. -- King of ♥ ♦ ♣ ♠ 08:51, 19 February 2025 (UTC)
  • Support per nom. Also, would that allow file movers to undo any move made by a file mover, or is another permission needed for that? Chaotic Enby (talk · contribs) 11:04, 19 February 2025 (UTC)
  • This is a reasonable-sounding usecase, but I can't support it. There are a lot of file movers - this would increase the number of users who can change the main page by almost half - and while I trust most of the usernames there that I recognize, and while I'm sure there's other Commons admins among them who, like Squirrel Conspiracy, I don't recognize, there are several who used to be able to edit the main page but lost that privilege for cause. This risk isn't worth the inconvenience it would mitigate. —Cryptic 11:30, 19 February 2025 (UTC)
    Maybe this would be technically more difficult to implement, but would there be a way to make it so that cascade-protection prevents reupload-shared? Chaotic Enby (talk · contribs) 11:40, 19 February 2025 (UTC)
    Or protection of the underlying image at Commons. But both of those are well outside the one-line config change proposed here. —Cryptic 11:47, 19 February 2025 (UTC)
    That sounds like a bug that should be reported on Phabricator. * Pppery * it has begun... 17:20, 19 February 2025 (UTC)
  • I kinda worry that this will result in a lot of questionable decisions to put local files over a Commons file. Not all edits to Commons files are bad, in fact, I suspect it's more the other way around. Jo-Jo Eumerus (talk) 14:36, 19 February 2025 (UTC)
  • Support while noting that I'm the person who suggested this idea. I'm not worried about the main page here, as the images on Commons could already be uploaded-over. I seriously doubt any of our file-movers, even those desyopped for-cause, would use this for vandalism, and if so that could be quickly resolved. As for questionable overwriting decisions, I'd hope and expect that our file-movers would have a good understanding of when files should be local. If this goes poorly, it can be reversed, but it's better than requiring sysop for this task. Elli (talk | contribs) 17:41, 19 February 2025 (UTC)
  • Support per Elli. charlotte 👸♥ 19:15, 19 February 2025 (UTC)
  • Support as if file-movers abuse this, they should lose that ability. Graeme Bartlett (talk) 21:47, 19 February 2025 (UTC)
  • Support, but with conditions. I can't say for sure that the use case the OP has pointed out is the only use case for this permission by file movers, but it should be trivial to add reasonable restrictions to when non-admin filemovers can use this permission, such as "when a file is being deleted from Commons but meets the criteria to be uploaded locally either under enwp policy or non-free use criteria". I would not support non-local-admin filemovers being able to use this permission, for example, to upload local versions of high traffic files, since they by definition can't immediately protect those files and I believe (please point out if I'm wrong) that once it's uploaded, anyone could replace it with a new version pending it being protected which may take some time. -bɜ:ʳkənhɪmez | me | talk to me! 21:51, 19 February 2025 (UTC)
  • oppose the hassle presented in the proposal is understandable, but it's a relatively rare need AFAIK, especially when contrasted with the huge potential for mistakes and confusion. It looks like this is going to pass, so I hope someone has a regular report ready to ensure we never have a local file with the same name as an extant (not deleted) commons file. — Rhododendrites talk \\ 23:35, 19 February 2025 (UTC)
  • The Squirrel Conspiracy, how many file movers are also Commons admins and do this kind of work regularly? Could we maybe just make you (and anyone else) an admin here instead? WhatamIdoing (talk) 03:14, 20 February 2025 (UTC)
    Note that Squirrel Conspiracy (narrowly) failed in the last AELECT. charlotte 👸♥ 05:31, 20 February 2025 (UTC)
    Oh, that's too bad. I was thinking that having a clear purpose would be a positive thing at RFA. WhatamIdoing (talk) 06:21, 20 February 2025 (UTC)
    If people here think I have a realistic chance of success going through the conventional route, I'm happy to talk to potential nominators, but I assumed that my lack of recent local activity would be a dealbreaker. The Squirrel Conspiracy (talk) 16:17, 20 February 2025 (UTC)
    We've made people be admins under similar circumstances in the past, but I don't know how long it's been since the last time. I don't hang out at RFA. WhatamIdoing (talk) 18:01, 20 February 2025 (UTC)
  • Oppose this is an edge case, and an edge case about another project. We shouldn't be creating shadows-commons files here. This would also override upload-protected files on commons here, by allowing non-admins to just upload local copies. — xaosflux Talk 10:32, 20 February 2025 (UTC)
  • Support, but there needs to be a bot or other system that flags local files that share names with Commons files so that errors don't slip through the cracks. ꧁Zanahary꧂ 22:27, 20 February 2025 (UTC)
  • Support. The people saying that this is a rare occurrence are being somewhat optimistic. I track down a lot of copyvios on Commons and unfortunately it's semi-regular for an image to have gone undetected long enough that it gets used in an article by someone well meaning. I didn't know the process to remove them from here was so tedious. Gnomingstuff (talk) 23:39, 21 February 2025 (UTC)
    Gnomingstuff, it's because there's a EnWiki --> Commons importer, but not a Commons --> EnWiki importer. Ideally we'd have a version of the tool that moved files back out of Commons, but I suspect the volume is low enough or the problem obscure enough that that's why no one has developed such a tool. The Squirrel Conspiracy (talk) 01:09, 22 February 2025 (UTC)
  • Support for now -- Main page vandalism will be immediately noticed and the person responsible will lose permissions. Vandalism of other pages using this is less of a serious concern. I think this change may have to be reverted if vandalism does turn out to be a problem, but as file movers are approved, I think that Wikipedia should try to give people the level of trust they need to fix the things they want to fix. Mrfoogles (talk) 16:51, 25 February 2025 (UTC)
  • Support - if there turn out to be more downsides that we expect, we can undo later. The potential amount of damage seems limited enough that I'm not worried about try-it-and-find-out-what-happens. --SarekOfVulcan (talk) 17:26, 25 February 2025 (UTC)
  • Support. Commons and enwiki have very different policies on copyright, especially with regard to PD in source country. I don't understand why people are saying this is an edge case. Toadspike [Talk] 12:35, 2 March 2025 (UTC)
    I think it's because it's only a small fraction of files where the difference in copyright matters. I also suspect that in many cases, uploading the file to a different name is a perfectly valid option. Jo-Jo Eumerus (talk) 09:03, 3 March 2025 (UTC)
  • Oppose While I can understand the frustration, the example given perhaps requires some more targeted technical solution. Permitting all file-movers to re-use filenames already in use on Commons will, in my view, result in:
  • The widespread duplication of files on this project simply because it is convenient to do so, undermining the fundamental principle that media should be hosted on Commons wherever possible. Unless there are compelling technical or legal reasons, we should not be creating shadow versions of Commons files;
  • Errors and confusion, where different files are inadvertently uploaded or moved to a filename already in use on Commons and linked from this project.
It is unrealistic to expect file-movers collectively to have the experience or vigilance to avoid such issues. MichaelMaggs (talk) 10:06, 3 March 2025 (UTC)
There are only 389 file movers, so I think it is unlikely that any mass duplication will be "widespread". JJPMaster (she/they) 19:14, 3 March 2025 (UTC)

Please see

Please Wikipedia talk:Talk page guidelines#AI for translation and grammar checking. Please comment over there. WhatamIdoing (talk) 03:57, 5 March 2025 (UTC)

Time for a new Nutshell Icon?

No consensus has emerged in favour of this proposal, and since opposition to it is unanimous, it walnut be likely to emerge in future. Fortuna, Imperatrix Mundi 17:41, 5 March 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.

Hi, I believe it is time to consider updating the icon used for nutshell to a more contemporary design. The current icon have been in use since 2006, and after 18 years, I am of the opinion that it merit a refresh. Regards Riad Salih (talk) 17:44, 25 February 2025 (UTC)

It isn't used on very many en.wikipedia pages, but is globally used on quite a few pages, so it seems like your suggestion should take place at the file page on Commons. Schazjmd (talk) 17:53, 25 February 2025 (UTC)
The other option would be to replace its uses here with a new file (rather than changing the current file), in which case making the suggestion here does make more sense. Chaotic Enby (talk · contribs) 18:14, 25 February 2025 (UTC)
It's mainly used to summarize all policies, guidelines, and essays so the number isn't too large but not too small either. When changing an icon here, we don't usually open a discussion on Wikimedia Commons since it's used in a template here. Riad Salih (talk) 22:47, 25 February 2025 (UTC)
What is wrong with the current icon, other than it being old? If you are unable to articulate any specific problems the current design is causing or specific benefits a different design would bring then this just feels like change for the sake of change (c.f. WP:BROKE). Thryduulf (talk) 18:15, 25 February 2025 (UTC)
The design of Wikipedia evolves over time. If we consistently apply WP:BROKE to all proposed changes, Wikipedia would end up looking like it did in 2001. We simply need a way to insert text, media, and references; nothing more.
I think we are not obligated to retain icons indefinitely, also the design does not align with the OOUI icons developed by Wikimedia. Riad Salih (talk) 22:58, 25 February 2025 (UTC)
Wikipedia doesn't look like it did in 2001 because we've made changes that have fixed identified problems or otherwise made identifiable improvements. We are indeed not obligated to retain icons indefinitely, but equally we are not required to change icons just because they haven't been changed in a long time. The OOUI icons are user interface icons, which the nutshell icon is not, so that's irrelevant. The actually comparable icons are for things that identify types of content, e.g. featured articles, redirects, disambiguation pages, etc, at least most of which have remained unchanged for decades. So you haven't actually answered the question I asked. Thryduulf (talk) 00:08, 26 February 2025 (UTC)
I completely agree with you, but I mentioned OOUI icons to explain that continuous improvements are made to icons and appearances here. Regarding the examples you mentioned, if nobody has raised these points for discussion, it doesn't mean they should be used as valid arguments. These finer details often catch the eye of designers or those with a similar background. Personally, I don't see a strong reason to stick with an outdated designed icon. Riad Salih (talk) 00:24, 26 February 2025 (UTC)
As someone advocating for a change (any change) the onus is on you to explain why the change would be beneficial. You thinking the current icon is "outdated" is the only reason you've even attempted to give, but that's completely irrelevant because we don't do change for the sake of change. We are an encyclopaedia not a graphic design studio, it doesn't matter if we're using "outdated" design language unless changing that design language will bring some benefit for readers and/or editors. Thryduulf (talk) 06:14, 26 February 2025 (UTC)
We don't have to align with the OOUI icons. Just becuase the trend is to more and more minimalism until we lose all aesthetic grace whatsoever and all logos are coloured circles doesn't mean we have to follow it. Cremastra (talk) 22:20, 3 March 2025 (UTC)
This definitely isn't significant enough to warrant a post at the Pump. And it'll be more likely to go somewhere if there is a specific proposal for a new icon on the table. Sdkb talk 19:23, 25 February 2025 (UTC)
The conversation has already started on the template's talk page. I shared it here to gather a variety of opinions. Riad Salih (talk) 00:18, 26 February 2025 (UTC)
@Riad Salih, for next time, see WP:TALKCENT. We like to centralize discussions in a single place. You can place {{Please see}} notices elsewhere to draw attention to them, but starting the same discussion in multiple places tends to fragment it and create confusion. Sdkb talk 15:59, 26 February 2025 (UTC)
@Sdkb sure, thanks. Riad Salih (talk) 16:00, 26 February 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.

Forums?

I think people can talk on a discussion forum whilst contributing to make a free and open-source encyclopedia... We should have two boards, one is related to Wikipedia, and the other one is any topic alike. We may have to change What Wikipedia Is Not, but I find this as a great idea. A editor from mars (talk) 08:08, 4 March 2025 (UTC)

Changing WP:NOT to allow forums doesn't really have a chance of succeeding, but there are discussions forums around, such as the Wikipedia subreddit, WP:IRC, and WP:Discord, which you may be interested in. CMD (talk) 09:02, 4 March 2025 (UTC)
And, if you like that sort of thing, Wikipediocracy etc. Gråbergs Gråa Sång (talk) 06:31, 5 March 2025 (UTC)
The internet has plenty of any-topic forums, reddit, Quora, Twitter, etc. Gråbergs Gråa Sång (talk) 09:17, 4 March 2025 (UTC)
I know. A editor from mars (talk) 09:18, 4 March 2025 (UTC)
Why not just use the relevant talk pages, either for articles or for broader topics? If you're looking for general Wikipedia chat, that exists in the usual places like reddit, facebook, etc. If you think we should have some kind of place that's a general "open for any kind of suggestion or proposal" talk page, well, this is it right here. If you're thinking of a more purely social space, hmmm...--Jimbo Wales (talk) 15:04, 7 March 2025 (UTC)
To your first sentence: because article talk pages fall under WP:NOTFORUM, which is to say that they are intended for discussions that are focused on improving the associated article, not for general discussions on the article's topic. This is a helpful principle to short-circuit a ton of drive-by whinging about a topic that the hypothetical OP doesn't like or agree with, but doesn't care to actually interface with the article about, or attempts to contact the article's subject, or any number of other topics that already clutter up talk pages. Writ Keeper ⚇♔ 15:15, 7 March 2025 (UTC)

Proposal to not refer to the children of Donald Trump as simply "Trump" on their articles

Originally posted on Talk:Donald Trump, but I was advised to post it here instead.

Before I start, yes, I am aware that what I am proposing violates Wikipedia's manual of style, however I believe that in this case, an exception is justified.

While I was scanning the article of Tiffany Trump, I encountered the following sentence: "In 2015, Trump worked as an intern for Vogue magazine and, in 2016, modelled for an Andrew Warren fashion show during New York Fashion Week". For a brief moment, I was pretty confused by this, until I realized that "Trump" in this context was referring to Tiffany, and not Donald Trump. I realised that the article on multiple occasions referred to Tiffany as "Trump", as would be typical on any other article per WP:SURNAME. However, this leads to other bizarre statements such as "In summer 2018, while on vacation in Greece with the actress Lindsay Lohan, Trump met Michael Boulos, a Lebanese-American business executive. The pair began a relationship and were married on November 12, 2022, at Mar-a-Lago in Palm Beach, Florida. In October 2024, it was announced that they were expecting their first child together."

While this convention works perfectly fine on most articles, I believe it is problematic on articles pertaining to the children of Donald Trump, as at this point the name "Trump" has become so heavily associated with the president himself that most people will instinctively think of D.J.T. whenever they see simply "Trump" written without a first name, which could lead to confusion, as well as Wikipedia passages potentially being taken out of context (as I have done here). For this reason, I believe it would be best if Wikipedia articles did not refer to Trump's children, or indeed anyone carrying the Trump surname, as simply "Trump", with the exception of D.J.T. himself. While I appreciate that Wikipedia's manual of style is robust, and has been painstakingly developed over the span of many years, all guidelines have exceptions, and I believe that this should be one of them.

As for how it should be handled, I think the best way would be to simply use their first names instead (and append Jr. in the case of Donald Trump Jr.), however I am not explicitly proposing that this is the way it should be handled. My proposal here is simply to stop referring to them as "Trump" alone, and for another convention to be agreed upon. Alex the weeb (talk) 13:44, 1 March 2025 (UTC)

I disagree that Donald Trump is such an exception as to warrant dropping our guidelines. Surely you didn't think that he had worked for Vogue or married someone called Michael? If I am reading about snooker and see the name "Trump" I think of Judd, not Donald. There is life beyond contemorary American politics. Phil Bridger (talk) 14:13, 1 March 2025 (UTC)
  • Given that any article on Trump’s children will likely mention their father, and that in the context of articles relating to that family confusion can arise as to which member of the family is being referred to as “Trump”… I agree that we should specify more clearly. This obviously isn’t needed in an article on the snooker player. Blueboar (talk) 14:50, 1 March 2025 (UTC)
  • After writing several articles about United States first ladies, including Melania Trump, I've found that it's simply not practical to have a clear understandable article using a surname in these cases. If every part of the article goes back and forth mentioning different people with the surname Trump, then it should refer to them by their first names for readability purposes. I recently promoted Edith Roosevelt to featured article with her and her immediate family members referred to by first name, and I believe the article benefits from it. Thebiguglyalien (talk) 🛸 16:48, 1 March 2025 (UTC)
    I'm not sure we need a policy on this. Perhaps it should be settled on an article by article basis in normal editing discussion. Wehwalt (talk) 16:50, 1 March 2025 (UTC)
    Note this usage is covered by Wikipedia:Manual of Style/Biography § People with the same surname. isaacl (talk) 16:53, 1 March 2025 (UTC)
    I see this problem when only one member of the family is famous (or infamous) and the others are only known because of their relative. It's even more awkward in the childhood section where most the people the subject interacts with have the same surname. The max is when a Briton becomes so famous that he's ennobled and from then on everybody calls him by his titular town or other namesake and this is also used in describing childhood activities. General Sir Arthur Wellesley is an example. I would prefer a bit more looseness in such matters, making him "Arthur" as a child, "Wellesley" as a soldier, and "Wellington" in politics. Jim.henderson (talk) 17:13, 1 March 2025 (UTC)
    The scenario of the commonly used name changing is covered by Wikipedia:Manual of Style/Biography § Subsequent use, which I believe the article follows (I appreciate it doesn't match your personal preference). isaacl (talk) 17:27, 1 March 2025 (UTC)
    Thing is… as is stated at the top of the guideline page… “occasional exceptions may exist”. The question is: should this be one of those occasional exceptions? Blueboar (talk) 18:20, 1 March 2025 (UTC)
    I think Wikipedia's guidance (and how the article mostly handles it) seems reasonable: use Wellesley until the event where he gained his title, then use Wellington. I don't see a reason to treat his childhood differently than the childhoods of other people. isaacl (talk) 18:32, 1 March 2025 (UTC)
  • Of course if an article refers to several people with the same surname we should disambiguate somehow, and first name is an obvious thing to use. My main problems with the OP are with the phrase "or indeed anyone carrying the Trump surname" and the implication that Donald Trump is unique in this regard. Phil Bridger (talk) 18:22, 1 March 2025 (UTC)
    Trump and Wellington are only two examples of what could be made a more general guideline. I am often confused by unmarried women who only did anything notable after taking her new husband's name, and her biography backdates the name to her girlhood or premarital collaborations. Better to follow the usage of whatever time is being handled in each section, with a notice of each change both in the intro and at the time at happened. Or by a British Ambassador or whatever, who became Baron whatever, and continued doing important things. Jim.henderson (talk) 18:44, 3 March 2025 (UTC)
My knee-jerk reaction is that there's no reason to treat the Trump-children different in this regard than say John Shakespeare and Tom Shakespeare. Gråbergs Gråa Sång (talk) 19:46, 3 March 2025 (UTC)
  • This does not have the makings of any kind of "rule", it happens all the time in sections describing families that you write differentiation into the text but let writers be free how they want do so. In general, it remains, if the last mention is Sam Trump than Trump is going to refer to Sam. Also, this is nothing new, even in the United States: Adams, Astor, Rockefeller, Roosevelt, Bush, etc, etc, Alanscottwalker (talk) 20:12, 3 March 2025 (UTC)
  • I don't really see why this is a thing. Surely this is true for any famous person, and people who share their surname. Should we also not refer to Judd Trump as Trump? Lee Vilenski (talk • contribs) 20:34, 3 March 2025 (UTC)
  • This shouldn't need a special rule. Everything should be written in a way that is quick to understand and hard to misinterpret. That's just common sense, and outweighs even the manual of style. Where a reader is likely to be confused (to think of Donald when we meant Judd), allow editors the discretion to use whatever name best minimises the risk of misreading. Same goes for other famous names. Elemimele (talk) 15:33, 4 March 2025 (UTC)
  • I recently had this problem with Gittings family, there are three John Sterett Gittings - the third is a "Jr." because his father had the same name, but the second took his name from the grandfather so is not "Jr." The only way to disambiguate the first and second is (birth-death). I'm all for first name though, particularly in "early life" sections when referring to the mother and fathers life. Convention for primary topic is last name throughout, any ancillary family can use first name, or some other method. -- GreenC 17:47, 4 March 2025 (UTC)
    You might find a phrase like "the elder Gittings" to be useful on occasion, and for childhood, there's sometimes a family nickname that can be presented (e.g., the man who is called "Junior" his whole life, so you might write about "his grandfather, who was called Junior..."). WhatamIdoing (talk) 04:04, 5 March 2025 (UTC)
    In the convention I am familiar with, the three John Sterett Gittingses would be JSG, JSG II , and JSG III. Junior would only be used for a son named after a father who was not named for any ancestor. --User:Khajidha (talk) (contributions) 09:16, 8 March 2025 (UTC)
  • I think this can only be handled on a by-article basis, and it is up to the editors of each article to deal with any possible ambiguities. If there is a paragraph which mentions each of Donald, Donald junior, and Tiffany, the way to handle it is just like that—first names only. In this sort of situation, I think existing guidelines hold good, and it really doesn't matter who Donald Trump is when it comes to preventing ambiguity. The readers come first. Spartathenian (talk) 10:32, 13 March 2025 (UTC)

School Block

When schools are blocked indefinitely after kids going ahead and vandalizing multiple times cause its fun or cool, the IP often almost always gets blocked, with account creation blocked. Obviously kids who do want to edit Wikipedia will create an account and kids who vandalize because its just cool generally don't go through the hassle of that. This is why I propose that when Administrators block school IP addresses, they allow people to still create accounts. Of course if vandalism goes on even after a block is imposed through creating accounts, then an administrator can step in and block account creation access. I predict that this argument will spring up, so I will answer it: "Why not just create the account at home and login with it at school?". Well its simple, people might have accounts but they might not want to associate it with the school for safety and technical reasons. Heres an example: If a person is LGBTQ+ and they live in an extremely religious neighborhood which is hostile to the idea of LGBTQ+ and on Wikipedia they have edited heavily on LGBTQ+ topics or they may even identify as LGBTQ+ on their userpage, if they log in to Wikipedia and are caught they can face severe consequences by the community and their parents. Another example is accidentally leaving it logged in while at school, at home this would be fine as your likely using a personal computer, at school however someone can just walk in, see that your logged in to Wikipedia and start to vandalize. This is why having 2 separate accounts, one for school and one for personal reasons can avoid the examples above. DotesConks (talk) 05:23, 12 March 2025 (UTC)

In that case, I would suggest them to go through Wikipedia:Request an account, which explicitly points to school blocks as one of its relevant use cases. Chaotic Enby (talk · contribs) 09:43, 12 March 2025 (UTC)
Do you know which schools are blocked indefinitely? Both Wikipedia:Blocking policy#IP address blocks and Wikipedia:Blocking IP addresses#Block lengths indicate that IPs shouldn't be blocked indefinitely. CambridgeBayWeather (solidly non-human), Uqaqtuq (talk), Huliva 03:21, 13 March 2025 (UTC)
Note: We need an example of an IP address that was blocked indefinitely, not the name of a school. WhatamIdoing (talk) 17:10, 13 March 2025 (UTC)
That's what I meant. CambridgeBayWeather (solidly non-human), Uqaqtuq (talk), Huliva 22:27, 13 March 2025 (UTC)
Rather than "Why not just create the account at home and login with it at school?" the question is "Why not create two accounts at home, and use one at home and the other at school?" That avoids all the issues you mentioned, you don't have to create them in different places. -- LCU ActivelyDisinterested «@» °∆t° 18:40, 13 March 2025 (UTC)
Hopefully identified as alternate accounts. Donald Albury 20:56, 13 March 2025 (UTC)
You would definitely want to read WP:LEGITSOCK and WP:ALTACCN before creating an alternative account. -- LCU ActivelyDisinterested «@» °∆t° 21:16, 13 March 2025 (UTC)

Conversion of all-numeric date formats

This is clearly not happening. * Pppery * it has begun... 23:53, 13 March 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.

Hi, all. First, I hope I've come to the right place. This proposal concerns WP:CITESTYLE and WP:DATEVAR, which I understand to be guidelines rather than actual policies. Please point me in the right direction if I've gone astray.

A very useful maintenance aid I've adopted is the 'MOSNUM dates' script written by User:Ohconfucius. Using this has made me aware of inconsistent date formats across a wide range of articles. WP:CITESTYLE rightly says citations within any given article should follow a consistent style. It goes on to deprecate all-numeric date formats with the exception of YYYY-MM-DD. As CITESTYLE says, an all-numeric date can be ambiguous as to which number is the month and which is the day.

I agree with YYYY-MM-DD up to a point, in that it does remove ambiguity for the editor. But, it does not remove it for the reader.

Even if 9 January 2024 (dmy format) appears in United States—or if January 9, 2024 (mdy format) appears in England—a reader of any nationality knows it means the ninth day of January. But, 2024-01-09 remains ambiguous, even if the reader is aware of CITESTYLE and believes YYYY-MM-DD is the only format we use for all-numeric dates. Bear in mind that very few readers will be aware of that and, probably, only a minority of editors too. Also, the reader has no certainty that a numeric value has been input correctly, because the editor might have got their numbers mixed and inadvertently written 2024-01-09 instead of 2024-09-01.

If the name of the month is written, whether as 9 January or January 9, the ambiguity is gone. Then, it's only a question of whether the topic is, for the most part, British or American.

Having said all of that, I do realise there must be some editors who find it easier to type a single numeric format than to choose and write one of dmy or mdy. I am not saying they should cease doing that, because it may create difficulties for them.

Proposal. When an article is reviewed, and to avoid ambiguity, dates should be converted to one of the dmy or mdy formats only, subject to the variety of English in which the article is written. All-numeric dates should be amended, but use of the YYYY-MM-DD format is not prohibited as a means of date input.

To achieve this, we would amend the second paragraph of CITESTYLE to confirm that YYYY-MM-DD remains an acceptable informat, but that it is subject to conversion when the article is reviewed, so that the outformat becomes either dmy or mdy. Furthermore, to ensure a smooth process, we would amend WP:DATEVAR so that it endorses reformatting of all-numeric dates to one of the dmy or mdy formats. Spartathenian (talk) 14:16, 12 March 2025 (UTC)

  • Oppose as WP:CREEP. I do sometimes change YYY-MM-DD to dmy or mdy depending on the established style of the article, but I just do not see the necessity of mandating the change. - Donald Albury 14:47, 12 March 2025 (UTC)
  • Oppose except if automatic conversion can be done by a bot. Many tools such as WP:ProveIt automatically generate YYYY-MM-DD dates, and it would be an added burden for new page reviewers to have to change them each time, especially given the already increasing backlog of articles to review. Noting that "converting dates to a consistent format" is not even, currently, a requirement for marking an article as reviewed. (edit 12:48, 13 March 2025 (UTC): striking the bot idea per Jc3s5h) Chaotic Enby (talk · contribs) 15:15, 12 March 2025 (UTC)
    I agree it would be ideal if a bot could do the job. Thanks. Spartathenian (talk) 15:48, 12 March 2025 (UTC)
    Striking this as a bot would be indiscriminate, and I now accept that some types of article do require the YYYY-MM-DD format. Spartathenian (talk) 12:43, 13 March 2025 (UTC)
  • Oppose. YYYY-MM-DD AKA ISO 8601 is not ambiguous ("The standard provides a well-defined, unambiguous method of representing calendar dates and times in worldwide communications"), and indeed is the only correct format in some contexts. Date formats should be consistent in the prose (except where date formats are the subject of discussion, direct quotes, etc) and consistency of citation date formatting is a nice to have, but YYYY-MM-DD needs to remain one of the allowed formats. Thryduulf (talk) 16:23, 12 March 2025 (UTC)
    The Wikipedia article "ISO 8601", like all other Wikipedia articles, is not a reliable source. It would be rare indeed that ISO 8601 would be the only correct format in a Wikipedia article, if it's visible to the reader. Jc3s5h (talk) 12:18, 13 March 2025 (UTC)
  • Comment. These are fair points, but I get the impression you think I'm advocating compulsory conversion. I'm suggesting "should", not "must", so conversion is at the reviewer's discretion. If that is the de facto case already, I think we need to tighten the guidelines to make clear that the reviewer does have that discretion, as when using the 'MOSNUM dates' script. Thanks for taking part, all. Spartathenian (talk) 09:33, 13 March 2025 (UTC)
  • Oppose, YYYY-MM-DD is not only an ISO standard, it is commonly used in some countries, albeit likely due to word order in a non-English language. It is not really ambiguous, when is YYYY-DD-MM used? It may be unfamiliar to some readers, but I don't agree unfamiliarity necessitates depreciation. CMD (talk) 10:25, 13 March 2025 (UTC)
  • Does anyone anywhere use YYYY-DD-MM? Otherwise I can't really see a reasonable possibility for confusion with YYYY-MM-DD. – Joe (talk) 11:52, 13 March 2025 (UTC)
    Hi, Joe, it's more a case of what readers know about formats. Someone might see 2024-03-12 and it may not be obvious to them that it means March last year, so they wonder if the event or action was in December. My concern is removing possible ambiguity, but I'm happy to accept YYYY-MM-DD where it is necessary as a standard format, as seems to be the case in some types of article. Perhaps we should be focusing on articles where it is not a necessary format? Thanks for your reply which is a good point. Spartathenian (talk) 12:06, 13 March 2025 (UTC)
    Answer: No. Nobody ever uses YYYY-DD-MM. It's not 'a thing' anywhere. The middle endian format for calendar dates never begins with the year. WhatamIdoing (talk) 17:15, 13 March 2025 (UTC)
  • Strongly oppose conversion with a bot. I also use the script written by Ohconfucius, and it has fewer errors than any date-related bot or template I've seen, but it still requires manual supervision to spot errors it makes. Jc3s5h (talk) 12:22, 13 March 2025 (UTC)
    Hi, Jc3s5h. I agree, now, that we can't have a bot doing it, and I've struck my earlier comment. Due diligence is still necessary when using any kind of utility. Spartathenian (talk) 12:48, 13 March 2025 (UTC)
  • Oppose in general, and very strongly oppose tying this to the WP:NPP page review process. NPP's main job is to get rid of copyvios, hoaxes, and other WP:CSD candidates. Fiddling around with date formatting is not their job. WhatamIdoing (talk) 17:19, 13 March 2025 (UTC)
    I haven't mentioned NPP, and I'm not seeking to tie this idea to any specific process. As I have said above, the target guidelines are CITESTYLE and DATEVAR, nothing else, because the sort of reviews I'm mainly interested in are routine article improvement and maintenance, where the 'MOSNUM dates' script is likely to be used. Spartathenian (talk) 19:22, 13 March 2025 (UTC)
  • Oppose. Where in the world is YYYY-DD-MM ever used? The potential for confusion seems vanishingly small. older ≠ wiser 17:21, 13 March 2025 (UTC)
    The proposal is not about YYYY-DD-MM, if that even exists. It is about the ambiguity of YYYY-MM-DD in comparison with the dmy and mdy formats in which the month is alphabetic, not numeric. Spartathenian (talk) 21:27, 13 March 2025 (UTC)
  • Comment There seems to be some misunderstanding above. The YYYY-MM-DD format is not the only date format permitted by ISO 8601 - it is just one of several. I have written on this matter several times in the past, going right back to October 2009 - see for example: --Redrose64 🌹 (talk) 22:28, 13 March 2025 (UTC)
  • Oppose as this is a standard way to write dates, and is not ambiguous at all. It would be good in template values, where it can be converted automatically to more readable localised dates. Graeme Bartlett (talk) 23:30, 13 March 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.

Discussion at Wikipedia talk:User pages § RfC: allowing editors to opt-out of seeing floating decorative elements

 You are invited to join the discussion at Wikipedia talk:User pages § RfC: allowing editors to opt-out of seeing floating decorative elements. HouseBlaster (talk • he/they) 23:03, 16 March 2025 (UTC)

RFC: Officeholder infoboxes

Should we delete order numberings from infoboxes of office holders?
See previous related discussions:

GoodDay (talk) 18:58, 9 February 2025 (UTC)

Survey (Officeholder infoboxes)

  • Yes - We have the numberings in the pros & that's enough. GoodDay (talk) 18:58, 9 February 2025 (UTC)
  • Mostly yes, as the numberings in most offices are done by WP editors counting and adding that information, and rarely is a numbering system used by reliable sources. But where the numbering is frequently used by reliable sources (such as in reference to the US presidency), it does not make sense to hide that. So numbering should only be used when it is clear that it is a common mention within the reliable sources. --Masem (t) 19:04, 9 February 2025 (UTC)
    We should indeed not hide the numbers from the US presidents. We should present them when we are writing about the presidents themselves, such as in the lead sentences; but the infobox and the succession box parameters present the office. See the messy "45th & 4th president of the United States" heading with different data underneath at the Donald Trump page. In any case, leaving the numbers in the US infoboxes guarantees that they will creep back into all the other infoboxes, because monkey see, monkey do. Surtsicna (talk) 20:16, 9 February 2025 (UTC)
  • Sometimes, only delete them if there is no (consistent) numbering used by reliable sources. I don't think we need to have a majority of reliable sources using the numbering (after all, no source is complete and information isn't excluded just because it isn't present in most sources). However, we still want sources to use a numbering, and that numbering to be consistent, to avoid OR. Chaotic Enby (talk · contribs) 19:44, 9 February 2025 (UTC)
    Sometimes for reasons laid out by Chaotic Enby ꧁Zanahary꧂ 20:08, 12 February 2025 (UTC)
  • Yes, because the way they are presented in the infobox does not make sense. The numbers are not part of the office. The number 46, for example, refers to Joe Biden specifically, not to the office he held. Name him 46th in the lead sentence, but not in the infobox or in the succession box, because in those templates we are talking about the office, not Biden personally. And of course, these numbers inevitably creep into topics where they are not used at all. Surtsicna (talk) 20:09, 9 February 2025 (UTC)
  • Yes, but they should be elsewhere, the current spot makes no sense. Maybe a specific Number field? I don't have any good ideas, but agree they don't belong where they are currently. --JackFromWisconsin (talk | contribs) 23:03, 10 February 2025 (UTC)
  • No, though it certainly isn't mandatory to use them. Officeholding is often sequential. Sometimes, the ordinal is part of the title itself, as in certain titles of nobility. Sometimes, that fact is also verifiable (per ChaoticEnby's argument) and sometimes it isn't. Sometimes it's irrelevant, as in the overlapping terms of US Senators. If, for a given office, order is relevant and verifiable, there is no better place to put in than in the infobox, since it provides readers with a clear navigational feature, along with preceded by and succeeded by. Of course editors on the given topic can make the decision as to whether it's relevant, meaningful, and verifiable, but taking it out of the template removes valuable information in all case.
The concerns raised by Surtsicna and JackFromWisconsin—"George W. Bush was not preceded by Bill Clinton in the role of '43rd President of the United States'"—refer to a visual interpretation that had never occurred to me before I read it. I would suggest that most people read the linked text different and understand that the ordinal isn't part of the title.--Carwil (talk) 00:34, 11 February 2025 (UTC)
If the ordinals are not part of the office, we should not present them as if they were. Surtsicna (talk) 00:46, 11 February 2025 (UTC)

Discussion (Officeholder infoboxes)

I realize that their may be resistance to 'deletion', concerning American, Australian, Canadian & New Zealand officeholders. But, perhaps we can eliminate the numberings from most (if not all) officeholders' infoboxes. GoodDay (talk) 18:58, 9 February 2025 (UTC)

I believe that numbering can be important, and I believe this extends further than american, australian, canadian and NZ officeholders to most of the world. Thehistorianisaac (talk) 06:56, 20 March 2025 (UTC)

Set mentor status to away for other users

Sadly, sometimes Wikipedians take a break, or leave and never come back. If they were signed up as mentors, they keep getting assigned new mentees. Is there a way to set mentor status to "away" for another user? If not, this is urgently needed. I discovered this issue while looking at User talk:Bsoyka, who is currently MIA. Toadspike [Talk] 10:03, 20 March 2025 (UTC)

Well, I just discovered that admins can edit Special:ManageMentors. Not sure if they can only remove mentors, or also change their mentor status. Anyone mind setting Bsoyka to "away" or removing him from the list? We might also want to check for other inactive users, or automatically set mentors who haven't edited for two weeks to "away". It is pretty bad that we're directing new editors to mentors who are not active. Toadspike [Talk] 10:06, 20 March 2025 (UTC)
Okay, admins can edit MediaWiki:GrowthMentors.json, not Special:ManageMentors, and I think setting "weight" to 0 is the same thing as setting status to away. Toadspike [Talk] 10:08, 20 March 2025 (UTC)
One can actually edit directly, by clicking on the "edit" button in the corresponding line....I tried some things (just setting on "away", but then you need to set a date, and you have to edit the welcome text). Lectonar (talk) 10:11, 20 March 2025 (UTC)
Update: I have set on "away" until November 20th. Courtesy @Bsoyka:. Lectonar (talk) 10:13, 20 March 2025 (UTC)
Thanks. I cannot see the history of that page, but it looks like it's worked. I feel like marking inactive mentors as "away" would be a good bot task. Toadspike [Talk] 12:11, 20 March 2025 (UTC)
MediaWiki:GrowthMentors.json is some of the data underlying Special:ManageMentors. The latter is a sortable list, and admins also get two buttons on each row - Edit and Remove. The Edit feature produces a small form, that includes four or five items:
  • "Introduction message" - single-line text box, this sets the "Message for newcomers" column
  • "Number of newcomers assigned" - four-option radio, offering: None (I claim them manually); About half the average; Average (the default); About twice the average
  • "Is away? - checkbox: if unchecked, sets the "Status" column to "Active"; if checked, offers a further entry item
    • "Away until" - date & time entry (with popup calendar): sets the "Status" column to "Away until" plus this date
  • "Reason" - single-line text box
I guess changes are logged, but I don't know where. --Redrose64 🌹 (talk) 19:27, 20 March 2025 (UTC)
Changed to only the "away" status are not logged anywhere (T345272). Other changes are logged in the history of MediaWiki:GrowthMentors.json. And I've been manually marking mentors who have been MIA for ~2 months as away for a while (apparently since July 2024, although I no longer remember what made me start doing it) - Bsoyka was missed by that since he's only been gone for one month. * Pppery * it has begun... 20:58, 20 March 2025 (UTC)

Encouraging use of alt text in lead images

Note: prior topic name was "Mandatory use of alt text in lead images"

As someone who is active on the Fediverse, cases of persons with impaired visibility are rising, this is why I encourage everyone to read WP:ALTTEXT before adding alt text to lead images. This suggestion might be useful because without the alt text on lead images (long pressing or hovering to the lead image), how can they describe them? Ahri Boy (talk) 06:34, 14 March 2025 (UTC)

Hi, this topic was removed without comment, so I've restored it. Spartathenian (talk) 06:53, 14 March 2025 (UTC)
It certainly is a useful suggestion, but it should not be mandatory. We should do everything we can to assist editors and readers with disabilities. ALTTEXT is a big step forward. Spartathenian (talk) 07:06, 14 March 2025 (UTC)
To take an example: The Adventures of Tintin; what purpose does the alt text there serve? How does it help visually impaired readers, and how does it help them any better than the caption? Fram (talk) 09:25, 14 March 2025 (UTC)
For example, the lead image of Raiden Shogun has a different alt text, straight to the point. Ahri Boy (talk) 09:29, 14 March 2025 (UTC)
I do support encouraging the use of alt text as much as possible, and having more editors familiarize themselves with WP:ALTTEXT. However, regarding making it mandatory, I'm afraid that it might be counterproductive, as not all editors know from the get-go what makes a good alt text, and might add something unhelpful instead (as I've also seen happen with short descriptions). To take Fram's example, the alt text on that picture is Tintin is standing in front of all of his friends. While technically accurate, it doesn't really match the image's function (to introduce the cast of the Tintin series), and the caption is in fact more helpful for that purpose. In that case, |alt=refer to caption could be more optimal. Chaotic Enby (talk · contribs) 09:52, 14 March 2025 (UTC)
Are you running in to situations where you have added alt text and other editors are arguing with you that there should be no alt text? What do you suggest is done for violations of this "mandatory" requirement? — xaosflux Talk 11:00, 14 March 2025 (UTC)
I would worry that too strong language would discourage people from going out and finding images, which can be quite a task.--Wehwalt (talk) 13:34, 14 March 2025 (UTC)
Making something like this mandatory isn't going to work, but as an accessibility issue it should be strongly encouraged. -- LCU ActivelyDisinterested «@» °∆t° 13:58, 14 March 2025 (UTC)
One way to encourage this would be to add something like "media has suitable alt text" to the Wikipedia:Good article criteria and Wikipedia:Featured article criteria. This wont fix the issues alone, no single thing can, but I think it will help. It would require separate discussions to implement but I don't imagine it being particularly controversial. Thryduulf (talk) 14:07, 14 March 2025 (UTC)
It's been discussed, I believe, from time to time for the Featured Article criteria but not added. The proper forum for that would be WT:FAC. Wehwalt (talk) 14:12, 14 March 2025 (UTC)
Here is an RFC from 2019 on alt text in FAs. There have been a number of other discussions. Alt text is encouraged but not required.Wehwalt (talk) 15:32, 14 March 2025 (UTC)
Personally I expect alt text on FAs and require it if I am checking them out for FA. FAs are supposed to be the best work on Wikipedia, and so should not have any identifiable deficiencies. Graeme Bartlett (talk) 20:33, 14 March 2025 (UTC)
I also expect it on FAs. WP:FACR states that "[The article] follows the style guidelines", and those style guidelines state "An image's |alt= text takes the image's place for those who are unable to see the image. See Wikipedia:Manual of Style/Accessibility/Alternative text for images". CMD (talk) 14:26, 17 March 2025 (UTC)
If someone were to open another RfC on requiring alt text at FA, I would definitely support it. Honestly I'm rather surprised by the arguments that were made against it in that 2019 RfC. --Grnrchst (talk) 11:43, 17 March 2025 (UTC)
I believe the Design team has been looking at making this a structured/suggested task for more experienced users (suggested tasks are things that are evaluated while you edit the page and then make suggestions to editors) —TheDJ (talk • contribs) 12:39, 17 March 2025 (UTC)
We've actually fiddled around with it as an edit check as well, which is more of a helpful hint for newbies in terms of targeting.
Check out this userscript that I made and which is running on this patchdemo: add an image to that page, don't give it a caption, and try to publish changes -- it should show you an edit check asking whether you really want to publish something without a caption.
I made a version specifically for alt text as well -- if you look at the script you can probably see that it'd just be a minor change -- but captions are already used as an alt text fallback when there's no explicit alt provided, and the manual-of-style says that there should always be a caption and sometimes be an alt if the caption isn't sufficient. So in terms of nudges-for-new-editors, getting them to definitely add a caption seems easier to explain than walking them through "does this image also need alt text?"... DLynch (WMF) (talk) 01:28, 21 March 2025 (UTC)
Yeah, this is a good idea. We already have {{Alt text missing}} for categorizing and tracking but it doesn't render anything on the page, so it's only useful if you go looking in the category for pages that are tagged. I just threw together {{No alt text}} for a cleanup banner, but haven't made the companion category or documentation, if anyone wants to run with it. Or maybe merge it with the first one since the structure is already there. Ivanvector (Talk/Edits) 13:02, 17 March 2025 (UTC)

Hotcat for stub-sorting?

I don't know whether this is the right village pump but anyway: Hotcat is a pretty useful gadget that makes categorizing articles a lot intuitive and easier by recommending potential categories. And stub-sorting is a pretty important task too in categorizing different stubs on different subjects. So it seems weird to me that a Hotcat analogue designed to stub-sort isn't a thing. The basic principle is the same for both in that you categorize articles. Ofr how it could work, it's basically like Hotcat: Whenever this "StubCat" detects that you're on a stub page, it automatically at the end of the page but before the category list gives an option to easily add stub templates and suggest them. Seems like a pretty useful gadget to me, though I might be wrong since I'm by no means an experienced user yet. Yelps :) talk 11:51, 20 March 2025 (UTC)

What you are asking for is a gadget, they start out as user scripts. There doesn't seem to be a venue dedicated to requesting them, with Wikipedia talk:User scripts and Wikipedia:Village pump (technical) suggested in different places. Thryduulf (talk) 13:03, 20 March 2025 (UTC)
We have User:Danski454/stubsearch, which is pretty close to that! (the only difference with what you suggest being that it is at the top and not at the bottom) Chaotic Enby (talk · contribs) 13:48, 20 March 2025 (UTC)
Requests for user scripts can be made at WP:User scripts/Requests BugGhost 🦗👻 15:27, 20 March 2025 (UTC)
We also have User:SD0001/StubSorter — GhostInTheMachine talk to me 23:04, 21 March 2025 (UTC)

Should other groups be able to use 2FA by default?

Should other groups be able to use 2FA by default? ~/Bunnypranav:<ping> 16:13, 11 February 2025 (UTC)

Background

In Wikipedia:Village pump (proposals)/Archive 216#Allowing page movers to enable two-factor authentication, many people advocated for other advanced and even that all used should be able to use 2FA by default. This RfC clearly asks which groups should get 2fa. This is asking for them to have the permission/ability to turn 2FA on, i.e. have the oathauth-enable right, not require these group holders to use 2fA. This will allow these users to enable 2FA themselves and not have to ask stewards at meta. Feel free to choose one or more options:

~/Bunnypranav:<ping> 16:14, 11 February 2025 (UTC)

Survey (2FA for more groups)

  • Support option 2, since that adds a basic barrier of I know what I'm doing. As said by me in the previous discussion, 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> 16:13, 11 February 2025 (UTC)
  • Oppose 1 and 2 - what this really would do is allow people to enroll in 2FA without asserting that they know what they're doing, which seems bad. Weak oppose 6, since rollback doesn't really grant you the ability to do anything you couldn't already, so it shouldn't be a distinguisher here. Weak support the others, I guess. * Pppery * it has begun... 16:45, 11 February 2025 (UTC)
  • Support 2 and weak support 1. We don't need to put a barrier to make sure people know what they're doing if they choose to set up 2FA. If they activate it, we can presume that they have an idea of how it works, and any consequence for their mistakes only affects them. Only weak support for 1 as the presumption of "they have an idea of what they're doing" is a bit lower for very new editors who might not be as familiar with the interface, but we can still presume that a new user finding the 2FA setting didn't do it fully by accident. Chaotic Enby (talk · contribs) 16:54, 11 February 2025 (UTC)
  • I was the person who made the original page mover 2FA proposal. I think that out of these groups, only file movers have a significant need for 2FA access, since that right allows for the ability to make rapid changes that could affect tens of thousands of pages (similar to template editors). However, I'm not opposed to allowing all autoconfirmed users to enable 2FA, as long as they must turn on a preference where they accept the risks of using it. This is similar to how the IP Information tool works. JJPMaster (she/they) 17:02, 11 February 2025 (UTC)
    I would also be fine with encoding in PHP the current process with a preference checkbox, since that's all the stewards ask for as it stands. * Pppery * it has begun... 17:08, 11 February 2025 (UTC)
  • Oppose all until Special:Manage Two-factor authentication (MediaWiki:Oathauth-ui-general-help) is rewritten in non-technical language that clearly explains the benefits and risks of enabling 2FA and links to the detailed help at WP:2FA. Once that has been rewritten then I'll consider which if any of the above groups should have access by default. Thryduulf (talk) 17:49, 11 February 2025 (UTC)
    I written up a draft at User:Bunnypranav/Oathauth-ui-general-help, and also posted an edit request at MediaWiki talk:Oathauth-ui-general-help. I am open to anyone editing my sandbox to create a more detailed and descriptive message. ~/Bunnypranav:<ping> 12:34, 12 February 2025 (UTC)
    Thryduulf, gentle reminder if you would be willing to reconsider your decision, now that the message has been updated. Thanks! ~/Bunnypranav:<ping> 12:22, 27 February 2025 (UTC)
    Oppose all. Despite the improved message, I'm convinced by the arguments below that the whole system is still not robust enough for casual adoption. It's true that going to meta to make a request is a small, arguably tedious hurdle, but it forces turning on 2FA to be a considered, conscious action which serves to reduce the number of people who will get locked out of their account accidentally. Thryduulf (talk) 14:29, 27 February 2025 (UTC)
  • Oppose all. There is already insufficient support for those who currently must or may have the WMF 2FA. The software is not yet properly supported, the planned-for upgrades are not yet complete, the documentation for the software is incomplete and not intuitive, and the only people who can turn off 2FA in case of loss of device are the very very small number of people with shell access. None of the roles listed above have the ability to adversely affect any project any more than an average user, unlike those few roles that today are required to have 2FA. Risker (talk) 19:01, 11 February 2025 (UTC)
    This might sound a bit blunt, but why should WMF care so much about recovering account who lost 2FA. If a user with no email given loses their password, its their own fault, WMF need not take any responsibility it tediously recovering it. Then can try and help, but they are not liable. Also, as SD has said below, the most newbie and non-techie friendly version a 2FA app, at least on android, is Google Authenticator, which drastically minimizes risk of losing by automatically syncing to a google account. Other platforms also offer such easy to use solutions. ~/Bunnypranav:<ping> 12:20, 12 February 2025 (UTC)
    Because people mess this up all the time, then start using up volunteer and staff time complaining about it. — xaosflux Talk 15:41, 12 February 2025 (UTC)
    How many people will even take the time and effort to enable 2FA? One has to install an authenticator app (probably with cloud backup enabled by default), scan the code, and enter a verification code from the app before even turning it on. This is not something like I clicked a button and now I'm locked out account level easy to mess up; those people who manage to enable this, and lose access to it should be less than people without an email who lost the password and now did a clean start. We can advise these limited people to do the same as well (fresh start, with a CU verify if they need advanced perms early). ~/Bunnypranav:<ping> 07:29, 13 February 2025 (UTC)
    Trust me, a shockingly high number of people screw up 2FA. There are 2 solutions to this problem. Either a) we don't care. We put a big warning, and if you mess it up you are permanently locked out. Or b) we decide its acceptable to use a lower level of validation for unprivleged accounts. Something like we send an email and wait 7 days and unlock the account if nobody responds. This defeats some of the point of 2FA, as an attacker can now attack this weaker process, but perhaps is a reasonable compromise. It all comes down to what you want to protect against with 2FA. There is a certain sense that in practise the real thing 2FA protects against is people reusing passwords (credential surfing), because in essence its a fancy password that wikipedia chooses for you. Bawolff (talk) 12:51, 13 February 2025 (UTC)
    "The software is not yet properly supported, the planned-for upgrades are not yet complete" – as far as I know, and based on ACN's comment at the last discussion, 2FA is not being actively worked on. If we are waiting for upgrades, we will likely be waiting years.
    "None of the roles listed above have the ability to adversely affect any project any more than an average user" – Autopatrolled and NPP can bypass article review processes and are highly coveted by promotional scam rings like Orangemoody, which you should be very familiar with. In my opinion, these groups are, right behind governments, the largest and most organized threat to Wikipedians. Toadspike [Talk] 07:48, 18 February 2025 (UTC)
  • Oppose all per Risker above. If someone really really wants to test 2FA they can already opt-in after being warned about risks. — xaosflux Talk 19:09, 11 February 2025 (UTC)
  • Oppose I am an admin and I don't use 2FA. The reason for that is that the implementation is (as Risker says above in far more polite language that me) a pile of crap, and I don't think the devs want an ever-increasing list of people who have managed to lock themselves out. Black Kite (talk) 19:13, 11 February 2025 (UTC)
  • Support 3–6 Like I mention in the reply below to Risker, a lot of the opposition to 2FA arises out of ignorance of how 2FA works. People seem to assume that the "multitude of commercial and free 2FA software" are incompatible with Wikimedia sites when in fact, they aren't. You can very well use Google Authenticator, Authy, Ente Auth and other 2FA apps with WMF sites – all three of these apps support syncing of your tokens in the cloud, ensuring that even if you lose your device, you can still view tokens using another device. – SD0001 (talk) 12:15, 12 February 2025 (UTC)
    The real problem is the collision of two situations: (a) many end users are ignorant of how 2FA works technically, and have no idea how to properly manage their recovery codes or backup and restore anything; (b) unlike many other places you may set up 2FA, we don't have good other ways to authenticate someone to aid in helping them recover from their errors in (a), nor a support system to with cycles to do it if they could. — xaosflux Talk 23:29, 12 February 2025 (UTC)
  • Support all, but from what I understand of the conversation above is that it's not well-implemented. MFA/2FA is great for account security, which is why nearly every service does it. Google can enable it for every user, why shouldn't we? SWinxy (talk) 16:53, 13 February 2025 (UTC)
    Google can enable it for every user, why shouldn't we? The biggest difference between Google's 2FA and Wikimedia's 2FA is that Google has approaching infinitely better support for those that are locked out of their account due to 2FA than we do, both in terms of number of options and in terms of support bandwidth. Google has multiple options available to establish identity, and literal teams of customer support people who can implement and help. Wikimedia sometimes has an email address, very occasionally has personal knowledge and very little else in terms of options, and rather than dedicated customer support people only a circa single digit number of developers who can implement and help. The difference is comparable to that between a multi-lane highway and a barely used footpath through the woods - both will get you from A to B but that's about where the similarities end. Thryduulf (talk) 18:39, 13 February 2025 (UTC)
    Google also still gets criticism for permenantly locking people out of their accounts with no recourse. Bawolff (talk) 19:05, 13 February 2025 (UTC)
  • Option 2 and probably everything else. Serial (speculates here) 19:10, 13 February 2025 (UTC)
  • Support 3, 4, and 5 based on ACN's comment and ToBeFree's comment, especially "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", at the pagemover discussion. Autopatrolled and NPP are the most coveted userrights to scam rings and other malicious groups targeting Wikipedians. It is ridiculous that a user wishing to use 2FA has to bother a Steward to do so. 2FA is not going to get any better anytime soon, so we may as well encourage folks to start using it now and lower the barriers to doing so.
I am neutral on 1, 2, and 6. I don't think rollbackers need extra security, and while I agree in principle that most users should have access to 2FA I strongly disagree that extended confirmed = "I know what I'm doing". On the other hand, checking a box in your Preferences to activate 2FA does mean you should know what you're doing, and (assuming the explanatory pages are well-written) it's mostly your fault if you screw up. Toadspike [Talk] 07:37, 18 February 2025 (UTC)
  • Support 2 as optional choice for EC - i see args for technical limitations and user incompetence to be strange. It should not be hard to extend a preexisting system to other users, including those seeking additional protection. Honestly, if its buried as a preference for an account, most folks won't use it. User:Bluethricecreamman (Talk·Contribs) 04:46, 19 February 2025 (UTC)
  • If you really want 2FA you can just go to Meta and get the requisite user right freely - provided you've understood the risks involved. It would be better and easier to direct users interested in 2FA to go there, IMHO, and make that venue more visible. No need to separately enable 2FA access for a large number of users here - that's redundant, at the least. JavaHurricane 23:24, 20 February 2025 (UTC)
    The main concern raised is why should people bother to go to meta and request stewards? 2FA/MFA should be allowed by default. ~/Bunnypranav:<ping> 06:44, 21 February 2025 (UTC)
    Because we actually want people to understand the problems with the current 2FA system that Risker brings up before they get it for themselves. And if it really is a big deal to have to actually click on a link, read through a documentation page and write two lines in a request: well, what do I know. I for my part see this as a solution in search of a problem, and one that may result in users not being aware of the issues by default. And your blunt reply to Risker above is poorly thought: people can lose access to their authenticator app and security codes without any fault of their own, such as purely accidental loss of device, or a change in device, etc. It definitely is the WMF's job to care about if 2FA users can get locked out of their accounts and what should be done in such circumstances. For what it's worth, I had got 2FA for myself but had to turn it off when changing devices because for whatever reason Google Authenticator wouldn't load my Wikimedia 2FA on the new device. JavaHurricane 19:30, 21 February 2025 (UTC)
    If a person is signing up for a service [MFA], I guess they should be aware of the risks involved and what they're getting into? WMF should not have the job of taking care of users who just like to turn on stuff for the sake of testing it, and then lose their account. If I have to give a comparison, this is like saying you should request someone to be able to add a password to your account, because some people do not know how to save it and lose access to their account (lost password, no email set). If we can entrust saving a password to every user, why can't the same be extended to MFA? After all, it's another password. ~/Bunnypranav:<ping> 07:18, 22 February 2025 (UTC)
    The flaw in this analogy is that there is no way to "not have a password" or some other authorization credential and still have user accounts be a thing—there must necessarily be some credential for the computer at the other end to request, for you to prove that you are actually User:Example and not, J. Q. Random, or, another computer executing a program to guess passwords and crack into people's accounts. (And of course, as-is, people can edit without any account, subject to some restrictions.)
    This in fact—no accounts—is precisely how Wikipedia was when it first began back in the primeval eons of 2001 on Usemodwiki! There are no user accounts on Usemodwiki; the site is simply world‐writable by all and sundry. "Administrative tasks" such as deleting and blocking were protected behind "the admin password": the way you originally became an admin was, you asked Jimbo on the mailing list and if he approved he emailed you the password. (Have a look at nostalgia:Wiki Administrators.)
    This is the origin of what functions were originally bundled into the "administrator" package. When what became Mediawiki was first written, it essentially just copied the functions of UseMod and that distinction between "regular user" and administrator, only now with actual individual user accounts with password authentication, hooked into the Mediawiki SQL database backend. --Slowking Man (talk) 05:33, 23 February 2025 (UTC)
    @Slowking Man The analogy seems wrong, but it is actually being done, IRC. Unless you specifically set a password, your nickname is free for anyone to use (Ofcourse I'm not ranting about IRC, it is an example). Same can be extended for my argument about widely available MFA in Wikimedia, like we have a password granted by default to users, why can't we give them the opportunity to get a second password (MFA)? ~/Bunnypranav:<ping> 06:02, 23 February 2025 (UTC)
    There is a bit of a distinction: In IRC, two clients can't both have the same nick at once. The distinction arises because IRC is a stateful protocol, while HTTP (Web) is stateless. In IRC, servers keep track of which client currently has nick X; in HTTP servers have no concept of "users" or "usernames" or "user X is currently connected to me" (a connection state), anything like that. All that, where it exists, is implemented "on top" of HTTP in the application layer via mechanisms like Web cookies. (Similarly IRC nick "ownership" and authentication are implemented "on top" of IRC—which is a very rudimentary protocol—by adding "network services" like NickServ, which are just "bot" programs that sit on the network as users with superuser powers and (in the case of nicks) kick people off a nick unless they authenticate with the password.)
    The IRC case is actually quite similar to how "anonymous" users work in Mediawiki: because of TCP being stateful and connection-oriented, and IP using globally-unique "public" addresses, two clients can't both have the same IP address at once (analogy: IRC nicks). There can't be a situation where one-half of an edit from 1.2.3.4 is from one person, and the second half of the edit is from a different person on another continent. However IP addresses can be reassigned, so from one edit to the next, 1.2.3.4 can be different people.
    Also, from reading others' comments, my understanding is that 2FA de facto already is available to anyone who wants it? You just have to jump through the hoop of going to Meta and asking for it. --Slowking Man (talk) 17:02, 23 February 2025 (UTC)
    Also, from reading others' comments, my understanding is that 2FA de facto already is available to anyone who wants it? You just have to jump through the hoop of going to Meta and asking for it.
    Yes, anyone who wants it and isn't in a 2FA group here just needs to:
    1. Know they need to ask at Meta
    2. Ask at Meta
    3. Convince whoever it is at Meta that does the processing of requests that they understand the risks.
    My understanding is that all that is required for 3 is:
    1. Making the request in the right place
    2. Stating that you have read the documentation and/or understand the risks
    3. Not doing/saying something that makes it obvious you don't understand the risks
    Thryduulf (talk) 18:17, 23 February 2025 (UTC)
    Apologies if I did not get it clear, IRC was just an example with no intentions to get into the nitty-gritties of the tech behind it. Since 2FA is just frame a rationale to stewards that you know what it is and what can be the risks, I proposed that everyone*(EC if option 2, autoconfirmed if option 1) have it by default, with an additional change to the 2FA interface message (MediaWiki:Oathauth-ui-general-help) to clearly indicate the risks. I believe that it should help give the opportunity to help more people to secure their accounts. ~/Bunnypranav:<ping> 12:47, 24 February 2025 (UTC)
    In re If we can entrust saving a password to every user, why can't the same be extended to MFA?
    We entrust saving a password to every user, and people do lose their accounts this way. However, the difference is that the password works the way people expect, and the 2FA software is ...maybe not quite so likely to meet people's expectations. WhatamIdoing (talk) 19:27, 26 February 2025 (UTC)
  • Support > 3 provided it is optional, tbh the current defacto granting standard for oauth-testers on meta seems to be "has a pulse and/or has eyes". We are merely going to save folks a trip down to meta with this change. Sohom (talk) 04:50, 21 February 2025 (UTC)
  • Support 3, 4, 5 and 6 per Toadspike and TBF. Users in these groups are trusted by the community to wield advanced permissions that can do damage in the wrong hands so any argument about incompetence does not convince me, especially after MediaWiki:Oathauth-ui-general-help was updated to mention the risks. If such users want to secure their accounts with 2FA, they shouldn't need to ask anyone for it. Nickps (talk) 16:18, 4 March 2025 (UTC) 6 added on 18:52, 4 March 2025 (UTC)
    On second thought, supporting 6 as well. While not as dangerous as the others, I think that a user trusted with rollback can be trusted with 2FA as well. Nickps (talk) 18:52, 4 March 2025 (UTC)
    I don't think 2FA is a trust-based permission. Whether or not someone can use it is determined more by a baseline understanding of the technical risks of using it rather than trust. JJPMaster (she/they) 13:32, 11 March 2025 (UTC)
    That's not what I'm saying. My point is that editors are expected to be competent. This is even more true for editors holding advanced permissions. Therefore, we shouldn't insult their intelligence by having them tell the stewards that they understand the risks before they gain access. We should just assume they do. Nickps (talk) 13:56, 11 March 2025 (UTC)
    We expect editors to be competent at editing the encyclopaedia, we do not require them to be competent with poorly supported technologies with risks that are significantly greater than (and significantly different to) anything else you can casually turn on in your settings. Ensuring someone is actively aware of the risks of permanently losing access to their account is not an insult to their intelligence but a proportionate precaution. Thryduulf (talk) 14:28, 11 March 2025 (UTC)
    anything else you can casually turn on in your settings There's nothing casual about enabling 2FA even if you don't have to ask the stewards for permission. It's an process with multiple steps involving at least 2 different UIs, (WP and the 2FA app). Multiple warnings are given before and during this process. If the user ignores them and gets locked out of their account because of it, it's on them to convince T&S to let them back in. Otherwise, that's a CIR global lock right there. Nickps (talk) 15:49, 11 March 2025 (UTC)
  • Oppose all, you can already get 2FA tester by just asking the stewards for it, and they'll just ask if you actually read the policy (ie: don't blame us if you screw up 2FA because you didn't read it). I don't think we should really need to make it easier, especially when the only support for being locked out is essentially to convince Trust and Safety/sysadmins that you're the legitimate owner of the account. EggRoll97 (talk) 16:34, 4 March 2025 (UTC)
  • Oppose all, as the benefits basically consist of a couple fewer requests on SRP and are far outweighed by the massive backlog for T&S/sysadmins that would result. I am not convinced that occasional non-admin compromised accounts pose a major security risk. ⟲ Three Sixty! (talk, edits) 16:07, 11 March 2025 (UTC)
  • Support 2 I've been waiting for the day when more users will be able to use 2FA. This would allow more users to be able to protect their accounts even if they don't pose a greater security risk. Extended confirmed users will know what they are doing and are far less likely to cause problems in this area than autoconfirmed users. Knowledgegatherer23 (Say Hello) 17:43, 21 March 2025 (UTC)
    This would allow more users to be able to protect their accounts even if they don't pose a greater security risk. given that anybody can currently request 2FA at Meta, this won't increase the number of people able to use 2FA. Thryduulf (talk) 18:27, 21 March 2025 (UTC)
    But it'll definately make it easier to enable it and encourage more people to better secure their account. ~/Bunnypranav:<ping> 04:09, 22 March 2025 (UTC)

Discussion (2FA for more groups)

  • "with a registered email" isn't even an available option in this software. If someone wants this, I hope they are ready to write a patch to build it... — xaosflux Talk 19:11, 11 February 2025 (UTC)
  • Just noting that a lot of people already have non-WMF 2FA in one form or another. For me, it's that I need it to open my password keeper, which I need to do because I have no idea what my passwords for WMF wikis are. So I've already done a 2FA before I even log into my account. There is a multitude of commercial and free 2FA software, much of which is better supported than the WMF variant; if people are really concerned about the security of their account, they should consider that. Or not do things like use public computers or wifi in Starbucks, or choosing easy passwords; account security is ultimately the responsibility of the user. Note that I'm not kicking the WMF on this point; I know that improving this software and ensuring proper "ownership" and ongoing maintenance is very much on their radar, but there's still a lot of work to be done. We do need to keep in mind that the underlying software was created for WMF staff (at the time a much smaller and cohesive group), and it was maintained by volunteers for most of its existence. Risker (talk) 22:50, 11 February 2025 (UTC)
    There is a multitude of commercial and free 2FA software, much of which is better supported than the WMF variant Please avoid spreading FUD about 2FA. There is no WMF "variant" – Wikimedia uses the same, standard TOTP protocol like most other websites. I have been using 2FA for Wikimedia and other accounts for 5 years and have never faced any issue, nor seen any difference in Wikimedia's implementation as compared to others. – SD0001 (talk) 12:15, 12 February 2025 (UTC)
    My point is that many people are already using 2FA just to get to their WMF account. Having to then use the WMF 2FA on top of that adds zero security. The WMF requires the use of its own software (what I call the WMF variant) for certain permission types. It is in fact distinct from others, only a very limited number of WMF people are authorized to reset it. This is all well and good for English Wikipedia, but we are the exception. We speak the same language as the primary contacts to get things fixed. Most of the rest of the world doesn't. There is zero security or other benefit for those groups to use 2FA on their WMF account. The project doesn't benefit. The more people who use this particular extension, the more WMF resources are needed to support users who mess up. Given the non-existent security benefit for the websites, that is not good use of our resources. (And yes, I would call the one that I need for my password keeper a variant, just as I would the one I need for Google, and the one I need for two other apps I use. They may use the same principles, but they are all linked to specific functions and are only useful on that one site or group of sites.) Risker (talk) 19:01, 12 February 2025 (UTC)
    We don't use the term 2FA for anything other than mw:Extension:OATHAuth – doing that would be very confusing. The WMF requires the use of its own software (what I call the WMF variant) for certain permission types. It is in fact distinct from others,... Which permission types? Which software? I don't think what you are referring to has anything to do with this proposal. – SD0001 (talk) 07:23, 13 February 2025 (UTC)
    You can use any compatible client-side software for this, server-side you obviously have to use that extension. WMF only requires 2FA enrollment for these groups: meta:Category:Global user groups that require two-factor authentication. — xaosflux Talk 09:54, 13 February 2025 (UTC)
    This is a bit of a pet peeve of mind, but i think we should stop telling people not to use the wifi in starbucks. While that was good advice in 2010, its not really accurate anymore (hsts preload makes pulling off a MITM attack against Wikipedia very difficult even if you are on path). As far as what you're describing with a password manager - that is very good security practise, but would traditionally not be considered a form of 2FA (arguably though the security benefits are mostly the same). Bawolff (talk) 12:34, 13 February 2025 (UTC)
    Pure technical note: things like password managers are nice, but they don't add any "extra" security to your WMF account—besides encouraging you to use a better password. The password is the only thing that proves your identity as the account owner to WMF's computers, and anyone with it "is you" as far as the computers know and has total control over the account. This is "one-factor authentication": the password is the only thing, factor, needed to authenticate. Calling a password manager "non-WMF 2FA", while I understand where that's coming from, can mislead those not fluent with the concepts. The point of 2FA is that authenticating to the system on the other end, requires you to provide both of those two factors. Just the password by itself isn't sufficient. Hence if a malicious actor guesses or obtains the password, they still can't do anything with it without also obtaining access to that second factor. Analogy: something locked with two locks, keyed to different keys, so that both keys are required to unlock. --Slowking Man (talk) 21:57, 18 February 2025 (UTC)
  • IMO Option 1 (and maybe Option 2) should, if they gain consensus here, also require global consensus. It wouldn't make much sense for 2FA access to be automatically granted to anyone who makes a few en.wikipedia edits but restricted to advanced permission holders on every other WMF wiki. ⟲ Three Sixty! (talk, edits) 15:58, 13 February 2025 (UTC)
    Basically, yup. I tried to pass an RFC on meta-wiki to enable for all there, so that you would at least have to make a trip over to a non-content project and read a centralized, translated warning - but it failed to gain consensus. The lack of support is a real problem, but once someone makes it over to metawiki 2FA access is pretty much shall-issue - we mostly only check that a requester says that they read the warning. — xaosflux Talk 16:11, 13 February 2025 (UTC)
  • A notice for this discussion has been added to Help talk:Two-factor authentication. Nickps (talk) 01:07, 7 March 2025 (UTC)

Captions

Hi, I started a discussion about some texts I found unclear, at least for me, regarding when we don't have to add captions. Those who are interested, please share your opinion here. Regards Riad Salih (talk) 23:59, 24 March 2025 (UTC)

RFC on immigration terminology in Wikipedia articles

RCraig09 has begun an RFC about which of the terms "illegal immigrant" or "undocumented immigrant" should be used in Wikipedia articles. Please comment at Talk:Illegal immigration to the United States#Terminology: "Illegal" immigrant vs "Undocumented" immigrant in article mainspace. Jc3s5h (talk) 11:01, 28 March 2025 (UTC)

Consistency in coverage of Jeffrey Epstein ties

I had brought up this issue in individual discussion pages, but the argument generally ran afoul of WP:OSE, so I was advised to take the issue up to a community level. I hope this is an appropriate venue for it.

Currently, the articles for Bill Clinton, Bill Gates, Peter Mandelson, Lawrence Krauss, Nathan Myhrvold, Steven Hoffenberg and Jes Staley have detailed sections accounting their relationships with sex offender Jeffrey Epstein. The article on Donald Trump, who also had a well-documented relationship with Epstein, has no such section. This strikes me as a clear double standard. I had suggested adding an equivalent section to Trump's article, but got shot down on the grounds of it lending undue weight to the matter and assigning guilt by association to Trump.

That may be, but if that is the case, the sections in the other articles I mentioned shouldn't have such a section either. There simply is no valid reason to treat the Epstein connection as worth reporting on for all these other people, but not in Donald Trump's article. Either an equivalent section should be added, or the sections should be removed from the other articles where it's not essential.

The double standard seems especially galling due to the inclusion of Epstein info in Clinton and Gates' articles. By mentioning the matter in their pages, but omitting in in Trump's article, Wikipedia seems to be replicating Trumpian propaganda where the Epstein associations are treated as being of huge importance for Trump's political foes, but are minimized and treated as unimportant for Trump himself. I see this as an effective breach of Wikipedia's neutrality rules, and one that needs to be corrected. TKSnaevarr (talk) 23:20, 26 March 2025 (UTC)

If you want to bring it to community level, the appropriate venue is probably an RFC, I think -- the Trump article has a lot of those -- unless you're proposing something more general than just for Trump's article, which is probably unnecessary. Mrfoogles (talk) 16:07, 27 March 2025 (UTC)
Concur with Mrgoogles. WP:OCON. Wehwalt (talk) 16:26, 27 March 2025 (UTC)
My bad, then, since I'm the one who sent the OP in this direction. But I think an RfC should be here, not at the Trump article, since it will potentially impact at least three articles (Trump, Clinton, Gates). Pardon my pesky, obsessive need for organization. ―Mandruss ☎ IMO. 17:02, 27 March 2025 (UTC)
Another possible location to discuss it is WP:NPOVN or WP:BLPN (but it should be in one location, not several.) That said, my experience is that weighing articles directly against each other rarely goes anywhere constructive - even aside from WP:OCON, there's too many individual differences, both in the articles and their subjects. A more useful discussion might be to take a step back and ask what the general threshold should be for including Epstein file stuff on BLPs, at various levels of granularity (no mention / brief sentence / paragraph / subsection / full section, hopefully based on coverage levels) Making the discussion general and limiting specific focus on individuals (although some will obviously come up as examples) is more likely to produce useful results. Then, once those guidelines have been hammered out, you can turn around, figure out which articles are out of line with them, and raise that issue on their talk pages. --Aquillion (talk) 20:19, 27 March 2025 (UTC)
Is there really anything to discuss at a general level other than "follow WP:DUE" and assess whether content at issue complies with the policy? signed, Rosguill talk 23:36, 27 March 2025 (UTC)
Yes, there is - we could establish clear guidelines on what the threshold ought to be for each. For example, a devoted section could require WP:SUSTAINED coverage (eg. over the course of several months) in high-quality sources devoted solely to the subject's connection to Epstein (as opposed to just sources that mention them in passing as one of many people connected to them), or actual legal processes that sources treat as placing them in genuine jeopardy, or dedicated high-quality sourcing outside of the news media, or something of that nature. If there's sparse coverage dedicated to the figure specifically but none of the other things, it might get a paragraph rather than a section. If no coverage is dedicated to the figure specifically, and they're just mentioned in passing in larger articles, they might get a sentence or nothing. Part of the issue is that the conspiratorial thinking surrounding Epstein and many related figures makes it hard to judge due weight objectively; it also attracts many editors who are inexperienced with our processes and who therefore may feel that the simple fact that coverage exists makes a section due. Having guidelines we can point to saying "roughly this threshold" will make it easier to either decrease excessive weight where it doesn't belong, or increase it where we need more focus. And it'll give us at least something vaguely objective to use as a yardstick - otherwise WP:DUE can become highly subjective, which is a problem when dealing with so many highly controversial political figures. If you look at the figures mentioned here - Bill Clinton, Bill Gates, Peter Mandelson, Lawrence Krauss, Nathan Myhrvold, Steven Hoffenberg, Jes Staley, Donald Trump, etc - they differ wildly in how much weight the article gives them, for reasons that are simply unclear; establishing guidelines would avoid that problem. --Aquillion (talk) 13:55, 29 March 2025 (UTC)
I suspect the question, for all the Myhrholds there may be, and however responses would be phrased, would come down to Donald Trump, as if often does, whether there should be such a section on his page. Thus, my view is having another discussion elsewhere, when the Trump talk page has extensively discussed this matter, would be WP:FORUMSHOP.--Wehwalt (talk) 14:09, 29 March 2025 (UTC)
Trump is certainly an outlier, but the point is partially to avoid getting bogged down in people's opinions on highly-divisive individuals like that, and partially to escalate to a broader consensus on how to handle Epstein-related stuff about individuals due to concerns about inconsistency - it is not forum-shopping to escalate a potential problem that affects multiple articles to seek a broader consensus, which would (obviously) override any local consensuses on the affected articles per WP:CONLOCAL, and which is therefore clearly not duplicitive. That said, depending on where we set the threshold, it could just eg. result in less coverage on other articles (or more). If the problem is that we're doing it inconsistently, though (and I think there's a fair case for it), talking about broad guidelines might make people approach it more objectively and produce more constructive discussions. (Truthfully, my honest expectation is that the main thing such a review would discover is that we're probably significantly over-emphasizing Epstein stuff on a wide range of articles - for many of the listed articles it's just really hard to justify the level we have with the sources that are present. But that's an easier argument to make if we can determine rough guidelines first.) --Aquillion (talk) 14:15, 29 March 2025 (UTC)
  • Regarding WP:OCON, it's often cited without reading it; While consistency with other pages is not a good argument by itself, comparisons between pages are often made in order to illustrate a more substantial argument; as such, comparative statements should not be dismissed out of hand unless they lack any deeper reasoning. While relying on comparisons to other articles is generally unconvincing, articles that have been through some form of quality review—such as featured articles, good articles, or articles that have achieved a WikiProject A-class rating—are often the way they are for good reasons informed by site policy. If such articles have remained current with policy since their promotion, they are often more compelling examples to illustrate arguments. Many of the articles in question have undergone feature review, and a lot of the discussion has emphasized commonalities in sourcing that are not accurately reflected in our level of coverage, so there's an obvious deeper reasoning here. This shows that, yes, there is probably an underlying problem, which is best resolved by the sort of centralized discussion I outlined above that at least attempts to avoid getting bogged down in people's opinions about individual article subjects and instead tries to determine rough guidelines that can be used to then look back at the list of articles and confirm in a more systematic way whether WP:DUE is being properly applied. --Aquillion (talk) 14:22, 29 March 2025 (UTC)
I see that our article on Prince Andrew also has such a section. Phil Bridger (talk) 22:51, 27 March 2025 (UTC)
It seems more clearly pertinent in his case, since he faced pretty substantial consequences over his Epstein accusations and was personally accused by one of Epstein's victims of complicity, which is why I didn't include his article when I wrote the OP. TKSnaevarr (talk) 22:01, 29 March 2025 (UTC)

Proposal for something

Original heading: "Good Night". ―Mandruss ☎ IMO. 06:24, 24 March 2025 (UTC)

We could put a table of acknowledgments of edits also comparing with the page, would that be good? Exxxtrasmall (talk) 05:41, 12 March 2025 (UTC)

Isn't that what the page history is for? Chaotic Enby (talk · contribs) 09:42, 12 March 2025 (UTC)
I can't. I prefer to compare non-editor articles with this parameter and not users. Exxxtrasmall (talk) 13:02, 12 March 2025 (UTC)
Sorry, Exxxtrasmall, but I can't make sense of either your original post or the reply above. Could you elaborate a bit, or say what you want to say in your native language and let the reader translate? Phil Bridger (talk) 13:40, 12 March 2025 (UTC)
Prefiro a segunda opção como falante nativo de português. Exxxtrasmall (talk) 18:45, 12 March 2025 (UTC)
I don't know much Portuguese (only a few words I have learnt from friends, mostly Brazilian), but I think that translates to "I prefer the second option as a native Portuguese speaker". Phil Bridger (talk) 19:10, 12 March 2025 (UTC)
Podia criar uma tabela atualizada por um bot "ranqueando" (ranking) as 5000 páginas do domínio principal com mais "thanks log" (agradecimentos em português). Exxxtrasmall (talk) 19:16, 12 March 2025 (UTC)
You're saying that you'd find it useful to have a way to see a compact list of distinct contributors to an article instead of combing through every one of the thousands of contributions from a few contributors in order to get their names? If you want to get a list of who's contributed to an article instead of a list of every contribution, that's not currently easy to do AFAIK.
Now I'm trying to think of what that might be used for. If I understand your message correctly, your use case is to thank everyone who contributed to an article? (Sorry, I don't speak Portuguese either; just attempting to understand based on French and Latin cognates.) -- Avocado (talk) 22:31, 12 March 2025 (UTC)
When viewing an article click history, then page statistics, which brings you to something like this that lists contributors. ScottishFinnishRadish (talk) 22:35, 12 March 2025 (UTC)
TIL -- thank you! -- Avocado (talk) 22:35, 12 March 2025 (UTC)
Tipo, uma página assim ranqueando os artigos e não os usuários. Exxxtrasmall (talk) 15:57, 13 March 2025 (UTC)
It's there for articles, too. Use "View History" -> "Page Statistics". Here's an example: https://https://xtools.wmcloud.org/articleinfo/en.wikipedia.org/Portuguese_language#top-editors . And then a link at the bottom of that table to view "3,238 others". -- Avocado (talk) 16:10, 13 March 2025 (UTC)
Mas usando como eixo/vetor cartesiano da tabela principal os artigos do domínio principal, não do domínio usuário Exxxtrasmall (talk) 16:21, 13 March 2025 (UTC)
Google Translation: "But using articles from the main domain, not the user domain, as the Cartesian axis/vector of the main table". ―Mandruss ☎ IMO. 05:57, 24 March 2025 (UTC)
Maybe a "top contributors" section of the would be possible (omit reverted edits)? Thehistorianisaac (talk) 19:07, 22 March 2025 (UTC)
Mas não quero estatísticas de top- contribuintes e sim de top bibliografias citadas e/ou de top artigos com mais bibliografias. Calvice feminina (talk) 02:41, 23 March 2025 (UTC)
I'm sorry, I can't understand what you are saying(even with the help of google translate, because it is a bit confusing). May I ask if you could please use english instead? This is english wikipedia after all. there is portguese wikipedia in case you need it. Thehistorianisaac (talk) 05:58, 23 March 2025 (UTC)
But I don't want statistics on the top contributors, I want statistics on the top bibliographies cited and/or the top articles with the most bibliographies. Calvice feminina (talk) 20:23, 23 March 2025 (UTC)
So you want to know where the sources came from?
Simply scroll down to the references section, and you may see references that are used multiple times. Thehistorianisaac (talk) 23:43, 23 March 2025 (UTC)
In addition to what others have said, if you're looking for the most used reference within a given article you can check the number of pointers used in the references section, though that can vary based on citation style. If instead you're curious about the most times a single reference is used in any one article, at present that would be Smith's sea fishes in List of marine bony fishes of South Africa. 184.152.65.118 (talk) 20:06, 25 March 2025 (UTC)
@Calvice feminina, are you looking for Wikipedia:Articles with the most references or https://diff.wikimedia.org/2018/04/05/ten-most-cited-sources-wikipedia/ ? WhatamIdoing (talk) 03:41, 24 March 2025 (UTC)
Or the number of times citation |title= links are followed? I doubt that would be technically possible, as Wikipedia software is not involved in the processing of clicks on links. I detect a bit of a language barrier, and Google isn't helping much. ―Mandruss ☎ IMO. 06:15, 24 March 2025 (UTC)
We actually do have the answer to that, at the whole-site level. It's doi:10.1145/3366423.3380300. The answer is about once for every 300 page views. WhatamIdoing (talk) 02:41, 30 March 2025 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_217&oldid=1285081427"