[13:06:18] is there API access to RC/watchlist with a userExpLevel filter? [13:08:20] hm, doesn’t look like it as far as I can tell [15:17:22] inductiveload: for RC, you can use https://stream.wikimedia.org/v2/ui/#/?streams=mediawiki.revision-create. It's not exactly that, but it tells you about all revisions and it includes the editcount and registration date for the user who saved the edit [15:18:15] seems a bit weird that the special page and the API have completely different views into the revisions [15:18:33] the thresholds for each of the exp levels are known (https://www.mediawiki.org/wiki/Edit_Review_Improvements/New_filters_for_edit_review#Search_by_experience_level), so you can filter by that pretty easily [15:18:43] i need an API query rather than a stream, sadly [15:18:49] i see [15:19:23] basically what I'm trying to do is take a URL like https://en.wikisource.org/wiki/Special:RecentChanges?userExpLevel=unregistered%3Bregistered%3Bnewcomer&hidebots=1&reviewStatus=all&hidecategorization=1&hideWikibase=1&hidelog=1&limit=1000&days=30&urlversion=2 [15:19:27] and construct an API query [15:19:42] this is for a popups-type tool [15:20:14] i see [15:20:27] so you can hover over a link and get the same (or basically the same) results [15:21:38] anyway, looks like it's not possible, so I'l just have to make do with unregistered/registered and what patrol statuses match up too [15:22:32] i had assumed Special:RC would be internally hit the RC API logic, but ChangesListSpecialPage.php seems to say "no" [15:24:50] yeah, no, I think it’s at least partially separately implemented [15:25:28] (the filter for userExpLevel in ChangesListSpecialPage.php also doesn’t look particularly efficient to me but I hope the relevant data is pre-fetched in bulk…) [20:30:03] Krinkle: could have have a look at this? https://gerrit.wikimedia.org/r/754911 [20:38:34] musikanimal, btw you've got two people who have submitted more than 5 tasks (which the FAQ says is the limit), Pigsonthewing and C933103 [20:42:55] legoktm: i started work on converting extension.json to the new settings file structure internally, want to have a look? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/745613 [20:50:22] Izno: yeah, we've decided to mostly turn a blind eye to that rule... it's there to ensure the proposers are responsive, but these two are so barring some other issue we're okay with it. We allllmost removed the rule entirely, but left it as a (meaning we can change it without need for re-translation), so we could just change it to 10 or whatever now :) [20:50:31] thanks for pointing it out, nonetheless! [20:50:39] :D [20:57:51] duesen: done. [21:01:01] I remain skeptical on whether this makes sense to use YAML for. I also have once again forgotten how it relates to either of the two TDMP/RFCs on-going (about config modes for dev, and about live k8s config from etcd without new docker images). I don't know why we need a schema now or at all. and why that'd have to be in the same file, or why jsonschema. Thre's also things like append configs (e.g. $wgFoo['foo']=1) that woudl be hard to [21:01:01] translate to a declarative etcd-compatible format, and to validated against the same MW schema for a full value before pushing to prod etc. [21:02:17] I'm also surprised the code is already live in prod in Setup.php, I thought it was live in Setup.php. I guess that's still kind of true, it's just mostly dummy/empty loops. [21:02:58] Anyhway, lots of questions and lacking good docs I think. So long as it's all still an experiment to gather data and proof the concept, I remain idle and waiting to read the results and conclusion in a public place and learn how it fits in long-term :) [22:08:57] Krinkle: I plan to have another round of meetings with youall (aka "stakeholders" per the tdf process) to evaluate what we have come up with, and then write it all down nicely. [22:10:43] Krinkle: for now, the very brief answer to your question is: both use cases need to merge settings from multiple files. For that we need to know the appropriate merge strategy for each config variable. This should be maintained in the place that defines the config variable. So instead of having a file that initialized globals (we don't want globals anyway) we have a schema files that contains defaults, merge strategies, and documentation. [22:36:06] ack