[00:04:08] harej: Okay, that sounds useful. Do you happen to have notes from our last chat about WikiLabels integration? [00:04:50] I remember being conflicted about how it's a lot of work for very small returns, at least at the beginning. [00:09:57] The incoming integrations shoud be much less work and give us an idea of feasibility [00:22:51] awight: I think the main issue was blind append-only judgements [00:23:53] harej: that it's sort of meaningless to integrate that way? [00:23:59] I wouldn't argue... [00:24:22] & the editing will be silly too, since it's all JSON [00:27:41] Gotta run but we should pick this up tomorrow! [08:33:14] (02:54:23 μμ) akosiaris: Amir1: that's up to you. It can be a fallback or you can distribute the locks if you want (you will have to do some consistent hashing though based on some key). Both approaches are fine cause they are locks, losing them means nothing. mediawiki does the latter btw [08:33:22] Amir1: awight ^ [08:33:51] I am fine with both as I already said [08:34:15] If you are asking what I prefer, it would be consistent hashing, but I am fine with the first incarnation being a fallback [08:46:27] Amir1: there is a chance the thing I reported yesterday is related to https://phabricator.wikimedia.org/T202764#4537363 [14:56:35] 10Scoring-platform-team, 10ORES, 10RESTBase, 10RESTBase-API, 10Services (done): Use RESTBase for ORES precaching - https://phabricator.wikimedia.org/T166161 (10mobrovac) [15:15:40] 10Scoring-platform-team, 10ORES, 10RESTBase, 10RESTBase-API, 10Services (later): Use RESTBase for ORES precaching - https://phabricator.wikimedia.org/T166161 (10Pchelolo) 05Resolved>03Open Ouch, it's not actually done. Not sure why did I close it. [16:49:59] !sal [16:49:59] 04Error: Command “sal” not recognized. Please review and correct what you’ve written. [16:58:06] 10Scoring-platform-team, 10ORES, 10Services (designing): Merge ORES precaching with ORESFetchScoreJob - https://phabricator.wikimedia.org/T201868 (10mobrovac) I'd like to get back to the topic of ORES score caches and RESTBase for a second :P My understanding is that precaching is done for new revisions. CP... [17:55:33] harej: I had a change of heart about the recommendation to keep page judgments in MCR, in a slot on the article. [17:56:01] Now I'm thinking we should drop drafttopic in our first release. [17:56:54] Allowing free-form topics is going to be a huge mess on the data side, and on the implementation side, MCR is still immature. [18:02:31] I agree we can do without it for now. [18:04:50] cool, I'm almost ready to do another round of implementation... [18:11:03] harej: How do you feel about switching from a generic API to ones that are specific for judging each entity type? [18:11:29] I think I left a note at the end of the day, sorry if this is a re-run. [18:27:19] In the RFC meeting, there was unaninimity (including myself) that the generic column I'd suggested for our secondary schema was a terrible idea. [18:28:26] The solution is probably to have a table judgment_revision which links diff and revision judgment pages to target revision rows, and a judgment_page table which links page judgment pages to target pages. [18:29:14] judgment_page could also link rev and diff judgments to the page containing the revision, if that turns out to boost query efficiency for RC views etc. [18:30:58] but yeah... the generic vs specialized API is something separate, with different concerns. [18:31:47] We would provide judgediffdamaging(revid, isdamaging, rationale, editsummary) or something [18:32:10] judgediffgoodfaith, judgerevisionquality, judgedraftquality... [18:34:26] Here's an example of something gross which makes me take ^ seriously: https://en.wikipedia.org/w/api.php?action=help&modules=tag [20:38:36] awight: what exactly would be changing, in terms of the method signature? [20:39:21] harej: sorry for the extended walk, but I needed it! [20:39:39] harej: Currently, the signature is https://www.mediawiki.org/wiki/Extension:JADE#API [20:39:58] createjudgment Signature: [20:39:58] entity-type, entity-id, schema, data, [notes], [summary], [tags] [20:39:58] → [20:39:58] status [20:39:58] {\textstyle {\text{entity-type, entity-id, schema, data, [notes], [summary], [tags]}}\rightarrow {\text{status}}} [20:40:05] [20:40:18] Just this one: [20:40:18] entity-type, entity-id, schema, data, [notes], [summary], [tags] [20:40:39] and instead we'd have separate signatures for each type of thing [20:40:43] yes [20:40:51] I think I'm fine with that [20:40:54] and, *instead as you said [20:41:00] yeah me too, and I'm surprised at it [20:41:19] But I have no good memories of Verb('Noun', 'otherverb', 'params') [20:41:24] It may in the long run be helpful in case we have different types of models with different signatures [20:41:44] yes, good way to look at it [20:41:48] also better semantics [20:41:56] diff_id instead of entity_id [20:41:58] self-documenting, good point [20:42:07] also I'm pretty sure Wikibase has dibs on "entity" :P [20:42:18] I feel weird about the commit summary [20:42:30] Are you convinced? [20:42:53] That Wikibase has dibs on entity? Not of that; I'm pretty sure "entity" is a generic word anyone can use. [20:43:16] ah no, I was asking twice about commit summary [20:43:32] hehe I hadn't thought of Wikibase cornering "entity", but you're right [20:43:41] It's not a good precedent to have any precedent. [20:45:07] What's the commit summary? Sorry if I'm missing something [20:46:12] I'm convinced that we need judgment.notes, but sometimes it feels weird to have an optional commit summary string as an API param. [20:46:25] Although it's the right thing to do ;-) [20:46:54] The way I see it is that the note is attached to content at the level edit summaries aren't [20:46:58] edit summaries are attached to wholesale revisions [20:47:03] these are comments attached to individual pieces of content [20:47:21] aha: so the GET method has a smaller-than-page granularity [20:47:41] yah your summary works for me [20:47:59] getdamagingjudgment(rev_id) [20:48:10] rev_id is [1..*] [20:48:54] ^ I like this [20:49:16] and you could address an individual judgment as: r123456/content/editquality/n [20:49:18] or something like that [20:49:35] address would be opaque to the caller, I think [20:49:42] although I was considering the return values [20:49:54] maybe we return (judgment_page_title, revision_id) [20:50:09] should be... same as action=edit [21:34:07] harej: FYI https://phabricator.wikimedia.org/T203025 [21:34:34] I don't like "oldrevid" and "newrevid" but if it's what people are used to... [22:01:44] 10Scoring-platform-team (Current), 10JADE: Use local articlequality assessment scale for JADE. - https://phabricator.wikimedia.org/T203030 (10awight) [22:04:04] Rats. We can almost leave revid out of judgearticlequality and assume latest, but the race condition is too nasty to ignore. [22:04:31] judgearticlequality(title, quality) would be so nice, though :-| [22:27:02] harej: Why is itemquality not called "articlequality"? We already localize the scale per-wiki: http://ores-beta.wmflabs.org/v3/scores/ruwiki/?models=articlequality&revids=123 [22:33:02] harej: You were mentioning this a few weeks ago, but I'm finally coming around to seeing that we need to allow articlequality scales and drafttopic categories to be either configurable or an editable list on-wiki. [22:35:27] 10Scoring-platform-team, 10JADE, 10drafttopic-modeling: Discuss whether we can deploy JADE for draft topic without fixed categories - https://phabricator.wikimedia.org/T203032 (10awight) [22:36:51] This is awful, but I'm thinking make articlequality configurable in code and strictly validated, but drafttopic editable on-wiki and allowing values outside the recommended list. [22:42:05] (03PS1) 10Legoktm: Use $this->setTemporaryHook() in tests [extensions/ORES] - 10https://gerrit.wikimedia.org/r/456040 [22:42:52] (03CR) 10Awight: [C: 032] "Great cleanup, thanks!" [extensions/ORES] - 10https://gerrit.wikimedia.org/r/456040 (owner: 10Legoktm) [22:43:55] (03CR) 10jerkins-bot: [V: 04-1] Use $this->setTemporaryHook() in tests [extensions/ORES] - 10https://gerrit.wikimedia.org/r/456040 (owner: 10Legoktm) [22:44:52] (03PS2) 10Legoktm: Use $this->setTemporaryHook() in tests [extensions/ORES] - 10https://gerrit.wikimedia.org/r/456040 [22:47:45] 10Scoring-platform-team (Current), 10JADE, 10Operations, 10TechCom, and 3 others: Deploy JADE extension to production - https://phabricator.wikimedia.org/T183381 (10awight) 05stalled>03Open [22:48:34] 10Scoring-platform-team (Current), 10JADE, 10Operations, 10TechCom, and 3 others: Deploy JADE extension to production - https://phabricator.wikimedia.org/T183381 (10awight) Unblocking as I have steps to take, then we'll resubmit for another round of technical and community review. [22:50:26] 10Scoring-platform-team, 10JADE, 10drafttopic-modeling: Discuss whether we can deploy JADE for draft topic without fixed categories - https://phabricator.wikimedia.org/T203032 (10awight) [22:50:28] 10Scoring-platform-team (Current), 10JADE: Use local articlequality assessment scale for JADE. - https://phabricator.wikimedia.org/T203030 (10awight) [22:50:36] 10Scoring-platform-team (Current), 10JADE, 10Operations, 10TechCom, and 3 others: Deploy JADE extension to production - https://phabricator.wikimedia.org/T183381 (10awight) [23:01:06] 10Scoring-platform-team (Current), 10JADE: Distinct APIs and tables for each judgment target type, drop polymorphism and generic interfaces or schemas - https://phabricator.wikimedia.org/T203037 (10awight) [23:01:25] 10Scoring-platform-team (Current), 10JADE: Distinct APIs and tables for each judgment target type, drop polymorphism and generic interfaces or schemas - https://phabricator.wikimedia.org/T203037 (10awight) [23:01:30] 10Scoring-platform-team (Current), 10JADE, 10Operations, 10TechCom, and 3 others: Deploy JADE extension to production - https://phabricator.wikimedia.org/T183381 (10awight) [23:01:40] (03PS1) 10Awight: [WIP] Replace generic APIs with specific ones [extensions/JADE] - 10https://gerrit.wikimedia.org/r/456044 (https://phabricator.wikimedia.org/T203037) [23:04:45] (03CR) 10jerkins-bot: [V: 04-1] [WIP] Replace generic APIs with specific ones [extensions/JADE] - 10https://gerrit.wikimedia.org/r/456044 (https://phabricator.wikimedia.org/T203037) (owner: 10Awight) [23:10:45] 10Scoring-platform-team (Current), 10JADE, 10Operations, 10TechCom, and 3 others: Deploy JADE extension to production - https://phabricator.wikimedia.org/T183381 (10awight) [23:22:14] (03CR) 10jerkins-bot: [V: 04-1] [WIP] Replace generic APIs with specific ones [extensions/JADE] - 10https://gerrit.wikimedia.org/r/456044 (https://phabricator.wikimedia.org/T203037) (owner: 10Awight) [23:23:04] (03PS1) 10Awight: [WIP] APIs for specific schemas [extensions/JADE] - 10https://gerrit.wikimedia.org/r/456048 [23:23:34] gtg for now [23:27:29] (03CR) 10jerkins-bot: [V: 04-1] [WIP] APIs for specific schemas [extensions/JADE] - 10https://gerrit.wikimedia.org/r/456048 (owner: 10Awight) [23:30:24] (03CR) 10jerkins-bot: [V: 04-1] [WIP] APIs for specific schemas [extensions/JADE] - 10https://gerrit.wikimedia.org/r/456048 (owner: 10Awight) [23:42:38] (03CR) 10Jforrester: [C: 031] Use $this->setTemporaryHook() in tests [extensions/ORES] - 10https://gerrit.wikimedia.org/r/456040 (owner: 10Legoktm)