[08:29:55] halfak: around for a quick PR review? [08:30:17] I need it to make wikilabels enforce SSL [09:14:02] 10Scoring-platform-team (Current), 10Discovery, 10ORES, 10Wikidata, and 2 others: Include ORES predictions in RDF export - https://phabricator.wikimedia.org/T200716 (10Ladsgroup) There is actually two way to implement it in the backend. 1- Send a request to ORES service every time someone requests rdf expo... [11:33:19] Amir1, not sure I understand this change. [11:33:41] halfak: sure, let's discuss [11:33:55] Yeah. Why specify "http" as the scheme? [11:34:32] halfak: that's for localhost [11:34:42] Ahh I see. [11:35:06] So wikilabels-wmflabs-config will specify https [11:35:14] https://github.com/wiki-ai/wikilabels-wmflabs-deploy/pull/47/files [11:35:21] Can't we enforce this in the uwsgi config? [11:35:21] halfak: Yup ^ [11:35:35] I tried it really hard over the weekend [11:35:38] but it's not possible [11:35:42] Damn. OK [11:35:50] specially url_for return http scheme [11:35:56] I need to run now. Will be back later to do some testing and merge :) [11:36:06] I think it's because it's a proxy to labs, it's a rough guess [11:36:11] coolio [11:36:13] * halfak brings car into shop [12:02:53] o/ [12:05:17] * halfak digs through uwsgi for ORES [12:07:40] Amir1, how do we get ORES to force https? I forget. [12:08:29] halfak: actually it took me half an hour to see [12:08:54] in prod, it's based on outer layers and we communicate in http internally [12:09:12] halfak: but in labs, it's the nginx rewrite rule in the lb node [12:09:58] Ahh yes. Am looking at the nginx config now. [12:10:07] But for wikilabels, we don't use nginx. [12:10:26] nope [12:11:05] we basically have to have a very basic support [12:11:29] and the biggest problem is not the ssl or not ssl, it's this jumping around in between in a navigation [12:11:48] specially ssl doesn't send cookies over http [12:13:11] and we redirect to http after oauth dance (in url_for that gives http regardless of real protocol, I think it's because of the X_FORWARDED_PROTO header, basically [12:13:21] we can't do oauth in certain cases [12:13:37] and people are complaining about it [12:14:12] halfak: also last but not least, this is the puppet change needed [12:14:13] https://gerrit.wikimedia.org/r/c/operations/puppet/+/450395/7/modules/wikilabels/manifests/web.pp [12:14:41] this redirects http requests to ssl [12:15:11] but without the changes I made in wikilabels, we end up in redirect loops, I did it in staging node and it exploded :D [12:16:07] Gotcha. So how will we solves just forcing people to use https? [12:16:11] If uwsgi can't do it? [12:16:26] Also, doesn't oauth assume https? [12:16:30] It should [12:16:36] halfak: oauth assumes https [12:16:42] kk [12:16:47] but /auth/callback redirects to http [12:16:53] hmm. [12:16:59] I see. [12:17:02] Damn labs proxy. [12:17:06] exactly [12:17:11] Makes the requests look like they are http [12:17:27] halfak: uwsgi can enforce it and we will be using it https://gerrit.wikimedia.org/r/c/operations/puppet/+/450395/7/modules/wikilabels/manifests/web.pp [12:17:50] OK I see now. So we merge this, then enable that change. And we *should* be good to go? [12:17:50] but that alone is not enough because of cookies we send over http [12:18:22] yup, I will baby sit everything today [12:18:45] I need to ask Joe to merge this puppet change and make sure it doesn't break anything [12:19:37] kk [12:20:27] OK last question. What's this "relative root" thing? [12:20:34] btw. I talked to Joe about pool counter he said we should talk to Tim first, This poolcounter is a rather big project. We need to probably spin off another poolcounter node for separation of concerns (if poolcounter goes down, wikipedia goes down too) [12:20:42] halfak: which one [12:20:52] https://github.com/wiki-ai/wikilabels/pull/241/files#diff-5c15e1b625867e0901451eeea3ec4da1R24 [12:21:06] I guess that would be "//" or "///" depending on the scheme? [12:21:22] it's a little bit funny [12:21:52] request.url_root returns 'http://labels.wmflabs.org' for ssl requests too [12:22:10] because the proto after labs DNS is http and not ssl [12:23:02] what these two lines does is basically finding out the 'labels.wmflabs.org' or 'labels-staging.wmflabs.org' and then prepending the schema to it [12:23:14] Oh. I think I see now. Cool. [12:23:45] it might be an issue in flask altogether and not an issue in labs DNS but regardless that's the current behaviour [12:24:14] https://github.com/wiki-ai/wikilabels-wmflabs-deploy/pull/47 need an updated submodule. [12:24:24] yup [12:24:31] I wanted to do after the merge [12:24:33] Thanks! [12:25:30] pushed the new commit [12:26:48] merged! [12:28:12] Gotta run again. [12:32:23] me too, will be back soon [12:38:06] nope, it got canceled [12:38:15] back to work and deploy wikilabels [12:40:58] it's on staging and it works like a charm [12:41:09] just one thing is that I need to test fully [12:43:13] Aand that got tested too [12:43:15] going live [12:55:11] 10Scoring-platform-team, 10Wikilabels, 10articlequality-modeling, 10artificial-intelligence: Build article quality model for Galician Wikipedia - https://phabricator.wikimedia.org/T201146 (10Elisardojm) p:05Triage>03High [12:55:45] 10Scoring-platform-team, 10Bad-Words-Detection-System, 10revscoring, 10artificial-intelligence: Add language support for galician - https://phabricator.wikimedia.org/T201142 (10Elisardojm) p:05Triage>03High [13:08:38] 10Scoring-platform-team, 10Wikilabels, 10articlequality-modeling, 10artificial-intelligence: Build article quality model for Galician Wikipedia - https://phabricator.wikimedia.org/T201146 (10Theklan) A system similar to the one developed in euwiki (wp10) would be great for Galician. Also the same gadget @H... [14:03:24] (03PS4) 10Sbisson: Maintenance script to backfill scores in PageTriage queue [extensions/ORES] - 10https://gerrit.wikimedia.org/r/449475 (https://phabricator.wikimedia.org/T198982) [14:03:42] (03CR) 10Sbisson: Maintenance script to backfill scores in PageTriage queue (031 comment) [extensions/ORES] - 10https://gerrit.wikimedia.org/r/449475 (https://phabricator.wikimedia.org/T198982) (owner: 10Sbisson) [14:28:56] (03CR) 10jerkins-bot: [V: 04-1] Maintenance script to backfill scores in PageTriage queue [extensions/ORES] - 10https://gerrit.wikimedia.org/r/449475 (https://phabricator.wikimedia.org/T198982) (owner: 10Sbisson) [14:31:50] (03PS5) 10Sbisson: Maintenance script to backfill scores in PageTriage queue [extensions/ORES] - 10https://gerrit.wikimedia.org/r/449475 (https://phabricator.wikimedia.org/T198982) [16:47:09] (03CR) 10Halfak: [V: 032 C: 032] Add wp10 and draftquality for testwiki [services/ores/deploy] - 10https://gerrit.wikimedia.org/r/450392 (https://phabricator.wikimedia.org/T198997) (owner: 10Ladsgroup) [16:49:00] 10Scoring-platform-team (Current), 10JADE, 10Operations, 10TechCom, and 3 others: [Blocked] Deploy JADE extension to production - https://phabricator.wikimedia.org/T183381 (10awight) [16:49:22] 10Scoring-platform-team (Current), 10JADE, 10WMF-Communications: Blog about JADE - https://phabricator.wikimedia.org/T183200 (10Halfak) Looks like comms is working from https://docs.google.com/document/d/10RZsi3KPdYnY5t36mhkWNoulv7ZKLlI49PSM7uPLq2w/edit [16:52:13] halfak: there is this branch in wikilabels-deploy that I noticed today, it's called backup and has one commit, Is it safe to delete this branch? https://github.com/wiki-ai/wikilabels-wmflabs-deploy/branches [16:52:51] Yup. OK to delete. [16:56:49] Am I misremembering or did Amir1 sign up to describe how federation would work in the context of JADE? [16:57:17] And is that different from just generally having a central wiki? [16:58:28] I have no idea how federation work in JADE context, I know a little bit how it works in wikidata's context [16:58:52] PROBLEM - puppet on ORES-worker01.experimental is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [16:58:56] I thought I just need to explain the wikidata thing [16:59:05] if not, It's all good [16:59:20] 10Scoring-platform-team, 10ORES: ORES feature extraction triggers new MCR-related deprecation warning - https://phabricator.wikimedia.org/T201332 (10awight) [17:00:55] To back up Amir1 about federation, that’s already the name for a specific feature which allows for multiple data sources (e.g. wikibases) to be included in a single SPARQL query. [17:01:11] 10Scoring-platform-team, 10ORES: ORES feature extraction triggers new MCR-related deprecation warning - https://phabricator.wikimedia.org/T201332 (10Ladsgroup) This is happening everywhere.... [17:01:15] We should call this other thing “cross-wiki recentchanges” or some such [17:01:24] I'm thinking it may be a red herring here, if it doesn't lend us much in terms of reusable code. [17:01:32] Cross-wiki recent changes is a thing I have in mind as a requirement for a central wiki. [17:01:41] +1 [17:05:52] PROBLEM - puppet on ORES-worker04.experimental is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [17:05:52] PROBLEM - puppet on ORES-worker03.experimental is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [17:13:18] +1 from me too [17:14:06] PROBLEM - puppet on ORES-worker05.experimental is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [17:17:49] PROBLEM - puppet on ORES-web02.Experimental is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [17:18:32] PROBLEM - puppet on ORES-worker02.experimental is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [17:22:48] ^ Scheduled maintenance? [17:23:28] I don’t see any activity in #wikimedia-cloud, fwiw [17:26:52] RECOVERY - puppet on ORES-worker01.experimental is OK: OK: Puppet is currently enabled, last run 42 seconds ago with 0 failures [17:31:50] RECOVERY - puppet on ORES-worker04.experimental is OK: OK: Puppet is currently enabled, last run 1 minute ago with 0 failures [17:31:51] RECOVERY - puppet on ORES-worker03.experimental is OK: OK: Puppet is currently enabled, last run 31 seconds ago with 0 failures [17:36:46] halfak: there’s server maintenance in progress [17:36:46] Horizon has been shut off [17:36:51] Not sure if it should affect this [17:36:53] Gotcha. [17:37:10] * halfak is in a surprise day-long meeting [17:38:28] That doesn’t sound good. [17:41:00] halfak: We can skip our check-in if you want, since we did cover important stuff last week… [17:41:25] na. It's OK. This is a ridiculous failure of remote participation support anyway. [17:41:34] So I think I'm going to leave. [17:41:47] oof [17:42:06] RECOVERY - puppet on ORES-worker05.experimental is OK: OK: Puppet is currently enabled, last run 1 minute ago with 0 failures [17:42:31] all day? wut [17:42:40] Argh, I’m reading MCR docs and discovered that it relies on fake two-phase commits. [17:44:32] RECOVERY - puppet on ORES-worker02.experimental is OK: OK: Puppet is currently enabled, last run 46 seconds ago with 0 failures [17:45:30] i.e. faking transactions across multiple storage backends and just hoping that we can say “everyone good? commit yourselves” at the end :-/ [17:45:49] RECOVERY - puppet on ORES-web02.Experimental is OK: OK: Puppet is currently enabled, last run 5 seconds ago with 0 failures [17:58:05] awight, is that different from what MW already does now? [17:58:16] I certainly hope so... [17:58:19] Or maybe MCR allows sharding through applying this strategy? [17:58:44] I’m not sure where we have multi-backend storage either with or without MCR, honestly. [18:15:26] awight: do you know why no content shows up in the judgment namespace on beta wikipedia? [18:15:32] https://en.wikipedia.beta.wmflabs.org/wiki/Judgment:Revision/376901 [18:16:54] harej: No, I meant to create a bug for that. It happened a few weeks ago with no explanation. [18:18:03] T199750 [18:18:04] T199750: JADE pages on beta no longer render - https://phabricator.wikimedia.org/T199750 [18:18:12] wtf [18:18:18] > I don't like it, but the solution was to overwrite the page with new content... [18:19:38] harej: reload... [18:20:13] there we go [18:30:18] I still don’t like it. [18:31:03] There’s a remote possibility that the extension’s isValid check was preventing the page from rendering since it contained bad data, but I don’t think that’s actually a feature. [18:31:15] halfak: are you coming to the tech PM meeting? [18:31:22] https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Judgment:Revision/376901&diff=382853&oldid=381937 [18:31:35] I'm in this PAI meeting. Looking for a good way to exit. Will likely join a bit late [18:31:37] harej, ^ [18:36:13] wikilabels: it's callback hell in here [18:36:24] ha. That's just javascript :P [18:36:32] It's consistently structured FWIW [19:02:46] okay, I'm back [19:08:42] The way that wikilabels is written right now, is a subroutine to go and get a diff, and it's duplicated in both the `precaching` function and copy pasted in the `present` function. The only differrence is that in the precaching case we want to call the next `precache` job after, and in the present case we want to immediately call present. I'm trying to abstract this into a diff-getter with a callback [19:29:12] I sent a semi-announcement regarding wikilabels and the SSL thingy [19:41:17] ^ nice! [19:41:42] notconfusing, yeah that seems like it violates DRY [19:41:50] Must have been done in a rush :| [19:42:02] Actually, most of wikilabels was built in volunteer time on the weekend. [19:42:18] I'm going to go take a break. Will be back online in 45 mins. [19:42:22] yup, that's how it goes [19:48:51] I have to leave for the bus ASAP, will write the custom table thingy on the bus [19:49:59] awight: I'm thinking of how to best organize the words we've written so far about JADE. I'd like to move the more general FAQ information to JADE, then have E:Jade/Deployment to include the deployment FAQ and the deployment strategies I've been writing [19:50:34] which page are you referring to when u say “to JADE”? [19:50:37] mw:JADE? [19:51:05] Yes [19:51:08] I’m not sure “Deployment” is the right title for this, also [19:51:21] Maybe something more like “deployment contingency planning"? [19:51:49] "Deployment planning"? [19:52:12] My thought is that we’re doing to need a new document when it’s time to actually deploy [19:52:34] this isn’t specifically about deployment at all, but more about exploring technical alternatives for implementation [19:53:05] plus I guess a bit about how we’ll handle contingencies when deploying in each scenario [20:00:35] awight: how much do you know about X1 tables... and the other kinds of tables [20:00:45] What I gather is that X1 is the name of a server, but I otherwise have no context. [20:00:50] harej: I do not know much but I can try [20:01:13] Seems that x1 is the name of an experimental cluster [20:01:37] If we want to keep our data there, it’ll have to be as custom tables rather than a wiki, AFAICT [20:02:13] That sounds like a complete non-starter. [20:02:15] Beyond that, I think you saw: x1 tables aren’t replicated to labs, and we can’t join between production tables and x1 [20:02:23] +1 [20:07:36] harej: https://wikitech.wikimedia.org/wiki/MariaDB#Extension_storage [20:08:21] https://wikitech.wikimedia.org/wiki/Reading_List_Service [20:09:14] We would have to invent all of our own workflows from scratch if we used X1, no? [20:10:16] https://www.slideshare.net/jynus/mysql-at-wikipedia-how-we-do-relational-data-at-the-wikimedia-foundation slide 31 [20:10:26] harej: Sure seems to be the case, yes. [20:10:49] Reinvent editing, recent changes, abuse filters, fucking edit hooks, and so on. [20:58:03] (03CR) 10Catrope: Maintenance script to backfill scores in PageTriage queue (031 comment) [extensions/ORES] - 10https://gerrit.wikimedia.org/r/449475 (https://phabricator.wikimedia.org/T198982) (owner: 10Sbisson) [20:58:45] (03PS6) 10Catrope: Maintenance script to backfill scores in PageTriage queue [extensions/ORES] - 10https://gerrit.wikimedia.org/r/449475 (https://phabricator.wikimedia.org/T198982) (owner: 10Sbisson) [20:59:06] (03CR) 10Catrope: [C: 032] Maintenance script to backfill scores in PageTriage queue [extensions/ORES] - 10https://gerrit.wikimedia.org/r/449475 (https://phabricator.wikimedia.org/T198982) (owner: 10Sbisson) [21:00:08] awight, halfak: having a central wiki isn't actually that offensive from a risker's checklist perspective. it *would* be a wiki. the main costs would be integrating with other wikis and the costs of running a wiki [21:00:49] Yeah, I think it does violate it though unless the changes show up where the locals expect. [21:01:37] Under "visibility" I think it's implied that "appropriate" means "mine" [21:02:07] Also, I'm worried about cross-wiki user rights. E.g. I want enwiki admins to be able to suppress JADE revisions relevant to their wiki. [21:02:28] yup that won’t be a thing... [21:04:11] Can you look at the Central Wiki section of https://etherpad.wikimedia.org/p/JADE_deployment ? [21:06:20] At line 33, I would order by difficulty, descending [21:15:59] (done) [21:16:09] So building integrations between the JADE wiki and the other wikis isn't even the most daunting part of centralization. I'm more concerned about the building a new community from scratch thing. [21:17:32] (03Merged) 10jenkins-bot: Maintenance script to backfill scores in PageTriage queue [extensions/ORES] - 10https://gerrit.wikimedia.org/r/449475 (https://phabricator.wikimedia.org/T198982) (owner: 10Sbisson) [21:30:01] harej: It’s a suicidal proposition. [21:30:22] Also, one we can’t even do, we’re asking other people to do so. [21:32:42] Yeah. Unless we have full integration and JADE-wiki becomes a sort-of no-mans-land wiki, then it's not gonna work. [21:38:41] re ORES deployment, I missed the window on that. Still waiting for new editquality models anyway, so we might as well do everything at once, tomorrow. [21:38:54] makes sense [21:39:40] These new rvslots deprecation errors are the ants at my picnic. [21:41:37] halfak: Full interwiki integration would be a great, general design approach for MediaWiki. I’m happy to switch over to it, in the distant future in a parallel multiverse in which that’s released. [21:42:10] Yeah. I feel the same. It seems very difficult which means that what we do will be partial at best. [21:42:18] Again this should not be the problem we need to solve. [21:42:29] I think this should land in platform evolution/mediawiki platform. [21:42:35] IMO it just makes single-wiki a project killer [21:42:52] I kept it on the table just to have *any* plausible alternative. [21:43:42] It’s funny to think that I was about to go ahead and implement as custom tables *plus* a MediaWiki mirror, at one point. [21:44:03] Reminds me that any current paradigm is probably going to be outdated soon enough. [21:46:11] awight: did you think about judgments as Special:Log entries? [21:47:33] 10Scoring-platform-team, 10JADE: Integrate Judgment watchlists with the target wiki entity - https://phabricator.wikimedia.org/T201361 (10awight) [21:47:37] harej: Can they be edited there? [21:47:55] They can't be edited, but they can be deleted/suppressed. [21:48:27] We need editability, so that would have to be kludged somehow [21:48:44] Does it have to be editable in-place? [21:49:01] Perhaps an updated log entry would link to its previous revision, you mean? [21:49:48] That’s reasonable in that it has the same structure as the Kafka-esque log that would be fed to downstream analytics. [21:50:07] But I think harder for humans. [21:50:27] For example, we would have to emulate the revision history view. [21:50:36] eh no I guess that would be the log view itself. [21:50:46] I think at this point we have to pick which hard thing we want to do. [21:51:24] IMO we’re still working with contingencies, the outcome of TechCom discussion could release us from these bonds [21:52:11] One thing about the log table is that it’s still in the MediaWiki database [21:52:33] We should ask how it scales, though. Mostly, if it’s replicated on every node. [21:52:43] It's not on the revision table, which I believe helps. [21:52:51] And log entries do have unique IDs, so we can refer to old ones. [21:53:03] And there are API methods for individual log entries. [21:53:07] Log is pretty huge, Amir1 just did some work to purge billions of rows. [21:53:15] * awight waves hands like Carl Sagan [21:53:23] A row for every star. [21:53:30] :) [21:54:51] Actually, log table scaling is an apt analogy for the Judgment namespace. [21:55:45] It’s possible to have a log event for each revision, but that’s considered poor form and we have ways of avoiding or cleaning up after having made mistakes. [21:56:31] So to our point, we can do things affecting behavior and discouraging revision scaling. To Ops’s point, if nobody notices revision-scaling behavior and it goes on for a long time, we have a huge and uncleanable mess. [21:58:10] I’m realizing that revision-scaling isn’t the problem itself, it’s more about the factor of judgments / revisions. [21:59:05] I'm going AFK for the evening. Have a good one, folks. [21:59:06] o/ [21:59:29] Hope you have light for more gardening! [22:00:19] harej: I like that log entries already have columns for linking to a namespace and title. [22:02:01] is there a risk that if we propose creating log entries instead that they'll just repeat the same criticism but with the log table? [22:04:46] It’s a risk we should take :-) [22:07:43] What will we be losing, though: watch-ability, RecentChanges integration, manual edit/write interface, AbuseFilter (?)... [22:09:08] On second thought, the manual edit interface is probably better omitted [22:09:16] We replace RC integration with logs integration. [22:09:18] That’s a ridiculous hack [22:09:23] +1 [22:09:32] We don't have AbuseFilter either way because AbuseFilter doesn't know how to deal with JSON. [22:12:41] We can’t use a hook to flatten the format? [22:13:12] AbuseFilter-contentToString [22:14:01] I don't know, can we? [22:15:33] It looks like that hook does the job, will send a link [22:15:55] https://github.com/wikimedia/mediawiki-extensions-AbuseFilter/blob/master/hooks.txt#L20-L24 [22:17:57] 10Scoring-platform-team, 10AbuseFilter, 10JADE: AbuseFilter integration for JADE - https://phabricator.wikimedia.org/T201365 (10awight) [22:19:24] awight: from an engineering perspective, is judgments as log entries worth taking seriously as an idea? [22:24:06] * awight is spilling sandwich on myself [22:25:54] harej: I’m happy to take almost anything seriously at this point [22:26:55] I think the log table idea has some technical aspects that make it entertainable, but if we add up the technical hurdles and damage to our central use cases, it’ll probably fall short of being worthy of consideration. [22:28:17] The way I’d prefer to play it would be to get Ops to say whether it satisfies their needs, then we can look in more depth in order to not waste effort. [22:28:45] But I understand that you’re front-loading a bunch of this effort in order to have that conversation with Ops, so we might not have the luxury of doing it in the right order. [22:40:57] OMG, etherpad now removes spaces if you use the arrow keys on long lines. [22:41:10] * awight looks for “VE inside” sticker :p [22:42:01] We should replace Etherpad with VEPad, which is a totally real thing that exists. [22:42:05] Dogfooding! [22:43:25] O_O [22:43:37] link or it didn’t happen. [22:44:31] https://visualeditor-realtime.wmflabs.org/doc/edit/Hi_Adam [22:44:32] Line 19 is a great strategy statement in a nutshell. [22:44:58] * awight attempts to insert citation and is disappointed. [22:45:19] “view as right-to-left” lol [22:46:19] my comment text disappeared... [22:46:26] ok that’s funky [22:46:40] operational transformation? [22:49:43] * awight casts a suspicious glance at cscott [22:49:51] This is quite an interesting skunkworks project! [22:50:24] awight: you mentioned above lack of watchlist/RC integration for log entries, but I don't think that's true. Log entries do show up in recent changes and possibly watchlists as well. [22:51:28] Well watchlist integration is flawed for the namespace implementation too, so that’s fair [22:52:27] * awight tries to surface log entries in dev wiki [22:55:08] I just did a page rename on Test Wikipedia and the log entry showed up in both RC and watchlist [22:55:26] https://usercontent.irccloud-cdn.com/file/Ld4ljgiI/Screen%20Shot%202018-08-06%20at%2015.54.07%20.png [22:55:52] https://usercontent.irccloud-cdn.com/file/60ZHM31v/Screen%20Shot%202018-08-06%20at%2015.55.29%20.png [22:57:20] Per-wiki – log entries [22:57:20] With this strategy, JADE would be deployed to each wiki, but instead of creating a new namespace, judgments would be a kind of log entry. Log entries nicely match the format of judgments ("so-and-so assessed revision 12345 as damaging, bad-faith") and log entries can be deleted and suppressed as needed. Log entries cannot be edited in place but new ones can be created as needed to update a page. This also removes the need for editors to interact with [22:57:20] raw JSON, and from the operational perspective it is easier to purge log entries than revisions. However, this may result in a slightly more complicated user experience, as well as poor AbuseFilter integration. [22:57:24] anything else you would write there? [22:58:00] Nice, thanks for demonstrating! RC looks good [22:59:29] 10Scoring-platform-team (Current), 10Wikilabels: Extend wikilabels to support session-labelling - https://phabricator.wikimedia.org/T201370 (10notconfusing) [23:00:22] harej: I would question “removed the need for editors to interact with raw JSON”, we’ll still have JSON as the judgment payload, so all we’re removing is the ability to interact with the raw JSON, rather than a requirement that they do so. [23:02:34] FYI https://www.mediawiki.org/wiki/JADE/Implementations [23:02:53] That’s a good list of our requirements [23:04:10] … not a good list of use cases, unfortunately. [23:05:30] log-judgments satisfies the requirements… [23:10:00] Who should make the request on the Phabricator ticket on whether the log table will be suitable? [23:11:55] 10Scoring-platform-team (Current), 10Wikilabels: Extend wikilabels to support session-labelling - https://phabricator.wikimedia.org/T201370 (10notconfusing) working on this here: https://github.com/notconfusing/wikilabels/tree/multi-diff-to-previous [23:11:57] Not to be overly hasty, but it would be nice to get some validation (or know we're not going to get it) before investing more effort into this [23:15:41] 10Scoring-platform-team, 10AbuseFilter, 10JADE: AbuseFilter integration for JADE - https://phabricator.wikimedia.org/T201365 (10Huji) Do you mean that the judgements should be subject to abuse filters? (E.g. if they contain profanity, it should be possible to block saving that judgement using an abuse filter... [23:18:17] harej: Maybe marostegui? [23:18:57] Ooh. So we should workshop it internally before we post publicly? [23:20:02] IMO it’s fine to talk about this, not like there’s a big internal disagreement we need to settle first. [23:20:22] We generally agree that it’s kind of an effed-up solution but want to explore as an alternative. [23:20:39] It’s a really bad fit conceptually, if I haven’t said that yet... [23:20:55] Makes it very unclear that we’re doing something collaborative [23:25:14] 10Scoring-platform-team, 10AbuseFilter, 10JADE: AbuseFilter integration for JADE - https://phabricator.wikimedia.org/T201365 (10awight) @Huji Yes, exactly. We're hoping to create a new namespace "Judgment" and want to take every possible precaution against creating additional patrolling workload. It probab... [23:34:59] (03CR) 10jenkins-bot: Maintenance script to backfill scores in PageTriage queue [extensions/ORES] - 10https://gerrit.wikimedia.org/r/449475 (https://phabricator.wikimedia.org/T198982) (owner: 10Sbisson) [23:54:39] (03CR) 10jenkins-bot: Localisation updates from https://translatewiki.net. [extensions/JADE] - 10https://gerrit.wikimedia.org/r/450758 (owner: 10L10n-bot)