Wikipedia:Village pump (proposals)

Source: Wikipedia, the free encyclopedia.
 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

Discussions are automatically archived after remaining inactive for nine days.

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

Why in the world would we do this? Sure, Twitter/X is routinely not a good source, but that's because of

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

@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)[reply]
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)[reply]
@Chaotic Enby: What I mean is that those articles are not great. Polygnotus (talk) 20:58, 29 January 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply
]
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)[reply]
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)[reply]

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

Reviving / Reopening Informal Mediation (
WP:MEDCAB
)

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

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

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.

Help resolve disputes! 09:57, 25 January 2025 (UTC)[reply
]

Addressing Two Concerns

I will try to address the comments of

dispute resolution
works poorly, and is not worth improving.

First, I am not sure whether I understand the concerns of

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

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

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
Help resolve disputes! 09:51, 27 January 2025 (UTC)[reply
]
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)[reply
]
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)[reply]
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)[reply]

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.

]

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

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

US cabinet nominees

Which is the better format for using "Nominee"?

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

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

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

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

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

Producing data dumps with only a subset of article history

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

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

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

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

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

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

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

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

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

Let's talk about Pending Changes

I've done a little bit of research into English Wikipedia's use of

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

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

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

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

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

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

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

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

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

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

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

Baghdad

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

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

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

An
conspiracy theorist
in the first sentence

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

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

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

  • Support this. * Pppery * it has begun... 00:09, 7 February 2025 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    Thanks for the clarifications, sounds like that achieves similar goals. CMD (talk) 03:53, 8 February 2025 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Comment Phabricator ticket T386290 is created. ~ 🦝 Shushugah (he/him • talk) 01:15, 13 February 2025 (UTC)[reply]

Trump, Cleveland, etc

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

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

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

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

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

Survey (Officeholder infoboxes)

  • Yes - We have the numberings in the pros & that's enough. GoodDay (talk) 18:58, 9 February 2025 (UTC)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
    Sometimes for reasons laid out by Chaotic Enby Zanahary 20:08, 12 February 2025 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]

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

I posted a message in that page proposing to use active voice in the edit notice. Z. Patterson (talk) 11:58, 11 February 2025 (UTC)[reply]

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

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:

  • Option 1:
    Autoconfirmed
    users with a registered email
  • Option 2:
    WP:Extended confirmed
    users with a registered email
  • Option 3: Autopatrolled users
  • Option 4:
    File movers
  • Option 5:
    New page reviewers
  • Option 6:
    Rollbackers

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

Survey (2FA for more groups)

Discussion (2FA for more groups)