Well, if both will download both this won't actually help :/. What we'd do on literally any other part of Wikimedia's infrastructure is rely on the fact that the platform detection in our varnish caches redirects people to *.m.* as appropriate, which it doesn't do for the portals. I was seeking to distinguish the files so we could also look for file download, but if both files are going to be grabbed anyway that won't actually do much :(. Ah well.

I don't understand your example. If you'd rather read the French Wikipedia, then your preferred language is...French. For the purposes of browsing Wikipedia, at least.

We're only collecting for Goal 1 at the moment since Goal 2 has privacy implications.

Note that Michelle and Dario have both now given permission in email for this to go ahead.

Sounds good to me!

Because they're not "production" wikis; the goal was to avoid counting meta-pageviews (chapter traffic, say) towards our metrics.

I think we covered the grafana question.

@Mpaulson , @DarTar : if you could sign off here (or not) for max transparency?

@ori if you're looking to make changes to the EL here I'd suggest open a new task rather than tweak the priority on a resolved one.

Accelerating to Michelle at this point.

Hey, I said I was probably wrong! :D. I'll wait until the Engineers wake up; presumably they know.

I didn't think we'd moved them? I might be wrong (I'm probably wrong)

We are hoping to be able to switch away from pageview-based ordering, which is why it hasn't been.

Now got this working!

I'm not sure if moving is necessarily the solution. Like, this should eventually live in those dashboards.

*thumbs up*

Blocked still on the output :/. Mikhail, I'll need ya when you get in to discuss beeline (some time after 12am PST; I'm giving a talk this afternoon hence why I started work at 8am)

Krenair, it doesn't _matter_ why he's reopening. The manager/task-setter of the team that is tasked with this class of problem reopened it. Making the determination of if it gets worked on is his job, not yours. You should read Karen's comments above.

Currently blocked on some reaaally weird hive output.

IIRC the resolution for this was not to merge them, but to work on this independently (since it's more viable than the other)?

Yeah, that makes sense to me. Thanks Julien and Deb :)

Poking Legal, again

That needs to be discussed with Legal. "our data said you did a thing so we contacted you privately/publicly about the thing revealing data in the process/using other data in the process" is an area that has traditionally been ehhhhh.

@Deskana This is the card for creating the actual data collection scripts. The visualisation is a different still-being-worked-on ticket. The data collection is deployed.

Minor versions would massively increase the size of the dataset. Should I read the above as "major versions only" or "major and minor, split"?

Well, how many people are opted in to the completion suggester?

We're going to work on this ticket and update the links. Just to be transparent our next project is an A/B test to use language settings to sort and order the links - https://phabricator.wikimedia.org/T121567 . If it goes well the article-sorted counts may be deprecated (following the testing and discussion of the results)

Cool!

We do on the varnish caches, at least.

So, I'd strongly suggest:

Sounds fine!

I don't have the background here. Is this for the existing beta or some test?

Have pinged her in the email thread and CCd you in.

Can I suggest adding the blocker tasks?

Should now be done!

I'm not quite sure what you mean. I'm addressing Julien's comment, which replaces the EL searchSessionId field with "mw.user.sessionId() . '-' . mw.user.generateRandomSessionId();". Unless my JavaScript is incredibly rusty that's concatenating the ID we currently use with the ID QuickSurvey will use, in a single field.

I'd much rather add a new field entirely. If we add a new field I change one variable in the dashboard code. If we change the contents of the field I have to rework the dashboard code to split strings and loop through grabbing the first half before doing anything.

They do!

Indeed!

Because being able to see what proportion of queries have common syntactic attributes is a great way of being able to identify repetitive automata and/or identify what features are worth testing - nobody cares about a tweak on the OR operator if it's only used sixty times a day.

We have spent more time discussing it in sprints than we have actually working on it, which is also more time than has been spent getting the data collection going. Given that this has been stalled for over a month I'm marking it as declined. Dan, if you disagree, just open it again.