In T161907#4952554, @Ejegg wrote:

diagonal banner list on Special:CentralNoticeBanners in Firefox:

After talking to @joal at All Hands, I'm now thinking that T211069 should be the first priority for integrating the scoring pipeline into Hadoop. We should design a stream transformer to calculate features for each revision, and store the resulting values partitioned by feature name. This involves very different challenges than what's being discussed here, and in the end we might be able to entirely circumvent this minor glitch about merging the data centers.

Didn't have time to do this, regrettably.

I've only had very general conversations about this project so far, and didn't realize there was working code :-)

In T214874#4925938, @mobrovac wrote:

If I understand this task correctly, it seems to be a duplicate of T107196: Set up revscoring entry points in RESTBase.

Turns out this is really annoying in a stock mediawiki-vagrant, it obscures the form:

WIP: https://github.com/wikimedia/revscoring/compare/roots?expand=1

@fr-tech: Okay, just the main patch left and it's in your court! Let me know if I can do anything more.

Just for fun, I elaborated on the quick estimate based on existing w_cache files. Note that these are not the "root" data sources, these are the final, calculated values ready to be input into a model. Storing the calculated values is one alternative we might consider, the tradeoff is that the values are compact and can be used for existing models, but lack flexibility and completeness, so additional features added in the future will probably require another full MW API extraction.

Just discovered some good documentation about this exact problem, here: https://www.mediawiki.org/wiki/Manual:Extension_registration#Requirements_(dependencies)

@Nikerabbit Do you know of any mechanism to enable Extension:Translate when unit testing other extensions? ExtensionRegistry#isLoaded tells me that Translate isn't available from WMF CI tests for FundraisingTranslateWorkflow.

In T200297#4903879, @Milimetric wrote:

This wikitext-in-JSON thing seems really complicated.

Important change of plans—We're discussing backfilling, and it might be best to allow mismatched model versions in the dumps for now. In other words, go ahead and backfill with whatever the current model version is. Normalized data will continue to be segregated by model version, but the monthly "current" and "historical" dumps will patch together whatever scores are available, simply taking the newest model version used to score each revision.

@Nikerabbit Hi, are we unblocked now that MLEB 2019.01 is released?

In T213943#4888027, @Nikerabbit wrote:

All we have to do is rely on a namespace-based message group, and configure the group with:

Just to clarify, you have a code that gets run when the state of a language of message group's translations is changed to published?