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.

@Aklapper Yes, I was specifically leaving my comment as the reason for resolution of the task. Like @Tgr suspected, the web team agreed this was most likely due to a temporary drop in network connection and is thus resolved.

This image loads correctly with the given parameters.

This has been implemented in beta mode for some time. We're currently evaluating the design and bugs associated with the feature before moving it to stable.

I believe it stays for about 2s, although I'm not certain. It's whatever the default timing is, so it should be the same as all our other toasts.

To reiterate from Sprint Prioritization meeting: I'm in favor of creating an npm module and including it as a dev dependency on any extensions we want to use the same test pages for.

In T150575#2793011, @MBinder_WMF wrote:

@jhobs Would you please indicate what this task needs to get out of Needs Analysis? :)

Elevating out of subtask.

@Jdlrobson this task has already been merged, signed off, and deployed. I think keeping this resolved and opening the bug as its own task is fine, especially since there were no mentions of multi-word titles in the design spec (I obviously still should have caught it though). We wouldn't re-open our original language switcher task if we found a new bug with it, for example. ;)

FYI, it's on our (the Reading Web Team's) radar to build Wikidata support directly into the extension. It may take a while as we're currently refactoring the extension, but just wanted to let you all know that this incident didn't go unnoticed. :)

It's a bit difficult to tell what you mean by your description. Can you be more specific about what you're expecting to see and what you're actually seeing? It's unclear which order the screenshots are in (I'm guessing left is expected).
@Iniquity

In T149801#2785804, @bmansurov wrote:

@jhobs, isn't Hovercards disabled when the gadget is on? The problem with Wikidata yesterday was that it was serving old JS files.

We should consider adding "works on Wikidata" as a requirement. Right now Wikidata uses a gadget to make Popups work, which recently broke after some of the earlier refactoring we did on master. It will, of course, break again with the larger refactor, so we may want to think of Wikidata support early on. I think all the the gadget does is add more classes to the link selector and then call a bunch of functions manually.

In T149801#2783011, @bmansurov wrote:

What are the downsides of using RxJS and Redux?

In T146293#2773093, @Catrope wrote:

git review -d is broken for me too, but only for https remotes. If I manually rewrite the remote to be ssh, it works.

@Jdlrobson Yeah that confused me at first too. Disambig-related redirect text is left intentionally. :)

In T126825#2777719, @pmiazga wrote:

let me add one more hygiene task

In T131105#2761299, @dr0ptp4kt wrote:

For existing consumers of the API, will it "just work" without having to change anything in calling the API or inspecting the JSON object?

We decided to proceed with option 2 in T131105#2714458. This would mean that getting a free and non-free image would require two requests. I'll be updating the description to reflect the decision shortly.

I believe all of the associated patches have been merged!
/cc @bmansurov

Was moved on the wrong board.

Per a discussion during kickoff, we will be continuing this task as-is and addressing the identified editor use case in T150189: Make toasts tappable links when redirecting a user away from a page. This means https://gerrit.wikimedia.org/r/#/c/319323/ is ready for merge per the review on the task.
cc @bmansurov @phuedx