The source code for this has been forked into the Wikimedia organization on GitHub:

meets user needs

One possible simplification: What if we just test different theories on different wikis?

There is also the several days to a week it takes to fill a new index (for enwiki)

Ah, that makes sense, thanks.

If a user follows the "did you mean" link to a result, do we consider that a zero-result? Or do we only consider a dead-end to be a zero-result?

Is EL the way to go for this collection?

This one might be too much complexity to be worthwhile, but could we duplicate the Elastic cluster, and have Cirrus search one or the other based on some client-side selection criterion?

get their heads together and make a list of the 10 things that impede them the most

Analysis task?

Awesome, thanks! I'll copy them into the task description.

What are the requirements that this hardware is needed to satisfy?

blocked on operations to deploy stuff

I dig all of the above, however I have noticed in roughly every single meeting that we're severely inhibited by our developer flow. I recommend we take some time to streamline our software development process, automate as much as possible, and head ever toward continuous delivery.

Tomasz is out on family leave; bumping up to Wes.

If all I want to do is write Hive jobs, do I still need such high-level access, or can I get something more limited?

Did @Ironholds say something about analyzing these separately from the rest, and that both still came up with a 25% no-results rate?

With the revised context of this task, I suspect we don't need EventLogging instrumentation at all, assuming we can get access to the HTTP request logs from Varnish (or wherever) HDFS.

The zero-results logs have lots of prefix searches -- are these from typeahead searches run automatically from the search input box, or did folks search for these literal phrase fragments?

Are these messages coming from master, or non-master? Could we simulate/debug this by forcing network timeouts between the two?

and setup the external 'MediaWiki' account

Here are my thoughts/recommendations on the above, to be discussed next week:

@EBernhardson thanks for the copy/pasta. I'll get it queued for the Thursday 18:00–20:00 UTC SWAT.

@Smalyshev The first thing that the bigBang() test does is update(1,1) which appears to fail with the above message, but only on Jenkins.

This is happening during the Big Bang test, and I can't yet figure out why:

How do we make the configuration change in production to enable this on enwiki?

This is coming from the blazegraph subproject:

Based on feedback, we need to iron out some acceptance criteria before we can proceed:

Status: awaiting approval/deployment by a Meta admin: https://meta.wikimedia.org/wiki/Talk:Www.wikipedia.org_template#Add_EventLogging

Reviews:

Status: awaiting approval/deployment by a Meta admin: https://meta.wikimedia.org/wiki/Talk:Www.wikipedia.org_template#Add_EventLogging

Do we need to edit *includes/specials/SpecialSearch.php*, or is there a way to do this via a template?

https://en.wikipedia.org/wiki/Template:Disambiguation

Houston, we have IE support. That's a "go" for both IE6 and IE7.

• Who's "the community" in this context?
• What are they using the search APIs for?

It follows from the preceding steps:

Ok, I think we're pretty close now. No Beacon API required, yet it should still wait for event.gif to be loaded before proceeding to a new page.

To be determined: the rate at which we want to log events from the Wikipedia Portal -- it might be an enormous amount of traffic.