Mar 16 2018
Mar 15 2018
We could. Given the work that's on Readers-Web-Kanbanana-Board and the fact that this has been pushed back to "early Q4", we could wait a little while so as to avoid too much context switching.
Mar 14 2018
Mar 13 2018
👆 To be clear, I'm not suggesting that we don't get further estimates or slowly scale up collection. Indeed, the 700-800 events/s may be an average, in which case we're going to need to pay close attention as @Ottomata suggests in T184793#4048056.
@Tbayer estimated ~700-800 events/s in https://lists.wikimedia.org/pipermail/analytics/2018-January/006108.html. This estimate is based on data collected in the December 2017 Page Previews A/B test.
@hashar: Thanks for taking a look at the change. Readers Web are also interested in this topic in general as we maintain an extension that also uses a build step (Page Previews) (see T158980: [EPIC] Generate compiled assets from continuous integration). Transitioning to an automated build step would be a boon for us.
💪 Excellent work, @Ottomata!
Mar 12 2018
Mar 9 2018
Thanks for the heads up, @Peter!
^ Being bold.
This seems like @ovasileva's call.
Mar 8 2018
Given the comment history of this task, it's not clear that we've actually discussed this.
Mar 7 2018
Mar 6 2018
Or maybe @alexhollender?
I've reached out to SRE and Services to clarify where we are with deploying the mediawiki-services-chromium-render and what level of support we can expect in Q4. I'll update this task and all other related tasks currently on Readers-Web-Kanbanana-Board when we reach a conclusion.
During the Web Team Task Grooming ritual, I proposed that the Page Summary API should return three images: an image at 320px, an image at 640px, and the original. The client should only be responsible for deciding which image is the most appropriate to display to the user and requesting it, not deriving what the image's URI is – specialised knowledge of our image serving infrastructure crossing an API boundary.
Mar 2 2018
@mobrovac Did you sync with SRE about this task per last week's Audiences Services Sync meeting?
Thanks for the feedback, @Krinkle. You're right that the description was a little confused and I was aiming for "Make it easier to…" rather than "Open up…". I've updated the task accordingly.
Mar 1 2018
Feb 27 2018
Just popping in to drop this link to a detailed explanation of the time origin of HighResTimeStamps: https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp#The_time_origin
Feb 26 2018
Feb 23 2018
Perhaps we can remove the language variant part of this and just leave the Wikidata-specific part?
Excellent discussion and work all!
Feb 22 2018
☝️ Reflecting reality.
Can this be merged into T185139: Popups should respect user's language variant preferences, which seems more generic?
☝️ We'll be discussing this at today's Audiences Services Sync meeting.
We never really gave much weight to the treatment of thumbnails in the new service and perhaps we should've. Of course, this needs to be fixed for now (likely with a SWAT), but, ideally, there shouldn't be special handling for thumbnails in the client.
Feb 21 2018
☝️ Reflecting reality.
Feb 20 2018
I'm assigning this to myself as I'm on the hook for submitting a hygiene change to tidy up the pageview/page view verbiage across the codebase.
Feb 19 2018
Aside: That the above is a Phab keyword/meme, is as awesome as the hard work done for this task.
Over to you, @ovasileva!
Feb 17 2018
Feb 16 2018
Feb 15 2018
Feb 14 2018
^ Per T179552#3969087.
Feb 12 2018
As is, this task is worded precisely but I just want to be clear: let's respond with an HTTP 200 OK and a standard request body for a valid response with an empty extract property.