@Michael , should I go ahead and mark this task as resolved, since logstash hasn’t shown any errors for over a week? Also, should we resolve the associated tasks at the same time, or wait until QA formally closes them? cc : @Sgs

Picking this task since it seems somehow related to T369312.

@Urbanecm_WMF,
I'd lean on option 4 for now, test the subfeatures in CI so we at least catch the exact regression we just fixed and maybe pair it with option 3 that runs against beta or testwiki on a daily/weekly timetable to cathc other cuases. Longterm we should work towards option 1 as it's the ony option that truly removes the false choice between core and CentralAuth coverage.But it's a RelEng-level investment, so it needs to be pitched as a cross-team infra project, not a Growth-only need. I'd avoid option 2(CI for one extension) because of the relEng pushback and even if approved, we'd inherit maintenance tax everytime CI changes.

In T386116#11038614, @Michael wrote:

In T386116#11020403, @Cyndymediawiksim wrote:

@Michael , i added the alerting to mediawiki_GrowthExperiments_image_recommendation_provider_seconds_bucket to show data-pipeline issues that do not affect the weighted tags in the search index.. Would you mind taking a quick look? :)

Thanks, but I don't think this is tracking the right thing. Specifically, what we are concerned about is that the api might return no results, and thus the processing might be extremely fast. So, probably a better value to alert on might be whether it is <10ms, given that it is usually 200+ms.

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
https://test.m.wikipedia.org/w/index.php?title=Special%3AHomepage&namespace=0#/homepage/suggested-edits/openTaskTypeDialog 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?

Updating this to 3 due to increased scope

What's the conventional tool to keep a chart for a long-lived product health metric captured through xLab.

Grafana - Time-series chart.
cc@Sgs

In T400118#11028286, @Michael wrote:

In T400118#11027138, @AAlhazwani-WMF wrote:

note for engineers: i'm unsure if this is a regression but the current get started notification includes the copy "Try other edits" from our work on T398262 instead of the original copy which is "Try suggested edits"

Yes, that looks like the regression Elena found in T398262#11002681. But my change to fix that had been merged last Tuesday, so I would have expected this to be fixed on testwiki by now. Maybe that needs a bit more investigation.

@Michael , i added the alerting to mediawiki_GrowthExperiments_image_recommendation_provider_seconds_bucket to show data-pipeline issues that do not affect the weighted tags in the search index.. Would you mind taking a quick look? :)

Thank you for tagging this task with good first task for Wikimedia newcomers!

I did an archaelogy into why users are incorrectly redirected to the Welcome Survey instead of returning to their editing session after account creation. My analysis on adding some logging to WelcomeSurveyHooks.php :
Edit Source (Working):

• returnToQuery: 'action=edit' ==> PRESERVED
• userWasEditing() result: true ==> DETECTION SUCCEEDS
• onCentralAuthPostLoginRedirect() user was editing -> preserving return parameters and exiting

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

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

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

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?

@Michael, quick dashboard-hunt question:

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

@Seddon , the notifications are being sent to a slack channel

@Urbanecm_WMF , I had a quick question, for this AC:

- check that Growth Engineers + Mobile App engineers actually get the alert emails (Who exactly? Only devs? QA? EM? PO?),