Search Global Search

Global Search
Use Results
Edit Query
Hide Query

	Open
	Closed

Use the application-specific Advanced Search for better results and additional search criteria: Tasks, Commits. (More information)

T435248: Allow display of login link on create account form
Task
== Background For certain workflows where it is expected that users will not have accounts, but some may, it would be useful to add a login link to the bottom of the create account. Currently this is not possible. It is proposed we allow optional display of this link via a query string parameter. == User story As a user who is responding to a certain campaign (e.g. email or on platform prompt) that requires an account, I want to be able to signal that I have an account and complete the process via login. == Requirements [] It should be possible to toggle on a login link that shows at the bottom of the form === BDD [] If I visit /wiki/Special:CreateaAccount I do not see the login link [] If I visit /wiki/Special:CreateaAccount?showlogin=1 the form includes a login link === Test Steps - For QA engineer to fill out == Design {F99024620} == Acceptance criteria - Add acceptance criteria == Communication criteria - does this need an announcement or discussion? - Add communication criteria == Rollback plan Not necessary since this is opt in only. //This task was created by Version 1.2.0 of the [[ https://mediawiki.org/w/index.php?title=Reading/Web/Request_process | Web team task template ]] using [[ https://phabulous.toolforge.org/ | phabulous ]] //
T435145: Account Creation: make it clearer that email is still optional on Special:CreateAccount
Task
#####User story As a new account creator, I want to clearly understand that providing an email address is optional, so that I can make an informed choice about whether to share it without being confused or blocked during signup. As WMF Legal, I want to be sure our account creation form is clear and transparent, so there is no risk of breaking trust or legal rules. #####Design {F97006671} #####Acceptance criteria - Add the [[ https://doc.wikimedia.org/codex/latest/components/demos/field.html | codex field ]] `optional` prop for the email field
T434905: Compute coverage reports for ImpactModule extension
Task
The extension is not at https://doc.wikimedia.org/cover-extensions/ and the `coverage` pipeline is not registered for that extension in CI.
T434881: ImpactModule should make AQS requests in parallel
Task
See https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ImpactModule/+/1323994/comment/fa1c6eff_3ce4a293/ for the original thought by @Michael.
T434758: TypeError: MediaWiki\Output\OutputPage::parseInternal(): Argument #1 ($text) must be of type string, null given, called in /srv/mediawiki/php-1.47.0-wmf.14/includes/Output/OutputPage.php on line 2515
Task
==== Error ==== * service.version: 1.47.0-wmf.14 * timestamp: 2026-08-13T05:10:38.823Z * labels.phpversion: `8.3.33` * trace.id: `441b1cc2-0f8e-4a44-94b9-bbbe8f7578ab` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2026-08-12T05:10:38.823Z',to:'2026-08-13T08:51:02.731Z'))&_a=(query:(query_string:(query:'reqId:%22441b1cc2-0f8e-4a44-94b9-bbbe8f7578ab%22'))) | Find trace.id in Logstash ]] ```name=labels.normalized_message,lines=10 [{reqId}] {exception_url} TypeError: MediaWiki\Output\OutputPage::parseInternal(): Argument #1 ($text) must be of type string, null given, called in /srv/mediawiki/php-1.47.0-wmf.14/includes/Output/OutputPage.php on line 2515 ``` | Frame | Location | Call | -- | -- | -- | from | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/Output/OutputPage.php#2554 | /srv/mediawiki/php-1.47.0-wmf.14/includes/Output/OutputPage.php(2554) ]] | | #0 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/Output/OutputPage.php#2515 | /srv/mediawiki/php-1.47.0-wmf.14/includes/Output/OutputPage.php(2515) ]] | MediaWiki\Output\OutputPage->parseInternal(null, MediaWiki\Title\Title, bool, MediaWiki\Parser\ParserOptions, bool, null, bool) | #1 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/Output/OutputPage.php#2538 | /srv/mediawiki/php-1.47.0-wmf.14/includes/Output/OutputPage.php(2538) ]] | MediaWiki\Output\OutputPage->parseAsInterface(null, bool) | #2 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/AbuseFilter/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/BlockedDomains/BlockedDomainEditor.php#157 | /srv/mediawiki/php-1.47.0-wmf.14/extensions/AbuseFilter/includes/BlockedDomains/BlockedDomainEditor.php(157) ]] | MediaWiki\Output\OutputPage->parseInlineAsInterface(null) | #3 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/AbuseFilter/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/BlockedDomains/BlockedDomainEditor.php#130 | /srv/mediawiki/php-1.47.0-wmf.14/extensions/AbuseFilter/includes/BlockedDomains/BlockedDomainEditor.php(130) ]] | MediaWiki\Extension\AbuseFilter\BlockedDomains\BlockedDomainEditor->doDomainRow(array, bool) | #4 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/libs/ObjectCache/WANObjectCache.php#1840 | /srv/mediawiki/php-1.47.0-wmf.14/includes/libs/ObjectCache/WANObjectCache.php(1840) ]] | MediaWiki\Extension\AbuseFilter\BlockedDomains\BlockedDomainEditor->MediaWiki\Extension\AbuseFilter\BlockedDomains\{closure}(bool, int, array, null, array) | #5 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/libs/ObjectCache/WANObjectCache.php#1650 | /srv/mediawiki/php-1.47.0-wmf.14/includes/libs/ObjectCache/WANObjectCache.php(1650) ]] | Wikimedia\ObjectCache\WANObjectCache->fetchOrRegenerate(string, int, Closure, array, array) | #6 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/AbuseFilter/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/BlockedDomains/BlockedDomainEditor.php#124 | /srv/mediawiki/php-1.47.0-wmf.14/extensions/AbuseFilter/includes/BlockedDomains/BlockedDomainEditor.php(124) ]] | Wikimedia\ObjectCache\WANObjectCache->getWithSetCallback(string, int, Closure) | #7 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/AbuseFilter/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/BlockedDomains/BlockedDomainEditor.php#53 | /srv/mediawiki/php-1.47.0-wmf.14/extensions/AbuseFilter/includes/BlockedDomains/BlockedDomainEditor.php(53) ]] | MediaWiki\Extension\AbuseFilter\BlockedDomains\BlockedDomainEditor->showList() | #8 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/AbuseFilter/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/BlockedDomains/EditorCapability.php#41 | /srv/mediawiki/php-1.47.0-wmf.14/extensions/AbuseFilter/includes/BlockedDomains/EditorCapability.php(41) ]] | MediaWiki\Extension\AbuseFilter\BlockedDomains\BlockedDomainEditor->execute(null) | #9 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CommunityConfiguration/+blame/refs/heads/wmf/1.47.0-wmf.14/src/Specials/SpecialCommunityConfiguration.php#63 | /srv/mediawiki/php-1.47.0-wmf.14/extensions/CommunityConfiguration/src/Specials/SpecialCommunityConfiguration.php(63) ]] | MediaWiki\Extension\AbuseFilter\BlockedDomains\EditorCapability->execute(MediaWiki\Extension\AbuseFilter\BlockedDomains\BlockedDomainConfigProvider, null) | #10 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/SpecialPage/SpecialPage.php#727 | /srv/mediawiki/php-1.47.0-wmf.14/includes/SpecialPage/SpecialPage.php(727) ]] | MediaWiki\Extension\CommunityConfiguration\Specials\SpecialCommunityConfiguration->execute(string) | #11 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/SpecialPage/SpecialPageFactory.php#1725 | /srv/mediawiki/php-1.47.0-wmf.14/includes/SpecialPage/SpecialPageFactory.php(1725) ]] | MediaWiki\SpecialPage\SpecialPage->run(string) | #12 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/Actions/ActionEntryPoint.php#505 | /srv/mediawiki/php-1.47.0-wmf.14/includes/Actions/ActionEntryPoint.php(505) ]] | MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, MediaWiki\Context\RequestContext) | #13 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/Actions/ActionEntryPoint.php#145 | /srv/mediawiki/php-1.47.0-wmf.14/includes/Actions/ActionEntryPoint.php(145) ]] | MediaWiki\Actions\ActionEntryPoint->performRequest() | #14 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/MediaWikiEntryPoint.php#180 | /srv/mediawiki/php-1.47.0-wmf.14/includes/MediaWikiEntryPoint.php(180) ]] | MediaWiki\Actions\ActionEntryPoint->execute() | #15 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.14/index.php#44 | /srv/mediawiki/php-1.47.0-wmf.14/index.php(44) ]] | MediaWiki\MediaWikiEntryPoint->run() | #16 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+blame/refs/heads/master/w/index.php#3 | /srv/mediawiki/w/index.php(3) ]] | require(string) | #17 | {main} | ==== Impact ==== ==== Notes ====
T434544: LogicException: GrowthExperiments\NewcomerTasks\TaskSuggester\NewcomerTasksCacheRefreshJob executed for invalid userId (55085007)
Task
==== Error ==== * service.version: 1.47.0-wmf.14 * timestamp: 2026-08-11T07:58:21.127Z * labels.phpversion: `8.3.33` * trace.id: `ee12b9a0-d10d-469a-a8fe-fdc2ae82d298` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2026-08-10T07:58:21.127Z',to:'2026-08-11T13:27:27.223Z'))&_a=(query:(query_string:(query:'reqId:%22ee12b9a0-d10d-469a-a8fe-fdc2ae82d298%22'))) | Find trace.id in Logstash ]] ```name=labels.normalized_message,lines=10 [{reqId}] {exception_url} LogicException: GrowthExperiments\NewcomerTasks\TaskSuggester\NewcomerTasksCacheRefreshJob executed for invalid userId (55085007) ``` | Frame | Location | Call | -- | -- | -- | from | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/NewcomerTasks/TaskSuggester/NewcomerTasksCacheRefreshJob.php#42 | /srv/mediawiki/php-1.47.0-wmf.14/extensions/GrowthExperiments/includes/NewcomerTasks/TaskSuggester/NewcomerTasksCacheRefreshJob.php(42) ]] | | #0 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/EventBus/+blame/refs/heads/wmf/1.47.0-wmf.14/includes/JobExecutor.php#94 | /srv/mediawiki/php-1.47.0-wmf.14/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} | ==== Notes ==== * xref: {T419172} (not exactly the same, but probably very related)
T434476: updateIsActiveFlagForMentees.php can be heavily optimized
Task
Currently, `updateIsActiveFlagForMentees.php` queries the database individually for each mentee it processes. For huge wikis, that can take a significant portion of time (see the four hours in T432959#12200953, for example). Most methods `updateIsActiveFlagForMentees.php` use support batching, at least: * `UserIdentityLookup::newSelectQueryBuilder()` * `UserRegistrationLookup::getFirstRegistrationBatch()` (technically a difference from `getRegistration()`, which we use, but shouldn't be significant, plus easy to implement `getRegistrationBatch` anyway) Unfortunately, `UserEditTracker::getLatestEditTimestamp` doesn't have a batched version, and adding it would be a ton of work (at the least, `ActorStore` would need to have a batched version too). Given `actor` table is now locked in (and as we query it anyway), a direct query seems easiest at the moment.
T434360: GrowthExperiments tests fail when virtual domains are configured
Task
When virtual domains are properly configured (local multi-DB setup), GrowthExperiments tests fail: ``` Wikimedia\Rdbms\DBQueryError : Error 1146: Table 'awiki.unittest_growthexperiments_mentor_mentee' doesn't exist Function: GrowthExperiments\Mentorship\Store\DatabaseMentorStore::loadMentorUserUncached Query: SELECT gemm_mentor_id FROM `unittest_growthexperiments_mentor_mentee` `growthexperiments_mentor_mentee` WHERE gemm_mentee_id = 1 AND gemm_mentor_role = 'primary' LIMIT 1 /var/www/html/w/includes/libs/Rdbms/Database/Database.php:1231 /var/www/html/w/includes/libs/Rdbms/Database/Database.php:1215 /var/www/html/w/includes/libs/Rdbms/Database/Database.php:1189 /var/www/html/w/includes/libs/Rdbms/Database/Database.php:644 /var/www/html/w/includes/libs/Rdbms/Database/Database.php:1369 /var/www/html/w/includes/libs/Rdbms/Database/Database.php:1318 /var/www/html/w/includes/libs/Rdbms/Database/DBConnRef.php:129 /var/www/html/w/includes/libs/Rdbms/Database/DBConnRef.php:366 /var/www/html/w/includes/libs/Rdbms/QueryBuilder/SelectQueryBuilder.php:779 /var/www/html/w/extensions/GrowthExperiments/includes/Mentorship/Store/DatabaseMentorStore.php:47 /var/www/html/w/extensions/GrowthExperiments/includes/Mentorship/Store/MentorStore.php:99 /var/www/html/w/includes/libs/ObjectCache/WANObjectCache.php:1709 /var/www/html/w/includes/libs/ObjectCache/WANObjectCache.php:1519 /var/www/html/w/extensions/GrowthExperiments/includes/Mentorship/Store/MentorStore.php:95 /var/www/html/w/extensions/GrowthExperiments/tests/phpunit/integration/Mentorship/Store/DatabaseMentorStoreTest.php:46 ``` and similar. This happens because `growthexperiments_mentor_mentee` does not exist on the main DB, so cloning doesn't copy it into the test DB.
T434350: [EPIC] Add a Link: improvements requested by communities
Task
=== User story As a newcomer completing "Add a Link" suggested edits, I want the link suggestions I see to be accurate and appropriate, so that my edits improve articles and are less likely to be reverted. As an experienced editor or patroller, I want communities' feedback about "Add a Link" suggestion quality to be addressed, so that reviewing newcomer edits takes less effort and communities keep the feature enabled. === Background Communities have requested improvements to the "Add a Link" structured task. This epic collects that work: improvements to the machine learning model that generates link suggestions (owned by #machine-learning-team), community configuration improvements (owned the by #growth-team), and and other relevant UX/UI improvements (owned the by #growth-team). === Model improvements - {T405185} - {T434259} - {T409138} - {T415623} - {T415622}) === Community configuration - {T434255} - {T317290} === UX/UI improvements - TBD
T434319: Revalidate Add Link suggestions on enwiki
Task
According to conversation on WMF Slack ([internal WMF link](https://wikimedia.slack.com/archives/C01C4BJ657V/p1786049151346869)), the enwiki community recently [changed](https://en.wikipedia.org/w/index.php?title=MediaWiki:GrowthExperimentsSuggestedEdits.json&diff=prev&oldid=1368026053) the minimum required score. However, the task pool was not refreshed: ``` mysql:research@dbstore1009.eqiad.wmnet [enwiki]> select sum(jt.score >= 0.7), count(*) from growthexperiments_link_recommendations r, JSON_TABLE(r.gelr_data, '$.links[*]' COLUMNS (score DOUBLE PATH '$.score')) AS jt; +----------------------+----------+ | sum(jt.score >= 0.7) | count(*) | +----------------------+----------+ | 2719146 | 4336334 | +----------------------+----------+ 1 row in set (15.150 sec) mysql:research@dbstore1009.eqiad.wmnet [enwiki]> select 2719146 / 4336334 * 100; +-------------------------+ | 2719146 / 4336334 * 100 | +-------------------------+ | 62.7061 | +-------------------------+ 1 row in set (0.000 sec) mysql:research@dbstore1009.eqiad.wmnet [enwiki]> ``` and it only has ~63% of suggestions that actually meet the requirements. Let's revalidate all of them via `revalidateLinkRecommendations.php`.
T434259: Introduce case sensitivity to Add-a-Link
Task
The machine learning model being used in #add-link-structured-task often makes erroneous suggestions that appear to reflect a lack of knowledge of case sensitivity. For example, @Rich_Farmbrough [[ https://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AGrowth_Team_features#c-Rich_Farmbrough-20250903100700-Ongoing_problems_with_adding_inappropriate_links | reports ]] that [[ https://en.wikipedia.org/wiki/Listen_to_the_Music | Listen to the Music ]] (an album) has been suggested over the phrase "listen to the music". In another example, [[ https://en.wikipedia.org/wiki/Secondary_school | Secondary school ]] was suggested over the words in "Had his primary education at Nisuco Staff Children School Bacita and secondary education at Government Secondary School Bacita, Kwara State but obtained..." (something a newcomer [[ https://simple.wikipedia.org/w/index.php?title=Benjamin_Justice_Soghie&diff=prev&oldid=10484948 | subsequently did ]]). {F66092265} This task captures the work around training the machine learning model to make better suggestions in light of the signals case sensitivity provides. **Benefits**: * This could reduce the error rate of the model, particularly around instances of [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Linking#Names_in_names | partial name links ]], as in the second example above. (To frame it another way, a human seeing a phrase with the capitalization `xxxxxxx xx Xxxxxxxx Yyyyyyyyy Yyyyyy Xxxxxx` can probably figure out that suggesting a link over the Y-words is a bad idea because all four capitalized words probably form a single multi-word term. A properly trained machine learning model could hopefully do the same.) **Risks/concerns/challenges**: * Sometimes articles have bad capitalization, and case sensitivity could lead the model to misjudge these instances. In particular, articles that are underdeveloped and have poor grammar are disproportionally likely to appear in "Add a Link" and are also disproportionally likely to have bad capitalization. * Article titles almost always begin with capitalization, which introduces a challenge when compiling the data to train the model with. One possible solution is to use the Wikidata item label linked to the article rather than the article title itself, since Wikidata items aren't supposed to capitalize item labels unless they're proper nouns (e.g. the English Wikipedia article "House" has the Wikidata item label "[[ https://www.wikidata.org/wiki/Q3947 | house ]]"). However, some Wikidata item labels may be erroneously capitalized, introducing errors into the data. ---- //This task was originally located at T405185, which has since been usurped to focus specifically on named entity recognition. It was split off again following [[ https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#We_need_to_get_rid_of_the_%22suggested_links%22_tool | this discussion ]].//
T434255: Provide mechanism to exclude articles from having links to them suggested by Add-a-Link
Task
**User story:** As an experienced editor who has noticed that a particular article is erroneously being suggested by #add-link-structured-task to newcomers as a link, I want to prevent the model from suggesting it again, so that bad links are not added to the encyclopedia and so that newcomers who unwittingly add them won't have to be reverted. //Note: This is separate from the situation of wanting to exclude a particular article from having links added //from// there, which is handled by {{[[ https://en.wikipedia.org/wiki/Template:No_newcomer_task | No newcomer task ]]}}.// **Open questions:** What would the UX of this mechanism look like (would it sit in #mediawiki-extensions-communityconfiguration)? How would other editors monitor and adjust the list of excluded articles? Would excluding individual articles be sufficient, or would we also want a way to exclude categories? ---- //This task was inspired by [[ https://en.wikipedia.org/w/index.php?title=Wikipedia%3AVillage_pump_%28proposals%29&dtnewcommentssince=c-SSalgaonkar-WMF-20260806151500-Asilvering-20260806052300&dtinthread=1#c-Certes-20260806110100-BD2412-20260805155800 | this comment ]] from @Certes.// [[ https://www.mediawiki.org/wiki/Talk:Growth#c-Kerry_Raymond-20251031232000-Remove_links_to_tree_planting_as_a_suggestion | Similar requests have been shared on the Growth Team's talk page ]].
T434234: Measure if AQS queries are sufficiently quick for usage in ImpactModule
Task
The #growth-team intends to build the #mediawiki-extensions-impactmodule using primarily AQS queries (see the review at T433352). To ensure that is indeed viable, we should measure how long all relevant queries take to respond (warning: this might change when T433983 finishes, but not substantially). This applies even with caching – whenever the cache is cold, the AQS queries would be made on the fly. Within this task, we should write a maintenance script that downloads relevant data from the AQS, and checks how long it takes. Then, we should decide if such a delay is acceptable or whether we need to take some precautions to ensure the cache is not cold in most cases. Note we should run the measurement in production (in practice, the requests would be done within the DC rather than across half of the world).
T434232: Create a proof of concept metric client in ImpactModule
Task
Within {T433352}, we completed a list of metrics that can be included in the #mediawiki-extensions-impactmodule extension. Within this task, we should create a proof of concept metric client in the extension. This client would be: * capable of requesting individual metrics (primarily from AQS, but not exclusively), * responsible for caching the results, * returning the metrics to the caller. This task is intended as "where can we get within a couple of days". Specific changes will be filled as follow-ups as needed. Completing this task also means the decisions (listed as subtasks) will at least have all necessary information to progress.
T434222: Decide to what extent should non-AQS data lookups be allowed in ImpactModule
Task
Recording an open question from {T433352}. #growth-team engineers should agree on: In the new Impact module, should non-AQS data lookups be allowed? If so, to what extent? One of the benefits is to remove the internal DB caching layer, which is unnecessarily complicated. "Challenging" lookups should definitely be in AQS. But what puts us to the level of "challenging"? Would it be reasonable to read `user_editcount` from DB? CentralAuth's "global user editcount"? Number of Thanks received?
T434136: AQS - Add per wiki filtering to edits/v3/per_editor
Task
The [Get 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) AQS endpoint returns a timeseries of a user's summed global edit counts across all wikis. Impact Module needs the ability to filter this by a wiki, to show the users's edit count on that wiki. In T414020#11925837, @Ottomata suggested that the ability to filter the data by-project "could be added very easily". edits/v3/per_editor is backed by the mediawiki_history_reduced druid dataset. Druid should allow us to filter the sum by the project dimension. We would either need to change the existing API endpoint to add a new `project` or `wiki_id` parameter, or add a new endpoint that allows to filter. === Done is [] Analytics API has an endpoint that returns a timeseries of edit counts per editor for a specific wiki.
T434113: top_pages_per_editor returns implausible data for metawiki:Steward requests/Global permissions
Task
NOTE: This is relevant to #de1.3.2_impact_dashboard, owned by #growth-team, which intends to use this API. https://wikimedia.org/api/rest_v1/metrics/pageviews/v3/top_pages_per_editor/34722510/monthly/20260101/20260201 claims that: ```lang=json { "context": { "endpoint": "pageviews/v3/top_pages_per_editor", "user_central_id": 34722510, "granularity": "monthly", "start": "2026-01-01T00:00:00.000Z", "end": "2026-02-01T00:00:00.000Z" }, "items": [ { "timestamp": "2026-01-01T00:00:00.000Z", "top_k": 10, "rank_items": [ { "rank": 1, "wiki_id": "metawiki", "page_id": 135805, "view_count": 75149 }, // [...] ] } ] } ``` I interpret this as "in January 2026, metawiki's page 135805 was visited 75149 times". However, I was unable to find this number when cross-checking with pageviews dataset itself. According to [the query](https://gerrit.wikimedia.org/r/plugins/gitiles/analytics/refinery/+/refs/heads/master/hql/pageview/pageview_per_editor_per_page_daily/load_pageview_per_editor_per_page_daily.hql), the pageviews are computed for the calendar month represented by the `timestamp` key. For this case, this should mean January 2026. ==== Pageviews tool I checked the [Pageviews tool](https://pageviews.wmcloud.org/?project=meta.wikimedia.org&platform=all-access&agent=user&redirects=1&start=2026-01-01&end=2026-01-31&pages=), which says: {F97274868} putting the number of January 2026 pageviews at Pageviews: 26,826 (significantly longer than the 75k figure given by the other tool). ==== `wmf.pageview_hourly` ``` spark-sql (default)> select sum(view_count) > from wmf.pageview_hourly > where year=2026 and month=1 > and project = 'meta.wikimedia' > and page_id = 135805 > and agent_type = 'user'; sum(view_count) 29051 Time taken: 84.412 seconds, Fetched 1 row(s) spark-sql (default)> ``` this puts the number of pageviews at 29051 (slightly higher than the Pageviews tool, but attributable to query looking for something slightly different). ==== Intermediary tables The `wmf_readership.pageview_per_editor_per_page_daily` and `wmf_readership.pageviews_top_pages_per_editor` intermediary tables have the wrong numbers: ``` spark-sql (default)> > > > > select sum(view_count) from wmf_readership.pageview_per_editor_per_page_daily > where user_central_id = 34722510 > and wiki_id = 'metawiki' > and page_id = 135805 > and day >= DATE '2026-01-01' and day < DATE '2026-02-01' > ; sum(view_count) 75149 Time taken: 33.627 seconds, Fetched 1 row(s) spark-sql (default)> select view_count from wmf_readership.pageviews_top_pages_per_editor > where user_central_id = 34722510 > and wiki_id = 'metawiki' > and page_id = 135805 > and granularity = 'monthly' > and dt = TIMESTAMP '2026-01-01 00:00:00.000' > ; view_count 75149 Time taken: 10.656 seconds, Fetched 1 row(s) spark-sql (default)> ``` What is the cause for the discrepancy? Are we double-counting certain pageviews? Or are pageviews defined differently in this specific endpoint?
T434111: Use lock manager service in GrowthExperiments
Task
See {T161749} and {T366938}. We are trying to switch off using databases as lock management system.
T434067: Wikimedia\NormalizedException\NormalizedException: There was a problem during the HTTP request: 500 Internal Server Error
Task
==== Error ==== * service.version: 1.47.0-wmf.13 * timestamp: 2026-08-05T11:51:22.399Z * labels.phpversion: `8.3.33` * trace.id: `dc4cf455-2551-4087-a1ff-a2665b457100` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2026-08-04T11:51:22.399Z',to:'2026-08-05T12:21:26.181Z'))&_a=(query:(query_string:(query:'reqId:%22dc4cf455-2551-4087-a1ff-a2665b457100%22'))) | Find trace.id in Logstash ]] ```name=labels.normalized_message,lines=10 [{reqId}] {exception_url} Wikimedia\NormalizedException\NormalizedException: There was a problem during the HTTP request: {parameter1} {parameter2} ``` | Frame | Location | Call | -- | -- | -- | from | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.47.0-wmf.13/includes/Util.php#191 | /srv/mediawiki/php-1.47.0-wmf.13/extensions/GrowthExperiments/includes/Util.php(191) ]] | | #0 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.47.0-wmf.13/includes/HomepageHooks.php#383 | /srv/mediawiki/php-1.47.0-wmf.13/extensions/GrowthExperiments/includes/HomepageHooks.php(383) ]] | GrowthExperiments\Util::logStatus(MediaWiki\Status\Status) | #1 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.13/includes/HookContainer/HookContainer.php#127 | /srv/mediawiki/php-1.47.0-wmf.13/includes/HookContainer/HookContainer.php(127) ]] | GrowthExperiments\HomepageHooks->onBeforePageDisplay(MediaWiki\Output\OutputPage, MediaWiki\Minerva\Skins\SkinMinerva) | #2 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.13/includes/HookContainer/HookRunner.php#1031 | /srv/mediawiki/php-1.47.0-wmf.13/includes/HookContainer/HookRunner.php(1031) ]] | MediaWiki\HookContainer\HookContainer->run(string, array, array) | #3 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.13/includes/Output/OutputPage.php#3094 | /srv/mediawiki/php-1.47.0-wmf.13/includes/Output/OutputPage.php(3094) ]] | MediaWiki\HookContainer\HookRunner->onBeforePageDisplay(MediaWiki\Output\OutputPage, MediaWiki\Minerva\Skins\SkinMinerva) | #4 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.13/includes/Actions/ActionEntryPoint.php#162 | /srv/mediawiki/php-1.47.0-wmf.13/includes/Actions/ActionEntryPoint.php(162) ]] | MediaWiki\Output\OutputPage->output(bool) | #5 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.13/includes/MediaWikiEntryPoint.php#180 | /srv/mediawiki/php-1.47.0-wmf.13/includes/MediaWikiEntryPoint.php(180) ]] | MediaWiki\Actions\ActionEntryPoint->execute() | #6 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.13/index.php#44 | /srv/mediawiki/php-1.47.0-wmf.13/index.php(44) ]] | MediaWiki\MediaWikiEntryPoint->run() | #7 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+blame/refs/heads/master/w/index.php#3 | /srv/mediawiki/w/index.php(3) ]] | require(string) | #8 | {main} | ==== Notes ==== - Since at least 1.47.0-wmf.1 - Related to T415912 (504 vs 500). Merge as appropriate - Volume growing over time. Last 90 days: {F97259108 width=600}
T434036: Early communications: gather community feedback on Home plans and designs
Task
== User story: == As the Growth team, we want to incorporate community feedback early in the planning process because we'll build a better product together, one that more accurately reflects community needs. [[ https://docs.google.com/document/d/1gLduUm-nkn0iUUHHsVBTtDBqwAQSS4ubgusb3rdmUIM/edit?tab=t.0 | Home communications plan ]] == Overview == The Wikimedia Foundation is developing a unified [[ https://www.mediawiki.org/wiki/Home | Home ]] to help Wikimedians at every stage, from curious readers to experienced editors and moderators, find meaningful ways to participate and grow. It builds on the [[ https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Newcomer_homepage | Newcomer Homepage ]] and the [[ https://www.mediawiki.org/wiki/Moderator_Tools/Dashboard | Moderator Tools Dashboard ]]. This task tracks early communications work to gather community feedback on Home plans and designs. Over 2026-2027 Q1, we will ask communities for feedback on the different explorations of this project, starting with the designs around onboarding simplification, dashboard layout, and navigation. The goal is to gather feedback quickly, in a more lightweight way than we have in the past, with feedback collected per audience (newcomers and the users who support them; moderators and curious experienced users) so that input about specific workflows comes from the people who know those workflows. - High-level project plans: https://www.mediawiki.org/wiki/Home - Early designs available for discussion: {T426702} == First steps == The first step is to finalize, share, and execute the first steps of the Contributors Home communication plan: [] Finalize the [[ https://docs.google.com/document/d/1gLduUm-nkn0iUUHHsVBTtDBqwAQSS4ubgusb3rdmUIM/edit?tab=t.0 | Home communications plan ]] and agree on dates with the product manager [] Consult with ambassadors on the designs for early feedback [] Identify communities to work with [] Share the communication plan with the Ambassadors [] Start to gather feedback
T434015: Change "Home" label to "Main page" in the Minerva main menu
Task
=== Background In the Minerva (mobile web) main menu, the link to the wiki's main page is labeled **Home** for logged-out users. For logged-in users who are opted in to the Newcomer Homepage, that label changes to **Main page**. #### Current menu on mobile: Logged out: {F97169985} Logged in user (with Homepage enabled): {F97169984} On desktop, however, the default menu label is always **Main page**: #### Current menu on desktop: Logged out: {F97170283} Logged in: {F97170295} We should consider changing the menu to use the same terminology (Main page) across all platforms and skins. Reasoning: - We shouldn't use different terms for the same page. - Using "Home" creates a terminology mismatch: as soon as someone follows the link, they see "Main page" in both the URL and the page title (which displays on desktop). //While "Main page" is wiki-specific terminology, it is deeply embedded throughout MediaWiki, and moving away from it isn't realistic.// - As we move toward creating a central [[ https://www.mediawiki.org/wiki/Home | Home ]] for users, we should stop referring to the Main page as "Home" on mobile. === Proposed solution Change the main menu label for the link to the wiki's main page from "Home" to "Main page", so that: - The label matches the actual page title and URL that users land on. - The label no longer changes between logged-out and logged-in (Newcomer Homepage opted-in) states. - The label no longer differs between desktop and mobile. === Acceptance criteria Given I'm viewing the main menu on while on mobile (Minerva skin), When I am logged out or logged in, Then the link to the mainpage is labeled "Main page" and the icon matches the current logged in "news" icon [ ] Translations/message keys for the menu label are updated accordingly.
T433983: Make the AQS endpoints more usable for the ImpactModule extension
Task
== Background As part of #de1.3.2_impact_dashboard, the #growth-team intends to create an AQS-based version of the Impact module ([see example](http://cs.wikipedia.org/wiki/Special:Impact/Martin%20Urbanec?uselang=en)). The main advantage here is avoiding the need to maintain a fairly complex infrastructure for analytics queries within MediaWiki. The Impact module is available on individual wikis; visiting the Impact module on enwiki should give enwiki-specific data (while a dewiki visit would show data about dewiki, and so on). We have already reviewed the list of metrics we want to include in the Impact module with what is offered via Analytics Query Service. Details are available at {T433352} (past conversation with #data-platform is available in T414020). Based on our review, we have a couple of questions and couple of requests that would hopefully allow us to move forward. == Requests Filling this within one task to make orienting easier (and since I'm not sure how to break down the work effectively). Let me know if I should be fill separate/specific subtasks for some of this! === Add per-project filtering to several endpoints Given the ImpactModule should display wiki-specific data, we need to be able to filter the data on per-wiki basis. This includes the following endpoints: * [Get 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): in T414020#11925837, @Ottomata already confirmed the ability to filter the data by-project "could be added very easily" - T434136 * [Get number of page views for an editor's edited pages](https://doc.wikimedia.org/generated-data-platform/aqs/analytics-api/reference/page-views.html#get-number-of-page-views-for-an-editor-s-edited-pages) * [List most-viewed pages for an editor's edited pages](https://doc.wikimedia.org/generated-data-platform/aqs/analytics-api/reference/page-views.html#list-most-viewed-pages-for-an-editor-s-edited-pages) === Make the most-viewed pages for editors' edited pages available for last floating month As of now, the //[List most-viewed pages for an editor's edited pages](https://doc.wikimedia.org/generated-data-platform/aqs/analytics-api/reference/page-views.html#list-most-viewed-pages-for-an-editor-s-edited-pages)// endpoint only allows downloading the data after a full month has passed since the user's first edit. This is practically unusable for ImpactModule's purposes – we want to motivate newcomers by telling them "hey, your edits were viewed by many people". If we only have this information after a month, the newcomer is long gone, and the motivation wouldn't work. To make the information usable, we would need to have the data available for the last floating month (last 30 days, regardless of calendar month boundaries). Getting `daily` granularity (as previously discussed in T414020#11925837) wouldn't help, because the ImpactModule should display data for last N days (to be more meaningful; currently, N=60, but we are open to changing that), and merging daily granularity top-k most viewed articles into a floating monthly top-k most viewed articles is not possible (to order the articles, we would need to know how many times they were viewed on days on which they were not among a user's most viewed articles). === Add Thanks data into the AQS It would be nice if AQS included data about the number of thanks a specific user gave/received during a given period. Note that the example linked above only displays received thanks, but a similar moderator-oriented module will also include //sent// thanks.
T433912: Revise Tone: batch create suggestions for "forgotten articles"
Task
==== User story ==== As a **newcomer** looking for an easy way to start editing, I want Revise Tone suggestions to exist on older, less-maintained articles, so I can find newcomer-friendly tasks on the articles that need the most work. As a **member of the Growth team**, I want to batch generate Revise Tone suggestions for articles that haven't been edited in X months, so that the pool of suggested edits covers the long tail of forgotten articles instead of only recently edited ones. ==== Background ==== New Revise Tone suggestions are currently generated when an article is edited. This means we are missing the long tail of "forgotten" articles that haven't been edited in a long time. These are often the most newcomer-friendly articles, because they need the most work. ==== Details ==== Streamline a process where we can batch generate Revise Tone suggestions for a subset of articles that haven't been edited in X months. ==== Open questions ==== - What should the threshold be for "forgotten" (X months since last edit)? - How should the batch job be run: one-time backfill, recurring job, or on-demand? - Which wikis should this run on initially? ==== Acceptance criteria ==== - [ ] A repeatable process exists to batch generate Revise Tone suggestions for articles not edited in X months - [ ] Generated suggestions appear for newcomers the same way edit-triggered suggestions do NOTE: we are considering work on {T432765} to be higher priority, but this is a task we might want to return to as a way to generate more Revise Tone suggestions, but also because it helps surface some of the most neglected articles on the wikis.
T433845: [a11y] CreateAccount form - Elements should not have tabindex greater than zero
Task
//Note:// - the issue `Elements should not have tabindex greater than zero` was listed by axe DevTools as "Serious". - the issue is present on both - desktop and mobile **Steps:** - On CreateAccount page, use tab to navigate through the form text fields - You notice that all text fields (Username, Password, Confirm password, Email address) will be skipped Running axe DevTools check flags 5 occurrences of `Elements should not have tabindex greater than zero` error {F97018509} ``` Element Location: #wpName2 <input id="wpName2" name="wpName" size="20" placeholder="Enter your username" class="mw-createacct-username cdx-text-input__input" tabindex="1" required="" autocomplete="username"> ```
T433784: Experiment: Welcome Notification (DE1.3.1)
Task
**INSTRUMENTATION SPECIFICATION**: TBD ### Testable hypothesis If we suppress the Welcome notification for new account holders, it will **increase constructive activation** because the notification fires at the moment of account creation, when newcomers are trying to complete the task that brought them to the wiki. An unread alert at that moment may pull attention away from that first task without providing actionable guidance, and the notification's benefit to newcomers has not been empirically validated. (NOTE) This is intentionally framed as a two-sided question: the experiment is equally designed to detect whether the notification is *helping* (holdback decreases constructive activation) or *harming* (holdback increases it). ### Experiment details #### Overview - **Experiment Name**: Welcome Notification Holdback Experiment - **Tracking Key**: `welcome-notification-holdback` - **Risk Level**: Tier 3: Low Risk (only standard, already-instrumented events and metrics; no new sensitive data or experiment-wide contextual attributes planned) #### Traffic - **Assign Variation by Attribute**: MW User ID - **Traffic Percent**: 100% (maximum allowed traffic for MW User ID assignment) - **Variations** - Control (`control`): New account holders receive the current Welcome notification (Echo `welcome` notification) upon account creation, as they do today. - Holdback (`no-welcome-notification`): The Welcome notification is suppressed for new account holders. No other notifications or onboarding surfaces are changed. - **Targeting** - MediaWiki Database Code in: - Growth team pilot wikis: arwiki, enwiki, eswiki, frwiki - **Expected start date**: TBD ## Metrics - **Goal metrics** - Constructive activation - **Secondary metrics** - Logged-in reader retention - **Guardrail metrics** - Second week editor retention ------ **Needs to be updated / added to this task:** # Instrumentation spec # Expected start date # GrowthBook links for all three metrics Open questions: - Is this technically feasible? (A/B testing with notifications has proven challenging in the past) - Is this something we can experiment with as a separate experiment, or should we attempt to bundle this into the broader Account Set up experiment? {T432126}
T433783: Remove the benefits block from Special:CreateAccount
Task
== User story: == As a newcomer creating my first account, I want the account creation form to be simple and free of distractions, so that I can focus on the one thing I came to do: complete my registration. In other words: remove the benefits block (`mw-createacct-benefits-container`) from Special:CreateAccount **Parent epic: ** {T429029} == Background == The benefits block (the panel showing project statistics alongside the account creation form) was hidden as part of [[ https://www.mediawiki.org/wiki/Contributors/Account_Creation_Experiments | Account Creation Experiments ]] on mobile (as part of the 1.8.3). [[ https://www.mediawiki.org/wiki/Contributors/Account_Creation_Experiments#V2_Test_-_UX_Improvements_&_Username_Summary_(T415972) | Results showed that simplifying the form improved registration completion considerably ]]. {F96827907} We then ran a desktop experiment (WE1.8 FY25/26) to confirm "Benefits Block" removal is safe there as well ({T430785}, results: {T433291}). == Task == Remove the benefits block and all supporting code: - Remove the benefits block rendering from Special:CreateAccount on all platforms and skins - Remove the components, templates, styles, and i18n messages used only by the benefits block - Remove any configuration flags / experiment instrumentation specific to the benefits block - Remove or update any tests that cover the benefits block - Check for and remove dead references (hooks, feature flags, docs) left behind == Acceptance criteria == - [ ] Special:CreateAccount renders without the benefits block on desktop and mobile, across supported skins - [ ] No benefits-block code, styles, messages, or config remain in the codebase - [ ] Account creation works end to end
T433653: suggestedLink should ignore quotations and italics
Task
**Feature summary**: `suggestedLink` suggestions should ignore content within quotation marks, and italics. **Use case(s)**: I believe we generally don't want to propose links within book-titles and similar, nor within direct quotations. * E.g. Undesired link example in a PDF-title: https://www.mediawiki.org/wiki/Talk:VisualEditor/Suggestion_Mode/Feedback#suggestedLink_on_Spamming_at_enwiki * The system suggested linking to "Internet Security" within the last sentence (in a PDF-title) of https://en.wikipedia.org/wiki/Spamming#Email * E.g. Enwiki MoS: https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Linking#Linking_quotations * "//Be conservative when linking within quotations; link only to targets that correspond to the meaning clearly intended by the quote's author. Where possible, link from text outside of the quotation instead – either before it or soon after.//" **Benefits**: Reduce the quantity of edge-cases where an edit might be inappropriate.
T433551: Ship the post-publish bottom sheet for temp accounts to all wikis
Task
== Background == Experiment WE1.8.6 "Post-Publish Bottom Sheet for Temp Accounts" (T429110) simplified the post-edit experience for new temporary account holders. Instead of several competing calls to action plus a welcome notification arriving at the same moment, the treatment showed a single streamlined dialog confirming the edit was published and highlighting the benefits of creating an account, with copy drawn from interviews with newcomers who had previously edited via temporary or IP accounts. The experiment ran Jul 20 – Jul 29, 2026 (10 days) on frwiki, arwiki, eswiki, and enwiki (50% of eligible traffic, split 50/50; control n=2,830, treatment n=2,841). **Results:** - Permanent account creation rate: 3.66% treatment vs. 1.94% control (+87% relative, 99.8% chance of winning). The 95% credible interval for the relative change is [26.8%, 147%], so even the worst case within the interval is a lift of at least 26.8%. - More experiment details to be shared as part of {T433549}. Based on these results, the treatment should become the default experience. == Acceptance criteria == [] The post-publish bottom sheet (WE1.8.6 treatment) is the default post-edit experience for new temporary account holders on all wikis where temporary accounts are enabled [] The welcome notification is suppressed at the post-edit moment for temporary account holders, matching the treatment [] Experiment enrollment and configuration for WE1.8.6 are removed.
T433373: Integrate the ImpactModule extension with Translatewiki.net
Task
The `mediawiki/extensions/ImpactModule` extension should have its messages localised via Translatewiki.net, similarly to all other extensions. This task will only be actionable once the extension is actually created (at that point, we should tag this task with #translatewiki.net as well).
T433372: Create initial documentation for the ImpactModule extension at MediaWiki.org
Task
In this task, a basic documentation page should be written fro the ImpactModule extension at MediaWiki.org. https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment offers a preloading form that would be useful for this purpose. ==== Acceptance Criteria [ ] A MediaWiki.org page `Extension:ImpactModule` exist and explains the purpose of the extension
T433354: Decide on a mechanism to communicate with Wikimedia Analytics API from a MW extension
Task
As part of #de1.3.2_impact_dashboard, we will need to download data from the Wikimedia Analytics API from an extension, similar to what #pageviewinfo does. However, our need for data will be broader than just pageview info. Within this task, we should experiment with various options to do that and decide on the one we will use going forward. Options to consider (list is not guaranteed to be complete): 1. **Direct CURL from the ImpactModule extension**: We can communicate with the API directly, self-implementing the interface and "PHP objects to JSON" conversion. This is what #pageviewinfo does currently. 2. **Centralise the logic somewhere(TM)**: We can designate a central extension that would communicate with Wikimedia Analytics API and that would then be used both by #pageviewinfo and by the future ImpactModule extension. ==== Acceptance Criteria [ ] Pros and cons were considered of the options in the description [ ] A decision was made on what option is best
T433243: Vanishing a mentor should automatically remove them from mentorship
Task
Similar to {T433242}. If a mentor uses `Special:GlobalVanishRequest` to vanish from Wikipedia, and their request is approved, they should be automatically removed from mentorship, given that account becomes permanently unusable (see [vanishing documentation](https://meta.wikimedia.org/wiki/Account_vanishing/en)).
T433242: cleanMentorList is unable to remove locked mentors from mentorship
Task
See this from dewiki (script execution happened for T431804): ``` [urbanecm@deploy1003 ~]$ mwscript-k8s -f GrowthExperiments:cleanMentorList.php -- --wiki=dewiki ⏳ Starting GrowthExperiments:cleanMentorList.php on Kubernetes as job mw-script.eqiad.i98y0pye ... ⏳ Waiting for the container to start... 🚀 Job is running. 📜 Streaming logs: Renamed user 2e233d074791c0e6ac153f38829154f0 {{GENDER:Renamed user 2e233d074791c0e6ac153f38829154f0|is}} currently locked. {{GENDER:Renamed user 2e233d074791c0e6ac153f38829154f0|Their}} mentor status cannot be modified while locked.[urbanecm@deploy1003 ~]$ ``` cleanMentorList should definitely be able to remove mentors who are locked. Not sure what part stopped this from happening. {T433243} is a similar task that would remove mentors automatically on vanishing. It is a distinct task from this one.
T433031: Revise Tone Structured Task: Community Configuration for setting "Confidence" threshold
Task
As a Wikipedia admin, I want Revise Tone's confidence threshold to be configurable via Community Configuration, so that my community can tune the tradeoff between suggestion quality and quantity to meet our wiki's needs. #### Background The Revise Tone task already has basic configuration available via: `Special:CommunityConfiguration/GrowthSuggestedEdits`. This task adds a configurable confidence threshold so admins can raise or lower the default value (`0.79`). #### Acceptance Criteria **1. Section visibility** Given I am on a wiki where Revise Tone is available, When I visit `Special:CommunityConfiguration/GrowthSuggestedEdits`, Then I see a section labeled **Revise Tone**. Given I am on a wiki where Revise Tone is //not// available, When I visit `Special:CommunityConfiguration/GrowthSuggestedEdits`, Then no Revise Tone section is shown. **2. Confidence threshold field** Within the **Revise Tone** section there is a text field labeled `Minimum required confidence score` that: - accepts only numeric values between 0 and 1 (same input logic as the existing `Minimum required link score` field) - is pre-populated with the current configured value, defaulting to `0.79` - has the help text: `Minimum confidence threshold for Revise Tone suggestions, expressed as a decimal between 0 and 1. A higher value means suggestions shown to the end user are more likely to be good quality, but fewer will be available. A lower value makes more suggestions available, but some may be lower quality.` **3. Validation** Given I enter an invalid value (e.g. `1.5`, `-0.2`, or non-numeric text), When I attempt to save, Then I see a validation error and the invalid value is not saved (matching `Minimum required link score` behavior). **4. Saving and applying** Given I save a valid new value, Then the change is stored via Community Configuration (including a corresponding entry in the configuration page's history), And the new threshold is applied to all Revise Tone task recommendations generated after the change.
T432924: Account setup: Browser test — define and implement happy path testing scenarios (DE1.3.1)
Task
== User story & summary As a Growth team member, I want automated browser test coverage of the happy paths through the new onboarding experience so that regressions are caught before release. == Background & research Parent task: {T430058} **Testing scenarios** - Complete all account set up questions - Partially complete account set up questions - Skip account set up - (More to be defined!) == Acceptance criteria - [] **Given** the **Testing scenarios** defined, **when** the browser tests run, **then** they pass and cover each defined scenario == QS Lead Support Needed YES! [[https://www.mediawiki.org/wiki/Growth/Team/QS_Lead_Support#When_to_Seek_for_QS_Support | (see criteria) ]]
T432923: Account setup: Remove extra noise on homepage (DE1.3.1)
Task
== User story & summary As a new account holder, I want a homepage with fewer competing calls to action so that my original intent is not postponed by stacked onboarding elements. == Background & research Parent task: {T430058} The current post-account-creation experience compensates for UI that should be self-explanatory. Competing CTAs: - welcome survey homepage modal - "welcome to your homepage overlay" - multi-step "About suggested edits" onboarding - pulsing blue "topic-picker" dot - email module == Design [[ https://www.figma.com/design/6VElpFGPXf9EAuClQbpPlA/T419358-Special-Homepage?node-id=2312-3537&p=f&t=hTROhDZIvglYXPHS-0 | Figma designs ]] //(confirm the relevant frames)// --- == Acceptance criteria - [] **Given** a newly created account, **when** they navigates to their Homepage for the first time , **then** the competing CTAs are removed
T432921: Account setup: Move homepage navigation banner to first article page visit after homepage (DE1.3.1)
Task
== User story & summary As a new account holder, I want to encounter the navigation banner on my first //article // page visit after the homepage (rather than stacked onto the homepage) so that the homepage carries less competing noise. == Background & research Parent task: {T430058}. There are many competing calls to action surfaced to a new account holder. The hope is to simplify the initial (critical!) post-account creation moments, and only provide guidance on navigation at a later stage. == Design [[ https://www.figma.com/design/6VElpFGPXf9EAuClQbpPlA/T419358-Special-Homepage?node-id=2312-3537&p=f&t=hTROhDZIvglYXPHS-0 | Figma designs ]] --- == Acceptance criteria - [] **Given** a new account holder is on the homepage, **when** the homepage renders, **then** the homepage navigation banner is not shown there - [] **Given** a new account holder leaves the homepage, **when** they visit their first article page after the homepage, **then** the navigation banner is shown - [] **Given** a new account holder is editing, **when** the editor is open, **then** the navigation banner is not shown - [] **Given** a new account holder is within a Suggested Edits flow (including a post-edit dialog after completing a Suggested Edit), **when** any page in that flow renders, **then** the navigation banner is not shown
T432920: Account setup: Screen 1 (welcome) + Screen 2 (account type) in account setup flow (DE1.3.1)
Task
== User story & summary As a new account holder, I want a focused account setup experience that personalizes my experience so that I can get a more personalized experience and see relevant suggestions. == Background & research Parent task: {T430058} This task covers the first part of the Account setup flow: the loading state, screen 1 (welcome) and screen 2 (account type). Screen 3 (interests) is covered by {T432811}. Account setup is presented as a dialog layered over the newcomer homepage rather than as a separate page, so that the destination is visible (blurred) behind the dialog from the first moment and dismissing setup lands the user on the newcomer homepage. == Design [[ https://www.figma.com/design/sIvFfvFgrw59lEjtJHlX62/T430418-account-setup--aka-welcome-survey-?node-id=517-2438&t=UvoERB8o6mYFOjY8-1 | Figma designs ]] {F98043361 width=480} {F98041380 width=960} [[ https://aminalhazwani.github.io/protowiki3/pr-preview/pr-4/no-distractions | Prototype ]]: Create a (fake) account from the Main Page or any article. {F98042319 size=thumb} Baby globe asset: https://commons.wikimedia.org/wiki/File:Wikipedia%27s_25th_birthday_mascot_-_Confetti_Baby_Globe.gif **Note on the GIF timing:** the animation is deliberately delayed (1 second) and plays/loops only once. Two reasons: it gives the dialog time to fully load, and it leaves room for the operating system's save-credentials prompt, which can appear immediately after account creation. Users need a moment to confirm or dismiss that prompt before anything animates underneath it. --- == Acceptance criteria Please refer also to [[ https://phabricator.wikimedia.org/T430058#12174389 | this comment ]] which outlines the whole flow for additional context. AC1 * Given I have just submitted the account creation form * When my account is created * Then I am taken to the newcomer homepage, with the homepage blurred (`backdrop-filter: blur(30px);`) and the account setup dialog displayed on top of it. on mobile the dialog is full height, on desktop we set an arbitrary height of 640px/size-4000 that we can refine as we implement and test this AC2 * Given the newcomer homepage has loaded but the account setup dialog is not ready yet * When I am waiting * Then I see the waiting screen (blurred background, codex progress indicator, and a "Did you know..." fact) until the dialog is ready AC3 * Given I was mid-edit when I started account creation * When I finish account creation * Then I am returned to the editor and NOT interrupted by account setup * AND my account creation reason is automatically logged as "Edit" **Screen 1: welcome** AC4 * Given the account setup dialog has opened * When I view screen 1 * Then I see "Welcome to Wikipedia, $Username!", the baby globe animation, a step indicator showing 1 of 3, a close button in the top left, and a "Personalize your Home" primary button AC5 * Given screen 1 has opened * When the animation plays * Then the GIF holds on its first frame for 1 second, loops once, and then rests back on the first frame AC6 * Given I am on screen 1 * When I tap the close button * Then the dialog is dismissed and I am on the newcomer homepage (with no interests stored * AND Suggested edits shows unfiltered random suggestions) AC7 * Given I am on screen 1 * When I tap "Personalize your Home" * Then I am taken to screen 2 **Screen 2: account type** AC8 * Given I have arrived on screen 2 * When I view the dialog * Then the step indicator shows 2 of 3, the close button has been replaced by a back button, and I see three options: "Reading and exploring", "Editing and contributing", and "A bit of both", plus a "Skip" quiet button AC9 * Given I am on screen 2 * When I select any one of the three options * Then I am taken immediately to screen 3 (no separate confirm step) * AND my selection is saved in a permanent user property so the Home view can be configured based on it AC10 * Given I am on screen 2 * When I tap "Skip" * Then I am taken to screen 3 with no account type stored AC11 * Given I am on screen 2 * When I tap the back button * Then I am returned to screen 1
T432812: Account setup: Integrate interest selector into suggested edits + propose tasks by interest (DE1.3.1)
Task
== User story & summary As a new account holder, I want suggested edits matched to my selected interests so that the tasks I see are relevant to me. == Background & research Parent task: {T430058} Depends on the interest selector task: {T432811} The interest selector built in T432811 stores a set of articles/topics. This task connects that stored set to the suggested edits module on the newcomer homepage and to the suggested edits carousel, and defines what newcomers see when they have no stored interests, when their interests return nothing, and when they return a single result. We should also refer back to {T433151} as we implement this with real data, so that we have a better understanding on how often the empty pool might happen. == Design [[ https://www.figma.com/design/sIvFfvFgrw59lEjtJHlX62/T430418-account-setup--aka-welcome-survey-?node-id=366-13679&t=UvoERB8o6mYFOjY8-1 | Figma specs ]] Full account setup flow, including every action that leads to the newcomer homepage: {F98049270 width=960} **Newcomer selected interests during account setup** Suggested edits on the newcomer homepage are drawn from those interests. The module counter reflects the size of the matched set ("1 of 4 suggestions"). The module's primary button stays "See all suggestions". {F98048619} **Newcomer has no stored interests (skipped account setup)** Skipping can happen by closing the welcome screen (X on 1/3), or tapping "Go to your Home" on 3/3 without selecting any interest. In all two cases the newcomer lands on the newcomer homepage and the suggested edits module shows the whole unfiltered pool with the counter reflecting the full pool ("1 of 1,174,550 suggestions"). The module's primary button changes from "See all suggestions" to "Select interests". {F98048843} **Stored interests return no suggestions** The module reuses the existing empty state copy: "No suggestions found" and "Select other interests or difficulty levels to find suggested edits." The primary button reads "Select interests". {F98049166} {F96393575} **Stored interests return exactly one suggestion** The single suggestion is shown as-is, with the counter reading "1 of 1 suggestions". The set is not padded with random suggestions. **Reaching the interests dialog** "Select interests" opens the same interest selector UI used in account setup screen 3 of 3, with any stored interests pre-filled as chips and their related articles listed below. For a newcomer with no stored interests, the dialog opens empty with random articles listed. The dialog also reports the size of the resulting set ("4 suggested edits found"). The dialog is also reachable from the "Interests" filter in the suggested edits carousel. {F98049481} {F98049512} **6. Reaching the carousel** Regardless of which label the primary button shows, the suggested edits carousel remains reachable by tapping the suggestion card itself, or the arrow in the "Suggested edits" module header. --- == Acceptance criteria **For newcomers with stored interests** AC1 * Given I selected interests during account setup * When I land on the newcomer homepage * Then the suggested edits module shows suggestions matched to my interests. AC2 * Given the suggested edits module is showing interest-matched suggestions * When I view the module * Then the primary button reads "See all suggestions" AC3 * Given I am in the suggested edits carousel * When I tap the "Interests" filter * Then the interest selector dialog opens with my stored interests pre-filled AC4 * Given I have changed my interests in the dialog * When I tap "Done" * Then the suggested edits set and its counter update to reflect the new interests **For newcomers with no stored interests** AC5 * Given I skipped account setup (closed the welcome screen, or went to Home without selecting an interest) * When I land on the newcomer homepage * Then the suggested edits module shows the full unfiltered pool of suggestions and the counter reflects the total pool size AC6 * Given the suggested edits module is showing the unfiltered pool * When I view the module * Then the primary button reads "Select interests" AC7 * Given the suggested edits module is showing the unfiltered pool * When I tap "Select interests" * Then the interest selector dialog opens with no interests selected and random articles listed **Edge cases** AC8 * Given my stored interests return no suggested edits * When I view the suggested edits module * Then I see "No suggestions found" and "Select other interests or difficulty levels to find suggested edits.", and the primary button reads "Select interests" AC9 * Given my stored interests return exactly one suggested edit * When I view the suggested edits module * Then that single suggestion is shown and the counter reads "1 of 1 suggestions", with no additional unmatched suggestions added AC10 * Given the suggested edits module is showing at least one suggestion, with or without stored interests * When I tap the suggestion card or the arrow in the module header * Then the suggested edits carousel opens
T432811: Account setup: Create interest selector and storage of interests (DE1.3.1)
Task
== User story & summary Create a Vue component that enables the selecting of articles as "interests" and shows related articles. This component will be used in three places: # In the new onboarding # as a replacement of the TopicSelector for suggested edits # in the new migrated SuggestedEdits module on the PersonalDashboard (this is created by moderator tools) Also, this is about defining the user option that will hold these interests. == Background & research https://www.mediawiki.org/wiki/Home Parent task: {T430058} NOTE: This is only about creating the Vue.js component, follow up integration work part of this task: {T432812} == Design [[ https://www.figma.com/design/sIvFfvFgrw59lEjtJHlX62/T430418-account-setup--aka-welcome-survey-?node-id=364-12430&t=UvoERB8o6mYFOjY8-1 | Figma designs ]] {F98051093 width=960} == Acceptance criteria # if the account creation process was initiated on a page other than an article page (Main Page also excluded even if it counts as a article page) we display random suggestions (pending decision on T433151) below a multiselectlookup. the "Go your Home" button is default quiet as long 3 interests are not picked. {F96123278} # if the account creation process was initiated on an article page, the system uses that page to suggests related interests. the "Go your Home" button is default quiet as long 3 interests are not picked. {F96123288} # people can add more then 3 interests, but once they add 10 interests we should a confirmation message under the multiselect lookup. additional interests are not to reload the 'Related articles' and are not considered while creating the pool of suggested edits. {F96644344} ==== QS Lead Support Needed Yes, this is the fundamental UI that needs to be tested for the associated epic.
T432810: Account setup: Aggregate stats — Grafana (DE1.3.1)
Task
== User story & summary As a Growth team member, I want aggregate statistics for Account Setup == Background & research Part of epic DE1.3.1 Early onboarding (T430058). - Related: {T432809} - **[[ https://docs.google.com/spreadsheets/d/1Noy5RMQQPdXoQFcME8A5lQos9AXkBxlV6C7io1749eA/edit?gid=0#gid=0 | Instrumentation Specification ]]** == Acceptance criteria * time users take on Special:WelcomeSurvey (and later Special:AccountSetup) * completion of questions on welcome survey (and first two answers) * skip rate of welcome survey * record wiki (specific name of each language wiki: example: enwiki, eswiki, etc.) and platform labels (mobile vs. desktop)
T432809: Experiment: Account setup: Instrumentation + A/A test (DE1.3.1)
Task
**[[ https://docs.google.com/spreadsheets/d/1Noy5RMQQPdXoQFcME8A5lQos9AXkBxlV6C7io1749eA/edit?gid=0#gid=0 | INSTRUMENTATION SPECIFICATION ]]** == User story & summary As a Growth team member, I want instrumentation in place and validated via an A/A test so that we can reliably measure the DE1.3.1 experiment before the A/B test begins. == Background **Parent task:** {T430058} **Experiment details:** {T432126} **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. == Details **Events/interactions to instrument:** - Welcome Survey / Account Setup started (at least one answer completed) - Welcome Survey / Account Setup completed (all questions completed) - Proportion of accounts with email addresses - Homepage impression **Which schema(s)/stream(s) to use:** TBD **This A/A test should validate:** - Instrumentation is working as expected. - There are no SRM between groups. (Although this might not be verifiable until an A/B test is started) ### Testable hypothesis If we run an A/A test with identical experiences in both groups, it will show no significant differences between groups because any observed difference would indicate a problem with instrumentation or group assignment (SRM). ### Experiment details #### Overview - **Experiment Name**: Account setup A/A test (DE1.3.1) - **Tracking Key**: `TBD` - **Risk Level**: Low risk #### Traffic - **Assign Variation by Attribute**: MW User ID - **Traffic Percent**: 100% - **Variations**: - A1 (`control`): default post-account-creation experience - A2 (`treatment`): identical to control (A/A test — no experience differences between groups) - **Targeting** - MediaWiki Database Code in: - arwiki, enwiki - **Expected start date**: TBD ## Metrics - **Goal metrics**: - Second week (editor) retention => {T431016} - For REx: internal referrer rate => {T434837} - **Secondary metrics**: - Constructive Activation => {T433322} - Welcome Survey / Account Setup started - Welcome Survey / Account Setup completed - Proportion of accounts with email addresses - **Guardrail metrics**: - Homepage impression - [[ 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}
T432765: Revise Tone: populate suggestions for new predicted topics
Task
####User story & summary: As a editor on Wikipedia, I want to review Revise Tone suggestions related to more topics so that I can improve article neutrality across the wikis and have plenty of tasks to work on. ####Background & research: This task is important because enwiki has completed all Revise Tone suggestions, and ideally we have enough tasks to support newer editors. ####Questions: - Are there other viable ways to expand the task pool that we should consider? - Work with Machine Learning to decide if/how we should expand the [[ https://docs.google.com/spreadsheets/d/1JOYu7fbBsqRGD-uTcXKR82F4LI51UKHrKzrigd3ClWA/edit?gid=0#gid=0 | criteria for "Articles to feed the model"]]. Based on the [[ https://www.mediawiki.org/wiki/ORES/Articletopic | ORES article topics ]], here's a very rough, intuition-based ranking of which topic areas might be more likely to contain opportunities for tone or neutrality improvements. //This is not based on empirical data and should be treated as a hypothesis rather than a conclusion. It is not intended to suggest that articles in any particular topic are inherently more biased or less encyclopedic than others.// | Likelihood of non-neutral writing | Topics | Why | | --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Very High** | Biography, Politics and government, Philosophy and religion, History, Military and warfare | These frequently involve contentious subjects, ideological viewpoints, living people, or historical interpretation. Articles often require careful attribution and neutral framing. | | **High** | Business and economics, Society, Education, Media (Books, Films, Television, Music, Video games, Entertainment, Software), Internet culture, Sports | These topics often attract fan-like language, promotional wording, recentism, or subjective evaluations. Articles about companies, schools, athletes, and entertainment are common targets for promotional editing. | | **Moderate** | Visual arts, Architecture, Fashion, Performing arts, Literature, Food and drink, Transportation | These can include subjective descriptions ("iconic," "beautiful," "renowned") but are generally less controversial than politics or biographies. | | **Lower** | Biology, Chemistry, Mathematics, Physics, Earth and environment, Computing, Engineering, Libraries and information, Space, Technology | Scientific and technical topics tend to be more factual and are often written in a more objective style, although articles about emerging technologies or companies can still contain promotional language. | | **Lowest** | Geography, regional geography topics, species, physical geography | These articles are typically descriptive and fact-based. While they can contain local bias or nationalistic framing, they generally present fewer neutrality issues. | - Should we manually review a small sample of new suggestions? ####Acceptance Criteria: TBD (based on open questions) Given [preconditions] When [user action] Then [outcome resulting from actions taken in the when clause] All tasks should also meet the Growth Team’s task completion definition.
T432668: Design: Pilot wiki release of Home (MVP to replace Newcomer Homepage)
Task
#### Context This task continues design work from {T426702}, which explored Dashboard layout paradigms, onboarding simplification, and navigation, and {T420862} before it. We are now moving from exploration to definition: this task covers the final designs and specs for the **pilot wiki release of Home**. The pilot will be a minimum viable product (MVP) that can replace the existing Newcomer Homepage on pilot wikis. For this release we will be aiming to improve second-week retention. https://www.mediawiki.org/wiki/Contributors/Strategy #### Task Objective Produce final mobile and desktop designs and specs detailing the initial pilot release of Home. The MVP must: * Be capable of fully replacing the existing Newcomer Homepage for new accounts on pilot wikis * Be mobile-first: all core flows optimized for mobile, with desktop parity ##### 1. MVP module scope Final designs and specs for the following modules: * **Suggested Edits** * **Mentorship** * **Impact** * **Review Changes** — conditionally surfaced only when a user meets defined logic (> x edits; threshold TBD with Product/Data). Designs should specify: * The default state (module hidden or teased?) for users below the threshold * NOT NEEDED: How the module appears/is introduced once the threshold is met (this will be owned by Mod Tools as part of their Review Changes improvements). ##### 2. Onboarding * Define the post-account-creation flow. * If users skip the onboarding flow, how do we display suggestions. * If users sign up primarily to "Read", what appears as part of this MVP? We may want to plan for a pilot release that doesn't have any reading suggestions, but ideally we also have a plan for a very simple "Reading Suggestions" list that could be based on interests and highlighted mainpage articles. ##### 3. Specs For each module and flow, designs should include: * Mobile and desktop layouts * Module states (empty, loading, populated, error) where applicable * Conditional display logic (e.g. Review Changes edit threshold) * Information sufficient for engineering handoff #### Acceptance Criteria * [ ] Final mobile designs for the MVP of Home (Suggested Edits, Mentorship, Impact, Review Changes) * [ ] Final desktop designs for the MVP * [ ] Specs documenting module states, conditional logic, and post-account-creation landing flow * [ ] Designs reviewed with @KStoller-WMF, @Michael and ready for implementation on pilot wikis
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
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 ]]. - [ ] Design should match the 'codex-ification' version at T433021#12219434 ([[ https://www.figma.com/design/KJUU0vNeKwPhVd9K05qpCr/T419358-Home?node-id=387-29733&t=GBPvBf3vDb5lgZ1c-1 | figma ]])
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 ]].
T432031: [Epic] DE1.3.9 Migrate select Special:Homepage Modules to PersonalDashboard
Task
####Background This epic captures Moderator Tools + Growth Teams' journey in consuming the [[ https://www.mediawiki.org/wiki/Extension:PersonalDashboard#Development | PersonalDashboard ]] by doing some minimal module migration of Modules found on Special:Homepage and preparing them for registration on PersonalDashboard. It is captured under DE 1.3.X under the following hypothesis to track the efforts related to this work: > If we migrate Suggested Edits, Mentorship, and Impact modules from the Newcomer Homepage to the Personal Dashboard, we will validate the migration process, achieve a MVP for the Dashboard as the provider of the primary newcomer experience, and establish the foundation needed for future Dashboard modules to increase 2-week editor retention. The work will be driven from the Moderator Tools Team side and Growth will give product feedback and code review in support. Docs on how to register modules on PersonalDashboard: https://gerrit.wikimedia.org/g/mediawiki/extensions/PersonalDashboard/%2B/HEAD/docs/modules.md ####Acceptance Criteria [] Mentorship PD Module is registered in the GrowthExperiments extension [] Suggested Edits PD Module is registered in the GrowthExperiments extension [] Impact PD Module is registered in the GrowthExperiments extension [] "Home" moduleGroup is registered. - whether in GrowthExperiments or PersonalDashboard is TBD [] All modules render properly in Patchdemo via PersonalDashboard with MVP functionality as defined in subtask. [] All modules render properly in Beta via PersonalDashboard with MVP functionality as defined in subtask (experience may be gated behind query params/cookies/etc). ####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.):
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.
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.
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
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.
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 | 2026-07-30 | | 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
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}
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: [EPIC] Account Setup (DE1.3.1 - early onboarding)
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. #####DE1.3.1 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. #####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 #####Designs [[ https://www.figma.com/design/sIvFfvFgrw59lEjtJHlX62/T430418-account-setup--aka-welcome-survey-?node-id=320-11442&t=RZCi5lpTihqFuBAs-1 | Figma file ]] | [[ https://phabricator.wikimedia.org/T430058#12174389 | Phab comment below ]] {F96645470 width=960} #####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 ]].
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 ####Example questions: - How many users who see the Email module actually click through or confirm their email via this CTA? //This data will help us determine if we need to port a similar module to the new Home view, or if we should rely on other mechanisms for encouraging email validation. (Related: 4.3.4 hypothesis) // - How many wikis are using the Community Updates module regularly? //This data will help us determine if we need to port a similar module to the new Home view ASAP, or if we can wait for the Connections team to decide on the long-term plan for surfacing events. // ####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.
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.
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.
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
Blockers: - [X] {T407802} - [] {T433319} ---- 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 | ------ **Acceptance Criteria:** [x] Connect with the Machine Learning team ASAP [] 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)
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}
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}
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

Global SearchUse ResultsEdit QueryHide Query

Global Search
Use Results
Edit Query
Hide Query