Outstanding! I can't wait to try this out. Hearty congratulations to all involved shipping this feature.

Here are my notes on the Android (Java) implementation as of rMLMP7ceb5cbb9e75: Simplify event queuing by using a single buffer.:

@cjming: I think that this task would be a good entry point into the Metrics Platform repository, specifically where the JS and PHP clients are similar and where they differ.

Being bold and moving this back to the Backlog. Without additional context, I'm tempted to decline this. @EChetty: What do you think?

Status update: The instrument was enabled on testwiki ~10 days ago and, as of this morning, the event.mediawiki_edit_attempt Hive table now has 400+ rows in it. Is this enough to double-check the shape of the events that are being logged?

Status update:

In T317682#8251384, @Jdlrobson wrote:

Regarding the instrumentation, tracking these as a submit event instead of a click also seems a bug, so that sounds fine to me.

Is there anything that I can do to help?

I stumbled across this task while finalising T316229: Decommission the ContentTranslation instruments using legacy EventLogging schemas, which decommissioned all of the legacy EventLogging schemas that hadn't been migrated to the Event Platform. The last remaining reference to those schemas appears to be limn-language-data's reference to ContentTranslationError, which I think can be safely tidied up. Am I correct? If so, I can submit the patch to do so.

Being bold.

Mark the schema as inactive

Being bold.

Being bold and resolving this because:

In T295619#8224268, @phuedx wrote:

The cookies that the instrument sets are session cookies, which should be cleared when the browsing session ends. In practice, however, that isn't the case, e.g. Chrome, Firefox, and Safari (at least) all allow you to resume a previous browsing session complete with session cookies. Remembering that the instrument ticks once every minute, a user could end their browsing session and resume it at any point in that time window and, from the point of view of the instrument, be continuing their session. Switching to localStorage would make the above scenario more likely since it persists between browsing sessions but at least it would be consistent.

In T311268#8229839, @Jdlrobson wrote:

@phuedx can this ticket be resolved now? I think we're done, right?

[The] Metrics Platform Clients should all be updated to capture the salted, hashed user ID whenever the performer_id context attribute is requested

In T286344#8227782, @Ottomata wrote:

I think there are action API usages out there that set all_settings=true, but IIUC that param will just be ignored now, and all settings will always be returned, right?

Being bold. Sincere thanks to @Ladsgroup for merging the patch.

Being bold.

In T295619#7732091, @Krinkle wrote:

@jlinehan Could you review the above and assess the possibility of storing the volatile tick time and tick count outside the cookie?

In T315674#8214559, @gmodena wrote:

My understanding is that yaml is the only format actually in use. If so, I think there is no point in supporting both; I'd lean towards the path of least resistance (even if suboptimal) and deprecate json support.

In T311015#8028198, @Krinkle wrote:

• Chrome warning (5x): Error with Permissions-Policy header: Unrecognized origin: 'intake-analytics.wikimedia.org'. Error with Permissions-Policy header: Origin trial controlled feature not enabled: 'interest-cohort'.. This is unrelated to QuickSurveys.

@Nikerabbit: Code review would be welcome :) I was planning on reaching out to any/all WMF engineers for help as I have done with other instruments.

Being bold. Thanks to @ppelberg for following up on whether the instrument should be decommissioned or migrated and to @Jdforrester-WMF for merging the patches.