Dashboards Panels W1994

Open Growth Team Tasks
ActivePublic
Actions

Referenced Files

None

Open Growth Team Tasks
View All

T432414: ExtensionJsonTestBase should verify that Hooks registrations resolve to a working handler
Task
## Summary `ExtensionJsonTestBase` only verifies that each `HookHandlers` entry can be constructed; nothing checks that a handler registered under `Hooks` actually implements the hook it is registered for. As a result, a dangling registration — left behind when a handler method is removed but its `Hooks` entry is not — goes unnoticed by the extension.json structure tests and only surfaces at runtime when the hook fires. ## Technical notes Add a data-driven test (`testHookImplementedByHandler`) to `tests/phpunit/integration/includes/ExtensionJsonTestBase.php`, reusing the existing `provideHookNames` provider. For each handler that references a `HookHandlers` entry, construct the object via `ObjectFactory` (matching `testHookHandler`, which also covers `factory`-based specs) and assert it has the matching `on<Hook>` method, using the same hook-name normalization as `HookContainer::getHookMethodName()` (`'on' . strtr($hook, ':\\-', '___')`). For legacy `Class::method` callable handlers, assert the callable is valid via `assertIsCallable`. Keep this separate from `testHookUsesHookHandler`, which enforces the stricter "must use HookHandlers" policy behind `$requireHookHandlers` and rejects callable handlers outright — the two checks are complementary (style policy vs. correctness). The test runs for every extension that extends `ExtensionJsonTestBase`, so it applies without any per-extension opt-in flag. ## Open questions The new test overlaps with `testHookHandler`: both construct every referenced `HookHandlers` object via `ObjectFactory`. This introduces two forms of duplicity worth deciding on before merge. First, redundant construction — a handler registered for N hooks is now constructed N times here, on top of the once in `testHookHandler`; construction cost on the test path is negligible, so this is mostly a tidiness concern. Second, overlapping failure signal — if a handler's construction throws, both tests fail for the same root cause, which is harmless but noisier in CI output. Options: (a) keep the tests separate and accept the overlap, favouring a clean separation of concerns (construction validity vs. hook implementation); (b) fold the method check into `testHookHandler`, constructing each handler once, at the cost of a reverse handler→hooks lookup and mixing two concerns in one test; (c) drop `ObjectFactory` here and check `method_exists` statically on the declared class name, which removes all construction overhead but loses coverage of `factory`-based specs (the reason `ObjectFactory` was chosen). ## Acceptance criteria - [ ] Extension.json structure tests fail when a hook is registered to a handler that lacks the corresponding `on<Hook>` method (or an invalid callable), and pass otherwise. - [ ] The check covers both `HookHandlers`-style registrations (including `factory`-based specs) and legacy `Class::method` callables.
T432190: clicking a suggested username after partial name entry on Mentor dashboard gives 'No mentees found'
Task
I suspect a possible mismatch in filtering the dropdown list of suggested username matches on partial name entry, and the filter used to produce the results of the search when a complete username is given. **Steps to replicate the issue** (include links if applicable): * Logon as me, or simulate viewing my Mentor dashboard * Go to p. 2 of the dashboard (don't know if this is required; that's just where I happened to be when I noticed the problem) * Start typing 'Laura' * after typing 'L-a-u', you should see three suggested usernames in the dropdown * click the top one, which starts, 'Laura'; (full username not given here for privacy; it is six words and 23 chars long; [[https://en.wikipedia.org/wiki/Special:EmailUser/Mathglot|email me]] if you need it, or just check my mentees) **What happens?**: * the dashboard is replaced by the message, 'No mentees found. \n Change your filters to find mentees.' (my filters: min=1 max=500; User:Laura... has 1 edit, but not in mainspace) **What should have happened instead?**: * the dashboard should have shown the full username of the 'Laura...' user suggested in the dropdown. along with the dashboard row corresponding to that mentee One thing occurs to me: are you filtering the dropdown suggestions using the same filter that you apply to the username search? If so, suppose I set minimum edits to 500, and search for some mentee names. Will the dropdown return any suggested usernames? It should not, because afaik, no mentee of mine has reached 500 edits yet. If you are not using the same filter for the dropdown as for search, then that might be part of the explanation. But not in this 'Laura' example, unless you are also applying the min value to mainspace only; are you? If not, then the problem must lie elsewhere.
T432164: Instrumentation: DE1.3.1 Early onboarding experiment
Task
#####Instrumentation specification [[ https://docs.google.com/spreadsheets/d/1Noy5RMQQPdXoQFcME8A5lQos9AXkBxlV6C7io1749eA/edit?gid=736473020#gid=736473020 | Instrumentation specs for DE1.3.1 ]] #### Testable hypothesis If we reduce cognitive load and provide more personalized post-account creation experiences for new account holders, then a greater proportion of users will constructively activate by making their first edit. #### Experiment details {T432126} #### Acceptance Criteria: - [[ https://docs.google.com/spreadsheets/d/1Noy5RMQQPdXoQFcME8A5lQos9AXkBxlV6C7io1749eA/edit?gid=736473020#gid=736473020 | Instrumentation specs for DE1.3.1 ]] are drafted and agreed upon with @KStoller-WMF and @MNeisler - Instrumentation is set up to support {T432126}
T432129: Investigate removing the duplicated task-type conversion logic between PHP and JS
Task
The task-type conversion/filtering logic exists twice: in `NewcomerTasksUserOptionsLookup` (PHP) and `TaskTypesAbFilter.js` (JS). Parity is enforced only by doc comments ("This has to be equivalent to..."), and the implementations have already drifted: the JS side has the `taskTypeOrFalse()` guard, "unavailable" task-type filtering, and an empty-result fallback that the PHP side lacks. One such divergence caused an UBN (T431668). This is a recurring maintenance hazard: every change to the conversion logic must be made twice and reviewed for equivalence by hand. The most promising direction is to compute the conversion map (or the fully converted task-type list) in PHP only and ship it to the client as a generated virtual packageFile (like `TaskTypes.json`), then delete the duplicated JS logic. ## Open questions to resolve in the investigation: * whether the JS-only behaviours (unavailable-task-type filtering via `wgGESuggestedEditsTaskTypes`, empty-result fallback) depend on client-side state that is not available at packageFile generation time * how much of `TaskTypesAbFilter.js` can actually be removed. Outcome of this task should be a decision plus follow-up implementation task(s). ## Acceptance criteria - [ ] Investigation/PoC determines whether the conversion logic can be computed server-side only, and what the JS-only behaviours require - [ ] Follow-up implementation task(s) filed accordingly
T432126: Experiment: DE1.3.1 Early onboarding & account set-up
Task
**INSTRUMENTATION SPECIFICATION**: [[ https://docs.google.com/spreadsheets/d/1Noy5RMQQPdXoQFcME8A5lQos9AXkBxlV6C7io1749eA/edit?gid=736473020#gid=736473020 | Instrumentation specs for DE1.3.1 ]] ### Testable hypothesis If we reduce cognitive load and provide more personalized post-account creation experiences for new account holders, then a greater proportion of users will constructively activate by making their first edit. ### Experiment details #### Overview - **Experiment Name**: DE1.3.1 Early onboarding - **Tracking Key**: `DE1.3.1-early-onboarding` - **Risk Level**: [TBD] [according to Data Collection Guidelines, depending on data you plan to collect, including experiment-wide contextual attributes (see last section)] [For Medium and High Risk only: Link to approved L3SC request in Asana] #### Traffic - **Assign Variation by Attribute**: MW User ID [survey is shown post-account-creation, so all subjects are logged in] - **Traffic Percent**: 100% - **Variations**: {T430418} - Control (`control`): Current Welcome Survey - Treatment (`treatment`): Redesigned account set-up experience. - **Targeting** - MediaWiki Database Code in: - enwiki - frwiki - arwiki - eswiki - **Expected start date**: [TBD] ## Metrics [REMINDER: The linked specification at the top should list all these metrics and their events, and which (if any) contextual attributes are needed for specific events.] - **Goal metrics** - Constructive Activation - **Secondary metrics** - Account set-up completion rate - Completion rate for each account set up question - Second-week retention (DE1.3 KR metric) - Proportion of accounts with an email - **Guardrail metrics** - [TBD]
T432125: Guard conversion-map fallback targets in NewcomerTasksUserOptionsLookup::getConversionMap()
Task
During the Revise Tone UBN (T431668), `NewcomerTasksUserOptionsLookup::getConversionMap()` produced a fallback target (`copyedit`) that is not a configured task type on all wikis (e.g. dewiki has it disabled). The JS counterpart `TaskTypesAbFilter.getConversionMap()` guards against this with `taskTypeOrFalse()`, but the PHP implementation does not, even though the doc comments require the two to be identical. The UBN fix ([1309099](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/1309099)) filters non-existent task types in `convertTaskTypes()`, but the map itself still contains unconfigured targets — `filterTaskTypes()` only reads map keys today, but if in the future it would also consume the values of the map, then that would reintroduce the fatal. ## Technical notes Port the `taskTypeOrFalse()` guard from `TaskTypesAbFilter.js` to `getConversionMap()`: when the fallback target (`links`, `copyedit`) is not in `ConfigurationLoader::getTaskTypes()`, map to `false` instead. This applies to both the `link-recommendation => links` and `revise-tone => copyedit` entries. The filtering added in [1309099](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/1309099) can stay as defence in depth. ## Acceptance criteria - [ ] `getConversionMap()` never maps to a task type that is not configured on the wiki, matching the JS implementation - [ ] Unit test covers the case where the fallback target is not a configured task type
T432064: Broken section links to mentee's published question – double hash ## in url
Task
After posting a message to a mentor via the Your Mentor module, the mentee receives a faulty link to their question containing a reduplicated hash ('##') in the url. This breaks the section link ([[https://en.wikipedia.org/wiki/URI_fragment|url fragment]]) in two places: * in the 'Your question has been published!' dialog pop-up immediately after publication. The link underlies the anchor text 'View your question on your mentor's talk page.' * in the Your mentor module, under the 'Your recent questions' section, underlying anchor text consisting of a copy of the first ten words or so of the mentee question. {F93460821,layout=right, float, width=185} The links with broken fragments gracefully degrade to top-of-page on the Mentor talk page, but they also get a small pop-up dialog box that says, 'This topic could not be found. It might have been deleted, moved, or renamed.' Given the mentee's newness (often their very first edit at Wikipedia), imho, this is functionally equivalent to sending them to the wrong page entirely. Real-world test: url generated was: https://en.wikipedia.org/wiki/User_talk:Alextejthompson##Question_from_Mathglot_(19:32,_13_July_2026) **Steps to replicate the issue** : # go to [[https://en.wikipedia.org/wiki/Special:Homepage#growthexperiments-homepage-module-mentorship|your Mentor module]] # click the button to ask your mentor a question about editing # in the Ask your mentor pop-up, enter your question and click Publish # the 'Your question has been published!' dialog pop-up should appear # mouse over or click the anchor text 'View your question on your mentor's talk page' **What happens?**: * it goes to the top of the mentor talk page when clicked (notice the double hash in the url) * you get a pop-up dialog, 'This topic could not be found. It might have been deleted, moved, or renamed.' **What should have happened instead?**: * it should go to the section containing the question the mentee just posed. * there should be no 'not found' pop-up. **Steps to replicate the second issue:** 6. go back to [[https://en.wikipedia.org/wiki/Special:Homepage#growthexperiments-homepage-module-mentorship|your Mentor module]] 7. find your question under the 'Your recent questions' section 8. click your question **What happens?**: * same result as above **What should have happened instead?**: * same as outcome above
T432039: Register Mentorship Module with PersonalDashboard
Task
####Description Register the Mentorship Module with PersonalDashboard so that it can be rendered on the Special:Homepage through PersonalDashboard instead of the current system. ####Acceptance Criteria - [ ] Module configured to use PersonalDashboard in line with the [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/PersonalDashboard/%2B/HEAD/docs/modules.md#existing-modules-as-reference | documentation instructions ]]. - [ ] No fallback to placeholder and no stale/incorrect content shown. - [ ] Module displays on Special:Homepage via PersonalDashboard correctly on [[ https://patchdemo.wmcloud.org/ | Patch demo ]].
T432037: Register Suggested Edits Module with PersonalDashboard
Task
####Description Register the Suggested Edits Module with PersonalDashboard so that it can be rendered on Special:Homepage through PersonalDashboard instead of the current system. ####Acceptance Criteria - [ ] Module configured to use PersonalDashboard in line with the [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/PersonalDashboard/%2B/HEAD/docs/modules.md#existing-modules-as-reference | documentation instructions ]]. - [ ] No fallback to placeholder and no stale/incorrect content shown. - [ ] Module displays on Special:Homepage via PersonalDashboard correctly on [[ https://patchdemo.wmcloud.org/ | Patch demo ]].
T432036: Register Impact Module with PersonalDashboard
Task
####Description Register the Impact Module with PersonalDashboard so that it can be rendered on Special:Homepage through PersonalDashboard instead of the current system. ####Acceptance Criteria - [ ] Module configured to use PersonalDashboard in line with the [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/PersonalDashboard/%2B/HEAD/docs/modules.md#existing-modules-as-reference | documentation instructions ]]. - [ ] No fallback to placeholder and no stale/incorrect content shown. - [ ] Module displays on Special:Homepage via PersonalDashboard correctly on [[ https://patchdemo.wmcloud.org/ | Patch demo ]].
T432035: Register Email (confirm dialog) with PersonalDashboard
Task
####Description Register the Email (confirm dialog) module with PersonalDashboard so that it can be rendered on Special:Homepage through PersonalDashboard instead of the current system. ####Acceptance Criteria - [ ] Module configured to use PersonalDashboard in line with the [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/PersonalDashboard/%2B/HEAD/docs/modules.md#existing-modules-as-reference | documentation instructions ]]. - [ ] No fallback to placeholder and no stale/incorrect content shown. - [ ] Module displays on Special:Homepage via PersonalDashboard correctly on [[ https://patchdemo.wmcloud.org/ | Patch demo ]].
T432034: Register Help Module with PersonalDashboard
Task
####Description Register the Help Module with PersonalDashboard so that it can be rendered on Special:Homepage through PersonalDashboard instead of the current system. ####Acceptance Criteria - [ ] Module configured to use PersonalDashboard in line with the [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/PersonalDashboard/%2B/HEAD/docs/modules.md#existing-modules-as-reference | documentation instructions ]]. - [ ] No fallback to placeholder and no stale/incorrect content shown. - [ ] Module displays on Special:Homepage via PersonalDashboard correctly on [[ https://patchdemo.wmcloud.org/ | Patch demo ]].
T432033: Register Community Updates with PersonalDashboard
Task
#### Description Register the Community Updates module with PersonalDashboard so that it can be rendered on Special:Homepage through PersonalDashboard instead of the current system. ####Acceptance Criteria - [ ] Module configured to use PersonalDashboard in line with the [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/PersonalDashboard/%2B/HEAD/docs/modules.md#existing-modules-as-reference | documentation instructions ]]. - [ ] No fallback to placeholder and no stale/incorrect content shown. - [ ] Module displays on Special:Homepage via PersonalDashboard correctly on [[ https://patchdemo.wmcloud.org/ | Patch demo ]].
T432031: [Epic] Register Special:Homepage Modules using PersonalDashboard
Task
####Background This epic captures Growth Teams journey in consuming the [[ https://www.mediawiki.org/wiki/Extension:PersonalDashboard#Development | PersonalDashboard ]] by registering Modules on Special:Homepage through PersonalDashboard. Starting this registration work now lets the team surface integration issues well ahead of future A/B tests. It is captured under DE 1.3.X under the hypothesis to track the efforts related to this work: > If the Growth Team starts progressively registering the modules on the Special:Homepage via PersonalDashboard, this will allow Growth to uncover critical integration issues with PersonalDashboard earlier and setup ourselves for success in the upcoming A/B tests. Docs on how to register modules on PersonalDashboard: https://gerrit.wikimedia.org/g/mediawiki/extensions/PersonalDashboard/%2B/HEAD/docs/modules.md ####Acceptance Criteria [] Mentorship Module is registered on Special:Homepage via PersonalDashboard [] Suggested Edits Module is registered on Special:Homepage via PersonalDashboard [] Email confirm dialog module is registered on Special:Homepage via PersonalDashboard [] Help Module is registered on Special:Homepage via PersonalDashboard [] Community Updates is registered on Special:Homepage via PersonalDashboard [] All modules render properly in Patchdemo via PersonalDashboard with visual parity (content, ordering, refresh behavior) to production. [] All modules render properly in Beta via PersonalDashboard with visual parity (content, ordering, refresh behavior) to production. ####QS Lead Support Needed [[ https://www.mediawiki.org/wiki/Growth/Team/QS_Lead_Support#When_to_Seek_for_QS_Support | (see criteria) ]]: Yes.
T432008: Upgrade GrowthExperiments extension to node16
Task
According to {T431855}, the extension needs to be updated from node10 to node16
T431861: Add way of excluding all newcomer tasks
Task
https://en.wikipedia.org/wiki/Special:CommunityConfiguration/GrowthSuggestedEdits should have a way of excluding templates and categories for **all** newcomer tasks. Right now enwiki admins have community configured the same set of exclusions for every single type of newcomer task, and having to do it manually for each new type of task is leading to problems like T426690.
T431859: Community Configuration template/category exclusions autocompletes in wrong namespace
Task
**Steps to replicate the issue** (include links if applicable): * Go to https://en.wikipedia.org/wiki/Special:CommunityConfiguration/GrowthSuggestedEdits * type some text in "Articles containing categories defined here will not be shown to users as tasks for this task type" or "Articles containing templates defined here will not be shown to users as tasks for this task type" * **What happens?**: Autocomplete shows mainspace pages **What should have happened instead?**: Autocomplete shows templates/categories **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.):
T431810: If a task type is undeployed, Suggested Edits might misbehave for certain users
Task
**Steps to replicate the issue** (include links if applicable): NOTE: Those steps to reproduce are incomplete. The issue appeared when I had revise-tone in `se-filters` and disappeared when I reset that property to a default value. However, retrospectively following those steps does not cause the problem. P94786 is a dump of my user properties at the time of seeing that bug. https://test.wikipedia.org/w/index.php?title=MediaWiki:GrowthExperimentsSuggestedEdits.json&diff=prev&oldid=750689 also happened at around the reproduction of this bug. I was also playing with `new mw.Api().saveOption('growthexperiments-homepage-suggestededits-activated', null)` at that time. Visit Special:Homepage with an account that has a task type selected (in `growthexperiments-homepage-se-filters`) which is no longer available. An artificial way to do this can be: * Call `new mw.Api().saveOption('growthexperiments-homepage-se-filters', "[\"revise-tone\"]")` in your browser console * Go to Special:Homepage **What happens?**: The task type selector is unusable (no task types were provided) **What should have happened instead?**: Task type selector was operating normally. **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.):
T431804: Deploy automated mentor list cleanup to all Wikimedia wikis
Task
Following the pilot wiki testing done in {T427386}, let's enable the automated mentor list cleaner on all Wikimedia wikis. Communities will still need to enable it via Community Configuration if they wish to use it. This should be actionable starting the week of July 13. ==== Acceptance Criteria [ ] Make the automated mentor list cleaner available at all Wikimedia wikis
T431772: Include performer_is_temp contextual attribute with account_created events
Task
In [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikimediaEvents/+/5b84f89f9b06fbbe200ec7f5215a6639587bb793/modules/ext.wikimediaEvents/accountCreation/useAccountCreationInstrument.js | useAccountCreationInstrument.js ]], `account_created` events should include `performer_is_temp` contextual attribute which is needed by: - [[ https://growthbook.wikimedia.org/fact-metrics/fact__2CcZv7bN9PoQTS3Nt3esLY | Permanent account creation rate ]] - [[ https://growthbook.wikimedia.org/fact-metrics/fact__2Cc59w27tF41fLDNjG748o | Permanent account activation rate ]] - [[ https://growthbook.wikimedia.org/fact-metrics/fact__2CcZv5n7zVBiJ3N8dCqMSF | Temporary account creation rate ]] metrics in GrowthBook. Right now the experiment owner must remember to include that contextual attribute when configuring the experiment in TK UI or GrowthBook. It would be easier/simpler and better to collect this per-event (rather than experiment-wide) via: ```lang=diff - experiment.send( 'account_created' ); + experiment.send( 'account_created', {}, [ 'performer_is_temp' ] ); ``` And then the experiment owner doesn't have to select `performer_is_temp` when configuring the experiment, and there would be no risk of an experiment owner forgetting to do that step.
T431763: Add GrowthExperiments campaign configuration for Community Development campaign
Task
Add GrowthExperiments campaign configuration for Community Development campaign **User story:** As a Community Development manager, I want to be able to track users who arrive via a specific campaign link so that I can measure the effectiveness of our outreach efforts and better understand how those campaigns contribute to account creation and other down-funnel metrics. **Background** The GrowthExperiments extension supports campaign URLs that allow incoming traffic from specific outreach efforts or referral sources to be associated with a named campaign. https://www.mediawiki.org/wiki/Extension:GrowthExperiments/Technical_documentation#Campaigns ####Acceptance Criteria: - URLs containing ?campaign=`social-tryediting` are recognized by GrowthExperiments. - The standard account creation experience is displayed. (No custom benefits block) NOTE: data analysis will not be handled by the Growth team or Contributor Product Analytics
T431755: Improve reliability of Tone suggestions
Task
This is a tracking task for the issues that, if addressed, could reduce the false positive rate of the [small language model](https://meta.wikimedia.org/wiki/Machine_learning_models/Production/Tone_Check) powering Tone Check and its corresponding edit suggestions.
T431754: False-positive Tone Check instance for translated poetry
Task
**Steps to replicate the issue**: * Edit with SuggestionMode: https://en.wikipedia.org/wiki/Burushaski#Sample_text **What happens?**: It shows a Tone Check suggestion for each of the translations of the poetry samples {F92642796} **What should have happened instead?**: No Tone Check. **Other information**: Essentially it's a difficult-to-flag example of “exclude quoted content” - {T426362}
T431747: GEMentorshipShouldBeAutoremoved needs more specific message in GrowthExperiments log
Task
This is a follow-up task on @Trizek-WMF comment (https://phabricator.wikimedia.org/T427386#12106168): The edit summary [[ https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Journal?type=growthexperiments&user=&page=&wpdate=&tagfilter=&subtype=mentorassignmentchanges&wpFormIdentifier=logeventslist | in the logs ]], "[[ https://translatewiki.net/wiki/MediaWiki:Growthexperiments-quit-mentorship-reassign-mentees-log-message-removed/en | $2 removed $1 from mentorship ]]", is a bit obscure. Could we add a proper reason connecting the removal with the community configuration, like [[ https://fr.wikipedia.org/w/index.php?title=MediaWiki:GrowthMentors.json&action=history | the reason posted in the json file history ]]: "inactive for 90 days"?
T431634: Tighten validation of page titles in CommunityConfiguration
Task
CommunityConfiguration allows clients to specify a value should be a page title, cf.: ```lang=php class Schema extends JsonSchema { public const GEHelpPanelViewMoreTitle = [ self::REF => [ 'class' => MediaWikiDefinitions::class, 'field' => 'PageTitle', ], ]; } ``` However, CommunityConfiguration then never validates the value actually //is// a page title that might exist. At times, this might cause errors such as {T431625} or {T431632}. Within this task, we should make CommunityConfiguration validate page titles.
T431632: Misconfiguring Revise Tone's Community Configuration can turn off Suggested Edits for everyone
Task
By including characters invalid in a title (such as `}`), it is possible to disable Suggested Edits for everyone (for example, reverting [this testwiki change](https://test.wikipedia.org/w/index.php?title=MediaWiki:GrowthExperimentsSuggestedEdits.json&diff=prev&oldid=750552) would have that effect on testwiki). This is because GrowthExperiments' validation expects a valid title, and CommunityConfiguration fails to provide one. xref {T431625}
T431592: Add an Image: configuration for image suggestion "type" (Add an image to an article without illustrations)
Task
####User Story: As a newcomer editing Wikipedia, I want to receive task suggestions that are fairly accurate and structured, so that I can get started and successfully edit on a mobile device. NOTE: this task relates to `Add an image to an article without illustrations` not `Add an image to a section of an article`. ####Documentation: https://www.mediawiki.org/wiki/Platform_Engineering_Team/Data_Value_Stream/Data_Gateway#Image_Suggestions https://www.mediawiki.org/wiki/Help:Growth/Tools/Add_an_image https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Structured_tasks/Add_an_image ####Background: [[ https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Structured_tasks | Structured tasks ]] provide new editors with machine generated suggestions and structured the edit in a way that helps more new account holders edit constructively [[https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Structured_tasks/Add_an_image/Experiment_analysis,_March_2024 | (1) ]]. We tested initial suggestions with our pilot wikis to ensure the tasks provide good suggestions the majority of the time. Task onboarding indicates that suggestions aren't always correct, and that's why editors are asked to review the suggestions. In other words, we don't expect the suggestions to be 100% accurate, but they should be good suggestions ~70% of the time. However, as we looked into scaling "add an image" to more wikis, we completed an additional round of evaluation: {T366925}. When reviewing these suggestions it seemed that certain suggestion "kinds" were less likely to be good suggestions. The `istype-depicts` and `istype-commons-category` suggestions were often lower quality. After removing these task kinds from the suggestion pool, we notice suggestions improve. The downside of removing these suggestions is that the task pool is reduced dramatically. But for many wikis a reduction in suggestions will be preferable to offering more suggestions that might be low-quality or "bad" suggestions. We now have the ability to filter image suggestions: {T368987} ---- **Type of suggestions: ** - Wikipedia - article lead images (istype-lead-image) - Wikidata - item [[ https://www.wikidata.org/wiki/Property:P18 | image ]] (istype-wikidata-image) - Wikidata - item [[ https://www.wikidata.org/wiki/Property:P373 | Commons category ]] (istype-commons-category) - Commons - [[ https://commons.wikimedia.org/wiki/Commons:Depicts | depicts ]] (istype-depicts) ####Questions: - Should we simply increase the default confidence or also allow communities to adjust this within Community Configuration? - Allow Community Configuration. It's likely large wikis will have very different needs and interests than smaller wikis. - Should we simply allow for filtering based on confidence score? Or allow for filtering for confidence and "type" (which might be more confusing to explain in Community Configuration)? - Given that the confidence score is essentially generated via the type information, let's first start with exposing only the "type" configuration. We can consider expanding this if there is need, but it would be best to keep this simple to start. - Should we allow communities to adjust the confidence level for article-level AND section-level, or should we first only focus on article-level suggestions? - Start with article-level suggestions for initial scaling effort. ####Copy: **Sources for image suggestions** ☑ Other Wikipedias Suggest images that appear as the lead image in versions of the same article on other language Wikipedias. ☑ Wikidata [[ https://www.wikidata.org/wiki/Property:P18 | image ]] Suggest images that are associated with the article's Wikidata image. ☑ Wikidata [[ https://www.wikidata.org/wiki/Property:P373 | Commons category ]] Suggest images that are associated with the article's Wikidata Commons categoruy. ☑ Wikimedia Commons [[ https://commons.wikimedia.org/wiki/Commons:Depicts | depicts ]] Suggest images based on structured metadata that describes what images depict. {F93439532} ####Acceptance Criteria: **Scenario 1: Default configuration is that all types (sources) are "enabled"** Given a community has not modified the image suggestion type configuration When article-level image suggestions are generated Then the default set of enabled image suggestion types is used. **Scenario 2: Configuration is saved** Given a community administrator enables or disables one or more image suggestion types When they save the configuration Then the selected image suggestion types are stored and applied to future article-level image suggestions.
T431233: Autogen or autosync Growth/Deployment table from the canonical deployment data
Task
Please automatically generate or synchronize the [[ https://www.mediawiki.org/wiki/Growth/Deployment_table | mw:Growth/Deployment table]] from the canonical deployment data. I'm not sure if the Wikidata sitelinks at [[ https://www.wikidata.org/wiki/Q14339834#sitelinks-wikipedia | d:Q14339834 ]] (Wikipedia:Growth Team features/Mentor list) are the source of truth for Wikipedias with mentorship enabled, or there's some other deployment config that is perhaps feeding the sitelinks, but whatever the case the mw:Growth/Deployment_table is grossly out of date. I have already given out incorrect information because of it. I was about to blank the page and turn it into a soft 404 to d:Q14339834, but it occurred to me that Wikidata might not have the correct data either. (But a blank Deployment table would still be better than wrong info.) Please figure out what one source you want to contain the official on-wiki source of deployment info, and then sync that automatically to whatever internal config holds the actual list. Every other on-wiki source should identify itself as derivative, and link to one on-wiki source with sync'ed data.
T431084: Design a Homepage module inviting users to view Review Changes
Task
Per the parent task, we want to use the existing centralised newcomer surface, the Newcomer Homepage, to invite users to review changes to pages that they are likely to be interested in. This means we need to design a new module to be placed on the Newcomer Homepage. **Current homepage layout/modules** | Mobile | Desktop | | {F91662625} | {F91662610} | Because we plan to run an A/B test, where some users see this module and others don't, but where we expect the //impact// of this test to surface after users engage with the module and arrive at Review Changes, we want to make this module flashy/attention grabbing/engaging. The higher % of users who see this module who engage with it, the stronger our signal will be on whether this feature drives participation or not.
T431016: Move DE1.3 (editor second-week retention) into GrowthBook
Task
**User Story:** As part of the WMF Contributors Growth, I need Key Result metrics to be available and compatible in GrowthBook so that planned experiments can use them to measure outcomes. Related: {T424695} **Description:** All DE (Deepen Engagement) Key Results have a defined metric, but those metrics aren't yet defined in GrowthBook or aren't compatible with event-based architecture. This task tracks the work needed to make the KR metrics usable as an experiment metric in GrowthBook. This is an enabler task, sequenced ahead of the experiments that depend on it. - KR: DE1.3 - https://www.mediawiki.org/wiki/Personal_Dashboard - Metric: Editor second-week retention - Hypothesis: By the end of Q2, achieve at least a 12% relative increase in second-week retention for editors who are presented with interventions focused on editor progression through controlled experiments, compared to editors in the control group. **Acceptance Criteria: ** [] Editor second-week retention available in GrowthBook //Timeline: ideally we have this metric available in GrowthBook by the end of August, 2026. //
T430794: At Special:CommunityConfiguration/Mentorship, separate the sections (eligibility, experienced users and suspension) to improve readability
Task
Special:CommunityConfiguration/Mentorship has more and more options, which makes it complicated to skim. Adding section title could help. It could be something like this: {F91425699} Titles in the mockup are: - Mentorship eligibility - Mentorship for experienced users - Mentors suspension and removal
T430790: Special:CreateAccount: increase button-size and drop mobile logo and notice message
Task
In the V1 experiment (T415659), which was also included in the V2 iteration, we removed visual clutter from the Special:CreateAccount page, and made the "Create Account" button more prominent. These changes should now be upstreamed as the new experience for everyone. **Acceptance criteria** * [ ] The wiki logo is removed from the mobile version of Special:CreateAccount and Special:UserLogin * [ ] The notice message is removed from the mobile version of Special:CreateAccount and Special:UserLogin * [ ] The "Create Account" button has its size increased on both mobile and desktop * [ ] If there was related experiment code in GrowthExperiments, then it has been removed * The following aspects should be verified as working as expected: * Special:Create Account, Special:UserLogin * visiting/using these pages as anonymous, temporary, or named user * visiting/using these pages both on desktop (=Vector2022) and on mobile (=Minerva)
T430760: [EPIC] Modernize and integrate Impact metrics into the Personal Dashboard (DE1.3.2, FY26-27)
Task
As part of the DE1.3 Personal Dashboard initiative, show Impact metrics (from the Newcomer Homepage) on the Personal Dashboard (while modernizing the underlying architecture to support long-term scalability, maintainability, and ownership). This Epic encompasses product, engineering, and platform work needed to evolve Impact from a newcomer-specific feature into a shared contributor experience that can serve editors throughout their editing journey. **Hypothesis: ** If we add Impact data to the Personal Dashboard, then this will help unblock a future experiment to compare the new Dashboard layout vs. the current Homepage. ## Background The Growth team's Impact module helps contributors understand the value of their work by surfacing metrics such as article pageviews, editing activity, and other contribution statistics. While the feature has been successful in reinforcing contributor motivation, its current implementation reflects its origins as a Growth MVP. The Personal Dashboard (DE1.3) envisions a central home for Wikimedia users that brings together reading tools, contribution tools, personalized recommendations, and meaningful visibility into a user's activity and impact. As part of that vision, Impact metrics should become a core component of the dashboard experience rather than remaining exclusive to the Newcomer Homepage. At the same time, the current implementation presents technical and ownership challenges: * The existing Impact APIs were developed as an MVP and are not intended to support long-term growth or highly prolific contributors. * Much of the implementation lives within the GrowthExperiments extension, making future ownership by other teams more difficult. * The longer-term ownership model anticipates the Connections team maintaining Impact metrics, requiring a clearer separation of responsibilities and supported platform interfaces. This Epic coordinates the work needed to address these product and technical goals. ## Goals * Integrate Impact metrics into the Personal Dashboard experience. * Establish the Personal Dashboard as the primary location for contributor activity and impact information. * Improve scalability to support contributors across a wide range of editing activity. * [TBD] Transition from the existing Growth Impact APIs to supported Wikimedia DPE APIs where appropriate. * [TBD] Reduce technical debt by separating Impact functionality from GrowthExperiments where practical. ## Potential workstreams * **Product and UX**: Design how Impact metrics are presented within the Personal Dashboard. * **Engineering: Impact data on Dashboard:** Implement Impact metrics within the Personal Dashboard. * **API and backend modernization**: Evaluate supported Wikimedia DPE APIs that can replace Growth-owned services. * **Architecture and code ownership**: Identify if GrowthExperiments code needs to be relocated or refactored.
T430697: Update the password fields to conform with the V1/V2 experiment changes
Task
As part of the V2 experiment for Special:Create Account (T422295, which included the changes from the V1 experiment), we made a number of changes to the password field on that page. This task is about upstreaming these changes into mediawiki core. **Acceptance criteria** * [x] The GrowthExperiments extension no longer has code modifying the password fields on Special:CreateAccount or Special:UserLogin * [x] The adjustments that were made during the experiment to these fields for the treatment group are now available in MediaWiki core as the default experience. * The following aspects should be verified as working as expected: * Special:Create Account, Special:UserLogin * visiting/using these pages as anonymous, temporary, or named user * visiting/using these pages both on desktop (=Vector2022) and on mobile (=Minerva) * when logged-in: checking the check-box that says "Use a temporary random password and send it to the specified email address"
T430604: Account Creation form: Simplify username guidance based on experiment data and user research
Task
As part of the English Wikipedia V2 Account Creation experiment, we updated the username helper text to: >**[Choose carefully](https://en.wikipedia.org/wiki/Wikipedia:Username_policy)** - it's how the community will know you. The expanded Username policy (TL;DR) panel also includes links to sections of the English Wikipedia username policy: https://en.wikipedia.org/wiki/Wikipedia:Username_policy {F91142981} ####Problems Early experiment results suggest that the overall Account Creation form improvements have increased account creation rates. However, very few users engage with the username guidance: Fewer than 4% of users expand the username helper text. Of those users, only a small percentage continue on to the full username policy. We should be sure that the username help text is as succinct as possible, but contains the most important information we want all new accounts to be aware of. The current implementation also creates localization challenges. The TL;DR panel links to specific sections of the English Wikipedia username policy, but many wikis do not have equivalent sections or policy structures. This makes the content difficult to translate and maintain across Wikimedia projects. ##### Background User testing (2026-04-30) found: > Nobody opened the 'Choose carefully' drawer. The link, which expands a panel with username policy guidance, was ignored by most participants. Those who did notice it didn't tap it. One participant (P9) explained they assumed it was a hyperlink that would navigate away from the page: 'I would have preferred just a little info button that I could tap and it pops up.' This combines with the form autopilot finding to point at a broader pattern: participants in familiar form flows don't read inline text, whether it's displayed openly or hidden behind a control. It's worth being direct about what this means for username policy communication - there's no strong evidence from this study (or past studies) that users will discover or read that guidance regardless of how it's presented. This pattern holds across multiple studies: people move through familiar forms on autopilot and rarely read instructional text, whether it's visible or tucked behind an expandable control. Changing how the guidance is presented is unlikely to meaningfully increase engagement with it. What does matter is form length: the more text on the page ---> the longer the form appears ---> the less likely people are to complete the form. #### Included as part of this task: ##### 1. Improve the inline Username helper text Community feedback suggests that the current copy ("Choose carefully") is vague and does not clearly communicate why usernames matter. English Wikipedia is also discussing ways to ensure newcomers are aware that they may want to avoid using their real name: https://en.wikipedia.org/wiki/MediaWiki_talk:Createacct-username-help Suggestions include: >Avoid using your real name. (Why?) or >Your username is public and cannot be made private later. Avoid using your real name. (Why?) From a newcomer-friendly perspective, the helper text should be as clear, concise, and actionable as possible. ##### 2. Reconsider how users access additional guidance User research indicates that many participants assumed the expandable helper would navigate them away from the form, so they ignored it entirely. Instead of using expandable helper text, consider an information icon or similar affordance that more clearly communicates that tapping it will display additional information without leaving the page. > - text "Avoid using your real name." > - add a codex icon-only small quiet button next to the codex field description > - set the icon of the button to `cdxHelpNoticeFilled` > - on tap the button opens a codex popover > {F91567939} ----- ####Acceptance Criteria: **Updated inline helper text is displayed** Given a user is on the account creation form When the username field is rendered Then the field description reads "Avoid using your real name." (And the previous text "Choose carefully" is not present) **Help icon button is visible next to the username field description** Given a user is on the account creation form When the username field is rendered Then an icon-only quiet button using the `cdxHelpNoticeFilled` icon is displayed adjacent to the field description And the button has an accessible label (e.g. "More information about usernames") **Tapping the help icon opens a popover** Given a user is on the account creation form And the username help icon button is visible When the user taps the help icon button Then a Codex popover opens And the popover contains username guidance content And the user remains on the account creation form **Popover can be dismissed** Given the username help popover is open When the user taps outside the popover or closes it Then the popover closes And the user remains on the account creation form with their progress intact **Popover provides access to open username policy** Given the username help popover is open When the user taps on "Read the full username policy" Then a new tab opens the associated wikis' username policy (Q4664077) Example for enwiki: https://en.wikipedia.org/wiki/Wikipedia:Username_policy [] enwiki Community should be updated here: https://en.wikipedia.org/wiki/MediaWiki_talk:Createacct-username-help#Technological_iteration
T430586: Red link for talk pages is no longer rendered correctly in Vector
Task
**Steps to replicate the issue** (include links if applicable): * Go to https://en.wikipedia.org/wiki/Main_Page?useskin=vector or https://en.wikipedia.org/wiki/Main_Page with an account without a talk page * Observe the blue talk link instead of a red one **What happens?**: ```lang=html <li id="pt-mytalk" class="new mw-list-item"><a href="/wiki/User_talk:Stjn_(bot)" title="Your talk page (page does not exist) [Alt+n]" accesskey="n"><span>Talk</span></a></li> ``` **What should have happened instead?**: `.new` CSS class should be on the link itself and not on the list item. Don’t know how recent it is but it is definitely a regression from something specifically for talk page links: {F91114507}
T430581: Analyze the impact of WE1.8 account creation improvements on registration rates (WE1.8 FY 25-26)
Task
Although each WE1.8 experiment was released as an A/B test, those experiments only measure the impact on a subset of users during the pilot phase. They do not capture the overall effect on permanent (non-temporary) account registrations once features are rolled out more broadly. The goal of this analysis is to estimate the impact of the WE1.8 experiments on permanent account creation across Wikimedia wikis. This will likely require correlating experiment rollout timelines with changes in registration rates to understand which releases contributed to meaningful increases (or decreases) in account creation, and by approximately how much. Early analysis suggests that the initial rollout of WE1.8.2 (the improved logged-out edit warning) was associated with an increase in account registrations. However, this rollout coincided with the Reading Challenge and other initiatives, making it difficult to isolate the contribution of any single change. {F91110256} --- WE1.8 (Wiki Experience 1.8) is a product initiative focused on reducing friction in the account creation and registration flow across Wikimedia wikis. https://www.mediawiki.org/wiki/Contributors/Account_Creation_Experiments Experiments under this Key Result consisted of a series of experiments that were released in phases: - Phase 1: A/B tests on pilot wikis with a subset of users to measure the impact of individual changes. - Phase 2: Full rollout of successful experiments to all eligible wikis. **Essentially this task is about measuring the impact of Phase 2. ** ----- ####Account Creation experiments: | Experiment name | Experiment report | Pilot Wikis | Phase 1: Pilot experiment release date | Phase 2: Full release date | | ------------------------------- | -------------------------------- | ----------------- | ----------------------------- | ----------------- | | WE1.8.2 Logged out edit warning | [[ https://superset.wikimedia.org/superset/dashboard/789fbd08-6730-431b-827d-749a0481c895/?native_filters_key=U7-3XO_d4i3UoLImFx4vdwuJKgZxKGpChmUdSsa7shsB6Jh3y_P6vVtc34tbpY2S | Test Kitchen experiment results ]] | arwiki, frwiki, eswiki, dewiki, ruwiki, zhwiki, itwiki, ptwiki, fawiki, plwiki | 2026-03-17 | 2026-06-04 | | WE1.8.3 Account Creation Form improvements V2 | [[ https://growthbook.wikimedia.org/experiment/exp_10ipnmqb88wy4#results | Growth Book experiment results ]] | enwiki | V1: 2026-04-13 , V2: 2026-05-21 | TBD | | WE1.8.4 Mobile Account menu | [[ https://superset.wikimedia.org/superset/dashboard/789fbd08-6730-431b-827d-749a0481c895/?native_filters_key=U7-3XO_d4i3UoLImFx4vdwuJKgZxKGpChmUdSsa7shsB6Jh3y_P6vVtc34tbpY2S | Test Kitchen experiment results ]] | Hindi Wikipedia, Indonesian Wikipedia, Bengali Wikipedia, Thai Wikipedia, Hebrew Wikipedia | 2026-03-31 | 2026-07-02 | | WE1.8.5 Reading List | [[ https://growthbook.wikimedia.org/experiment/exp_10ipnmqbj1zeo#results | Growth Book experiment results ]] | dewiki, eswiki, itwiki, ptwiki, plwiki, nlwiki, trwiki, urwiki | | | | WE1.8.6 Temporary Accounts | [[ https://growthbook.wikimedia.org/experiment/exp_10ipnmqzch3jt#overview | Growth Book experiment dashboard ]] | arwiki, frwiki, eswiki | 2026-05-30 | TBD | ----- ####Deliverables TBD: Attribution model with estimated contribution of WE1.8 to high-level registration metrics
T430418: Design for account set-up (Welcome Survey 2.0)
Task
#####User story As a new account holder, I want to be guided through a brief, meaningful setup experience after creating my account, so that my homepage/dashboard and first steps on the wikis reflect what I actually care about. #####Background The current Welcome Survey introduces friction at a critical moment in the user journey (immediately after account creation) without offering any clear user-benefit in return. Key issues: - Interrupts momentum: Users are prompted with a survey before they have a clear sense of what they want to do. - Low perceived value: The purpose of the survey is not clear to users, and it does not provide immediate, visible benefits. - Redundant data collection: Much of the same intent can be inferred from user behavior (entry point, early actions). - WMF and the Community has limited visibility into responses {T394559} The Growth team is shifting toward a model where the onboarding experience actively serves the newcomer — not just data collection — by: - Using survey responses to immediately shape the newcomer homepage (or personal dashboard) and suggested first tasks - Reframing questions around the newcomer's goals and interests, not WMF research needs - Reducing question count and replacing open-ended fields with visual, low-friction choices - Connecting each question explicitly to a visible outcome ("We'll suggest tasks based on this") - Inferring additional intent from behavior and entry points to reduce repetition over time #####Open questions - Which homepage modules or features can realistically be personalized based on survey input in the near term? - What is the minimum number of questions needed to produce a meaningfully differentiated first experience? - Should the redesigned survey be skippable, and if so, what default experience do skippers receive? #####Acceptance criteria - Account-set up responses immediately influence at least one element of the newcomer homepage (e.g. suggested edits, etc.) - Users who skip the survey receive a sensible default homepage (dashboard) state - Design for a multivariate test: a multi-step design and a one-step design NOTE: this task is about designing the first step that we can test ASAP, and shouldn't be blocked by the Homepage/Dashboard transition.
T430380: Revise Tone Structured Task: add more advanced Community Configuration
Task
As a Wikipedia Admin, I want Revise Tone to be community configurable, so that I decide if the task is available and determine how is should be configured to best meet the needs at my wiki. ####Background: All Suggested Edits are configurable via `Special:CommunityConfiguration/GrowthSuggestedEdits` As we release Revise Tone to all wikis supported by the Tone Check model, we should ensure wikis have access to the basic Community Configuration options they need. ####Design: Final design and copy TBD ####Acceptance Criteria: Given I am on a wiki where **Revise Tone** is available, When I visit `Special:CommunityConfiguration/GrowthSuggestedEdits`, Then I see a section called **Revise Tone**. //Within the Revise Tone section, the following configuration fields are present:// **Link to learn more about this task** Specify a wiki page or URL where users can learn more about the Revise Tone task type. **Minimum time since last edit** Only surface articles that have not been edited within the last X hours. Default: 24 hours **Minimum article age** Only surface articles created at least X days ago. Default: 90 days **Minimum confidence score** Only surface suggestions with a confidence score of at least X. Default: 0.8
T430337: Vector 2022 should use user icon for Log in/Create account dropdown on small resolutions
Task
**Steps to replicate the issue** (include links if applicable): * Go to https://en.wikipedia.org/wiki/Main_Page?useformat=mobile&useskin=vector-2022 * Get the window to 600px **What happens?**: {F90598084} Gets extremely confusing with three dots in both directions. **What should have happened instead?**: This icon should be used for this dropdown: {F90598203}
T430232: Design personalized Suggested Edits feed for the Personal Dashboard
Task
#####User Story As a contributor, I want my dashboard to recommend tasks that are relevant to my interests and previous activity so that I can quickly find meaningful ways to contribute without having to search through large backlogs of work. #####Description Design an initial experience for a personalized Suggested Edits feed within the Personal Dashboard. The goal is to move beyond generic task recommendations by surfacing a small set of meaningful, relevant editing opportunities based on what we already know about the contributor. The design should explore both the user experience and the recommendation logic that determines which tasks are shown. Areas to consider: * What signals should be used to personalize recommendations (for example, the article a user was reading when they created their account, selected interests, bookmarks, watchlist, recent editing history, etc.). * How recommendations should evolve as contributors gain experience and build an editing history. * How tasks should be presented to encourage action without overwhelming contributors. * How the experience can support both newcomers, junior, and more experienced editors. * How can the design shift from a large, impersonal task pool to a smaller and more curated feed that helps contributors quickly identify relevant and meaningful opportunities to contribute. #####Acceptance criteria * Initial UX designs are created for a personalized Suggested Edits feed within the Personal Dashboard. * Recommendation logic is documented, including the personalization signals used to generate suggestions. * The design considers an approach for evolving recommendations as contributors gain experience. * The design presents a smaller and more curated set of relevant tasks instead of emphasizing the total number of available suggestions. * Design rationale and open questions are documented to support future experimentation and implementation. NOTE: there is longer-term research starting (Research recommendation algorithms for contributors and moderators) that relates to a more complex recommendation system, but this task is about exploring the design and the early POC release that uses existing APIs. In other words, this POC release might be blocked by {T430058}, but it should not be blocked based on needing a more complex recommender system.
T430230: Suggested edits feed: Explore personalized recommendations based on contributor interests and editing history
Task
####**User need** As a contributor, I want the Suggested Edits feed to recommend meaningful tasks related to topics I care about so I can easily find impactful ways to contribute and remain engaged over time. ####**Description** As part of the unified Personal Dashboard initiative, explore how personalized task recommendations could help contributors discover meaningful work based on their interests and past contributions. Today, Suggested Edits primarily support newcomers with simple editing tasks. This investigation should evaluate how the same recommendation infrastructure could evolve to serve contributors across experience levels by surfacing opportunities that align with a contributor's demonstrated interests, expertise, and editing history. //Receiving 'articles about topics I usually edit about' and visual charts of one's edit types were newcomers' top 2 features of interest:// {F90502159} This work should: * Review existing recommendation systems (for example, Suggested Edits, Newcomer Tasks, and Content Translation) and identify opportunities to reuse or extend them. * Identify potential signals for personalization, such as selected interests, editing history, topic affinity, WikiProjects, or other contributor activity. * Define an initial set of high-value task types that could be personalized for experienced contributors. * Produce concepts or prototypes that could be tested through the Personal Dashboard.
T430089: Proposal: provide a database report of unanswered questions delay
Task
In order to determine whether and when to auto-suspend or remove a mentor, we want to assess whether mentees are being well-served, in particular, whether their questions are being answered and how long it is taking to get an answer. Proposal: provide a database report showing statistics about mentee questions and the delay involved in answering them. Ideally, I'd like to see a summary report with totals and averages, followed by various detail reports activated by dropdowns or fill-in fields, perhaps a bit like the [[https://pageviews.wmcloud.org/?project=en.wikipedia.org&platform=all-access&agent=user&redirects=0&range=latest-30&pages=Wikipedia:FAQ | page views tool]]. One detail report should be a sortable, by-mentor list showing delay stats (avg, SD, etc.) ideally along with time-series graphs so we can spot trends. I can go into further detail if there is interest. Note that as a secondary benefit, having these reports available will enable willing mentors (and other volunteers) to temporarily fill in answering questions that are lagging too long before they are re-assigned. Currently, such unanswered questions are not easy to find. I can envision a q&d method to at least provide a window into the issue: alter the procedure that places mentee questions on mentor talk pages to include parser conditionals (or a template that I can provide) that, after delay X, categorizes the mentor UTP into [[https://en.wikipedia.org/w/index.php?title=Category:Mentor_pages_with_mentee_questions_unanswered_longer_than_one_week | Category:Mentor pages with mentee questions unanswered longer than X]], and define various delay milestones of interest; perhaps: three days, one week, ten days. This raises this related question: when you suspend an inactive mentor, what happens to unanswered questions already on their page before suspension?
T430058: Account Set up / Welcome Survey 2.0 (DE1.3)
Task
#####User story As a new account holder, I want to be guided through a brief, meaningful setup experience after creating my account, so that my dashboard and first steps on the wikis reflect what I actually care about. #####Background The current Welcome Survey introduces friction at a critical moment in the user journey (immediately after account creation) without offering any visible benefit in return. Key issues: - Interrupts momentum: Users are prompted with a survey before they have a clear sense of what they want to do. - Low perceived value: The purpose of the survey is not clear to users, and it does not provide immediate, visible benefits. - Redundant data collection: Much of the same intent can be inferred from user behavior (entry point, early actions). - WMF and the Community has limited visibility into responses {T394559} The Growth team is shifting toward a model where the onboarding experience actively serves the newcomer — not just data collection — by: - Using survey responses to immediately shape the newcomer homepage (or personal dashboard) and suggested first tasks - Reframing questions around the newcomer's goals and interests, not WMF research needs - Reducing question count and replacing open-ended fields with visual, low-friction choices - Connecting each question explicitly to a visible outcome ("We'll suggest tasks based on this") - Inferring additional intent from behavior and entry points to reduce repetition over time #####Open questions - Which homepage modules or features can realistically be personalized based on survey input in the near term? - What is the minimum number of questions needed to produce a meaningfully differentiated first experience? - Should the redesigned survey be skippable, and if so, what default experience do skippers receive? - How do we A/B test and measure whether the redesigned survey improves newcomer activation vs. the current version? #####Acceptance criteria - The redesigned welcome experience is shown after account creation on all platforms - Each question is accompanied by a visible explanation of how the answer will affect the user's experience - Survey responses immediately influence at least one element of the newcomer homepage (e.g. suggested edits, etc.) - Users who skip the survey receive a sensible default homepage state - Time-to-first-edit (or equivalent activation metric) is not negatively impacted vs. the baseline - Completion rate of the new survey meets or exceeds a defined target threshold
T429871: Allow "Named Entity Recognition for Add-a-Link" to present links to other Wikipedias
Task
**Feature summary** (what you would like to be able to do and where): E.g. in case of T405185#11391268, if NER wants to suggest a link to Agricultural Bank of France but there is no such article in this project, it could somehow suggest a link to another Wikipedia which then (by the tool that utilizes add-a-link model -- e.g. Add-a-Link task or EditCheck) gets formatted using [[ https://www.wikidata.org/wiki/Q13606208 | this template ]] or [[ https://www.wikidata.org/wiki/Q128590885 | this template ]].
T429855: Growth Team Newsletter: July 2026
Task
####User story & summary: As the Growth team, I want to be sure we are proactively sharing team news, because we appreciate community involvement and feedback on our work. https://www.mediawiki.org/wiki/Growth/Newsletters ####Background: (From Kirsten) We've been busy and @Trizek-WMF and I haven't had as much time for community outreach as I wish we could, and we are overdue at publishing a Newsletter. My suggestion is that this newsletter focus on these four things: - https://www.mediawiki.org/wiki/Contributors/Account_Creation_Experiments - https://www.mediawiki.org/wiki/Growth/Revise_Tone - Community Requested changes, like {T321509} / https://www.mediawiki.org/wiki/Help:Growth/Mentorship#Automated_mentor_list_cleanup - Upcoming work: {https://phabricator.wikimedia.org/T419358} / https://www.mediawiki.org/wiki/Personal_Dashboard Ideas for the newsletter can also be pulled from: - https://www.mediawiki.org/wiki/Growth/Growth_team_updates - Completed Growth team work in Phab - Asana annual planning reports ####Acceptance Criteria: [] Draft Newsletter [] Share draft with @KStoller-WMF & #growth-team and ask for feedback [] Finalize Newsletter, add to: https://www.mediawiki.org/wiki/Growth/Newsletters [] Mark for translation and coordinate translations [] Share Growth Newsletter with subscribers
T429797: [Epic] Personalised dashboard explore feed for new editors - Technical Exploration
Task
####Background & research: As part of the DE 1.3 hypothesis, one of the explorations on driving second-week editor retention centers on displaying tasks that a new editor can undertake in a feed style. While a Q1 FY26-27, exploration will mostly focus on testing the feed style itself using the existing suggested edits endpoint, at some point in Q2 FY26-27 building a personalised "Explore" feed that accepts multiple feed sources other than Suggested edits will be attempted. High level discussions are ongoing to figure out key issues like: - **How to approach Personalisation** - What sources do we use to aggregate articles e.g. last-edited, watchlist, saved articles. Which sources are the most relevant to consider e.t.c.? - **How to approach Orchestration of various feed sources** - What will handle the orchestration of different feed sources and provide a common entry point to getting the feed? A dedicated extension / A module in an existing extension that then gets extracted into a dedicated extension later on? - **How to serve the feed Optimally** - Will the feed be pre-computed? Is it going to use caching? Will it use a job to handle feed population in the database? This Epic could be a central place to track the related technical exploration work related to the multi-source explore feed, since this will most likely be a multi-team effort. ####Design: An early exploration by @AAlhazwani-WMF of how the "Explore feed" could look like: {F89967891} ####Architecture: An early data flow proposal by @Michael after a chat with @Mooeypoo on how the explore feed could work {F89967996}
T429784: hCaptcha: Show privacy policy text in suggested edits
Task
== Summary The suggested edits publish dialog doesn't show the hCaptcha privacy policy / terms of use: {F89954989} compare with: {F89955065} == Acceptance criteria - [ ] Suggested edits publish dialog contains the hCaptcha privacy policy / terms of use links
T429555: Homepage metrics: snapshot of available metrics
Task
####User story & summary: As the Connections Team, Moderator Tools team, and the Contributor Growth Team, we want access to data that provides visibility into how users interact with the Homepage, so that we can make informed product decisions about features such as Impact Data, Mentorship, Suggested Edits, Community Updates, and future Homepage investments. ####Data needs: Data snapshot that ideally includes: * Homepage visits * Unique users visiting the Homepage * Homepage visit frequency * Homepage return rate For each Homepage module: * Unique users exposed to the module * Click-through rate * Interaction rate * Module-specific engagement events Question: can we get this data for the Email/Start module and Community Updates too? ####Segmentation Where possible, data breakdowns by: * Wiki * Platform (desktop/mobile) * User bucket / tenure? * Time period ####Acceptance Criteria * Timeboxed to ~2 days; if that means we are missing some of the above data or segmentation, that's fine. * Teams can use this data to evaluate engagement with Homepage modules and identify opportunities for future improvements.
T429462: GrowthExperiments refreshLinkRecommendations.php: TypeError: MediaWiki\ExternalStore\ExternalStoreDB::getDomainId(): Argument #1 ($server) must be of type array, false given
Task
==== Error ==== * mwversion: 1.47.0-wmf.6 * timestamp: 2026-06-17T09:35:54.278Z * phpversion: `8.3.31` * reqId: `f04e074b0b4385813ea73966` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2026-06-16T09:35:54.278Z',to:'2026-06-17T10:59:58.069Z'))&_a=(query:(query_string:(query:'reqId:%22f04e074b0b4385813ea73966%22'))) | Find reqId in Logstash ]] ```name=normalized_message,lines=10 [{reqId}] {exception_url} TypeError: MediaWiki\ExternalStore\ExternalStoreDB::getDomainId(): Argument #1 ($server) must be of type array, false given, called in /srv/mediawiki/php-1.47.0-wmf.6/includes/ExternalStore/ExternalStoreDB.php on line 159 ``` | Frame | Location | Call | -- | -- | -- | from | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/ExternalStore/ExternalStoreDB.php#186 | /srv/mediawiki/php-1.47.0-wmf.6/includes/ExternalStore/ExternalStoreDB.php(186) ]] | | #0 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/ExternalStore/ExternalStoreDB.php#159 | /srv/mediawiki/php-1.47.0-wmf.6/includes/ExternalStore/ExternalStoreDB.php(159) ]] | MediaWiki\ExternalStore\ExternalStoreDB->getDomainId(bool) | #1 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/ExternalStore/ExternalStoreDB.php#299 | /srv/mediawiki/php-1.47.0-wmf.6/includes/ExternalStore/ExternalStoreDB.php(299) ]] | MediaWiki\ExternalStore\ExternalStoreDB->getReplica(string) | #2 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/ExternalStore/ExternalStoreDB.php#58 | /srv/mediawiki/php-1.47.0-wmf.6/includes/ExternalStore/ExternalStoreDB.php(58) ]] | MediaWiki\ExternalStore\ExternalStoreDB->fetchBlob(string, string, bool) | #3 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/ExternalStore/ExternalStoreAccess.php#62 | /srv/mediawiki/php-1.47.0-wmf.6/includes/ExternalStore/ExternalStoreAccess.php(62) ]] | MediaWiki\ExternalStore\ExternalStoreDB->fetchFromURL(string) | #4 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/Storage/SqlBlobStore.php#533 | /srv/mediawiki/php-1.47.0-wmf.6/includes/Storage/SqlBlobStore.php(533) ]] | MediaWiki\ExternalStore\ExternalStoreAccess->fetchFromURL(string, array) | #5 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/libs/ObjectCache/WANObjectCache.php#1830 | /srv/mediawiki/php-1.47.0-wmf.6/includes/libs/ObjectCache/WANObjectCache.php(1830) ]] | MediaWiki\Storage\SqlBlobStore->MediaWiki\Storage\{closure}(bool, int, array, null, array) | #6 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/libs/ObjectCache/WANObjectCache.php#1640 | /srv/mediawiki/php-1.47.0-wmf.6/includes/libs/ObjectCache/WANObjectCache.php(1640) ]] | Wikimedia\ObjectCache\WANObjectCache->fetchOrRegenerate(string, int, Closure, array, array) | #7 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/Storage/SqlBlobStore.php#527 | /srv/mediawiki/php-1.47.0-wmf.6/includes/Storage/SqlBlobStore.php(527) ]] | Wikimedia\ObjectCache\WANObjectCache->getWithSetCallback(string, int, Closure, array) | #8 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/Storage/SqlBlobStore.php#310 | /srv/mediawiki/php-1.47.0-wmf.6/includes/Storage/SqlBlobStore.php(310) ]] | MediaWiki\Storage\SqlBlobStore->expandBlob(string, array, string) | #9 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/Storage/SqlBlobStore.php#226 | /srv/mediawiki/php-1.47.0-wmf.6/includes/Storage/SqlBlobStore.php(226) ]] | MediaWiki\Storage\SqlBlobStore->fetchBlobs(array, int) | #10 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/libs/ObjectCache/WANObjectCache.php#1830 | /srv/mediawiki/php-1.47.0-wmf.6/includes/libs/ObjectCache/WANObjectCache.php(1830) ]] | MediaWiki\Storage\SqlBlobStore->MediaWiki\Storage\{closure}(bool, int, array, null, array) | #11 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/libs/ObjectCache/WANObjectCache.php#1640 | /srv/mediawiki/php-1.47.0-wmf.6/includes/libs/ObjectCache/WANObjectCache.php(1640) ]] | Wikimedia\ObjectCache\WANObjectCache->fetchOrRegenerate(string, int, Closure, array, array) | #12 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/Storage/SqlBlobStore.php#221 | /srv/mediawiki/php-1.47.0-wmf.6/includes/Storage/SqlBlobStore.php(221) ]] | Wikimedia\ObjectCache\WANObjectCache->getWithSetCallback(string, int, Closure, array) | #13 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/Revision/RevisionStore.php#1150 | /srv/mediawiki/php-1.47.0-wmf.6/includes/Revision/RevisionStore.php(1150) ]] | MediaWiki\Storage\SqlBlobStore->getBlob(string, int) | #14 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/Revision/RevisionStore.php#1462 | /srv/mediawiki/php-1.47.0-wmf.6/includes/Revision/RevisionStore.php(1462) ]] | MediaWiki\Revision\RevisionStore->loadSlotContent(MediaWiki\Revision\SlotRecord, null, null, null, int) | #15 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/Revision/SlotRecord.php#307 | /srv/mediawiki/php-1.47.0-wmf.6/includes/Revision/SlotRecord.php(307) ]] | MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}(MediaWiki\Revision\SlotRecord) | #16 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/Revision/RevisionRecord.php#170 | /srv/mediawiki/php-1.47.0-wmf.6/includes/Revision/RevisionRecord.php(170) ]] | MediaWiki\Revision\SlotRecord->getContent() | #17 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/NewcomerTasks/AddLink/LinkRecommendationUpdater.php#211 | /srv/mediawiki/php-1.47.0-wmf.6/extensions/GrowthExperiments/includes/NewcomerTasks/AddLink/LinkRecommendationUpdater.php(211) ]] | MediaWiki\Revision\RevisionRecord->getContent(string) | #18 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.47.0-wmf.6/includes/NewcomerTasks/AddLink/LinkRecommendationUpdater.php#95 | /srv/mediawiki/php-1.47.0-wmf.6/extensions/GrowthExperiments/includes/NewcomerTasks/AddLink/LinkRecommendationUpdater.php(95) ]] | GrowthExperiments\NewcomerTasks\AddLink\LinkRecommendationUpdater->evaluateTitle(MediaWiki\Page\PageIdentityValue, MediaWiki\Revision\RevisionStoreRecord, bool) | #19 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.47.0-wmf.6/maintenance/refreshLinkRecommendations.php#359 | /srv/mediawiki/php-1.47.0-wmf.6/extensions/GrowthExperiments/maintenance/refreshLinkRecommendations.php(359) ]] | GrowthExperiments\NewcomerTasks\AddLink\LinkRecommendationUpdater->processCandidate(MediaWiki\Page\PageIdentityValue, bool) | #20 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.47.0-wmf.6/maintenance/refreshLinkRecommendations.php#216 | /srv/mediawiki/php-1.47.0-wmf.6/extensions/GrowthExperiments/maintenance/refreshLinkRecommendations.php(216) ]] | GrowthExperiments\Maintenance\RefreshLinkRecommendations->processCandidate(MediaWiki\Page\PageIdentityValue, bool) | #21 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.47.0-wmf.6/maintenance/refreshLinkRecommendations.php#148 | /srv/mediawiki/php-1.47.0-wmf.6/extensions/GrowthExperiments/maintenance/refreshLinkRecommendations.php(148) ]] | GrowthExperiments\Maintenance\RefreshLinkRecommendations->refreshByIteratingThroughAllPages(bool) | #22 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/maintenance/includes/MaintenanceRunner.php#692 | /srv/mediawiki/php-1.47.0-wmf.6/maintenance/includes/MaintenanceRunner.php(692) ]] | GrowthExperiments\Maintenance\RefreshLinkRecommendations->execute() | #23 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.6/maintenance/run.php#53 | /srv/mediawiki/php-1.47.0-wmf.6/maintenance/run.php(53) ]] | MediaWiki\Maintenance\MaintenanceRunner->run() | #24 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+blame/refs/heads/master/multiversion/MWScript.php#219 | /srv/mediawiki/multiversion/MWScript.php(219) ]] | require_once(string) | #25 | {main} | ==== Impact ==== ==== Notes ====
T429417: When a Link Suggestion is reverted, the same suggestion should not be suggested again
Task
As an experienced editor reviewing Add a Link edits, I want suggestions that are reverted to be automatically removed, so that newcomers are less likely to encounter and accept known bad suggestions. ####Problem: The Add a Link system currently learns from explicit newcomer feedback. When a newcomer declines a suggestion, that signal is used to prevent the suggestion from being shown again. However, if a newcomer accepts a suggestion and publishes the edit, the system treats that as a successful outcome. If the edit is later reverted by another editor because the link was incorrect, that revert is not currently incorporated into suggestion quality controls. As a result, the same incorrect suggestion may continue to be surfaced to other newcomers, creating repeated cleanup work for experienced editors. ####Community Feedback: [[ https://www.mediawiki.org/wiki/Talk:Growth#c-Flibirigit-20260616215000-Feedback_on_link_suggestion_tool | Feedback from enwiki ]]: I have noticed multiple instances where the link suggestion tool resulted in adding a link that does not fit the context, specifically a similarly named organization from a different era. Three times I have had to revert the addition of Eastern Canada Amateur Hockey Association (ECAHA) to Cecil Duncan: * [Cecil Duncan: Difference between revisions](https://en.wikipedia.org/w/index.php?title=Cecil_Duncan&diff=1326355070&oldid=1251199023) * [Cecil Duncan: Difference between revisions](https://en.wikipedia.org/w/index.php?title=Cecil_Duncan&diff=next&oldid=1340172795) * [Cecil Duncan: Difference between revisions](https://en.wikipedia.org/w/index.php?title=Cecil_Duncan&diff=next&oldid=1348497971) It has also happened in other articles: * [W. B. George: Difference between revisions](https://en.wikipedia.org/w/index.php?title=W._B._George&diff=1337640818&oldid=1335538725) * [W. R. Granger: Difference between revisions](https://en.wikipedia.org/w/index.php?title=W._R._Granger&diff=prev&oldid=1352538569) The ECAHA existed from 1906 to 1909. It is not the same organization as the similarly named association from the 1940s. I'm not sure what the best solution is, but it is frustrating to repeatedly revert these edits despite the good intentions of new editors. ####Solution TBD # **Suppress suggestions associated with reverted edits:** Track whether an Add a Link edit is subsequently reverted. If a suggestion is reverted, prevent that exact suggestion from being surfaced again. # **Incorporate revert signals into model training:** Use reverted Add a Link edits as negative training examples when generating future link suggestions. Suggestions that are frequently reverted would reduce the model's confidence in similar suggestions, while accepted and retained suggestions would serve as positive training examples.
T429354: Identify and remove mentors who are active but who don't answer their mentees' questions
Task
Feedback [[ https://fr.wikipedia.org/wiki/Discussion_Projet:Aide_et_accueil#c-Antimuonium-20260616122100-L'embellie-20260616071700 | suggested ]] at French Wikipedia a as a follow up of {T427386}. Some mentors are active editors, but they don't answer their mentees' questions. At the moment, manual messaging is done ([[ https://fr.wikipedia.org/w/index.php?diff=234988110 | example ]]) to encourage these users to stop being mentors. This is a time consuming task which would benefit from any for of assistance at some point.
T429314: PageImages returned 0-height image for page {title}, {fileName}
Task
==== Error ==== * mwversion: 1.47.0-wmf.6 * timestamp: 2026-06-16T10:50:05.116Z * phpversion: `8.3.31` * reqId: `ad12360c-b2af-4827-b54d-e36b42b64087` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2026-06-15T10:50:05.116Z',to:'2026-06-16T10:50:25.419Z'))&_a=(query:(query_string:(query:'reqId:%22ad12360c-b2af-4827-b54d-e36b42b64087%22'))) | Find reqId in Logstash ]] ```name=normalized_message,lines=10 PageImages returned 0-height image for page {title}, {fileName} ``` ```name=,lines=10 exception.trace ``` ==== Impact ==== Unclear. ==== Notes ==== This is happening almost exclusively at `wikidatawiki`, where GrowthExperiments was recently enabled. See {T418115}. However, I can also see few entires for `zhwiki`. Usually, this is associated with PDF files as filenames.
T429188: Notify mentors when they are automatically suspended or removed due to inactivity
Task
As a mentor, I want to receive a notification when I am automatically suspended or removed from the Mentorship program due to inactivity so that I understand why I am no longer mentoring newcomers and can take action if appropriate. ---- The notification clearly explains the reason for the action and any next steps available to the mentor. Notifications are delivered through the standard MediaWiki notification system. ####Acceptance Criteria: When a mentor is automatically suspended due to inactivity, a notification is sent to the mentor. - Notification Copy: TBD When a mentor is automatically removed from the Mentorship program due to inactivity, a notification is sent to the mentor. - Notification Copy: TBD
T429029: [EPIC] Move Account Creation Form Changes from GrowthExperiments to MediaWiki Core
Task
#### Background After concluding the V1 and V2 experiments in T409236, the Account Creation form changes that were deployed will have to be moved to [[ https://www.mediawiki.org/wiki/Core | MediaWiki core ]] to be made widely available for all wikis. #### Acceptance Criteria Move all V1 work: [ ] {T415659} Move all V2 work: [ ] {T419395} [ ] {T419401} [ ] {T419413} [ ] {T423894} [] Remove all A/B related instrumentation from features.
T428885: Drop growthexperiments_* tables from closed wikis
Task
Affected wikis: ``` akwiki nawiki pihwiki ``` List of DB tables: * `growthexperiments_link_recommendations` * `growthexperiments_link_submissions` * `growthexperiments_mentee_data` * `growthexperiments_mentor_mentee` * `growthexperiments_user_impact` Affected cluster: per wiki databases in x1
T428797: [wmf.5-regression] Add image dialog doesn't display image
Task
**Steps to replicate the issue**: * Go on a wiki with Add image tasks enabled (e.g. `frwiki`, `cswiki`) * On the Homepage select "Add an image to an unillustrated article" or "Add an image to an article section") * go to any suggested article with that task **What happens?**: - Add image dialog on an article won't display an image Ex. [[ https://cs.wikipedia.org/w/index.php?title=Shrom%C3%A1%C5%BEd%C4%9Bn%C3%AD_hlav_st%C3%A1t%C5%AF_Africk%C3%A9_unie&gesuggestededit=1&veaction=edit ]] {F87860201} ``` Request URL https://upload.wikimedia.org/wikipedia/commons/thumb/3/3c/Assembly_of_the_African_Union.jpg/320px-Assembly_of_the_African_Union.jpg Request Method GET Status Code 400 Bad Request Referrer Policy strict-origin-when-cross-origin ``` **What should have happened instead?**: - images in the add image dialog should be displayed **Software version**: - checked on chrome and FF - the issue is present on both browsers - the issue is present on mobile too (checked on iPhone) **Other information** (browser name/version, screenshots, etc.): - clicking on the image dialog full screen ( `mw-ge-recommendedImageToolbarDialog-fullScreen-icon `) displays the image correctly - `commons wiki` displays images correctly - upon inserting, images are displayed correctly
T428265: Revise Tone Structured Task: remove experiment instrumentation and automatic analysis code
Task
Now that the Revise Tone Structured Task A/B test is concluding (T426363), clean up the experiment by removing the instrumentation code and the code that drove automatic analysis, following the [Test Kitchen cleanup guidance](https://wikitech.wikimedia.org/wiki/Test_Kitchen/Conduct_an_experiment#Clean_up). ##Acceptance criteria - [ ] Instrumentation/event-logging code specific to the Revise Tone A/B test is removed - [ ] The automatic analysis code/configuration for the experiment is removed ##Notes * See these related PRs: https://gitlab.wikimedia.org/repos/product-analytics/test-kitchen/experiment-analytics-configs/-/merge_requests/?state=merged&search=Revise * Let's keep the aggregated statistics we collect with statslib for https://grafana.wikimedia.org/d/0352e22b-1ebf-4e13-a97d-4f5f05eb8463/revise-tone-structured-task for the time being
T427478: Mentor list cleaner: Disable threshold field when parent checkbox is unchecked
Task
####User story & summary: As an admin, I want the threshold field to be greyed out when its parent checkbox is unchecked so that I cannot set values that have no effect. ####Background & research: When the parent checkbox is off, any value entered in the threshold field is ignored — but the UI currently allows admins to interact with it anyway. This creates confusion about the relationship between the two fields and allows silent misconfigurations. Community feedback (see Slack) flagged this inconsistency with the existing AC, which already specifies "If yes:" as a precondition for the threshold field. ####Design: {F84832992} ####Acceptance Criteria: Given the parent checkbox is unchecked When an admin views the threshold field Then the threshold field is greyed out and non-interactive Given the parent checkbox is checked When an admin views the threshold field Then the threshold field is enabled and editable Given the parent checkbox is unchecked and the threshold field has a previously saved value When an admin views the settings Then the threshold field is greyed out (value may be retained but ignored until the checkbox is re-enabled) All tasks should also meet the Growth Team's task completion definition.
T427477: GrowthExperiments: Mentor list cleaner should reset auto-set away status on mentor edit
Task
## Summary The mentor list cleaner (introduced in T321509) currently does not reset a mentor's away status when that mentor makes an edit. It should clear the status on edit, but only when the status was set automatically by the system (not when the mentor set it manually). ## Acceptance criteria - [ ] When a mentor with an auto-set away status makes an edit, their status is reset to active. - [ ] When a mentor with a manually-set away status makes an edit, their status is preserved.
T427196: [beta-cluster] Fetching task suggestions failed: cirrussearch-backend-error
Task
On beta cluster, SE tasks are not present on Special:Homepage {F84123061} ``` Fetching task suggestions failed: cirrussearch-backend-error cirrussearch-backend-error Object { error: {…}, servedby: "deployment-mediawiki13" } error: Object { code: "cirrussearch-backend-error", info: "We could not complete your search due to a temporary problem. Please try again later." ``` There were some fixes to the `cirrussearch-backend-error`, e.g. {T426529}, but the error is still present not only for Suggested tasks, but for a simple search: {F84124485}
T426365: Revise Tone Structured Task: release & scaling Communications
Task
Movement Communications work necessary for scaling work: {T426363} {T426364} ####Acceptance Criteria: - Share experiment results {T407802} - Communication as needed to support this rollout - TBD: Diff post? - TBD: Pilot wiki communication w/ support from Ambassadors? - TBD: External Comms? w/ support from Liv
T426364: Revise Tone Structured Task: release on remaining wikis supported by Tone check
Task
Release Revise Tone task as default on all remaining wikis supported by Tone Check: https://meta.wikimedia.org/wiki/Machine_learning_models/Production/Tone_Check ------ Released as part of: {T426363} | **Language** | **wiki_db** | **lang_code** | | English | enwiki | en | | French | frwiki | fr | | Arabic | arwiki | ar | | Spanish | eswiki | es | ------ New releases (part of this task): | **Language** | **wiki_db** | **lang_code** | | Russian | ruwiki | ru | | Japanese | jawiki | ja | | Dutch | nlwiki | nl | | Portuguese | ptwiki | pt | | Chinese | zhwiki | zh | | German | dewiki | de | ------ BLOCKER: Before this task is completed, experiment results should be shared publicly before this task is started: T407802: Product Analytics: Experiment Analysis - Revise Tone Structured Task (WE1.7.5, FY25-26) **Acceptance Criteria:** [] Connect with the Machine Learning team ASAP - subtask may be needed? [] Check translations for new wikis & announce to each wiki [] Alert Communities via Tech News @Trizek-WMF [] Alert Machine Learning team and Editing team about release date and plan [] Release the Revise Tone task on ru, ja, nl, pt, zh, and de [] Community Configuration for Revise Tone is available (Related: T426690)
T426363: Revise Tone Structured Task: end experiment on Pilot wikis
Task
Release Revise Tone task as default on pilot wikis included in the currently running A/B test: Arabic Wikipedia, English Wikipedia, French Wikipedia, and Portuguese Wikipedia. Before this task is completed, experiment results should be shared publicly before this task is started: {T407802} - [[ https://www.mediawiki.org/w/index.php?title=Growth%2FRevise_Tone&diff=8411934&oldid=8180123 | Results published ]] ####Acceptance Criteria: [] End the Revise tone newcomer task A/B test. Pilot wikis should receive the "treatment" experience [ ] after the code to make Revise Tone available to everyone has arrived on Production (ETA: July 9th), the experiment should be turned off on https://test-kitchen.wikimedia.org/experiment/growthexperiments-revise-tone (Do **not** delete the experiment there!) [ ] after the above date, [refactor: Clean up Revise Tone experiment scaffolding](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/1306953) can be merged
T426362: Tone check: Improve handling of quoted content
Task
We have some basic handling to ignore quoted content for tone check (and some other checks). Currently this checks * If the content is in a <blockquote> * If the first chracter is the matched range is inside quotes. This is done by counting the quotes either side of that offest. This misses cases where most of the text is quoted, e.g. paragraph 2 here: https://en.wikipedia.org/w/index.php?title=Henry_Hudson_(artist)&oldid=1347919439#A_Rake_Revisited Possible solutions: 1. Let `ignoreQuotedContent` set a % of how much content should be quoted before the whole paragraph is ignored, e.g. if 80% of the paragraph is inside quotes, ignore the check. 2. Mask quoted content before passing it to the model, e.g. > He was described as "the greatest artist ever" by his contemporaries, and "an inspiration" by his partner. V > He was described as "----" by his contemporaries, and "----" by his partner.
T426219: [QA task] Account creation entry points
Task
To list the UX workflows for Create Account from different entry points //Notes:// - all cases below were checked on `enwiki wmf.1` - since the scope of the task to document where an account creation workflow might be initiated, I excluded the account creation options that are not user-facing, e.g. account creation api, script for account creation, and auto-created accounts. - [[ https://www.mediawiki.org/wiki/Growth/Analytics_updates/EditorJourney_initial_report#Account_creation_context | Growth Analytics updates Editor Journey Account creation context ]] ===== Desktop |Where| steps| screenshots |---|---|--- |**Create account** link is present in the nav bar on every page | a user sees the link, clicks on it and redirected to Special:CreateAccount page [[ https://auth.wikimedia.org/enwiki/wiki/Special:CreateAccount?useformat=desktop | Special:CreateAccount ]] | {F81216564} {F81216640} |search for **Special:CreateAccount**| a logged in user searches for Special:CreateAccount andcreates another account| {F81217636} |a user attempts to see the page restricted to logged in users only - **Special:Homepage**| a login page is displayed with "Join Wikipedia" button [[ https://auth.wikimedia.org/enwiki/wiki/Special:UserLogin?useformat=desktop&usesul3=1&warning=exception-nologin-text&returnto=Special%3AHomepage&returntoquery=&centralauthLoginToken=ee6fc08229158a87febfa3a563069009 | Special:UserLogin ]] |{F81217730} |creating account in mid-edit | a user starts editing an article. sees the warning and clicks on Create account| {F81217947} ===== Mobile |Where| screenshots |---|--- |no **Create Account** option on a page| {F81218059, width=200} | no Create Accoount option in the side menu|{F81218065, width=200} |a user attempts to see the page restricted to logged in users - **Special:Homepage**|{F81218309, width=200} |searching for **Special:CreateAccount** | {F81218342, width=200} |mid- edit invitation for login| {F81218391, width=200} |anon user clicks on ** Watch star** | {F81218445, width=200} |!! (new)!! Bookmark (Save page) click //Use the flag for non-logged users:// `?mpo=account-creation-reading-list-cta:treatment`|{F81218552, width=200} |!! (new)!! (Growth team) User logo option, //Use the flag for non-logged users:// `?mpo=we-1-8-mobile-account-menu:treatment ` |{F81218506, width=200} |!!mobile apps!!| create account option is a in user logo; searching for Special:CreateAccount shows a normal Create Account page {F81219082, width=200} {F81219105, width=300}{F81219086, width=200}
T425768: [Spike] WelcomeSurvey redesign exploration
Task
As part of Sprinthackular May 2026 several design explorations around the welcome survey have been made (as part of DE1.3 //Progression system//). This task captures the related UI prototypes that have been developed and collects the challenges, blocker and learnings around it. [[ https://www.figma.com/design/L1txTmG5SBTxCxWSoUpAk3/Sprinthackular-2026?node-id=1-5&p=f&m=dev | Figma file ]] **Product questions** - Per designs the survey can be skipped at any step. Should we capture interim results as a regular submission? - How often do we think the questions can change? Last time took some years. **Technical questions** - When should the WelcomeSurvey be presented? Same as current behavior? - What should be the long-term storage solution? Currently it's a user option - How should be the data-write request be performed, currently handled as a special page post action. May vary if partial results are allowed. **UI/Design challenges** - The multi-step pattern, be it on dialogs or not, is repeating itself across different extensions (GrowthExperiments onboardings, PersonalDashboard quiz exploration). What's the most appropriate mechanism to share components between two extensions? - Codex icons are provided via a ResourceLoader callback hook for each module requiring some icon. How should a component that uses a codex icon be architected so it's reusable. - The nature of designs (some views are in the MW content surface while others on top of a dialog) make the UX mobile experience challenging in terms of orchestration of view navigations. Using some conventional tool like `vue-router` could come very handy. Also to allow some sort of "state URL serialization" so the survey can be recovered on its last state. - The current Codex dialog offers `fixedHeight` property to expand but does not take the full screen viewport. On narrow screens, the close button is always shown. - If the survey is fully rendered on the client, what should show while it loads?
T425603: Error: Unknown task type revise-tone
Task
==== Error ==== * [[ https://logstash.wikimedia.org/goto/af2a8d4f0fc162c6fa5e951e9cca3c9d| b096bd8c-16c3-47f0-9047-6ae20c6c4acb]] ```name=message Error: Unknown task type revise-tone ``` ```name=trace,lines=10 at new TaskExplanationWidget https://en.wikipedia.org/w/load.php?lang=en&modules=%40wikimedia%2Fcodex%2Ccodex-styles%2Cjquery%2Coojs-ui-core%2Cvue%7Cext.growthExperiments.Homepage.Impact%2CSuggestedEdits&skin=vector-2022&version=119b6:422:554 at SuggestedEditsModule.updateTaskExplanationWidget https://en.wikipedia.org/w/load.php?lang=en&modules=%40wikimedia%2Fcodex%2Ccodex-styles%2Cjquery%2Coojs-ui-core%2Cvue%7Cext.growthExperiments.Homepage.Impact%2CSuggestedEdits&skin=vector-2022&version=119b6:405:742 at SuggestedEditsModule.updateControls https://en.wikipedia.org/w/load.php?lang=en&modules=%40wikimedia%2Fcodex%2Ccodex-styles%2Cjquery%2Coojs-ui-core%2Cvue%7Cext.growthExperiments.Homepage.Impact%2CSuggestedEdits&skin=vector-2022&version=119b6:410:783 at SuggestedEditsModule.onNewcomerTasksDataChanged https://en.wikipedia.org/w/load.php?lang=en&modules=%40wikimedia%2Fcodex%2Ccodex-styles%2Cjquery%2Coojs-ui-core%2Cvue%7Cext.growthExperiments.Homepage.Impact%2CSuggestedEdits&skin=vector-2022&version=119b6:406:52 at OO.EventEmitter.emit https://en.wikipedia.org/w/load.php?lang=en&modules=oojs&skin=vector-2022&version=rwdvu:8:193 at NewcomerTasksStore.onTaskQueueChanged https://en.wikipedia.org/w/load.php?lang=en&modules=ext.growthExperiments.DataStore&skin=vector-2022&version=84hq6:10:390 at NewcomerTasksStore.setPreloadedTaskQueue https://en.wikipedia.org/w/load.php?lang=en&modules=ext.growthExperiments.DataStore&skin=vector-2022&version=84hq6:9:974 at initSuggestedTasks https://en.wikipedia.org/w/load.php?lang=en&modules=%40wikimedia%2Fcodex%2Ccodex-styles%2Cjquery%2Coojs-ui-core%2Cvue%7Cext.growthExperiments.Homepage.Impact%2CSuggestedEdits&skin=vector-2022&version=119b6:395:339 at https://en.wikipedia.org/w/load.php?lang=en&modules=%40wikimedia%2Fcodex%2Ccodex-styles%2Cjquery%2Coojs-ui-core%2Cvue%7Cext.growthExperiments.Homepage.Impact%2CSuggestedEdits&skin=vector-2022&version=119b6:396:839 at index.js https://en.wikipedia.org/w/load.php?lang=en&modules=%40wikimedia%2Fcodex%2Ccodex-styles%2Cjquery%2Coojs-ui-core%2Cvue%7Cext.growthExperiments.Homepage.Impact%2CSuggestedEdits&skin=vector-2022&version=119b6:397:70 ``` ==== Impact ==== - last 7 days 13 hits - https://logstash.wikimedia.org/goto/396ee02253540484f346f5fa25288f03 ==== Notes ==== - I checked a test user with Revise tone task type enabled - all works as expected
T425232: Mentor status dashboard: display mentor activity, responsiveness, and other stats
Task
####User story & summary: As an admin who cares about new editors receiving timely responses to their mentorship questions, I want to be able to monitor mentors and be fully informed about Mentor activity and responsiveness so I can make the right decision about whether to be proactive and reach out to a Mentor, reassign their mentees, possibly dementor them, or whether to allow a proposed automatic procedure (see T321509) to take over and cull them when a configured threshold is reached. As a Growth team member interested in Mentorship, I need data about mentor activity, responsiveness, awayness, performance, abandonment, and exit from the program so I can measure and evaluate how Mentors are performing overall at an individual wiki and know how to best allocate team resources to optimize for mentee satisfaction and retention based on mentor response. ####Background: Currently, an admin has no easy access to information about mentor activity, as it affects what mentees are experiencing from their mentors. At task T321509, @Kudpung pointed out (at T321509#11881665) that a mentee was assigned a mentor with 1,465 edits and 508 days of inactivity. Some wikis (de, ru, ko) are coming up with bot-driven auto-dementorship to deal with this. As a partial solution, T321509 "Provide a system to automatically suspend or remove mentors from the list of mentors" was proposed. That proposal addresses the issue of ensuring we do not miss cases where mentors are inactive for long periods via a new automated dementorship process. What the current manual system and the proposed automated system have in common is that they both lack the ability to provide admins with access to full information about mentor status and activity to support admins who wish to remain fully abreast of mentor status in order to support making administrative decisions about mentors when warranted. Under the current system, we don't know about Mentor1465 and their 508 days of inactivity, so admins don't do anything about them. Under the proposed system, we still don't know anything about Mentor-1465; the automated process will eventually strip their bit and reassign their mentees, and we will either learn about it after the fact (if logged or otherwise reported) or we will never know at all. The admin is left out of the picture, even if they might have been able to help (either the mentor, or the mentee) earlier in the process, had they been aware. Regarding the automated system, in T321509#11882195, @KStoller-WMF wrote: > It is important to note that this type of automation can address inactivity, but it cannot reliably identify or remove mentors who are ineffective, as that would be much harder (and likely problematic) to attempt to address programmatically. We need to support providing admins the information they need to reliably monitor and remove ineffective mentors in a way an automated system cannot. The way to support admins in this way is via a new dashboard tool that provides the missing information. ####Proposal: A new reporting tool should be created aimed at admins to provide them the ability to make manual decisions about mentors when appropriate. A **Mentor Status Dashboard** is proposed. The Mentor Status Dashboard should be a table of all mentors with sortable columns: * MENTOR – mentor name * RTNDAT – self-declared away status/return date * LEDAT – date of last WP edit * N30 – number of edits in last 30 days * LQDAT – date of last mentee question * LADAT – date of last mentor response ('A' for answer, as in Q&**A**) And some frequency stats t.b.d. to assess mentor activity, but perhaps things like: * Q30 – number of mentee questions in last 30 days to this mentor ('volume'; skip last 5 days) * A30 – number of mentor answers in last 30 days from this mentor ('responses'; skip last 5 days) * NA30 – number of mentee questions in last 30 days not answered ('dropped'; skip last 5 days?) * A30pctQ – mentor answers as a percent of all mentee questions in last 30 days, i.e., A30*100/Q30 ('responsiveness') * MTBQ30 – mean time between mentee questions in last 30 days ('mean Q frequency') * MTBA30 – mean time between mentor answers/responses ('mean A frequency' and maybe also some stats to assess mentor burden, like: * A30pctE – mentor answers as a percent of all mentor edits in last 30 days (skip 5), i.e., A30*100/N30 ('burden') This would provide admins with the data they need to watch what is going on, never miss a user like Mentor-1465 again, and decide what, if anything, to do about a mentor nearing (one of?) the dementorship threshold(s?). #####Style As for styling, some things to consider: * mentor name – set max-width and force-wrap or use ellipsis with tooltip to limit col 1 width and avoid horizontal scroll * liberal use of classes and a default style sheet, in order to enable individual admins to restyle the table to their liking using common.css. * perhaps an unobtrusive row background coloring of faded green, amber, and pink to highlight mentors at various levels of activity relative to a local community threshold might be useful; or just several row classes with no default bg-color so individual admins could pick their own scheme for whether and how to highlight. * transparency – who should be able to view it (everyone, imho) * dementor column – an optional convenience column with action and/or visibility restricted to admins which would remove the mentorship bit and initiate mentee reassignment NOTE: Not shown are other stats of more interest to the Growth team itself, such as abandonment (no answer to questions, but mentor still active) and exit from the program. But stats like 'burden' (here defined as A30pctE, perhaps others) should be plotted against abandonment and exit as curves on a time-series graph, which might give an early warning about individual mentors who are approaching values that indicate they are at risk for leaving or not answering based on previous experience. If averaged over all mentors, it could show when a program at an individual wiki is at risk and needs resources applied to recruitment.
T424979: Account Creation: improve password & confirm password field UX
Task
####User story: As a new account creator on mobile web, I want clear and timely feedback when my **password** and **confirm password** fields don't meet requirements or don't match, so that I can quickly fix errors and complete account creation without unnecessary friction. ####Background & research: The current account creation form delays password mismatch validation until form submission and does not clear errors after the user corrects their input. This creates confusion and unnecessary friction, particularly on mobile where context-switching between fields is more error-prone. Providing validation on blur - and re-validation on subsequent edits - aligns with standard UX practices and reduces failed submissions. This task is part of the broader V3 account creation effort (T415659). ####Design: [[ https://www.figma.com/design/mEYvnTEoCHGLavr3g7Jjs2/T409236-account-creation?node-id=910-4541&t=VAPgRxAODAnZCyIz-1 | Figma designs ]] ####Acceptance Criteria: **Note on error severity:** blur-triggered validation uses a warning state (yellow triangle + warning message). Submit-triggered validation escalates to an error state (red icon + error message + form-level error banner). These are distinct visual states and should be implemented accordingly. **Note on optimistic vs. conservative re-validation:** AC8 and AC9 describe the ideal (optimistic) behavior. AC10 and AC11 describe the acceptable fallback (conservative). Implement optimistic if straightforward; fall back to conservative if re-validation on keystroke is non-trivial. --- **On blur - password field** - AC1: Given the user leaves the password field, when the password meets all requirements, then clear any existing password warning. {F81620319} - AC2: Given the user leaves the password field, when the password does not meet requirements (e.g. fewer than 8 characters), then display an inline warning below the field. {F81620385} - AC3: Given the confirm password field is already filled and the user leaves the password field, when the password is now valid and the fields do not match, then display a mismatch warning below the confirm password field. {F81620561} - AC4: Given the confirm password field is already filled and the user leaves the password field, when the password is now valid and the fields match, then clear any existing mismatch warning. {F81620591} --- **On blur - confirm password field** - AC5: Given the user leaves the confirm password field, when the password field is still invalid, then do not validate confirm password - suppress any match-related feedback. {F81620775} - AC6: Given the user leaves the confirm password field, when the password field is valid and the passwords do not match, then display a mismatch warning below the confirm password field. {F81620819} - AC7: Given the user leaves the confirm password field, when the password field is valid and the passwords match, then display no error. {F81620844} --- **On keystroke - optimistic re-validation (ideal)** - AC8: Given a password field warning or error is already displayed, when the user types in the password field and the value now meets requirements, then clear the warning or error immediately without waiting for blur. {F81620890} - AC9: Given a mismatch warning or error is already displayed, when the user types in either field and the passwords now match, then clear the mismatch warning or error immediately. {F81620939} --- **On keystroke - conservative fallback (acceptable)** - AC10: Given a password field warning or error is already displayed, when the user types in the password field, then re-validate on next blur rather than on each keystroke. {F81621008} - AC11: Given a mismatch warning or error is already displayed, when the user types in either field, then re-validate on next blur rather than on each keystroke. {F81621067} --- **On submit** - AC12: Given the user submits the form, when the password field is invalid, then display the password requirements error inline below the password field regardless of prior field state. {F81621118} - AC13: Given the user submits the form, when the passwords do not match, then display the mismatch error inline below the confirm password field regardless of prior field state. {F81621152} - AC14: Given the user submits the form, when both the password is invalid and the passwords do not match, then display both errors simultaneously alongside a form-level error banner ("There are problems with some of your input."). {F81621203} - AC15: Given the user submits the form, when client-side validation fails due to password-related errors (invalid password or mismatched passwords), then the password and confirm password fields retain their current values so the user can reveal and edit rather than retype. --- ####Open questions: - [ ] Can this be included in the V3 release? * [ ] Is additional instrumentation needed to track validation error rates or correction patterns? * [x] Should a debounce be applied to keystroke re-validation (AC8/AC9) to avoid noisy feedback on fast typists? * Yes, 2000ms as we do for [[ https://phabricator.wikimedia.org/T419401 | username validation ]]. * [x] How should password mismatch errors interact with other password errors? (stack vs. display as one error) * Display only one error - whatever the API returns first.
T424940: Suggested edits feature added an unnecessary nowiki tag
Task
**Steps to replicate the issue** (include links if applicable): * Unclear, the issue has been observed in a specific edit, once. * Link: https://pl.wikipedia.org/w/index.php?title=Twierdzenie_japo%C5%84skie&diff=prev&oldid=79648481 **What happens?**: An unnecessary nowiki tag is inserted, separating the letters after the linked page’s name from the link. In this edit the nowiki tag is inserted changing "czworokąta" to "[[czworokąt]]<nowiki/>a". **What should have happened instead?**: The nowiki tag should not have been inserted. In the provided edit the correct output should be "[[czworokąt]]a".
T424861: Prevent mentees from sending questions to former mentors
Task
Since the relationship between mentor and mentees is not being properly removed when a mentor quits mentorship and it's in current investigation under T418194, let's try to avoid mentees sending questions to the wrong recipient. This should be possible by checking if a mentee's mentor is active at the time of sending a question. **Acceptance criteria** - [] Detect a mentee is trying to send a question to a former mentor - [] Try to re-assign the mentee to a new mentor and re-send the question to them - [] Make any additional checks to make sure the old relation is dropped - [] If the re-assignment fails make sure the question is not sent to the former mentor, add logs Questions: - if we're unable to re-assign, should we at least drop the old relation? I'd say yes - if we're unable to re-assign and send the question, should we give specific feedback to the mentee? I'd say yes
T424097: Allow extensions to register custom form controls via extension.json attributes
Task
=== Problem === CommunityConfiguration today bundles a fixed set of custom form controls (`PageTitleControl`, `PageTitlesControl`, `NamespacesControl`, `CommonsFileControl`, ...) directly in `ext.communityConfiguration.Editor`, registered in a local controls registry via `rankRenderer( N, Control, tester )` [1]. Extensions that need a schema-specific control (e.g. lookup widgets for domain-specific IDs) currently have three options, none of them clean: # Upstream the control into CC itself, coupling CC to extension-specific concepts (e.g. Wikifunctions ZIDs). # Fork CC's Editor module # Build out their own Special page outside CC and lose schema-validation history, and all the other CC affordances. The first is how the existing `PageTitleControl` and `CommonsFileControl` got in, but those controls consume only MediaWiki-core and Commons concepts. For third-party extensions — WikiLambda, Wikibase, Growth, … — landing a domain-specific control in CC itself crosses an architectural boundary that the existing built-ins don't. === Use case motivating this === The Abstract Wikipedia team is migrating two WikiLambda-managed lists to CC (see {T394410}): * `WikifunctionsSuggestions` — a 5-entry list of recommended Wikifunctions shown in the `{{#function:…}}` VisualEditor dialog on client-mode wikis. * `AbstractWikiSuggestedWikifunctions` — a 10-entry list of HTML-returning Wikifunctions offered in Abstract Wikipedia's fragment menu. Both providers currently validate ZIDs by regex (`^Z[1-9]\d*$`) and render in CC's default string-array editor, which means sysops type ZIDs blind with no autocomplete and no return-type safety net. The Wikifunctions search Action API already exposes a typed autocomplete — we'd like to plug that into the CC form instead of rebuilding it. === Proposed API === Add an `attributes.CommunityConfiguration.Controls` block to `extension.json` that maps a control ID to a ResourceLoader module + exported Vue component name: ```lang=json "attributes": { "CommunityConfiguration": { "Controls": { "WikifunctionsFunctionLookup": { "module": "ext.wikilambda.functionLookup", "component": "FunctionLookupControl", "schemaControlName": "MediaWiki\\Extension\\WikiLambda\\Controls\\FunctionLookupControl" } } } } ``` On the frontend, the DispatchRenderer/controls registry merges those extension-registered entries with the built-ins at registration time. When a schema property declares "control": "<schemaControlName>", CC lazy-loads the named RL module via mw.loader.using() before mounting the component in place of the default renderer. The registered component would receive the same props as the built-in controls (modelValue, schema, etc.) and emit update:modelValue for CC's v-model binding, so the contract is identical to existing controls. === Acceptance criteria === [ ] Extensions can register custom Vue controls by adding an `attributes.CommunityConfiguration.Controls.<ID>` block, with no edits to CC's own tree. [ ] Schema properties reference the custom control via the existing `"control": "…"` key (no new schema keyword). [ ] Extension controls are lazy-loaded on demand (not bundled with CC's baseline editor module). [ ] Jest coverage in CC exercises the renderer with a mock extension-registered control. [ ] Zero regression in existing built-in controls. === Open questions for discussion === - Should the extension-supplied module also be allowed to contribute a tester function (for ranked/fallback dispatch), or is direct mapping by schemaControlName sufficient? - Do we want to support control-level options in the schema (//e.g.// `"control_options": { "outputType": "Z89" }`) via a formal annotation, or leave option transport to control-specific conventions? - Should we allow extensions to override built-in controls, or reject that as too footgun-prone? === References === - Downstream migration task: {T394410} - WikiLambda-side CC providers (client mode): https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/1276054 - WikiLambda-side CC providers (abstract mode): https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/1276055 - Downstream feature request task: {T424096}
T423692: CommunityConfiguration nested arrays don't use valid message keys, breaking support for them
Task
**Reproduction steps** 1. Use the following configuration schema: ``` public const CCExample_Pages = [ / / Copy-pasted from the root example self::TYPE => self::TYPE_OBJECT, self::PROPERTIES => [ 'NestedPage' => [ self::TYPE => self::TYPE_ARRAY, self::DEFAULT => [], self::ITEMS => [ self::TYPE => self::TYPE_OBJECT, self::PROPERTIES => [ 'title' => [ self::REF => [ 'class' => MediaWikiDefinitions::class, 'field' => 'PageTitle', ], // TODO: this does not work! self::MIN_LENGTH => 1, ], ], self::REQUIRED => [ 'title' ], ], ] ], ]; ``` 2. No messages show up when an item is added: {F76374925} **Expected Behavior** Arrays should use valid message keys like when they're in the root: {F76374951}
T423347: [EPIC] Streamline and simplify newcomer onboarding
Task
Improve the initial experience for new account holders by reducing friction, removing unnecessary steps, and making it faster and clearer to get started. #####User story As a new account holder, I want to get started immediately without unnecessary decisions or distractions, so that I can quickly explore or contribute in a way that feels simple and relevant to me. #####Problem Newcomer onboarding today is fragmented and introduces unnecessary complexity at key moments: - Users are asked to make decisions (for example, topic selection) before they understand their goals - Key UI elements can feel overwhelming or distracting - Onboarding steps are not clearly tied to immediate user value - The experience does not adapt well to different types of users (readers vs. contributors) #####Goal Create a more seamless onboarding experience that: - Helps users get started quickly with minimal upfront decisions - Reduces cognitive load and interface complexity - Aligns onboarding steps with clear, immediate value - Supports flexible paths based on user intent and behavior #####Related Metrics: - Reduced time from account creation to first meaningful action - Increased activation rates (for example, first edit or key interaction) - Improved clarity and ease of use in early sessions - Fewer drop-offs during onboarding steps - Higher second-week retention #####Scope This parent task brings together efforts that simplify and modernize onboarding.
T423343: Design: Rethinking Topic Selection in Suggested Edits
Task
As a new contributor, I want to start editing right away without having to choose topics first, so that I can quickly try editing and build momentum. ####Background Suggested Edits currently asks newcomers on desktop to select topics before they can begin editing. While this helps personalize recommendations, it may also introduce friction and delay the moment when users can start contributing. Additionally, existing topic filters may feel too broad or not meaningful enough for users with more specific interests. ####Objective Explore ways to reduce friction in getting started with Suggested Edits while improving the relevance and usefulness of topic filtering. **Key Questions to Explore** - What happens if users can access Suggested Edits immediately, without selecting topics first? - How can we introduce topic preferences in a more lightweight or contextual way? - How might we make topic filtering more granular and meaningful, especially for users with niche or specific interests? - What signals (implicit or explicit) can we use to infer user interests without requiring upfront input? - Improved topic model: Explore more detailed or flexible topic structures - User control and transparency: Ensure users can easily understand and adjust why certain suggestions are shown. - How can we reusing existing topic filtering design patterns (Content Translation for example)? **Related metrics:** - Increased constructive activation - Increased second week retention - Improved perceived relevance of Suggested Edits ####Acceptance Criteria: Concept flows and wireframes for alternative entry experiences Interaction patterns for progressive topic selection Proposals for a more granular and flexible topic filtering system Recommendations for experimentation and measurement
T423115: Implement stepped account creation form (V3) on mobile web
Task
####User story & summary: As a logged-out mobile web user, I want to create a Wikipedia account through a simple step-by-step flow so that I can complete registration without being overwhelmed by all fields at once. ####Background & research: This task builds on the V2 account creation experiment (T422295), which introduced a cleaned-up single-page form with username policy copy, live username validation, and a password reveal toggle. While V2 reduced visual clutter, the form still presents all fields simultaneously, which increases cognitive load - especially on small screens where the keyboard covers much of the viewport. A comparative analysis of the top 20 most visited websites (T410558) shows that most platforms use stepped or single-field-per-view account creation flows to reduce friction. This task implements that pattern for Wikipedia's mobile web account creation, splitting the form into three sequential steps: (1) email, (2) username, and (3) password and confirm password. ####Design: //**Scope: this task is scoped to Mobile web only.**// [[ https://www.figma.com/design/mEYvnTEoCHGLavr3g7Jjs2/T409236-account-creation?node-id=783-17250&t=LZnVitRHrLJOeXOM-1 | Figma designs ]] {F75834941 width=600} ####Acceptance Criteria: **Step 1 - Email** AC1 * Given I am a logged-out user and I navigate to the account creation destination (displayed as full-screen dismissible dialog) * When the dialog opens * Then I see a single-step form showing only the email address field, a "Next" button, and a "Register without an email" button below it AC2 * Given I am on Step 1 and I enter a valid email address * When I tap "Next" * Then I am taken to Step 2 (username) AC3 * Given I am on Step 1 and I leave the email field empty * When I tap "Next" * Then I see an inline error below the field: "Email address is required" * AND I cannot advance to Step 2 AC4 * Given I am on Step 1 * When I tap "Register without an email" * Then I am taken to the V2 single-page account creation form (T422295) * AND the email address field is visible on page load with: a warning/alert icon before the "Email address" label, a "(recommended)" flag, and the field description "Email is required to recover your account if you lose your password or log in from an unfamiliar location or new browser" **Step 2 - Username** AC5 * Given I am on Step 2 * When the step loads * Then I see the username field with the policy tl;dr displayed as a field description above the input, per the V2 design (T422295) AC6 * Given I am on Step 2 and I am typing a username * When I pause after entering characters * Then live validation runs and I see either a "Username available" confirmation or an inline error AC7 * Given I am on Step 2 and a valid username is entered * When I tap "Next" * Then I am taken to Step 3 (password) **Step 3 - Password** AC8 * Given I am on Step 3 * When the step loads * Then I see a password field and a confirm password field, each with a password reveal toggle AC9 * Given I am on Step 3 and both password fields are filled in correctly * When I tap "Create your account" * Then my account is created and I am redirected (see open questions) ####Open questions: 1. Where should users be redirected after successful account creation when they started from the Wikipedia main page? Options include: the newcomer homepage, the main page (with a welcome banner), something else?
T422837: Encourage Wikidata contributions for items with frequent red links on Wikipedia
Task
Red links on wikis such as Wikipedia represent pages not created yet. When a red link appears many times on a wiki and articles exist for it in many other languages, we can consider those a sign of the missing pages being in high demand for the wikis where they are missing. Once an editor decides to create a page for that red link, it may be beneficial for a wikidata item to exist and contain useful data. In this way, users can use the information and references available in wikidata (manually or assisted by tools such as #article-guidance). This ticket proposes to surface opportunities to contribute to Wikidata items, based on the demand for the associated red links on the wikis. That is, Wikidata editors can be encouraged to contribute to items of high demand on different wikis such as Wikipedia. ___ A challenge for this task is to determine which Wikidata item a readlink corresponds to. Related to this, there is a proposal to allow annotating the red links with a Wikidata ID (T422822).
T422828: Flappy test UncachedMenteeOverviewDataProviderTest::testGetFormattedDataForMentors
Task
A #growthexperiments test failed on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1269334 but otherwise passed after a +2: https://integration.wikimedia.org/ci/job/quibble-with-gated-extensions-vendor-mysql-php83/26178/console ``` There was 1 failure: 1) GrowthExperiments\Tests\Integration\UncachedMenteeOverviewDataProviderTest::testGetFormattedDataForMentors Failed asserting that array contains the expected submap. --- Expected +++ Actual @@ @@ 'questions' => 0, 'editcount' => 0, 'registration' => '20260409131537', - 'blocks' => 3, + 'blocks' => 2, 'last_active' => '20260409131537', ), 5 => /workspace/src/tests/phpunit/MediaWikiTestCaseTrait.php:294 /workspace/src/extensions/GrowthExperiments/tests/phpunit/integration/MentorDashboard/MenteeOverview/UncachedMenteeOverviewDataProviderTest.php:97 ```
T422786: Run @selenium-test npm script in *future* release branches
Task
While working on #growthexperiments (T419574, T417412) and #wikidata tasks (T287582) we have noticed that `@selenium-test` npm script does not run for commits in release branches. Example patch for GrowthExperiments: [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/1262308 | 1262308 ]]
T422730: Develop an API that enables Edit Checks/Suggestions to be kept in sync with Growth Experiments
Task
This task involves the work of implementing an API that would enable the configuration values governing how "Add a link" gets presented in the newcomer homepage (`MediaWiki:GrowthExperimentsSuggestedEdits.json`) be automatically mirrored within the configuration values governing how the "Add a link" suggestion gets presented within Suggestion Mode. To enable the above, the Editing Team will implement a new API that will: 1. Listen for changes to `MediaWiki:GrowthExperimentsSuggestedEdits.json` 2. Update to `MediaWiki:Editcheck-config.json` to reflect //relevant// changes in `MediaWiki:GrowthExperimentsSuggestedEdits.json` NOTE: The API this ticket will introduce will be relevant now //and// in a potential future wherein EditCheck-config.json is migrated to the Community Configuration extension (T372927) === Requirements |`MediaWiki:GrowthExperimentsSuggestedEdits.json`|Mirror in `MediaWiki:Editcheck-config.json`?| `MediaWiki:Editcheck-config.json` equivalent|Notes |---|---|---|--- |This task is disabled| ❌ Not now |`showAsSuggestion: false` | |Articles containing templates defined here will not be shown to users as tasks for this task type|✅ Yes| `lacksTemplate `| |Articles containing categories defined here will not be shown to users as tasks for this task type|✅ Yes| `notInCategory `| |Destination page for learning more about add link task type|❌ Not now| N/A|Links shown within Suggestion Cards are defined in interface messages not within the config file. Although, importing could be supported if we deemed it necessary. |Maximum number of links to show per task| ❌ No |N/A| We are increasing the `predictionThreshold` to `0.8` to mitigate this risk |List of excluded sections from the Add link task|✅ Yes|`ignoreSections`| |The maximum number of "Add a link" suggested tasks a newcomer can complete daily|❌ Not now | N/A| We assume the risk of someone completing //a lot// of link suggestions using Suggestion Mode to be low enough to omit this ceiling //for now// |Weight of underlinked articles|❌ No | N/A|This value is specific to the newcomer homepage, per T421968#11795735 |Minimum required link score|✅ Yes AND no... |`predictionThreshold`| Suggestion Mode ought to set the link prediction threshold to `0.8` which differs from what is set by default in the `Add a link` config (`0.6`) |Stop suggesting "Add a link" tasks based on newcomers' total edits|❌ Not now| N/A |Suggestions don't currently respect account-based limits; this functionality will be implemented in TICKET (@Esanders to file) === Done - [x] Editing Team populates the `Requirements` section with details about the proposed API - [x] Growth Team (@KStoller-WMF + @Michael) review proposed API - [x] @ppelberg review https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Structured_tasks/Community_feedback - [x] Editing Team updates `Requirements` to include Growth Team feedback - [ ] Editing Team implements API
T422563: [EPIC] Impact Module: move to Wikimedia Analytics API
Task
####User story & summary: As the Growth team, we want to migrate the Impact Module away from Growth’s custom User Impact API and instead use the Wikimedia Analytics API, so that Impact Module metrics are powered by a more stable, scalable, and supported data source. ####Background & research: [[ https://www.mediawiki.org/wiki/Extension:GrowthExperiments/developer_setup#User_impact | Growth's User Impact API ]] was originally created to meet immediate data needs for the MVP version of the Homepage Impact Module. It was intended as a temporary solution and is not designed for long term scalability or broader reuse. The Data Engineering team has since expanded the Wikimedia Analytics API to support editor focused metrics that align well with the Impact Module’s requirements. We should shift the Impact Module to being served by data in the Wikimedia Analytics API to ensure the data is more stable and we can remove some of the data caps that limit the usefulness of this feature to more experienced editors. **Relevant documentation:** - Daily updated number of edits made by an editor - https://doc.wikimedia.org/generated-data-platform/aqs/analytics-api/reference/edits.html#get-number-of-edits-made-by-an-editor - Number of page views for an editor's edited pages - https://doc.wikimedia.org/generated-data-platform/aqs/analytics-api/reference/page-views.html - Most-viewed pages for an editor's edited pages - https://doc.wikimedia.org/generated-data-platform/aqs/analytics-api/reference/edits.html#get-number-of-edits-made-by-an-editor ####Scope and Goals Work with DPE to align on missing contributor metrics necessary to support the long-term Contributor strategy Shift the Impact Module away from the User Impact API and instead use the Wikimedia Analytics API
T422513: Image Suggestions uses AI-generated images from Commons when adding images on English Wikipedia
Task
**Steps to replicate the issue** (include links if applicable): * Open the Wikipedia app * Navigate to an article on English Wikipedia (enwiki) * Start the flow to add an image to the article * Observe the suggested images provided by the app **What happens?**: The app [[ https://en.wikipedia.org/w/index.php?title=Egoi&diff=prev&oldid=1338507354 | suggests ]] images from Wikimedia Commons without filtering out AI-generated images. A user [[https://en.wikipedia.org/wiki/User_talk:ScottyNolan/Archive_1#:~:text=%5Bsubscribe%5D-,AI%2Dgenerated%20images,-Per%20WP%3AAIIMAGE | reported ]] that they added an AI-generated image based on the app’s suggestion, assuming it was appropriate since it appeared in other language versions of the article. **What should have happened instead?**: AI-generated images should not be suggested when adding images on English Wikipedia, or at least should be filtered out when possible, given that enwiki policy ([[https://en.wikipedia.org/wiki/Wikipedia:AIIMAGE | WP:AIIMAGE ]]) generally discourages their use. **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): Prevent the app from suggesting AI-generated images (based on Commons categorization or metadata) when users are adding images to articles on English Wikipedia. ==Potential solutions - **[hard]** filter images with the `{{PD-algorithm}}` template in their Commons File pages, see T422513#11813943 - **[hard]** filter images with ([instance of](https://www.wikidata.org/wiki/Property:P31), [AI-generated image](https://www.wikidata.org/wiki/Q116177346)) Commons statements - **[easy, only for depicts-based suggestions]** filter Commons statements as above when [parsing mediainfo](https://gitlab.wikimedia.org/repos/structured-data/image-suggestions-data-pipelines/-/blob/cf70a2fac7477c1475366d0211e5d898dea8da74/image_suggestions/image_suggestions/udfs.py#L122) - **[medium, only for Wikipedia lead images]** implement a filter in [filter_articles_with_lead_images](https://gitlab.wikimedia.org/repos/structured-data/image-suggestions-data-pipelines/-/blob/main/image_suggestions/image_suggestions/wikidata_and_lead_images.py?ref_type=heads#L378)
T422469: ReviseTone.cy.ts flakily fails to find ve-ui-editCheck-gutter-action-warning
Task
== Summary The `ReviseTone.cy.ts` test flakily fails to find the `ve-ui-editCheck-gutter-action-warning` element == Technical details Example at https://integration.wikimedia.org/ci/job/quibble-with-gated-extensions-selenium-php83/24532/console#console-section-4 (kept forever): ```lines=10,name=Failing test 09:58:51 Revise Tone 09:58:54 On desktop 09:59:01 ✓ Shows the Revise Tone Edit Check (9862ms) 09:59:01 - Closes the Editor when declining Edits and suggests a new task 09:59:01 - Shows the Revise Tone Edit Check and tags edits 09:59:01 On mobile 09:59:30 1) Shows the Revise Tone Edit Check 09:59:30 cy:command ✔ visit /index.php -> 301: http://127.0.0.1:9413/index.php?title=Main_Page 09:59:30 cy:command ✔ window 09:59:30 cy:command ✔ assert expected **<window>** to have property **mw** 09:59:30 cy:command ✔ window 09:59:30 cy:command ✔ its .mw.Api 09:59:30 cy:command ✔ assert expected **[Function]** to exist 09:59:30 cy:command ✔ window 09:59:30 cy:xhr ➟ POST http://127.0.0.1:9413/api.php 09:59:30 Status: 200 09:59:30 cons:warn ❖ movePinnableElement: destination container not found , 09:59:30 vector-toc-unpinned-container 09:59:30 cy:xhr ➟ POST http://127.0.0.1:9413/api.php 09:59:30 Status: 200 09:59:30 cy:command ✔ visit /index.php -> 301: http://127.0.0.1:9413/index.php?title=Main_Page 09:59:30 cy:command ✔ window 09:59:30 cy:command ✔ its .mw.Api 09:59:30 cy:command ✔ assert expected **[Function]** to exist 09:59:30 cy:command ✔ window 09:59:30 cons:warn ❖ movePinnableElement: destination container not found , 09:59:30 vector-toc-unpinned-container 09:59:30 cy:xhr ➟ POST http://127.0.0.1:9413/api.php 09:59:30 Status: 200 09:59:30 cy:command ✔ viewport 360, 780 09:59:30 cy:command ✔ visit index.php?title=Special:Homepage/suggested-edits&mobileaction=toggle_view_mobile&mpo=growthexperiments-revise-tone:treatment -> 301: http://127.0.0.1:9413/index.php?title=Special:Homepage/suggested-edits&mpo=growthexperiments-revise-tone%3Atreatment 09:59:30 cy:command ✔ get .se-card-title 09:59:30 cy:command ✔ assert expected **<h3.se-card-title>** to have text **Kristallsee** 09:59:30 Actual: "Kristallsee" 09:59:30 Expected: "Kristallsee" 09:59:30 cy:command ✔ get a.se-card-content 09:59:30 cy:command ✔ assert expected **<a.se-card-content>** not to have attribute **href** with the value **#** 09:59:30 cy:command ✔ get .suggested-edits-next .oo-ui-buttonElement-button 09:59:30 cy:command ✔ click 09:59:30 cy:xhr ❖ GET http://127.0.0.1:9413/api/rest_v1/page/summary/Kristallsee 09:59:30 Status: 404 09:59:30 cy:xhr ❖ GET https://wikimedia.org/api/rest_v1/metrics/pageviews/per-article/127.0.0.1/all-access/user/Kristallsee/daily/20260204/20260405 09:59:30 Status: 404 09:59:30 cons:warn ❖ This page is using the deprecated ResourceLoader module "moment". 09:59:30 [1.44] Use mediawiki.DateFormatter or native Intl function instead. See https://phabricator.wikimedia.org/T146798 09:59:30 cy:xhr ❖ GET http://127.0.0.1:9413/api/rest_v1/page/summary/Ma'amoul 09:59:30 Status: 404 09:59:30 cy:xhr ❖ GET https://wikimedia.org/api/rest_v1/metrics/pageviews/per-article/127.0.0.1/all-access/user/Ma'amoul/daily/20260204/20260405 09:59:30 Status: 404 09:59:30 cy:xhr ❖ GET http://127.0.0.1:9413/api/rest_v1/page/summary/Eldfjall 09:59:30 Status: 404 09:59:30 cy:xhr ❖ GET https://wikimedia.org/api/rest_v1/metrics/pageviews/per-article/127.0.0.1/all-access/user/Eldfjall/daily/20260204/20260405 09:59:30 Status: 404 09:59:30 cy:command ✔ get .se-card-title 09:59:30 cy:command ✔ assert expected **<h3.se-card-title>** to have text **Eldfjall** 09:59:30 Actual: "Eldfjall" 09:59:30 Expected: "Eldfjall" 09:59:30 cy:command ✔ get a.se-card-content 09:59:30 cy:command ✔ assert expected **<a.se-card-content>** not to have attribute **href** with the value **#** 09:59:30 cy:command ✔ get a.se-card-content 09:59:30 cy:command ✔ click 09:59:30 cy:command ✔ page load --page loaded-- 09:59:30 cy:command ✔ new url http://127.0.0.1:9413/index.php?title=Eldfjall&getasktype=revise-tone&gesuggestededit=1&geclickid=qugd8ldm5i8rodkobe35r54ar6ipgk2a&genewcomertasktoken=jmnp0gblgrghe2vhni2hb2ehn20upf2p&mpo=growthexperiments-revise-tone%3Atreatment&veaction=edit&section=all 09:59:30 cy:command ✔ get .ext-growthExperiments-ReviseToneOnboarding 09:59:30 cy:command ✔ assert expected **<div.cdx-dialog.ext-growthExperiments-OnboardingDialog.ext-growthExperiments-ReviseToneOnboarding>** to be **visible** 09:59:30 cy:command ✔ new url http://127.0.0.1:9413/index.php?title=Eldfjall&getasktype=revise-tone&gesuggestededit=1&genewcomertasktoken=jmnp0gblgrghe2vhni2hb2ehn20upf2p&mpo=growthexperiments-revise-tone%3Atreatment&veaction=edit&section=all 09:59:30 cy:command ✔ new url http://127.0.0.1:9413/index.php?title=Eldfjall&gesuggestededit=1&genewcomertasktoken=jmnp0gblgrghe2vhni2hb2ehn20upf2p&mpo=growthexperiments-revise-tone%3Atreatment&veaction=edit&section=all 09:59:30 cy:command ✔ new url http://127.0.0.1:9413/index.php?title=Eldfjall&gesuggestededit=1&mpo=growthexperiments-revise-tone%3Atreatment&veaction=edit&section=all 09:59:30 cy:xhr ➟ POST http://127.0.0.1:9413/api.php 09:59:30 Status: 200 09:59:30 cons:info ✱ You are running a development build of Vue. 09:59:30 Make sure to use the production build (*.prod.js) when deploying for production. 09:59:30 cy:command ✔ new url http://127.0.0.1:9413/index.php?title=Eldfjall&gesuggestededit=1&mpo=growthexperiments-revise-tone%3Atreatment 09:59:30 cy:command ✔ new url http://127.0.0.1:9413/index.php?title=Eldfjall&gesuggestededit=1&mpo=growthexperiments-revise-tone%3Atreatment#/editor/all 09:59:30 cons:warn ❖ Failed to log experiment interaction because mw.testKitchen is not defined 09:59:30 cons:warn ❖ This page is using the deprecated ResourceLoader module "moment". 09:59:30 [1.44] Use mediawiki.DateFormatter or native Intl function instead. See https://phabricator.wikimedia.org/T146798 09:59:30 cy:xhr ➟ GET http://127.0.0.1:9413/api.php?action=visualeditor&format=json&paction=parse&page=Eldfjall&uselang=en&editintro=&preload=&preloadparams=&formatversion=2 09:59:30 Status: 200 09:59:30 cy:command ✔ get .close-all-button button 09:59:30 cy:command ✔ assert expected **<button.cdx-button.cdx-button--action-default.cdx-button--weight-quiet.cdx-button--size-medium.ext-growthExperiments-OnboardingDialog__header__top__button>** to be **visible** 09:59:30 cy:command ✔ click 09:59:30 cy:xhr ➟ POST http://127.0.0.1:9413/api.php 09:59:30 Status: 200 09:59:30 cy:command ✔ get .ve-ui-editCheckActionWidget 09:59:30 cy:command ✔ assert expected **<div.oo-ui-widget.oo-ui-labelElement.oo-ui-flaggedElement-warning.oo-ui-iconElement.oo-ui-messageWidget-block.oo-ui-messageWidget.ve-ui-editCheckActionWidget>** to be **visible** 09:59:30 cons:warn ❖ Failed to log experiment interaction because mw.testKitchen is not defined 09:59:30 cy:xhr ➟ POST http://127.0.0.1:9413/api.php 09:59:30 Status: 200 09:59:30 cy:command ✔ wait 1000 09:59:30 cy:command ✔ get .ve-ui-editCheckActionWidget 09:59:30 cy:command ✔ assert expected **<div.oo-ui-widget.oo-ui-labelElement.oo-ui-flaggedElement-warning.oo-ui-iconElement.oo-ui-messageWidget-block.oo-ui-messageWidget.ve-ui-editCheckActionWidget>** to be **visible** 09:59:30 cy:command ✔ get .ve-ui-editCheckActionWidget 09:59:30 cy:command ✔ assert expected **<div.oo-ui-widget.oo-ui-labelElement.oo-ui-flaggedElement-warning.oo-ui-iconElement.oo-ui-messageWidget-block.oo-ui-messageWidget.ve-ui-editCheckActionWidget>** to have a length of **1** 09:59:30 Actual: 1 09:59:30 Expected: 1 09:59:30 cy:command ✔ get .ve-ui-editCheck-gutter-action-warning .oo-ui-image-warning 09:59:30 cy:command ✘ assert expected **<span.oo-ui-widget.oo-ui-widget-enabled.oo-ui-iconElement-icon.oo-ui-labelElement-invisible.oo-ui-iconWidget.oo-ui-iconElement.oo-ui-icon-alert.oo-ui-flaggedElement-warning.oo-ui-image-warning>** to be **visible** 09:59:30 09:59:30 09:59:30 - Closes the Editor when declining Edits and suggests a new task 09:59:30 - Shows the Revise Tone Edit Check and tags edits 09:59:30 09:59:30 09:59:30 1 passing (39s) 09:59:30 4 pending 09:59:30 1 failing 09:59:30 09:59:30 1) Revise Tone 09:59:30 On mobile 09:59:30 Shows the Revise Tone Edit Check: 09:59:30 AssertionError: Timed out retrying after 20000ms: expected '<span.oo-ui-widget.oo-ui-widget-enabled.oo-ui-iconElement-icon.oo-ui-labelElement-invisible.oo-ui-iconWidget.oo-ui-iconElement.oo-ui-icon-alert.oo-ui-flaggedElement-warning.oo-ui-image-warning>' to be 'visible' 09:59:30 09:59:30 This element `<span.oo-ui-widget.oo-ui-widget-enabled.oo-ui-iconElement-icon.oo-ui-labelElement-invisible.oo-ui-iconWidget.oo-ui-iconElement.oo-ui-icon-alert.oo-ui-flaggedElement-warning.oo-ui-image-warning>` is not visible because its parent `<div.oo-ui-window-content.oo-ui-dialog-content.ve-ui-sidebarDialog-content.oo-ui-window-content-setup.oo-ui-window-content-ready>` has CSS property: `overflow: hidden` and an effective width and height of: `44 x 0` pixels. 09:59:30 at Context.eval (webpack://GrowthExperiments/./cypress/e2e/ReviseTone.cy.ts:126:75) ``` Video: https://integration.wikimedia.org/ci/job/quibble-with-gated-extensions-selenium-php83/24532/artifact/log/GrowthExperiments/ReviseTone.cy.ts.mp4 - The relevant part starts at 0:18 - The check is visible - why does it not find it? Or is this about the ⚠️-icon in the gutter being partially obscured by the help-panel button? == Acceptance criteria * [ ] The test no longer flakily fails on this check
T422187: [QA] Suggested tasks issues
Task
This is a list of tasks/issues to serve as a reference for future prioritization of work on SE workflows. **(1) Wrong message after all suggestions were rejected.** Tested on `testwiki wmf.22`. @Sgs comment - https://phabricator.wikimedia.org/T336245#9095986 >|Mobile Structured (AddLink) |VE Yes, wrong messaging |Yes Yields console errors, same as T342465#9081167. The messaging is wrong when all recommendations have been rejected (You've published an edit as opposite of Thanks for reviewing suggestions. Keep going!) In the gif below the following steps are illustrated: - a user selects an article with Add link task - on an article, a user rejects all suggestions - after the last suggestion was rejected, a user sees the "Save" overlay and clicks on the "Done" button - a message appears "Congratulations on publishing another suggested edit!" **(2) {T421306} - re-confirmed on `testwiki wmf.22`** **(3) The congrats message appears after a suggested message is undone via View history link** Steps: - make an a SE edit - on an article where the edit was made, go to View history" - in "View history" click `undo` - the SE edit is undone, the congrats message apears. **(4) [WIP] re-check ** {T342465}
T422082: "Get started here" incorrectly points to central notice banner
Task
(found by @AAlhazwani-WMF) Steps: 1. As a non-logged user on mobile `enwiki wmf.21`, go to the Main page and click on 'Log in" 2. Click on "Join Wikipedia" to create a new account 3. After a new account is created, the Welcome survey is displayed - fill it out & submit 4. Go to Homepage button is displayed - do not click. 5. Click on the side menu item - Main page Main page with "Get started here" is displayed pointing to the central notice banner. {F74752325} ** What should happen instead:** - "Get started here" should only to the user menu icon - Hide the central notice banner as long as the 'Get started here' banner is visible. So that even if they don't dismiss the banner - and if they visit other pages - the arrow is still pointing at the user button in the top bar.
T421655: Onboarding experiment: Redirect Main Page account creators to Homepage post-registration
Task
####User Story: As a newcomer who has just created an account from the Main Page, I want to be guided to a clear and personalized starting point so that I understand what to do next and can begin contributing right away. ####Background: Newcomers who create accounts from the Main Page are often returned to the Main Page after registration. This experience lacks clear next steps, personalization, and guidance, which may hinder activation. This task proposes an experiment to redirect these users to their Homepage immediately after account creation to provide a more structured and supportive onboarding experience. ####Problem: After account creation, newcomers need a clear landing experience that helps them get started. ####Currently: - Many accounts are created from the Main Page [[ https://www.mediawiki.org/wiki/Growth/Analytics_updates/EditorJourney_initial_report | In past analysis, ]] ~30% of new accounts were created after visiting the Mainpage. - Users are returned to the Main Page post-registration - The Mainpage is content-dense and not designed for onboarding - Why so many automated "Welcomes" and competing calls to action? - {F74286340} - This may contribute to confusion, drop-off, and lower activation rates. ####Hypothesis: If newcomers who create accounts from the Main Page are redirected to their Homepage after registration, they will be more likely to engage with onboarding features and complete constructive edits, leading to improved activation and retention. ####Experiment Design: - Target group: Newly registered users who create accounts from the Main Page - Treatment: Redirect users to their Homepage immediately after account creation - Control: Existing behavior (return to Main Page) - Platform: Prioritize mobile, but include desktop if feasible - Metrics: - Constructive activation rate - Constructive edit rate - 2-week retention ####Acceptance Criteria: - Consider instrumentation to confirm entry point (Main Page account creation) - Experiment is implemented and gated to users who create accounts from the Main Page - Users in the treatment group are reliably redirected to their Homepage - Metrics are tracked and analyzed against control group
T421459: Allow mentees to remove or clear old questions from the “Your mentor” Homepage module
Task
#### User Story As a **mentee**, I want to remove old or irrelevant questions from my “Your mentor” module so that my homepage reflects my current needs and progress, and I can focus on questions that matter now (and not be annoyed by seeing old questions). #####Description: Mentees currently cannot remove or clear previously asked questions from the “Your mentor” module on the homepage. This can lead to outdated or unanswered questions persisting indefinitely, even after a mentee has progressed or been reassigned to a new mentor. [[ https://en.wikipedia.org/wiki/Wikipedia:Teahouse#c-WendlingCrusader-20260326161200-Is_it_possible_to_edit_my_homepage? | Example feedback ]]: A mentee reported that after being assigned a new mentor, their homepage still shows questions asked to a previous mentor two years ago. They would like the ability to remove these outdated questions. ####Proposed solution: Allow mentees to: - Remove individual questions from the module **Impact:** - Keeps the mentor module relevant and up to date - Reduces clutter and confusion for returning or progressing mentees - Improves sense of ownership and control over the homepage experience
T421306: [wmf.5 - regression] desktop Help panel cannot be open on Link recommendations articles
Task
**//Notes:// ** - The issue is present on `wmf.5` - **mobile** Help panel can be open for any type of SE tasks - Help panel for other tasks works as expected - {icon exclamation-triangle color=green} If you click to close the add link dialog, the Help panel works as expected. ====Steps:===== - from Homepage go to any Link recommendation article - an article in Suggested Edit mode displays the Help panel as collapsed - click to uncollapse Help panel =====What happened===== **(1)** the panel cannot be open. When the Help button is clicked, the background of a link recommendation card changes to grey (click on the gif below). {F73668092} **(2)** when a user switches to Read mode on an Add link article, the Help button and SE button persist, see the steps below: - a user in SE mode on an Add a link article - the Help button is not clickable, but Add link functionality and UI works as expected. - click to collapse the SE dialog - it collapses and is displayed alongside with the Help button - switch to the Read mode - the non-clickable buttons are still displayed: {F78733138} =====What should happen===== - if a button is displayed, it should be clickable - Read mode should not display the SE and Help buttons
T420653: New editor's Special:Homepage in dark mode shows inverted image in suggested-edits-card
Task
**Steps to replicate the issue** (include links if applicable): 1. Set Wikipedia to "light mode" via Preferences > [[ https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-rendering | Appearance ]] 1. Turn on "dark mode toggle" via Preferences > Gadgets > [[ https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets | Dark mode toggle: Enable a toggle for using a light text on dark background color scheme ]] 1. Go to [[ https://en.wikipedia.org/w/index.php?title=Special:Homepage | https://en.wikipedia.org/w/index.php?title=Special:Homepage ]] for new editors (I think this is part of the "growth experiments" feature set?). I have attached a screenshot at the bottom of this issue. 1. Refresh until the article under "Suggested Edits" has an image 1. Click on the person icon in the top right of the page to open the "Personal Settings" dropdown & use the "dark mode toggle" to change the page to dark mode. {F73670544} 1. Observe that the image in the `.suggested-edits-card` is inverted (see screenshot at the bottom of this issue) **What happens?**: Images in the suggested-edits-card on the Special:Homepage are inverted when dark mode is active. (see attached screenshot at the bottom of this bug) **What should have happened instead?**: Images should not be inverted in dark mode. **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): MediaWiki: 1.46.0-wmf.20 (f1911ec), 18:24, 19 March 2026 **Other information** (browser name/version, screenshots, etc.): Firefox 148.0.2 On other pages, images are not inverted in dark mode. This is because the CSS style rule which applies `filter: invert(1) hue-rotate(180deg);` uses the `html img:not(.mw-invert)` selector to ignore most images, such as those on article pages. However, in the `.suggested-edits-card` on the Special:Homepage, images are placed using a CSS rule `background-image` instead of with an `img` element. Therefore, the normal selector that protects most images from inversion is not applied correctly. **My first impression is that you could add a class like `.cdx-no-invert` to the div with the background-image (`.se-card-image`) so that that element is not inverted with the rest of the page in dark mode.** {F73157967}
T420566: Decide how GrowthExperiments should be handled on closed wikis
Task
==== Background The #growth-team enabled #growthexperiments on all publicly editable Wikipedias to help newcomers edit the wikis (T304052). To do that, we changed the `growthexperiments` dblist to correspond to `wikipedia.dblist - private.dblist - closed.dblist` (plus `frwiktionary`, which is the only non-Wikipedia we operate on). However, at times, Wikipedias get closed, which means they disappear from the `growthexperiments` dblist. ==== Problem When requesting schema changes, we ask it to be performed on the `growthexperiments` dblist. However, closed wikis can also have the corresponding tables. Even though the GrowthExperiments extension is not enabled there //now//, wikis can get reopened (at which point, GrowthExperiments would get re-enabled, and it would not see the schema changes made in the meantime). ==== Possible solutions There are two approaches we can take: 1. **Drop growthexperiments tables on closing Wikipedias**: each time we close a wiki in the `growthexperiments` dblist, we would need to drop the corresponding DB tables; if it is reopened, they can be created again 2. **Enable GrowthExperiments on all closed Wikipedias and create the DB tables there**: alternatively, we can set `growthexperiments` to `wikipedia - private`, and keep closed wikis in there; in that case, the DB tables would still be maintained and updated, and re-enabling would be straightforward The advantage of the first option is that we do not have any DB tables we don't need in production. However, it would be pretty expensive on people time (especially given we tend to be fairly careful before dropping tables). The second solution brings some extra empty tables, but it will work on its own, without needing human attendance. Tagging #DBA to advice on what approach should the #growth-team take. ==== Acceptance Criteria * [ ] update https://wikitech.wikimedia.org/wiki/Close_a_wiki to include a "notify DBAs the wiki was closed" instruction * [ ] the task template should list extensions that are auto-disabled on closing a wiki (i.e. including GrowthExperiments)
T420542: Design exploration: Evolve Impact module for experienced editors and patrollers
Task
####User Story: As an experienced Wikimedian editor or patroller, I want access to impact metrics that match the depth and complexity of my contributions, so that I can efficiently understand and evaluate my work without relying on tools that are too basic or disconnected from my workflow. ####Description The Growth team’s Impact module on the Newcomer Homepage is designed to reinforce early contributions by showing lightweight impact metrics (for example, pageviews and edit counts). However, community feedback suggests that the module becomes less useful as editors gain experience, particularly for highly active contributors and patrollers. More experienced editors often rely on external tools such as the XTools Edit Counter for deeper and more comprehensive contribution insights. This raises an opportunity to rethink how the Impact module scales with user experience, and whether it should adapt, redirect, or phase out over time. ####Problem The current Impact module: - Is optimized for newcomer motivation, not ongoing contributor workflows - Provides limited depth compared to tools used by experienced editors - Does not adapt based on editor maturity or needs ####Community feedback >>! In T341599#11721478, @Mathglot wrote: > The more experience a user has, the more they should shift away from using the Impact module and toward the [[https://xtools.wmcloud.org/ec | Toolforge Edit counter tool]], which contains all of the Impact stats (except for 'streak', which is probably the least valuable of them, especially when one is no longer a newbie). > > Note: the tool does have some limits, but they are stratospheric; one million edits is a hard limit. For a typical user, results take a second or two. The #1000 [[https://en.wikipedia.org/wiki/Wikipedia:List_of_Wikipedians_by_number_of_edits|top editor]] (99k edits) takes about [[https://xtools.wmcloud.org/ec/en.wikipedia.org/Gidonb|9 seconds]] to return complete results. The #25 editor (918k edits) takes [[https://xtools.wmcloud.org/ec/en.wikipedia.org/WOSlinker|over a minute]]. For a user with > 1M edits, the tool [[https://xtools.wmcloud.org/sc/en.wikipedia.org/BrownHairedGirl|returns immediately]] but with only one estimated statistic. > > I would propose we implement a "shift" in the Impact module, thus: > * add an Ec tool link below the current stats when the users total edits exceeds X (X =~ 1,000?) > * replace all content in the module with a 'Please see...' and a link to the Ec tool when total edits exceeds Y (Y =~ 5,000?) > * drop the Impact module when total edits exceeds Z (Z =~ 10,000?). > > So, for their first 1,000 edits, the modules would appear as it does now, and then at thresholds X, Y, and Z it would shift them increasingly towards using the tool. > > To help support this, and come up with good values for X, Y, and Z, it would be helpful to see a line graph of number of clicks on the Homepage tab as a percentage of all clicks by a given user (y-axis) plotted against total number of edits (x-axis). This might be useful for other growth apps as well. ---- ####Goal Explore design directions for how the Impact module could better support: - More experienced editors - Patrollers and high-volume contributors - While maintaining its effectiveness for newcomers **Design questions / exploration areas** - Should the Impact module adapt based on experience level? If so, how? - What is the right balance between keeping users within the Homepage ecosystem & pointing them to external tools like the XTools Edit Counter? - Are there opportunities to surface more advanced metrics in-product? ####Acceptance criteria - Design exploration includes multiple concepts - Sharing designs with involved WMF teams and interested community members (via this task)
T420354: Add alerting on suspiciously long mw-cron jobs
Task
Today, @Michael discovered there is a long-running mw-cron job for the Growth team: ``` migr@deploy2002:~$ kubectl logs -f job/growthexperiments-listtaskcounts-29513771 mediawiki-main-app Error from server (BadRequest): container "mediawiki-main-app" in pod "growthexperiments-listtaskcounts-29513771-jrv9k" is waiting to start: trying and failing to pull image migr@deploy2002:~$ kubectl get jobs -l team=growth,cronjob=growthexperiments-listtaskcounts NAME STATUS COMPLETIONS DURATION AGE growthexperiments-listtaskcounts-29513771 Running 0/1 33d 33d migr@deploy2002:~$ ``` This job should never take more than a couple of minutes to complete. If it takes more than an hour, we definitely have a problem. Would it be possible to add something like `max_expected_length = XX hours` to the job definition, and trigger an alert if the expected duration was exceeded? This would help us notice this much quickly than manually after a month. --- //Update 2026-03-19// - One alternative to passive alerting that we may want to consider is functionality for setting `activeDeadlineSeconds` on the cronjob's job template. That would provide an //active// backstop on execution time. As a side effect, the job failure alert should also fire, as a result of the job being terminated. See T420354#11722534.
T419938: Support per-user preference configuration
Task
This is similar to the current CommunityConfiguration, but it per-user instead of per-site, and this will be stored in a subpage of user page such as User:Example/twinkle.json See https://en.wikipedia.org/wiki/Wikipedia:Twinkle/Preferences for a current example, and also {T382959} for allowing gadgets to setup a per-site (instead of per-user) setting page. Note: * This is not suitable to be stored in user_property table since a gadget may introduce hundreds of options. See {T408733} * We may want to introduce a user right to edit other's per-user preference, to combat the situation that someone setting that improperly. This would be granted to sysops, who are able to edit others' JSON pages (and thus can modify such setting of anyone directly).
T419416: Add "email me a password" option to mobile account creation form
Task
This task builds on the account creation form cleanup (T409236) by adding an option for users to skip choosing a password and instead receive an auto-generated one via email. This is an existing pattern on MediaWiki (`create2` [[ https://www.mediawiki.org/wiki/Manual:Account_creation | Manual:Account creation ]]) but is currently not surfaced. Offering this option could simplify the form for users who prefer not to create a password on the spot. ####User story & summary: As a new user creating an account on mobile web, I want the option to receive a password via email so that I can complete registration without having to think of and type a password. ####Design: //**Scope: this task is scoped to Mobile only.**// {F72758817} ####Acceptance Criteria: AC1 - Checkbox display * Given I am on the account creation page on mobile web * When I view the password section * Then I see an "Email me a password instead" checkbox displayed above the password field, unchecked by default **When the checkbox is checked:** AC2 - Hide password fields * Given I check the "Email me a password instead" checkbox * When the form updates * Then the password field, password helper text, and confirm password field are hidden AC3 - Email field becomes required * Given I check the "Email me a password instead" checkbox * When the form updates * Then the email address field label no longer shows "(recommended)" and the field becomes required AC4 - Email field description removed * Given I check the "Email me a password instead" checkbox * When the form updates * Then the email address field description ("Email is required to recover your account...") is removed **When the checkbox is unchecked again:** AC5 - Restore default state * Given I uncheck the "Email me a password instead" checkbox * When the form updates * Then the password field, helper text, confirm password field, email optional indicator, and email description are all restored to their default state
T419415: Remove confirm password field from mobile account creation form
Task
If {T419413} is implemented, we may test if the "Confirm password" field becomes redundant - given that users can verify their password visually instead of retyping it. ####User story & summary: As a new user creating an account on mobile web, I want to register without having to type my password twice so that the form is shorter and faster to complete. ####Background & research: The confirm password field exists to prevent typos, but with a reveal password action in place (T419413), users can visually verify what they've typed. Removing the field reduces form length by one input - meaningful on mobile where screen space is limited and every field adds friction. Most platforms in the comparative analysis (T410558) that offer password reveal do not require password confirmation. ####Design: {F72757951} ####Acceptance Criteria: 1. Remove the "Confirm password" field from the account creation form on mobile web 2. The single password field continues to enforce the password requirements 3. The reveal password action (T419413) remains functional on the single password field
T419358: [EPIC] Personal Dashboard + Homepage [FY26-27, Deepen Engagement 1.3]
Task
https://www.mediawiki.org/wiki/Personal_Dashboard == Summary == As outlined in the [[ https://www.mediawiki.org/wiki/Contributors/Strategy | Contributors Strategy ]], volunteers currently face a fragmented experience that provides limited guidance on how to navigate the many available contribution pathways and policies. Over time, both volunteers and Wikimedia Foundation teams have attempted to address this problem through dashboards and special pages, such as: - The Newcomer Homepage ([[ https://en.wikipedia.org/wiki/Special:Homepage | en ]]) - Special:PersonalDashboard - Community-created dashboards and scripts - Special:Contribute ([[ https://en.wikipedia.org/wiki/Special:Contribute | en ]]) Active readers have also demonstrated interest in personalized experiences through products such as mobile feeds, the Android activity tab, and the annual Year in Review. At the same time, internet users increasingly expect a central starting page on platforms where they consume content or contribute. Experiments with the Newcomer Homepage show that a centralized hub can significantly improve retention and constructive activation. This Epic explores the creation of a unified personal homepage/dashboard that can support contributors across the journey from reader to experienced editor and moderator. The homepage would function as the engine behind a contributor experience that supports: - Discovering compelling opportunities to contribute - Being equipped to act on those opportunities - Having a rewarding experience where impact and next steps are clear - Creating this cycle is critical to building long-term participation habits and improving contributor retention, especially given the decline in active editors across Wikimedia projects. Because multiple use cases have emerged and experimentation requires flexible infrastructure, this Epic proposes establishing a new extensible architecture that supports homepage experimentation and modular dashboards across different contributor roles. == Objective: Deepen Engagement 1 == We increase the number of retained editors by 30% by delivering a structured, progression-driven, and more meaningful mobile-first editor experience. This is a milestone on our way to doubling retained editors within two years. == Key Result: Deepen Engagement 1.3 == By the end of Q2, achieve an x% increase in second-week retention for editors who are presented with interventions focused on editor progression through controlled experiments, compared to editors in the control group. **Context** This work advances a unified personal dashboard that supports the full journey from reader to contributor to moderator. The initiative will: - Integrate the Newcomer Homepage and the Personal Dashboard MVP into a cohesive experience - Introduce a clear progression system that helps contributors advance beyond their first edits - Strengthen onboarding pathways for moderation and cleanup work - Help interested contributors take on more responsibility while reducing patrolling backlogs over time == Benefits == A centralized homepage or personal dashboard allows the platform to connect the dots for volunteers in ways that are currently difficult. Key benefits include: - Modular experiences that can be customized by wikis and individuals - Personalized recommendations for impactful contributions - Clear visibility of impact so contributors understand the value of their work - Recognition and milestone experiences that celebrate progress - A consistent entry point for discovering opportunities and returning to continue contributing This approach can benefit multiple audiences: - Readers who want deeper engagement with content - New contributors learning how to participate - Experienced editors seeking meaningful work - Moderators managing community workflows == Use Cases == === Reader experience === As a reader, I can engage with Wikipedia in a personalized way that helps me curate content and discover opportunities to contribute. '''Supporting context''' === Language and localization contributors === As a translator, I can seamlessly integrate translation work with other types of contributions while understanding my overall impact. === New contributors === As a newcomer, I receive guided steps that help me: - Learn how to contribute - Find help when needed - Understand the impact of my edits === Experienced editors === As an experienced editor, I can easily identify high-impact opportunities to contribute and track my contributions and impact. === Moderators and patrollers === As a moderator, I have access to a customizable dashboard that: - Reduces fragmentation across moderation tools - Makes moderation workflows easier to navigate - Supports skill development - Helps reduce community moderation backlog NOTE: this epic is still a work is progress. This work is scheduled for July 2026 - December 2026.
T419305: Vector 2022 defaults for new accounts: collapse tools & appearances menus
Task
####User story & summary: As a new Wikipedia account holder using the desktop site, I want the interface to feel simple and focused when I first arrive, so that I am not overwhelmed by too many menus and options while I am trying to get started. **Context:** The #growth-team is exploring ways to reduce cognitive load for newcomers during account creation and their first editing sessions. Minimizing non-essential interface elements by default may help create a simpler initial experience while still preserving full functionality for users who want to access these menus. **Related: ** - {T409236} - {T317884} ####Description: New account holders often encounter a large amount of interface information when they first arrive on the desktop experience. In the current Vector 2022 layout, the Tools and Appearance menus appear expanded in the right sidebar. While these menus are useful for experienced contributors, they may contribute to information overload for people who are just getting started. {F72643484} The expanded menus also create layout issues for some pages: {F72643385} This task proposes minimizing the Tools and Appearance menus by default for newly created accounts using the desktop Vector 2022 skin. The menus would remain available but would appear collapsed initially, allowing newcomers to expand them if needed. The goal is to simplify the interface and reduce visual complexity during the earliest stages of the editing experience. ####Proposed behavior: For newly created accounts using Vector 2022 on desktop: - The Tools menu should be collapsed by default. - The Appearance menu should be collapsed by default. - Users should still be able to manually expand either menu. - Once expanded, normal interface behavior should continue (remembering the user’s preference). **Scope considerations:** - Applies only to newly created accounts. - Applies only to the Vector 2022 skin on desktop. - Does not remove or hide functionality, only changes the default state of the menus. **Open questions:** - Can we release this an a quick A/B test to measure the impact on new editor metrics (constructive activation, constructive edit rate, retention, etc.). - In the longer term, we may want to reconsider the placement of the Appearance menu when it is collapsed into the main header. For logged-in users, it may not be immediately clear why appearance-related settings are located separately rather than within Preferences, where most other user configuration options live. ####Acceptance Criteria: Given I'm on the wikis on Desktop while using Vector 2022, When I visit Special:CreateAccount or Special:UserLogin, Then the Appearance and Tools menus are collapsed by default Given I'm on the wikis on Desktop while using Vector 2022, When I've successfully created my new account Then the Appearance and Tools menus are collapsed by default
T419266: Make the TestKitchen extension available on PatchDemo
Task
Request: It would be great to have the TestKitchen extension available on PatchDemo, so that experiment URL overrides like `?mpo=we-1-8-account-creation-form-v1:treatment` work natively there. This would be useful to demo upcoming experiments on PatchDemo without having to craft bespoke workarounds. Acceptance Criteria [] Add TK to default extensions [[ https://gitlab.wikimedia.org/repos/test-platform/catalyst/patchdemo/-/blob/main/ADDING_EXTENSIONS.md | following these instructions ]] [] `mpo` query should show the treatment, but follow current behaviour -- not send events. [] Update documentation to reflect change
T419172: LogicException: GrowthExperiments\NewcomerTasks\TaskSuggester\NewcomerTasksCacheRefreshJob executed for invalid userId (0)
Task
==== Error ==== * mwversion: 1.46.0-wmf.18 * timestamp: 2026-03-05T21:23:40.144Z * phpversion: `8.3.30` * reqId: `cc4e0baa-2184-4d5a-9431-b1e6b35cc8b1` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2026-03-04T21:23:40.144Z',to:'2026-03-05T21:53:36.789Z'))&_a=(query:(query_string:(query:'reqId:%22cc4e0baa-2184-4d5a-9431-b1e6b35cc8b1%22'))) | Find reqId in Logstash ]] ```name=normalized_message,lines=10 [{reqId}] {exception_url} LogicException: GrowthExperiments\NewcomerTasks\TaskSuggester\NewcomerTasksCacheRefreshJob executed for invalid userId (0) ``` | Frame | Location | Call | -- | -- | -- | from | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.18/includes/NewcomerTasks/TaskSuggester/NewcomerTasksCacheRefreshJob.php#42 | /srv/mediawiki/php-1.46.0-wmf.18/extensions/GrowthExperiments/includes/NewcomerTasks/TaskSuggester/NewcomerTasksCacheRefreshJob.php(42) ]] | | #0 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/EventBus/+blame/refs/heads/wmf/1.46.0-wmf.18/includes/JobExecutor.php#94 | /srv/mediawiki/php-1.46.0-wmf.18/extensions/EventBus/includes/JobExecutor.php(94) ]] | GrowthExperiments\NewcomerTasks\TaskSuggester\NewcomerTasksCacheRefreshJob->run() | #1 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+blame/refs/heads/master/rpc/RunSingleJob.php#60 | /srv/mediawiki/rpc/RunSingleJob.php(60) ]] | MediaWiki\Extension\EventBus\JobExecutor->execute(array) | #2 | {main} | ==== Impact ==== - 6 error reports `frwiki` https://logstash.wikimedia.org/goto/3edfea0b1b376704952d1edb7f7a5e02 - the error seems to be present for some time - 30 days report https://logstash.wikimedia.org/goto/f894fb895636523d0825826c3eb78d9a
View All Results

Panel Used By

This panel is not used on any dashboard or inside any other panel container.

Event Timeline

RHo renamed this panel from to Open Growth Team Tasks.Oct 30 2018, 5:42 PM

RHo edited a custom field.

RHo edited an edge.

RHo edited an edge.Oct 30 2018, 5:51 PM

Open Growth Team TasksActivePublicActions

Open Growth Team TasksView All

Panel Used By

Event Timeline

Open Growth Team Tasks
ActivePublic
Actions

Open Growth Team Tasks
View All