Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• Jump to bottom
• New topic
• All village pumps

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, note:

• Discussions of technical issues belong at Village pump (technical).
• Discussions of policy belong at Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for 10 days.

« Archives, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80

Too many vague edit summaries when creating redirects

This is a problem caused by some people who don't know about WP:AES and think they always need to type something in the edit summary box. If you check the list of recently created redirects you will basically always see summaries like "Redirect." or "Created redirect" or something just as unhelpful that goes against WP:SUMMARYNO. On the other hand, if these editors just left the summary blank then an automatic summary would have been generated which includes the target. You can see how bad this can get with something like this where checking which of these redirects fails WP:FORRED is probably 10 times slower that what it could have been. I proposed an edit filter to fix this in EFR but they sent me here. So, how do we fix this? How can we make it so we can always tell what the target of a redirect is by looking at the edit summary? Warudo (talk) 17:19, 30 May 2026 (UTC)

When I create redirects I usually state the reason for creation rather than the target as that's what I find helpful at RfD where I already know the target. I can see why you would find the target useful in the creation summary though. My first thought as to a solution is for the software to append the redirect target as/in a manner similar to a tag. I haven't a clue how easy that would be to program though. I agree though that an edit filter prohibiting summaries that don't include the target isn't the right solution. Thryduulf (talk) 17:51, 30 May 2026 (UTC)

It depends on the kind of redirect. If it's a {{R from short name}} like Special:Permalink/1339839836 or a {{R to disambiguation page}} like Special:Permalink/1339428536 then it is helpful. But if it is a {{R from alternative language}} like the examples above then just saying for example "Created redirect to subject's name in Hebrew" is less helpful than "Redirected page to [name of subject]" because I can already see the name is in Hebrew but I can't read it to see if it's obviously a valid FORRED or if I need to look at the target article to find affinity.

Also, while not including the target can sometimes create problems, there's no harm from including the target every time. Special:Permalink/1339839836's sumamry could just as easily have been "new redirect form a short name of Horatio Arthur Yorke". So, even though I understand that my original proposal seems draconian, I don't see why it's not the right solution or why an edit filter "would end up being disruptive" as User:Daniel Quinlan asserted without any explanation. Warudo (talk) 18:25, 30 May 2026 (UTC)

But more importantly that all of that, getting the developers to fix this in the software level, while it is almost certainly the best solution, is going to be much slower than simply making an edit filter and that's assuming they will get to it eventually. Alternatively, we can make the filter now, ask the developers to fix the issue on phabricator and disable the filter after they do. Warudo (talk) 18:44, 30 May 2026 (UTC)

Filters interrupt the editing workflow so they should generally be reserved for more serious issues, not constructive good-faith edits. Given a notification after attempting to save their edit, many users will simply abandon the edit, or make an incorrect WP:EFFPR report that someone will have to handle, rather than read the notification and fix their edit. The right place to address this is in the editor (perhaps as part of Wikipedia:Edit check), but it needs careful design and testing to avoid similar downsides, which is why I suggested VPI rather than a direct feature request. Daniel Quinlan (talk) 19:52, 30 May 2026 (UTC)

All I can say to that is WP:CIR. If editors choose to abandon an edit instead of fixing an easily fixable problem with it because they can't or refuse to read an error message, that's on them. Warudo (talk) 20:29, 30 May 2026 (UTC)

That's a very ableist (for want of a better term) view. Error messages are scary and unless very carefully written often hard to interpret for those who don't already know what they need to do. What is trivial for very experienced editors like you are I is absolutely not for the majority of contributors. Every barrier to making an edit decreases the likelihood of the edit being completed (WhatamIdoing has stats on this I believe), so minimising barriers is important and intentional ones should be reserved for actual problems not just nice to haves. Thryduulf (talk) 20:43, 30 May 2026 (UTC)

The Editing team has a dashboard that shows the editing equivalent of a Conversion funnel. I doubt that there are recent stats available. WhatamIdoing (talk) 22:15, 30 May 2026 (UTC)

The entire field of UX exists because that approach consistently produces bad outcomes. Daniel Quinlan (talk) 20:50, 30 May 2026 (UTC)

But what about the user experience of the rest of us? Editors who do this make the interface more difficult for us to use by obscuring information. I don't think I have much more to say because having a conversation is much harder after the -isms start flying around, but why are we only focusing on the UX of people who can't or won't follow instructions? Warudo (talk) 21:00, 30 May 2026 (UTC)

I guess I am guilty of this since my last redirect creations were with the summary "Create", "create", "Create redirect", and "create redirect". Preventing constructive edits from happening because they don't have an edit summary never happens and would end up being disruptive. think they always need to type something in the edit summary box I have a preference checked that literally makes me verify that I meant to submit an edit with no edit summary. It is manifestly more difficult for me to edit if I do not submit an edit summary. I just tried to make a redirect with no edit summary and it stopped me from doing so. 1brianm7 (talk) 18:51, 30 May 2026 (UTC)

I have a preference checked that literally makes me verify that I meant to submit an edit with no edit summary that is actually disabled when creating redirects because the automatic summary is good enough (unless you use the 2017 editor). This is actually the reason I stopped using the 2017 editor because I also have this setting enabled. Warudo (talk) 18:58, 30 May 2026 (UTC)

Well, I am using the 2017 editor, so I guess that's why it happened. I have created 11 redirects in 2026, which really isn't enough to justify moving to a worse editor. 1brianm7 (talk) 21:04, 30 May 2026 (UTC)

Same situation. I use 2017 editor and would leave it blank except then people scrutinize edit summary statistics. Thebiguglyalien (talk) 21:38, 3 June 2026 (UTC)

... but teacher has always said to never leave a blank edit summary! I too have a user script that alerts me to a blank summary. If there is an automatic feature that is designed to make a better edit summary, then the edit summary box should clearly and dramatically indicate this. Not sure how that would work technically, but the edit UI needs to be very clear when/if a blank summary is encouraged — GhostInTheMachine ^{talk to me} 11:03, 21 June 2026 (UTC)

There is a very easy fix for this. The automatic summary should appear when previewing the page. Warudo (talk) 10:33, 22 June 2026 (UTC)

My practice varies. I typically leave the edit summary blank when I think the basis for creating the redirect is likely to be obvious or uncontroversial. Otherwise I will typically provide a brief explanation or rationale in my edit summary, like Thryduulf. I would have told you I usually include the target when I write my own edit summary but in looking at my history, I see I often omit this. I agree it's helpful when the target is included in the edit summary for the redirect creation (and every subsequent retargeting). At RfD and when assessing redirects on my own, I find the history of prior targets and the explanations are both helpful. For most redirects it may not make a huge difference but for those that have more than a few edits, it is helpful to be able to quickly see when, where, and why the redirect was targeted without having to click through each revision. If the target can automatically be appended for redirect creation (and retargeting?) without erasing the editor's own edit summary, that would be great. But I wouldn't want to lose the ability to add my own edit summary. I'm have no idea what the technical implementation would look like nor have I thought through all the implications of a mass, automated process. As an aside, I will try to remember to include the target when creating my own redirects. —Myceteae‍🍄‍🟫 (talk) 18:55, 30 May 2026 (UTC)

I don't understand the problem. When I look at that list of contributions that you linked, I just hover over the redirect title and the popup shows me the article it targets. (I think that's from Wikipedia:Tools/Navigation popups.) That seems just as effective as having the target in an edit summary. Schazjmd (talk) 21:04, 30 May 2026 (UTC)

That does not work in Special:RecentChanges and Special:Contributions. If I link to H.A. Yorke here and hover over it I get a popup, but if I go to https://en.wikipedia.org/w/index.php?title=Special%3AContributions&target=Thryduulf&namespace=all&tagfilter=mw-new-redirect&start=&end=2026-02-22&limit=50 and try it, I get nothing. Warudo (talk) 21:13, 30 May 2026 (UTC)

And even if it did work having to hover over every individual redirect would be significantly slower. Warudo (talk) 21:16, 30 May 2026 (UTC)

Odd, works for me in both contributions and recent changes. Schazjmd (talk) 21:27, 30 May 2026 (UTC)

Oh sorry, my bad. I enabled page previews but not navigation popups in my testing. When I enabled the gadget it also worked in those pages. Still, a gadget that is not enabled by default is hardly a solution. I'm not looking to just solve the issue for myself here. Warudo (talk) 21:35, 30 May 2026 (UTC)

It sounds like the issue is being able to see the redirect target without opening the page; nav popups helps with that. I don't think it's very likely that the community will approve an edit filter or any other means of enforcing a specific type of edit summary. It is not burdensome to enable the gadget. Schazjmd (talk) 21:40, 30 May 2026 (UTC)

The issue is being able to see the redirect target without opening the page at a glance. The gadget still takes time to use because you have to hover over the link. More importantly vague summaries go against WP:SUMMARYNO so there is still an issue to solve here. Warudo (talk) 21:45, 30 May 2026 (UTC)

Vague edit summaries are a social problem, not something a proposal like this can do anything about. Thryduulf (talk) 21:58, 30 May 2026 (UTC)

"a gadget that is not enabled by default is hardly a solution", if the scenario is one that ordinary editors encounter. A gadget that is very widely used by the tiny fraction of experienced editors who do this kind of work is an acceptable solution. It sounds like this is a problem that can be solved via documentation. The FAQ might look like this:

• Q: If someone doesn't link the redirect in an edit summary, then I have to actually look at the page. This wastes my time.
• A: So turn on NAVPOPS already.

WhatamIdoing (talk) 22:14, 30 May 2026 (UTC)

I'm guilty of this also. Looking at my last 44 redirect creations (which date back to 2018, which I suppose is when the tags started getting added):

• 17 of them have an edit summary consisting solely of "created redirect"
• 1 was essentially "created redirect" along with some thoughts about undeleting the history of a deleted article that was under the redirect.
• 19 of them were page moves and have the automatic summary generated with a page move, often along with some additional detail.
• The remaining ones generally seem to give some reason why I felt the redirect was appropriate, such as,
  • Redirect from typo.
  • Make it easier for people who can't remember the word.
  • created redirect from a NN company to its notable founder
  • created redirect from one island that does not have an article to the article on the chain of islands of which it is the largest.
  • created redirect for anyone looking for information on her
  • Department of university

I did not include the target in any of the ones that weren't a result of page moves. Would it be helpful to include the target? Which would be more helpful, the target, the reason, or both? ~ ONUnicorn^{(Talk|Contribs)}problem solving 22:05, 3 June 2026 (UTC)

Including both is most helpful. 'Created redirect to Foo, R from typo' or similar is concise and helpful. —Myceteae‍🌈 (talk) 15:17, 4 June 2026 (UTC)

Adding the target could be very useful if the software changes aren't too onerous. It could be prepended to the manual edit summary, rather like a section link often is when we edit a section of a normal page. Of course, the section header is added by seeding the edit summary box, which wouldn't work here because that appears before we reveal the target (or even that the page will be a redirect). Certes (talk) 22:27, 3 June 2026 (UTC)

Is there any indication of what the default edit summary would be if left blank? I don't think I've ever created a redirect, and if I didn't know for sure that an automatic one would be created, I almost certainly would never have thought to leave it blank. If there were some kind of preview of what the automatic summary will generate, or perhaps a button to fill in the summary with a generated version with the necessary details, it would prevent me from writing a less helpful version. I'm not sure what's possible there from a technical perspective though. I'd imagine any time an edit summary is generated (are there other cases?) it should be displayed to the user before they submit, otherwise it's always going to feel like a gamble. dylansan (talk) 19:23, 4 June 2026 (UTC)

Good point. It was certainly a surprise the first time I created a redirect forgetting to add an edit summary and found that I'd written an essay. I assumed that I'd accidentally pasted the page text into the edit summary box (and felt relieved that nothing confidential or embarrassing had been in my clipboard). More people might use this feature if it were discoverable. Certes (talk) 19:56, 4 June 2026 (UTC)

@Dylansan the default edit summary is "←Redirected page to [target]", see User:Thryduulf/Sandpit (history) for an example. Thryduulf (talk) 19:59, 4 June 2026 (UTC)

Thank you. I'm glad it's documented. I do think it's not enough to be documented somewhere. I think most users are going to be unaware of this unless it happens by mistake. An indication while making the edit would be more helpful. dylansan (talk) 21:02, 4 June 2026 (UTC)

If you leave the edit summary field blank when creating a redirect, the edit will always have an edit summary with the exact form "←Redirected page to <target>", where <target> is the target of the redirect. That's it. This is determined by MediaWiki:Autoredircomment. Here's an example. This edit summary also appears whenever you WP:BLAR a page or otherwise create a redirect without leaving an edit summary. Because of this behavior, I never fill out the edit summary field when making a mainspace redirect. SuperPianoMan9167 (talk) 20:02, 4 June 2026 (UTC)

Yeah, this is a good point. Editors rightfully have it in their head that they should always leave an edit summary and to keep it short and as others have noted some get an alert when they don't enter something, and that alert apparently doesn't account for edits that will generate one automatically when left blank. —Myceteae‍🌈 (talk) 20:08, 4 June 2026 (UTC)

@Warudo See User:Ahecht/Scripts/RedirectTagID, which modifies the "New redirect" tag to include a link to the target. --Ahecht (TALK
PAGE) 16:36, 16 June 2026 (UTC)

@Ahecht Thank you! I tested your script and it is very helpful. However, a problem I found is it only has access to the current target of the redirect. So, when a redirect is created targeting A and is later retargeted to B, your script will have "new redirect to B" next to the first edit, which is misleading example (4th entry). The phrasing needs some tweaking to reflect that what is shown is the current target, not what the target right after the edit. Warudo (talk) 17:27, 16 June 2026 (UTC)

@Warudo Yeah, I just discovered that too. I started a draft of a version that might work for old revisions at User:Ahecht/sandbox/Scripts/RedirectTagID.js, but it's not very straightforward to get the edit time from the contributions page. The same limitation applies to using popups, as suggested above, but I still changed the output to say "New redirect (currently to Foo)" --Ahecht (TALK
PAGE) 17:36, 16 June 2026 (UTC)

@Warudo I updated it with a new version that fetches the old revision of the page. My only concern is that it requires 50 times more API calls, so it may bump up against the new Wikipedia API rate limits. --Ahecht (TALK
PAGE) 21:08, 16 June 2026 (UTC)

@Ahecht That fixed the problem but it also made the tool more unreliable. I haven't run across API rate limits yet but when I check my own redirects a bunch of pages don't have a listed redirect and I see logs like "RedirectTagID: Invalid value "2026-06-1T14:16:00Z" for timestamp parameter "rvstart"." in the console. Warudo (talk) 22:06, 16 June 2026 (UTC)

I think the redirects where the tool fails are the ones that were created in the first 9 days of any month. The tool seems to handle days with 1 digit incorrectly. Warudo (talk) 22:10, 16 June 2026 (UTC)

@Warudo Should be working now. The only ones in your contributions that it fails on are cases where the redirect was malformed (e.g. return [[Module:Sandbox]], #REDIRECT [[Hololive Production#Holostars English]\n, or #REDIRECTG [[Template:Di-no_source-notice]]). --Ahecht (TALK
PAGE) 23:19, 16 June 2026 (UTC)

@Ahecht The script also fails if an rcat appears right after the redirect markup, as in #REDIRECT [[Dmitry Ioffe]]{{R to transliteration|he}} from דמיטרי יופהדמיטרי יופה which, along with some other such redirects (see console) appears in [1]. Warudo (talk) 12:18, 22 June 2026 (UTC)

The issue isn't the rcat being right after the redirect. The issue is that the first edit to that page was just {{R to transliteration|he}} without the redirect code, and the edit adding the redirect occurred within the same minute. Since the contribution page doesn't include seconds, there's no way for the script to tell which edit is being referred to.

I should be able to fix this on Special:Contributions pages since it gives an oldid, but there's no way to get the specific edit from Special:RecentChanges. --Ahecht (TALK
PAGE) 15:02, 22 June 2026 (UTC)

Ah nevermind then. Don't worry about it. After all, the same minute limitation is well documented. Warudo (talk) 15:57, 22 June 2026 (UTC)

@Warudo Actually, I figured out a way around it by grabbing the revid on RecentChanges as well. It should work now in almost every case except if the page was moved and then recreated after the redirect was created. --Ahecht (TALK
PAGE) 16:42, 22 June 2026 (UTC)

I've created phab:T428112 with the initial goal of getting an understanding of whether something like a tag or appending the target to the edit summary is at all practical (and if so which). Knowing that will be very useful in focusing this discussion and there are too many unknowns at present. Thryduulf (talk) 00:09, 4 June 2026 (UTC)

• I can't be the only one who is prone to typos and other errors in edit summaries, as in this example where I tried to be helpful by providing both the redirect target and the reasoning. Just adding this to the list of reasons why it would be helpful if the tags for redirect creation and retargeting automatically specified the target(s) regardless of what the editor puts in the edit summary. —Myceteae‍🌈 (talk) 20:16, 10 June 2026 (UTC)

Problem with newcomers leaving Wikipedia

Sorry, if this is not the right place to ask this. This is not an idea (but it may lead into one). In Polish Wikipedia we have a project led by Wikimedia Polska called WP:NOWI (nowi in Polish means new, but in a form that implies people) where we're working on increasing retention of Wikipedia users. We can share what we did and what the effect was when the project ends if someone is interested.

My question is if this is not a problem in English Wikipedia and what you do to make more newcomers stay?

We've noticed that some users don't contact their mentors when their article is reverted. We assume that they didn't know why and just left the project. The same happened when the article was proposed for deletion (in PL called DNU) and the person didn't contact their mentor. Those are our hypotheses. If someone is interested, my analysis in Jupyter Notebook is on my GitHub [2] (sorry, the comments and README are in Polish).

Did you notice anything like this in EN Wiki? Is this a problem you also want to overcome? jcubic (talk) 20:06, 3 June 2026 (UTC)

This is a major problem on enwiki. In my personal opinion, it's among the biggest problems we face. Mentorship especially doesn't seem to have much effect. I currently have about 800 mentees assigned to me, I get about one question every few days, and none of my mentees have reached an edit count of 500. Thebiguglyalien (talk) 21:36, 3 June 2026 (UTC)

Given that the number of editors who reach 100 edits is quite small (according to Wikipedia:Wikipedians, about top 1% of all users, top 2.5% of users who've made at least one edit), I didn't expect the mentorship program to have a huge effect, though I hoped it would have a small one. For reference, the number of editors who reach 500 edits is about top 0.25% of all users, and top 0.75% of users who've made at least one edit. isaacl (talk) 02:02, 4 June 2026 (UTC)

I think it does have a small one, but my impression is that the vast majority of new account creations aren't created with "I want to be a Wikipedian" in mind. Those I see on my talkpage usually make one comment and then disappears, but not all. Many newbies want to do something they probably can't, COI-thing or whatever, and when they learn that, they bugger off. Gråbergs Gråa Sång (talk) 03:54, 4 June 2026 (UTC)

The idea many people decide one day that "I want to be a Wikipedian" seems a bit silly to me. That is something that people might decide after getting a taste of working on Wikipedia. GeogSage ^{(⚔Chat?⚔)} 04:23, 4 June 2026 (UTC)

It took me 7 years to start making passable edits! There are definitely some of us who did not know how Wikipedia was actually going to go for them. Momonowa (talk) 15:52, 15 June 2026 (UTC)

I personally made my account to correct a typo here and there when reading Wikipedia. It took 3 years before I dived in deeper and became a daily-editing "Wikipedian" Athanelar (talk) 06:29, 16 June 2026 (UTC)

There are some major issues with retention for sure, but I think solutions fail to grasp how the majority of people end up being editors, and how Wikipedia policy gets in the way of that. Most people don't decide one day to start editing Wikipedia as a hobby, they have a goal in mind or want to fix some small mistake/omission.

For example, Wikipedia:Conflict of interest means we often discourage people who are most interested/knowledgeable in a topic from editing it. While this is often for good reason as it could otherwise be promotional, most cases of COI I've seen have been from people who were very obviously new editors and therefore very sloppy. Rather then trying to salvage their work and gently nudge it into compliance (if possible), COI slams them. If you look at the page for COI, it states COI is a problem because:

On Wikipedia, editors with a conflict of interest who unilaterally add material tend to violate Wikipedia's content and behavioral policies and guidelines. The content they add is typically unsourced or poorly sourced and often violates the neutral point of view policy by being promotional and omitting negative information. They may edit war to retain content that serves their external interest. They may overuse primary sources or non-independent sources, and they may give too much weight to certain ideas.

I propose this isn't necessarily because of COI, but because these editors are new. I got accused of COI on one of my early articles for a person I've never met (at the time, I was going through the textbooks on my shelf and trying to make pages for authors who appeared more then once in my collection), mostly for including stuff that wasn't necessarily noteworthy or standard on other bios (in hindsight, with more then 12000 edits, partly because the other editors were not very nice). Wikipedia policy, MOS, and the grey area where certain things are unwritten standards is hard to learn. The bait that could draw many new editors, making or expanding an article for someone or something they are connected to, ends up biting them and framing their early edits as bad because of COI, not because they are new editors learning the process. People don't want to necessarily start out on articles they have no "interest" in, but maybe after working on such an article, they would decide to stick around. I point this out partly because the COI policy seems to be counter to WP:OUTING policy (demanding people declare a COI very well could put them in the awkward position of needing to choose between lying, and outing themselves), which is much more important in my opinion.

Other issues pertain to the general culture around Wikipedia. For example, people who are used to spending time on Reddit might not realize until it is to late that common internet behavior/language is frowned upon or even blockable on Wikipedia. While the rules around civility are certainly important, the policies and rules (as well as how they are enforced) are very White, western, and neurotypical, and force conversation to be more like a BBQ with the HR department or a white collar company then how researchers organically collaborate IRL. Even if new editors aren't blocked/banned, the gamification of these rules can leave a bad taste in their mouth and cause them to leave. GeogSage ^{(⚔Chat?⚔)} 03:49, 4 June 2026 (UTC)

When mentees ask me about creating articles, especially if COI seems likely, I always add an if about COI (and explain it in plain English instead of using acronyms like COI). There's also been an occasion or two where they seemed competent enough that I mentioned they might consider editing as a hobby. I doubt they'll take me up on it, but it might be a numbers game. And to your other point, we really need to enforce WP:BITE very strictly. However much we endorse WP:CIVIL, WP:BITE needs to be a few degrees higher. Thebiguglyalien (talk) 17:53, 4 June 2026 (UTC)

I agree, bite needs to be more seriously considered. I've tried taking a "blunt" approach when I see a new editor making a mess if they push back, but this is mostly because experience says if I don't broadside right away the discussion gets out of hand. Essentially: "You're edits are not appropriate because _________. I suggest you read ____ before making changes." I believe we are too quick to apply penaltlies though, and that we probably need to be a bit more adult when it comes to dealing with difficult personalities in general. GeogSage ^{(⚔Chat?⚔)} 22:16, 5 June 2026 (UTC)

A lot of people will turn up at Wikipedia because they know something about a subject, and spot an error. This is a good entry-route, but can lead to bruising interactions with other editors. We need to be careful about accusing people of conflicts of interest merely because they are experts. WP:EXPERT is more applicable than WP:COI but both are sometimes brandished thoughtlessly. EXPERT also doesn't match the reality of articles on specialist technical subjects. We need to avoid throwing acronyms at new editors because it makes it look as though we care more about wikilawyering than making the encyclopedia good ("Ha! You may know about photosynthesis, but what do you know about WP:XYZ?? Back off newbie! I have wikiknowledge of which you can only dream..."). In the coming few years, we'll need to be careful about accusing newcomers of AI: it's increasingly difficult to tell the difference a human imitating AI and AI imitating humans.

Another very off-putting problem is gatekeeping: it's all too common for an editor's first efforts to be reverted with a rather patronising comment that the new editor is new, and therefore doesn't know what they're doing; the current version of the article has been stable for 10 years, and therefore all change is wrong. In fact, of course, the current article has been stable for 10 years because its creator has politely bludgeoned into submission anyone who attempted to change it. The determined newbie editor will come back and say that contrary to the accusation, they actually do know about the subject. Their further efforts are then reverted again, this time with a link to WP:EXPERT, and a comment that whatever they know to be Right is Wrong because it's merely what they Know. You either know too little, or too much... So they come back a third time, this time citing good secondary review articles, and it gets reverted again, on the grounds that (a) the review articles are irrelevant because they discuss a subtly different concept to the exact subject matter of the article, and (b) with a polite suggestion that the newbie editor is unqualified to edit the article because they show bias by using reviews of which they are aware (and that might have been written by someone with whom they are acquainted). At this point, the average newbie will decide that Wikipedia articles are vanity-items for their creators, and the whole thing is a waste of time. Elemimele (talk) 16:57, 9 June 2026 (UTC)

Showing no evidence for this and with the understanding that it may have been hashed out to death in the past, my impression is that there are a few trends in the project that gradually increase friction for newcomers by making it more difficult to make substantial edits that stay sustained in the article. Without edits that are sustained, newcomers lose the important sense of self-efficacy (that they can translate free time spent editing to impact on an article) and then they quit.

Examples of these trends:

1. Instruction creep: More policies, a bigger precedent body, and a more mature editor culture (in terms of unwritten rules, etiquette, etc.) means that the skill floor needed to make a substantial edit stay sustained gradually increases.

2. Less collaborative editor culture: In a normal organization where employees can't easily leave their job, less collaborative, tenacious people can and do get pushback for not being good team players. On wikipedia, the job is free time. That means that it's easier to quit than to push back on an un-collaborative person. The result is that on Wikipedia specifically, those editors tend to survive more, on average. Over time, the average long-time editor is more tenacious and in my eyes less willing to collaborate because the environment silently rewarded tenacity: If making the other person silently give up and go away is rewarded (because you get your way), then that's the editor base that you'll get after a long enough period. By now, I think that the average newcomer is far less tenacious than the average long-time editor, so the result is that in an inevitable disagreement, the long-time editor gets their way and the newcomer leaves.

3. Less open culture: Extended confirmed restrictions are an example of this. I think this one is a lesser issue than the ones above because it's focused on specific topic areas, but it still contributes. It's hard to reconcile the myth of "an open encyclopedia" with the fact that most hot-button topics are practically locked to newcomers. For a casual newcomer, getting 500 edits seems like a herculean task if they extrapolate from their first edit, which may have taken a few minutes to read the article, notice some mistake, and then fix it. If I was told that I need to spend e.g. 500* 4 minutes = 33 hours to be able to edit some article, I'd think lol k and go do something else with those 33h of free time.

How to fix: #1 and #3 are frankly complicated. #2 is difficult because of a scale surveillance and enforcement problem: From a project-wide perspective, uncollaborative behavior is a death by a thousand paper cuts where many small unfriendly interactions make many newcomers leave. Frankly, I wonder if setting up AI that scans all editor interactions and scores people's behavior for collaborativeness might be useful, along with producing exemplars as evidence for the score. It's not technically difficult to set up, and it can just act as an alert queue for interactions that likely led a newcomer to leave (one can test that by the last few interactions of a newcomer, who they worked with and what happened). The main issue might be cost, but I think a selective trial run could be inexpensive to try out. spintheer (talk) 21:48, 12 June 2026 (UTC)

A triangular graphic representing a "hierarchy of disagreement" from clear refutation to mere vituperation, based on the essay "How to Disagree" by Paul Graham.

• I think that we can look at Hierarchy of Disagreement to see the problem. When dealing with new editors, some experienced editors start by contradicting them and then never actually offer a counterargument. New editors respond with name-calling, and then the experienced editors respond to the new editor's tone without addressing the point. On Wikipedia, accusing someone of being an expert or looking "involved" is just a thinly veiled ad hominem.
• I started editing Wikipedia because I found an error on a page, I was looking for citations for a publication I was working on and figured the Wikipedia article might have some useful ones. The main problem I've seen with experts is they are used to writing to expert audiences, and citing certain technical things for them is like citing the sky is blue. Then, when a citation is demanded, they don't actually know where to find it because it is so deeply engrained as common knowledge that no one in their discipline has cited the fact in decades.
• In the coming few years, we'll need to be careful about accusing newcomers of AI: it's increasingly difficult to tell the difference a human imitating AI and AI imitating humans. I spoke to a journal editor a few years ago about AI detection, and he said they were running all the submissions through a checker and desk rejecting the ones that came back as using AI. I told him to take something he wrote from before AI was a thing and check it, and it returned with a number that would have caused a desk rejection. Turns out, academics have a way of speaking that AI is really good at mimicking as it was trained on a lot of open peer-reviewed publications. Wikipedia also has a way of writing, and AI was trained on Wikipedia. This will be a huge problem in the future.
• The worst Wikilawyering I've encountered was on an article I originated where several editors decided they wanted it a certain way, even though I had researched policy and found the way I was doing it was acceptable. The problem was formatting and layout of the page, not even content related. A few admins were mixed in the bunch, and they essentially told me that they were doing it because that is the way they like it, and then went through other articles I made and applied the changes. They then tagged other articles I wrote with multiple tags, and nominated a page I originated for deletion that ultimately was not deleted. Really turned me off from the Wikipedia community, still sour about it, and again in hindsight, I don't think they had a leg to stand on besides 3 against 1 new editor. I'm the one who originated the pages, and I've stopped thinking about expanding them at this point because of this interaction.

GeogSage ^{(⚔Chat?⚔)} 18:22, 9 June 2026 (UTC)

I spoke to a journal editor a few years ago about AI detection, and he said they were running all the submissions through a checker and desk rejecting the ones that came back as using AI. I told him to take something he wrote from before AI was a thing and check it, and it returned with a number that would have caused a desk rejection.

I have never seen anyone make a claim like this and actually provide proof of the text that supposedly did this.

Actually, wait, no, I saw it once. That person was a blogger who previously wrote an article about how they use AI in their writing process. Gnomingstuff (talk) 05:45, 11 June 2026 (UTC)

I used ZeroGPT on random open-access science journal articles from 2016, I checked five articles and got scores between 1% and 39% (at 35% and 39% ZeroGPT describes the text as mostly human written but containing contributions from an AI; at 4% and below it describes it as human-written, I didn't get any results between 4% and 35% in my sample). I don't know what threshold the editor GeogSage talked to was using, but the claim is certainly believable. Thryduulf (talk) 09:51, 11 June 2026 (UTC)

I believe you that you've done this, but which five? Gnomingstuff (talk) 19:08, 16 June 2026 (UTC)

I didn't think to keep a record of that unfortunately (I don't even remember which journal it was and I'm on a different machine to then so can't reconstruct it from browser history). I think I googled something like "open access science journal 2016". I know I picked studies from different fields (or what appeared to me to be different fields based on the title) and used the abstract and first section up to the maximum length allowed for free (iirc the list of articles was sorted by date). Thryduulf (talk) 19:47, 16 June 2026 (UTC)

I ran a couple of my Wikipedia articles through one of the free online detection websites during an early discussion about LLMs. One of them was declared to be highly likely to be AI-generated. (I no longer remember which one, but there may be a link in one of the talk (WT:) pages.) Now: that was then, and the detectors might be better now, and free websites are often worth what you paid for them, etc., but it made me wary of trusting them. Maybe they mostly work, but a 1% false-positive rate applied to 100,000 edits would mean 1,000 edits wrongly flagged. WhatamIdoing (talk) 05:03, 14 June 2026 (UTC)

My Masters thesis is from 2019 and is considered 3% GPT with zerogpt. Within the body of the document, in more technical sections, the number goes a bit up. For example, the line "H0; There is no statistically significant difference between the performance of the" comes back as AI. A few years ago, the number was higher when I checked. Grammarly currently detects zero AI in it, but earlier this year did say there was something or other that looked like AI. One concerning thing is Grammarly only detects my Abstract as 100% plagiarism, so someone could get the rest of my thesis past it and publish it as their own if it was the only plagiarism checker. @Thryduulf, this was a few years ago now, but I believe they were using a 10% hard cutoff, but the editor would use discretion if it was lower, so a 1% detection could have resulted in a desk rejection if the editor felt it look particularly egregious. Go play with old peer-reviewed publications, if you do it for any amount of time you'll find old publications that come back as AI-written. GeogSage ^{(⚔Chat?⚔)} 05:32, 14 June 2026 (UTC)

• I think we need to look beyond raw numbers. Do we want to retain new editors? Yes - if they are helping us to have well researched and well written articles … No - if they are producing crap. Blueboar (talk) 12:31, 11 June 2026 (UTC)

  If someone is actively trying to be helpful and willing to learn, we can teach them not to produce crap if we have some patience. GeogSage ^{(⚔Chat?⚔)} 05:33, 14 June 2026 (UTC)

  Hi. Alas the situation does not look so good with respect to technical articles. We can teach newcomers how to edit pages that do not require deep knowledge, but many of those people who know technical topics have played with Wikipedia or done serious work in the past 10 years then left. I am surprised how many have left. I did a few fixes to Theory (mathematical logic) the other day, then went to see who had edited it before. The top 3 editors who had done about 60-70% of the edits (and all seemed to know the subject) are no longer here. Two stopped a few years ago, the other was blocked for other reasons. And the wannabe logicians have made a mess of some issues. Good intentions, but low on knowledge. So the situation is highly time sensitive. As the experts get tired and leave very few newcomers have expertise to replace them. I was pleasantly surprised to see the young and bright User:JoaoFrancisco1812 do good edits, but he is an exception in the logical space. So time is not on our side. Sorry, but that is how it is. Yesterday, all my dreams... (talk) 09:27, 15 June 2026 (UTC)

  I see a trend here. They left or got blocked, probably because of hostility (WP:BITE). On PL wiki we want to engage mentors more, so they look up the mentees instead of just waiting for questions that may never come.

  I had this idea to list all mentees and their latest edits using the template that transludes Special:Contributions.

  I plan to create a bot on PL Wiki that will keep the list in sync when new mentees join. This way mentors could, once a week, go through the list and see if anything needs their attention.

  I do a similar thing for people during trainings about Wikipedia to monitor their activity, but I do this by hand. jcubic (talk) 14:56, 15 June 2026 (UTC)

  Sorry, but that was not the trend. Please look at the facts. The user CBM was an admin and gave it up because of lack of time, he said. Then he stopped editing later. Greg Bard was blocked for copy vio. I am not sure why the other one left but fights were not the reason. They had all been long term editors and the subject of logic does not invite big and repeated fights. Now if you feel like writing a bot please see Wikipedia:Bot requests. I requested a bot to generate data about departed users so we could analyze it. It would be nice if you would write that. Cheers. Yesterday, all my dreams... (talk) 17:33, 15 June 2026 (UTC)

  If I have working code on PL Wiki, I will think about adding it to En Wiki. Will probably write a different thread to know if anyone is interested. jcubic (talk) 17:39, 15 June 2026 (UTC)

  • One issue I've seen on issues I'm fairly well versed on is a strong Dunning–Kruger effect. If you have one expert on a topic, unless the rest of Wikipedia is willing to be open to the idea they are wrong, the expert has an uphill battle to fight. The editors who have a limited background on the topic think they have a stronger grasp of it then they actually do, and because of Wikipedia policy regarding WP:BLUDGEON, it is extremely easy for a few people to overwhelm an expert editor, and then actively use Wikipedia rules to tell the expert to shut up. Makes it pretty hard to keep motivated when you put a significant amount of time and effort into something, only to have it overruled by a local consensus that has almost no idea about what they are talking about. 1,000 editors arguing with one expert on a topic doesn't make those 1,000 editors correct, but good luck pointing that out.

  GeogSage ^{(⚔Chat?⚔)} 17:37, 15 June 2026 (UTC)

  That is certainly true for some topics, but not all. How many novices have even heard of Tennenbaum's theorem which gets about 10 views a day. CBM seems to have just written most of that with no conflicts. I am sure everyone and his uncle has an expert opinion on psychology or economics. But in high energy physics or the obscure parts of math logic the novices do not even know how to spell the article titles. Alas some experts who joined 10 to 15 years ago have all worn out, by fatigue not just fights. And the supply of young experts is limited. The smart ones want to start a billion dollar AI company, not do anonymous unpaid work. C'est la vie. Yesterday, all my dreams... (talk) 20:32, 15 June 2026 (UTC)

  To look at your question from a purely numbers standpoint, we can make some ballpark back of the napkin estimates to see the problem. First, assume experts are equally likely to become Wikipedia editors as the general population. Looking at the tables on Wikipedia:List of Wikipedians by number of edits, only about 1 in 5 editors have made more then 10 edits. Generally speaking, even if we snag an expert, the chances of them staying around are already pretty low. Looking at Wikipedia:Wikipedians, there are 16 million accounts that have edited Wikipedia. Assume that the 2011 demographic numbers at Wikipedia:Wikipedians/Demographics still holds, roughly 20% of those will be U.S. citizens, so 3,200,000 accounts (limiting for U.S. cause the numbers are a bit easier to get). The U.S. population is roughly 341,784,857, so assuming everyone who has edited Wikipedia is still alive, roughly 0.936% of the population has an account that has edited Wikipedia. You can then apply that to say, the number of Americans with a doctoral degree of some sort is (roughly 2%, so roughly 6,835,697 people), so all things being even, roughly 63,982 Americans with a doctoral degree should have edited Wikipedia at some point. If you split this number up by discipline, the numbers will be shockingly low. Looking back at the table, 1 in 1,000 editors has made 10,000 edits, so without some outside influence, we can expect 64 doctoral level editors from the U.S. to have made 10,000 edits. Obviously confounding variables make this ballpark guesstimate have pretty enormous error margins, but even if you triple that it still is a fairly small number across all disciplines. GeogSage ^{(⚔Chat?⚔)} 21:28, 15 June 2026 (UTC)

  My friend I have never trusted napkins numbers. No can do. Sorry. Yesterday, all my dreams... (talk) 22:49, 15 June 2026 (UTC)

  Not a fan of Fermi problems? Understandable. I was taught to guestimate as part of designing a broader experiment to answer a question. Essentially, start with broad estimate, refine the number, then use that to formulate your hypothesis. Then design an experiment, gather observations, and compare them to the initial estimate. GeogSage ^{(⚔Chat?⚔)} 22:55, 15 June 2026 (UTC)

  Another issue is that of "extremely occasional" edits by experts. Over time, I had seen some advanced and nice edits by User:Tillmo eg the creation of the page Institutional model theory which novices could not even begin to edit except for typos. But he does 5 to 7 edits per year at best! Can we get new young editors to work on those pages? I have not seen them. We are seriously short of experts. Yesterday, all my dreams... (talk) 21:26, 15 June 2026 (UTC)

Speculation, stratified sampling and real data

Why do newcomers leave? I would not even attempt to hazard a guess. It would be pure speculation without multiple focus group studies, which we can not easily perform, given no access to the departed, so to speak. What experienced marketing people would tell you is: never guess, study the market and the participants. So we can all guess for ever, based on our limited samples of interactions, but I have no idea who will be proven right if we have access to the motives of the users. We could contact those with emails, but not so easy. So let it be as it may. Yesterday, all my dreams... (talk) 22:31, 12 June 2026 (UTC)

I agree. I'm also curious to know why non-newcomers have also left: Wikipedia:Missing Wikipedians. Maybe the reasons for leaving are similar for both groups. Some1 (talk) 22:50, 12 June 2026 (UTC)

I did not know about the MIA page. When I looked at it my first reaction was: this needs multidimensional analysis. Then something funny happened. I looked at the multi-D page and saw that it was really short with just 2 sources and would probably make John Tukey laugh because it totally ignores his work. Then I saw that over 50% of the edits were by User:Wikiant who stopped editing in 2018! That page needs help. But the MIA page needs to go into a database so multi-D views can be used. I wonder who has time to do it. Yesterday, all my dreams... (talk) 02:10, 13 June 2026 (UTC)

By the way, having looked more at the MIA page, I have serious doubts about the completeness and accuracy of the data there. There is a lot of data, a good deal of it entered by ip edits. A simple bot can generate that page correctly every month. Yesterday, all my dreams... (talk) 06:12, 14 June 2026 (UTC)

That page was never intended to be comprehensive. I believe it was begun by editors who missed particular friends, collaborators or sparring partners; over the years it may have been added to somewhat more objectively or systematically, but it’s certainly unsuitable for analysis beyond individual anecdotes or ‘case studies’.—Odysseus1479 22:14, 15 June 2026 (UTC)

Indeed so. I have said above that I do not trust the data there at all. So I requested a bot to generate it correctly. Would you like to support that at the Wikipedia:Bot requests page? Thanks Yesterday, all my dreams... (talk) 22:24, 15 June 2026 (UTC)

...A bot that automatically emails editors with more then 100 edits who have not edited in 12 months with a survey could provide some pretty useful data... Like, worthy of a peer-reviewed publication. GeogSage ^{(⚔Chat?⚔)} 22:45, 15 June 2026 (UTC)

That is your idea, and a good one. Please suggest it where I suggested mine. Anyway, I have said all I have to say on this subject, so now it is time for you know what on my part. Have a good day. Yesterday, all my dreams... (talk) 22:54, 15 June 2026 (UTC)

There's been a lot of research done in the past, and the main reason for a promising new editor to quit is that their first good-faith attempt was reverted. The best thing you could do to retain editors was to fix the problems they created. This means, e.g., looking at a fairly bad edit with a fairly bad source, and thinking "Oh, they're right: This article was missing information about ____. Let me see if I can find a good source and fix this up". Instead, what we mostly do is say "You didn't do it perfectly on the first try – revert!" WhatamIdoing (talk) 05:06, 14 June 2026 (UTC)

I do not know who did the research and how good they were at research. So I will still assume nothing. Yesterday, all my dreams... (talk) 06:08, 14 June 2026 (UTC)

As an RC patroller, I think that this is a very important issue that I myself do without meaning anything about it. I'd honestly be fine going on an RC patrol tool (even one where the entire job is to revert vandalism) mainly to find bad but good-faith edits and make them good again. In solidarity, FantasticWikiUser_{(Ts and Cs)} 13:21, 16 June 2026 (UTC)

I try, but it can be quite a bit of work, for niche articles, and for editors that may still never return.[3][4] Rjjⁱⁱⁱ (talk) 04:00, 17 June 2026 (UTC)

From my perspective as someone who joined Wikipedia in 2024, newcomers are probably too afraid to make a mistake or not seem professional, as their edit mistakes are forever kept in an article's edit history. So some kind of spotlight effect or such is turning new users away. This effect is amplified if their edit gets reverted on an article about their local history and area. QuadrangleDinglePingle (talk) 07:17, 14 June 2026 (UTC)

On the 8th and 9th June, I decided to make a quick test by putting some accounts into a word processor and seeing what happened. This is what they've done.

Kaffe453 - Doing quite well. None of their edits were reverted, but they weren't welcomed either. I welcomed them just now.

Madein100 - Was welcomed and not reverted, but added links to articles over and over again.

RetlawStnaj - 2 edits, one on May and one on 8th June. No reverts, no welcomes.

Fizzymelonjuice - Did newcomer tasks without reverts on 9th June. On the 14th, they were welcomed and made another edit.

Cbbc history of 2002 - First two edits were reverted, last two weren't. No welcomes. In solidarity, FantasticWikiUser_{(Ts and Cs)} 14:00, 16 June 2026 (UTC)

One newbie who left's perspective

I speak only for myself, but I really wasn't inclined to stick around after my bad experience with ANI and the J.K. Rowling article (in fact I resigned myself top reading due to the reception I got, especially from one particular Wikipedian). I went to the J.K. Rowling article, hoping to find out about her transphobia, and found nothing, which I thought odd for a featured article. Having been an IP editor/reader for a long while, I knew about talk pages and pages like Administratrator's Noticeboard/incidents (and enjoy reading them as well as policies. I'm one of those people who likes to see how the sausage is made), though not entirely how they worked. I read through the talk page, which was in the middle of a very contentious featured article review, and found some serious WPO:OWN issues, what I perceived as throwing out policies because they might make Rowling look bad and "it's a featured article", and what I saw as other rulebreaking. I thought I would take it to ANI to get things on track, and while it was rightly closed as a content dispute, the call to ban me from the noticeboard, the constant pestering from one user to explain how I had come across that board (IIRC. May be misremembering), and, in the aftermath, the perceived unapologetic approach to what I saw and still see as a major case of WP:BITE, instead of acknowledging that maybe they had gone too far in trying to do so, directing me to an area I had no interest in, let's just say that I wasn't exactly interested in sticking around if a newbie could be treated like that without even a slap on the wrist. That the J.K. Rowling article was ultimately defeatured did make me happy, but it was too little, far too late to bring me back at that point--Lover of lgbt literature (talk) 22:35, 14 June 2026 (UTC)

Revision history statistics

The page information external tool "Revision history statistics" shows editor activity measured in several different ways. What is missing is any count of article text deleted. When an article is overlong and full of questionable content (uncited, off-topic, hyperbole, etc.), deleting material may be more important than adding new content, yet it is given no recognition in the statistics. This seems to be an omission. ThoughtIdRetired _TIR 21:25, 6 June 2026 (UTC)

Which tool are you talking about? Can you post a link? WhatamIdoing (talk) 20:35, 9 June 2026 (UTC)

I guess they're talking about the Xtools page history (linked as "page statistics" on the history tab), e.g. [5] for the random article I got. It shows the top 10 editors by added text and by authorship, but the only thing related to deletion it shows is the single edit that resulted in the greatest reduction in page size. Thryduulf (talk) 20:58, 9 June 2026 (UTC)

Yes, was just putting together the answer:
At the bottom of Information for "Wikipedia:Village pump (idea lab)"[6] you see "External tools", the second one down is "Revision history statistics" with the link [7] . ThoughtIdRetired _TIR 21:06, 9 June 2026 (UTC)

So you're starting at https://en.wikipedia.org/w/index.php?title=Feng_shui&action=info#External_tools which links to https://xtools.wmcloud.org/pageinfo/en.wikipedia.org/Feng_shui which says that @Hipal has made 57 edits, but it's not until you click through to https://xtools.wmcloud.org/topedits/en.wikipedia.org/Hipal/0/Feng%20shui that you can see that the net effect is removing about five times as much as they've added. WhatamIdoing (talk) 05:14, 14 June 2026 (UTC)

OK, we can see the amount of deleting that one editor does, but not the activity of an efficient editor who deletes a lot of material in a very small number of edits. In your example, Hipal has made 57 edits and so appears in the list for you to investigate further. Suppose another editor had deleted much more text, but overall made just 5 edits; the deletion activity would be completely invisible.

Furthermore, there is no clue in [8] that Hipal has made any deletions. You have to do a manual search to find the information that you have highlighted.

The point I am making, if it needs reiterating, is that this tool tells us all about those who add text to Wikipedia and nothing (readily accessible) about those who delete material that should not be here. Reporting added text, when an encyclopedia is meant to be concise (summary style), is perhaps a little off-key when not balanced with showing deletion activity.

We know that deletions happen, from the ups and downs of the graph of article size (at the bottom of the page linked immediately above). The questions "who does this?" and "what do they delete?" are difficult to answer without laborious study of an article. ThoughtIdRetired _TIR 08:25, 14 June 2026 (UTC)

https://xtools.wmcloud.org/pageinfo/en.wikipedia.org/Feng_shui#top-editors shows the first 20 by default; if you want to see the full list, then a link is provided immediately after the 20th entry. If you click it, it expands to 200; if you click it again, it expands even further. Every editor of that page is listed, but you have to click to reveal the less frequent ones.

I agree that Wikipedia:XTools does not highlight the information you're seeking. You could ask the volunteers who created and maintain it to add more information. WhatamIdoing (talk) 00:52, 15 June 2026 (UTC)

Very useful but rather obscure tool

I asked a question at WP:Help Desk#What links here and discovered a very useful tool called WikiNav that gives link statistics. A number of experienced users were also unaware of it, and some were surprised that it exists. I find the information it provides eye opening.

My suggestion is to let more users know about it. But how? Please promote it as you see fit. Thanks. Yesterday, all my dreams... (talk) 17:15, 10 June 2026 (UTC)

Could ask @MusikAnimal to add it to the "analysis" submenu of the MoreMenu gadget, as I suggested in that earlier discussion. A lot of editors use the gadget, and it being available from the menu would immediately make it widely available and convenient to use. – Scyrme (talk/solidarity) 17:31, 10 June 2026 (UTC)

The issue is that for privacy reasons, the tool only works for popular-ish articles, and for a limited number of languages. MoreMenu can be configured to handle the language bit but it won't know if the tool supports a given article or not, so many times the link won't work. That said I do hope to maybe one day integrate WikiNav data (and a link to WikiNav for the visualizations) directly into https://pageviews.wmcloud.org. — MusikAnimal ^talk 19:52, 10 June 2026 (UTC)

I wonder if the "popular-ish articles" limitation is why it sometimes fails without explanation. WhatamIdoing (talk) 20:09, 10 June 2026 (UTC)

Let us not expect perfection as a start. Let people love it, as I do, and it will grow. Yesterday, all my dreams... (talk) 20:12, 10 June 2026 (UTC)

Wikinav was created five years ago as part of an Outreachy internship.[9] It won't necessarily grow. In fact, it's at risk of breaking without warning due to software rot. WhatamIdoing (talk) 05:27, 14 June 2026 (UTC)

What can I say, what can I say. A very useful program is ignored, and far out projects attempted. I will use it as is anyway. I have learned a lot from it already. Yesterday, all my dreams... (talk) 06:04, 14 June 2026 (UTC)

That is my impression. WikiNav doesn't work when pageviews are too low, but I don't know what the cut-off is, and it would be nice if it just said that rather than returning a cryptic error. —Myceteae‍🌈 (talk) 21:40, 10 June 2026 (UTC)

Sometimes, eg for Chicago, the graph fails but the data is available below. The system is far from perfect, but still better than not having it. Yesterday, all my dreams... (talk) 06:24, 11 June 2026 (UTC)

Agreed, I find it quite useful. I've learned about its strengths and weaknesses by using it and reading what other editors have to say about it in discussions, mostly RMs. I've developed my own sense of how to use it alongside other tools but I know there are gaps in my understanding. As I suggested down below, it would be helpful if we had an essay or information page describing how it works and addressing good use cases and pitfalls/limitations. This could include a broader discussion of Clickstreams. —Myceteae‍🌈 (talk) 14:25, 11 June 2026 (UTC)

The underlying data is cut off at ten clickthroughs per page pair per month. So if there are nine clicks from A to C, and eleven from B to C, the data will only report the eleven B to C. If all pairs are below ten, then we get nothing at all. Unlike standard pageviews data, it seems to ignore any traffic through redirects (which can be significant for some pages) and is only available for 40 specific projects - I think this is the 40 largest WPs by traffic, but not 100% sure how they're selected.

I've just done a quick check on the clickstream dumps for recent months - roughly speaking in any given month about 80% of en.wiki page titles have data, but it's not consistent month on month. I would guess overall it is about 70% reliably having data and the rest being "...maybe, depending on recent traffic" (or recent page-moves, etc).

The flat cutoff of 10 pairs means that as we look at smaller wikis, they will have an increasingly higher dropout rate; one of the smallest datasets is for Malayalam, ml.wiki, and that has data for less than 30% of page titles in April. Andrew Gray (talk) 17:02, 11 June 2026 (UTC)

That clarified a few things for me, and I assume for a few other people. Personally, I am not concerned about other languages at the moment, once/if it becomes popular in English it will spread. As for what it misses, in the land of the blind..., as always. Thanks for the info. Yesterday, all my dreams... (talk) 20:08, 11 June 2026 (UTC)

I noticed that the list of developers is at the end of the page. Do you know any of them from your WMF days? If so, you could ask. Thanks Yesterday, all my dreams... (talk) 06:29, 11 June 2026 (UTC)

Yes, I have noticed that it works in some cases and not others. But I have realized several things with this tool, as is. So it is much better to have it as is rather not. As for other languages, let us start with the largest Wiki, English language. A journey of a thousand miles begins with ... one language. Thanks Yesterday, all my dreams... (talk) 20:10, 10 June 2026 (UTC)

Well, after the attention given to that tool due to my misguided attempts the powers that be seem to have made matters simple by totally disabling it. Sigh... Long live WMF... Yesterday, all my dreams... (talk) 20:16, 16 June 2026 (UTC)

Well that sucks! —Myceteae‍🌈 (talk) 20:33, 16 June 2026 (UTC)

You are right, of course. But I generally do not like to directly impose on other users, hence this post. Thanks. Yesterday, all my dreams... (talk) 20:15, 10 June 2026 (UTC)

Please see my response below. They disabled it. Let me get something to dry my tears now... Yesterday, all my dreams... (talk) 20:18, 16 June 2026 (UTC)

How do you know that it's intentionally disabled and not just not working for the moment/on an individual page? WhatamIdoing (talk) 22:08, 16 June 2026 (UTC)

Because pages such as Berkeley Timesharing System that originally drew me there no longer work. Neither do any others I tried today. But I have learned enough, and have had enough of this... Time to move on. Yesterday, all my dreams... (talk) 22:18, 16 June 2026 (UTC)

I don't think you should jump to conclusions like that. Services on Toolforge sometimes need to be restarted manually. WhatamIdoing (talk) 22:40, 16 June 2026 (UTC)

I did say seems to. May be it was an amazing coincidence that it died as soon as we started talking about it. Anyway, I will say no more, no more. Yesterday, all my dreams... (talk) 23:59, 16 June 2026 (UTC)

WMF has recently reduced its rate limits for some API calls. It is possible that publicising a tool might cause many people to try it out simultaneously and hit the newly lowered caps. Ideally, the frustrated tool would then explain why it is unhappy, but that may not always happen. Certes (talk) 10:25, 17 June 2026 (UTC)

Certes, as I said above, I shall make no further comment on WikiNav. But I do feel that I owe you a thank you for your initial comment on the help desk. So thank you, and I am done. Cheers. Yesterday, all my dreams... (talk) 15:18, 17 June 2026 (UTC)

It could be mentioned at pages such as Wikipedia:Disambiguation, since it's useful for identifying primary topics. WhatamIdoing (talk) 20:08, 10 June 2026 (UTC)

It is mentioned at Wikipedia:Disambiguation#Tools, under WP:DPT. It could perhaps be mentioned at Wikipedia:Requested moves (which already mentions Google Ngram and pageviews statistics). It might be useful to look at pages that link to Wikipedia:Pageview statistics and Wikipedia:Search engine test since WikiNav is useful in many of the same contexts as the tools described there. Wikipedia:Pageview statistics#External links does include a link to WikiNav but no description of the tool. —Myceteae‍🌈 (talk) 21:52, 10 June 2026 (UTC)

I learned about it by participating in a lot of RMs, where it is often used. I assume most editors learn about on- and off-wiki tools and resources in a piecemeal fashion by participating in discussions. I like the idea of spreading the word. I provide some ideas in reply above but otherwise I'm not sure what the best way to do this is. An essay, information page, or how-to guide that describes WikiNav and some of its pitfalls, à la Wikipedia:Search engine test and Wikipedia:Pageview statistics, may or may not increase visibility, but would be of benefit to the community. —Myceteae‍🌈 (talk) 21:58, 10 June 2026 (UTC)

Just chiming in to say thanks for mentioning the timeouts on the graphs and I appreciate the patience but these should hopefully be fixed now. Glad that you all are finding it useful! @WhatamIdoing is right that it's in a bit of a maintenance-mode state but we try to make fixes/improvements where we can. Isaac (WMF) (talk) 21:15, 17 June 2026 (UTC)

Thanks! It's working for me now :) —Myceteae‍🌈 (talk) 21:17, 17 June 2026 (UTC)

And let me add, I hope that WMF continues to support WikiNav. I find it quite useful and see it cited with some regularity at RM and other venues. —Myceteae‍🌈 (talk) 21:18, 17 June 2026 (UTC)

New User Tutorial

I would like to suggest adding some kind of relatively comprehensive tutorial for people who are interested in getting involved that shows where everything is. Simple things like how to make citations using the visual editor would go a long way. Something that guides through where to post and where to reply and simply what buttons to push would not only make a more welcoming environment and encourage people to register, but would also avoid mistakes and confusion. Simple ignorance can quickly escalate into conflict.

I don't know if I'm putting this in the right place right now or not because no such tutorial exists. I saw a suggestion that included this, but had no way (that I could see) to reply to it. Idacticus (talk) 06:46, 13 June 2026 (UTC)

To clarify, I'm talking about instructions on the user interface: not just what to do (and not do) but how to do it. Idacticus (talk) 06:52, 13 June 2026 (UTC)

We do have Help:Introduction, but beyond that, this seems like a good application for Help:Guided tours, which I suggested not too long ago (check it out!) Chaotic Enby (in solidarity · talk · contribs) 12:21, 13 June 2026 (UTC)

A couple of years ago I started to draft Wikipedia:WikiProject Editor Retention/Wikipedia rudiments, and I found some of the tutorials from Help:Introduction. I think they're pretty good for those looking more for a cookbook than a guided tour. The usual problem, of course, is how to get people interested in them to find them. isaacl (talk) 21:20, 13 June 2026 (UTC)

The guided tours are an absolutely brilliant idea. I hope we can get some experienced hands to write them. It's frustrating not knowing where any of the buttons are or what they do, and confusing trying to figure out how to use the various community and talk pages. I can't be the only person that gets discouraged from contributing when there's such a big learning curve. As soon as I'm confident with operating this setup, I'll write a tour. Once we have them written, it's a matter of implementing them for new users. Idacticus (talk) 00:49, 19 June 2026 (UTC)

Auto-citing a source using VisualEditor, small

This old gif doesn't show the up-to-date interface colors, but I think it will show you what you need to know about the most popular way to add a citation in the visual editor.

See also Help:VisualEditor if you want more (though I haven't looked at it in years, so I'm not sure how up to date it is). WhatamIdoing (talk) 05:32, 14 June 2026 (UTC)

That's a great one. Is there a place where I can find other helpful gifs like this? Idacticus (talk) 00:50, 19 June 2026 (UTC)

Neil Shah-Quinn (WMF) made a bunch of them when the visual editor was new. You can see the ones he made at c:User:Neil Shah-Quinn (WMF)/Visual editor.

I've heard that someone tried to make a more traditional video, but I don't think it ever got finished. WhatamIdoing (talk) 01:24, 19 June 2026 (UTC)

Naming Convention elimination

I have a draft RFC at User:BilledMammal/NC minimization project that I plan to open next month. The intent is to start address the ludicrous number of naming conventions we have, by proposing we demote twelve of the least impactful.

I'm opening an initial discussion here to determine whether there are any I've included that I am wrong about - that have to be kept - or if there are any I have missed that should be demoted. I have deliberately omitted some with low impact, as I prefer to address those with mergers in stage two of this project, if stage one is successful.

I've included my planned !votes in the draft, to make it clearer why I am proposing each of them. BilledMammal (talk) 09:27, 16 June 2026 (UTC)

My initial impression is that your analysis frequently treats explicitly linked references in RM discussions as the sole (or at least by far the most important) factor determining whether a convention is useful to maintain. That is an overly narrow view imo, as it neglects to account for cases where a naming convention guidance is uncontroversially followed to the extent that RMs have not been needed in the topic area. Thryduulf (talk) 11:47, 16 June 2026 (UTC)

I agree, this is overly narrow. I have had the thought that it would be interesting to review actual article titles against various NCs to see which are most often followed in practice. Even with this, there is a risk of making broad conclusions based on superficial analysis. Some topic areas are subject to more scrutiny than others. Also, some NCs or other guidelines may be frequently cited because they are controversial. Not every guideline that gets linked in an RM wins the argument. I'll have to look more closely at the proposal before offering additional opinions. I think there is something worth looking at here but I'm skeptical of the approach initially. —Myceteae‍🌈 (talk) 17:24, 16 June 2026 (UTC)

When there are very few references - just a couple a year, or in some cases far less than one a year - I do think that's the most important criteria, as it is strong evidence that the guideline is basically useless. It is possible that some of these naming conventions are uncontroversially followed to the extent that RMs have not been needed in the topic area, but that is why I've listed this here to help identify such conventions, and I also believe that if they are uncontroversially followed then in general WP:CONSISTENT should be sufficient.

With that said, I will make sure to beef up my evidence for each before opening the RFC. BilledMammal (talk) 06:54, 17 June 2026 (UTC)

I would do away with a lot more of these than are proposed, and rely on just one policy/guideline, but I also recognise that many people seem to want to have everything spelt out for them. Phil Bridger (talk) 19:01, 16 June 2026 (UTC)

I do share the reservations of Thryduulf and Myceteae, but looking these over I think it's safe to say that we can do some trimming here. We can get rid of ancient Romans, manuscripts, Norse mythology and operas and baseball players without it changing a thing. The one on Indian constituencies can be easily merged into WP:PLACE, and the ones on ice hockey and football in Australia can be merged into sports. I feel like more consideration is needed for the others though. ⹃Maltazarian ^{ᚾparley$\lor$investigateᛅ} 01:22, 17 June 2026 (UTC)

Regarding baseball players, by "get rid of" do you mean eliminating the separate page, but leaving the naming conventions in place? If so, I agree the content shouldn't be duplicated on multiple pages. I don't agree with the proposal in the draft RfC to demote the conventions themselves. My understanding is that they were all devised to handle real cases that came up, so they might as well be written down in one place rather than left behind in the mist of time. isaacl (talk) 01:41, 17 June 2026 (UTC)

Yeah I separated that one from the other sports ones because it's already duplicated on the general sports naming convention. ⹃Maltazarian ^{ᚾparley$\lor$investigateᛅ} 05:58, 17 June 2026 (UTC)

I think the relevant aspects of football in Australia are already covered at Wikipedia:Naming conventions (sportspeople)#Association football (soccer) and Wikipedia:Naming conventions (sportspeople)#Australian rules football? If you disagree, I'm open to converting that proposal into a straightforward merge rather than demotion. BilledMammal (talk) 06:56, 17 June 2026 (UTC)

Is there some issue created by having 80 naming convention pages that have the guideline tag on them that having 68 won't cause? Katzrockso (talk) 01:55, 17 June 2026 (UTC)

68 naming conventions is bad - it's WP:CREEP, WP:BURO, and makes it difficult for new (and even experienced) editors to participate - but 80 is worse. It's not a solution by itself, but it is the first stage of a project that I hope will make our naming conventions far more manageable. BilledMammal (talk) 06:57, 17 June 2026 (UTC)

Fair point. This would be a 15% reduction in NCs, which is meaningful even if one thinks there are still too many left. —Myceteae‍🌈 (talk) 16:24, 17 June 2026 (UTC)

What's the advantage to reducing these to essay status? I'm firmly in favour of reducing instruction creep so that guidelines become more readable and less imposing. But if anything, I think short naming conventions separated from Wikipedia:Article titles help in that way. I don't see the problem with them briefly codifying consensus, given we should be aiming towards standardisation as enwiki becomes more mature. Where there's consensus that can be codified, it should be codified as long as isn't creepy. If these guidelines don't reflect current editorial consensus, then that's a much greater issue. J947 ‡ ^edits 02:50, 17 June 2026 (UTC)

I think codifying any consensus contributes to WP:CREEP. In some cases it is necessary, but in most cases it isn't.

For example, Indian constituencies has been referenced once since creation, but we would be fine with it existing as an essay that is enforced by WP:CONSISTENT. BilledMammal (talk) 06:59, 17 June 2026 (UTC)

I just don't see what distinction it makes to demote to essay. This feels to me like putting too much faith in our bureaucracy. It's a sheet of paper that everybody follows anyhow, and the guideline status makes it clear that everybody does follow it. It's not that they're hard to understand either. In solidarity, Aaron Liu (talk) 16:39, 17 June 2026 (UTC)

This is a good point. Topic-specific naming conventions are mentioned multiple times throughout WP:AT, including the initial description of 'consistency' at WP:CRITERIA, and are nicely listed in the {{naming conventions}} infobox right at the top. Maybe some of the shortest, most straightforward, and least controversial NCs are some of the best. CREEP is a real concern but it can be tough to balance that with the value of concise, uncontroversial documentation of actual consensus. —Myceteae‍🌈 (talk) 16:21, 17 June 2026 (UTC)

I feel like this is a fair reservation in some cases, but some of the guidelines add little to nothing to other ones, and only our conventions much harder to parse for any new editor. We don't exactly distinguish between NCs that are constantly being applied with those that are applied once in a blue moon. We have to also consider new editors aren't really able to quickly identify and discard excess information in the guidelines in the way we in this discussion are able to. As they aren't familiar with NCs it will be far from obvious to new editors that some of the guidelines are just rewording other guidelines, and if they do realize it seems very similar they may think they're missing something because there isn't any reason to have a guideline that says the same thing another guideline does. It wastes time and contributes to unnecessary confusion. ⹃Maltazarian ^{ᚾparley$\lor$investigateᛅ} 17:29, 17 June 2026 (UTC)

I have no problem with eliminating conventions that are just repeating broader conventions, but for the rest, I don't see how those make conventions harder to parse. I'm also not sure how often newcomers would need up deal with naming conventions. Naming conventions seems like one of those areas where correcting newcomers doesn't drive them away thanks to how uncontroversial (following them, not making them) it is. In solidarity, Aaron Liu (talk) 22:33, 17 June 2026 (UTC)

Plus it doesn't matter that much if a new editor isn't initially aware of the non-controversial naming conventions for a given topic (unless they immediately start creating many articles at once). If it's an active area of interest, interested editors will move the article and let the new editor know ("hey, just letting you know for the next time"). Learning by example is very common. isaacl (talk) 22:42, 17 June 2026 (UTC)

I'm not as much concerned about new editors who don't know, it's more about the new editors who want to know and are trying to learn. ⹃Maltazarian ^{ᚾparley$\lor$investigateᛅ} 23:23, 17 June 2026 (UTC)

But I think most do learn by example, either by stumbling across WP:RM or when their preferred title is changed or disputed at AFC or by someone boldly moving a page or some other process or discussion. Or they start reading about policies and guidelines first, before encountering NCs "in the wild". In that case they will either encounter WP:Article titles first, where NCs are referenced multiple times and listed in the infobox. Or they will first stumble on a specific NC, where they will see the same infobox listing all the other NCs and the Article titles policy. On one hand, I do think the sheer number of policies and guidelines is intimidating and that newbies are prone to getting discouraged when all their early edits are met with a deluge of WP:UPPERCASE. On the other hand, NCs are a fairly "contained" family of guidelines and so if the goal is just help newbies learn about them, the present organization would seem to accomplish this. And a newbie may still feel discouraged and overwhelmed by links to WP:CONSISTENT and a dozen other articles that illustrate a pattern that used to be codified in a naming convention. —Myceteae‍🌈 (talk) 23:50, 17 June 2026 (UTC)

Regarding using uppercase jargon: I just get disappointed at the extent that all-caps jargon terms are used. I appreciate there are times when it provides significant expressive conciseness, but the vast majority of the time, it doesn't. Some editors have expressed the view that learning the jargon is part of joining the community, but I think other forms of initiation are more worthwhile to promote. Unfortunately, most of the community seems to feel that using jargon is a net benefit. isaacl (talk) 00:52, 18 June 2026 (UTC)

Sure, but getting rid of some of the wholly unnecessary ones feels like a net positive considering we're not getting any use out of them.

As for the comment about uppercase jargon: yes, it is true, it takes some getting used to, but in my personal experience it's alright as long as there are wikilinks to the thing being referenced. ⹃Maltazarian ^{ᚾparley$\lor$investigateᛅ} 03:24, 18 June 2026 (UTC)

Yeah, I didn't mean to digress into the pros and cons of UPPERCASE so much an engage with the impact to new editors particularly. I'm open to the idea of trimming the list of NCs but I'm not on board with the proposal in its current state. Some could probably be condensed with others but I'm not sure there's a "home" for all of them. I see an important distinction between those which are redundant or WP:CREEPy and those which may not reflect consensus. If we "downgrade" some of them to advice pages or mark them as historical, that may suggest they no longer reflect consensus, which may lead to confusion or open up fresh disputes about long settled titles. —Myceteae‍🌈 (talk) 03:44, 18 June 2026 (UTC)

To be clear I have reservations towards parts of the proposal too and do not wish to see all of those NCs demoted to essay status. ⹃Maltazarian ^{ᚾparley$\lor$investigateᛅ} 03:48, 18 June 2026 (UTC)

Which ones do you think should not be demoted? I'm open to removing some from the RfC. BilledMammal (talk) 02:49, 24 June 2026 (UTC)

I was thinking over why the Manual of Style has historically been so contentious while these naming conventions (as far as I know) generally haven't been and I think maybe the missing element is "applicability". Naming conventions for ancient Romans aren't applicable to most editors, who don't have to know what they are or even that there is a naming convention. If you're one of the few editors writing new articles about ancient Romans, you'll probably find your way to the others pretty quickly, and everyone will have some background knowledge about why the conventions are justified. On the other hand, if some editors start revising MOS:DASH, the guidance there is applicable to just about any editor, and you need to be cognizant of it to understand why Mexican–American War doesn't seem consistent with Franco-Prussian War. I think WP:CREEP carries much more weight in the latter situation than in the former. Choess (talk) 01:02, 19 June 2026 (UTC)

This is a good point, and articulates something I had been tossing around in my head but hadn't quite pinned down. —Myceteae‍🌈 (talk) 03:33, 20 June 2026 (UTC)

I think we need to do more to connect new users to the corresponding groups of editors with common shared interests, so they can help guide people on established norms. I think the best bet is for the auto-assigned mentor to point users to the right discussion pages. But how to get communication going between mentors and their assigned users has so far been a hard problem; the question to mentor ratio has been reportedly very low. Hopefully any users who have trouble finding the right guidance page and aren't asking their mentor will still create new pages and then be able to learn by example. isaacl (talk) 00:43, 18 June 2026 (UTC)

A feature request: Syncing the cursor between Source Editor and Preview window (like Chrome Inspect)

Hi everyone,

I had a thought while going back into editing (after a while i was absent) some long articles recently.

Right now, when using the split-screen/side-by-side view with the Source Editor and Live Preview, navigating back and forth, while trying to pin-point an exact location can get a bit frustrating. If I'm looking at a specific paragraph or an infobox in the preview side, I have to manually scroll and hunt through sometimes hundreds of lines of wikitext to find where it actually sits in the code.

I was wondering if it's possible to implement a cursor-level synchronization, similar to how the Chrome Developer Console works when you use "Inspect Element".

The best option would be if it  work both ways:

If I click on a paragraph or a citation in the Live Preview, the cursor in the Source Editor would instantly jump to that same line in the code or highlight it some how

And if I place my cursor on a line of the wikitext, that part should automatically scroll into view and maybe also get a highlight in the preview window.

I think this might prevent a lot of small errors and would be very helpful for editors that go through large amounts of material while editing and dealing with big templates, infoboxes, or massive articles where it's super easy to get lost and confused in the code.

Has this been discussed or proposed before? I went over the archives but couldn't find any prior similar suggestions, or maybe its already there with a gadget or something similar that im not yet aware of? Would love to hear your thoughts Happypenguins82 (talk) 13:15, 17 June 2026 (UTC)

When I'm jumping between a preview and the source code I usually use ctrl+F on a portion of prose without a wikilink. A few words is usually unique within a particular article. CMD (talk) 13:44, 17 June 2026 (UTC)

I'm actually doing the exact same thing :)

It is a lifesaver, but it still feels a bit clumsy and slows down the flow. It gets especially confusing when you're dealing with really big articles, or when you're trying to find the exact spot inside big infoboxes or long citation templates where text search is a bit more of a headache.

That's why I thought an automated function would be rally useful… but naturally only if its technically achievable, it would save all those extra steps and just make everything much much smoother.Happypenguins82 (talk) 15:05, 17 June 2026 (UTC)

I generally use the same method, but agree that an improvement on those lines would be very useful. Phil Bridger (talk) 18:17, 17 June 2026 (UTC)

So happy you liked it! It could relieve a lot of strained editors' eyes Happypenguins82 (talk)

Happypenguins82 (talk) 19:38, 17 June 2026 (UTC)

...and my eyes are more strained than most people's. Phil Bridger (talk) 19:54, 17 June 2026 (UTC)

Its happypenguins82 to the rescue... that, and dark mode ;) (for the time being)

Happypenguins82 (talk) 21:56, 17 June 2026 (UTC)

Since I'm kinda new and still a wiki toddler, i have to ask... is there any thing i should do? or maybe place the request somewhere else? Happypenguins82 (talk) 10:42, 22 June 2026 (UTC)

I think that will require work by the mw:Editing team. You could leave a note on @PPelberg (WMF)'s talk page and see if he would like you to write an official feature request on phab:. WhatamIdoing (talk) 01:50, 24 June 2026 (UTC)

Thank you for the kind guidance, i'll do that :) Happypenguins82 (talk) Happypenguins82 (talk) 18:41, 24 June 2026 (UTC)

Feedback on communication support tool

Our tool is a lightweight user-facing early warning system which alerts users when conversations are getting heated, based on research which shows that giving users a gentle nudge can help de-escalate tense conversations. The tool will provide an estimate of whether or not the discussion looks to be getting tense (i.e., likely to deteriorate into violations of the Wikipedia:No personal attacks policy) Since last October, we have talked with several members of the community (some which are collaborators on the project Barkeep49 L235) to refine this tool, and we’re interested in launching a larger user study. Through participatory design, taking into account ongoing discussions on other tools like Tone Check, we have designed the tool to empower the user, while leaving all decisions in their hands: the tool does not make any edits and does not suggest text. (We are seeking more contributors who would be willing to test these tools long-term!)

Information page: https://en.wikipedia.org/wiki/User:Laerdon/ConvoCompass Would be excited to discuss with anyone interested in this thread; we envision ConvoWizard as a prototype for a future user-facing tool that editors who frequently engage in discussions could include in their everyday workflow, and are curious as to how this might fit in alongside the many other tools that editors already use. Laerdon (talk) 16:10, 17 June 2026 (UTC)

@Laerdon, who is "we"? WhatamIdoing (talk) 21:56, 24 June 2026 (UTC)

Referring to my collaborators on the Opportunities for Supporting Community-Scale Communication project; @Cristian at CornellNLP and I are researchers at Cornell University and we have worked on this tool with the two users mentioned in the post. Laerdon (talk) 23:28, 24 June 2026 (UTC)

Religion in Infobox country

There is a discussion at Template talk:Infobox country on the Religion parameter in that infobox. Rolluik (talk) 15:58, 19 June 2026 (UTC)

 Courtesy link: Template talk:Infobox country § Religion in Infobox country —Myceteae‍🌈 (talk) 02:40, 20 June 2026 (UTC)

Glossary title issue

I've noticed that many glossary articles have the problem of beginning the title with "Glossary of" but also including "terms" or "terminology" in the title. Such examples currently include:

• Glossary of professional wrestling terms
• Glossary of music terminology
• Glossary of botanical terms
• Glossary of international relations terms

and so on. Including wording such as "terms" or "terminology" in the case of these articles not only makes the titles longer (unideal per Wikipedia:CONCISE), but is also poor English. A glossary is by definition already a list of terms or terminology, so adding such words is completely redundant. This is the equivalent of eg. titling a map of Germany as a "map of German places". If the above titles were corrected, they would read:

• Glossary of professional wrestling
• Glossary of music
• Glossary of botany
• Glossary of international relations

However, I am unsure on how to perform such a mass correction, as it appears that many tens of articles are named in this way (based on my searches). I would like to know other people's thoughts on these titles and if/how they can be changed. ―Howard • 🌽³³ 23:11, 23 June 2026 (UTC)

TIL that there is/was a proposal to create a MOS/guideline on this: Wikipedia:Manual of Style/Glossaries. It appears to have died. My first thought is that "Glossary of X terms" is perfectly acceptable. Strict adherence to WP:CONCISE would call for the shorter titles, and nothing is really lost by dropping terms, but I'm not sure this is an improvement. If there are tens of thousands of articles like this it reflects a great deal of WP:EDITCON although it's possible the majority of these are just following suit per WP:CONSISTENCY. I did a Google Books search for "glossary of" and restricted publications to the 21st century. On the first four pages of results, 25/40 (62.5%) of titles included the word terms. None of the titles on page five did, so 25/50 (50%) of the first 50 titles included terms. Several that omitted terms included something else like Glossary of Standards in International Law. Thus, it is common off-wiki to title something a Glossary of Terms and it is not an unreasonable standard for us to adopt. tl;dr Shortening these is not an improvement but I don't have a stronger argument against concision here. —Myceteae‍🌈 (talk) 23:44, 23 June 2026 (UTC)

Very vague question- possible new articles

What would the criteria be for a new emoji article? There are quite a few, and I think a great number of them have okay coverage, but would there be specific requirements? _{In solidarity} Wikipedian12512 (Talking is fine | contribs) 00:31, 24 June 2026 (UTC)

• We should stick with GNG as well as WP:PAGEDECIDE considerations as to whether there is enough to say about a single emoji. —Myceteae‍🌈 (talk) 00:45, 24 June 2026 (UTC)

  If all of the emoji encyclopaedias count, then I think it could work. Either they’re tertiary sources, in which case we can find the secondary sources, or they’re secondary sources. _{In solidarity} Wikipedian12512 (Talking is fine | contribs) 01:01, 24 June 2026 (UTC)

  I doubt Emojipedia is a reliable source. Just compiling all the information from sources like that would likely run afoul of WP:PAGEDECIDE. To be clear, I don't think we should have lots more articles on individual emojis. Such articles should be held to the fairly high GNG standards. —Myceteae‍🌈 (talk) 01:04, 24 June 2026 (UTC)

We also had a big fight over emojis a couple of years ago, e.g., about whether 🌈 should redirect to Rainbow or to List of emojis (answer: usually to Rainbow). If you want either to create or to delete such pages, it would probably be worth your time to find that discussion. WhatamIdoing (talk) 01:57, 24 June 2026 (UTC)

My answer for that: When people are using an emoji on a Wikipedia search, they want an article on the emoji, so probably list of emojis (or, as I like to say, emojae). _{In solidarity} Wikipedian12512 (Talking is fine | contribs) 02:00, 24 June 2026 (UTC)

Our typical approach is documented at WP:REMOJI. Note that this is nearly a description of common outcomes at WP:RFD, not a police or guideline. The linked 2023 RFC (also available via the fun shortcut WP:😃↪️📊2️⃣) is actually rather inconclusive. I'm quite active at RFD and I find the description at REMOJI accurate but the discussions are sometimes lengthy with multiple alternative targets suggested. There was a discussion not too long ago where the idea of revisiting our approach was raised but was unsuccessful. I'm not thrilled with our current approach, and think it could be changed, but I prefer it to creating a massive amount of articles about individual emojis. I find it actually quite difficult to guess what most people want when searching an emoji. 🌈 maps cleanly to Rainbow and there's not enough to say about the emoji itself to write a standalone article. Many of the smileys are ambiguous but some like 😂 have enough to support an article. We have examples like ❤️ which redirects appropriately to Hearts in Unicode, an article covering many different symbols, or 🫈 which maps to a brief article section specific to the emoji. —Myceteae‍🌈 (talk) 02:16, 24 June 2026 (UTC)

@Wikipedian12512, I don't know what "people" want, but when I search for an emoji, that's not what I want. Instead, I want to find out what that little tiny blur actually is. If you live long enough, you might find that you do that, too. WhatamIdoing (talk) 21:58, 24 June 2026 (UTC)

Yeah, we spend a lot of time trying to divine "what people want" when they search these. If anyone wants to see how these play out in real time, Wikipedia:Redirects for discussion/Log/2026 June 24#🌊 is live. —Myceteae‍🌈 (talk) 22:15, 24 June 2026 (UTC)

Hmmm… That’s a point I hadn’t considered. Seeing as that I already need absurdly strong glasses (and they’re still not powerful enough), I really do not hope that happens. I’m nearsighted enough where looking at a book 3 inches away without glasses is about the point where I both become cross eyed, and stop seeing a blank page. _{In solidarity} Wikipedian12512 (Talking is fine | contribs) 22:16, 24 June 2026 (UTC)

Limits for expanded master's thesis RS

I have wanted to see master's theses allowed more broadly for a while now, and I have a couple of arguments in favor that I can make. Before I started working on a draft to be reviewed by more experienced editors, however, I wanted to run it by the community at large.

What are the common arguments against MS/MA thesis use? What are some arguments that might not be obvious?

Pietrus1 (talk) 01:41, 24 June 2026 (UTC)

There was a lengthy discussion on this here quite recently: Wikipedia:Village pump (idea lab)/Archive 80#h-Potential RfC around Master thesis reliability-20260507050000. The last comment was made less than a month ago. It's worth a read. I won't attempt to summarize it all but I'll say this: While there was some support, my read is that a majority of editors were either opposed or had significant reservations about how exactly we would expand the use case. —Myceteae‍🌈 (talk) 01:51, 24 June 2026 (UTC)

The linked thread links to several other fairly recent discussions on the topic. —Myceteae‍🌈 (talk) 01:53, 24 June 2026 (UTC)

Thanks for linking me that :)

Pietrus1 (talk) 01:58, 24 June 2026 (UTC)

Happy reading! —Myceteae‍🌈 (talk) 02:29, 24 June 2026 (UTC)