In T291353#7448702, @odimitrijevic wrote:

@jlinehan @dr0ptp4kt putting this on your radar again.

Done

Closing since we have a regular process for meeting and communicating set up

Closing this s we've moved on to more specific tasks and have de facto formats in the library code now.

Will examine this during end-to-end testing.

We completed this task and had a meeting to discuss the results.

Repurposing this as a potential end-to-end test case for the Metrics Platform.

In T288660#7278894, @Mholloway wrote:

Per https://www.mediawiki.org/wiki/Manual:SameSite_cookies#Browser_warnings it looks like these warnings can be ignored, as we have no need to send the cookies in question in any cross-domain AJAX requests.

Closing this since the spike is complete

For a recommendation on our migration strategy as it relates to Vue, I need to hear more about the migration strategy for the Vue upgrades themselves. That will inform a lot. When I know that, I will update this ticket again.

A preliminary review of the instrumentation needs for each of these can be found in the following table https://docs.google.com/spreadsheets/d/1wKd7HKc4RNRBl9L-5WQqrR45e5dd0juj-fu9KGMCkjg

Picked this up, started learning more about Vue.js in order to understand it better from the developer perspective to start with. Will be following up with more.

In T276379#7175884, @mforns wrote:

I second @JAllemandou!

One related question: Are all fields specified in the schema going to be collected by default?
I recall that the collected fields would be specified in the extension's configuration? Is that correct?
Will they be enabled in groups (i.e. add all user fields), or individually?

I mention this, because the schema contains a lot of privacy-sensitive fields:
pageview_id, session_id, and app_install_id, page.id, page.title, page.wikidata_id, page.revision_id, user.id, user.name, user.groups, user.edit_count, user.registration_dt.
I would argue in favor of not collecting any of those by default, even if we can delete them later, following the privacy-by-design principle.

In T88399#7137078, @Aklapper wrote:

Could someone answer this please?: Has this ticket been superseded by Metrics Platform Backlog / Better Use Of Data nowadays?
Does this task still serve a purpose nowadays, or can it be closed?

In T284147#7129127, @Ottomata wrote:

FYI, I don't think supporting UNIONTYPES is going to be possible. It isn't just Hive that has to work with this data.

My preference would be for one of options B, D, or G, in order of increasing flexibility. My sense is that Option G would be able to accommodate the vast majority of data fields that people will want to carry, namely:

• basic types (integer, float, string, boolean)
• arrays of mixed basic types
• objects mapping strings to basic types