Jul 2 2019
Jun 11 2018
Jan 6 2017
I guess it's lucky this didn't get resolved last sprint then.
Jan 5 2017
@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).
Dec 19 2016
Dec 15 2016
In order to properly track our sprint work and because this task was timeboxed, let's go ahead and resolve this.
@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.
Dec 14 2016
@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.
Dec 12 2016
Dec 7 2016
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!
Dec 5 2016
Hey @leila, we're trying to line this up for this sprint, but it looks like we're still missing the following:
- sampling rate (coverage)
- definitive list of wikis to which the survey should be enabled (right now based on the description it would be eswiki only
- date range to run the survey
Dec 1 2016
@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.
This can probably even be Normal if you want @Nirzar.