User Details
- User Since
- Oct 6 2014, 10:27 PM (539 w, 5 d)
- Roles
- Disabled
- LDAP User
- Jhobs
- MediaWiki User
- JHobson (WMF) [ Global Accounts ]
Jul 2 2019
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
Yep, looks good.
Dec 15 2016
In order to properly track our sprint work and because this task was timeboxed, let's go ahead and resolve this.
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.
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.)
Nov 30 2016
@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.
Nov 29 2016
Nov 22 2016
Nov 21 2016
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.
Nov 16 2016
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.
Nov 15 2016
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.
Nov 14 2016
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. ;)
Nov 10 2016
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
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.
Nov 9 2016
Nov 8 2016
@Jdlrobson Yeah that confused me at first too. Disambig-related redirect text is left intentionally. :)
Nov 7 2016
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