[17:35:29] Just added a few of you as reviewers for https://gerrit.wikimedia.org/r/#/c/238825/ -- the MediaWiki extension -- pretty close to usable, I believe. [21:26:26] awight: do you mind if I amend your patch? [21:28:12] awesome! [21:28:22] when is Wikimedia AI going to be made into an actual department? [21:28:24] :> [21:28:27] Feel free to squash too, I don't think the evolution is too important [21:58:23] harej, BTW https://phabricator.wikimedia.org/T99046 [21:58:33] Oh wait.. you're already a subscriber :) [21:58:52] halfak: yeah, holler if you have any feedback on the db model! I figured we should make it comprehensive, if we're taking the trouble to cache data for every revision. [21:59:19] But if we never plan to use the non-winning scores, I would trim them out of the db. [21:59:30] awight, will do. I have one more meeting today, an analysis process to kick off and then I'll scope it out. [21:59:44] take yr time [21:59:54] awight, if we include article quality scores, we might want it. [22:01:22] yeess. [22:01:43] Might make for pretty onHover popups, anyway. [22:01:55] Data is cheap! [22:01:59] :D [22:11:04] awight: ok, I'm going to sqash them then [22:22:48] awight: what format is $model_outputs['error'] in? [22:23:29] awight: also, return false in a job means that it will be retried in ~30 minutes, I assume we want it to do that? [22:26:44] legoktm: it's an array of 'message' and something else [22:27:14] aha [22:27:14] https://ores.wmflabs.org/scores/enwiki/?models=reverted&revids=1|15645485 [22:28:18] thx! [22:28:28] I'm amending the patch right now [22:28:47] is there another model besides reverted that I can test with? [22:31:12] There's also wp10 [22:31:26] Cool! [22:31:57] Do you think we should add a job for slowly backfilling existing revisions? [22:32:55] a maintenance script probably [22:35:41] okay, and that would be run by cron? [22:36:44] we'd only need to run it once right? [22:37:32] That would take approx forever on a big wiki, plus would melt down the ORES server [22:37:48] er, it would only be the last 30 days [22:37:50] I was thinking tunable batch size, and it just runs through all the revisions from newest to oldest [22:37:53] oh? [22:37:57] Why's that? [22:38:39] I was thinking that we'd make this similar to recentchanges [22:39:11] Special:RC/Watchlist only go back 30 days so we only need data that goes that far back [22:39:59] and we'd have a job that purges old data every so often [22:40:03] (again, like RC) [22:40:44] I suppose we could store everything, but I don't really see the value in that... [22:40:53] Is there any value in surfacing ORES scores as part of page history? I guess this current iteration is just a page patrolling helper. [22:43:00] there probably is, but I'd think that value goes down the older the edit is (unless you're deliberately looking for old stuff) [22:43:52] our plan was to recalculate scores whenever a model changed, I think that would be pretty bad if we had to re-calculate the entire en.wp every month [22:44:02] Seriously. I'm sold [22:44:25] For invalidation, I was imagining a second table that would just have (model_name, highest_version) [22:44:34] We could check that at the end of each fetch job [22:45:54] and do what after checking? queue more jobs? [22:46:33] lessee. when a new edit is made, we fetch the score no matter what, then compare the max_version and increment if needed. [22:47:25] Maybe, when the RC feed is viewed, we fetch the max_version and compare against the model version we found in the db. If it's lower, we queue a multi-revision fetch job. [22:47:28] I don't really like that... [22:48:16] Maybe we just do a nightly job that refetches scores from any RC from the last 30 days, with an outdated model version. [22:48:47] yeah that sounds good [22:48:57] it could even be a script someone runs whenever a new model version is deployed [22:49:13] That would be fine for now. [22:49:31] I think we need to be able to quickly update a model version in case a bad version is deployed (as happened last time :P) [22:49:59] mm. yeah so the maintenance script has an option to immediately invalidate specific versions. [22:50:22] also we should use a PoolCounter to prevent overloading the ores server [22:50:40] that sounds like magick [22:51:11] it was written in response to the Michael Jackson problem [22:51:18] 'ores_model_version' => 0, // FIXME: waiting for API support [22:51:18] ^ do we have a bug filed for that? [22:51:37] no, just hearsay [22:56:05] where should I file bugs? phab? [22:56:05] k, made a task [22:56:08] yep [22:56:13] https://phabricator.wikimedia.org/T112995 [22:56:14] oh, awesome :D [23:01:54] awight, re. scores on history pages yes, ScoredRevisions already supports this. [23:02:05] I think that usercontribs is a great place to have scores too. [23:05:08] halfak: uh, oh. Is that something we should be integrating with? Existing MW extension? [23:05:21] Oh no. It's a gadget [23:05:32] ooh right thx [23:05:39] This thing: https://github.com/he7d3r/mw-gadget-ScoredRevisions [23:05:40] So it doesn't cache scores, then? [23:06:22] ScoredRevisions? No. But ORES will. [23:06:40] k [23:21:35] legoktm, what is this with PoolCounter? [23:24:42] halfak: https://wikitech.wikimedia.org/wiki/PoolCounter its basically a lock manager that works across all MW servers [23:32:34] It would be nice if we could say, "No more than 50 requests at a time." [23:32:37] Would that work?