⚓ T393771 Send a notification to newcomers when Add a link edit threshold is reached

⚓ T393771 Send a notification to newcomers when Add a link edit threshold is reached
Page Menu
Phabricator
Create Task
Maniphest
T393771
Send a notification to newcomers when Add a link edit threshold is reached
Closed, Resolved
Public
2 Estimated Story Points
Actions
Edit Task
Edit Related Tasks...
Create Subtask
Edit Parent Tasks
Edit Subtasks
Merge Duplicates In
Close As Duplicate
Edit Related Objects...
Edit Commits
Edit Mocks
Mute Notifications
Protect as security issue
Assigned To
Cyndymediawiksim
Authored By
Sgs
May 9 2025, 11:20 AM
2025-05-09 11:20:24 (UTC+0)
Tags
GrowthExperiments-NewcomerTasks
(Backlog)
Add-Link-Structured-Task
(Backlog)
Growth-Structured-Tasks
Growth-Team (Current Sprint)
(Blocked / Needs Work)
MW-1.45-notes (1.45.0-wmf.12; 2025-07-29)
Referenced Files
F65741971: try_other1_edits.gif
Aug 12 2025, 3:06 PM
2025-08-12 15:06:23 (UTC+0)
F62706450: CleanShot 2025-06-30 at 10.31.03.png
Jun 30 2025, 8:35 AM
2025-06-30 08:35:11 (UTC+0)
F62706426: CleanShot 2025-06-30 at 10.31.03.png
Jun 30 2025, 8:35 AM
2025-06-30 08:35:11 (UTC+0)
F62631612: Screenshot 2025-06-27 at 3.24.15 PM.png
Jun 28 2025, 12:09 AM
2025-06-28 00:09:28 (UTC+0)
F62631602: Screenshot 2025-06-27 at 2.27.31 PM.png
Jun 28 2025, 12:09 AM
2025-06-28 00:09:28 (UTC+0)
F62631493: Screenshot 2025-06-27 at 2.27.14 PM.png
Jun 28 2025, 12:09 AM
2025-06-28 00:09:28 (UTC+0)
F62432358: CleanShot 2025-06-23 at 13.37.19.mp4
Jun 23 2025, 11:40 AM
2025-06-23 11:40:35 (UTC+0)
Restricted File
Jun 23 2025, 10:58 AM
2025-06-23 10:58:28 (UTC+0)
View All 17 Files
Subscribers
AAlhazwani-WMF
Aklapper
daniel
Etonkovidova
gmodena
Johannnes89
kostajh
View All 12 Subscribers
Description
We want to send a notification to a TBD cohort of users when they reach the number of edits configured by community (
T393769
). The goals of the notification are:
Inform Add a link task is no longer available for them
Congratulate the achievement and reinforce the user by showing their editing impact/stats
Design:
Notification when the threshold is reach
Complete design:
+ video walkthrough linked inside the figma file
Acceptance Criteria:
notification: newcomers with more than X edits && that completed at least 1x add-a-link task && still have add-a-link selected will receive a congratulatory/levelling up message
Questions
What limiting factors should we use to restrict the cohort of users that we'll get the notification? Registered time? Last time active? Interacted with homepage? Interacted with Add a link?
What impact data do we
want
to show in the notification and what impact data
can
we show?
design shared 2 proposals for engineering to evaluate (
comment
Echo thanks 1,10,100,1000 edit. Is that a problem? Attention competition?
we changed the options to
No, 5, 20, 50, 75, 150
(thanks to
community input
What happens when the user clicks the notification? Opening the homepage?
newcomers are re-directed to "Select types of edits" dialog (
comment
Details
Related Changes in Gerrit:
Subject
Repo
Branch
Lines +/-
Update the URL generation to prevent skin switching
mediawiki/extensions/GrowthExperiments
master
+1
-1
Auto-open difficulty filter dialog via URL fragment
mediawiki/extensions/GrowthExperiments
master
+11
-1
Send notification when Add a Link edit threshold is reached
mediawiki/extensions/GrowthExperiments
master
+414
-2
fix: add missing messages for change Add Link config
mediawiki/extensions/GrowthExperiments
master
+8
-8
fix: amend wrong message keys after enum values changed
mediawiki/extensions/GrowthExperiments
master
+8
-8
Config(AddLink): change maximumEditsTaskIsAvailable enum values
mediawiki/extensions/GrowthExperiments
master
+14
-7
Customize query in gerrit
Related Objects
Search...
Task Graph
Mentions
Status
Subtype
Assigned
Task
Resolved
KStoller-WMF
T368187
[EPIC] Constructive activation experimentation (Growth work related to Wiki Experiences 1.2)
Resolved
KStoller-WMF
T389288
[Epic] Add a Link (Structured Task): Improvements to address community feedback (WE1.2.16, FY24/25)
Resolved
KStoller-WMF
T386034
Add a Link: Community Configuration setting to allow limiting "Add a Link" to new editors
Resolved
AAlhazwani-WMF
T390079
Design Exploration: Allow limiting "Add a Link" to new editors
Resolved
KStoller-WMF
T393688
Allow limiting "Add a Link" to new editors
Resolved
Cyndymediawiksim
T393771
Send a notification to newcomers when Add a link edit threshold is reached
Resolved
Michael
T398262
Adjustments to Limiting Add Link notification CTA label and icon
Mentioned In
T402422: [mobile] Add a link edit threshold notification should link to type-of-edit selection dialog overlay
T396382: Deployment Plan: Allow limiting "Add a Link" to new editors
T398262: Adjustments to Limiting Add Link notification CTA label and icon
T397936: Update user edit count before invoking event listeners in hooks.
T395383: Community Configuration: Restrict "Add a link" suggested tasks based on newcomer total edit count
T393920: Add a reinforcing message under the disabled task with some user impact metric
T393688: Allow limiting "Add a Link" to new editors
Mentioned Here
T402422: [mobile] Add a link edit threshold notification should link to type-of-edit selection dialog overlay
T398262: Adjustments to Limiting Add Link notification CTA label and icon
T397936: Update user edit count before invoking event listeners in hooks.
P78632 confetti icon
T393920: Add a reinforcing message under the disabled task with some user impact metric
T390079: Design Exploration: Allow limiting "Add a Link" to new editors
T395383: Community Configuration: Restrict "Add a link" suggested tasks based on newcomer total edit count
T393769: Disable task type X for a user when the configured threshold is reached
Event Timeline
There are a very large number of changes, so older changes are hidden.
Show Older Changes
Cyndymediawiksim
claimed this task.
Jun 4 2025, 9:06 AM
2025-06-04 09:06:36 (UTC+0)
Cyndymediawiksim
moved this task from
Incoming
to
Doing
on the
Growth-Team (Current Sprint)
board.
Cyndymediawiksim
added a comment.
Jun 10 2025, 7:51 AM
2025-06-10 07:51:11 (UTC+0)
Comment Actions
@Sgs
, my recommendations for the questions would be:
Questions
What limiting factors should we use to restrict the cohort of users that we'll get the notification? Registered time? Last time active? Interacted with homepage? Interacted with Add a link?
->I think a combination of registered time and recent activity(last active date) would ensure that we target
true
newcomers, and then add a requirement for having interacted with the “Add a link” task. This will have a narrow engaged cohort who will understand and appreciate being notified about a change in the task availability.
What impact data do we want to show in the notification and what impact data can we show?design shared 2 proposals for engineering to evaluate (comment)
-> I’d lean toward displaying impact via page views. This metric is less likely to push for volume over quality and instead offers a tangible, quality-oriented reflection of an edit’s impact.
Echo thanks 1,10,100,1000 edit. Is that a problem? Attention competition?
-> We can allow communites to select what thresholds makes sense for them, something like preset options like what was done in
T395383
. Though am not quite sure on how feasible it is to extend this pattern.
AAlhazwani-WMF
added a comment.
Edited
Jun 10 2025, 8:45 AM
2025-06-10 08:45:02 (UTC+0)
Comment Actions
some spontaneous thoughts
In
T393771#10898284
@Cyndymediawiksim
wrote:
@Sgs
, my recommendations for the questions would be:
Questions
What limiting factors should we use to restrict the cohort of users that we'll get the notification? Registered time? Last time active? Interacted with homepage? Interacted with Add a link?
->I think a combination of registered time and recent activity(last active date) would ensure that we target
true
newcomers, and then add a requirement for having interacted with the “Add a link” task. This will have a narrow engaged cohort who will understand and appreciate being notified about a change in the task availability.
if we build off what we wrote as acceptance criteria in the task description we could lean towards something like this:
newcomers with more than
{COMMUNITY CONFIG TOTAL EDIT COUNT}
* edits && that completed at least 1x add-a-link task in the past
{30 DAYS}
&& still have add-a-link (structured task) selected in the selection dialog
*defined by
T395383
cc
@KStoller-WMF
is past 30 days reasonable? or should we extend that to 60 or 90 days?
What impact data do we want to show in the notification and what impact data can we show?design shared 2 proposals for engineering to evaluate (comment)
-> I’d lean toward displaying impact via page views. This metric is less likely to push for volume over quality and instead offers a tangible, quality-oriented reflection of an edit’s impact.
agreed
Echo thanks 1,10,100,1000 edit. Is that a problem? Attention competition?
-> We can allow communites to select what thresholds makes sense for them, something like preset options like what was done in
T395383
. Though am not quite sure on how feasible it is to extend this pattern.
if we're concerned about conflicts with
we could consider changing the defaults of
T395383
from
No, 10, 50, 100, 250, 500
to
No, 20, 75, 150, 300, 500
cc
@KStoller-WMF
KStoller-WMF
added a comment.
Jun 10 2025, 2:30 PM
2025-06-10 14:30:49 (UTC+0)
Comment Actions
is past 30 days reasonable? or should we extend that to 60 or 90 days?
I think we should default to either 30 or 60 days.
30 ensures the notification is more relevant, but 60 might increase the "re-engagement" impact. Let's default to 30 unless others feel we should increase that?
AAlhazwani-WMF
mentioned this in
T393920: Add a reinforcing message under the disabled task with some user impact metric
Jun 11 2025, 10:48 AM
2025-06-11 10:48:42 (UTC+0)
KStoller-WMF
added a comment.
Jun 11 2025, 9:04 PM
2025-06-11 21:04:43 (UTC+0)
Comment Actions
In
T393771#10898464
@AAlhazwani-WMF
wrote:
if we're concerned about conflicts with
we could consider changing the defaults of
T395383
from
No, 10, 50, 100, 250, 500
to
No, 20, 75, 150, 300, 500
Hmmmmm, I'm not too worried about this since the "worst case scenario" is that an editor receives two positive notifications upon reaching an editing milestone. But given that this would be an issue at both 10 edits and 100 edits, I can see how "No, 20, 75, 150, 300, 500" might be a slightly preferred approach.
@Cyndymediawiksim
@Sgs
- should we make this change, and I'll update related task descriptions?
Cyndymediawiksim
added a comment.
Edited
Jun 12 2025, 8:55 AM
2025-06-12 08:55:48 (UTC+0)
Comment Actions
In
T393771#10906619
@KStoller-WMF
wrote:
In
T393771#10898464
@AAlhazwani-WMF
wrote:
if we're concerned about conflicts with
we could consider changing the defaults of
T395383
from
No, 10, 50, 100, 250, 500
to
No, 20, 75, 150, 300, 500
Hmmmmm, I'm not too worried about this since the "worst case scenario" is that an editor receives two positive notifications upon reaching an editing milestone. But given that this would be an issue at both 10 edits and 100 edits, I can see how "No, 20, 75, 150, 300, 500" might be a slightly preferred approach.
@Cyndymediawiksim
@Sgs
- should we make this change, and I'll update related task descriptions?
@KStoller-WMF
@AAlhazwani-WMF
, Thanks for flagging the overlap. IMHO, most people want an early positive feedback so keeping the 10-edit might be trade-off we are ready to make? That said, if the overlap becomes too noisy getting in the way of the user experience, we can always revisit the thresholds(i think the change would need to be done in the schema only).
@Sgs
, what do you think?
Sgs
added subscribers:
Urbanecm_WMF
Michael
kostajh
Jun 12 2025, 11:19 AM
2025-06-12 11:19:59 (UTC+0)
Comment Actions
In
T393771#10898464
@AAlhazwani-WMF
wrote:
No, 10, 50, 100, 250, 500
to
No, 20, 75, 150, 300, 500
TLDR: let's change the values now that's cheap. Changing the values is pretty easy now that we haven't yet deployed the initial list of values to any production wiki. In the future for production it would require a migration. In beta we can manually change whatever values we have now set from the first list.
Implementation proposal
Some implementation notes discussed with
@Cyndymediawiksim
The general implementation plan would be to use a
hook
(I forgot we now have
domain events
which is probably better) event ingress to check if the user is reaching the maximum configured on the edit and meets the rest of criteria, if so, send a notification. The main thing to figure out is how to check for the criteria to receive the notification
In order to meet the criteria
newcomers with more than X edits && that completed at least 1x add-a-link task && still have add-a-link selected will receive a congratulatory/levelling up message
we need:
add a link is enabled and cc-enabled
: easy through mw/cc config interfaces
newcomers with more than X edits
get the user total edit count, which can be retrieved from
UserEditTracker
still have add-a-link selected
also straight forward through
NewcomerTasksUserOptionsLookup
completed at least 1x add-a-link task in the past 30-60days
, this is more tricky to calculate without using "user impact" data. The proposal would be to check if we have the impact data computed [1] for the given user, if the data is already calculated we can use it straight away to check if it meets the criteria and send or not the notification. If the impact data is not yet computed we would call the compute function and schedule a deferred notification job for a sensible release time when we expect the user impact data to be already calculated (1 min?). This has the side effect of users in the cohort of "reaching the configured limit" being added as rows into the
growthexperiments_user_impact
table, but we expect the numbers to be fairly low on a per-wiki basis so that shouldn't be a problem. Still, would be wise to monitor the table size. cc
@Michael
@kostajh
@Urbanecm_WMF
to double check the reasoning and express any concerns.
[1] afaiu there are two mechanisms in place that cache user impact data to serve it promptly:
User visits their homepage or any user visits Special:Impact/ or pages with transcluded impact
Two recurring runs of the
refreshUserImpactData
script (
puppet config
) which cache impact data for
recently registered
users (
--registeredWithin=2week --hasEditsAtLeast=3 --ignoreIfUpdatedWithin=6hour
) and for users
recently editing
--registeredWithin=1year --editedWithin=2week --hasEditsAtLeast=3
). An example of user data not cached would be:
user registered 3 years ago and just edited
gerritbot
added a comment.
Jun 12 2025, 11:30 AM
2025-06-12 11:30:18 (UTC+0)
Comment Actions
Change #1156309 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):
[mediawiki/extensions/GrowthExperiments@master] Config(AddLink): change maximumEditsTaskIsAvailable enum values
gerritbot
added a project:
Patch-For-Review
Jun 12 2025, 11:30 AM
2025-06-12 11:30:19 (UTC+0)
AAlhazwani-WMF
added a comment.
Jun 13 2025, 8:57 AM
2025-06-13 08:57:11 (UTC+0)
Comment Actions
In
T393771#10908707
@Sgs
wrote:
In
T393771#10898464
@AAlhazwani-WMF
wrote:
No, 10, 50, 100, 250, 500
to
No, 20, 75, 150, 300, 500
TLDR: let's change the values now that's cheap. Changing the values is pretty easy now that we haven't yet deployed the initial list of values to any production wiki. In the future for production it would require a migration. In beta we can manually change whatever values we have now set from the first list.
ok, let's go for
No, 20, 75, 150, 300, 500
. thank you
@Sgs
AAlhazwani-WMF
updated the task description.
(Show Details)
Jun 13 2025, 8:59 AM
2025-06-13 08:59:16 (UTC+0)
gerritbot
added a comment.
Jun 13 2025, 9:33 AM
2025-06-13 09:33:15 (UTC+0)
Comment Actions
Change #1156749 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):
[mediawiki/extensions/GrowthExperiments@master] Send notification when Add a Link edit threshold is reached
Johannnes89
added subscribers:
neriah
Nemoralis
Jun 13 2025, 11:43 AM
2025-06-13 11:43:33 (UTC+0)
Comment Actions
In
T393771#10912439
@AAlhazwani-WMF
wrote:
In
T393771#10908707
@Sgs
wrote:
In
T393771#10898464
@AAlhazwani-WMF
wrote:
No, 10, 50, 100, 250, 500
to
No, 20, 75, 150, 300, 500
TLDR: let's change the values now that's cheap. Changing the values is pretty easy now that we haven't yet deployed the initial list of values to any production wiki. In the future for production it would require a migration. In beta we can manually change whatever values we have now set from the first list.
ok, let's go for
No, 20, 75, 150, 300, 500
. thank you
@Sgs
Sorry for noticing this just now: Is there a reason why there are fixed values? The initial design
T390079
looked different, I just noticed that
T395383
added fixed options. Admins can choose any number they like for the daily limit of add link tasks (
@neriah
mentioned that hewiki limited the task to 1x per day
to stop users from gaining voting rights too quickly just by doing this task). It doesn’t make sense to me to just allow five (random?) values for the absolute limit.
Note that a limit of 300 or 500 edits basically equals to having no limit at all if the goal is to prevent users from gaining certain permissions without doing any "real" edits -
extended confirmed
on English Wikipedia requires 500 edits,
reviewer permissions
on German Wikipedia require 150/300 edits,
access to temporary account IPs
requires 300 edits per WMF policy... – you can even get elected as an admin on some smaller wikis with just a couple of dozen edits (
example
).
@Nemoralis
mentioned the desire to limit the task to 100 or less for azwiki in
T390079#10797759
, from a dewiki perspective we would go even lower, because our articles usually have all the desired links and we are just using the task to offer a first edit experience to newbies – the new values proposed in
T393771#10898464
by
@AAlhazwani-WMF
only leave the option for 20 or 75 if you want "100 or less".
If there is a reason for fixed values and you don't want to interfere with the 1, 10, 100
milestone notifications
I propose removing 300 and 500 and go for the following options:
No, 5, 20, 50, 75, 150
AAlhazwani-WMF
added a comment.
Jun 13 2025, 8:38 PM
2025-06-13 20:38:41 (UTC+0)
Comment Actions
In
T393771#10912880
@Johannnes89
wrote:
Sorry for noticing this just now: Is there a reason why there are fixed values? The initial design
T390079
looked different, I just noticed that
T395383
added fixed options.
no worries at all, and thank you for chiming in! yes, we initially explored a solution with a free text field, but soon realized that would have required a lengthy label explaining that the default value (empty text field) meant 'no limit'. given that this setting is about turning on or off suggestions beyond a certain threshold, we decided to use a component (radio buttons) that echos that pattern.
Note that a limit of 300 or 500 edits basically equals to having no limit at all if the goal is to prevent users from gaining certain permissions without doing any "real" edits -
extended confirmed
on English Wikipedia requires 500 edits,
reviewer permissions
on German Wikipedia require 150/300 edits,
access to temporary account IPs
requires 300 edits per WMF policy... – you can even get elected as an admin on some smaller wikis with just a couple of dozen edits (
example
).
@Nemoralis
mentioned the desire to limit the task to 100 or less for azwiki in
T390079#10797759
, from a dewiki perspective we would go even lower, because our articles usually have all the desired links and we are just using the task to offer a first edit experience to newbies – the new values proposed in
T393771#10898464
by
@AAlhazwani-WMF
only leave the option for 20 or 75 if you want "100 or less".
If there is a reason for fixed values and you don't want to interfere with the 1, 10, 100
milestone notifications
I propose removing 300 and 500 and go for the following options:
No, 5, 20, 50, 75, 150
thanks for providing all the additional context, very much appreciated! and yes, you are correct: we wanted to provide sensible defaults that align well with existing milestone notifications sent to newcomers. i'm in favor of your proposal, and would suggest engineering to follow it.
AAlhazwani-WMF
updated the task description.
(Show Details)
Jun 13 2025, 8:45 PM
2025-06-13 20:45:07 (UTC+0)
Sgs
mentioned this in
T395383: Community Configuration: Restrict "Add a link" suggested tasks based on newcomer total edit count
Jun 16 2025, 11:46 AM
2025-06-16 11:46:54 (UTC+0)
Cyndymediawiksim
added a comment.
Jun 17 2025, 12:27 PM
2025-06-17 12:27:37 (UTC+0)
Comment Actions
@KStoller-WMF
, How should we treat reverted edits?, and should a newcomer get the “Add-a-Link threshold reached” notification only the first time they cross a milestone, or every time they re-cross it even if they’ve already been notified?
Cyndymediawiksim
added a comment.
Jun 17 2025, 12:31 PM
2025-06-17 12:31:56 (UTC+0)
Comment Actions
@AAlhazwani-WMF
, are we still using the page views as part of congratulatory message or did we opt to simplify the message ?
AAlhazwani-WMF
added a comment.
Jun 17 2025, 1:24 PM
2025-06-17 13:24:35 (UTC+0)
Comment Actions
In
T393771#10922812
@Cyndymediawiksim
wrote:
@AAlhazwani-WMF
, are we still using the page views as part of congratulatory message or did we opt to simplify the message ?
@Cyndymediawiksim
yes, we would still recommend including some verbiage around the newcomer impact. our proposal is to use page views given that we already have the data pipeline for the impact module.
in the example below, imagine a community admin setting the total edits threshold to
75
. after completing their 75th edit, the newcomer will receive the notification.
FYI some context around how we're thinking about "composing" the message
[...] when i was thinking about this copy, i was trying to make it possible to re-use the strings for the notification copy too (shared parts in bold)
100 edits, congrats!
Articles you’ve edited received 17,210 views recently.
Available suggested edits have changed.
KStoller-WMF
added a comment.
Jun 17 2025, 10:07 PM
2025-06-17 22:07:45 (UTC+0)
Comment Actions
In
T393771#10922788
@Cyndymediawiksim
wrote:
@KStoller-WMF
, How should we treat reverted edits?, and should a newcomer get the “Add-a-Link threshold reached” notification only the first time they cross a milestone, or every time they re-cross it even if they’ve already been notified?
Ideally a newcomer only receives this notification once.
(If an admin adjusts the threshold to a higher limit and some editors hit the threshold a second time and receive the notification again, I think that's an edge-case we can live with).
As for the question about reverts: my understanding is that a user's total edit count doesn't decrease even if their edit is reverted. Which means this isn't a use case we need to consider... but let me know if I'm missing something!
"Your Preferences page's User profile tab shows the total number of edits you have made in its Basic information section. The number is based upon an edit count that is stored for each user, incremented each time the user makes an edit, but not decremented when a user's edit is deleted. Therefore, the count includes deleted edits."
gerritbot
added a comment.
Jun 18 2025, 1:32 PM
2025-06-18 13:32:32 (UTC+0)
Comment Actions
Change #1156309
merged
by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Config(AddLink): change maximumEditsTaskIsAvailable enum values
ReleaseTaggerBot
added a project:
MW-1.45-notes (1.45.0-wmf.7; 2025-06-24)
Jun 18 2025, 2:00 PM
2025-06-18 14:00:49 (UTC+0)
gerritbot
added a comment.
Jun 18 2025, 3:26 PM
2025-06-18 15:26:38 (UTC+0)
Comment Actions
Change #1160845 had a related patch set uploaded (by Michael Große; author: Michael Große):
[mediawiki/extensions/GrowthExperiments@master] fix: add missing messages for change Add Link config
gerritbot
added a comment.
Jun 19 2025, 9:30 AM
2025-06-19 09:30:57 (UTC+0)
Comment Actions
Change #1161451 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):
[mediawiki/extensions/GrowthExperiments@master] fix: amend wrong message keys after enum values changed
gerritbot
added a comment.
Jun 19 2025, 9:31 AM
2025-06-19 09:31:59 (UTC+0)
Comment Actions
Change #1161451
abandoned
by Sergio Gimeno:
[mediawiki/extensions/GrowthExperiments@master] fix: amend wrong message keys after enum values changed
Reason:
Done in I6c49f9c415c6a8eb91c9bd61d95e1184393709d1
Stashbot
added a comment.
Jun 19 2025, 9:38 AM
2025-06-19 09:38:51 (UTC+0)
Comment Actions
Mentioned in SAL (#wikimedia-releng)
[2025-06-19T09:38:50Z] deployment-prep: GrowthExperiments config migration
foreachwiki extensions/CommunityConfiguration/maintenance/migrateConfig.php GrowthSuggestedEdits
T393771
gerritbot
added a comment.
Jun 19 2025, 9:50 AM
2025-06-19 09:50:53 (UTC+0)
Comment Actions
Change #1160845
merged
by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] fix: add missing messages for change Add Link config
Sgs
added a comment.
Edited
Jun 20 2025, 3:58 PM
2025-06-20 15:58:43 (UTC+0)
Comment Actions
@AAlhazwani-WMF
we're facing an issue with the notifications presentation model. It seems that Echo only allows messages for the header with the user name parameter (for gender purposes) but not random parameters, so we cannot use the threshold number or pagevies numbers in the title. We can in the body. This is how it looks right now, we haven't found a way to instruct Echo to no display a title/header for a given notification. TLDR: can you provide a title for this notification that only uses username as a parameter?
Apologies for the miss-information here, this is how it looks based on the initial design:
{F62432072}
Cyndymediawiksim
added a comment.
Jun 23 2025, 8:46 AM
2025-06-23 08:46:29 (UTC+0)
Comment Actions
@AAlhazwani-WMF
, could you also kindly provide the SVG icon that matches the design ? :)
AAlhazwani-WMF
added a comment.
Jun 23 2025, 11:40 AM
2025-06-23 11:40:35 (UTC+0)
Comment Actions
In
T393771#10937463
@Cyndymediawiksim
wrote:
@AAlhazwani-WMF
, could you also kindly provide the SVG icon that matches the design ? :)
yes
@Cyndymediawiksim
, here's the code!
P78632 confetti icon
svg
xmlns
"http://www.w3.org/2000/svg"
width
"30"
height
"30"
viewBox
"0 0 30 30"
path
fill
"#36C"
"m9.231 9.14.532.098c2.647.553 5.118 2.022 7.048 3.952 2.058 2.058 3.591 4.731 4.048 7.579l.034.34a2.682 2.682 0 0 1-2.265 2.751 1.554 1.554 0 0 1-.115.05L2.314 29.798C.998 30.277-.278 29.002.2 27.686l5.89-16.199.05-.125a2.684 2.684 0 0 1 2.752-2.256l.34.035ZM4.006 25.993l9.72-3.535a15.35 15.35 0 0 1-3.537-2.646 15.35 15.35 0 0 1-2.648-3.54l-3.535 9.721Zm5.176-13.81c.42 1.975 1.55 3.928 3.129 5.507 1.579 1.58 3.53 2.706 5.505 3.127-.42-1.974-1.548-3.926-3.126-5.505-1.58-1.58-3.533-2.709-5.508-3.13ZM30 16.5h-6v-3h6v3ZM26.56 5.56l-4.5 4.5-2.12-2.12 4.5-4.5 2.12 2.12ZM16.502 6h-3V0h3v6Z"
/>
svg
would it be possible to animate the icon? if yes, how can i best support you? i built this animation with a software powered by
KStoller-WMF
added a comment.
Jun 23 2025, 11:10 PM
2025-06-23 23:10:21 (UTC+0)
Comment Actions
would it be possible to animate the icon?
I think an animation would be great if possible, but if it's technically complex or time-consuming, let's plan to address it in a follow-up task. My preference is to release as soon as possible, ideally by June 30, and refine details like this afterward.
Michael
added a comment.
Edited
Jun 24 2025, 1:35 PM
2025-06-24 13:35:09 (UTC+0)
Comment Actions
completed at least 1x add-a-link task in the past 30-60days
Getting that information for a specific time-frame may be unexpectedly tricky. The user-impact data that we are using currently does not provide that information. Which means that right now the check defacto is "Have they completed at least 1 add-a-link task ever?". I suggest that we move forward towards release with this implementation and do the change to calculate the "Number of newcomer edits per task-type per day" and check that for the time-frame as a follow-up. (If it is important enough to do at all.)
@AAlhazwani-WMF
@KStoller-WMF
⬆️
AAlhazwani-WMF
added a comment.
Jun 24 2025, 1:38 PM
2025-06-24 13:38:21 (UTC+0)
Comment Actions
In
T393771#10942893
@Michael
wrote:
completed at least 1x add-a-link task in the past 30-60days
Getting that information for a specific time-frame maybe unexpectedly tricky. The user-impact data that we are using is currently does not provide that information. Which means that right now the check defacto is "Have they completed at least 1 add-a-link task ever?". I suggest that we move forward towards release with this implementation and do the change to calculate the "Number of newcomer edits per task-type per day" and check that for the time-frame as a follow-up. (If it is important enough to do at all.)
@AAlhazwani-WMF
@KStoller-WMF
⬆️
@Michael
agreed, thank you!
Cyndymediawiksim
moved this task from
Doing
to
Code Review
on the
Growth-Team (Current Sprint)
board.
Jun 24 2025, 4:36 PM
2025-06-24 16:36:14 (UTC+0)
KStoller-WMF
awarded a token.
Jun 24 2025, 11:07 PM
2025-06-24 23:07:49 (UTC+0)
Sgs
added a subscriber:
daniel
Jun 26 2025, 9:33 AM
2025-06-26 09:33:28 (UTC+0)
Comment Actions
We decided to go with a domain event ingress for
PageRevisionUpdatedEvent
events and now we're realizing
nothing
ensures the order of execution between our handler (
NewcomerMilestoneIngress.php
) and the handler that updates the user edit count (
deferred/UserEditCountUpdate.php
). In the milestone handler we want to check if the user edit count is equal to a given threshold but we cannot tell if the edit count we get fron
UserEditTracker
has already computed the last edit. So far, by
observation
in our local setups, it seems the
DomainEventIngress
runs before the
UserEditCountUpdate
deferred update, but I haven't go into the depths to understand the differences between these two.
I vaguely remember discussing about order of executions in early domain event discussion but I don't know what was the conclusion, if order should never be relied on or there's any way to tweak the execution priority for a particular update. Currently the user edit count deferred update has a hook
onUserEditCountUpdate
that we could use, but that feels going backwards on the domain event adoption.
@daniel
do you see any reasonable solution to achieve what we're looking for here with domain events?
Michael
added a comment.
Jun 26 2025, 9:51 AM
2025-06-26 09:51:21 (UTC+0)
Comment Actions
In
T393771#10949607
@Sgs
wrote:
We decided to go with a domain event ingress for
PageRevisionUpdatedEvent
events and now we're realizing
nothing
ensures the order of execution between our handler (
NewcomerMilestoneIngress.php
) and the handler that updates the user edit count (
deferred/UserEditCountUpdate.php
). In the milestone handler we want to check if the user edit count is equal to a given threshold but we cannot tell if the edit count we get fron
UserEditTracker
has already computed the last edit. So far, by
observation
in our local setups, it seems the
DomainEventIngress
runs before the
UserEditCountUpdate
deferred update, but I haven't go into the depths to understand the differences between these two.
I vaguely remember discussing about order of executions in early domain event discussion but I don't know what was the conclusion, if order should never be relied on or there's any way to tweak the execution priority for a particular update. Currently the user edit count deferred update has a hook
onUserEditCountUpdate
that we could use, but that feels going backwards on the domain event adoption.
@daniel
do you see any reasonable solution to achieve what we're looking for here with domain events?
Looking at
\MediaWiki\Extension\Notifications\MediaWikiEventIngress\PageEventIngress
which schedules the celebration notification at powers of 10 edits, I notice that they have the same logic there:
Echo/includes/MediaWikiEventIngress/PageEventIngress.php
/**
* Get the predicted edit count after a page save event
* @param UserIdentity $user
* @return int
*/
private
function
getPredictedEditCount
UserIdentity
$user
$editCount
$this
->
userEditTracker
->
getUserEditCount
$user
?:
// When this code runs, the deferred update that increments the edit count
// will still be pending.
return
$editCount
Though I'd also be curious to learn why we expect that to hold in production.
That being said,
\MediaWiki\Extension\Notifications\MediaWikiEventIngress\PageEventIngress::maybeSendThankYouEdit
is also explicitly checking if the notification was already sent. This is something we could do as well to avoid duplicates.
daniel
added a subscriber:
gmodena
Jun 26 2025, 10:09 AM
2025-06-26 10:09:52 (UTC+0)
Comment Actions
There's a lot to unpack here, I'll try to give a brief version in bullet points:
execution of event listeners is deferred until after the resonse has been sent
listeners of the same event will be invoked in the order in which they were registered
this means that listeners registered by core are always invoked first
user edit count updates are triggered via ChangeTrackingEventIngress which calls UserEditTracker::incrementUserEditCount before any listeners from extensions are invoked
however
I now realize that incrementUserEditCount() just schedules a UserEditCountUpdate - which will be run in the next round of updates,
after
all the extension listeners have been invoked.
@gmodena
we talked about this in the context of EventBus - at the time I didn't realize that user edit count updates are deferred
twice
...
The best way to fix this would probably to have a synchronous version of incrementUserEditCount(), which ChangeTrackingEventIngress can use. That way, the edit count should get updated before the extension listeners run. At least for edits.
Note that
incrementUserEditCount is used in a couple of other places as well
, which are probably relying on the execution being async. As long as it's called before the relevant event is fired, and there is no double-deferring, that should still work fine.
Michael
added a comment.
Edited
Jun 26 2025, 1:05 PM
2025-06-26 13:05:37 (UTC+0)
Comment Actions
In
T393771#10949765
@daniel
wrote:
There's a lot to unpack here, I'll try to give a brief version in bullet points:
execution of event listeners is deferred until after the resonse has been sent
listeners of the same event will be invoked in the order in which they were registered
this means that listeners registered by core are always invoked first
user edit count updates are triggered via ChangeTrackingEventIngress which calls UserEditTracker::incrementUserEditCount before any listeners from extensions are invoked
however
I now realize that incrementUserEditCount() just schedules a UserEditCountUpdate - which will be run in the next round of updates,
after
all the extension listeners have been invoked.
Thank you for that explanation!
@gmodena
we talked about this in the context of EventBus - at the time I didn't realize that user edit count updates are deferred
twice
...
The best way to fix this would probably to have a synchronous version of incrementUserEditCount(), which ChangeTrackingEventIngress can use. That way, the edit count should get updated before the extension listeners run. At least for edits.
[...]
Please keep us in the loop when you're making any changes to that behavior. We need to make sure to make the corresponding change on our side as well an that it rides the same train.
gerritbot
added a comment.
Jun 26 2025, 1:13 PM
2025-06-26 13:13:07 (UTC+0)
Comment Actions
Change #1156749
merged
by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Send notification when Add a Link edit threshold is reached
Maintenance_bot
removed a project:
Patch-For-Review
Jun 26 2025, 1:33 PM
2025-06-26 13:33:02 (UTC+0)
ReleaseTaggerBot
edited projects, added
MW-1.45-notes (1.45.0-wmf.8; 2025-07-01)
; removed
MW-1.45-notes (1.45.0-wmf.7; 2025-06-24)
Jun 26 2025, 2:00 PM
2025-06-26 14:00:47 (UTC+0)
daniel
added a comment.
Jun 26 2025, 2:28 PM
2025-06-26 14:28:51 (UTC+0)
Comment Actions
In
T393771#10950257
@Michael
wrote:
Please keep us in the loop when you're making any changes to that behavior. We need to make sure to make the corresponding change on our side as well an that it rides the same train.
Filed
T397936: Update user edit count before invoking event listeners in hooks.
Michael
mentioned this in
T397936: Update user edit count before invoking event listeners in hooks.
Jun 26 2025, 4:36 PM
2025-06-26 16:36:48 (UTC+0)
Michael
moved this task from
Code Review
to
QA
on the
Growth-Team (Current Sprint)
board.
Jun 26 2025, 5:06 PM
2025-06-26 17:06:42 (UTC+0)
Etonkovidova
subscribed.
Edited
Jun 28 2025, 12:09 AM
2025-06-28 00:09:28 (UTC+0)
Comment Actions
Tested on beta wikis.
(1) This spec is in place:
notification: newcomers with more than X edits && that completed at least 1x add-a-link task && still have add-a-link selected will receive a congratulatory/levelling up message
users, who have reached the edit number threshold, but their edits do not included Add link edits, do not receive this notification
user, who already had more than the edit number threshold, won't get notifications
(2)
On beta I always see the difference between total page views counts in the Impact module and in the notifications. Probably it wouldn't be a problem in production.
mockup
beta
(3)
The following spec (also see the comment -
) refers only to the behavior on mobile and the current behavior is different.
newcomers are re-directed to "Select types of edits" dialog
The primary link redirects to Special:Homepage - e.g.
primary_link
Try suggested edits
@AAlhazwani-WMF
- should it be addressed as part of this task or it might be fixed separately?
AAlhazwani-WMF
added a comment.
Jun 30 2025, 8:35 AM
2025-06-30 08:35:11 (UTC+0)
Comment Actions
In
T393771#10955628
@Etonkovidova
wrote:
Tested on beta wikis.
(1) This spec is in place:
notification: newcomers with more than X edits && that completed at least 1x add-a-link task && still have add-a-link selected will receive a congratulatory/levelling up message
users, who have reached the edit number threshold, but their edits do not included Add link edits, do not receive this notification
user, who already had more than the edit number threshold, won't get notifications
my spanish is not strong, but i _think_ "Prueba las ediciones sugeridas" translated to "Try suggested edits". we suggested to change the copy to "Try other edits" to prompt newcomers to try things other than add-a-link which is not disabled.
i also noticed that the icon next to "Try other edits" is different. it should be the edit pencil.
(2) [...]
(3)
The following spec (also see the comment -
) refers only to the behavior on mobile and the current behavior is different.
newcomers are re-directed to "Select types of edits" dialog
The primary link redirects to Special:Homepage - e.g.
primary_link
Try suggested edits
@AAlhazwani-WMF
- should it be addressed as part of this task or it might be fixed separately?
yes, we would recommend redirecting to the selection dialog to reinforce the message to try other edits.
Michael
added a comment.
Jun 30 2025, 10:01 AM
2025-06-30 10:01:13 (UTC+0)
Comment Actions
Sounds like things that we should adjust, but not something that should block today's deployment, right?
AAlhazwani-WMF
added a comment.
Jun 30 2025, 10:22 AM
2025-06-30 10:22:50 (UTC+0)
Comment Actions
In
T393771#10957789
@Michael
wrote:
Sounds like things that we should adjust, but not something that should block today's deployment, right?
i would have preferred for those things to be included in this release, but given that the deployment is today i'm okay with a separate task.
Etonkovidova
mentioned this in
T398262: Adjustments to Limiting Add Link notification CTA label and icon
Jun 30 2025, 11:50 PM
2025-06-30 23:50:44 (UTC+0)
Etonkovidova
added a comment.
Jun 30 2025, 11:57 PM
2025-06-30 23:57:22 (UTC+0)
Comment Actions
In
T393771#10957901
@AAlhazwani-WMF
wrote:
In
T393771#10957789
@Michael
wrote:
Sounds like things that we should adjust, but not something that should block today's deployment, right?
i would have preferred for those things to be included in this release, but given that the deployment is today i'm okay with a separate task.
Filed a separate task for the CTA label/icon -
T398262: Adjustments to Limiting Add Link notification CTA label and icon
Etonkovidova
moved this task from
QA
to
Blocked / Needs Work
on the
Growth-Team (Current Sprint)
board.
Edited
Jul 1 2025, 12:16 AM
2025-07-01 00:16:57 (UTC+0)
Comment Actions
Moving to Needs Work for addressing the following spec (mobile only) - the primary notification link on mobile should link to the "Select types of edits" dialog:
newcomers are re-directed to "Select types of edits" dialog
AAlhazwani-WMF
added a comment.
Jul 1 2025, 8:23 AM
2025-07-01 08:23:52 (UTC+0)
Comment Actions
In
T393771#10961554
@Etonkovidova
wrote:
Moving to Needs Work for addressing the following spec (mobile only) - the primary notification link on mobile should to the "Select types of edits" dialog:
newcomers are re-directed to "Select types of edits" dialog
if possible, we would suggest to display (or open if you're already on the newcomer homepage on desktop) the type selection dialog for both platforms, mobile and desktop.
Nemoralis
unsubscribed.
Jul 1 2025, 9:26 AM
2025-07-01 09:26:21 (UTC+0)
Michael
mentioned this in
T396382: Deployment Plan: Allow limiting "Add a Link" to new editors
Jul 2 2025, 10:30 AM
2025-07-02 10:30:39 (UTC+0)
gerritbot
added a comment.
Jul 4 2025, 4:25 PM
2025-07-04 16:25:51 (UTC+0)
Comment Actions
Change #1166418 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):
[mediawiki/extensions/GrowthExperiments@master] [WIP]:Auto-open difficulty filter dialog via URL fragment
gerritbot
added a project:
Patch-For-Review
Jul 4 2025, 4:25 PM
2025-07-04 16:25:52 (UTC+0)
Cyndymediawiksim
moved this task from
Blocked / Needs Work
to
Doing
on the
Growth-Team (Current Sprint)
board.
Jul 7 2025, 8:56 AM
2025-07-07 08:56:59 (UTC+0)
Cyndymediawiksim
moved this task from
Doing
to
Code Review
on the
Growth-Team (Current Sprint)
board.
Jul 11 2025, 12:14 PM
2025-07-11 12:14:48 (UTC+0)
Michael
added a subtask:
T398262: Adjustments to Limiting Add Link notification CTA label and icon
Jul 15 2025, 6:34 AM
2025-07-15 06:34:50 (UTC+0)
gerritbot
added a comment.
Jul 22 2025, 1:42 PM
2025-07-22 13:42:56 (UTC+0)
Comment Actions
Change #1166418
merged
by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Auto-open difficulty filter dialog via URL fragment
Michael
moved this task from
Code Review
to
QA
on the
Growth-Team (Current Sprint)
board.
Jul 22 2025, 1:57 PM
2025-07-22 13:57:39 (UTC+0)
ReleaseTaggerBot
edited projects, added
MW-1.45-notes (1.45.0-wmf.12; 2025-07-29)
; removed
MW-1.45-notes (1.45.0-wmf.8; 2025-07-01)
Jul 22 2025, 2:00 PM
2025-07-22 14:00:26 (UTC+0)
Maintenance_bot
removed a project:
Patch-For-Review
Jul 22 2025, 2:31 PM
2025-07-22 14:31:16 (UTC+0)
gerritbot
added a comment.
Jul 23 2025, 11:17 AM
2025-07-23 11:17:38 (UTC+0)
Comment Actions
Change #1172022 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):
[mediawiki/extensions/GrowthExperiments@master] Update the URL generation to prevent skin switching
gerritbot
added a project:
Patch-For-Review
Jul 23 2025, 11:17 AM
2025-07-23 11:17:39 (UTC+0)
gerritbot
added a comment.
Jul 25 2025, 7:27 PM
2025-07-25 19:27:55 (UTC+0)
Comment Actions
Change #1172022
merged
by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Update the URL generation to prevent skin switching
Maintenance_bot
removed a project:
Patch-For-Review
Jul 25 2025, 7:31 PM
2025-07-25 19:31:48 (UTC+0)
Etonkovidova
moved this task from
QA
to
Blocked / Needs Work
on the
Growth-Team (Current Sprint)
board.
Aug 11 2025, 9:13 PM
2025-08-11 21:13:02 (UTC+0)
Comment Actions
Checked on
testwiki wmf.13
The following spec has been addressed on the desktop:
newcomers are re-directed to "Select types of edits" dialog
However, on mobile (I tried different browser emulators and different browsers on iPhone devices), the link
opens
Special:Homepage, not the task selection overlay.
Since
@AAlhazwani-WMF
suggested that the redirect to the task selection should be on both mobile and desktop,
@Cyndymediawiksim
- do you think it'd be ok to fix the redirection on mobile in this task or it'd be better to file another task?
Cyndymediawiksim
added a comment.
Aug 12 2025, 8:19 AM
2025-08-12 08:19:44 (UTC+0)
Comment Actions
In
T393771#11075833
@Etonkovidova
wrote:
Checked on
testwiki wmf.13
The following spec has been addressed on the desktop:
newcomers are re-directed to "Select types of edits" dialog
However, on mobile (I tried different browser emulators and different browsers on iPhone devices), the link
opens
Special:Homepage, not the task selection overlay.
Since
@AAlhazwani-WMF
suggested that the redirect to the task selection should be on both mobile and desktop,
@Cyndymediawiksim
- do you think it'd be ok to fix the redirection on mobile in this task or it'd be better to file another task?
@Etonkovidova
, I followed the link above , and got the task overlay. The redirection to mobile was fixed on this patch :
Etonkovidova
added a comment.
Edited
Aug 12 2025, 3:06 PM
2025-08-12 15:06:23 (UTC+0)
Comment Actions
Thanks,
@Cyndymediawiksim
! I checked again and realized that I made a mistake when posting the url :( (sorry) The url that I posted does work - it redirects to the task selection overlay. But the actual link that I meant to post looks like this:
Try other edits
And the actual behavior on mobile is still not quite correct - see that screen recording below: Clicking on
Try other edits
will redirects to Special:Homepage (recorded on
testwiki wmf.14
):
Etonkovidova
closed subtask
T398262: Adjustments to Limiting Add Link notification CTA label and icon
as
Resolved
Aug 13 2025, 7:24 PM
2025-08-13 19:24:02 (UTC+0)
Etonkovidova
mentioned this in
T402422: [mobile] Add a link edit threshold notification should link to type-of-edit selection dialog overlay
Aug 20 2025, 5:49 PM
2025-08-20 17:49:55 (UTC+0)
Etonkovidova
added a comment.
Aug 20 2025, 5:52 PM
2025-08-20 17:52:21 (UTC+0)
Comment Actions
Created a follow-up ticket -
T402422: [mobile] Add a link edit threshold notification should link to type-of-edit selection dialog overlay
. Closing this task as resolved.
Michael
closed this task as
Resolved
Aug 22 2025, 5:58 PM
2025-08-22 17:58:34 (UTC+0)
Log In to Comment
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
Code of Conduct
Disclaimer
CC-BY-SA
GPL
Credits