Wikipedia talk:Growth Team features

Protected edit request on 2 May 2026

Change User:Enbi's status to pause per user request on wikimedia discord: can someone remove me from the mentorship list temporarily? i cant access any wikimedia sites because my ip address seems to have been blocked by what i think is a bug with the wmf's new anti-scraping rate limits. [...] just a pause until i can get unblocked nhals8 (rats in the house of the dead) 00:29, 2 May 2026 (UTC)

I have marked Enbi as away. When they have access to Wikipedia again they can reset the "away" status by visting Special:MentorDashboard * Pppery * _{it has begun...} 00:33, 2 May 2026 (UTC)

As a reminder, any admin can use Special:ManageMentors to change a mentor's parameters. It is sometimes easier to use than editing MediaWiki:GrowthMentors.json. :) Trizek_(WMF) (talk) 13:08, 19 May 2026 (UTC)

Copy edit tasks are mostly peacock or undersourced articles

I originally posted on the related mediawiki talk page about my experience with the homepage and suggested edits. I'll quote the main part here:

I'm not a brand new editor, but I'm not particularly experienced. I thought I would try the user homepage to get some experience doing basic copyediting and such. However, I've noticed that most if not all the articles suggested to me are not tagged with a copyediting template, but are tagged as having promotional material or puffery, and often as having not enough citations. As a result, I haven't really felt confident editing any of these articles, as copyediting seems to be the least of their problems. I feel that in order to actually make any progress on the article, I'd need to look for sources and determine what's actually supported—valuable work, but not approachable for a beginner, and not something I can do as a quick task to make a small improvement.

There are lots of articles needing copyediting as seen here, but these do not seem to show up in the suggestions on the user homepage. From my perspective, the most approachable articles would be ones where there there is a need for copyediting, but there is no dispute about the content, i.e. no tags for "peacock", "tone", or "more citations needed". I know there are copyediting drives, so maybe including those would interfere, but as it is now, I find the category much more useful in finding articles I can work on than the homepage is.

As an example, one of the articles recommended to me for copy edits is Laura Chenel, an article which appears to be primarily promotional and goes into great detail about the history of her cheese business, including the exact menu items the cheese was included in at restaurants, and which contains exactly two sentences about her personal life outside of cheese. Copy editing, even for tone, does not feel like a worthwhile endeavor on such an article.

After looking at the configuration page, I've noticed a couple things. The first is that Category:Candidates for speedy deletion and Category:Articles for deletion are not applied as filters for the copyedit task as they are for other tasks. Another is that the whitelisted templates include {{Copy edit section}} but not {{Copy edit}}, which may explain why I get so few suggestions.

But I think the bigger issue is getting recommended articles which would not benefit from copyediting because they contain unsourced, unencyclopedic material which would be better resolved by removal or by doing research to find sources (which is a much more involved task). Perhaps adding Category:All articles lacking reliable references and Category:Articles with topics of unclear notability to the "blacklist" would help focus on articles which are already well sourced and encyclopedic, and just need cleaning up? Maybe it's worth considering removing the peacocking template as a filter, or making it into a separate, more challenging task, just because in my experience it's less often a matter of tone and more often a matter of what the sources can actually support for a more specific statement, which is difficult for a beginner (moreso if no inline source is provided to start with).

Sorry for the long message. Wanted to share my experience and maybe generate some ideas for improvement. I think it's a great tool with a lot of potential, and I can see myself using it if the articles it suggests are more workable. dylansan (talk) 16:53, 6 May 2026 (UTC)

@Trizek (WMF), can we please get the ability to rename this task? I was complaining about this as a new editor in 2021. -- asilvering (talk) 04:26, 7 May 2026 (UTC)

What would you rename it to? It might help, but I think the issue is more about combining basic copy editing for grammar and spelling with fixing peacock prose, all in one task.

As a clearer example of the problem, here's the article Japan Automotive Hall of Fame. It currently has a {{multiple issues}} template which includes {{update}} and {{refimprove}}. In the inductees section there is a {{peacock section}} template. So nothing indicating there are substantial problems with the grammar or spelling or clarity. But if you look at the page history, 9 of the last 10 revisions have the "Newcomer task: copyedit" tag, and involve changes to grammar and punctuation, and none of them address the peacock issue at all. Which means the peacock tag remains on the page and more and more newcomers are directed to copy edit it.

Fixing promotional or sensational language is part of copy editing in general, but I think on Wikipedia it may be too distinct a task. Because of Wikipedia's reliance on verifiable sources, fixing puffery requires finding what sources actually say and changing the prose to say something factual, or removing the problem text entirely if it's not supported. I don't think this is what users are expecting to have to do when they use these tasks.

As a final point, while the guidance for the task includes a description of puffery, the advice on how to fix it is conflicting:

You can also rewrite sentences so that they do not contain opinions. Wikipedia content should be neutral, clear, and encyclopedic. However, be careful not to change the facts in the sentence.

Her immense talent marked her as a rising star in the industry.

This sentence contains an opinion that should be removed.

This instruction indicates that opinions should be rewritten without changing the facts, but then says that this particular example should just be removed entirely. Does that mean all opinions or flowery sentences should just be removed? Or only if there's no other facts in the sentence? There's no suggestion of finding facts which would better illustrate the claim, as described in MOS:PEACOCK. dylansan (talk) 11:52, 11 May 2026 (UTC)

Thanks for sharing such detailed feedback, @Dylansan! The main point I hear from what you're saying (and please let me know if I'm misinterpreting) is that many of the articles you're encountering in the copy editing task have promotionalism issues, which is a more core concern that needs to be addressed before it makes sense to copy edit them, and also not a task as well-suited to newcomers. That both makes sense to me and also resonates with my own experience using the feature.

One piece of context it may be helpful to have is that the copyedit task is one of the earliest features the Growth team developed. We used it as a simple proof-of-concept for the idea of newcomer tasks, but we found that many newcomers sought more guidance around how to make a productive edit, which led us to develop the suite of structured tasks, which is where much of our attention has been more recently. Nevertheless, we still maintain the copyedit task.

The configuration page you found is designed to be adjustable by the community. The changes you've proposed sound reasonable to me, and any administrator (including @Asilvering) can make them.

The help panel guidance is also configurable; you can find the strings you're referencing at MediaWiki:growthexperiments-help-panel-suggestededits-tips-vector-visualeditor-copyedit-main-rules2, MediaWiki:growthexperiments-help-panel-suggestededits-tips-vector-visualeditor-copyedit-example-rules2, and MediaWiki:growthexperiments-help-panel-suggestededits-tips-vector-visualeditor-copyedit-text-rules2.

Lastly, @Asilvering, it'd also be helpful to me if you could say a bit more about how renaming the task might help, as I'm also not fully following how it relates to Dylansan's points. If you can find the link to your 2021 comment I'd also be happy to read through that.

Cheers, Sdkb‑WMF ^talk 04:35, 19 May 2026 (UTC)

As Sdkb said, that copyedit task is a basic proof of concept that never really evolved. Plus, it was created to fit all wikis, where the meaning of the "copy edit" task could vary: at French Wikipedia the interwiki linked template is about fixing spelling and grammar, not about style, cohesion and tone.

Besides renaming the task, what would be the ideal solution? Imagine that you select an article under Copy edit, open it, and see prompts to review specific elements that are highlighted? Would it work? Trizek_(WMF) (talk) 13:07, 19 May 2026 (UTC)

Right now I think adding the {{copy edit}} template and removing the {{peacock}} template from the copyedit suggested edits configuration would at least give more copy editing tasks without so many tricky ones. The number of {{copy edit}} articles is way larger than the number of {{copy edit section}} articles (by my count there are only 21 total articles with the latter!), so I expect just having more to choose from would help prevent the same articles getting tons of users doing the same task over and over. By the way, the copyedit newcomer task is also missing the CSD and AfD checks that prevent those articles being suggested. Regarding renaming, perhaps moving the peacock articles to a new suggested edits (or structured task) dedicated to reviewing sources and editing the article to match what the sources say (either by rephrasing, or by removing unsourced claims)? dylansan (talk) 15:00, 19 May 2026 (UTC)

It's this one: many of the articles you're encountering in the copy editing task have promotionalism issues, which is a more core concern that needs to be addressed before it makes sense to copy edit them. Basically, anyone who already knows what "copy editing" is gets to this task expecting something relatively straightforward, and that's not what we give them. And it can't be what we give them - easy grammar-fixing copy edits have gone the way of the dodo on en-wiki thanks to a small army of gnomes and AWB, and editors tend to only slap maintenance tags on things they don't want to touch, so the really simple stuff is fixed rather than tagged. We simply don't have a reasonable analogue of the task @Trizek (WMF) is talking about. If we were able to customize these tag-based tasks, with different titles and descriptions (being able to change the difficulty level would also be great), communities could aim newbies at tags that aren't so overwhelming to handle, or at least give them less faulty advertising. -- asilvering (talk) 21:20, 19 May 2026 (UTC)

Thanks for that clarification — I like the idea you're proposing of a flexible system where communities are able to create an arbitrary number of maintenance template–derived tasks, with custom titles/instructions/difficulty levels for each! I'll inquire with the team to get a better sense of how feasible it might be to build that.

In the meantime, I'm wondering how you feel about the changes Dylansan is proposing. Do you think it'd be a net positive to implement those in the configuration settings? (If so, you have the bit to go ahead and do it.)

Regarding the state of copy editing on English Wikipedia, I definitely agree that gnomes/AWB have had a remarkable impact and picked off a lot of lower-hanging fruit, but I'd push back a bit against the idea that it's gone totally extinct. My personal experience has been that this may be true on more-visible articles, but as soon as I start going to obscure (or non-Western) topics I've found a lot of basic editing to be done. Sometimes the articles aren't tagged, but enough of them are (just by editors who weren't interested in fixing them, not since the fixes would be hard) that I think there's a corpus out there. Does that resonate?

Cheers, Sdkb‑WMF ^talk 14:36, 20 May 2026 (UTC)

I have a feeling that we removed {{copy edit}} from the list for a reason, but can't recall it at the moment. I do notice that the tracking category presently holds 1744 items, but there are north of 2200 transclusions of the template itself, which may have something to do with it? -- asilvering (talk) 19:11, 20 May 2026 (UTC)

It's transcluded on a lot of User pages and drafts, which might explain the difference you're seeing in numbers. Limiting the search to article space it seems to match up with ~1750 though I didn't do an exact count. I assume these tasks already limit to article space? This discussion seems to indicate the {{copyedit}} template may have been removed because many of the articles were either fine, or a disaster, so it wasn't always clear what work was needed. Personally, I think that would be preferable to the current situation, as at least the tag could be removed on articles that no longer need work (which would reduce the backlog). If it's the case that these suggested edits are fundamentally too difficult for users, and structured tasks work better, perhaps it's worth considering disabling this feature, as it currently seems to lead to a lot of users putting unnecessary effort into a small collection of articles with no resolution. dylansan (talk) 11:29, 21 May 2026 (UTC)

I did some sleuthing. Apparently the copy editing tags were removed very early on in the feature's development (before it was deployed) because of concern that they might interfere with the WP:GOCE's work (cc @Jonesey95). {{copy edit section}} was added back by Pppery in 2024, and I don't think anyone noticed that it was a reversal of an earlier decision. I'd be interested to hear whether interference with GOCE is still a concern. Sdkb‑WMF ^talk 23:18, 22 May 2026 (UTC)

The other thing it might be helpful for me to share is a bit more about the relationship between the Copy Edit task and the Revise Tone task. As I mentioned before, Copy Edit was an early, comparatively unstructured task. The Revise Tone task, which we developed much more recently, also points editors toward articles with potential peacock language. However, to address the issue you observed, @Dylansan, of newcomers struggling with how to make fixes, it provides more structure/guidance, pointing editors to specific passages. We are currently running an A/B test of it here (following this discussion) and in a few other languages, and we'll have results of that ready to share quite soon. If it ultimately proves a more effective task than Copy Editing, we may consider replacing Copy Editing with it. I hope that helps shed some light on our thinking/strategy, and as always we're very interested to hear your views! Cheers, Sdkb‑WMF ^talk 23:19, 22 May 2026 (UTC)

Thanks for digging into that, Sdkb. I'll wait for a GOCE response before messing with the tag list. What I suspect will happen is that we'll soon get to a list that's too short for newbies to find much to do, causing a ridiculous flurry of edits on anything so tagged - ie, the problem we had with the links task before the ML-driven version. Which is a good problem to have, all things considered. -- In solidarity, asilvering (talk) 23:47, 22 May 2026 (UTC)

Ah, seeing @Trizek (WMF)'s response to the thread below, that is indeed exactly what will happen, haha. In solidarity, asilvering (talk) 23:49, 22 May 2026 (UTC)

The WP:GOCE, of which I am an emeritus coordinator and a previous long-time coordinator, has a good handle on the backlog of articles tagged with {{copy edit}} and related templates ({{copy edit section}}, {{copy edit inline}}, {{inappropriate person}}, {{cleanup tense}}, and their redirects), which all add articles to Category:All Wikipedia articles needing copy edit. Meanwhile, {{peacock}} does not indicate a need for copy editing, and we sometimes remove or comment out the copy edit template on such articles, especially if they are poorly referenced, because it makes little sense to spend copy editing effort on puffery and unsourced prose that would be better removed or sourced. The GOCE's remit does not include adding sources, although some copy editors add those editing tasks to the articles they edit. Similarly, {{Verify spelling}} and {{Sentence fragment}} categorize articles in the "clarify" category, not the copy editing category, so those should not lead to copy editing recommendations for new editors. One of the templates listed at the config page, {{awkward}}, is a redirect, which does not make sense. It is probably counterproductive to have new editors copy editing articles when the GOCE is doing fine, and the configuration is a mess. My gut recommendation would be to disable the task entirely, or to have Miniapolis, an admin who is a long-time GOCE coordinator, reconfigure the templates that generate copy edit tasks. – Jonesey95 (talk) 03:28, 24 May 2026 (UTC)

I'll have to learn how to do that. Jonesey95 is better at template editing than I am. In solidarity, Miniapolis 13:17, 10 June 2026 (UTC)

Miniapolis, it looks like this is not a template editing issue and should not be difficult. Go to Special:CommunityConfiguration/GrowthSuggestedEdits to modify the list of templates that trigger this "Copyedit" newcomer task. I think the consensus is to remove {{awkward}} (a redirect) as well as {{peacock}}, {{sentence fragment}}, {{Colloquialism}}, {{Expand acronym}}, and {{Verify spelling}}, none of which are copy editing tasks. I recommend adding the missing {{Copy edit inline}}. When you have removed those templates from the "Copyedit" section, scroll to the very bottom of the page and click "Save changes". A little scary, but we trusted you with the admin mop; I believe in you. – Jonesey95 (talk) 14:37, 10 June 2026 (UTC)

Thanks for the vote of confidence, Jonesey95, and for the instructions :-). I'll get to it ASAP, but am busy IRL at the moment.In solidarity, Miniapolis 15:08, 10 June 2026 (UTC)

Done, with thanks again for the guidance. In solidarity, Miniapolis 22:41, 10 June 2026 (UTC)

The only thing I would add to this is adding "Candidates for speedy deletion" and "Articles for deletion" to the "Articles containing categories defined here will not be shown to users as tasks for this task type." box, to match the other tasks. dylansan (talk) 18:09, 10 June 2026 (UTC)

I would strongly consider adding {{copy edit}} to the list. {{copy edit inline}} is only transcluded on 169 pages, so will not significantly add to the very small pool of articles being suggested to these new users (a pool which will shrink with the removal of the other templates you mentioned). {{copy edit}} appears on over 1700 articles and would hopefully provide much more variety, so users aren't constantly editing the same pages without them being resolved. dylansan (talk) 18:17, 10 June 2026 (UTC)

Done. In solidarity, Miniapolis 22:41, 10 June 2026 (UTC)

+1 toward what Jonesey95 has said. And I can confirm I had no idea of the prior history when I made that 2024 edit. * Pppery * _{in solidarity} 03:36, 24 May 2026 (UTC)

This discussion seemed to end in a place I wasn't expecting. I am not part of WP:GOCE, but it seems counterproductive to me to avoid bringing new editors into the mix and trying to teach them how to do copy editing and other tasks, just because a group of editors has a good handle on it. I acknowledge that they will not have the same level of experience as long-time GOCE editors, but it seems like every other initiative on Wikipedia right now is about bringing in new editors and giving them the skills to contribute to the project in the long-term. This seems like a great opportunity to do so. Even if things are okay right now, we can't rely on the current batch of GOCE editors forever, without bringing in new people. In fact, tasks like these (or structured tasks), could even be a way to introduce people to GOCE as a way to get more involved.

It doesn't look like the configuration has been changed since this discussion. Neither to deactivate it, nor to add the {{copyedit}} template or fix the missing filter to prevent AfDs from getting recommended. From what I can see, the same articles are still getting lots of edits without necessarily improving the article significantly. I suppose there may not be consensus to add to the filter, nor to deactivate the task, but it does seem like there's consensus that it's not working as intended currently due to the small pool of articles it's pulling from. How could we arrive at a consensus here and improve this task? Do others agree that newcomers should not be given tasks that overlap with other projects?

I think the AfD filters could be added now without further discussion, as that is clearly a simple oversight. dylansan (talk) 11:49, 9 June 2026 (UTC)

I very much agree with it seems counterproductive to me to avoid bringing new editors into the mix and trying to teach them how to do copy editing and other tasks, just because a group of editors has a good handle on it, and I don't quite follow It is probably counterproductive to have new editors copy editing articles when the GOCE is doing fine, and the configuration is a mess. Speaking only for myself, I was waiting to see if Miniapolis had something to say before I went digging around in the community config. @Miniapolis, here's a re-ping in case you intended to reply earlier and just forgot about it. Of course, feel free to ignore and we can sort ourselves out. In solidarity, asilvering (talk) 11:49, 10 June 2026 (UTC)

Just offering a recently new user perspective: I started out doing copyedit newcomer tasks in March 2026. The first one I got was Warbling antbird which...didn't sound too good, and after some investigation was in large part LLM including a big table that was completely hallucinated. And also was probably redundant with the article for its genus. Which also had that same LLM generated table. So my newcomer task progressed from spelling and grammar to source checking to wholesale revision to successfully proposing and carrying out a merge via AfD. Feeling, at every single step, that I didn't know what I was doing! I tried doing a few more copyedits but it stopped showing me those and started insisting on article updates, which by that time I had a realistic view on how much work it would be.

I didn't bounce off this but I can sure see how others might.

About that article update task: I am currently working on a case at AINB where someone worked their way through a pile of update new user tasks, putting LLM generated sources into a long list of articles: it wasn't caught right away and is now requiring tedious hand correction. (It is amazing how consistently bad the sources are. I don't blame the user: they were brand new, and no one seems to have told them this was a bad idea until it was too late.) We see this pretty often at AINB and the cost to fix it is high. I don't know if this is properly part of the discussion here, but there's definitely a downside to the newcomer tasks. Could they please warn the editor about the LLM policy? M kuhner (talk) 19:19, 22 June 2026 (UTC)

Gary Hooper (Paralympian)

How come this article was subject to a newcomer task in the first place despite not having any relevant maintenance templates that I can find? Also, why did it get another newcomer edit despite my addition of {{No newcomer task}}? To be fair, the second edit was helpful in the end. I was going to ask about it at Template talk:No newcomer task but a comment there led me here. Graham87 (talk) 15:09, 18 May 2026 (UTC)

Hello Graham

As the number of Copyedit tasks was low at English Wikipedia, we looked for a way to expand this number. Meanwhile, Edit check introduced an in-context guidance about revising the tone of an edit, based on a prediction model. As a consequence, we started an experiment, to combine the model that identifies non neutral terms and the Copyedit task. We are waiting for more data, but the example you found proves that this user understood what was expected.

As we used a different selection system to populate the queue of tasks, the template {{no newcomer task}} wasn't taken into consideration. Sorry, we forgot about it. Thanks to your feedback, we will create a proper community configuration for the Revise Tone task (T426690). Trizek_(WMF) (talk) 13:00, 19 May 2026 (UTC)

Username suggestion for account creation?

The Growth team is currently working on the account creation process, as creating an account is the very first step to joining Wikipedia. The team plans to add a feature to the account creation process that suggests automatically generated, available usernames to users, and allows them to choose from among them. This initiative aims to reduce the difficulties encountered when entering a username, particularly on mobile devices, and to improve account creation completion rates.

As a volunteer host of editing workshops, the question of account creation always comes up: “My username is already taken! Do you have any ideas for what I could choose?” That personal anecdote is backed by data: 38.31% of users who abandon account creation do so while filling out the username field. These issues are amplified on mobile, where typing and correcting input is more difficult. All these issues (and others) creates a high-friction, error-prone interaction at a critical point in the funnel, contributing directly to abandonment.

@KStoller-WMF and I would like to hear your initial feedback on this project, in particular regarding our initial exploration.

• Have you noticed the same thing when it comes to creating accounts? Or does this ring a bell for you?
• How should we change a username if it's already taken?
  • In our current mockup/prototype, 4 random digits are appended to the username the person originally typed. Is this the right approach, or is there a better method we should use?
• Do you think English Wikipedia would accept testing a basic form of username suggestion?

Thank you very much for your initial feedback.

Trizek_(WMF) (talk) 14:53, 2 June 2026 (UTC)

Yes, this is a huge problem when creating accounts. I like the idea of just adding random digits. What you really need to avoid, imo, is generating a whole new "suggested" name, since this will really complicate things for sockpuppetry patrollers and probably lead to a real default of AGF towards accounts with the "auto-generated" format. I would suggest adding a line in the mockup that tells editors that it is possible to rename their account in the future (so they know they're not stuck with Blueberry3827 or whatever and don't worry about it too much). In solidarity, asilvering (talk) 18:07, 2 June 2026 (UTC)

@Asilvering Thanks for the feedback!

One thing we're trying to balance is that many people arrive at account creation without a strong preference for a username. Both in workshops and in our data, we see users get stuck when their preferred name is unavailable and then abandon the process altogether. For those users, having a ready-made, available suggestions could remove a frustrating hurdle and help them get to editing more quickly. Auto-generated usernames also reduce the likelihood that someone accidentally includes personal information, such as their real name, birth year, or email address. Here's an example prototype if that's helpful to visualize what we are considering (T424906).

Clearly this auto-suggested username should remain optional. Users who already know what they want to be called should be able to choose their own name, while users who are blocked by the username step can simply select a suggestion and continue.

The question of how these names might affect patrolling and community norms is a good one, and something we'd want to learn more about before any broader rollout. At the same time, I wonder if this is something we could test and measure rather than assume will be a significant issue. As the Growth team develops features for newcomers, we try to balance the needs of experienced editors with those of good-faith newcomers. Where possible, I'd prefer to optimize for the common challenges that prevent people from getting started, while still monitoring for unintended effects on patrolling and abuse detection. That said, if you see this as a fundamental concern that would make even a limited experiment inappropriate, I'd be interested in hearing more about that perspective! - KStoller-WMF (talk) 21:47, 4 June 2026 (UTC)

@KStoller-WMF, I apologize if this comes off as curt, but I have, along with other functionaries, raised this as a serious concern every time this has been brought up by PSI, so it is frustrating to hear that the fully generated-from-scratch option is still being considered for testing. However, because we have already had this conversation, I can tell you already that this will be a significant issue and there is no good reason to even test it. I think you are already going to surface a number of problems even with just the "add some random numbers to the end of someone's preferred name" method, but because I agree quite strongly that this is a pain point for new account creation, I think this is likely to be a valuable feature, and I believe it is at least worth a test. To be clear, not all of the functs who have been in these discussions agree with me on this last part and you may need to sell people on it.

When testing a version of this that takes a name provided by the new user and alters it in some way, here are some things I hope your testing could take into account:

• are editors with these names more or less likely to be blocked than baseline?
• specifically, what about sockpuppetry blocks?
• are they more or less likely to be reverted than "normal" account names? what about vs TAs?
• do editors with these names find the community more or less welcoming vs "normal" names and/or TAs? (obviously difficult to measure, but worth trying, I think)
• how many editors subsequently apply for renames vs baseline? are the account renamers getting overwhelmed?

I'm sure there are other things you'd want to look at, but those ones are important for understanding the impact on antiabuse systems, in my view. There is a significant risk that editors end up as collateral damage in sockblocks. And I think "community members treat these editors with suspicion" is virtually certain, but I'm hoping the effect wouldn't be so significant and that it could in any case be mitigated.

You will also need to consider that individual wikis have rules against impersonation. In the present circumstances, anyone who names themselves "asilvering394387" or "asilveringblue" or whatever has an extremely high chance of being instantly blocked by whatever admin comes across them first. Whatever you do will need a lot of advance warning before you test it. Adding a ~ before whatever other added text might help, or adding that at the beginning of the username, since that's a symbol people are already used to seeing at the beginning of the auto-generated TA names. In solidarity, asilvering (talk) 23:17, 4 June 2026 (UTC)

Thanks, I appreciate the candid feedback. And apologies if this feels like a conversation you've already had with PSI. We've been collaborating with PSI on several ideas related to account creation, but it's clear there's an opportunity for better knowledge sharing and coordination across this area. I'll make an effort to attend more of the functionary check-ins going forward so we can stay better aligned. - KStoller-WMF (talk) 23:44, 4 June 2026 (UTC)

@Asilvering, we checked internally, and we suppose that you attended the PSI meeting where account creation using the user's email. What was presented during that meeting was the idea of creating an account with just an email address while letting the system taking care of everything else like generating and assigning a random username. Was it the case? This v3 proposal only suggests the digits if the account is already taken.

Regarding suspicions of impersonation, your feedback confirms our initial thoughts. :) I documented it. Thank you! Trizek_(WMF) (talk) 14:38, 8 June 2026 (UTC)

Suggesting changes to a username provided by the editor is (hopefully) fine. Generating and assigning a random username would not be. In solidarity, asilvering (talk) 06:33, 9 June 2026 (UTC)

What would not be fine generating a random username? Here are the most common reasons I hear:

• Generating and assigning a random username would help paid-contributors being less detectable.
  • There are two types of such users: the ones who create an account directly connected to the topic they edits (easy to catch) and the ones who hide the link. The latter are often caught because they are heavily editing one topic en masse. The "smarter" ones edit elsewhere to hide their intent. Finding a username isn't an issue for that user type.
• Generating and assigning a random username would help sock-puppeters being less detectable.
  • My feeling is that they use the same approach as the smarter paid-contributors: they will achieve their goals nevertheless. I'm not sure that being (not) suggested a username would stop them. :)
• A username, perfectly fine at one language, will be a problem in another language.
  • This is a matter of having lists of "tokens" to generate a good enough username. Technically doable, I guess.
• Generating a user name that doesn't fit your input method.
  • i.e. your keyboard is in Chinese but you get a username in latin script. Again, it is a matter of where the account originates from: if you signup at zh.wp you get something in Chinese. Or in latin script if you end goal is to edit in Spanish. That discovery phase is also technically doable, I guess, if relevant.

Is there any other reason that could join this list? I have a few other pieces of feedback but they were not relevant (very edge cases, or specific to one language...).

For almost 40% of people, account creation is currently impaired because finding a username is hard. We could suggest a username with 4 digits (or more alterations, like Trizek → TrizekBlue), which brings more risks for the user (accusation of sockpupptery, impersonation, etc.) or be bolder and suggest a username based on a library (up to the user to change it later). :)

At least, we will very likely test the 4 digits.

Thank you for your feedback! Trizek_(WMF) (talk) 15:28, 9 June 2026 (UTC)

@Trizek (WMF) please correct me if I'm wrong but I don't think you have any experience as a Checkuser on any project (just admin and crat). As such I would ask you to consider the experience of people with CUs rather than your feelings around Generating and assigning a random username would help sock-puppeters being less detectable. It would be entirely reasonable if the team decided that the benefit was worth the trade-off. But to ask for feedback and then decide your own feeling superceded that feedback is very frustrating. Best, Barkeep49 (talk) 02:13, 10 June 2026 (UTC)

Thanks, Barkeep. Indeed I found Trizek's response both deeply patronizing and alarmingly ill-informed; I'm not sure it would be entirely reasonable if the team decided the benefit was worth the trade-off, since they don't appear to have any idea what it is they are trading. So, let me try to explain.

You misunderstand why sockpuppetteers and paid contributors do what they do, and, furthermore, why they are caught. Neither sockpuppeteers nor paid contributors are at all deterred by the current account creation system. Nor, for that matter, are vandals and other kinds of bad actor. These editors create vast quantities of accounts with no trouble whatsoever. They do not need the random-generated username function in order to hide; most are not trying to hide, at least not in the way you're implying, and for the ones who are trying to hide, this would not usefully hide them. The people who find it difficult to pick a username are the people who are creating their accounts in good faith.

Presumably, you agree with me on that last sentence. But when you propose a fully auto-generated username as a solution, you are not simply making it easier for that kind of editor to make a new username. What you are doing is making it equally easy for every kind of editor to make exactly the same kind of username. There is a huge difference between making suggestions based on a username someone provides and making everyone equally likely to be BlueSquirrel09, BlackTrout87, or GreyQuokka10. If you're working from a name the user provides, asilvering might become asilvering2045, asilveringsquirrel, asilvering~SHD, asilv0478, or whatever, but a dumbass vandal is still going to be peepeepoopoo2045 and Timelash is still going to be Timelash2045. That distinction really matters. If you don't maintain that difference, you will end up with a giant pile of "no-effort account creations", and in that pile will be both the good-faith editors who were having trouble and anyone else who presses that button. If necessary, I can explain at some length why that would be a very bad idea. In solidarity, asilvering (talk) 04:02, 10 June 2026 (UTC)

Sorry if you found my comment patronizing. This was not the intent at all. My idea was to present the feedback I got from other conversations (that included CUs) and, from there deep dive and discuss the trade-offs. So thank you for the explanation, @Asilvering. This is the kind of feedback I was expecting, as it fuels our thinking.

Like you, I'm putting apart dumbass vandals and promotional editors: their edits will quickly reveal what they came for.

What makes BlueSquirrel09, BlackTrout87, or GreyQuokka10 different to check than MiraQuill42, Harthenox, Lena Voss, InfoTide7, Corvian, AshaRiley, Ziploft9811, Thesys, MateoKeene or QubitFable? I generated these 10 usernames with the idea of not getting them looking alike. Certainly, BlueSquirrel09, BlackTrout87, or GreyQuokka10 would get more scrutiny.

Working from a username a user provides has its own challenge. On a technical side, we'd need to check if the username isn't too close to an active user, or a retired user who marked history.

If we can we compare the number of acting-in-good-faith newcomers with the number of bad actors, what would be the acceptable trade-off to offer usernames suggestions (not matter how they look like)? According to you, what would be the solution to check on these numbers? Wouldn't a short test give us a better idea?

Again, I'm here to collect feedback. :) Trizek_(WMF) (talk) 10:42, 11 June 2026 (UTC)

I think you've "expected" this feedback to the extent that you're not actually reading what I've said. In solidarity, asilvering (talk) 11:02, 11 June 2026 (UTC)

I read it, but it seems that I haven't understood your key point(s).

To me making it equally easy for every kind of editor to make exactly the same kind of username. was a key point. Did I missed something here?

That distinction really matters. Could you elaborate, as it seems that I missed your point there too?

The people who find it difficult to pick a username are the people who are creating their accounts in good faith is an agreement we have. I hope that solving this is also something we have in common. I'm not here to force on a definitive solution, but to work together on 1/ possible resolutions paths to solve this difficult step and 2/ for the most reasonable path, and if possible, testing it in a limited way.

Again, I'm here to listen, in full good faith. Trizek_(WMF) (talk) 12:48, 11 June 2026 (UTC)

In my experience making it equally easy for every kind of editor to make exactly the same kind of username is the key point. What I don't think you're understanding is that the attempt to generate a username can be used as an anti-abuse measure. I will use my own two accounts. I have Barkeep49 and Testkeep49. If an account shows up as Bartester49, well that says something. I am having no problems coming up with usernames and that is something that can be used to make some connections. A system which automatically generates all usernames eliminates that signal.

Now where asilvering and I had disagreed is whether we trust you to appropriately weigh those positives and negatives. I previously had, but no longer do given how I cannot square My idea was to present the feedback I got from other conversations (that included CUs) and, from there deep dive and discuss the trade-offs. with the post both asilvering and I were replying to and given today's Diff post makes it seem like decisions have been made regardless of the feedback and this feedback exercise isn't an attempt at feedback collection, it's an attempt at persuasion. As such I will bow out of this discussion because I'd rather limit my "I find the Foundation unconcerned about editor feedback" to the Wishlist rather than spreading it across multiple product areas and teams. Best, Barkeep49 (talk) 14:40, 11 June 2026 (UTC)

I'm sorry if you have this feeling but forcing things on is not my intent. I'm still collecting feedback to see if a test could be made. Trizek_(WMF) (talk) 15:15, 11 June 2026 (UTC)

@Trizek (WMF) I'm gonna agree with Asilvering here, I don't think completely auto-generating usernames is a good idea. A ton of sockpuppetry detection occurs outside of admin and CU lenses, among normal contributors who notice "oh this guy has the same/similar name, let me go look at their contribs" before going "ah" (or sometimes at a much more shallow level, "look that username has some form of GenZ slang in it, it's probably this specific vandal gaming edits"). As a editor, if auto-generated usernames become the norm, we will lose that initial signal, I'll instead have to devote a significant amount of scrutiny/view with suspicion in effect all auto-generated usernames (when previously I looked for specific patterns). Maybe that is fine in the risk posture of a smaller wiki, but bigger or medium-sized wiki with persistent sockpuppets would probably err towards not losing a fairly widely used signal. I would be wary of testing this especially on enwiki. Sohom (talk) 15:49, 11 June 2026 (UTC)

Thank you to everyone who has taken the time to share feedback. I've been following this discussion closely, and I want to acknowledge that you all have experience in wiki abuse prevention and moderation roles that I don't have.

My goal with this work has always been to address a very real challenge in account creation. Looking at both qualitative and quantitative data, I see a significant number of good-faith people abandon the process while trying to choose a username. I want to make it easier for new contributors to successfully join Wikimedia projects. At the same time, it is clear from this discussion that usernames serve important functions beyond simply identifying an account. They are also part of the signals that experienced community members use when evaluating behavior, identifying abuse, and protecting our projects.

Given that feedback, the Growth team will not move forward with the current V3 concept of testing auto-generated username suggestions at this time. I've just updated the project page to reflect this decision.

That does not mean we are stepping away from the broader problem. We remain committed to improving the account creation experience and reducing unnecessary friction for good-faith newcomers. However, this discussion has reinforced that any future exploration in this area needs to be shaped not only by account creation data and newcomer needs, but also by the expertise of CheckUsers, Stewards, administrators, and other experienced editors who help keep our projects healthy and safe.

Thank you again for the candid feedback. Even when perspectives differ, these conversations help us better understand the trade-offs involved and build better solutions. We'll continue exploring ways to improve account creation, and we'll make sure the communities affected by these decisions are part of that discussion. KStoller-WMF (talk) 16:58, 11 June 2026 (UTC)

Thank you for listening and taking action based on that feedback. I also appreciate that you didn't simply discount it as negativity. I wish these types of comments happened more often, although I know you as an individual can only do so much and can't fix the entire foundation by yourself. Community members want to feel like their voices matter from the start and aren't simply an afterthought where they have to prove themselves, just in a general sense. I get that this probably is early stages from your perspective, but I think it's usually more effective to ask people who already have experience what they think is not working and how they would fix that problem rather than coming to the table with preconceived notions of how to fix things. Clovermoss🍀 (talk) 21:32, 11 June 2026 (UTC)

To add to what the others have said about the value of the signal, what I really want to emphasize is the negative effect this would have on the innocent editors. The username a person uses tells us something about who they are. Often, when you're looking at just a single name, there's not much you can really guess (what kind of person is "asilvering" or "Barkeep49"?), though that's not always true ("Sohom Datta" is going to be a dedicated contributor or a person with a COI, "skibidi6767" is going to be a troll, "TornadoZone" is going to be an overenthusiastic teenager, and "TruthWarrior88" is going to be up to no good whatsoever). What long-time editors will conclude, once they notice the pattern in any of these partly or fully generated username solutions, is that the editors with this pattern are the "no effort account creations". You've probably seen people on twitter derisively referring to individual users as "firstnamebunchanumbers". It means that account is a dumbass whose opinions should be discarded (because they are a noob, or a bot). New editors with auto-generated names will get similar treatment here. We already see that with how people treat non-autoconfirmed/extended-confirmed accounts and temporary accounts. The question then becomes, how strong is that effect? Is it worth making it easier for someone to sign up, if what we're doing is sticking a big "kick me" sign on their back?

I think that's probably worth testing. But I only think it's worth testing if we can still tell at least some of the difference between Barkeep49~278, Sohom Datta~278, skibidi6767~278, and TornadoZone~278. The problem is not that skibidi6767 can now effortlessly show up as BrownToad80 - their vandalism will be roughly as easy to spot as it was before. (Though there are a lot of ways in which these names will drive anti-abuse patrollers crazy, as Sohom explains only a fraction of above.) The core problem is that Barkeep49 is now also named BrownToad80. We already know that productive, helpful editors make up a tiny minority of new account creations. The assumptions people make about BrownToad80 will not be kind. In solidarity, asilvering (talk) 21:32, 11 June 2026 (UTC)

The hyperbole of that diff post does not inspire confidence in the process. CMD (talk) 01:59, 12 June 2026 (UTC)

I was frustrated when I first read it too, but my understanding is that it was pre-written before all these objections. I'm mostly just relieved to feel like we were actually listened to and that the automatically generated usernames won't go as planned. I am cautiously optimistic we can move forward from this. Clovermoss🍀 (talk) 05:52, 12 June 2026 (UTC)

I don't think we were clear enough, either in this discussion or in the Diff post, that no engineering work has actually been done on the username suggestion idea. We created some designs and early concepts, but the whole reason for starting this thread was to gather feedback before starting work on that idea.

And while I can see how the title "Wikipedia’s account creation process is broken" comes across as a bit hyperbolic, there is some truth behind it. Today, we block a meaningful number of good-faith newcomers from creating accounts on mobile, and our account creation form is long, full of warnings and error messages, and far from what people have come to expect from modern online experiences.

That said, we are already testing some relatively simple usability and interface improvements (Account_Creation_Experiments) that are showing promising results! More people are successfully completing registration, and when we look at downstream contributor metrics, things still appear healthy. In other words, the additional people completing registration seem to be getting started making constructive (unreverted) edits at roughly the same rate as previous new account holders.

All of that makes me think there's still more we can and should do to improve the experience!

The Growth team will be wrapping up our account creation work in the near future, but the Reader Experience team (@HFan-WMF) will be spending more time thinking about account creation challenges as part of broader efforts to engage readers and support pathways that lead to account creation and contributing.

Following @Clovermoss's advice, I'd also love to hear your suggestions! How do we make account creation easier for readers and newcomers who want to take a step into Wikimedia projects? Many of these users expect simple sign-up experiences and quickly run into wiki-specific friction points such as IP blocks, username restrictions, or other hurdles that can be confusing before they've had a chance to become invested. What opportunities do you see to reduce that friction while still preserving the needs of the community and anti-abuse workflows? KStoller-WMF (talk) 18:49, 12 June 2026 (UTC)

The IP block notice really needs some UI changes, especially on mobile. At present, it foregrounds the name of the admin who blocked you (mostly useless information) and doesn't make it very clear what an editor needs to do to create an account or be unblocked. Not to mention that WP:ACC is mostly en-wiki specific and everyone else is just out of luck as far as I'm aware. In solidarity, asilvering (talk) 18:52, 12 June 2026 (UTC)

+1, on fixing the IP block interface both on mobile and desktop tbh. The current status is really not good, almost every time I've been caught in a block, I've had trouble figuring out how/what to do to get unblocked (especially on mobile) and this is as a volunteer with a very good visibility into the backend processes. Sohom (talk) 21:34, 13 June 2026 (UTC)

"our account creation form" appears to be one small screen of four questions, one of which (the email address) is unnecessary. It is hard to understanding how this form can be interpreted as "long" (it is not), "full of warnings and error messages" (the form doesn't display any, presumably it would take a lot of triggers to make it full of them), or "far from what people have come to expect from modern online experiences" (seems pretty standard, shorter than many, the only obvious deviation being not using an email address as a username). Running into an IP block isn't the fault of the account creation form. Picking a bad username isn't the fault of the account creation form. As an aside, is the "Email is required to recover your account if you...log in from a unfamiliar location or new browser" actually true? CMD (talk) 02:40, 14 June 2026 (UTC)

@Chipmunkdavis, to answer your final question: yes. See here: [1]. In solidarity, asilvering (talk) 03:07, 14 June 2026 (UTC)

Thanks. Surprised I've never triggered that. CMD (talk) 04:37, 14 June 2026 (UTC)

Thanks, @Asilvering and @Sohom Datta - I've passed along your feedback about the IP block interface to the PSI team. I agree there is so much we need to do in this space! My understanding is the PSI team will be working on related projects in the coming fiscal year under the Safety & Security objective.

screenshot of Create account form on mobile, June 2026

@Chipmunkdavis Here's an example of two warning messages that currently appear for the majority of people creating accounts on English Wikipedia.

The username warning is shown to anyone who doesn't capitalize the first letter of their username, and the email warning appears to everyone who taps into that field.

These are among the most common issues, but there are several others that are even more problematic. For example, the current account creation form delays password mismatch validation until form submission and does not clear error messages after the user corrects their input (T424979).

The Growth team has already developed improvements for several of these issues, and we're currently A/B testing these usability changes to measure their impact on account creation conversion (MW: Account Creation Experiments).

I also agree that four fields is not inherently a long form, although modern mobile users who are accustomed to one-click authentication may feel differently. When I describe the form as "long," I'm referring less to the number of fields and more to the amount of text and guidance presented during the process. For example, the password reminder is a standard security recommendation. Does it need to be shown by default? Similarly, does the hCaptcha legal text need to appear above the primary call to action? On mobile devices, the "Create your account" button is often not visible above the fold as a result of the current layout and helper text.

Those are some of the areas we've been exploring to improve account creation conversion. Are there other improvements you think we should consider? - KStoller-WMF (talk) 16:10, 14 June 2026 (UTC)

Thanks for the examples. I don't think there's any issues with tweaking reminder text positioning or adjusting elements, but they don't fit the claim the process is broken. A mismatch between expressed needs and expressed actions makes it hard to understand what sort of response or suggestions you are looking for.

My suggestion of reducing the username policy encouragement appears to have been taken up already. You could get rid of the please look for an email warning, if that sort of reminder message is needed (not weighing in on that either way here) you can use the echo notifications or some similar system to send it after account creation. On Desktop I'd suggest increasing the size of the form slightly. Problems with the mobile skin is why I advise users to load desktop mode on mobile, but in general it seems harsh to blame mobile issues on the signup form, similar to how blaming IP block on the signup form is misplaced.

I don't think I've ever one-click authenticated onto a website, what is your point of comparison? I just tried the Reddit signup form, as an example of a popular site, and it required me to input an email and then receive a code from my email. That feels like the more common standard, and is much more involved than the Wikipedia signup process. CMD (talk) 16:29, 14 June 2026 (UTC)

Thanks for the feedback!

Many online platforms have streamlined account creation through options like Google, Apple, or other third-party sign-in providers, which allow users to create an account without needing to come up with and remember a new password.

For example, Fandom offers several third-party sign-in options that make the registration process feel very quick from a user's perspective.

To be clear, I'm not suggesting the wikis should adopt the same approach. We have different privacy, security, and movement values than many commercial platforms, and those considerations matter. My point is simply that many internet users have become accustomed to these faster sign-up experiences elsewhere, which may contribute to Wikipedia's account creation process feeling more cumbersome or outdated by comparison. KStoller-WMF (talk) 16:50, 14 June 2026 (UTC)

@KStoller-WMF, can I ask if y'all have investigated m:Community_Wishlist/W301. I wondering if centering the page would help bring it more in-line with what folks are more accustomed to seeing on other websites and whether it could have any impact on user familiarity with the login process? Sohom (talk) 19:11, 14 June 2026 (UTC)

@Sohom Datta I didn't consider that wish to be within the scope of this project for two reasons:

First, we haven't touched the Special:UserLogin page at all. Our experiments have focused exclusively on Special:CreateAccount. While some platforms effectively combine login and account creation into a single flow, the technical complexity of Wikimedia's login experience, along with some wiki-specific logic, make a project like that extremely complex (and maybe contentious) so I deemed it out of scope.

Second, that wish appears to be primarily focused on the desktop experience, whereas we intentionally prioritized improvements to the mobile account creation flow.

That said, I agree there is room to improve Special:UserLogin as well. It would be great to simplify the page and potentially replace or remove that graphic. As a side note, I'd also love to see the appearance menu collapsed on the desktop Login and Account Creation pages - T419305.

Thanks for the reminder to review Community Wishes. I receive feedback in so many places, it's challenging to stay on top of it all, so I alway appreciate people highlighting important wishes that relate to newcomers / Growth features. KStoller-WMF (talk) 23:34, 16 June 2026 (UTC)

@Sj - looping you into this thread in case you are interested based our previous discussions and your notes here:https://meta.wikimedia.org/wiki/User:Sj/Design_chats/Create_account

We've published results from one of our account creation experiments here, and hope to have more experiment results to share soon! KStoller-WMF (talk) 21:50, 4 June 2026 (UTC)

Thakns -- great to see the data! And I look forward to seeing a test of v3, which fits on one screen :) – SJ + 22:37, 6 June 2026 (UTC)

Perhaps toning down (removing?) the "Choose carefully" language would be a simpler step before embarking on a Pokémon-style name your character selector? CMD (talk) 02:01, 5 June 2026 (UTC)

@Chipmunkdavis We explored and user-tested several different versions of that copy. One of our goals is to encourage people to learn about the username requirements and conventions, which is why we include a link. Our concern is that if we simply label it "Username Policy," many newcomers will assume it leads to a long policy page and be less likely to click through.

The current wording was an attempt to make the guidance feel more approachable and relevant to the decision they're making in the moment. That said, the specific copy is definitely open to adjustment. Do you have any alternative wording in mind that you think would better strike that balance? KStoller-WMF (talk) 15:52, 5 June 2026 (UTC)

Anything that doesn't say "Choose carefully"? You are concerned about friction due to editors who may not have a strong username preference. One thing that might give them the impression they need to really think about it is a warning they need to be careful. Encouraging people to click through to the username policy is probably a goal contrary to the goal of reducing friction in the signup policy, as reading any requirement page, however non-long and non-policy it may feel, is friction. CMD (talk) 16:01, 5 June 2026 (UTC)

I'll follow the provocative idea (I like it!): if the goal is to reduce friction, what about removing this link indeed? We have all seen anyone not reading the instructions. Even if someone chooses carefully, they could be asked to justify their choice of username based on their edits. Trizek_(WMF) (talk) 14:43, 8 June 2026 (UTC)

Years ago I saw a user essay that I cannot locate at the moment. The idea was that a new account not be given an opportunity to enter a name. Instead, an algorithm would generate a name and tell them to use it and that they would be able to change it in [some period, say a week?]. It would point out that, once changed, all their edits would be attributed to the new name. Advantages: very low hassle to make an account; new users who don't stay more than a few days (which was common) would not take a name making it unavailable for others. @Asilvering: might comment on how this would impact anti-abuse procedures. Johnuniq (talk) 04:58, 5 June 2026 (UTC)

@Johnuniq Thanks for the feedback! We discussed a similar approach early on. It has some appealing advantages, particularly reducing friction during account creation and avoiding the long-term reservation of usernames by people who never go on to edit or only make one edit and then abandon their account.

Ultimately, we decided not to pursue it because it would funnel more newcomers into the username change process, which currently requires manual review. Given the scale of account creation, we wanted to avoid a workflow that would generate substantial additional demand on that process.

That said, I appreciate the creative thinking! There are several potentially impactful ideas that we left off the table because they would likely require changes to existing community processes. Those changes are certainly possible, but they add complexity and coordination costs that can make experimentation and deployment substantially more difficult. KStoller-WMF (talk) 15:47, 5 June 2026 (UTC)

A couple of comments around Trizek_(WMF)'s original research findings and questions:

(1) My sole experience of Wikipedia account creation was >20 years ago. However, my recollection for that and many other online services since is that I didn't follow-through the first time on the screen, but exited and pondered who I wanted to be: real-name variant, other more masked account name, same / similar / different handle to other services, etc.? That paused completion seems prudent, so I am unconvinced that abandoned sign-ups are such a bad thing.

(2) A point came up in a mentor exchange yesterday: this new user had already been involved as a Temporary Account in a Talk discussion involving disputed facts. They had now created an account, and I cautioned them to identify as the previous TA if further participating in that discussion, to avoid being called out as a Sock. Which they did, but that suggests the desirability of avoiding siloing TA and real accounts, instead building easy and clearly-identifiable transition between them. That may be relevant for T416418 and giving more prominence to permanent than temporary accounts at outset. AllyD (talk) 11:38, 8 June 2026 (UTC)

1) It is a good summary of the challenges we try to solve. :)

2) At the moment, we can display a call to create an account after the edit (which we are currently testing at other wikis). Would it be relevant to add it before? Would it be relevant at some pages (like on talk pages) but not other? Wouldn't it be a blocker? Wouldn't it go against the Founding principle #2?

Trizek_(WMF) (talk) 15:02, 8 June 2026 (UTC)

As I see this discussion happening in English Wikipedia (while it affects everyone), I'm jumping it.

You are right: we have hundreds of new editors every year in our University workshops and many struggle to find a name, because all "normal" names (JohnD) are already taken. So they end up adding or more information (full surname) or a random number on their own. Or even the classical Z generation "JooohhnnnDoooeee" trick.

However, the main issue here is not that less people is creating an account because they can't pick a name that is cool for them. The main issue is that people is that less people is creating an account because there's no point on creating an account. If we don't solve that issue, this kind of improvements might be good or bac, but not solving the underlying question. Theklan (talk) 14:06, 11 June 2026 (UTC)

Thanks for chiming in @Theklan!

I agree with the core concern that improving the mechanics of account creation alone is not sufficient if there is no clear reason for people to want an account in the first place.

That said, I would frame it slightly differently: the work on account creation was necessary but not sufficient. It reduces friction for people who already have some intent, but it does not create that intent on its own.

There are several parallel efforts aimed at strengthening the underlying value proposition of having an account:

• The Readers teams are exploring logged-in reader features such as saving or revisiting content and personalized recommendations.
• Next fiscal year the Contributor Growth team is exploring enhancements to the Homepage experience, including potential logged out version of a Homepage with certain features "locked" for logged-out users and temporary accounts, to better communicate what additional functionality becomes available with an account.
• The Editor team is looking at ways to surface lightweight, approachable editing opportunities, so that the transition from reading to contributing feels more natural and less like a separate step.

Overall, I see account creation improvements and incentive-building as tightly linked parts of the same funnel. The former reduces drop-off once interest exists, while the latter helps more readers reach that point of interest in the first place.

What do you see as the most compelling “reason to create an account” for readers today? Which types of value (personalization, saving, participation, recognition, etc.) do you think are most likely to motivate account creation? KStoller-WMF (talk) 23:51, 16 June 2026 (UTC)

Automatic removal of inactive mentors through Community Configuration

Mentorship is most effective when active experienced users act as mentors. To support the community's efforts in curating the mentor list, the Growth team will soon release a way to remove inactive users automatically. You can read more about this at Wikipedia_talk:Mentorship#Automatic_removal_of_inactive_mentors_through_Community_Configuration. Trizek_(WMF) (talk) 12:50, 11 June 2026 (UTC)