After talking about this with @Keegan and scoping it with the Growth team, we've decided that we can't do this task for the coming year. The Growth team's bandwidth has been limited by being down one engineer, and since Echo is not currently built for one-off notifications, sending this particular notification would be a hack that would be difficult for the team to manage. @Mh-3110, thank you for filing this task and discussing it with us. I'm sorry we couldn't help. I leave this task with you to move it or resolve it as you see fit.

Hi @Kudpung -- thanks for following up on this. A volunteer wrote a patch to make this fix, and an engineer from the Growth team reviewed and merged it, so I believe this should be fixed on the wiki by Friday of next week! Please let us know if you see differently. Although the Growth team isn't always able to fit in work on PageTriage, we definitely try, and especially try to prioritize reviewing volunteer patches. Happily, that's what happened here.

This is ready for @nettrom_WMF to work on.

@EdErhart-WMF -- before we start this analysis, could you please add a comment with this information:

I approve -- @KStoller-WMF needs access to these tools to analyze data as part of her product management role.

Hello @Mh-3110. Thank you for filing this task. I want to ask some questions because creating one-off notifications is something that has been done only rarely. I think I remember that CentralNotice is usually used to notify editors about Board elections. Is this a new idea this year -- to send notifications? Will there also be CentralNotice?

I'm moving this to QA for now, but note there are other values that can be configured for add a link. Here's a list of configuration options we can easily add to the form – the current/default value for each of the options is in square brackets.

• desired task pool size (per topic) [500]
• minimum number of links for a task to be valid [2]
• minimum link confidence score returned by the suggestion algorithm for a suggestion to be valid [50 %]
• minimum time that needs to pass since last edit on the article for it to be suggested [1 day]
• minimum/maximum size of article for it to be suggested [no restrictions].

I'm not sure whether any of those numbers is also considered quality gate-related. @Trizek-WMF @Dyolf77_WMF @KStoller-WMF @MMiller_WMF – should we include any of the above-mentioned fields to the form?

We want to prioritize this task because of multiple communities feeling overwhelmed with patrolling link edits. We want them to be able to easily control the volume.

Thank you for filing this, @Etonkovidova. When this is solved, it would be great if engineers include on this task the date when the problem started occurring so we know which data it impacts.

@Sgs @Etonkovidova @Tgr -- I noticed something strange as I was testing these landing pages. I noticed that when I use a desktop browser to create an account from the mobile site, I get to the following page after account creation. This was on English Wikipedia, where I know the landing pages are not yet present. I did just by going to en.m.wikipedia.org/wiki/Special:CreateAccount without including our landing URLs. But when I went to create an account from my actual mobile device, it did not happen and things were normal. What do you make of this?

This has come to Growth team from iOS, for us to triage as a bug.

Thank you all! Yes, that's right @kostajh -- this would be an annual planned project. This ticket was just to begin the thought process, and we'll figure out when to actually proceed here.

In T307902#7913384, @kostajh wrote:

But if we wanted to suggest people link recommendation tasks about the article they are reading at the moment (the project name for this is "entry point in reading experience"), we'd need this data for all articles.

An alternative to caching recommendations for all articles would be to fetch data on the fly. Especially when limiting the max recommendations to a value of 2 (the minimum on most wikis), getting the data is something like ~2 seconds. Presumably anything less than 10 seconds would work from a product perspective, where a user is actually reading/skimming an article before seeing that there are possible changes to make?

Also, given that this would be shown to logged-in newcomers only (who would probably also be able to opt out of this feature, I imagine), the traffic should be manageable.

Assigning to @nettrom_WMF, who is working on specifying measurements so we can make sure to instrument the right actions.

Thanks, @HNordeenWMF. I made some of the details more specific on the task description, and now it's ready for development.

Thanks, @HNordeenWMF. I made some of the details more specific on the task description, and now it's ready for development.

I'm going to look over and double-check this task before putting it into Ready for Development.

@Tgr -- I have added the finalized mobile text to the task description, and put it under a different header than the desktop text. Could you please post what this looks like in your dev environment so that Marketing can approve before we backport?

This is something that we will work on in the coming weeks. It is not fully specified yet, but I'm moving it to the sprint board to prioritize it getting into Ready for Development.

I just added the text of the standard disclaimer to the task description, in both English and Spanish.

@Tgr -- I updated the task description:

In T305406#7831359, @RHo wrote:

@MMiller_WMF - can we also determine if those who have switched to "AND" logic end up selecting articles to edit more so than those who select topics in the default OR mode?

@nettrom_WMF wants to double-check that the fetch event happens when the user toggles "AND" and "OR", per T301825#7798417. i.e. checking whether the instrumentation implemented on T301825 is sufficient to do the analysis in this task.

When a Growth engineer picks this up, could you please let us know what the URLs will be for the two landing pages (even before the code is complete), so they can start being built into the campaign? Thank you!

@nettrom_WMF -- thanks for looking at this. You're right -- we don't have to align the groups. I suppose we came up with that as an alternative to having to modify the export script to take into account whether the user has homepage enabled. But the way you are proposing sounds good to me, too, if that works for @Tgr. To sum up, here's what I think we're saying. Is this right?

@Sgs -- it seems that the date of the Wikimedia Chile has changed to April 20, so I changed the title of the task.

@kostajh and I talked today, and we devised a new solution, which is the one we want to implement in this task.

Thanks for the clarifications, @kostajh.

@kostajh -- thanks for checking in. The issue that @Urbanecm_WMF pointed out seems like it would be an easy whether or not we have a control group for the emails -- even without a control group, there would be people who don't have the homepage that would then get emails encouraging them to go to their homepage and get started. What experience would those people encounter if they click on the link we created in T304805: Welcome emails: track homepage visits?

@Sgs talked about how it would be good to move this feature set to all users so that they can get the benefits, and so that we can remove code that reserves it only for campaigns. Therefore, this task is now Ready for Development. We need to make these changes first, and then we can move on to T305399, in which we'll deploy to all users in our pilot wikis. Then we'll do the analysis in T305406, and then deploy to all users in all wikis.

@kostajh -- thank you for checking, but there is not a concern around that. The change will happen to the treatment and control groups at the same time, so it won't affect the experiment. We'll just want to know exactly what day the change is in place so we can see whether the funnel analysis changes after.

Thanks for the links, @1997kB.

In T304747#7814146, @Trizek-WMF wrote:

In T304747#7812488, @kostajh wrote:

After the fix is in production, we'll start seeing the tags in RecentChanges, but we won't see tags for edits made while this was broken, unless we run, rebuildrecentchanges.php for that time period. I can ask around to see if it is feasible to do that, but because it is potentially a huge amount of rows to update, I am not sure if it is going to be a popular idea.

As it is limited to RCs, I think we are good to let things as they are.
At big wikis, the feed is too big: no one would (or can) filter out edits being a while ago. At smaller wikis, checking RCs is more likely done entry by entry. And they are other ways to check on recent edits: watchlists, Special:Contributions, etc.

@Etonkovidova @kostajh -- thank you for bringing this up. On this ticket, we did explicitly require that the next task should be an image task. We did this because if you are in the images treatment group, we want you to intensively be using "add an image" so we can build up data. It also makes sense to me that we relaxed that requirement for "add a link", because "add a link" is no longer in an experiment, so we want it to behave like all the other tasks.

@kostajh -- yes, @EdErhart-WMF and I decided we want to do this. I made the task here: T305015: Welcome emails: reserve control group

The ambassadors have completed their qualitative evaluation of the "wrong target" rejection reason, with the results here: T304178#7815289

The ambassadors have completed their evaluations, with notes on that task. Thank you!

The ambassadors have finished their evaluation in the spreadsheet. Here are the most important notes:

@kostajh -- just for our information, when this is fixed, will the diffs from the "bug era" show up in RecentChanges retroactively, or will it only apply for diffs made after the fix?

@kostajh @mewoph -- yes, thank you, that format is fine!