Wed, Oct 6
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.
Mon, Oct 4
I believe we completed this task.
Repurposing this as a potential end-to-end test case for the Metrics Platform.
Sep 13 2021
Aug 30 2021
Aug 23 2021
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
Aug 11 2021
Jul 26 2021
Jul 21 2021
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
Jul 14 2021
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.
Jun 30 2021
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.
Jun 2 2021
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