Impact Module: improvements for former newcomers
Open, Stalled, HighPublic3 Estimated Story Points
Actions

Assigned To

Authored By

	KStoller-WMF
	Jul 11 2023, 4:59 PM

Description

User story & summary:

As a former new editor, I want to the Impact module to remain relevant as I edit more, so that I can continue to use it.

Background & research:

This task is important because ideally the homepage and impact module will remain relevant to editors as they continue to edit and deepen their involvement in the Wikimedia movement.

Due to performance reasons, the impact module surfaces the last 1,000 edits you made. This number is used to determine your longest streak as well.

The impact module main audience is newcomers. We designed this impact module with the average number of edits and days of presence of typical newcomers. This is why the numbers aren't reflecting the edits of very active users.

Example of how the Impact Module edit cap impacts the Impact Module for a highly-active editors:

Screenshot 2025-03-17 at 4.16.01 PM.png (590×874 px, 60 KB)

(Thanks is capped, the Longest streak only applies to the last 1,000 edits, and the Recent Activity graph is limited to only the last 1,000 edits).

The Wikipedia Mobile apps are interested in potentially using Impact Module data for: T371946: [Epic] Wikipedia Year in Review on iOS App .
However, they would ideally like the upper limit increased to make this data more meaningful for app users.

Potential Improvements:

There are many different improvements we could consider:

Increase the underlying query to a higher upper limit: 10,000?

Screenshot 2023-07-11 at 9.55.25 AM.png (782×690 px, 92 KB)

Acceptance Criteria:

Given I'm a logged in editor,
When I visit my Homepage or Impact module,
Then Impact module data includes my last (10,000?) edits

Release and test on beta: beta eswiki
On one pilot wiki (enwiki): increase the Impact Module data cap to a higher but reasonable limit 10,000 edits / 1,000 Thanks - June 1, 2025
Monitor the change, and rollout to all wikis if there aren't performance concerns - June 8, 2025

Details

Subject	Repo	Branch	Lines +/-
[Growth] enwiki: Decrease wgGEUserImpactMaxEdits to 1000	operations/mediawiki-config	master	+0 -1
[Growth] Move Impact limit configuration to ext-GrowthExperiments	operations/mediawiki-config	master	+10 -10
Growth: Configure higher impact module edit limits for english and test wiki	operations/mediawiki-config	master	+10 -0
Show actual limit value in Impact Module instead of hardcoded "999+"	mediawiki/extensions/GrowthExperiments	master	+38 -3
Growth-Beta: Configure higher Impact Module edit limits for pilot wikis	operations/mediawiki-config	master	+9 -0
Make Impact Module edit limit configurable for pilot testing	mediawiki/extensions/GrowthExperiments	master	+96 -32

Customize query in gerrit

Related Objects
Search...

Status	Subtype	Assigned	Task
Open		None	T316699 [EPIC] Growth: Positive reinforcement - Iteration 2
Stalled		Cyndymediawiksim	T341599 Impact Module: improvements for former newcomers
Open		None	T388558 Impact Module: Improvements and stats for experienced editors
Open	Feature	None	T391808 Line graph should have scale in Special:Impact
Open		None	T398500 [timebox: 3 days] Impact module: Support larger wgGEUserImpactMaxEdits

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

KStoller-WMF lowered the priority of this task from High to Medium.Mar 29 2025, 10:09 PM

KStoller-WMF moved this task from Backlog to Up Next on the Growth-Team board.

KStoller-WMF set the point value for this task to 3.Mar 31 2025, 3:57 PM

Cyndymediawiksim claimed this task.Apr 16 2025, 8:17 AM

Cyndymediawiksim edited projects, added Growth-Team (Current Sprint); removed Growth-Team.

Change #1136961 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/extensions/GrowthExperiments@master] Increase Impact Module edit limit from 1000 to 10000

https://gerrit.wikimedia.org/r/1136961

gerritbot added a project: Patch-For-Review.Apr 16 2025, 8:38 AM

Change #1136986 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[operations/mediawiki-config@master] Growth: Configure higher Impact Module edit limits for testwiki pilot

https://gerrit.wikimedia.org/r/1136986

Cyndymediawiksim moved this task from Incoming to Code Review on the Growth-Team (Current Sprint) board.Apr 16 2025, 12:35 PM

Michael merged a task: T352347: Impact Module: increase data cap.Apr 29 2025, 2:47 PM

Michael added a subscriber: A_smart_kitten.

Raising/adjusting the cap for Thanks revealed another challenge: The value that we show if the user has exceeded the cap is currently a fixed i18n message that in english reads 999+, as can be seen in the screenshot:

Currently, this message show regardless of the actual value of the cap. While it would still be technically correct if the cap were 10,000, it would still be strange if last week I had 9975 Thanks received, and then I look again today, and I'm seemingly "down" to 999+. How big of an issue is this?

We probably can change this message from 999+ to $1+ in en.json, which would change it in practice to 1,000+ or 10,000+ (with comma like the max edit count) when displayed (with a slight logic adjustment). Is that ok, and can other languages work with that? I wonder if @KStoller-WMF (as the PO), @Amire80 (as a language expert), or @Urbanecm_WMF (as a steward) have opinions/thoughts/insights/advice on how to move forward here.

We probably can change this message from 999+ to $1+ in en.json, which would change it in practice to 1,000+ or 10,000+ (with comma like the max edit count) when displayed (with a slight logic adjustment).

This sounds OK to me, but admittedly I'm not an expert on localization or internationalization.
I suggest we keep this simple, as the number of users who will see this message will be quite low once the data cap is increased.

Change #1136961 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Make Impact Module edit limit configurable for pilot testing

https://gerrit.wikimedia.org/r/1136961

ReleaseTaggerBot added a project: MW-1.44-notes (1.44.0-wmf.28; 2025-05-06).May 2 2025, 3:00 PM

Mathglot subscribed.May 5 2025, 11:16 PM

Change #1136986 merged by jenkins-bot:

[operations/mediawiki-config@master] Growth-Beta: Configure higher Impact Module edit limits for pilot wikis

https://gerrit.wikimedia.org/r/1136986

Mentioned in SAL (#wikimedia-operations) [2025-05-06T13:07:22Z] <tgr@deploy1003> Started scap sync-world: Backport for [[gerrit:1141700|CommonSettings: Document wmfGetPrivilegedGroups usage]], [[gerrit:623147|Revert "Add .well-known/matrix for wikimedia.org" (T223835 T261531)]], [[gerrit:1141034|core-Permissions: add move-subpages to enwiki templateeditor user group (T393167)]], [[gerrit:1136986|Growth-Beta: Configure higher Impact Module edit limits for pilot wikis (T341599)]], [[

Stashbot mentioned this in T261531: Configure subdomain foundation.wikimedia.org to enable *:foundation.wikimedia.org Matrix user IDs.May 6 2025, 1:07 PM

Stashbot mentioned this in T393167: [enwiki] Grant move-subpages to template editor user group.

Stashbot mentioned this in T223835: Configure wikimedia.org to enable *:wikimedia.org Matrix user IDs.

Mentioned in SAL (#wikimedia-operations) [2025-05-06T13:25:32Z] <tgr@deploy1003> Finished scap sync-world: Backport for [[gerrit:1141700|CommonSettings: Document wmfGetPrivilegedGroups usage]], [[gerrit:623147|Revert "Add .well-known/matrix for wikimedia.org" (T223835 T261531)]], [[gerrit:1141034|core-Permissions: add move-subpages to enwiki templateeditor user group (T393167)]], [[gerrit:1136986|Growth-Beta: Configure higher Impact Module edit limits for pilot wikis (T341599)]], [

Maintenance_bot removed a project: Patch-For-Review.May 6 2025, 1:31 PM

Change #1143108 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/extensions/GrowthExperiments@master] Show actual limit value in Impact Module instead of hardcoded "999+"

https://gerrit.wikimedia.org/r/1143108

gerritbot added a project: Patch-For-Review.May 7 2025, 2:08 PM

Change #1143108 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Show actual limit value in Impact Module instead of hardcoded "999+"

https://gerrit.wikimedia.org/r/1143108

Maintenance_bot removed a project: Patch-For-Review.May 8 2025, 3:31 PM

ReleaseTaggerBot added a project: MW-1.45-notes (1.45.0-wmf.1; 2025-05-13).May 8 2025, 4:00 PM

Sgs raised the priority of this task from Medium to High.May 9 2025, 10:25 AM

Sgs moved this task from Code Review to QA on the Growth-Team (Current Sprint) board.

Testing notes:

I don't have a Beta account with >1,000 edits, but I found an account with over 300,000 total edits on beta. However, I'm still only seeing the last 1,000 edits:
https://en.wikipedia.beta.wmflabs.org/wiki/Special:Impact/Selenium_user

Screenshot 2025-05-09 at 3.16.28 PM.png (1×918 px, 80 KB)

In T341599#10808810, @KStoller-WMF wrote:

However, I'm still only seeing the last 1,000 edits:

That's expected, apologies we didn't communicate that the bump was only made in beta eswiki to 10000. See for instance Special:Impact/SGimeno. I'm creating "test edits" with my user now to get closer to the threshold, but at least we can see it higher than 1000 which was the original cap.

Random note: I casually stumbled into the fact that Special:Impact is translated to Especial:Incidencia. Incidencia means incident in spanish. Which is far from the correct meaning for the page. Is this something to rise with the community? Or maybe @IZapico-WMF can make the change if it's not problematic?

This is stalled for now on T394785: Slow queries on finding articles created by a given user in GrowthExperiments which would become worse if raise the limit in production.

KStoller-WMF moved this task from Blocked / Needs Work to Incoming on the Growth-Team (Current Sprint) board.May 27 2025, 4:45 PM

Cyndymediawiksim moved this task from Incoming to QA on the Growth-Team (Current Sprint) board.May 28 2025, 4:05 PM

In T341599#10776858, @Michael wrote:

Raising/adjusting the cap for Thanks revealed another challenge: The value that we show if the user has exceeded the cap is currently a fixed i18n message that in english reads 999+, as can be seen in the screenshot:

Currently, this message show regardless of the actual value of the cap. While it would still be technically correct if the cap were 10,000, it would still be strange if last week I had 9975 Thanks received, and then I look again today, and I'm seemingly "down" to 999+. How big of an issue is this?

We probably can change this message from 999+ to $1+ in en.json, which would change it in practice to 1,000+ or 10,000+ (with comma like the max edit count) when displayed (with a slight logic adjustment). Is that ok, and can other languages work with that? I wonder if @KStoller-WMF (as the PO), @Amire80 (as a language expert), or @Urbanecm_WMF (as a steward) have opinions/thoughts/insights/advice on how to move forward here.

AFAIK, the thin non-breaking space separator is used for big numbers in Russia (and some other countries use a period)) - e.g. 10 000; the space is not so commonly used for smaller that 10,000, but it'd be ok to see, e.g. 1 000. Maybe one of the reason to use 999+ message was to avoid getting big numbers display in different formats?

In T341599#10872879, @Etonkovidova wrote:

In T341599#10776858, @Michael wrote:

Raising/adjusting the cap for Thanks revealed another challenge: The value that we show if the user has exceeded the cap is currently a fixed i18n message that in english reads 999+, as can be seen in the screenshot:

Currently, this message show regardless of the actual value of the cap. While it would still be technically correct if the cap were 10,000, it would still be strange if last week I had 9975 Thanks received, and then I look again today, and I'm seemingly "down" to 999+. How big of an issue is this?

We probably can change this message from 999+ to $1+ in en.json, which would change it in practice to 1,000+ or 10,000+ (with comma like the max edit count) when displayed (with a slight logic adjustment). Is that ok, and can other languages work with that? I wonder if @KStoller-WMF (as the PO), @Amire80 (as a language expert), or @Urbanecm_WMF (as a steward) have opinions/thoughts/insights/advice on how to move forward here.

AFAIK, the thin non-breaking space separator is used for big numbers in Russia (and some other countries use a period)) - e.g. 10 000; the space is not so commonly used for smaller that 10,000, but it'd be ok to see, e.g. 1 000. Maybe one of the reason to use 999+ message was to avoid getting big numbers display in different formats?

This is supposed to "just work" in a localized fashion. That is, it should use "," as the thousands-separator in English, "." in German, and the correct space in Russian. It is supposed to use the same logic as for the number of edits and other localized numbers.

In T341599#10875396, @Michael wrote:

In T341599#10872879, @Etonkovidova wrote:

In T341599#10776858, @Michael wrote:

Raising/adjusting the cap for Thanks revealed another challenge: The value that we show if the user has exceeded the cap is currently a fixed i18n message that in english reads 999+, as can be seen in the screenshot:

Currently, this message show regardless of the actual value of the cap. While it would still be technically correct if the cap were 10,000, it would still be strange if last week I had 9975 Thanks received, and then I look again today, and I'm seemingly "down" to 999+. How big of an issue is this?

We probably can change this message from 999+ to $1+ in en.json, which would change it in practice to 1,000+ or 10,000+ (with comma like the max edit count) when displayed (with a slight logic adjustment). Is that ok, and can other languages work with that? I wonder if @KStoller-WMF (as the PO), @Amire80 (as a language expert), or @Urbanecm_WMF (as a steward) have opinions/thoughts/insights/advice on how to move forward here.

AFAIK, the thin non-breaking space separator is used for big numbers in Russia (and some other countries use a period)) - e.g. 10 000; the space is not so commonly used for smaller that 10,000, but it'd be ok to see, e.g. 1 000. Maybe one of the reason to use 999+ message was to avoid getting big numbers display in different formats?

This is supposed to "just work" in a localized fashion. That is, it should use "," as the thousands-separator in English, "." in German, and the correct space in Russian. It is supposed to use the same logic as for the number of edits and other localized numbers.

Yes, it works just as you said. Adding ?uselang= will display different format for different languages (username obscured):

English	German	Russian/Spanish

Monitor the change, and rollout to all wikis if there aren't performance concerns

Is this part done? I thought this was still only being tested on pilot wikis and beta wikis?

In T341599#10882195, @KStoller-WMF wrote:

Monitor the change, and rollout to all wikis if there aren't performance concerns

Is this part done? I thought this was still only being tested on pilot wikis and beta wikis?

Thank you, that's right - I forgot about that requirement. Re-opening and moving to Test in Production.

KStoller-WMF updated the task description. (Show Details)Jun 4 2025, 4:24 PM

Moving to Blocked / Needs Work:
This needs to be released at eswiki to test the impact on performance.

KStoller-WMF updated the task description. (Show Details)Wed, Jun 18, 2:27 PM

KStoller-WMF moved this task from Blocked / Needs Work to Incoming on the Growth-Team (Current Sprint) board.

KStoller-WMF added a subscriber: Sdkb.

Cyndymediawiksim moved this task from Incoming to Doing on the Growth-Team (Current Sprint) board.Mon, Jun 30, 10:41 AM

Change #1164979 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[operations/mediawiki-config@master] Growth: Configure higher impact module edit limits for english and test wiki

https://gerrit.wikimedia.org/r/1164979

gerritbot added a project: Patch-For-Review.Mon, Jun 30, 10:50 AM

Cyndymediawiksim moved this task from Doing to Code Review on the Growth-Team (Current Sprint) board.Mon, Jun 30, 10:51 AM

Change #1164979 merged by jenkins-bot:

[operations/mediawiki-config@master] Growth: Configure higher impact module edit limits for english and test wiki

https://gerrit.wikimedia.org/r/1164979

Mentioned in SAL (#wikimedia-operations) [2025-07-01T13:10:25Z] <urbanecm@deploy1003> Started scap sync-world: Backport for [[gerrit:1164979|Growth: Configure higher impact module edit limits for english and test wiki (T341599)]]

Mentioned in SAL (#wikimedia-operations) [2025-07-01T13:13:00Z] <urbanecm@deploy1003> urbanecm, cyndywikime: Backport for [[gerrit:1164979|Growth: Configure higher impact module edit limits for english and test wiki (T341599)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-07-01T13:29:36Z] <urbanecm@deploy1003> Finished scap sync-world: Backport for [[gerrit:1164979|Growth: Configure higher impact module edit limits for english and test wiki (T341599)]] (duration: 19m 10s)

Maintenance_bot removed a project: Patch-For-Review.Tue, Jul 1, 1:31 PM

Trizek-WMF added a project: User-notice.Tue, Jul 1, 3:21 PM

Trizek-WMF updated the task description. (Show Details)

Change #1165865 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[operations/mediawiki-config@master] [Growth] Move Impact limit configuration to ext-GrowthExperiments

https://gerrit.wikimedia.org/r/1165865

Change #1165866 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[operations/mediawiki-config@master] [Growth] enwiki: Decrease wgGEUserImpactMaxEdits to 1000

https://gerrit.wikimedia.org/r/1165866

Change #1165865 merged by jenkins-bot:

[operations/mediawiki-config@master] [Growth] Move Impact limit configuration to ext-GrowthExperiments

https://gerrit.wikimedia.org/r/1165865

Change #1165866 merged by jenkins-bot:

[operations/mediawiki-config@master] [Growth] enwiki: Decrease wgGEUserImpactMaxEdits to 1000

https://gerrit.wikimedia.org/r/1165866

Mentioned in SAL (#wikimedia-operations) [2025-07-02T12:48:57Z] <urbanecm@deploy1003> Started scap sync-world: Backport for [[gerrit:1165865|[Growth] Move Impact limit configuration to ext-GrowthExperiments (T341599)]], [[gerrit:1165866|[Growth] enwiki: Decrease wgGEUserImpactMaxEdits to 1000 (T398418 T341599)]]

Mentioned in SAL (#wikimedia-operations) [2025-07-02T12:51:16Z] <urbanecm@deploy1003> urbanecm: Backport for [[gerrit:1165865|[Growth] Move Impact limit configuration to ext-GrowthExperiments (T341599)]], [[gerrit:1165866|[Growth] enwiki: Decrease wgGEUserImpactMaxEdits to 1000 (T398418 T341599)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-07-02T12:58:40Z] <urbanecm@deploy1003> Finished scap sync-world: Backport for [[gerrit:1165865|[Growth] Move Impact limit configuration to ext-GrowthExperiments (T341599)]], [[gerrit:1165866|[Growth] enwiki: Decrease wgGEUserImpactMaxEdits to 1000 (T398418 T341599)]] (duration: 09m 42s)

Maintenance_bot removed a project: Patch-For-Review.Wed, Jul 2, 1:31 PM

Urbanecm_WMF mentioned this in T398500: [timebox: 3 days] Impact module: Support larger wgGEUserImpactMaxEdits.Wed, Jul 2, 8:03 PM

Urbanecm_WMF mentioned this in T398506: EventBus throws TypeError: array_map(): Argument #2 ($array) must be of type array, int given when the event is too large.Wed, Jul 2, 8:32 PM

I move this as "not ready to announce" as it is still on the works. Please move it back to "backlog" when ready!

Thanks for adding me as a subscriber on this, Kirsten. I think many more experienced editors will be glad to see this feature. Raising the cap to 10,000 is unlikely to be high enough to produce meaningful data for a lot of folks, though, as many active editors have significantly more edits than that.

Raising the cap to 10,000 is unlikely to be high enough to produce meaningful data for a lot of folks, though, as many active editors have significantly more edits than that.

Thanks for the feedback!

The data cap primarily affects metrics calculated and displayed for the past 60 days. While we know there are a few prolific contributors who may exceed 10,000 edits during that period, the number impacted should be much smaller than the group we were previously “missing” under the 1,000-edit cap.

That said, we are also in discussions with the Data Engineering team about contributor data needs. Ideally, we would have easier access to cached contributor metrics in the future, rather than continuing to rely on the custom Impact metrics built by the Growth team for the Impact Module. So hopefully in the future we can explore adding in other metrics or increasing the data cap further.

Hello @KStoller-WMF,
For Tech News - What wording would you suggest as the content, and when should it be included? Thanks!

Michael added a subtask: T398500: [timebox: 3 days] Impact module: Support larger wgGEUserImpactMaxEdits.Wed, Jul 9, 7:44 PM

@UOzurumba: Please note that this is currently not enabled anywhere except test-wiki, and that it is fully blocked on T398500: [timebox: 3 days] Impact module: Support larger wgGEUserImpactMaxEdits which is not in our current sprint.

In T341599#10989732, @Michael wrote:

@UOzurumba: Please note that this is currently not enabled anywhere except test-wiki, and that it is fully blocked on T398500: [timebox: 3 days] Impact module: Support larger wgGEUserImpactMaxEdits which is not in our current sprint.

Thank you!

	F61412700: Screenshot 2025-06-02 at 1.10.24 PM.png
	Jun 3 2025, 11:02 PM

	F61412818: Screenshot 2025-06-03 at 2.51.30 PM.png
	Jun 3 2025, 11:02 PM

	F61412808: Screenshot 2025-06-03 at 2.51.05 PM.png
	Jun 3 2025, 11:02 PM

	F61413260: Screenshot 2025-06-03 at 4.00.15 PM.png
	Jun 3 2025, 11:02 PM

	F59833508: Screenshot 2025-05-09 at 3.16.28 PM.png
	May 9 2025, 10:18 PM

	F58855696: Screenshot 2025-03-17 at 4.16.01 PM.png
	Mar 17 2025, 11:22 PM

	F57461550: Screenshot 2024-09-04 at 3.06.42 PM.png
	Sep 4 2024, 10:16 PM

	F37136168: Screenshot 2023-07-11 at 9.55.25 AM.png
	Jul 11 2023, 4:59 PM

Impact Module: improvements for former newcomersOpen, Stalled, HighPublic3 Estimated Story PointsActions