Ok thanks @sdkim - in that case it sounds like the "purpose" in the task description ought to be changed

The Android team's MVP needs to filter out certain kinds of articles (disambiguation pages, years, and lists). This filtering will be handled upstream by the API for articles except the ones the MediaSearch results.

Initial work on this done, to finish it we'll need T260832

@CBogen can we close this? There doesn't appear to be any community demand for it, and we're not planning to do it anytime soon

@dcausse tbh I don't know exactly what relforge does, but as you know we've gathered a set of labeled search results, and written some code to compare resultsets from different search algorithms (see T268653). Will this ticket add anything to that?

And here's the generated ranklib file

Done, see https://github.com/cormacparle/media-search-signal-test

Numbers 1 and 2 done

This is done, and the data has been passed to the search team ... I still have to clean up the code enough to make the process repeatable, once that's done will close this ticket

Fantastic! Thanks @AikoChou

Min is zero, but there's actually no maximum - sorry! This is one of the things that makes elasticsearch difficult - scoring is on an open-ended scale

Yes we can begin it, though as the description says we can't complete it until the PoC is ready

Moving this into blocked for the minute, as we now have a more complete dataset that's being analysed atm, and would like that to complete before this is implemented

Yeah, automatically at the end.

Hey @ArielGlenn this has been in our code review column for a long while now, you reckon you'll get to it soon?

Funny enough myself and Matthias have been talking a lot about this already this afternoon, and the "MediaSearch with statements ...." column still will find things in those fields, it just won't use the fields for ranking the results. So maybe we already have what you want?

Also, what is the "suggest" input?

I moved this into "doing" because myself and @matthiasmullie have been talking about it, and I've been doing some prototypes to figure out what works, and I wanted to make the discussion more public

In T271933#6745342, @Krinkle wrote:

In T271933#6744789, @Cparle wrote:

patch merged to the branch that we think will fix it

For future reference, patches must not be merged in wmf unless they are currently being deployed by the person merging it. The branch is meant to reflect current production. To schedule or propose a patch for deployment, creating the cherry pick suffices, possibly using backport windows on the Deployment calendar to request someone else to deploy it (if not yourself).

@hashar patch merged to the branch that we think will fix it

Looking ...

I can't find a reference to formatNum anywhere in the MediaInfo code, so I guess this is not ours ... there's a formatNum template that's used in the French translation of wikibasemediainfo-special-mediasearch-empty-state

Just on AC number 3 - we (structured data) are currently kinda doing this using https://media-search-signal-test.toolforge.org/

Here's the current number of ratings we have for each search signal

First step - think about what structured data we might want to store for a wikipedia page

@Cparle, could you tell us a bit about your tool? Where do the matches come from? How many are there? Does it record the user's responses?

@AnneT the config patch has been merged so you're good to go on the UI patch. Options are

My updated understanding of what's going on here:

to do: setup cron script once patch is merged, see https://wikitech.wikimedia.org/wiki/Cron_jobs#mediawiki::maintenance

Would be good to set this up to run on a regular basis