when we deploy the feature (or when a community admin changes the threshold) we'll calculate the percentile.

Are you thinking the calculation would be something like:
(Total accounts that have made greater to or equal to x edits on that wiki) / (Total accounts created on that wiki) = y%

Or other thoughts on how we should consider calculating this?

Congrats on 100 edits! You're in the top 10% of Wikipedians. Available suggested edits have changed.

I don’t think a message suggesting it’s great to be in a certain percentile is a good idea -> might lead to newcomer editors striving for quantity over quality.

In T393771#10832486, @Johannnes89 wrote:

Congrats on 100 edits! You're in the top 10% of Wikipedians. Available suggested edits have changed.

I don’t think a message suggesting it’s great to be in a certain percentile is a good idea -> might lead to newcomer editors striving for quantity over quality.

Thank you for raising this point, I've been thinking about this too. Since this is intended as a one-time message when “Add a link” suggestions are no longer available, I wasn't too concerned. That said, I completely understand the importance of encouraging newcomers to focus on quality rather than quantity.

Growth engineers: If it’s technically feasible, using a metric like page views might better reflect the impact of an editor’s contributions without encouraging volume over quality. Alternatively, let us know if you have other ideas for positive metrics we could surface to help soften what might feel like disappointing news to some editors.

@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.

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 https://en.wikipedia.org/wiki/Help:Notifications#Milestone 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

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?

In T393771#10898464, @AAlhazwani-WMF wrote:

if we're concerned about conflicts with https://en.wikipedia.org/wiki/Help:Notifications#Milestone 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?

In T393771#10906619, @KStoller-WMF wrote:

In T393771#10898464, @AAlhazwani-WMF wrote:

if we're concerned about conflicts with https://en.wikipedia.org/wiki/Help:Notifications#Milestone 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?

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:

1. User visits their homepage or any user visits Special:Impact/<user> or pages with transcluded impact
2. 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

Change #1156309 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] Config(AddLink): change maximumEditsTaskIsAvailable enum values

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

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!

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

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

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.

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.

@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?

@AAlhazwani-WMF , are we still using the page views as part of congratulatory message or did we opt to simplify the message ?

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 https://phabricator.wikimedia.org/T393920#10912415

[...] 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.

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."
https://en.wikipedia.org/wiki/Help%3AUser_contributions#Total_edit_count

Change #1156309 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Config(AddLink): change maximumEditsTaskIsAvailable enum values

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

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

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

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

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

Change #1161451 abandoned by Sergio Gimeno:

[mediawiki/extensions/GrowthExperiments@master] fix: amend wrong message keys after enum values changed

Reason:

Done in I6c49f9c415c6a8eb91c9bd61d95e1184393709d1

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

Mentioned in SAL (#wikimedia-releng) [2025-06-19T09:38:50Z] <sergi0> deployment-prep: GrowthExperiments config migration foreachwiki extensions/CommunityConfiguration/maintenance/migrateConfig.php GrowthSuggestedEdits — T393771

Change #1160845 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] fix: add missing messages for change Add Link config

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

@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}

@AAlhazwani-WMF, could you also kindly provide the SVG icon that matches the design ? :)

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!

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 https://lottie.github.io/.

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.

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 ⬆️

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!

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?

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:

	/**
	 * 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 ) ?: 0;
		// When this code runs, the deferred update that increments the edit count
		// will still be pending.
		return $editCount + 1;
	}

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.

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.

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.

Change #1156749 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Send notification when Add a Link edit threshold is reached

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

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..

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 - https://phabricator.wikimedia.org/T393771#10811487) 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. https://es.m.wikipedia.beta.wmflabs.org/w/index.php?title=Especial:P%C3%A1gina_inicial&source=get-started-primary-link-web#/homepage/suggested-edits

<a class="oo-ui-widget oo-ui-widget-enabled oo-ui-labelElement oo-ui-optionWidget oo-ui-buttonElement oo-ui-buttonElement-frameless oo-ui-iconElement oo-ui-buttonOptionWidget mw-echo-ui-menuItemWidget mw-echo-ui-menuItemWidget-prioritized" aria-selected="false" tabindex="-1" role="option" href="https://es.wikipedia.beta.wmflabs.org/w/index.php?title=Especial:P%C3%A1gina_inicial&amp;source=get-started-primary-link-web#/homepage/suggested-edits"><a class="oo-ui-buttonElement-button" role="button"><span class="oo-ui-iconElement-icon oo-ui-icon-next"></span><span class="oo-ui-labelElement-label">Try suggested edits<label class="mw-echo-ui-menuItemWidget-description oo-ui-widget oo-ui-widget-enabled oo-ui-labelElement-label oo-ui-labelWidget oo-ui-element-hidden"></label></span><span class="oo-ui-indicatorElement-indicator oo-ui-indicatorElement-noIndicator"></span></a></a>

@AAlhazwani-WMF - should it be addressed as part of this task or it might be fixed separately?

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 - https://phabricator.wikimedia.org/T393771#10811487) 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. https://es.wikipedia.beta.wmflabs.org/w/index.php?title=Especial:P%C3%A1gina_inicial&source=get-started-primary-link-web#/homepage/suggested-edits

primary_link

<a class="oo-ui-widget oo-ui-widget-enabled oo-ui-labelElement oo-ui-optionWidget oo-ui-buttonElement oo-ui-buttonElement-frameless oo-ui-iconElement oo-ui-buttonOptionWidget mw-echo-ui-menuItemWidget mw-echo-ui-menuItemWidget-prioritized" aria-selected="false" tabindex="-1" role="option" href="https://es.wikipedia.beta.wmflabs.org/w/index.php?title=Especial:P%C3%A1gina_inicial&amp;source=get-started-primary-link-web#/homepage/suggested-edits"><a class="oo-ui-buttonElement-button" role="button"><span class="oo-ui-iconElement-icon oo-ui-icon-next"></span><span class="oo-ui-labelElement-label">Try suggested edits<label class="mw-echo-ui-menuItemWidget-description oo-ui-widget oo-ui-widget-enabled oo-ui-labelElement-label oo-ui-labelWidget oo-ui-element-hidden"></label></span><span class="oo-ui-indicatorElement-indicator oo-ui-indicatorElement-noIndicator"></span></a></a>

@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.

Sounds like things that we should adjust, but not something that should block today's deployment, right?

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.

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.

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

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.

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

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

Change #1166418 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Auto-open difficulty filter dialog via URL fragment

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

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

[mediawiki/extensions/GrowthExperiments@master] Update the URL generation to prevent skin switching

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

Change #1172022 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Update the URL generation to prevent skin switching

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