@MNovotny_WMF, @JKatzWMF, and I discussed the timeline for phase 3 today and came up with the following plan:

• I'm expecting to start working half-time on the project at the start of September (possibly with initial exploration before that).
• We will meet again midway through September with more knowledge of the project to set a firmer timeline.
• We hope to have something shareable by the end of September.

I don't see any signs of continued interested in this analysis.

This has been superseded by the Audiences-wide on annual plan program metrics.

Hah, okay, I guess something can't be in ContentTranslation and CX-analytics at the same time.

Thanks @Pchelolo! This will be super helpful for us.

Okay, that's quite disappointing. I think we need to discuss this more in our team meeting today, but some initial comments:

In T201062#4477232, @Milimetric wrote:

I see @chelsyx. We only save the user agent string in one place, the recentchanges and cu_changes tables. Those are sqooped and processed for the new geoeditors dataset, so there's some parsed user agent data per user-id / user-ip. But all of this is deleted after 90 days. So we don't have data going back too far. We would need to make a job that would look at these two datasets together and convert the tags if necessary. That could be done as part of the sqoop. I'll add that code here and you can review it if I forget.

@MMiller_WMF, would this still be valuable? If so, @Nettrom would probably be the person to take it on now.

@Nettrom, just so you know, if some of these links make your eyes glaze over or you want more backstory on a topic, I'm always happy to explain what I can face-to-face in one of our onboarding meetings (and you are very welcome to schedule more).

In T196110#4463166, @DarTar wrote:

1. What do we want to know? (i.e. the research question)
2. Why does it matter? (i.e. what happens if we answer this question? who cares?)
3. What are existing data sources that could help answer this question? (this may be relevant to people – future interns, external researchers, new f/t researchers being onboarded– exploring existing data one could use to work on this idea)

In T185355#4456115, @Ladsgroup wrote:

(probably it's better just to ditch the whole thing after we properly normalize change_tag, what do you think @Catrope ?) I would suggest you to use change_tag_id in change_tag table instead, give that it's a number instead of string, querying and grouping it would be faster.

This is not a very actionable request. We currently have a profusion of dashboards which provide some metrics that might help to answer this question, but it's not clear what additional ones this request is asking for.

This is not a very actionable request. We currently have a profusion of dashboards which provide some metrics that might help to answer this question, but it's not clear what additional ones this request is asking for.