In T187277#4053113, @Ottomata wrote:

To be specific though, I'd word this differently, and say that the VirtualPageviews should match Pageviews, not necessarily wmf.webrequest.

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.

In T187277#3982615, @Tbayer provided clear reasoning as to why the logging and consequent aggregation of VirtualPageviews events should match that of the wmf.webrequest table.

In T187277#3973952, @Ottomata wrote:

Given that EventLogging collects neither unique identifiers not IP / useragent by default

Aaannnnd to support this page previews project, IP is back (not in MySQL db because it's complicated) in order to geocode! See T186833. Both will be purged within 90 days.

Perhaps T187916#4048427 will help when it comes to planning for T159262: [EPIC] Improve page issues.

👆 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!

@bearND, @Mholloway: Does the Page Summary API support removal of <$tagName class="noexcerpt"> elements as laid out in T91344#4036824?

Thanks for the heads up, @Peter!

In T186748#4028238, @phuedx wrote:

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.

^ Being bold.

This seems like @ovasileva's call.

@Jdlrobson I agree with UBN! Content is still visible and the users can still interact with the article but we're fundamentally changing it by (accidentally) reordering paragraphs /cc @ovasileva

Per T188636#4033021.

In T188636#4032626, @bearND wrote:

That's another use case for T66214: Define an official thumb API.

Given the comment history of this task, it's not clear that we've actually discussed this.

Per T186748#4028238.

Per T186748#4028238.

Per T186748#4028238.

Per T186748#4028238.

Per T186748#4028238.

Per T186748#4028238.

Per T186748#4028238.

Per T186748#4028238.

/cc @ovasileva @pmiazga

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.

In T183833#4025462, @bearND wrote:

Isn't the plain text version still used somewhere or is that all old code that should go away?

@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.

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

Perhaps we can remove the language variant part of this and just leave the Wikidata-specific part?

In T187821#3994402, @Niedzielski wrote:

1. Install Proton to a virtual machine.

Excellent discussion and work all!

☝️ Reflecting reality.

@Niedzielski will be updating the task description after chatting with @Pchelolo and @mobrovac in the Audiences Services sync.

@ovasileva: I was going to be bold but I notice that the mocks in this task aren't on any other tasks (including T111231: Page previews for Wikidata). Could/should we refer to them there?

Can this be merged into T185139: Popups should respect user's language variant preferences, which seems more generic?

In T187955#3992222, @phuedx wrote:

I guess that we should figure out whether this is actually necessary, i.e. could we only request a thumbnail at 640px? If it is, then can the service deliver a set of thumbnail URLs with meaningful names <snip /> so that the client maps device pixel ratio to a name instead of manipulating strings.

☝️ We'll be discussing this at today's Audiences Services Sync meeting.

Reflecting reality.

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.

☝️ Reflecting reality.

https://grafana.wikimedia.org/dashboard/db/eventlogging-schema?orgId=1&var-schema=Popups&from=1519225439000&to=now LGTM 👍

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.

Aside: That the above is a Phab keyword/meme, is as awesome as the hard work done for this task.

Over to you, @ovasileva!

In T67079#3958406, @ovasileva wrote:

In signoff column until change is live on all wikis (Thursday, Feb 15th)

In T186728#3975127, @phuedx wrote:

I'll open a ticket with Readers Infra about adding namespace ID to the response. Working around a lack of data in the response by sending partial data from the client and reconstructing it on the server feels like knowingly introducing technical debt by splitting the implementation of the virtual pageview data pipeline across an API boundary (the EventLogging pipeline).

In T184534#3967535, @BBlack wrote:

Do we want to allow stale content in the UA's cache here, for up to 5 minutes past the expiry?

In T186728#3974261, @Jdlrobson wrote:

Inferring title from url can be done too but given that a preview is happening title or page_id should be available right ? as that content was retrieved from content service.

The page_id we are interested in is the page_id of the /target/ page. The only information we have available is that in the response: https://en.wikipedia.org/api/rest_v1/page/summary/San_Francisco - so we'd be able to get page_id and title but not namespace (but can derive namespace from title). My question is do we need to? I'm not sure what pageviews does, but would it be more consistent to calculate those the same way as they're done in pageviews?

In T182314#3966963, @Jhernandez wrote:

It is very hard to reason about this, it could be worthy to reach out with the data to the Mozilla or Chrome folks and just ask to see if we can get proper reasons for it.

^ Per T179552#3969087.

In T186933#3964347, @Mholloway wrote:

Maybe no-extract? none could be read to suggest there is no type, which would be confusing.

Chromium, a dependency of the project, is packaged by Puppeteer and as an outcome of T178189 and T178570, Puppeteer's installation process should not be tampered with. i.e., npm install should be permitted to execute normally.

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.