I guess it's lucky this didn't get resolved last sprint then.

@bmansurov I found the patch, but it had rebasing issues so I just abandoned it, rebased it manually, and uploaded a fresh one.

@bmansurov I'll be continuing work on it (although I don't think there will be many iterations anyways).

In T152004#2887732, @phuedx wrote:

@jhobs: Do those AC make sense?

Yep, looks good.

In order to properly track our sprint work and because this task was timeboxed, let's go ahead and resolve this.

In T147314#2877190, @bmansurov wrote:

@ovasileva if we pause, we don't have to log the page visibility information, do we?

Marking Normal, but please escalate to High if this turns out to be a regression.

@bmansurov @ovasileva The problem with this approach though is that if someone opens a tab to read later, then comes back to it after any significant period of time, our depth measurement is wildly skewed. If they leave it for over 100 minutes then we won't have any useful depth measurement at all. I know I personally open several tabs all the time when reading an article in order to read them after I'm done with my current one (especially on mobile). Pausing a timer when not visible ensures we get accurate logs, fewer irrelevant data points, and it's already been done and field-tested by another team, so it's a simple implementation (basically just copy-paste).

@bmansurov When you updated the schema, I noticed you added pageVisibility as a property, however, the Discovery team used that API to pause the timer when the page was hidden. Given a hidden page could generate a large number (currently 19) of unusable data points, would it not make more sense to follow Discovery's lead and only log checkin time, using the pageVisibility API to pause the timer? See https://gerrit.wikimedia.org/r/#/c/311844/3/modules/ext.wikimediaEvents.searchSatisfaction.js for Discovery's implementation.

My thinking was that from a design perspective, making the sidebar scrollable is far preferential to being able to scroll past the bottom of the workboard.

In T152223#2858633, @bmansurov wrote:

Any updates here, @jhobs?

Hi there @McIntireEvan, thanks for your interest in helping improve our codebase! Unfortunately, this task should have been marked "Stalled" a few weeks ago when we started working on a major rewrite of the Hovercards code, so I'm not sure there's much to be done here. There are, however, a few other tasks of similar complexity you could help us with, if you are so inclined!

• T124994: Vector should make use of deviceWidthTablet Less variable
• T145493: Some buttons in mobile interface don't indicate clickable target with pointer

Hey @leila, we're trying to line this up for this sprint, but it looks like we're still missing the following:

1. sampling rate (coverage)
2. definitive list of wikis to which the survey should be enabled (right now based on the description it would be eswiki only
3. date range to run the survey

@ovasileva @Nirzar please comment on whether we'd like to do this in the future or plan to decline. I've bumped the priority for now under the assumption we want to do this, but it's ultimately at the discretion of you two (it would probably need a new design too).

@Jdlrobson can you flesh out a description for this task? Right now it is unclear if moving this code out of MobileFrontend is worth the hit of requiring OOjs-UI. The best course of action may end up being a new design for this action flow, as @bmansurov suggested.
cc @Nirzar

This can probably even be Normal if you want @Nirzar.

@Jdlrobson do we have to ping anyone specifically to get this going, or is the fact that you added MediaWiki-Vagrant enough? (Asking for backlog grooming reasons.)

@Jdlrobson I updated the task to be clearer about my original intentions. If one of the AC has been completed but not the other, then we could split this task if needed for tracking work.