When picking this up, make a post in #talk-to-web and CC the author of the ticket to make sure this is a priority to be done, per our established norms

can be done in parallel with T378115, but worth coordinating to make sure we understand how to gate effectively

Changing the spirit of this ticket to be:

• help with the parts of legal review that are not on our team (session length mixin, ensuring it gets done and liaising as needed)
• legal review for the more common metrics that we typically go through legal review for

Reminder to double check day of with @sgrabarczuk!!

@Ioaxxere sounds like you might need to clear cache - are you still not seeing it?

Sounds good! I'll never argue against more points haha

I like 5 here

I would propose bumping this down to a 2 and then creating a separate ticket for removing the now-legacy code that depends on this one (which I would point as 2-3)

DST may have different story point conversion rate, so if we are hoping for them to do this ticket we might not want to provide a point estimate (unless I'm misunderstanding and this is the estimate for us incorporating their change, in which case I think the estimate is rather high)

Would this include any level of data analysis?

I'm not the most familiar with this area, but I'd vote for 5 over 3

Thank you! I've updated the task description with this information

Questions to guide our implementation/understand scope:

1. Will there ever be more than two groups (control/treatment)?
2. Do we need the ability to do a percentage based rollout?
3. Is there ever a situation where control and treatment are unevenly distributed? (note this makes analysis near impossible)
4. Do we want to opt in individual users (us) to the experiment?
5. What is the exact target audience of the experiment (logged out/which wikis/etc)? Will it change?

Apologies for the delay, will review this today

I think this makes sense, and in general I'm all for adding more monitoring/(actionable) alerts! What would you imagine as an initial threshold for the alert?

Thank you for revisiting this @Peter!

Best prod test cases are most pages on swedish wikivoyage

@LMora-WMF has expressed interest in pairing with whoever picks up this ticket to learn more about our deployment methodology. Please consult them when assigning yourself so you can work together on it!

We seem to all agree on 2 - also noting this is going to slip (sorry!)

Created T379214 - this should now be ready for signoff!

I've spent the last few days thinking about this - I think we've got a couple of options if we want more detailed metrics, although both of them have tradeoffs:

1. We could use eventlogging: the issue here is that we don't want to confuse people with adding new logs (specifically init) that would mess up others' data. We could potentially use an existing field to distinguish browser extension logs or add a second init_browser_extension log to the events extension, but we'd have to think through the implications
2. We could use prometheus: It seems likely that prometheus would support this level of granularity, and it's the long term direction of our monitoring infra as well. The issue here being that we would need to set it up, and I don't think any of us have a great sense of what that would entail

Makes sense! @ovasileva question for you then - while I look into whether event logging can be used to answer some of our stretch goal questions without disrupting the existing table structure, are we unblocked on the initial question of whether statsd can be used to answer the most essential questions? If so, is there any way I should reflect that in the ticket?

Somewhat fake move to code review, but I recall we wanted at least initial results by Monday so signaling that that is done (here)

As I'm gonna be out Monday - what, if anything, is preventing us from using event logging for this? It seems like the web_ui_actions table has all the fields we're looking to slice by. Metrics aggregators like prometheus and graphite seem to be mostly for counters in situations where structured logs would overwhelm logging infra - is there a similar problem here, or could we be firing logs for interactions with the browser extension?

There is also the conversation to be had about graphite being in the deprecation path, but I'm guessing we're cool to keep using it at least for this quarter

First question (can statsd instrument the most necessary metrics):

• yes
• we can count pageviews where summaries are displayed and pageviews where summaries are opened, then divide in grafana to get the percentage
• we can increment counters for "yes" and "no" similarly

Whoops I've been doing this one

Holding onto this as a potential onboarding task

Ran

SELECT day, count(*)
FROM event.DesktopWebUIActionsTracking
WHERE year = 2024 and month = 10
group by 1 order by 1 asc

and can confirm the 15th is the last day we have events!

Believe this is no longer blocked

@Jdrewniak does it make sense for you to QA this? We can also move directly to signoff I suppose

Hi @TAndic! I'm not an expert on this code, but Jon is indisposed right now. I spent a little bit of time reading through it and I'm pretty sure you're right that that line is where we're checking - in addition, I can confirm we're not using isNamed anywhere in that codebase, so it stands to reason that we're determining anon status using the isAnon method. Let me know if there's anything else we can do to help you!

@bwang I believe I was referring to Jon's comment from last year:

It's currently by design that we use different preference keys for font size on different skins as the assumption is a user may want a different font size on mobile and desktop. If we want to change that this would require substantial refactoring so we should check on the requirement.

@ovasileva no rush, but if you don't mind weighing in on prioritization here (is medium good, and should it be in this sprint or next?)

Thank you! I'll talk with @ovasileva about prioritizing these

@Pcoombe that would be great! We'll have to prioritize it and figure out with the team where to put user page links in general vs the appearance menu, but having that tracked would help (thank you!)

Another example of this: https://en.m.wikivoyage.org/w/index.php?title=Toyooka&useparsoid=1

@ovasileva would be great if we could talk about this during estimation on Thursday!

We discussed in sprint meeting and the new plan is to deploy back to pilots on Thursday, after the train has rolled out, and then all wikis on Monday the 23rd

Read through the backscroll and I understand the issue now - created T374753 and signing this one off!

Sounds good! I will read the above and create a new ticket, then sign this one off with a link to the new one

For Olga: this is now blocked on T373566, but we should be in good shape to do the pilot wikis on Monday (meaning this only got pushed back a week), with a subsequent rollout on Wednesday if things look good

For Olga: status of this one is that we had to do a little scramble this week because we figured out the hook we were using had a bug in it (more accurately, we introduced a bug by using it). The correct hook is now in code review, and will hopefully wrap up this ticket

This also looks good!

Looks good! Confirmed no more page jumping

This has been deployed!

feel free to assign back to me when you're done reviewing!