Page MenuHomePhabricator
Search Global Search

Global Search
Use Results
Hide Query

Use the application-specific Advanced Search for better results and additional search criteria: Tasks, Commits. (More information)
  • 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.
  • 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
  • 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
  • T422513: Image Suggestions uses AI-generated images from Commons when adding images on English Wikipedia
    • Task
    **Steps to replicate the issue** (include links if applicable): * Open the Wikipedia app * Navigate to an article on English Wikipedia (enwiki) * Start the flow to add an image to the article * Observe the suggested images provided by the app **What happens?**: The app [[ https://en.wikipedia.org/w/index.php?title=Egoi&diff=prev&oldid=1338507354 | suggests ]] images from Wikimedia Commons without filtering out AI-generated images. A user [[https://en.wikipedia.org/wiki/User_talk:ScottyNolan/Archive_1#:~:text=%5Bsubscribe%5D-,AI%2Dgenerated%20images,-Per%20WP%3AAIIMAGE | reported ]] that they added an AI-generated image based on the app’s suggestion, assuming it was appropriate since it appeared in other language versions of the article. **What should have happened instead?**: AI-generated images should not be suggested when adding images on English Wikipedia, or at least should be filtered out when possible, given that enwiki policy ([[https://en.wikipedia.org/wiki/Wikipedia:AIIMAGE | WP:AIIMAGE ]]) generally discourages their use. **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): Prevent the app from suggesting AI-generated images (based on Commons categorization or metadata) when users are adding images to articles on English Wikipedia. ==Potential solutions - **[hard]** filter images with the `{{PD-algorithm}}` template in their Commons File pages, see T422513#11813943 - **[hard]** filter images with ([instance of](https://www.wikidata.org/wiki/Property:P31), [AI-generated image](https://www.wikidata.org/wiki/Q116177346)) Commons statements - **[easy, only for depicts-based suggestions]** filter Commons statements as above when [parsing mediainfo](https://gitlab.wikimedia.org/repos/structured-data/image-suggestions-data-pipelines/-/blob/cf70a2fac7477c1475366d0211e5d898dea8da74/image_suggestions/image_suggestions/udfs.py#L122) - **[medium, only for Wikipedia lead images]** implement a filter in [filter_articles_with_lead_images](https://gitlab.wikimedia.org/repos/structured-data/image-suggestions-data-pipelines/-/blob/main/image_suggestions/image_suggestions/wikidata_and_lead_images.py?ref_type=heads#L378)
  • T422187: [QA] Suggested tasks issues
    • Task
    This is a list of tasks/issues to serve as a reference for future prioritization of work on SE workflows. **(1) Wrong message after all suggestions were rejected.** Tested on `testwiki wmf.22`. @Sgs comment - https://phabricator.wikimedia.org/T336245#9095986 >|Mobile Structured (AddLink) |VE Yes, wrong messaging |Yes Yields console errors, same as T342465#9081167. The messaging is wrong when all recommendations have been rejected (You've published an edit as opposite of Thanks for reviewing suggestions. Keep going!) In the gif below the following steps are illustrated: - a user selects an article with Add link task - on an article, a user rejects all suggestions - after the last suggestion was rejected, a user sees the "Save" overlay and clicks on the "Done" button - a message appears "Congratulations on publishing another suggested edit!" **(2) {T421306} - re-confirmed on `testwiki wmf.22`** **(3) The congrats message appears after a suggested message is undone via View history link** Steps: - make an a SE edit - on an article where the edit was made, go to View history" - in "View history" click `undo` - the SE edit is undone, the congrats message apears. **(4) [WIP] re-check ** {T342465}
  • T422082: "Get started here" incorrectly points to central notice banner
    • Task
    (found by @AAlhazwani-WMF) Steps: 1. As a non-logged user on mobile `enwiki wmf.21`, go to the Main page and click on 'Log in" 2. Click on "Join Wikipedia" to create a new account 3. After a new account is created, the Welcome survey is displayed - fill it out & submit 4. Go to Homepage button is displayed - do not click. 5. Click on the side menu item - Main page Main page with "Get started here" is displayed pointing to the central notice banner. {F74752325} ** What should happen instead:** - "Get started here" should only to the user menu icon - Hide the central notice banner as long as the 'Get started here' banner is visible. So that even if they don't dismiss the banner - and if they visit other pages - the arrow is still pointing at the user button in the top bar.
  • T421655: Onboarding experiment: Redirect Main Page account creators to Homepage post-registration
    • Task
    ####User Story: As a newcomer who has just created an account from the Main Page, I want to be guided to a clear and personalized starting point so that I understand what to do next and can begin contributing right away. ####Background: Newcomers who create accounts from the Main Page are often returned to the Main Page after registration. This experience lacks clear next steps, personalization, and guidance, which may hinder activation. This task proposes an experiment to redirect these users to their Homepage immediately after account creation to provide a more structured and supportive onboarding experience. ####Problem: After account creation, newcomers need a clear landing experience that helps them get started. ####Currently: - Many accounts are created from the Main Page [[ https://www.mediawiki.org/wiki/Growth/Analytics_updates/EditorJourney_initial_report | In past analysis, ]] ~30% of new accounts were created after visiting the Mainpage. - Users are returned to the Main Page post-registration - The Mainpage is content-dense and not designed for onboarding - Why so many automated "Welcomes" and competing calls to action? - {F74286340} - This may contribute to confusion, drop-off, and lower activation rates. ####Hypothesis: If newcomers who create accounts from the Main Page are redirected to their Homepage after registration, they will be more likely to engage with onboarding features and complete constructive edits, leading to improved activation and retention. ####Experiment Design: - Target group: Newly registered users who create accounts from the Main Page - Treatment: Redirect users to their Homepage immediately after account creation - Control: Existing behavior (return to Main Page) - Platform: Prioritize mobile, but include desktop if feasible - Metrics: - Constructive activation rate - Constructive edit rate - 2-week retention ####Acceptance Criteria: - Consider instrumentation to confirm entry point (Main Page account creation) - Experiment is implemented and gated to users who create accounts from the Main Page - Users in the treatment group are reliably redirected to their Homepage - Metrics are tracked and analyzed against control group
  • T421459: Allow mentees to remove or clear old questions from the “Your mentor” Homepage module
    • Task
    #### User Story As a **mentee**, I want to remove old or irrelevant questions from my “Your mentor” module so that my homepage reflects my current needs and progress, and I can focus on questions that matter now (and not be annoyed by seeing old questions). #####Description: Mentees currently cannot remove or clear previously asked questions from the “Your mentor” module on the homepage. This can lead to outdated or unanswered questions persisting indefinitely, even after a mentee has progressed or been reassigned to a new mentor. [[ https://en.wikipedia.org/wiki/Wikipedia:Teahouse#c-WendlingCrusader-20260326161200-Is_it_possible_to_edit_my_homepage? | Example feedback ]]: A mentee reported that after being assigned a new mentor, their homepage still shows questions asked to a previous mentor two years ago. They would like the ability to remove these outdated questions. ####Proposed solution: Allow mentees to: - Remove individual questions from the module **Impact:** - Keeps the mentor module relevant and up to date - Reduces clutter and confusion for returning or progressing mentees - Improves sense of ownership and control over the homepage experience
  • T421306: [wmf.5 - regression] desktop Help panel cannot be open on Link recommendations articles
    • Task
    **//Notes:// ** - The issue is present on `wmf.5` - **mobile** Help panel can be open for any type of SE tasks - Help panel for other tasks works as expected - {icon exclamation-triangle color=green} If you click to close the add link dialog, the Help panel works as expected. ====Steps:===== - from Homepage go to any Link recommendation article - an article in Suggested Edit mode displays the Help panel as collapsed - click to uncollapse Help panel =====What happened===== **(1)** the panel cannot be open. When the Help button is clicked, the background of a link recommendation card changes to grey (click on the gif below). {F73668092} **(2)** when a user switches to Read mode on an Add link article, the Help button and SE button persist, see the steps below: - a user in SE mode on an Add a link article - the Help button is not clickable, but Add link functionality and UI works as expected. - click to collapse the SE dialog - it collapses and is displayed alongside with the Help button - switch to the Read mode - the non-clickable buttons are still displayed: {F78733138} =====What should happen===== - if a button is displayed, it should be clickable - Read mode should not display the SE and Help buttons
  • T420653: New editor's Special:Homepage in dark mode shows inverted image in suggested-edits-card
    • Task
    **Steps to replicate the issue** (include links if applicable): 1. Set Wikipedia to "light mode" via Preferences > [[ https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-rendering | Appearance ]] 1. Turn on "dark mode toggle" via Preferences > Gadgets > [[ https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets | Dark mode toggle: Enable a toggle for using a light text on dark background color scheme ]] 1. Go to [[ https://en.wikipedia.org/w/index.php?title=Special:Homepage | https://en.wikipedia.org/w/index.php?title=Special:Homepage ]] for new editors (I think this is part of the "growth experiments" feature set?). I have attached a screenshot at the bottom of this issue. 1. Refresh until the article under "Suggested Edits" has an image 1. Click on the person icon in the top right of the page to open the "Personal Settings" dropdown & use the "dark mode toggle" to change the page to dark mode. {F73670544} 1. Observe that the image in the `.suggested-edits-card` is inverted (see screenshot at the bottom of this issue) **What happens?**: Images in the suggested-edits-card on the Special:Homepage are inverted when dark mode is active. (see attached screenshot at the bottom of this bug) **What should have happened instead?**: Images should not be inverted in dark mode. **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): MediaWiki: 1.46.0-wmf.20 (f1911ec), 18:24, 19 March 2026 **Other information** (browser name/version, screenshots, etc.): Firefox 148.0.2 On other pages, images are not inverted in dark mode. This is because the CSS style rule which applies `filter: invert(1) hue-rotate(180deg);` uses the `html img:not(.mw-invert)` selector to ignore most images, such as those on article pages. However, in the `.suggested-edits-card` on the Special:Homepage, images are placed using a CSS rule `background-image` instead of with an `img` element. Therefore, the normal selector that protects most images from inversion is not applied correctly. **My first impression is that you could add a class like `.cdx-no-invert` to the div with the background-image (`.se-card-image`) so that that element is not inverted with the rest of the page in dark mode.** {F73157967}
  • T420566: Decide how GrowthExperiments should be handled on closed wikis
    • Task
    ==== Background The #growth-team enabled #growthexperiments on all publicly editable Wikipedias to help newcomers edit the wikis (T304052). To do that, we changed the `growthexperiments` dblist to correspond to `wikipedia.dblist - private.dblist - closed.dblist` (plus `frwiktionary`, which is the only non-Wikipedia we operate on). However, at times, Wikipedias get closed, which means they disappear from the `growthexperiments` dblist. ==== Problem When requesting schema changes, we ask it to be performed on the `growthexperiments` dblist. However, closed wikis can also have the corresponding tables. Even though the GrowthExperiments extension is not enabled there //now//, wikis can get reopened (at which point, GrowthExperiments would get re-enabled, and it would not see the schema changes made in the meantime). ==== Possible solutions There are two approaches we can take: 1. **Drop growthexperiments tables on closing Wikipedias**: each time we close a wiki in the `growthexperiments` dblist, we would need to drop the corresponding DB tables; if it is reopened, they can be created again 2. **Enable GrowthExperiments on all closed Wikipedias and create the DB tables there**: alternatively, we can set `growthexperiments` to `wikipedia - private`, and keep closed wikis in there; in that case, the DB tables would still be maintained and updated, and re-enabling would be straightforward The advantage of the first option is that we do not have any DB tables we don't need in production. However, it would be pretty expensive on people time (especially given we tend to be fairly careful before dropping tables). The second solution brings some extra empty tables, but it will work on its own, without needing human attendance. Tagging #DBA to advice on what approach should the #growth-team take. ==== Acceptance Criteria * [ ] update https://wikitech.wikimedia.org/wiki/Close_a_wiki to include a "notify DBAs the wiki was closed" instruction * [ ] the task template should list extensions that are auto-disabled on closing a wiki (i.e. including GrowthExperiments)
  • T420542: Design exploration: Evolve Impact module for experienced editors and patrollers
    • Task
    ####User Story: As an experienced Wikimedian editor or patroller, I want access to impact metrics that match the depth and complexity of my contributions, so that I can efficiently understand and evaluate my work without relying on tools that are too basic or disconnected from my workflow. ####Description The Growth team’s Impact module on the Newcomer Homepage is designed to reinforce early contributions by showing lightweight impact metrics (for example, pageviews and edit counts). However, community feedback suggests that the module becomes less useful as editors gain experience, particularly for highly active contributors and patrollers. More experienced editors often rely on external tools such as the XTools Edit Counter for deeper and more comprehensive contribution insights. This raises an opportunity to rethink how the Impact module scales with user experience, and whether it should adapt, redirect, or phase out over time. ####Problem The current Impact module: - Is optimized for newcomer motivation, not ongoing contributor workflows - Provides limited depth compared to tools used by experienced editors - Does not adapt based on editor maturity or needs ####Community feedback >>! In T341599#11721478, @Mathglot wrote: > The more experience a user has, the more they should shift away from using the Impact module and toward the [[https://xtools.wmcloud.org/ec | Toolforge Edit counter tool]], which contains all of the Impact stats (except for 'streak', which is probably the least valuable of them, especially when one is no longer a newbie). > > Note: the tool does have some limits, but they are stratospheric; one million edits is a hard limit. For a typical user, results take a second or two. The #1000 [[https://en.wikipedia.org/wiki/Wikipedia:List_of_Wikipedians_by_number_of_edits|top editor]] (99k edits) takes about [[https://xtools.wmcloud.org/ec/en.wikipedia.org/Gidonb|9 seconds]] to return complete results. The #25 editor (918k edits) takes [[https://xtools.wmcloud.org/ec/en.wikipedia.org/WOSlinker|over a minute]]. For a user with > 1M edits, the tool [[https://xtools.wmcloud.org/sc/en.wikipedia.org/BrownHairedGirl|returns immediately]] but with only one estimated statistic. > > I would propose we implement a "shift" in the Impact module, thus: > * add an Ec tool link below the current stats when the users total edits exceeds X (X =~ 1,000?) > * replace all content in the module with a 'Please see...' and a link to the Ec tool when total edits exceeds Y (Y =~ 5,000?) > * drop the Impact module when total edits exceeds Z (Z =~ 10,000?). > > So, for their first 1,000 edits, the modules would appear as it does now, and then at thresholds X, Y, and Z it would shift them increasingly towards using the tool. > > To help support this, and come up with good values for X, Y, and Z, it would be helpful to see a line graph of number of clicks on the Homepage tab as a percentage of all clicks by a given user (y-axis) plotted against total number of edits (x-axis). This might be useful for other growth apps as well. ---- ####Goal Explore design directions for how the Impact module could better support: - More experienced editors - Patrollers and high-volume contributors - While maintaining its effectiveness for newcomers **Design questions / exploration areas** - Should the Impact module adapt based on experience level? If so, how? - What is the right balance between keeping users within the Homepage ecosystem & pointing them to external tools like the XTools Edit Counter? - Are there opportunities to surface more advanced metrics in-product? ####Acceptance criteria - Design exploration includes multiple concepts - Sharing designs with involved WMF teams and interested community members (via this task)
  • T420354: Add alerting on suspiciously long mw-cron jobs
    • Task
    Today, @Michael discovered there is a long-running mw-cron job for the Growth team: ``` migr@deploy2002:~$ kubectl logs -f job/growthexperiments-listtaskcounts-29513771 mediawiki-main-app Error from server (BadRequest): container "mediawiki-main-app" in pod "growthexperiments-listtaskcounts-29513771-jrv9k" is waiting to start: trying and failing to pull image migr@deploy2002:~$ kubectl get jobs -l team=growth,cronjob=growthexperiments-listtaskcounts NAME STATUS COMPLETIONS DURATION AGE growthexperiments-listtaskcounts-29513771 Running 0/1 33d 33d migr@deploy2002:~$ ``` This job should never take more than a couple of minutes to complete. If it takes more than an hour, we definitely have a problem. Would it be possible to add something like `max_expected_length = XX hours` to the job definition, and trigger an alert if the expected duration was exceeded? This would help us notice this much quickly than manually after a month. --- //Update 2026-03-19// - One alternative to passive alerting that we may want to consider is functionality for setting `activeDeadlineSeconds` on the cronjob's job template. That would provide an //active// backstop on execution time. As a side effect, the job failure alert should also fire, as a result of the job being terminated. See T420354#11722534.
  • T419938: Support per-user preference configuration
    • Task
    This is similar to the current CommunityConfiguration, but it per-user instead of per-site, and this will be stored in a subpage of user page such as User:Example/twinkle.json See https://en.wikipedia.org/wiki/Wikipedia:Twinkle/Preferences for a current example, and also {T382959} for allowing gadgets to setup a per-site (instead of per-user) setting page. Note: * This is not suitable to be stored in user_property table since a gadget may introduce hundreds of options. See {T408733} * We may want to introduce a user right to edit other's per-user preference, to combat the situation that someone setting that improperly. This would be granted to sysops, who are able to edit others' JSON pages (and thus can modify such setting of anyone directly).
  • T419416: Add "email me a password" option to mobile account creation form
    • Task
    This task builds on the account creation form cleanup (T409236) by adding an option for users to skip choosing a password and instead receive an auto-generated one via email. This is an existing pattern on MediaWiki (`create2` [[ https://www.mediawiki.org/wiki/Manual:Account_creation | Manual:Account creation ]]) but is currently not surfaced. Offering this option could simplify the form for users who prefer not to create a password on the spot. ####User story & summary: As a new user creating an account on mobile web, I want the option to receive a password via email so that I can complete registration without having to think of and type a password. ####Design: //**Scope: this task is scoped to Mobile only.**// {F72758817} ####Acceptance Criteria: AC1 - Checkbox display * Given I am on the account creation page on mobile web * When I view the password section * Then I see an "Email me a password instead" checkbox displayed above the password field, unchecked by default **When the checkbox is checked:** AC2 - Hide password fields * Given I check the "Email me a password instead" checkbox * When the form updates * Then the password field, password helper text, and confirm password field are hidden AC3 - Email field becomes required * Given I check the "Email me a password instead" checkbox * When the form updates * Then the email address field label no longer shows "(recommended)" and the field becomes required AC4 - Email field description removed * Given I check the "Email me a password instead" checkbox * When the form updates * Then the email address field description ("Email is required to recover your account...") is removed **When the checkbox is unchecked again:** AC5 - Restore default state * Given I uncheck the "Email me a password instead" checkbox * When the form updates * Then the password field, helper text, confirm password field, email optional indicator, and email description are all restored to their default state
  • T419415: Remove confirm password field from mobile account creation form
    • Task
    If {T419413} is implemented, we may test if the "Confirm password" field becomes redundant - given that users can verify their password visually instead of retyping it. ####User story & summary: As a new user creating an account on mobile web, I want to register without having to type my password twice so that the form is shorter and faster to complete. ####Background & research: The confirm password field exists to prevent typos, but with a reveal password action in place (T419413), users can visually verify what they've typed. Removing the field reduces form length by one input - meaningful on mobile where screen space is limited and every field adds friction. Most platforms in the comparative analysis (T410558) that offer password reveal do not require password confirmation. ####Design: {F72757951} ####Acceptance Criteria: 1. Remove the "Confirm password" field from the account creation form on mobile web 2. The single password field continues to enforce the password requirements 3. The reveal password action (T419413) remains functional on the single password field
  • T419358: [EPIC] Personal Dashboard + Homepage [FY26-27, Deepen Engagement 1.3]
    • Task
    https://www.mediawiki.org/wiki/Home == Summary == As outlined in the [[ https://www.mediawiki.org/wiki/Contributors/Strategy | Contributors Strategy ]], volunteers currently face a fragmented experience that provides limited guidance on how to navigate the many available contribution pathways and policies. Over time, both volunteers and Wikimedia Foundation teams have attempted to address this problem through dashboards and special pages, such as: - The Newcomer Homepage ([[ https://en.wikipedia.org/wiki/Special:Homepage | en ]]) - Special:PersonalDashboard - Community-created dashboards and scripts - Special:Contribute ([[ https://en.wikipedia.org/wiki/Special:Contribute | en ]]) Active readers have also demonstrated interest in personalized experiences through products such as mobile feeds, the Android activity tab, and the annual Year in Review. At the same time, internet users increasingly expect a central starting page on platforms where they consume content or contribute. Experiments with the Newcomer Homepage show that a centralized hub can significantly improve retention and constructive activation. This Epic explores the creation of a unified personal homepage/dashboard that can support contributors across the journey from reader to experienced editor and moderator. The homepage would function as the engine behind a contributor experience that supports: - Discovering compelling opportunities to contribute - Being equipped to act on those opportunities - Having a rewarding experience where impact and next steps are clear - Creating this cycle is critical to building long-term participation habits and improving contributor retention, especially given the decline in active editors across Wikimedia projects. Because multiple use cases have emerged and experimentation requires flexible infrastructure, this Epic proposes establishing a new extensible architecture that supports homepage experimentation and modular dashboards across different contributor roles. == Objective: Deepen Engagement 1 == We increase the number of retained editors by 30% by delivering a structured, progression-driven, and more meaningful mobile-first editor experience. This is a milestone on our way to doubling retained editors within two years. == Key Result: Deepen Engagement 1.3 == By the end of Q2, achieve an x% increase in second-week retention for editors who are presented with interventions focused on editor progression through controlled experiments, compared to editors in the control group. **Context** This work advances a unified personal dashboard that supports the full journey from reader to contributor to moderator. The initiative will: - Integrate the Newcomer Homepage and the Personal Dashboard MVP into a cohesive experience - Introduce a clear progression system that helps contributors advance beyond their first edits - Strengthen onboarding pathways for moderation and cleanup work - Help interested contributors take on more responsibility while reducing patrolling backlogs over time == Benefits == A centralized homepage or personal dashboard allows the platform to connect the dots for volunteers in ways that are currently difficult. Key benefits include: - Modular experiences that can be customized by wikis and individuals - Personalized recommendations for impactful contributions - Clear visibility of impact so contributors understand the value of their work - Recognition and milestone experiences that celebrate progress - A consistent entry point for discovering opportunities and returning to continue contributing This approach can benefit multiple audiences: - Readers who want deeper engagement with content - New contributors learning how to participate - Experienced editors seeking meaningful work - Moderators managing community workflows == Use Cases == === Reader experience === As a reader, I can engage with Wikipedia in a personalized way that helps me curate content and discover opportunities to contribute. '''Supporting context''' === Language and localization contributors === As a translator, I can seamlessly integrate translation work with other types of contributions while understanding my overall impact. === New contributors === As a newcomer, I receive guided steps that help me: - Learn how to contribute - Find help when needed - Understand the impact of my edits === Experienced editors === As an experienced editor, I can easily identify high-impact opportunities to contribute and track my contributions and impact. === Moderators and patrollers === As a moderator, I have access to a customizable dashboard that: - Reduces fragmentation across moderation tools - Makes moderation workflows easier to navigate - Supports skill development - Helps reduce community moderation backlog NOTE: this epic is still a work is progress. This work is scheduled for July 2026 - December 2026.
  • T419305: Vector 2022 defaults for new accounts: collapse tools & appearances menus
    • Task
    ####User story & summary: As a new Wikipedia account holder using the desktop site, I want the interface to feel simple and focused when I first arrive, so that I am not overwhelmed by too many menus and options while I am trying to get started. **Context:** The #growth-team is exploring ways to reduce cognitive load for newcomers during account creation and their first editing sessions. Minimizing non-essential interface elements by default may help create a simpler initial experience while still preserving full functionality for users who want to access these menus. **Related: ** - {T409236} - {T317884} ####Description: New account holders often encounter a large amount of interface information when they first arrive on the desktop experience. In the current Vector 2022 layout, the Tools and Appearance menus appear expanded in the right sidebar. While these menus are useful for experienced contributors, they may contribute to information overload for people who are just getting started. {F72643484} The expanded menus also create layout issues for some pages: {F72643385} This task proposes minimizing the Tools and Appearance menus by default for newly created accounts using the desktop Vector 2022 skin. The menus would remain available but would appear collapsed initially, allowing newcomers to expand them if needed. The goal is to simplify the interface and reduce visual complexity during the earliest stages of the editing experience. ####Proposed behavior: For newly created accounts using Vector 2022 on desktop: - The Tools menu should be collapsed by default. - The Appearance menu should be collapsed by default. - Users should still be able to manually expand either menu. - Once expanded, normal interface behavior should continue (remembering the user’s preference). **Scope considerations:** - Applies only to newly created accounts. - Applies only to the Vector 2022 skin on desktop. - Does not remove or hide functionality, only changes the default state of the menus. **Open questions:** - Can we release this an a quick A/B test to measure the impact on new editor metrics (constructive activation, constructive edit rate, retention, etc.). - In the longer term, we may want to reconsider the placement of the Appearance menu when it is collapsed into the main header. For logged-in users, it may not be immediately clear why appearance-related settings are located separately rather than within Preferences, where most other user configuration options live. ####Acceptance Criteria: Given I'm on the wikis on Desktop while using Vector 2022, When I visit Special:CreateAccount or Special:UserLogin, Then the Appearance and Tools menus are collapsed by default Given I'm on the wikis on Desktop while using Vector 2022, When I've successfully created my new account Then the Appearance and Tools menus are collapsed by default
  • T419172: LogicException: GrowthExperiments\NewcomerTasks\TaskSuggester\NewcomerTasksCacheRefreshJob executed for invalid userId (0)
    • Task
    ==== Error ==== * mwversion: 1.46.0-wmf.18 * timestamp: 2026-03-05T21:23:40.144Z * phpversion: `8.3.30` * reqId: `cc4e0baa-2184-4d5a-9431-b1e6b35cc8b1` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2026-03-04T21:23:40.144Z',to:'2026-03-05T21:53:36.789Z'))&_a=(query:(query_string:(query:'reqId:%22cc4e0baa-2184-4d5a-9431-b1e6b35cc8b1%22'))) | Find reqId in Logstash ]] ```name=normalized_message,lines=10 [{reqId}] {exception_url} LogicException: GrowthExperiments\NewcomerTasks\TaskSuggester\NewcomerTasksCacheRefreshJob executed for invalid userId (0) ``` | Frame | Location | Call | -- | -- | -- | from | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.18/includes/NewcomerTasks/TaskSuggester/NewcomerTasksCacheRefreshJob.php#42 | /srv/mediawiki/php-1.46.0-wmf.18/extensions/GrowthExperiments/includes/NewcomerTasks/TaskSuggester/NewcomerTasksCacheRefreshJob.php(42) ]] | | #0 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/EventBus/+blame/refs/heads/wmf/1.46.0-wmf.18/includes/JobExecutor.php#94 | /srv/mediawiki/php-1.46.0-wmf.18/extensions/EventBus/includes/JobExecutor.php(94) ]] | GrowthExperiments\NewcomerTasks\TaskSuggester\NewcomerTasksCacheRefreshJob->run() | #1 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+blame/refs/heads/master/rpc/RunSingleJob.php#60 | /srv/mediawiki/rpc/RunSingleJob.php(60) ]] | MediaWiki\Extension\EventBus\JobExecutor->execute(array) | #2 | {main} | ==== Impact ==== - 6 error reports `frwiki` https://logstash.wikimedia.org/goto/3edfea0b1b376704952d1edb7f7a5e02 - the error seems to be present for some time - 30 days report https://logstash.wikimedia.org/goto/f894fb895636523d0825826c3eb78d9a
  • T419108: On the user homepage, include a more aggressive new message notification
    • Task
    **Feature summary** (what you would like to be able to do and where): Some new contributors have are hard to reach. When contributors get a new talkpage message, and then visit their personal homepage, I would expect some more aggressive notification that they should check their talkpage. **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): A new contributor joins Wikipedia. However, they don't exactly behave the way that the community expects them to. An admin leaves feedback on their personal talkpage. However, maybe the new user doesn't understand the concept of a talkpage, or they developed a notification blindness. As the user homepage improves, it is more likely that they will visit that though - we have pipelines to suggest that they visit it. If I were a new contributor, I would expect a really explicit notification there to go check my talkpage - a notification that does not only tell me that a message is waiting for me, but also why it is important. If the user keeps ignoring the talkpage message, the only tool that admins have left, is blocking the user and hoping that they will engage. That is a bad experience for everyone. **Benefits** (why should this be implemented?): Hopefully more users will check their talkpage when they get a message! Whether this is likely to get any effect, could be evaluated by checking how many people visit their user homepage while a talkpage notification is active. If implemented successfully, I would expect the average age of that talkpage notification to drop among new users. Current view without talkpage notification, and with: {F72574227} {F72574233}
  • T418992: A blocked user shouldn't get a new mentor when their original mentor quits
    • Task
    **Steps to replicate the issue** # a user get blocked # this user's mentor quits # a new mentor gets assigned to the blocked users [[ https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Journal&page=Utilisateur%3AFouedkedjam.grosbaiseurdu77 | Example ]] Expectation: the blocked user should not get a mentor Related task * {T351234}
  • T418297: Introduce way(s) to disable suggestions
    • Task
    This task involves the work of making it possible for a tool – broadly defined – that causes VE to open to forcibly prevent any edit suggestions from appearing. The need for this task comes in response to noticing the following behavior... === Behavior 1. Enable the `Revise Tone` Structured Task 2. Enable the `Suggestion Mode` beta feature 3. Navigate to the newcomer homepage and tap a `Revise Tone` structured task that causes VE to open a page where edit suggestions are available **✅ Expected** 4. The `Revise Tone` Check/Suggestion card is focused/expanded and scrolled into view **❌ Actual** 4. The `Add citation` Check/Suggestion card is focused/expanded and scrolled into view === Requirements - Introduce the ability for a tool to disable/prevent Suggestions from appearing within an edit session it is activating - Introduce the ability for a tool to demand that Suggestions be shown within an edit session it activates //after// someone has engaged with said "tool"
  • T418295: Add-an-image on desktop
    • Task
    **Feature summary** (what you would like to be able to do and where): According to {T296700} the add-an-image suggested edit feature should be usable on desktop. However, it isn't as you can see in the screenshot below. Please make it possible to use the feature on desktop (and mobile Web). {F72317279} **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): Most contributors are on desktop and second most on mobile Web, not the apps. **Benefits** (why should this be implemented?): More media in articles, testing the image suggestions, using the image suggestions (especially if one can refine interests further).
  • T418194: Mentors still having mentees after removing themselves
    • Task
    **What happened?**: As reported [[ https://en.wikipedia.org/wiki/Wikipedia_talk:Growth_Team_features#Mentees_not_reassigned? | here ]], Liu1126 attempted to quit as a mentor, but they [[ https://en.wikipedia.org/w/api.php?action=query&format=xml&list=growthmentormentee&gemmmentor=Liu1126 | still have mentees ]] and are still receiving questions. **What should have happened instead?**: Mentors who quit mentorship should have all their mentees reassigned.
  • T418051: [RFC] Personalized article recommendations for Newcomer Tasks using content-based filtering
    • Task
    ## PRIORITY: ``` Normal ``` = Summary = Propose exploring **personalized article recommendations** for Newcomer Tasks and Suggested Edits using a content-based collaborative filtering approach (similar to Scholar-Inbox's system). This would enhance current topic-based filtering with per-user relevance ranking instead of random selection. = Problem = Current Newcomer Task recommendation pipeline: 1. Filters by topic (from welcome survey) 2. Filters by task type (copyedit, links, etc.) 3. **Randomly selects** from filtered pool 4. No personalization beyond initial topic selection 5. No learning from user behavior **Limitations identified in prior research** ([https://meta.wikimedia.org/wiki/Research:Prioritization_of_Wikipedia_Articles/Recommendation Research:Prioritization]): * Status quo bias (reinforces existing patterns) * Equal weighting of all articles in filtered pool * No adaptation to individual user preferences * Simple keyword-based topic matching ("morelike" query) **From T227728**: "A valuable tool for helping tasks be relevant to newcomers is the welcome survey, which was originally built specifically for **personalizing the newcomer's experience.**" ← We have the stated goal but not the implementation. = Proposed Solution = Implement **Scholar-Inbox style recommendations** using semantic embeddings + lightweight ML: '''Architecture:''' 1. **Pre-generate embeddings** for Wikipedia articles * Use GTE-large or SPECTER2 (open models, proven on Wikipedia) * 256-dimensional vectors via PCA (from 1024-d) * ~6GB storage for 6M English Wikipedia articles * One-time generation, updated weekly/monthly 2. **Per-user preference models** * Logistic regression on article embeddings * Trained on user's edit history or explicit ratings * Lightweight (runs client-side or on server) * Updates incrementally as user interacts 3. **Ranking instead of random** * Score all articles in filtered pool by predicted relevance * Return top-N ranked by personalized score * Fall back to topic-based filtering for cold-start users 4. **Feedback loop** (optional enhancement) * "Was this suggestion helpful?" after each task * Explicit ratings improve future recommendations * Active learning for cold-start users '''Cold Start:''' * Use existing welcome survey topics * Bootstrap with 2D t-SNE visualization of article space * Prompt user to select interesting clusters (like Scholar Maps) = Prior Art = **Research:** * **Scholar Inbox** (2025): Content-based arXiv paper recommendations * Paper: https://arxiv.org/abs/2504.08385 * Performance: 86.75% AUC, 78.31% balanced accuracy on 800K ratings * Architecture: GTE-large embeddings + logistic regression * Designed for personalization at scale * **Scalable Wikipedia Recommendations** (2020): * Paper: https://arxiv.org/abs/2009.11771 * Proves semantic embeddings work well for Wikipedia articles * Doc2Vec approach, highly efficient **Existing Infrastructure:** * Growth team already uses ML for link recommendations (T252822) * Evaluation framework exists: https://github.com/geohci/wiki-prioritization * Welcome survey provides initial preference data * Click-through data available for validation = Alternatives Considered = '''Option 1: Deep learning recommendations''' * Rejected: Too heavy, requires GPU, privacy concerns * Scholar-Inbox uses simple logistic regression (intentionally lightweight) '''Option 2: Collaborative filtering (user-user similarity)''' * Rejected: Cold-start problem for newcomers * Content-based works with zero user history '''Option 3: Improve "morelike" query''' * Limited improvement: Still keyword-based, not semantic * Embeddings capture deeper relationships '''Option 4: Keep current system''' * Works but leaves personalization opportunity on table * Random selection doesn't leverage available signals = Technical Feasibility = ✅ **Proven approach**: 86.75% AUC on scholarly articles (similar domain) ✅ **Lightweight**: Logistic regression, not neural networks * Can run in browser (localStorage for user model) * Or on WMF servers (minimal compute) ✅ **Storage manageable**: ~6GB for embeddings (one language) * Less than typical media file * Served via CDN, gzipped ✅ **Incremental rollout**: * Phase 1: Generate embeddings for 10K articles (proof of concept) * Phase 2: A/B test on test.wikipedia.org * Phase 3: Deploy to small wikis, gather metrics * Phase 4: Scale to all languages if successful ✅ **No major architecture changes**: * Fits into existing recommendation pipeline * Replace random selection step with ranking step * Backward compatible (falls back to current behavior) = Questions for Growth Team = 1. **Interest level**: Is personalized ranking something Growth team wants to explore for Newcomer Tasks? 2. **Data access**: Can we access anonymized newcomer task click/edit data from the evaluation framework for validation? 3. **Technical concerns**: Any red flags about: * Embedding storage/serving (~6GB per language)? * Privacy implications of user models? * Integration with existing GrowthExperiments extension? 4. **Testing approach**: Would you prefer: * A) Standalone prototype first (external service)? * B) Direct integration with A/B test on test wiki? 5. **Collaboration**: Should this go through: * Research team first (validate approach)? * ML team for embedding generation? * Direct Growth team implementation? 6. **Timeline fit**: Does this align with Growth team roadmap, or should we wait for future quarter? = Prior Related Work = Tasks explicitly mentioning personalization need: * **T227728**: Newcomer tasks 1.0 (mentions welcome survey for personalization) * **T213990**: Newcomer homepage ("personalizing newcomer's initial experience") * **T242400**: Topic matching improvements (currently uses "morelike" backend) * **T301096**: Prioritizing underlinked articles (global heuristic, not personalized) = Success Metrics (If Pursued) = Compared to current baseline (random selection from filtered pool): '''Primary:''' * Click-through rate on suggested tasks * Task completion rate * Time to first edit '''Secondary:''' * User satisfaction (survey) * Diversity of articles edited (avoid filter bubble) * Edit quality (revert rate unchanged) '''Evaluation framework:''' Use existing wiki-prioritization analysis pipeline = Next Steps (If Positive Response) = 1. **Week 1-2**: Generate embeddings for 10K English Wikipedia articles 2. **Week 3-4**: Build proof-of-concept ranking API 3. **Week 5**: Share evaluation results with Growth team 4. **Week 6**: If promising, discuss integration path If not interested now, happy to revisit in future quarter or explore alternative contributions. = References = * Scholar-Inbox paper: https://arxiv.org/abs/2504.08385 * Scalable Wikipedia recommendations: https://arxiv.org/abs/2009.11771 * Current evaluation framework: https://github.com/geohci/wiki-prioritization * Growth team research: https://meta.wikimedia.org/wiki/Research:Prioritization_of_Wikipedia_Articles/Recommendation = About Me = Researcher interested in recommendation systems, familiar with ML/NLP, happy to collaborate with Wikimedia community
  • T417957: Enable disabling/hiding mentor and guides modules in Special:Homepage
    • Task
    **Feature summary** (what you would like to be able to do and where): Please enable hiding these, there could be settings for this page where one could show them again (alternatively just collapse the tile and make it a small button to show it again). These two modules: {F72191094} **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): Active experienced users don't need these so may want to hide these as they just take up screen space and are distracting. **Benefits** (why should this be implemented?): Cleaner UI. Less distraction. Simply redundant parts of the page. It may be easier to use this page on mobile if these can be disabled. More space for other things ([[ https://meta.wikimedia.org/wiki/Community_Wishlist/W442 | here ]] is one idea that would also be useful for more experienced users)
  • T417956: Special:Homepage only shows interests from "Culture" category to select from
    • Task
    **Steps to replicate the issue** (include links if applicable): * Enable Special:Homepage in the English Wikipedia preferences and go to [[ https://en.wikipedia.org/wiki/Special:Homepage | that site ]] * See the interests to select from in the top left **What happens?**: It shows only the 11 interests of the 'Culture' category to select from and none of the others (and these are so broad that I selected none). **What should have happened instead?**: It should also show the other categories' interests (at least on a large screen that would be the best option) or show < > next buttons by which one can switch to the next category of interests. Also those interests are way too broad I think but that's a different issue. **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.): Firefox
  • T417955: Separating articles by type of contribution at Special:Impact
    • Task
    **Feature summary** (what you would like to be able to do and where): [[ https://en.wikipedia.org/wiki/Special:Impact | Special:Impact ]] and Special:Homepage currently just show the top 5 articles edited in any way. Please separate these into articles just copyedited slightly, articles extensively edited, articles created anew, etc. Probably via different tabs and there could still be a listing that shows all articles entirely undifferentiated. Note: this only makes sense when {T337311} also gets/got done. Splitting off articles created should be easy and that would be a really interesting page; currently one has to manually go to each individual page to see the pageviews or manually enter them into the pageviews tool. Eventually, articles created anew from existing redirects should also be included and articles that were translated maybe split off as well. Splitting off articles just edited in minor ways such as editing some typo or adding 1 wikilink or where one has reverted another user's change and articles extensively edited could be done via authorship stats of the articles and/or the bytes changed of the respective edits (in sum). **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): The stats would become useful. They would be interesting as well as make editing more engaging and provide for some feedback that makes it more fun. **Benefits** (why should this be implemented?): See above. It improves editor retention, newcomers turned to active editors, and may motivate to create articles to add to the collection and the source the total pageviews draw from. Also gives a sense of meaning and purpose as well as validation etc. I think just pageviews-based stats are very insufficient as an edit count alternative measure to track and stats + feedback, but they could still be useful...if one separated them in meaningful ways and showed more than just the top 5. Discussed this [[ https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_Annual_Plan/2026-2027#c-Prototyperspective-20260220004800-WhatamIdoing-20260219232900 | here ]] (maybe also one other place).
  • T417850: [EPIC] Revise Tone: Structured Task - V2 improvements
    • Task
    ####User story & summary: As a newcomer to Wikipedia, I want to receive suggestions that help me identify and improve non-neutral language in articles so that I can make constructive contributions that align with Wikipedia’s MOS, encyclopedic tone, and neutrality standards. ####https://www.mediawiki.org/wiki/Growth/Revise_Tone NOTE: Subtasks of this epic include ideas to further improve the Revise Tone Structured Task. This is follow-up work to consider after the V1 Revise Tone epic (T396162) is resolved.
  • T417708: Suggested Edits: Help Panel's "Quick Start Tips" auto scrolls too quickly
    • Task
    ####User story & summary: As a new editor, I want to read "quick start tips" before I start a Suggested Edit so that I understand the onboarding context necessary to complete the task successfully. ####Background & research: Feedback from [[ https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#c-Itsaclarinet-20260216025100-Suggested_Edits_Quick_Start_Tips | enwiki technical village pump ]]: >When opening a page from the Suggested Edits on my userpage, the Quick Start Tips scroll very quickly through their numbered suggestions. I generally consider myself to be a quick reader but adding 1 second more to the timer would be beneficial. Especially for other newcomers who might not know they can manually go back through the tips individually. They do, of course, come back around over time but just a small adjustment like that would be nice. Thank you for considering this! ####Solution: TBD: increase time? Don't autoscroll? Other options? ####Acceptance Criteria: TBD Given [preconditions] When [user action] Then [outcome resulting from actions taken in the when clause]
  • T417271: GuidedTour Cypress uprightdownleft.cy.ts test is flaky
    • Task
    The `uprightdownleft.cy.ts` test file in #mediawiki-extensions-guidedtour is flaky as shown in https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php83-selenium/18753/console ```lines=10 12:43:04 template spec 12:43:12 1) passes 12:43:12 cy:command ✔ visit /?tour=uprightdownleft 12:43:12 cy:command ✔ get #gt-uprightdownleft-1 12:43:12 cy:command ✘ assert expected **<div#gt-uprightdownleft-1.guider.mw-guidedtour-tour-uprightdownleft.mwe-gt-fade-in-up>** to be **visible** 12:43:12 12:43:12 12:43:12 12:43:12 12:43:12 0 passing (8s) 12:43:12 1 failing 12:43:12 12:43:12 1) template spec 12:43:12 passes: 12:43:12 AssertionError: Timed out retrying after 4000ms: expected '<div#gt-uprightdownleft-1.guider.mw-guidedtour-tour-uprightdownleft.mwe-gt-fade-in-up>' to be 'visible' 12:43:12 12:43:12 This element `<div#gt-uprightdownleft-1.guider.mw-guidedtour-tour-uprightdownleft.mwe-gt-fade-in-up>` is not visible because it has CSS property: `opacity: 0` 12:43:12 at Context.eval (webpack://GuidedTour/./cypress/e2e/uprightdownleft.cy.ts:4:0) 12:43:12 12:43:12 12:43:12 12:43:14 12:43:14 (Results) 12:43:14 12:43:14 ┌────────────────────────────────────────────────────────────────────────────────────────────────┐ 12:43:14 │ Tests: 1 │ 12:43:14 │ Passing: 0 │ 12:43:14 │ Failing: 1 │ 12:43:14 │ Pending: 0 │ 12:43:14 │ Skipped: 0 │ 12:43:14 │ Screenshots: 1 │ 12:43:14 │ Video: true │ 12:43:14 │ Duration: 7 seconds │ 12:43:14 │ Spec Ran: uprightdownleft.cy.ts │ 12:43:14 └────────────────────────────────────────────────────────────────────────────────────────────────┘ 12:43:14 12:43:14 12:43:14 (Screenshots) 12:43:14 12:43:14 - /workspace/log/GuidedTour/uprightdownleft.cy.ts/template spec -- passes (failed) (1280x720) 12:43:14 .png 12:43:14 12:43:14 12:43:14 (Video) 12:43:14 12:43:14 - Video output: /workspace/log/GuidedTour/uprightdownleft.cy.ts.mp4 12:43:14 12:43:14 12:43:14 ==================================================================================================== 12:43:14 12:43:14 tput: No value for $TERM and no -T specified 12:43:14 (Run Finished) 12:43:14 12:43:14 12:43:14 Spec Tests Passing Failing Pending Skipped 12:43:14 ┌────────────────────────────────────────────────────────────────────────────────────────────────┐ 12:43:14 │ ✖ uprightdownleft.cy.ts 00:07 1 - 1 - - │ 12:43:14 └────────────────────────────────────────────────────────────────────────────────────────────────┘ 12:43:14 ✖ 1 of 1 failed (100%) 00:07 1 - 1 - - 12:43:14 ```
  • T417259: GrowthExperiments\Mentorship\MentorManager::getMentorshipStateForUserInternal was asked to return mentorship state for a non-named user {user}
    • Task
    ==== Error ==== * mwversion: 1.46.0-wmf.15 * timestamp: 2026-02-12T11:03:46.772Z * phpversion: `8.3.30` * reqId: `f54bbac1-5e4a-4367-a936-04d2e9ddb7e6` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2026-02-11T11:03:46.772Z',to:'2026-02-12T11:06:17.602Z'))&_a=(query:(query_string:(query:'reqId:%22f54bbac1-5e4a-4367-a936-04d2e9ddb7e6%22'))) | Find reqId in Logstash ]] ```name=normalized_message,lines=10 GrowthExperiments\Mentorship\MentorManager::getMentorshipStateForUserInternal was asked to return mentorship state for a non-named user {user} ``` | Frame | Location | Call | -- | -- | -- | from | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Mentorship/MentorManager.php#243 | /srv/mediawiki/php-1.46.0-wmf.15/extensions/GrowthExperiments/includes/Mentorship/MentorManager.php(243) ]] | | #0 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Mentorship/MentorManager.php#272 | /srv/mediawiki/php-1.46.0-wmf.15/extensions/GrowthExperiments/includes/Mentorship/MentorManager.php(272) ]] | GrowthExperiments\Mentorship\MentorManager->getMentorshipStateForUserInternal(MediaWiki\User\User) | #1 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Mentorship/MentorManager.php#56 | /srv/mediawiki/php-1.46.0-wmf.15/extensions/GrowthExperiments/includes/Mentorship/MentorManager.php(56) ]] | GrowthExperiments\Mentorship\MentorManager->getMentorshipStateForUser(MediaWiki\User\User) | #2 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Mentorship/MentorManager.php#66 | /srv/mediawiki/php-1.46.0-wmf.15/extensions/GrowthExperiments/includes/Mentorship/MentorManager.php(66) ]] | GrowthExperiments\Mentorship\MentorManager->isUserIneligibleForMentorship(MediaWiki\User\User) | #3 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Mentorship/MentorManager.php#102 | /srv/mediawiki/php-1.46.0-wmf.15/extensions/GrowthExperiments/includes/Mentorship/MentorManager.php(102) ]] | GrowthExperiments\Mentorship\MentorManager->getMentorUserIdentityIfExists(MediaWiki\User\User, string) | #4 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/HomepageParserFunctions.php#34 | /srv/mediawiki/php-1.46.0-wmf.15/extensions/GrowthExperiments/includes/HomepageParserFunctions.php(34) ]] | GrowthExperiments\Mentorship\MentorManager->getMentorForUserIfExists(MediaWiki\User\User) | #5 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/ParserFunctionsHooks.php#26 | /srv/mediawiki/php-1.46.0-wmf.15/extensions/GrowthExperiments/includes/ParserFunctionsHooks.php(26) ]] | GrowthExperiments\HomepageParserFunctions::mentorRender(MediaWiki\User\UserFactory, GrowthExperiments\Mentorship\MentorManager, MediaWiki\Parser\Parser, string) | #6 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/Parser.php#3421 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/Parser.php(3421) ]] | GrowthExperiments\ParserFunctionsHooks::GrowthExperiments\{closure}(MediaWiki\Parser\Parser, string) | #7 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/Parser.php#3076 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/Parser.php(3076) ]] | MediaWiki\Parser\Parser->callParserFunction(MediaWiki\Parser\PPTemplateFrame_Hash, string, array, bool) | #8 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/PPFrame_Hash.php#267 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/PPFrame_Hash.php(267) ]] | MediaWiki\Parser\Parser->braceSubstitution(array, MediaWiki\Parser\PPTemplateFrame_Hash) | #9 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/Parser.php#2987 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/Parser.php(2987) ]] | MediaWiki\Parser\PPFrame_Hash->expand(MediaWiki\Parser\PPNode_Hash_Tree) | #10 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/PPFrame_Hash.php#267 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/PPFrame_Hash.php(267) ]] | MediaWiki\Parser\Parser->braceSubstitution(array, MediaWiki\Parser\PPTemplateFrame_Hash) | #11 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/PPTemplateFrame_Hash.php#166 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/PPTemplateFrame_Hash.php(166) ]] | MediaWiki\Parser\PPFrame_Hash->expand(MediaWiki\Parser\PPNode_Hash_Tree, int) | #12 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/PPTemplateFrame_Hash.php#178 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/PPTemplateFrame_Hash.php(178) ]] | MediaWiki\Parser\PPTemplateFrame_Hash->getNamedArgument(string) | #13 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/Parser.php#3911 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/Parser.php(3911) ]] | MediaWiki\Parser\PPTemplateFrame_Hash->getArgument(string) | #14 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/PPFrame_Hash.php#284 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/PPFrame_Hash.php(284) ]] | MediaWiki\Parser\Parser->argSubstitution(array, MediaWiki\Parser\PPTemplateFrame_Hash) | #15 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/ParserFunctions/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/ParserFunctions.php#145 | /srv/mediawiki/php-1.46.0-wmf.15/extensions/ParserFunctions/includes/ParserFunctions.php(145) ]] | MediaWiki\Parser\PPFrame_Hash->expand(MediaWiki\Parser\PPNode_Hash_Tree) | #16 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/Parser.php#3421 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/Parser.php(3421) ]] | MediaWiki\Extension\ParserFunctions\ParserFunctions->if(MediaWiki\Parser\Parser, MediaWiki\Parser\PPTemplateFrame_Hash, array) | #17 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/Parser.php#3076 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/Parser.php(3076) ]] | MediaWiki\Parser\Parser->callParserFunction(MediaWiki\Parser\PPTemplateFrame_Hash, string, array, bool) | #18 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/PPFrame_Hash.php#267 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/PPFrame_Hash.php(267) ]] | MediaWiki\Parser\Parser->braceSubstitution(array, MediaWiki\Parser\PPTemplateFrame_Hash) | #19 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/Parser.php#3277 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/Parser.php(3277) ]] | MediaWiki\Parser\PPFrame_Hash->expand(MediaWiki\Parser\PPNode_Hash_Tree) | #20 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/PPFrame_Hash.php#267 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/PPFrame_Hash.php(267) ]] | MediaWiki\Parser\Parser->braceSubstitution(array, MediaWiki\Parser\PPTemplateFrame_Hash) | #21 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/Parser.php#3277 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/Parser.php(3277) ]] | MediaWiki\Parser\PPFrame_Hash->expand(MediaWiki\Parser\PPNode_Hash_Tree) | #22 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/PPFrame_Hash.php#267 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/PPFrame_Hash.php(267) ]] | MediaWiki\Parser\Parser->braceSubstitution(array, MediaWiki\Parser\PPFrame_Hash) | #23 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/Parser.php#2899 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/Parser.php(2899) ]] | MediaWiki\Parser\PPFrame_Hash->expand(MediaWiki\Parser\PPNode_Hash_Tree, int) | #24 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/Parser.php#1537 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/Parser.php(1537) ]] | MediaWiki\Parser\Parser->replaceVariables(string) | #25 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Parser/Parser.php#624 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Parser/Parser.php(624) ]] | MediaWiki\Parser\Parser->internalParse(string) | #26 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Content/WikitextContentHandler.php#375 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Content/WikitextContentHandler.php(375) ]] | MediaWiki\Parser\Parser->parse(string, MediaWiki\Title\Title, MediaWiki\Parser\ParserOptions, bool, bool, null) | #27 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Content/ContentHandler.php#1574 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Content/ContentHandler.php(1574) ]] | MediaWiki\Content\WikitextContentHandler->fillParserOutput(MediaWiki\Content\WikitextContent, MediaWiki\Content\Renderer\ContentParseParams, MediaWiki\Parser\ParserOutput) | #28 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Content/Renderer/ContentRenderer.php#67 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Content/Renderer/ContentRenderer.php(67) ]] | MediaWiki\Content\ContentHandler->getParserOutput(MediaWiki\Content\WikitextContent, MediaWiki\Content\Renderer\ContentParseParams) | #29 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Revision/RenderedRevision.php#246 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Revision/RenderedRevision.php(246) ]] | MediaWiki\Content\Renderer\ContentRenderer->getParserOutput(MediaWiki\Content\WikitextContent, MediaWiki\Page\PageIdentityValue, MediaWiki\Revision\MutableRevisionRecord, MediaWiki\Parser\ParserOptions, array) | #30 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Revision/RenderedRevision.php#219 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Revision/RenderedRevision.php(219) ]] | MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached(MediaWiki\Content\WikitextContent, array) | #31 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Revision/RevisionRenderer.php#225 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Revision/RevisionRenderer.php(225) ]] | MediaWiki\Revision\RenderedRevision->getSlotParserOutput(string, array) | #32 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Revision/RevisionRenderer.php#158 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Revision/RevisionRenderer.php(158) ]] | MediaWiki\Revision\RevisionRenderer->combineSlotOutput(MediaWiki\Revision\RenderedRevision, MediaWiki\Parser\ParserOptions, array) | #33 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Revision/RenderedRevision.php#182 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Revision/RenderedRevision.php(182) ]] | MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}(MediaWiki\Revision\RenderedRevision, array) | #34 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/TemplateData/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Hooks.php#97 | /srv/mediawiki/php-1.46.0-wmf.15/extensions/TemplateData/includes/Hooks.php(97) ]] | MediaWiki\Revision\RenderedRevision->getRevisionParserOutput(array) | #35 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/HookContainer/HookContainer.php#135 | /srv/mediawiki/php-1.46.0-wmf.15/includes/HookContainer/HookContainer.php(135) ]] | MediaWiki\Extension\TemplateData\Hooks->onMultiContentSave(MediaWiki\Revision\RenderedRevision, MediaWiki\User\User, MediaWiki\CommentStore\CommentStoreComment, int, MediaWiki\Storage\PageUpdateStatus) | #36 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/HookContainer/HookRunner.php#2973 | /srv/mediawiki/php-1.46.0-wmf.15/includes/HookContainer/HookRunner.php(2973) ]] | MediaWiki\HookContainer\HookContainer->run(string, array) | #37 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Storage/PageUpdater.php#930 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Storage/PageUpdater.php(930) ]] | MediaWiki\HookContainer\HookRunner->onMultiContentSave(MediaWiki\Revision\RenderedRevision, MediaWiki\User\User, MediaWiki\CommentStore\CommentStoreComment, int, MediaWiki\Storage\PageUpdateStatus) | #38 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Storage/PageUpdater.php#814 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Storage/PageUpdater.php(814) ]] | MediaWiki\Storage\PageUpdater->saveRevision(MediaWiki\CommentStore\CommentStoreComment, int) | #39 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Page/MovePage.php#959 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Page/MovePage.php(959) ]] | MediaWiki\Storage\PageUpdater->saveDummyRevision(string, int) | #40 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Page/MovePage.php#661 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Page/MovePage.php(661) ]] | MediaWiki\Page\MovePage->moveToInternal(MediaWiki\User\User, MediaWiki\Title\Title, string, bool, array) | #41 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/Page/MovePage.php#455 | /srv/mediawiki/php-1.46.0-wmf.15/includes/Page/MovePage.php(455) ]] | MediaWiki\Page\MovePage->moveUnsafe(MediaWiki\User\User, string, bool, array) | #42 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CentralAuth/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/GlobalRename/LocalRenameJob/LocalPageMoveJob.php#111 | /srv/mediawiki/php-1.46.0-wmf.15/extensions/CentralAuth/includes/GlobalRename/LocalRenameJob/LocalPageMoveJob.php(111) ]] | MediaWiki\Page\MovePage->move(MediaWiki\User\User, string, bool) | #43 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CentralAuth/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/GlobalRename/LocalRenameJob/LocalPageMoveJob.php#84 | /srv/mediawiki/php-1.46.0-wmf.15/extensions/CentralAuth/includes/GlobalRename/LocalRenameJob/LocalPageMoveJob.php(84) ]] | MediaWiki\Extension\CentralAuth\GlobalRename\LocalRenameJob\LocalPageMoveJob->movePage(MediaWiki\Title\Title, MediaWiki\Title\Title) | #44 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/EventBus/+blame/refs/heads/wmf/1.46.0-wmf.15/includes/JobExecutor.php#94 | /srv/mediawiki/php-1.46.0-wmf.15/extensions/EventBus/includes/JobExecutor.php(94) ]] | MediaWiki\Extension\CentralAuth\GlobalRename\LocalRenameJob\LocalPageMoveJob->run() | #45 | [[ 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) | #46 | {main} | ==== Impact ==== Unknown ==== Notes ==== This would've been (semi)expected...if `{user}` wasn't a named user, [MT7Z94YB](https://meta.wikimedia.org/wiki/special:Centralauth/MT7Z94YB).
  • T417021: [3days timebox] Verify growthexperiments x1 tables are in sync with the definition on all wikis
    • Task
    Growth recently was surprised by a DB schema discrepancy on x1 (T414474). We would like to verify that: * all `growthexperiments_*` tables on all wikis in `growthexperiments.dblist` match the definitions in [the repo](https://github.com/wikimedia/mediawiki-extensions-GrowthExperiments/tree/master/sql/mysql), * no `growthexperiments_*` table exist on wikis outside of `growthexperiments.dblist`, * the tables are consistent with their SQL definition Before starting this task, we need to enable GrowthExperiments on a couple of wikis, see {T417019}. #dba will likely be able to asisst with the audit. Specific discrepancies are logged as subtasks of this task.
  • T416878: Update Add Link Wikitech documentation
    • Task
    The [Add Link](https://wikitech.wikimedia.org/wiki/Add_Link) Wikitech page contains several information that is no longer up to date. For example, it contains obsolete information on codebase location (see T416877 for more detailed description). Similarly, the instructions on how to run the training no longer apply (as of now, whoever wishes to do that needs to schedule an Airflow DAG on the ML instance). Let's update the #documentation!
  • T416666: Use Codex Field component (with Codex - inline -Message) for Special:CreateAccount validation
    • Task
    **Summary:** As we start working on {T415659} we'd like to rely on existing Codex components and validation props to enable us to run experiments in the account creation space. This task involves updating the Special:CreateAccount page to use Codex Field components that come with built-in props and validation messaging capabilities. **Background:** This work establishes the foundation needed to experiment with: * Feedback patterns during account registration * Interaction patterns for form validation * How the system communicates with and guides people registering on Wikipedia By implementing Codex Field components with inline validation messages, we'll have a flexible base for testing different approaches to user guidance and error messaging in the account creation flow. **Design:** | Before | After | | --- | --- | | {F71701239} | {F71701374} | | {F71701410} | {F71701299} | ####Acceptance Criteria: - [ ] Special:CreateAccount uses Codex Field components for form inputs - [ ] Validation messages use Codex inline Message component - [ ] Component implementation supports experimentation with different validation patterns and messaging - [ ] In addition to changing the dynamically added created messages, it is also approved to change the way errors messages are displayed in HTMLForm in general.
  • T416418: [EPIC] Explore opportunities to guide Temporary Account users toward full account creation
    • Task
    ####User story: As a Temporary Account holder, I want to clearly understand the benefits of creating a full account so that I can decide whether it is worth taking the extra step. As a Temporary Account holder who is starting to contribute repeatedly, I want to understand how creating a full account helps me connect with other editors and be part of the community, so that my contributions feel more meaningful and recognized. ####Background Temporary Accounts lower the barrier to starting an edit, but they also limit our ability to support and retain contributors over time. Temporary Account users cannot receive email, and experienced editors have fewer ways to teach, mentor, or follow up with them. In addition, we do not consistently communicate the benefits of creating a full account, nor do we guide Temporary Account users toward registration at moments when motivation is likely to be highest. Early data from the Temporary Accounts banner suggests there are opportunities to better align messaging, timing, and presentation with user intent and readiness. ####Problem Statement The current experience does not clearly explain why creating a full account is valuable, nor does it prompt users to register at moments that feel relevant and motivating. As a result, many Temporary Account users continue editing without converting, limiting long term engagement, community connection, and retention. ####Higher Level Goal: This work fits under **WikiExperiences 1.8 **: By the end of Q4, achieve a 5 percent overall relative increase in the mobile web account creation completion rate. Success will be measured by at least three controlled experiments, each achieving a minimum 2 percent relative improvement. https://www.mediawiki.org/wiki/Contributors/Account_Creation_Experiments ####Design Exploration Goals We should explore and propose design directions that: - Clearly communicate the benefits of full accounts compared to Temporary Accounts - Reduce cognitive load and confusion in the account creation journey - Identify moments of high motivation where registration prompts feel natural rather than disruptive - Are suitable for iterative experimentation on mobile web ####Key Questions to Explore - What value propositions resonate most with Temporary Account users at different stages of editing? - When are users most receptive to creating an account, for example after a successful edit or receiving positive feedback? - How might messaging differ for first time editors versus repeat Temporary Account editors? - Should this intervention be limited to Temporary Account holders who have demonstrated successful or constructive editing behavior, to avoid encouraging account creation by spammers or vandals?
  • T416324: Embed "Learn more" links within quiz confirmation messages
    • Task
    building off a prompt from peter to "design for curious people" we'd like to suggest to move the "learn more" links from being an //afterthought// to actually link word/s within the validation message that is displayed after answering a quiz question. Before: 1. This term conveys subjective praise rather than neutral description. [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Words_to_watch#Puffery | Learn more ]] 2. The text weighs different perspectives without misleading balance. [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Words_to_watch#Synonyms_for_said | Learn more ]] 3. This term adds the writer’s opinion rather than describing events objectively. [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Words_to_watch#Editorializing | Learn more ]] 4. This term is vague and doesn’t say where the information comes from. [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Words_to_watch#Unsupported_attributions | Learn more ]] 5. This term is a euphemism that avoids direct, clear language. [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Words_to_watch#Euphemisms | Learn more ]] example {F71656898} After: 1. This term conveys [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Words_to_watch#Puffery | subjective praise ]] rather than neutral description. 2. The text weighs [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Words_to_watch#Synonyms_for_said | different perspectives ]] without misleading balance. 3. This term adds [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Words_to_watch#Editorializing | the writer’s opinion ]] rather than describing events objectively. 4. This term is vague and doesn’t say [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Words_to_watch#Unsupported_attributions | where the information comes from ]]. 5. This term is a [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Words_to_watch#Euphemisms | euphemism ]] that avoids direct, clear language. example {F71656901}
  • T416311: HelpPanel Configuration in Community Configuration: Sort Namespaces
    • Task
    **Background**: This is follow-up work to the patch [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CommunityConfiguration/+/1233740 | 1233740 ]] for phabricator task [[ https://phabricator.wikimedia.org/T415288 | T415288: HelpPanel: NamespacesControl component creates a chip when user clicks outside of input ]]. When namespaces are saved, they should be saved in an numerical sorted order. To clarify, the user does _not_ need to see namespaces presented in alphabetical or numerical order after selecting the namespaces and before hitting save. For example, if the user selects the chips "Template," "File talk," and "File," the user will see the chips in the order they are selected. However, if the user selects those chips, hits save, and then reloads the page, the user should see "File," "File talk," and "Template." **Acceptance Criteria**: - [ ] Namespaces are saved in numerically sorted order when a user adds new namespaces via the CommunityConfiguration UI. - [ ] Enforcing numerical order of selected chips before the user hits "save" is not needed
  • T416021: Migrate CreateAccount PHP instrument (from WikimediaEvents) to use TestKitchen SDK
    • Task
    === Description `CreateAccount` instrument is using `EventLogging\MetricsPlatform\MetricsClientFactory` (PHP client library) to get an instance of `MetricsClient` to send events. We are already working on {T409913}, which will be `InstrumentManager#getInstrument()` so, once we finish that task, the mentioned instrument could be migrated to use that new way. === Acceptance criteria [] The instrument config is added to Test Kitchen UI [] [[https://codesearch.wmcloud.org/search/?q=newMetricsClient&files=&excludeFiles=&repos=Extension%3AWikimediaEvents|The instrument]] has been rewritten to use `InstrumentManager#getInstrument() [] The stream config is updated to reflect management via Test Kitchen [] Remove `producers.metrics_platform_client.provide_values` property [] Add a link to the instrument config in Test Kitchen UI
  • T415943: GrowthExperiments: LogicException: revise-tone does not have tip steps defined.
    • Task
    ==== Error ==== * service.version: 1.46.0-wmf.13 * timestamp: 2026-01-29T19:30:25.599Z * labels.phpversion: `8.3.29` * trace.id: `95db5fad-0b6e-4fb4-b620-711de1d4564f` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2026-01-28T19:30:25.599Z',to:'2026-01-29T19:31:15.253Z'))&_a=(query:(query_string:(query:'reqId:%2295db5fad-0b6e-4fb4-b620-711de1d4564f%22'))) | Find trace.id in Logstash ]] ```name=labels.normalized_message,lines=10 [{reqId}] {exception_url} LogicException: revise-tone does not have tip steps defined. ``` | Frame | Location | Call | -- | -- | -- | from | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.13/includes/HelpPanel/Tips/TipLoader.php#82 | /srv/mediawiki/php-1.46.0-wmf.13/extensions/GrowthExperiments/includes/HelpPanel/Tips/TipLoader.php(82) ]] | | #0 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.13/includes/HelpPanel/Tips/TipLoader.php#34 | /srv/mediawiki/php-1.46.0-wmf.13/extensions/GrowthExperiments/includes/HelpPanel/Tips/TipLoader.php(34) ]] | GrowthExperiments\HelpPanel\Tips\TipLoader->getTipTreeForTaskType(string, array) | #1 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.13/includes/HelpPanel/Tips/TipsAssembler.php#50 | /srv/mediawiki/php-1.46.0-wmf.13/extensions/GrowthExperiments/includes/HelpPanel/Tips/TipsAssembler.php(50) ]] | GrowthExperiments\HelpPanel\Tips\TipLoader->loadTipNodes(string, string, array, string) | #2 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.13/includes/Rest/Handler/TipsHandler.php#42 | /srv/mediawiki/php-1.46.0-wmf.13/extensions/GrowthExperiments/includes/Rest/Handler/TipsHandler.php(42) ]] | GrowthExperiments\HelpPanel\Tips\TipsAssembler->getTips(string, string, array, string, string) | #3 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.13/includes/Rest/SimpleHandler.php#41 | /srv/mediawiki/php-1.46.0-wmf.13/includes/Rest/SimpleHandler.php(41) ]] | GrowthExperiments\Rest\Handler\TipsHandler->run(string, string, string, string) | #4 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.13/includes/Rest/Module/Module.php#472 | /srv/mediawiki/php-1.46.0-wmf.13/includes/Rest/Module/Module.php(472) ]] | MediaWiki\Rest\SimpleHandler->execute() | #5 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.13/includes/Rest/Module/Module.php#301 | /srv/mediawiki/php-1.46.0-wmf.13/includes/Rest/Module/Module.php(301) ]] | MediaWiki\Rest\Module\Module->executeHandler(GrowthExperiments\Rest\Handler\TipsHandler) | #6 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.13/includes/Rest/Router.php#485 | /srv/mediawiki/php-1.46.0-wmf.13/includes/Rest/Router.php(485) ]] | MediaWiki\Rest\Module\Module->execute(string, MediaWiki\Rest\RequestFromGlobals) | #7 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.13/includes/Rest/Router.php#444 | /srv/mediawiki/php-1.46.0-wmf.13/includes/Rest/Router.php(444) ]] | MediaWiki\Rest\Router->doExecute(string, MediaWiki\Rest\RequestFromGlobals) | #8 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.13/includes/Rest/EntryPoint.php#207 | /srv/mediawiki/php-1.46.0-wmf.13/includes/Rest/EntryPoint.php(207) ]] | MediaWiki\Rest\Router->execute(MediaWiki\Rest\RequestFromGlobals) | #9 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.13/includes/MediaWikiEntryPoint.php#180 | /srv/mediawiki/php-1.46.0-wmf.13/includes/MediaWikiEntryPoint.php(180) ]] | MediaWiki\Rest\EntryPoint->execute() | #10 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.13/rest.php#25 | /srv/mediawiki/php-1.46.0-wmf.13/rest.php(25) ]] | MediaWiki\MediaWikiEntryPoint->run() | #11 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+blame/refs/heads/master/w/rest.php#3 | /srv/mediawiki/w/rest.php(3) ]] | require(string) | #12 | {main} | ==== Notes ==== Seeing 4 of these immediately after deploying 1.46.0-wmf.13 (T413804) to all wikis.
  • T415912: GrowthExperiments: Wikimedia\NormalizedException\NormalizedException: There was a problem during the HTTP request: 504 Gateway Timeout
    • Task
    ==== Error ==== * service.version: 1.46.0-wmf.12 * timestamp: 2026-01-29T11:03:42.846Z * labels.phpversion: `8.3.29` * trace.id: `29a1ca6a-44b2-4afc-8f7b-ebfc8d8f3c60` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2026-01-28T11:03:42.846Z',to:'2026-01-29T16:25:07.984Z'))&_a=(query:(query_string:(query:'reqId:%2229a1ca6a-44b2-4afc-8f7b-ebfc8d8f3c60%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.46.0-wmf.12/includes/Util.php#193 | /srv/mediawiki/php-1.46.0-wmf.12/extensions/GrowthExperiments/includes/Util.php(193) ]] | | #0 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+blame/refs/heads/wmf/1.46.0-wmf.12/includes/HomepageHooks.php#417 | /srv/mediawiki/php-1.46.0-wmf.12/extensions/GrowthExperiments/includes/HomepageHooks.php(417) ]] | GrowthExperiments\Util::logStatus(MediaWiki\Status\Status) | #1 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.12/includes/HookContainer/HookContainer.php#134 | /srv/mediawiki/php-1.46.0-wmf.12/includes/HookContainer/HookContainer.php(134) ]] | GrowthExperiments\HomepageHooks->onBeforePageDisplay(MediaWiki\Output\OutputPage, MediaWiki\Skins\Vector\SkinVector22) | #2 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.12/includes/HookContainer/HookRunner.php#1022 | /srv/mediawiki/php-1.46.0-wmf.12/includes/HookContainer/HookRunner.php(1022) ]] | MediaWiki\HookContainer\HookContainer->run(string, array, array) | #3 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.12/includes/Output/OutputPage.php#3300 | /srv/mediawiki/php-1.46.0-wmf.12/includes/Output/OutputPage.php(3300) ]] | MediaWiki\HookContainer\HookRunner->onBeforePageDisplay(MediaWiki\Output\OutputPage, MediaWiki\Skins\Vector\SkinVector22) | #4 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.12/includes/Actions/ActionEntryPoint.php#161 | /srv/mediawiki/php-1.46.0-wmf.12/includes/Actions/ActionEntryPoint.php(161) ]] | MediaWiki\Output\OutputPage->output(bool) | #5 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.12/includes/MediaWikiEntryPoint.php#181 | /srv/mediawiki/php-1.46.0-wmf.12/includes/MediaWikiEntryPoint.php(181) ]] | MediaWiki\Actions\ActionEntryPoint->execute() | #6 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.46.0-wmf.12/index.php#44 | /srv/mediawiki/php-1.46.0-wmf.12/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 ==== Noted one of these in 1.46.0-wmf.13 (T413804). Root's fairly unclear, but it doesn't seem like this should be hitting logs.
  • T415623: Explore retraining add-a-link model using first sentence after the lead
    • Task
    **Problem** Currently, [[ https://meta.wikimedia.org/wiki/Machine_learning_models/Production/add-a-link_model | the machine learning model ]] used in the #add-link-structured-task is trained on the first sentence in an article to contain a link. In many articles, this will be the first sentence of the article. However, on many wikis, the rules for linking in the first sentence are different and more permissive than the rules elsewhere. Specifically, [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section#Contextual_links | contextual links ]], which are "links to the broader or more elementary topics that are important to the article's topic or place it into the context where it is notable", are uniquely permitted in the first sentence. @Sdkb hypothesizes that some of the overlinking tendency we have observed with Add-a-Link may be a result of this issue with its training data. **Additional context:** The choice to use the first sentence with a link was originally made to avoid issues with links omitted because they'd be duplicates. i.e. in the phrase `[[Foobar]] blah blah blah. Blah blah foobar blah blah.` we wouldn't want to feed the model the second sentence and give it the impression that [[Foobar]] should not be linked. **Proposed solution** Because the [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Linking#Duplicate_and_repeat_links | rule for duplicate links ]] effectively resets after the lead section, any term that is linked in the lead should be (and typically is) linked as well when it first appears in the article body after the lead. Therefore, training the model on the first sentence after the lead to contain a link should solve the contextual links problem without creating a duplicate links problem. This may improve the model's alignment with linking best practice and cause it to output better suggestions. However, it is also possible that might cause the model to perform worse because of unforeseen reasons. **Challenges** - It is not currently clear how we would evaluate whether or not a change to the model improves its performance. --- //This task is a follow-up to [[ https://docs.google.com/document/d/1EpbeiXLbPra-VvA6JOoqp7ea63o3P5LGEELYlcSn-H8/edit?tab=t.0 | offline discussion ]] between @Sdkb, @KStoller-WMF, and @OKarakaya-WMF.//
  • T415622: Reduce tendency of Add a Link to suggest overlinks
    • Task
    **User story & summary:** As a Wikipedian, I want the "Add a link" task to better align with the Manual of Style (MOS) guidelines and the specific norms of my wiki. Primary concern: The current link suggestion algorithm frequently recommends links of common/generic topics, such as common occupations, languages, geographic features like oceans or continents (Q5107), religions, nationalities, everyday words like "river" or "aircraft", country names (Q6256), etc. These would be considered [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Linking#What_generally_should_not_be_linked | overlinks ]] on many wikis, going against the Manual of Style. We should prevent these suggestions to reduce patroller burden and improve compliance with community standards. T415623 is one possible intervention.
  • T415621: Explore retraining add-a-link machine learning model using only higher-quality articles
    • Task
    Currently, [[ https://meta.wikimedia.org/wiki/Machine_learning_models/Production/add-a-link_model | the machine learning model ]] used in the #add-link-structured-task is trained on all articles on a wiki. However, the degree to which articles on a wiki abide by that wiki's best practices for linking (e.g. [[ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Linking | WP:Manual of Style/Linking ]] at en-WP) varies widely. In particular, many articles in the lower tiers of the [[ https://en.wikipedia.org/wiki/Wikipedia:Content_assessment#Grades | quality assessment scale ]] may not adhere well to best practices. @Sdkb therefore hypothesizes that restricting the model to only train using articles at a higher quality assessment level may improve the model's alignment with linking best practice and cause it to output better suggestions. However, it is also possible that removing lower-quality articles may cause the model to perform worse, either because it would be trained on a smaller data set or because the absence of shorter/lower quality articles in the training data would give it a worse understanding of the type of linking needed on the shorter/lower quality articles where Add-a-Link tends to activate. **Decisions to be made** - Should we restrict the model's training data to use only higher-quality articles? If so, what should be the minimum assessment class for an article to be included in the training data? **Challenges** - It is not currently clear how we would evaluate whether or not a change to the model improves its performance. --- //This task is a follow-up to [[ https://docs.google.com/document/d/1EpbeiXLbPra-VvA6JOoqp7ea63o3P5LGEELYlcSn-H8/edit?tab=t.0 | offline discussion ]] between @Sdkb, @KStoller-WMF, and @OKarakaya-WMF.//
  • T415617: Revise Tone: upon declining suggestion, a highlighted section is displayed again after switching back to VE
    • Task
    found by @Sdkb **Steps to replicate the issue**: * on the desktop, on a wiki with Revise Tone task type enabled, go to an article with a Revise Tone suggestion. The article will show a highlighted section (a paragraph) that need revision * Click "decline" in the Revise tone dialog, select a reason for declining, and click on the Submit button. * Then, switch to the source editor (not making edits) and then back to VE (not making any edits) **What happens?**: - a highlighted text for the Revise tone task appears again **What should have happened instead?**: - if a Revise Tone task is declined, it should not appear anymore. **Software version**: `testwiki wmf.12`
  • T415546: [EPIC] Improve data collection and experiment ergonomics
    • Task
    **Background** > For years the Growth team had an embedded data scientist Morten Warncke-Wang who lead the experimentation spirit of the team and its main product focus, the GrowthExperiments extension. > > That involved building a custom bucketing system to be able to execute A/B tests on newcomer users and also building experiment focused instrumentation and long lived instruments for general product health observability. Over the years many GrowthExperiments-specific analytics schemas were created, custom streams, and more or less generic instrumentation capabilities. All of that great work has helped Growth establish their features as standard newcomer experiences ensuring edit quality and often increasing user activation. > > However, the ever evolving nature of software has left us in a situation where there’s lots of data collection going on in GE that we don’t have the resources to analyze or we deem the interest not worth it. On an audit performed by data analysts and data engineers in early 2025 (SDS 2.4.18: Growth’s instrumentation portfolio audit) 9 out of 15 data collection streams were identified as high risk according to the foundation collection guidelines. Also the adoption of the new experimentation platform de facto standard, Test Kitchen, has shifted the team analytics approach to move away from a lot of manual analysis towards a more balanced mixture of automated and manual analysis. > > In order to keep our team productivity and adapt to the general analytics shift in the foundation, we would benefit from paying some technical debt in the GE extension. In the last three experiments the team has conducted using Test Kitchen (Community updates, Leveling up notifications and Revise tone task), writing the instrumentation has consumed a huge amount of resources and felt like a start from scratch every time. This is an area where many improvements can be made. But this is not just a long term development maintenance issue, it also affects final users whose (private!) data is being collected for no good reason. With this background in mind there are at least three areas of work: - {T375198} - Improve instrumentation ergonomics - Reducing data collection risks - Building experiment and product health dashboards
  • T415356: Overflow menu userpage link loses its tooltip/access key
    • Task
    **Steps to replicate the issue** (include links if applicable): As seen in T415291 * Ensure "Default to newcomer homepage from username link in personal tools" option is enabled in the settings * Go to https://en.wikipedia.org/wiki/Main_Page?useskin=vector-2022 * Move focus to the userpage link ** Observe tooltip shows up: "Your homepage [ ctrl-option-. ]" * Now scroll down until header is replaced with sticky header * Move focus to the userpage link again (which now moves into the overflow menu) **What happens?**: Access key is lost. Tooltip title changed **What should have happened instead?**: They shouldn't change. The userpage link hasn't. This is likely caused by rMW962ad3329b12
  • T415261: Prepare upgrade to justinrainbow/json-schema to 6.x in CommunityConfiguration
    • Task
    For the update of the justinrainbow/json-schema library in core (see parent task) several CommunityConfiguration unit tests are failing in JsonSchemaValidatorTest.php, like the following: ``` 00:01:35.130 1) MediaWiki\Extension\CommunityConfiguration\Tests\JsonSchemaValidatorTest::testValidate with data set "wrong type" (MediaWiki\Extension\CommunityConfiguration\Schema\JsonSchema@anonymous/workspace/src/extensions/CommunityConfiguration/tests/phpunit/unit/Validation/JsonSchemaValidatorTest.php:66$27a Object (), array('baz'), false, array('type'), false, false, array(array('Number', '/Number', 'String value found, but a num...quired', array('type')))) 00:01:35.135 Failed asserting that two arrays are identical. 00:01:35.135 --- Expected 00:01:35.135 +++ Actual 00:01:35.135 @@ @@ 00:01:35.135 Array &0 ( 00:01:35.135 - 0 => 'type' 00:01:35.135 + 0 => Array &1 ( 00:01:35.135 + 'name' => 'type' 00:01:35.135 + 'params' => Array &2 ( 00:01:35.135 + 'found' => 'string' 00:01:35.135 + 'expected' => 'a number' 00:01:35.135 + ) 00:01:35.135 + ) 00:01:35.135 ) 00:01:35.135 00:01:35.135 /workspace/src/extensions/CommunityConfiguration/tests/phpunit/unit/Validation/JsonSchemaValidatorTest.php:359 ``` We should: * figure out if any production code changes are required to make use of the v6 version * figure out how to adjust the tests so that they either work with both v5 and v6 of the library, or disable the tests, do the library update, and then reenable them for v6 * investigate if the new version of the library contains any improvements that we may want to make use of
  • T415205: Remove "Don't show again" from Add an Image onboarding
    • Task
    ####User story & summary: As an editor who completes "Add an Image" Suggested Edits tasks, I want to see the onboarding tips only on my first attempt, so that I can start editing immediately on future tasks without repeating the tutorial or needing to manually opt out. Applies to both "Add an image to an unillustrated article" and "Add an image to an article section" ####Background: {T408544} ####Design: | Before | After | | --- | --- | | {F71584785} | {F71584786} | ####Acceptance Criteria: **AC1: First-time onboarding display** - Given a user initiates an "Add an Image" task for the first time - When the task is initiated - Then the onboarding dialog automatically opens to step 1 without a "Don't show again" checkbox **AC2: Automatic onboarding suppression** - Given a user has previously completed the "Add an Image" onboarding - When they initiate an "Add an Image" task again - Then the onboarding dialog does not automatically open **AC3: User account-level persistence (cross-device/browser)** - Given a user has completed the "Add an Image" onboarding on any device or browser - When they initiate an "Add an Image" task on a different device or browser - Then the onboarding dialog does not automatically open (preference is tied to the user account, not the device) **AC5: Existing users with previous checkbox interaction** - Given an existing user who previously checked "Don't show again" - When they initiate an "Add an Image" task - Then the onboarding dialog does not open (their previous preference is respected) All tasks should also meet the Growth Team’s task completion definition.
  • T415204: Remove "Don't show again" from Add a Link onboarding
    • Task
    ####User story & summary: As an editor who completes "Add a Link" Suggested Edits tasks, I want to see the onboarding tips only on my first attempt, so that I can start editing immediately on future tasks without repeating the tutorial or needing to manually opt out. ####Background: {T408544} ####Design: | Before | After | | --- | --- | | {F71584712} | {F71584714} | ####Acceptance Criteria: **AC1: First-time onboarding display** - Given a user initiates an "Add a Link" task for the first time - When the task is initiated - Then the onboarding dialog automatically opens to step 1 without a "Don't show again" checkbox **AC2: Automatic onboarding suppression** - Given a user has previously completed the "Add a Link" onboarding - When they initiate an "Add a Link" task again - Then the onboarding dialog does not automatically open **AC3: User account-level persistence (cross-device/browser)** - Given a user has completed the "Add a Link" onboarding on any device or browser - When they initiate an "Add a Link" task on a different device or browser - Then the onboarding dialog does not automatically open (preference is tied to the user account, not the device) **AC5: Existing users with previous checkbox interaction** - Given an existing user who previously checked "Don't show again" - When they initiate an "Add a Link" task - Then the onboarding dialog does not open (their previous preference is respected) All tasks should also meet the Growth Team’s task completion definition.
  • T414537: [Timebox 3 days] Revise Tone quiz onboarding + Help Panel animation
    • Task
    ####User Story: As a newcomer completing multiple Revise Tone tasks, I want understand where I can revisit the Revise Tone onboarding in the Help Panel, because it won't display by default on repeat visits. ####Context After the first round of testing and internal feedback, we recommend removing the "Don't show again" checkbox from the revise tone suggested edit quiz-styled onboarding. **Related: ** - {T414245} - {T413368} We've explored using motion to show newcomers where they can retake the quiz. When people dismiss or finish the quiz, it collapse "inside" the help panel via a masking effect. We'd be curious to learn more about engineering feasibility: {F71198049} ####Acceptance Criteria: Complete a research spike and quick POC version to explore the feasibility of adding in animation when the onboarding is complete or dismissed.
  • T414291: Add ability to exclude page targets
    • Task
    **Feature summary**: Allow CommunityConfiguration to set page titles to not link to. Or expand this proposition with more controls, like do not propose targets categorised/marked with some template. Currently we can control only what pages can (not) be edited using suggestions, like "more links" template. **Use case(s)**: Some terms are common or has specific meaning but are added to another topics. Then, some pages are often linked but these links are connecting wrong pages just by name or are redudant. **Benefits** (why should this be implemented?): Do not mislead readers about other definitions of the same word; rely on context. Do not add links not meeting link criteria, in almost random places.
  • T414167: Do not alert about a failed cron job when logs are already discarded
    • Task
    Today, I discovered #growth-team received several `MediaWikiCronJobFailed` alerts. Following the manual at https://wikitech.wikimedia.org/wiki/Mw-cron_jobs#Troubleshooting, I checked the status: ``` [urbanecm@deploy2002 ~]$ kubectl get jobs --field-selector status.successful=0 -l team=growth NAME STATUS COMPLETIONS DURATION AGE growthexperiments-fixlinkrecommendationdata-dryrun-29465720 Running 0/1 96m 96m growthexperiments-listtaskcounts-29465771 Running 0/1 45m 45m growthexperiments-refreshlinkrecommendations-s3-29465427 Running 0/1 6h29m 6h29m growthexperiments-refreshlinkrecommendations-s5-29465787 Running 0/1 14m 14m growthexperiments-updatementeedata-s1-29460615 Failed 0/1 3d14h 3d14h [urbanecm@deploy2002 ~]$ kubectl logs job/growthexperiments-updatementeedata-s1-29460615 mediawiki-main-app unable to retrieve container logs for containerd://ddfbb3217271b9f6fbabd6bbed0a71798c0e1651f9d90949601b7d38ce6519fb[urbanecm@deploy2002 ~]$ ``` This leaves me unable to figure out what actually happened, as I do not have access to the logs anymore. While I understand the need to purge logs, I don't understand: * why we need to do it so quickly (3 days after the job fails), * why we continue to send alerts, despite the failure logs were discarded (and are inaccessible using the documented methods) Would it be possible to sync job deletion timeline with the timeline for dropping the job records? That way, the alert would be actionable when it exists (and continues to fire).
  • T413906: Account creation funnel instrumentation: normalize username in presubmit events
    • Task
    The account creation form funnel was instrumented in T394744. When the user has filled out the form and attempts to create their account, an event is fired with the following data: ``` action = 'click' action_subtype = 'presubmit' action_context = '{user name}' ``` In this event the value of `user name` is pulled directly from the form. This can make it difficult to join this data with other sources (e.g. ServerSideAccountCreation or `user_name` in MediaWiki's `user` table) , because in those the user name follows MediaWiki's naming conventions (e.g. the first character is always capitalized). Desired behaviour: The user name in `action_context` is normalized so it matches other sources.
  • T413370: image-suggestions service is intermittently unstable / timing out
    • Task
    ==== Error ==== * mwversion: 1.46.0-wmf.7 * timestamp: 2025-12-22T16:17:55.538Z * phpversion: `8.3.28` * reqId: `9fc0e2f8-cd27-457d-99d7-0e237ab30825` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2025-12-21T16:17:55.538Z',to:'2025-12-22T16:32:35.160Z'))&_a=(query:(query_string:(query:'reqId:%229fc0e2f8-cd27-457d-99d7-0e237ab30825%22'))) | Find reqId in Logstash ]] * Growth Logstash Dashboard filtered for this error: https://logstash.wikimedia.org/goto/408f78035f3573f57cf345d266dc7f30 ```name=normalized_message,lines=10 GrowthExperiments\NewcomerTasks\AddImage\ServiceImageRecommendationProvider::get: Unable to decode JSON response for page {title}: {response} ``` Actual response from the service: `upstream connect error or disconnect/reset before headers. reset reason: connection timeout` ==== Impact ==== * missing suggestions on Newcomer Homepage and Apps ==== Notes ==== This seems to happen intermittently with long stretches where everything is fine: {F72153961}
  • T413137: Our email confirmation workflow is incompatible with email providers that scan emails and follow links
    • Task
    When you add an email address in preferences, MediaWiki sends you an email asking you to confirm it. The email contains two links, one to Special:ConfirmEmail/<token> and the other to Special:InvalidateEmail/<token>. Following one of these links instantly (on GET request) either confirms or removes the email, and invalidates the token so the links can't be used again. This is a problem when the user's email provider itself follows the links, due to some sort of email scanning. In T411799 we received a report from a user of Yandex that the links don't work, likely for this reason. I couldn't find online documentation about this, but apparently [[ https://www.reddit.com/r/sysadmin/comments/1aurdj1/how_to_stop_o365_from_clicking_on_email_links/ | Office365 will do that as well ]], [[ https://berthub.eu/articles/posts/shifting-cyber-norms-microsoft-post/ | some other Microsoft software will even run JS on the target page ]], and it's something [[ https://supertokens.com/features/email-magic-links#:~:text=Auto%2Dconsumption%20from%20email%20clients | commercial providers of auth systems are aware of ]]. So, single-use or magic links in emails are going to be unusable for some users. Can we do something about this? # We could try to magically detect browsers versus automated tools, and only allow using the links in browsers. This will be unreliable as well. # We could require the user to click through a confirmation form at the target page. This should be reliable but worsens user experience. # We could make the confirmation link only work when logged in. We'd still have to do something about the invalidation link, and it would worsen the user experience (e.g. the user may be signing up on desktop but access their email on their phone). # We could replace the links with one-time codes and a form that requires you to input them (like in the new EmailAuth extension). This would be a slightly worse user experience, and would require us to make the tokens shorter and simpler, but it would be completely reliable. Maybe we could have both links and codes to get the best of both worlds. # We could make the links multi-use (which would require not invalidating the tokens, and keeping the email stashed somewhere when the "invalidate" link is clicked). This should be reliable and won't make the experience any worse, but it's a security trade-off. It would probably be fine if we also reduce the lifetime of the token (currently 7 days, $wgUserEmailConfirmationTokenExpiry). Also worth noting that if the automated scanner clicks the confirmation link, but not the invalidation link, then the user will have their email confirmed without ever proving that they can access the email. I don't know if that's a practical concern. Thoughts? (Bonus relevant tasks: T62434, T387460)
  • T412876: Upgrade justinrainbow/json-schema to 6.x
    • Task
    To make picking up fixes like {T412194} easier in the future, and as {T293710} is stalled... We should probably upgrade justinrainbow/json-schema from 5.3 to 6.x (6.6.3 as of December 2025) --- https://github.com/jsonrainbow/json-schema/blob/main/UPGRADE-6.0.md
  • T412861: CommunityConfiguration structured test should only introduce a soft test-time dependency
    • Task
    CommunityConfiguration has a structured test which asserts a bunch of sensible defaults about Schemas/Providers for which it is extended. Extensions that make use of CommunityConfiguration are strongly encouraged to extend it. However, this test-class is currently implemented as an abstract class which is then extended by a concrete class in the respective repository. The problem is that this introduces a hard dependency on CommunityConfiguration during test-time and that is undesirable. Related tasks: * {T410117} * {T410051}
  • T412832: [QA task] Revise Tone - user editing workflows limitations
    • Task
    Follow up for {T410167} Articles with Revise Tone task have non-trivial user workflow for switching between VE/source editing mode and Revise Tone surface **(1) Publishing non-revise tone edit is not possible ** - go to a Revise Tone article - without interacting with Revise tone suggestion (the highlighted section) or the revise Tone dialog- make an edit - the Publish button is active - click on it **What happened** - the content of an article got dimmed and users cannot proceed with their edits without making decision on the Revise Tone section |{F71089966}| after clicking on publish button {F71089971} **What should happen** - a user should have a clear indication that normal edits are not possible at this point - a user should have guidance how to make normal edits from that state - a user should be able to opt-out from Revise tone task ✅ **DONE ** (re-checked on Jan 26/2026) **(2) Clicking `x` button on mobile produces `Uncaught TypeError: Cannot read properties of null (reading 'getSidebarDialogs')` ** - on mobile go to a Revise tone article - without interacting with Revise tone suggestion (the highlighted section) or the revise Tone dialog - click on `x` button to exit the surface - the following Console error will be displayed: ``` Uncaught TypeError: Cannot read properties of null (reading 'getSidebarDialogs') at OO.EventEmitter.emit at ve.ui.Surface.destroy at ve.init.Target.clearSurfaces at ve.init.mw.MobileArticleTarget.clearSurfaces ``` {F71113272} ✅ **DONE ** ({T414831}) (3) **The counter increases on each exiting & re-entering the Revise tone surface** - go to a Revise Tone article - the highlighted section will display the warning icon (a yellow triangle) and no counter which is a correct behavior - without interacting with Revise tone suggestion (the highlighted section) or the revise Tone dialog - click on `x` button to exit the surface - on the same article click on the pencil button to start editing - Revise Tone surface is displayed and the counter appears {F71113406} - at the bottom non-functional controls are displayed {F71113446} (4) "Before publishing" is displayed when a user tries to publish a normal edit - might be confusing for users what the next steps are: - from Homepage go to a Revise Tone article - without interacting with Revise Tone dialog, make a non-Revise Tone edits - the Publish icon is active - click on it - the surface is dimmed; the Revise Tone dialog is still displayed - "Before publishing" without any additional information is displayed {F71197981} ✅ **DONE ** (per comment https://phabricator.wikimedia.org/T412832) (5) Tags ` Newcomer task Suggested: revise tone` are added for non-Revise Tone edits Ex. https://test.wikipedia.org/w/index.php?title=Lorem_ipsum&diff=704421&oldid=643573
  • T412549: Create a stable way to show ReviseTone Edit Checks
    • Task
    To make the Revise Tone Structured Task work, Growth has extended the ToneCheck class and over time improvised various solutions to make it actually show up in a Visual Editor session. The current state is that we're re-triggering the `surfaceReady` event to make our check show up. ```lang=js if ( this.surfaceReadyHasFired ) { // This triggers the refresh() method in VE's controller.js, which should make our edit check show up // However, if surfaceReady has not yet fired, we do not want to trigger it before the surface is actually ready ve.init.target.emit( 'surfaceReady' ); } ``` This is probably not ideal and has the potential to also trigger a couple of other unexpected side-effects. So in a new change ([fix(ReviseTone): don't emit surfaceReady events to show the tone check](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/1215213)), the proposal is to instead directly call the necessary method on the editcheck controller that became available only recently: ```lang=js ve.init.target.editcheckController.refresh(); ``` While that would so far seem to work well with hopefully minimal side-effects, it is still making use of, and coupling tightly to, an implementation detail of the whole Edit Check. It would be great if we had a way to trigger our new edit check that has been explicitly designated as stable and intended for that purpose. Alternatively, and maybe that makes even more sense, we could more fundamentally re-imagine the way the integration between VE/EditCheck and the Revise Tone Structured Task works. Initially, there was the idea that at the start of a VE session, after the Growth Onboarding had shown, GrowthExperiments would just call a method in VE, or fire an event, with the needed data and then VE would take over and show the edit-check. This did not take off, and so we pivoted to registering our own Edit Check. But maybe that original idea would be worth revisiting in favor of a clearer boundary between teams.
  • T412055: linkrecommendation API does not include the model version in its output
    • Task
    ==== Background As part of {T398950}, @OKarakaya-WMF implemented v2 models into the linkrecommendation service. Those new models allow us to provide recommendations for more wikis than we were able to before. Unfortunately, the API provides no indication of the model version in its output. For example, consider `zhwiki` (which never had a working v1 model; I deleted the actual recommendations to make the output shorter): ``` urbanecm@wmf3345 ~ % curl -s 'https://api.wikimedia.org/service/linkrecommendation/v1/linkrecommendations/wikipedia/zh/%E5%B8%83%E6%8B%89%E6%A0%BC' | jq 'del(.links)' { "links_count": 15, "meta": { "application_version": "7e1c06b", "dataset_checksums": { "anchors": "8f2faa90dbd1c29f1cb925af2f09e199c61e58a5ff284c9c8a9649fa2048e305", "model": "c4796c3c193d983980a445bb2a76f65def9f2459599fa6df055984bd851d3ca3", "pageids": "29c35688a7206c891fcb3d5b3336ee9ae2eb01f54a4704377e79742b4cdc9d41", "redirects": "a4e4ea5402d77bd957f5e8f53016c1b21f33423d1fe9ba8800ee27eae0797a72", "w2vfiltered": "89763b701c921dd9fa6020b89814c9476de774c72dd196109342c0dd0473f408" }, "format_version": 1 }, "page_title": "布拉格", "pageid": 64458, "revid": 89938049 } urbanecm@wmf3345 ~ % ``` The only potentially relevant part of the output is `format_version`, which is hardcoded to 1, and it is documented as "Increment this version only for major changes in the output format" (which the new model release did NOT do). ==== Problem In T412040, I wanted to check how many itwiki recommendations are v1 and how many recommendations are v2. It seems like I'm unable to do so, because there is no straightforward indicator for that. This task asks for one. Such indicator would also allow us to ensure a wiki only has v2 models. At the end, I used the model hashes, which work, but are harder to work with.
  • T411817: [EPIC] Strengthen new editor onboarding, re-engagement, and Mentorship
    • Task
    NOTE: this work isn't currently prioritized, but the task can be used to gather early ideas and subtasks. ####User story As a **new account holder,** I want clear guidance, timely prompts, and access to supportive mentors so that I can understand how to begin editing, make constructive contributions, and feel motivated to return and continue building my skills. As an **experienced editor or Mentor**, I want streamlined tools, timely notifications, and better visibility into newcomer activity so that I can provide meaningful support, connect with mentees at the right moments, and help new editors grow into confident contributors. ####Background & research: This initiative improves how new account holders begin and continue their editing journey on Wikipedia. It focuses on creating a clearer onboarding path, delivering timely and helpful re-engagement communication, and supporting a more effective mentorship experience. The work includes refining early in-product guidance, offering relevant prompts that bring newcomers back to their work, and improving tools that help mentors provide support. The goal is to help new editors understand how to get started, feel confident contributing, and stay connected with the community as they advance their skills.
  • T411559: Mentor sign-up volume choice labels are mathematically unsound
    • Task
    **Steps to replicate the issue** (include links if applicable): * go to [[https://en.wikipedia.org/wiki/Special:EnrollAsMentor|en:Special:EnrollAsMentor]] * (Note: I am unable to see the enrollment page, as I am already a mentor and it shows me my dashboard instead) **What happens?**: * From memory, the sign-up process offers mentors a tripartite division of mentee numbers or activity volume, labeled something like: 'half the average', 'average', and 'twice the average'. This is circular, and the average may drop to 1, or increase indefinitely. **What should have happened instead?**: * It should offer volume labels that do not refer to the average, like, 'low', 'medium', 'high'; or absolute numbers (e.g., 1-10, 11-20, 20-40). Details at [[https://www.mediawiki.org/wiki/Talk:Growth#Mentor_sign-up_volume_choice_labels_are_mathematically_unsound|mw:Talk:Growth]].
  • T411534: Growth help panel overlaps diff tray on mobile
    • Task
    {F70595584} With the Growth help panel enabled, the button for it overlaps with the up arrow which should be presented as part of the new tray on mobile (T402297), enabling users to open the tray. The icon should be positioned above the tray, up from its current position, and should move up when the tray expands so that it's still above it. **Steps to reproduce** * Open a diff in mobile view in a namespace configured as one of the "Namespaces where the help panel is available in reading mode" in [[ https://en.wikipedia.org/wiki/Special:CommunityConfiguration/HelpPanel | CommunityConfiguration ]] * e.g. https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard&diff=prev&oldid=1325492833 * See the Help panel icon overlapping the mobile diff tray
  • T411188: Broken / flaky API test: GET quickstarttips: the copyedit response has the correct shape and parameters substituted
    • Task
    Seen in [this build](https://integration.wikimedia.org/ci/job/quibble-apitests-only-vendor-php81/11101/console) (kept forever): ```counterexample 1) GET quickstarttips the copyedit response has the correct shape and parameters substituted: AssertionError: expected 200 to equal 503 + expected - actual -200 +503 at Context.<anonymous> (tests/api-testing/quickstarttips.js:18:10) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) ``` That’s unfortunately not a lot of detail; the [mw-debug-web.log.gz](https://integration.wikimedia.org/ci/job/quibble-apitests-only-vendor-php81/11101/artifact/log/mw-debug-web.log.gz) is quite long (4.7 million lines) but I’m not sure which error in it is related (if any).
  • T411104: mwscript-k8s makes it challenging to run LoggedUpdateMaintenance across all wikis
    • Task
    === Background `LoggedUpdateMaintenance` is a MediaWiki maintenance script that can be executed only once on each wiki. Generally, a logged update is used for data migrations and similar needs. For example, the Growth team is using it to move mentor away timestamps to Community Configuration (T347152). MediaWiki tracks whether a logged update executed in the `updatelog` table. Each logged update tells MediaWiki whether it finished or not (using the return value of `LoggedUpdateMaintenance::doDBUpdates(): bool`). If a logged update returns `true`, MediaWiki records in `updatelog` table that it finished, and it will not run it again (unless the user forces it using the `--force` parameter). If `false` is returned, MediaWiki will rerun the update if executed again. Some logged updates support dry-run. In that case, `doDBUpdates()` typically returns `false`, as we do want to be able to dry-run it multiple times. More importantly, we want to run the actual update even if a dry run was already executed. `LoggedUpdateMaintenance` returns a non-zero exit code if `doDBUpdates()` returns false. This is because MediaWiki cannot differenciate between "the update decided not to run itself for now" (eg. user only wanted a dry run, which is an expected state) and "the update failed to execute" (an unexpected state). If the update deliberately did not want to execute itself, then that is probably a success (as it did what it wanted) from an exit code's perspective. If the update failed, then a non-zero exit code is definitely warranted. `mwscript-k8s` can be used to execute MediaWiki maintenance script across all wikis in a dblist. For example, running `mwscript-k8s --dblist="growthexperiments" -- Version.php` would execute `Version.php` on all wikis in `growthexperiments.dblist`. Internally, the looping happens in a shell script that looks like this (simplified): ```bash for wiki in ${DBLIST}; do echo "-----------------------------------------------------------------" echo "${wiki}" echo "-----------------------------------------------------------------" ${RUNNER} ${CMD} ${wiki} "${@}" done ``` Unless the `FOREACHWIKI_IGNORE_ERRORS` environment variable is defined, the shell script has `set +e` set, meaning it terminates whenever the maintenance script returns a non-zero exit code on any wiki (or whenever any of the other commands it executes fails, of course). === Problem There are several problems coming out of this that I'll describe in separate subsections. ==== Being difficult to debug Determining that the execution stopped executing because of a non-zero exit code is //extremely// challenging from a MediaWiki developer perspective. The output looked like this: ``` sgimeno@deploy2002:~$ mwscript-k8s -f --comment="T409170" --dblist="growthexperiments" -- GrowthExperiments:migrateMentorStatusAway --dry-run GrowthExperiments:migrateMentorStatusAway: Running on growthexperiments ----------------------------------------------------------------- abwiki ----------------------------------------------------------------- abwiki No mentors found in config, skipping migration. ----------------------------------------------------------------- acewiki ----------------------------------------------------------------- acewiki No mentors found in config, skipping migration. ----------------------------------------------------------------- adywiki ----------------------------------------------------------------- adywiki No mentors found in config, skipping migration. ----------------------------------------------------------------- afwiki ----------------------------------------------------------------- afwiki Nothing new to save, skipping sgimeno@deploy2002:~$ ``` looking like the execution was interrupted midway through with no exception, no error message and no explanation. Initially, I was assuming this is because the k8s pod exhausted resources and was killed by k8s itself, or that the kernel of the underlying machine killed that process because it did something illegal. I ended up exec'ing into the container (when it was running) to access the `foreachwikiindblist` wrapper, and in there, it was quite straightforward to find the `set +e` that is causing this. mwscript-k8s should make it more clear what is happening. Even saying "Skipping the rest of the wikis, because the script returned non-zero exit code for xxwiki" would be wonderful, and it would make the debugging much quicker (as I'd know what to look for inside MediaWiki). Even if I //do// know that the non-zero exit code is the problem, it is impossible to know that setting the `FOREACHWIKI_IGNORE_ERRORS` environment variable would fix this. The documentation at https://wikitech.wikimedia.org/wiki/Maintenance_scripts does not mention this, and neither does any other Wikitech page. ==== LoggedUpdateMaintenance treats all non-executions as a failure `LoggedUpdateMaintenance::doDBUpdates()` documentation says: > Return true to log the update as done or false (usually on failure). I interpret this as "return true if you want the update to be logged, and return false otherwise". For the dry-run scenario, I do not want the update to be logged, so returning false seems to be following the documentation. I treat the "usually on failure" part as advisory (saying that I should probably return false on failures, but //not// saying that returning false outside of a failure is an issue). `LoggedUpdateMaintenance::execute()` is then copying the return value of `doDBUpdate()`. However, the documentation for that function (coming from `Maintenance::execute`) is much stricter, as it says: > True for success, false for failure. Returning false for failure will cause doMaintenance.php to exit the process with a non-zero exit status. In other words, even though `doDBUpdate()` might return false in a success scenario (such as "dry run finished"), `LoggedUpdateMaintenance` is considering that as a failure, even though the documented interface doesn't back that assumption. Ideally, for expected non-executions, `LoggedUpdateMaintenance::execute` would return true, resulting in an exit code of zero, resulting in `mwscript-k8s` iterating through the rest of the wikis, as expected. ==== Lack of documentation I'm not sure how stable `FOREACHWIKI_IGNORE_ERRORS` is, or whether it is something internal the infrastructure has in the background. Regardless of the answer, https://wikitech.wikimedia.org/wiki/Maintenance_scripts should make it clear that: * `mwscript-k8s` with `--dblist` will stop iterating whenever an error is encouraged, * that it is possible to ignore errors (if the executor wishes to do so); whether that happens by setting `FOREACHWIKI_IGNORE_ERRORS` or by a parameter to `mwscript-k8s`, that is up to further discussion
  • T410830: CommunityConfiguration feature names do not support localization
    • Task
    **Steps to replicate the issue** (include links if applicable): * Enable a CommunityConfig feature, such as how Extension:AbuseFilter [[https://gerrit.wikimedia.org/g/mediawiki/extensions/AbuseFilter/+/e45f241cda261849edcc9f34b6345f27d753bcc9/extension.json#358|does it with BlockedDomain]] * Set your wiki to have a different default language than English * Try to localize the phrase "BlockedDomain" **What happens?**: There is no way to localize it. You can localize the name of CommunityConfiguration special page, but not the name of the specific feature. For instane, if your wiki contnet language is French, then `[[Special:CommunityConfiguration/BlockedDomain]]` becomes `[[Spécial:Configuration_communautaire/BlockedDomain]]` and there is no way for you to localize the `BlockedDomain` part, in the same manner that you can localize the namespace ("Spécial") and the Special Page name ("Configuration_communautaire"). **What should have happened instead?**: It should be allowed for wikis to localize the name of community config features through an alias. This helps with the readability and understandability of the URLs, especially in wikis whose content language is not a Latin-based language (think Arabic, Japanese, etc.) In the case of the BlockedDomain use case, this will require changes both to #mediawiki-extensions-communityconfiguration and #abusefilter codebases.
  • T410666: Visiting Special:Homepage is not recognised on urwiki
    • Task
    NOTE: The issue was hotfixed in production by removing the offending alias from `GrowthExperiments.aliases.php`. The underlying issue was **not** fixed. There is a Patch Demo instance (https://be7f4471b8.catalyst.wmcloud.org/) which allows the issue to be reproduced (standard `Patch Demo` / `patchdemo1` credentials should work). **Steps to replicate the issue** (include links if applicable): * On https://ur.wikipedia.org as a Homepage-enabled user, click the username link in the top right corner. * Alternatively, visit https://ur.wikipedia.org/wiki/Special:Homepage. **What happens?**: {F70303536} **What should have happened instead?**: Homepage is rendered!
  • T410544: Dashboard for tracking CTR for Growth's "48 hour" newcomer notifications
    • Task
    Follow up to: {T407431} **User Story: ** As the Growth team, I want reliable product health metrics that track engagement with newcomer notifications, so I can understand which messages draw interest and lead to clicks or taps. **Acceptance Criteria:** Create an analytics dashboard that displays the aggregate CTR for each of the following notifications: - Get started - Re-engage - Keep going In dashboard description provide a short definition of each notification audience, or link to: T407431 //Example descriptions:// - Get Started: at 48 hours, delivered to users with 0 edits - Keep Going: at 48 hours, delivered to users who have completed 0 suggested edits, but at least one edit, and less edits than max (max configured in Community Configuration) - Re-engage: at 48 hours, delivered to users who have completed at least 1 suggested edit, but less than max (max configured in Community Configuration) **Notes:** * we need to figure out the right stream in xLab/TestKitchen for that -> consult docs / Experimentation Platform team * The instrumentation code used for the experiment is in [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/GrowthExperiments/+/fdc6ca1576f0b4b82f72bf5eb168b02a5dd59e55/modules/ext.growthExperiments.NotificationsTracking/EchoNotificationsTracker.js | ext.growthExperiments.NotificationsTracking/EchoNotificationsTracker.js ]] and is still configured for the experiment, see [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/GrowthExperiments/+/master/modules/ext.growthExperiments.NotificationsTracking/index.js#13 | ext.growthExperiments.NotificationsTracking/index.js#13 ]], hence not collecting data . We need to change the config to follow a long-lived setup, see [[ https://wikitech.wikimedia.org/wiki/Test_Kitchen/Measure_product_health | Test_Kitchen/Measure_product_health ]] *
  • T410459: CommunityConfiguration has a hack to truly disable fields via onCommunityConfigurationSchemaBeforeEditor
    • Task
    While working on {T407818}, I noticed the following lines of code in `GrowthExperiments:includes/Config/CommunityConfigurationHooks.php`: ```lang=php public function onCommunityConfigurationSchemaBeforeEditor( IConfigurationProvider $provider, array &$rootSchema ) { switch ( $provider->getId() ) { // [...] case 'GrowthSuggestedEdits': if ( !$this->config->get( 'GELinkRecommendationsFrontendEnabled' ) ) { // HACK: for T370611. This should be removed asap, ideally before end of August 2024. $rootSchema['properties']['link_recommendation']['properties']['disabled']['disabled-true-hack-T370611'] = true; } break; // [...] } } ``` Equivalent hack is present in `CommunityConfiguration:resources/ext.communityConfiguration.Editor/lib/json-form/controls-codex/src/controls/BooleanControl.vue`. Because of the [Tim Starling's law](https://bash.toolforge.org/quip/AU7VTzhg6snAnmqnK_pc), this solution outlived the time annotation it has in the comment (to remove before the end of August 2024). Given that was well over a year ago, I'm filling this task to decide about the future of this hack. Originally, it was introduced because of {T370611}, where we needed to disable a checkbox, but keep it visible in the wikipage. Unfortunately, we would need UI schemas (T370534) for this to be easily possible, which we still do not have. I'm not sure if the original plan was to implement UI schemas prior to August 2024, or to eventually settle for some other solution.
  • T410458: ChangeWikiConfig.php maintenance script drops $version from the provider
    • Task
    **Steps to replicate the issue** (include links if applicable): * On a wiki where both `CommunityConfiguration` and `CommunityConfigurationExample` is available, delete `MediaWiki:CommunityConfigurationExample.json` * Go to `Special:CommunityConfiguration/CommunityConfigurationExample` and hit Save changes (without actually changing anything); the goal is to populate the page with default values * In the command line, run `php maintenance/run.php CommunityConfiguration:ChangeWikiConfig --summary 'test' CommunityConfigurationExample CCExample_Numbers.IntegerNumber 10` **What happens?**: The script changed `CCExample_Numbers.IntegerNumber` to 10 and dropped `$version` **What should have happened instead?**: Only the requested change was made; `$version` is included in the wikipage.
  • T410386: Prompt user to create a regular account after temp account creation rate limit trip
    • Task
    ####User story & summary: as a logged-out editor from an IP address that has hit the temp account creation rate limit, i want to be prompted to create a regular account or log in before i invest time editing so that i can successfully publish my changes without losing my work. ####Background & research: when this limit is hit, users cannot publish their edits via temp accounts, which creates a dead-end if we don't intervene early. right now, the system allows users to edit, which means they may invest significant time making changes only to discover at publish time that they cannot proceed without creating a regular account. this creates frustration at a critical conversion moment. additionally, the current implementation shows competing messages simultaneously (rate limit warnings alongside BLP notices and other article-specific communications), which creates visual clutter and makes it difficult for users to understand what action they need to take. ####Design: we suggest to introduce a modal that appears when the rate limit is hit, so that we can: - create a stronger separation of concerns between user-relevant authentication information and article-relevant notices - prevent users from investing time in edits they cannot publish - provide a clear path forward (create account or log in) at the moment when it's most actionable - reduce frustration by setting expectations upfront design specs https://www.figma.com/design/3irzISNEYik483LXUreJf5/T357802-prompt-user-to-create-a-regular-account-after-temp-account-rate-limit?node-id=155-1662&t=UdQJcvyNvEuZHWkZ-1 {F70274381} ####Acceptance Criteria: **Given** a logged-out user from an IP address that has already created 6 temp accounts in the past 24 hours **When** they click edit on an article **Then** the system checks whether their IP has hit the temp account creation rate limit before loading the editor **Given** a user has dismissed or bypassed the initial rate limit modal (if we implement the "show twice" approach) **When** they attempt to publish their edit **Then** the modal appears again before the publish dialog, preventing them from proceeding without creating an account or logging in ####Open questions: - Should we should the modal once or twice? - Should we disclose additional information inside as an accordion or styled as caption and visible at all times?
  • T410168: Flaky test: link inspector can be used to accept/reject links and save an article
    • Task
    Seen at https://integration.wikimedia.org/ci/job/quibble-with-gated-extensions-selenium-php81/12109/console: ```counterexample 20:51:53 1) Add a Link 20:51:53 link inspector can be used to accept/reject links and save an article.: 20:51:53 Error: The following error originated from your application code, not from Cypress. It was caused by an unhandled promise rejection. 20:51:53 20:51:53 > An unknown error has occurred: undefined 20:51:53 20:51:53 When Cypress detects uncaught errors originating from your application it will automatically fail the current test. 20:51:53 20:51:53 This behavior is configurable, and you can choose to turn this off by listening to the `uncaught:exception` event. 20:51:53 20:51:53 https://on.cypress.io/uncaught-exception-from-application 20:51:53 at makeErrFromObj (http://127.0.0.1:9413/__cypress/runner/cypress_runner.js:77560:10) 20:51:53 at errorFromProjectRejectionEvent (http://127.0.0.1:9413/__cypress/runner/cypress_runner.js:77869:10) 20:51:53 at Object.errorFromUncaughtEvent (http://127.0.0.1:9413/__cypress/runner/cypress_runner.js:77874:65) 20:51:53 at <unknown> (http://127.0.0.1:9413/__cypress/runner/cypress_runner.js:142033:66) ``` prior art: {T304011}
  • T410117: ReportIncident PHPUnit tests fail when CommunityConfiguration is not present
    • Task
    ReportIncident extension does not require CommunityConfiguration in `extension.json`. Running the PHPUnit tests fail with: ``` ```counterexample PHP Fatal error: Uncaught Error: Class "MediaWiki\Extension\CommunityConfiguration\Tests\SchemaProviderTestCase" not found in extensions/ReportIncident/tests/phpunit/integration/Config/ReportIncidentSchemaProviderTest.php:12 ``` ``` #0 vendor/phpunit/phpunit/src/Util/FileLoader.php(66): include_once() #1 vendor/phpunit/phpunit/src/Util/FileLoader.php(49): PHPUnit\Util\FileLoader::load() #2 vendor/phpunit/phpunit/src/Framework/TestSuite.php(398): PHPUnit\Util\FileLoader::checkAndLoad() #3 vendor/phpunit/phpunit/src/Framework/TestSuite.php(537): PHPUnit\Framework\TestSuite->addTestFile() #4 tests/phpunit/suites/ExtensionsTestSuite.php(37): PHPUnit\Framework\TestSuite->addTestFiles() #5 tests/phpunit/suites/ExtensionsTestSuite.php(46): ExtensionsTestSuite->__construct() #6 [internal function]: ExtensionsTestSuite::suite() #7 vendor/phpunit/phpunit/src/Framework/TestSuite.php(486): ReflectionMethod->invoke() #8 vendor/phpunit/phpunit/src/TextUI/TestSuiteMapper.php(84): PHPUnit\Framework\TestSuite->addTestFile() #9 vendor/phpunit/phpunit/src/TextUI/Command.php(393): PHPUnit\TextUI\TestSuiteMapper->map() #10 vendor/phpunit/phpunit/src/TextUI/Command.php(114): PHPUnit\TextUI\Command->handleArguments() #11 vendor/phpunit/phpunit/src/TextUI/Command.php(99): PHPUnit\TextUI\Command->run() #12 vendor/phpunit/phpunit/phpunit(107): PHPUnit\TextUI\Command::main() #13 vendor/bin/phpunit(122): include('...') #14 {main} ``` See also {T410051}
  • T410051: Babel tests fail when CommunityConfiguration is not present
    • Task
    #mediawiki-extensions-babel does not require CommunityConfiguration in `extension.json. Running the PHPUnit tests fail though: ``` 16:16:37 1) Babel\Tests\Unit\ConfigWrapperTest::testReturnsArray 16:16:37 PHPUnit\Framework\MockObject\UnknownTypeException: Class or interface "MediaWiki\Extension\CommunityConfiguration\Access\MediaWikiConfigRouter" does not exist 16:16:37 16:16:37 /workspace/src/tests/phpunit/MediaWikiTestCaseTrait.php:63 16:16:37 /workspace/src/extensions/Babel/tests/phpunit/unit/ConfigWrapperTest.php:15 16:16:37 ``` ``` 16:16:37 2) Babel\Tests\Unit\ConfigWrapperTest::testRelaysHas 16:16:37 PHPUnit\Framework\MockObject\UnknownTypeException: Class or interface "MediaWiki\Extension\CommunityConfiguration\Access\MediaWikiConfigRouter" does not exist 16:16:37 16:16:37 /workspace/src/tests/phpunit/MediaWikiTestCaseTrait.php:63 16:16:37 /workspace/src/extensions/Babel/tests/phpunit/unit/ConfigWrapperTest.php:29 16:16:37 ``` Those tests should be skipped when CommunityConfiguration is not present with `markTestSkippedIfExtensionNotLoaded( 'CommunityConfiguration' )` Note `tests/phpunit/integration/maintenance/MigrateConfigToCommunityTest.php` extends `MediaWiki\Extension\CommunityConfiguration\Tests\SchemaProviderTestCase` so I don't think we can make it skippable. See also {T410117}
  • T409953: Beta Wikis have no Revise Tone tasks that would have a topic
    • Task
    We currently have Revise Tone enabled to beta wikis, where the Growth team is testing it and making sure it works as expected. The tasks were manually generated and based on `tone.json` subpage. However, none of those tasks have a topic associated. This results in an odd experience for the tester, as tasks without topics are uncommon on production wikis. Recently, @Dyolf77_WMF was confused by this when testing Revise Tone on arwiki betalabs. There are two solutions we can consider: 1. Generate the suggestions in a real-ish way on beta, working with actual articles 2. Manually associate the tasks with certain topics The first solution is more desirable in the long term. It also matches what we do with Add Link (populated via the [publicly available Add Link API](https://api.wikimedia.org/service/linkrecommendation/)) and Add Image (where we use the `action=query&prop=growthimagesuggestiondata` API from the corresponding production wiki). If we want a short-term fix, the second solution might be appropriate (running `CirrusSearch:UpdateWeightedTags` with correct args should work well enough, cf. [developer documentation](https://www.mediawiki.org/wiki/Extension:GrowthExperiments/developer_setup#Seeding_article_topics)).
  • T409466: Clean up crutches added for Revise Tone A/B test
    • Task
    For the A/B test of the Revise Tone feature, we added several workarounds and makeshift changes to behavior that should not be part of the code long-term, but should be removed after they are no longer needed. This task aims to enumerate these so that we can remove them eventually: * `\GrowthExperiments\Config\Providers\SuggestedEditsConfigProvider::loadForNewcomerTasks` * `\GrowthExperiments\HomepageModules\SuggestedEdits::getJsData` * Remove `growthexperiments-revise-tone-treatment-initiated` user option (was only used during the experiment to add the new revise tone task to the user's selected tasks once)
  • T409463: Accessing user options of arbitrary users via UserOptionsManager results in a memory leak
    • Task
    The #growth-team is currently working with two memory leak tasks: * {T395893} * {T404804} After some investigations, I was able to come up with a simple maintenance script that successfully OOMs: ```lang=php <?php namespace GrowthExperiments\Maintenance; use MediaWiki\Maintenance\Maintenance; use MediaWiki\User\UserIdentityLookup; use MediaWiki\User\UserOptionsManager; $IP = getenv( 'MW_INSTALL_PATH' ); if ( $IP === false ) { $IP = __DIR__ . '/../../..'; } require_once "$IP/maintenance/Maintenance.php"; class TestUOM extends Maintenance { private UserIdentityLookup $userIdentityLookup; private UserOptionsManager $userOptionsManager; private function initServices(): void { $this->userIdentityLookup = $this->getServiceContainer()->getUserIdentityLookup(); $this->userOptionsManager = $this->getServiceContainer()->getUserOptionsManager(); } public function execute() { $this->initServices(); $userIdentities = iterator_to_array( $this->userIdentityLookup->newSelectQueryBuilder() ->registered() ->where( [ 'actor_user < 50000' ] ) ->fetchUserIdentities() ); $this->output( 'Processing ' . count( $userIdentities ) . ' user identities...' . PHP_EOL ); foreach ( $userIdentities as $userIdentity ) { $value = $this->userOptionsManager->getOption( $userIdentity, 'userjs-testing-T395893' ); $this->output( sprintf( '%s-%s', $userIdentity->getId(), $value ?? '(none)' ) . PHP_EOL ); } } } $maintClass = TestUOM::class; require_once RUN_MAINTENANCE_IF_MAIN; ``` Verification that it runs out of memory: ``` [urbanecm@deploy2002 ~]$ mwscript-k8s -f --file=TestUOM.php -- /data/TestUOM.php --wiki=testwiki ℹ️ Your job will run on PHP 8.3 (T405955). If you encounter a compatibility issue, you can use --php_version 8.1 to explicitly select 8.1. ⏳ Starting /data/TestUOM.php on Kubernetes as job mw-script.codfw.lduu6ib3 ... 🚀 Job is running. 📜 Streaming logs: Processing 49176 user identities... 4382-(none) 17638-(none) 40964-(none) 40976-(none) 10149-(none) 40792-(none) 827-(none) 40977-(none) 40978-(none) [...] [urbanecm@deploy2002 ~]$ kubectl get pods -l job-name=mw-script.codfw.lduu6ib3 NAME READY STATUS RESTARTS AGE mw-script.codfw.lduu6ib3-hkc4g 0/3 OOMKilled 0 96s [urbanecm@deploy2002 ~]$ ``` This pinpoints the root cause to UserOptionsManager (or its callees), as this script does not make any other actions besides making a DB query and calling UserOptionsManager::getOption() repetatively. Upon examining the code, I suspect that `UserOptionsManager::$cache` is unbounded in size, and thus can consume as much memory as it needs.
  • T409236: [EPIC] Account Creation Experiments (WE1.8 FY 25-26)
    • Task
    ####Description: This project focuses on a comprehensive review and redesign of the account creation experience on Wikimedia wikis. Account creation is the first interaction many potential contributors have with Wikipedia, and the current flow is outdated, cluttered, and can create confusion. For logged-out users, dense text, multiple warnings, pop-ups, and a complex interface can discourage registration. For logged-in users, Special:CreateAccount serves dual purposes—creating accounts for oneself versus creating accounts for others—which can lead to confusion, unintentional duplicates, and a user experience that diverges from common web conventions. The goal of this project is to modernize the interface, clarify workflows, reduce friction, and ensure that account creation behaves as expected for all user types while maintaining necessary functionality for trusted users. ####Strategic Alignment: This project supports the [[ https://www.mediawiki.org/wiki/Contributors/Strategy | Contributor Strategy ]] by improving the earliest interactions in the contribution funnel. A clearer, modernized account creation experience strengthens clarity, engagement, and motivation for new contributors. This work sits under the WMF FY25-26 Annual Plan Wiki Experiences 1 Objective: - Contributions increase because volunteers are offered compelling opportunities and understand their impact. Account Creation experiments are tracked under Wiki Experiences 1.8 Key Result: - By the end of Q4, achieve a 5 percent relative increase in the mobile web account creation completion rate, supported by at least three controlled experiments that each deliver a minimum 2 percent relative improvement within their target audience. - Details: https://www.mediawiki.org/wiki/Contributors/Account_Creation_Experiments ####User Stories: **As a newcomer,** - I want a clear, simple, and welcoming account creation process so that I can register easily and start editing without confusion. - I want to understand the benefits of creating an account (e.g., tracking edits, receiving notifications, connecting with mentors) so that I feel motivated to complete registration. - I want appropriately timed prompts to appear when I try to edit while logged out so that I can create an account without interrupting my workflow. - I want a streamlined interface with minimal warnings and pop-ups so that I don’t feel overwhelmed or discouraged from completing registration. **As an experienced editor, ** - I want to be able to create accounts for other users (e.g., for editathons or rate limited IPs) so that I can support contributors efficiently. - I want the system to make clear when I am creating a new account for someone else versus modifying my own account so that I avoid accidental duplicate accounts. **As a temporary account holder, ** - I want guidance and encouragement to convert my temporary account into a full account so that I can access a personal Homepage and continue contributing without losing my progress ####Opportunities to explore: - Modernize and clarify the account creation experience - Simplify the interface for logged-out and logged-in users - Make the design mobile-friendly and visually clear - Reduce cognitive overload by removing unnecessary text, warnings, and pop-ups - Explain benefits of account creation, such as edit tracking, notifications, and mentorship - Audit logged-in user flows on Special:CreateAccount - Identify pain points and confusion for users creating accounts for themselves or others - Explore design solutions that prevent accidental duplicate account creation while preserving functionality for trusted users (e.g., event organizers) - Align the experience with standard web UX patterns - Experiment with engagement strategies for new users - Streamline the “create an account” entry point from the logged-out editing view - [In consideration]Test in-context prompts when users attempt to edit while logged out - [In consideration] Surface account creation on mobile. - [In consideration] Encourage Temporary Accounts to convert to regular accounts - [In consideration] Investigate ways to reduce the negative impact of IP blocks on good-faith newcomers - [In consideration] Experiment further with surfacing editing opportunities to engaged readers. ####Measurement // This is an early draft of early ideas, a measurement plan will be drafted for specific experiments.// **Primary Metric** - Increase the percentage of users who successfully create an account (measured via controlled experiments). **Guardrail Metrics** - Edit completion rate for temporary accounts and newly registered regular accounts - Drop-off rate at each step of the account creation flow (e.g., landing on form → submitting → email verification) - Error rate or form validation failures (to detect UX friction or confusion) - Incidents of accidental duplicate accounts created by logged-in users **Leading Indicators** - Number of account creation form impressions - Form submission success rate - Time to complete the account creation process (average for logged-out vs. logged-in users) - Bounce rate from account creation landing page - User-reported clarity or satisfaction (via QuickSurvey or other feedback tools) ####Longer-Term Vision: This project is the first step in creating a more intentional and supportive contributor journey. By modernizing and improving the account creation experience, we can more smoothly transform initial curiosity into sustained engagement. ####Related Community Discussions: - [[ https://www.mediawiki.org/wiki/Talk:Growth#c-Mathglot-20251128095300-Temporary_editors | enwiki discussion about Growth features / Mentorship for Temp accounts ]]. "There are IP editors who are very reliable, senior, and experienced, and have been on the project for many years, and even help out very effectively at the en:WP:Teahouse, en:WP:Help desk, and other forums with good advice for new editors, registered or not." ####Instructions for developer local testing - In order to do local testing of the account creation form changes, the below conditions are needed: -- `mpo=we-1-8-account-creation-form-v2:treatment` or `mpo=we-1-8-account-creation-form-v2:control` -- the skin needs to be Minerva -- the wiki DB name needs to match enwiki [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/WikimediaEvents/+/refs/changes/43/1269543/2/includes/CreateAccount/ExperimentHooks.php#50 | source ]] - In order to do local testing of displaying a user account icon button in the mobile web header, the below conditions are needed: -- `mpo=we-1-8-mobile-account-menu:treatment` or `mpo=we-1-8-mobile-account-menu:control` -- the skin needs to be Minerva - In order to do local testing of the toasts displayed to a temp user after an edit, the below conditions are needed. -- run the override in the console, mw.testKitchen.overrideExperimentGroup( 'we-1-8-tempuser-post-edit', 'treatment') or mw.testKitchen.overrideExperimentGroup( 'we-1-8-tempuser-post-edit', 'control') -- the skin needs to be Minerva -- the screen width must be less than 639 pixels
  • T409171: Change mentor status away primary data source reading to config
    • Task
    This is step 3 from the parent task. In this task we should enable the reading of the mentor status away timestamp from user options to configuration and monitor things work as expected. **Acceptance criteria** - [] Mentor status away is read from config when the flag `GEMentorshipReadFromConfigAwayTimestampEnabled` is enabled
  • T409138: Investigate strategies to reduce prevalence of erroneous add-a-link suggestions of proper noun homonyms
    • Task
    #add-link-structured-task suggestions sometimes prompt erroneous links of proper noun homonyms (particularly people and places), such as to a [[Jane Smith]] who was a writer when the actual link was referencing a Jane Smith who was a swimmer. Newcomers often do not recognize that the entities referenced are different, and add an erroneous link as a result. This task captures the work of reducing the prevalence of this phenomenon. Potential strategies include: - Education in the onboarding or interface to help make newcomers aware of this risk. - Machine learning improvements to make more context-aware link suggestions more likely to go to the right entity - Machine learning improvements to help the model understand which links are most likely to be homonyms, and either not suggesting these or flagging them for newcomers as requiring extra caution (this could perhaps involve looking at the presence of hatnotes or linked disambiguation pages) - Community Configuration settings to enable editors to turn off suggestions to types of entities where the phenomenon is particularly bad ---- //This task was inspired by feedback from English Wikipedia, primarily [[ https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Classical_Greece_and_Rome#Erroneous_%22link_suggestions%22 | here ]], [[ https://en.wikipedia.org/wiki/Wikipedia_talk:Growth_Team_features#People's_names_-_not_a_good_idea_in_this_project | here ]], and [[ https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#c-Certes-20260806175600-MMiller_(WMF)-20260806165300 | here ]].//
  • T408568: Archived questions to your mentor don't allow you to continue the conversation
    • Task
    Archived messages to the Mentor are based on a `oldid` parameter rather than on a permalink. This causes mentees to access a message they can't respond to. Sometimes, mentors archive their talk page after a very short period of time, shorter than the return time of the newcomer. At my Hompeage, I want to access an old topic so that I can continue the conversation. {F67976241} I'm given this link: `https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:Trizek&`**`oldid=216850560`**`#Question_de_Trizek_(WMF)_(16_juillet_2024_%C3%A0_14:53)` When I access this link, I see my previous message, but I get this error message above it: {F67976530} Clicking OK doesn't reload the page. Reloading the page doesn't solve the issue, as the page is reloaded with the URL that has the oldid. (Tracked at {T408569}) Now that we have permalinks, we should use those permalinks instead, by removing the oldid. Note: this couldn't solve some cases where permalinks aren't applied or aren't working.
  • T408544: Display unstructured Suggested Edits onboarding on first use only
    • Task
    ####User story & summary: As an editor who completes Suggested Edits tasks (eg. "Copyedit", "Find references"), I want to see the onboarding only on my first attempt at each task type, so that I can start editing immediately on future tasks without repeating the quick start tips. {F65825220} ####Design: N/A ####Acceptance Criteria: **AC1: First-time onboarding display** Given a user initiates a unstructured suggested edit for the first time (eg. "Find references") When the task is initiated Then the onboarding dialog automatically opens to step 1 **AC2: Onboarding suppression for completed task types** Given a user has previously completed onboarding for a specific task type (eg. "Find references") When they initiate the same task type again Then the onboarding dialog does not automatically open **AC3: Cross-device and cross-browser sync** Given a user has completed onboarding for a task type on one device/browser When they initiate the same task type on a different device or browser Then the onboarding dialog does not automatically open (preference is tied to the user account, not the device) **AC4: Independent task type preferences** Given a user has completed onboarding for one task type (eg. "Find references") When they initiate a different task type (eg. "Copyedit") for the first time Then the onboarding dialog opens normally for the new task type All tasks should also meet the Growth Team’s task completion definition.
  • T408106: Flaky test: POST and GET requests to /growthexperiments/v0/user-impact/{user}
    • Task
    Failure seen in https://integration.wikimedia.org/ci/job/quibble-apitests-only-vendor-php81/5504/console (kept forever): ```counterexample 1) POST and GET requests to /growthexperiments/v0/user-impact/{user} GET: Data loaded for mocked user 1 via static user impact lookup (see GrowthExperiments.LocalSettings.php): TypeError: Cannot read properties of undefined (reading 'Foo') at Context.<anonymous> (tests/api-testing/user-impact.js:68:39) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) ```
  • T407871: Mentor dashboard: M1 mentee overview: Make it possible to manually trigger data update
    • Task
    Proposed improvement based on discussion on T293447#7430891 **User job story** (As a mentor) **When** I go to check on my mentees.... **I want** the information on my mentees to be as up-to-date as possible... **so that** I can take action to help them in a more timely fashion. A specific situation may be being able to see that the user data is 2.5hrs old, one may refresh to more recent info and see that there's a mentee question posted 5 minutes ago that if answered now has more opportunity to be seen. **Proposed design** * An indicator from T293454 shows the last updated data in the Mentee overview module: `Last updated # min ago` * Next to that indicator, refresh icon button is shown next to the last updated indicator, which when selected brings up a dialog to confirm that the mentor wants to refresh the data * The confirmation dialog has text explaining that the data will refresh in the background and could take a few minutes. There are two buttons to either `Cancel` or to proceed to `Refresh mentee data`. * If `Refresh mentee data` is selected the dialog will close to show the mentee module with last updated data until the data update is complete. [mocks TBC]
  • T407359: Do newcomers only/primarily edit articles lead sections on the Minerva skin?
    • Task
    When newcomers open a suggested edit with the Minerva skin, the system automatically opens a "quick tips" dialog. Inside this dialog there is a notice that says "Ready? Open the section you want to edit and tap the pencil icon." but once the dialog is closed, there is a pulsing dot on the edit button that leads to edit only the lead section of the article. I'd be curious to measure across suggested edits how many newcomers only try to edit the lead section, and potentially miss the notice in the quick tips dialog. {F66752422}
  • T407338: Refactor Util.php to allow to inject services
    • Task
    All `GrowthExperiments\Util` methods are `static` and many of them make calls to `MediaWikiServices::getInstance()` to get specific services making them non suitable for use in some parts of the code. An example of this is `VariantHooks::onResourceLoaderGetConfigVars` where the same method from the utils `Util::useMetricsPlatform` is replicated in `VariantHooks::useMetricsPlatform` due to this indirection. This task is to refactor the Util class and convert it into an inject-able GrowthExperiments service so it can be easily re-used across the extension. There are some methods that could/should conveniently remain static if their callers require it. **Acceptance criteria** - [] `GrowthExperiments\Util` can be injected as a service - [] At least one static method from `GrowthExperiments\Util` that does not require to be static is refactored and its callers updated
  • T407336: Header buttons inside the quick tips dialog look inactive/disabled
    • Task
    **Steps to replicate the issue** (include links if applicable): * Go to `Special:Homepage` * Launch a suggested edit (that is not a structured task) * Quick tips dialog opens **What happens?**: The icons of the buttons inside the header of the full-screen dialog (on mobile) or floating dialog (on desktop) appear grey. The buttons look inactive/disable. **What should have happened instead?**: The icons should not have reduced opacity, so that their existing black / `color-base` / `#202122` color is fully visible **Other information** (browser name/version, screenshots, etc.): {F66752087}
  • T407149: Add a Link: improve clarity for newcomers when task is no longer available
    • Task
    ####User story & summary: As a newcomer, I want to clearly understand why a task I was successfully completing is no longer available and know what I can do next, so that I feel supported in continuing to edit. ####Background & research: Newcomers often appreciate access to easy tasks like Add a Link, which help them build confidence and editing experience. However, when they “graduate” and lose access to this task, the current notification may feel abrupt or unclear. While it is designed to celebrate a milestone, it does not provide enough context or next steps, leaving some newcomers confused about why the change occurred or what to do next. [[ https://de.wikipedia.org/wiki/Wikipedia_Diskussion:Neulings-Startseite#c-Isderion-20251013094700-Johannnes89-20251013085400 | Feedback from dewiki discussion ]]: ~translations: > ...he also doesn't understand why he can't make simple edits anymore. I took a look at the interface and can see why. There, I can no longer select "simple edits," and the only reason I get is "5 edits, congratulations! The available edit suggestions have changed." This text should be changed. > Regarding text: He sees that he can no longer make simple edits, but doesn't know exactly why. "5 edits, congratulations! The available edit suggestions have changed." doesn't explain it (well, in my humble opinion). Something like "Due to your progress (5 edits), simple edits are no longer available" would explain it better. ####Design: [[ |Figma designs]] ####Acceptance Criteria: - Review the current notification flow and copy. - Propose updated copy that remains concise and celebratory while providing clearer guidance on why the task is no longer available.
  • T407134: Modify the instructions for suggested tasks to inform new users about the use of genAI
    • Task
    [[https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Demande_d%27intervention_sur_un_message_syst%C3%A8me#MediaWiki:???_%E2%80%93_T%C3%A2ches_pour_novices|From this fr.wp feedback]]: Some newcomers use GenAI to work on suggested tasks, while this is prohibited by certain wikis. "Going back is not pleasant, either for patrollers because it is particularly time-consuming, or for new contributors because they are acting in good faith." The suggestion is to add the case of genAI usage to the onboarding messages. We also need to take into account that no all communities have a strict policy against genAI usage.
  • T406761: Add option to Tone Check decline survey for quotes
    • Task
    In T389443, we implemented the initial Tone Check decline survey that offers people the following choices to explain why they have opted //not// to revise the Tone when prompted: 1. `The tone is appropriate` 2. `I'm not sure how to revise the tone` 3. `Other` This task involves the work of adding a response to that survey (described below). This suggestion is a response to the ML and Growth Teams coming to learn via T401968 that there are likely to be cases when the Tone Check model suggests that people revise the tone of a direct quote which is not aligned with what Wikipedia policy prescribes. - In an [[ https://docs.google.com/spreadsheets/d/1JOYu7fbBsqRGD-uTcXKR82F4LI51UKHrKzrigd3ClWA/edit?gid=279022996#gid=279022996 | internal review of enwiki suggestions ]], approximately 30% of suggestions included direct quotes. The Growth and Machine Learning teams plan to implement improvements to better filter out these cases. However, because the formatting of quotations on wiki varies widely, it is unlikely that all direct quotes can be excluded. === Story As a newcomer who is being prompted to revise the tone of text I've added to an article (or someone else did previously), I want to be able to decline doing so in cases where the text in question includes a direct quote so that I can make edits that align with Wikipedia policies and demonstrate this intention to other editors who might be reviewing this choice I've made. === Requirements # Add – what would become – a fourth option within the decline survey that reads: “This text is part of a direct quote” ## //Note: the `Other` response should continue to appear as the bottom-most option in the decline survey.// --- NOTE: the Editing Team will prioritize work on this task //after// T387918 concludes
  • T406414: Make "Special:Home_page" on en.Wikipedia
    • Task
    **Feature summary** [[Special:Home page]] on en.Wikipedia should work as an alias or (soft?) redirect to [[Special:Homepage]]. **Use case(s)** [[Special:Homepage]] is particularly targeted at new users; who are likely to misremember the page name as [[Special:Home page]] (with a space); particularly if they are familiar with [[Special:Main page]] (again, note space). Experienced users who mentor new users may also misremember the title, for similar reasons. This may apply also to projects other than en.Wikipedia, particularly if they also use English; or for other projects where the translated name of the equivalent page uses two concatenated words. **Benefits** (why should this be implemented?):
  • T405963: Consider running GrowthExperiments:graduateEligibleMentees maintenance script periodically
    • Task
    ==== Background & problem In {T403563}, we implemented mentee graduation feature, which allows communities to graduate experienced users from mentorship. This feature evaluates on edit, opting out the editor if they pass the configured edit threshold. However, the configured threshold consists of two parts: minimum editcount and minimum tenure. This means that a new user can meet the conditions //either// by making an edit or by waiting, depending on which one of the conditions needs to be met. ==== Solution This can be easily resolved by running the `GrowthExperiments:graduateEligibleMentees` maintenance script periodically (every week or so).
Prev
1
2
3
Next
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits