[09:04:09] (03PS1) 10MarcoAurelio: Typo fixes [extensions/JADE] - 10https://gerrit.wikimedia.org/r/453103 (https://phabricator.wikimedia.org/T202039) [09:05:19] (03PS2) 10MarcoAurelio: Typo fixes [extensions/JADE] - 10https://gerrit.wikimedia.org/r/453103 (https://phabricator.wikimedia.org/T202039) [09:12:21] (03CR) 10星耀晨曦: [C: 031] Typo fixes [extensions/JADE] - 10https://gerrit.wikimedia.org/r/453103 (https://phabricator.wikimedia.org/T202039) (owner: 10MarcoAurelio) [09:13:40] o/ [09:20:06] o// [10:16:26] 10Scoring-platform-team, 10ORES, 10Services (designing): Merge ORES precaching - https://phabricator.wikimedia.org/T201868 (10Halfak) We've had the ORES-->Restbase discussion a few times and I can't remember why we decided not to go that direction last time. Generally, for ORES' caching concerns, we need... [10:21:16] 10Scoring-platform-team (Current), 10Analytics, 10Analytics-Kanban, 10EventBus, and 3 others: Fix "score_schema" -- invalid JSON Schema - https://phabricator.wikimedia.org/T197828 (10Halfak) Undo! Undo! We already fixed and deployed this! :P [10:21:25] 10Scoring-platform-team (Current), 10Analytics, 10Analytics-Kanban, 10EventBus, and 3 others: Fix "score_schema" -- invalid JSON Schema - https://phabricator.wikimedia.org/T197828 (10Halfak) 05duplicate>03Resolved [10:21:29] 10Scoring-platform-team, 10Analytics, 10Analytics-Kanban, 10EventBus, and 4 others: Modify revision-score schema so that model probabilities won't conflict - https://phabricator.wikimedia.org/T197000 (10Halfak) [11:54:22] (03CR) 10Ladsgroup: [C: 032] "Thanks!" [extensions/JADE] - 10https://gerrit.wikimedia.org/r/453103 (https://phabricator.wikimedia.org/T202039) (owner: 10MarcoAurelio) [11:59:55] (03Merged) 10jenkins-bot: Typo fixes [extensions/JADE] - 10https://gerrit.wikimedia.org/r/453103 (https://phabricator.wikimedia.org/T202039) (owner: 10MarcoAurelio) [12:03:40] (03CR) 10jenkins-bot: Typo fixes [extensions/JADE] - 10https://gerrit.wikimedia.org/r/453103 (https://phabricator.wikimedia.org/T202039) (owner: 10MarcoAurelio) [12:05:38] (03CR) 10MarcoAurelio: "> Thanks!" [extensions/JADE] - 10https://gerrit.wikimedia.org/r/453103 (https://phabricator.wikimedia.org/T202039) (owner: 10MarcoAurelio) [13:36:36] o/ [13:39:11] halfak: oh I was looking for you [13:39:34] Sorry to be AFK. I accidentally posted my AFK notice in -analytics [13:39:44] because the channels are right next to each other in my client ^_^ [13:39:57] Amir1, ^ what's up? [13:41:17] 10Scoring-platform-team, 10ORES, 10Performance-Team (Radar), 10Wikimedia-log-errors: ORES Storage::SqlScoreStorage exception every 2-3 minutes: Model contains an error for [id]: TimeoutError - https://phabricator.wikimedia.org/T201412 (10Ladsgroup) https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ORES... [15:20:58] I had that python's json library doesn't allow you to specify custom decoder methods on your classes. [15:44:33] I think it does? [15:45:04] https://docs.python.org/2/library/json.html#encoders-and-decoders [15:45:14] object_hook, if specified, will be called with the result of every JSON object decoded and its return value will be used in place of the given dict. This can be used to provide custom deserializations (e.g. to support JSON-RPC class hinting). [15:45:49] halfak: Feel free to poke at https://etherpad.wikimedia.org/p/JADE_design_sync btw [15:46:29] awight, the problem there is that you need to provide it to the json.dumps() call [15:46:37] rather than defining it in your own object [15:46:43] So that json.dumps() calls just work [15:46:45] I see… [15:47:00] You’re looking for something like __repr__, makes sense [15:47:14] well +1 that python json encoding sux [15:48:45] Maybe you can provide a generic object_hook which looks for your __json_code__ method on everything? [15:48:59] *json_codec [15:52:57] I made a note on the "Why comments" question [15:53:15] This is the larger point for me. The higher quality labels is purely theoretical at this point. [15:53:16] nice one [15:53:32] the ability to tag judgments fits the observed grounded theory processes we're seeing. [15:53:57] Interesting, we’ll probably want to explicitly encourage that, then. [15:55:18] halfak: awight: WMDE is now moving all of their repos to wikimedia org in github [15:55:25] Can I move the only-code ones? [15:55:31] revscoring, ores, wikilables, [15:55:44] I leave editqaulity and similar for later [15:55:47] Was LFS our only blocker? I can’t quire remember. [15:55:53] *quite [15:56:12] can’t quite remember, squire [15:56:18] I think we had questions about using LFS, but it wasn't exactly a blocker [15:56:25] awight, related: https://bugs.python.org/issue27362 [15:56:28] I'm not sure if it's a blocker or not but this doesn't need lfs [15:56:32] *to our previous discussion [15:56:56] Amir1, if we don't get good LFS support in github, we've been looking at moving elsewhere [15:57:05] It would be a waste to do two moves. [15:58:15] moves are not that costly [15:59:14] halfak: Seems like a good conversation, the consensus there is that it should continue on python-ideas, fwiw [16:01:12] harej: u still interested in our meeting? [16:01:26] awight: yes, i had to find a quiet room that i will probably be kicked out of in 30 minutes [16:01:40] Loud room is fine with us :p [16:15:00] Hey folks. I'm helping some researchers set up a new campaign so I'm doing a wikilabels deployment. [16:19:26] Staging looks good. [16:19:29] o/ notconfusing_ [16:19:39] I saw I'm overdue for finishing a review of your PR. Will get to that shortly. [16:20:01] hey halfak [16:20:01] no worry [16:37:38] 10Scoring-platform-team (Current), 10ORES, 10User-Ladsgroup: Rewrite ORES "reference" UI using React - https://phabricator.wikimedia.org/T195274 (10Jdlrobson) @ladsgroup is there a patch you are waiting on or a component/issue in particular you'd like me to fix up? Will probably have some room to work on thi... [17:07:17] Amir1, awight: good conversation, i like where this is headed [17:07:56] I think it was helpful [17:08:41] The subjective scoreboard causes my forehead muscles to twitch, but I’m glad we’re doing something to break out of the impasse [17:09:19] I’d rather have the spreadsheet than talk in circles forever. It’s good to organize our thoughts :) [17:09:49] I’ll take the blame for quantifying the exercise by taking the average of each column [17:11:24] harej: me too :) [17:12:47] I’m uncomfortable that we’re all sort of gaming our favorite implementation... [17:13:07] But I think that’s unavoidable in this spreadsheet scenario [17:13:50] Yeah. Maybe we should put two or three numbers for each individual [17:14:10] or discuss until we reach a consensus [17:14:16] It's basically JADE [17:15:26] hehe we can use the pilot implementation to design the long-term integration [17:15:41] ah, a row: ease of schema migrations [17:17:12] Amir1: Can log entries be edited after the fact? [17:17:39] (03CR) 10Wladek92: Typo fixes (031 comment) [extensions/JADE] - 10https://gerrit.wikimedia.org/r/453103 (https://phabricator.wikimedia.org/T202039) (owner: 10MarcoAurelio) [17:17:51] They cannot [17:17:57] (Not that I've ever seen.) [17:18:07] awight: technically it's possible but it's basically update set in the database [17:18:29] harej: yes, AFAIK there is no interface in core to do it [17:18:32] That idea feels weird because then we'd need to do revision tracking of log entries [17:18:39] seems like it would jack anything reading the log [17:18:41] yeah [17:18:43] It seems like a business we're better off not getting into [17:18:54] so we’re talking, revise a judgment by creating a new log entry [17:18:59] Yes [17:20:22] yup [17:23:14] awight: What would you score C8? [17:24:51] halfak: how interested are you in the community engagement insights survey? [17:25:10] not really on my radar, but no reason for that. [17:27:21] Amir1: seems easy [17:27:53] Amir1: How is C9 easy, though? [17:27:59] OK I think I'm done for the day. [17:28:07] o/ [17:28:15] halfak: have fun [17:28:26] I'll be fully offline tomorrow for bike race. I [17:28:30] 'll be back online on Monday. [17:28:31] awight: logs have comments [17:28:49] But you can’t edit, as we were just saying [17:29:07] Wish me some healthy legs and good weather! I'll be on the bike for 14 hours if *everything goes as planned*. Longer if something goes wrong. [17:29:43] awight: maybe I'm misunderstanding. [17:29:48] Amir1, one final note. You were totally right about mwbase being a pain in the ass. [17:30:07] Ha. I've put a lot of time into this. Lots of little details. Especially around some old hacks we put together :| [17:30:18] halfak: yup [17:30:19] halfak: Break a leg! Hopefully it doesn’t blizzard [17:30:21] awight: what is the difference between per-user abuse filtering and automated abuse filtering? [17:30:38] that was one of the reason that I wanted to slice the frustration :D [17:30:42] awight, nope. Furnace, it looks like :| [17:31:16] Amir1, I think it'll still be good. It's nice to go back and forth between mwbase to implement some convenient features while I work. [17:31:18] harej: What I meant was, per-user is for when a newly discovered sockpuppet will be mass reverted; automated is when you write “f” bomb and AbuseFilter tells you to cut that shit out before saving. [17:32:31] Amir1: well, row 8 is where I would write the difficulty of “this integration supports freeform comments” and row 9 is “this integration allows comments to be edited" [17:32:48] I see [17:32:53] harej: hey nice work with the formula! [17:33:03] I copied and pasted the formula you wrote [17:33:35] We should probably use whole numbers for the average, since there isn't a lot of precision to this data. [17:33:38] " data " [17:34:07] I think my formula fell over when a cell was empty, that’s why it works for column B now. [17:34:11] sort of a feature ;-) [17:35:23] As for gaming the spreadsheet, if all three of us try to game it maybe it'll balance out :P [17:36:23] * Amir1 games harder [17:38:00] I am glad we can experiment with numbers without ascribing religious significance to the numbers. [17:38:27] Amir1: hehe if you don’t mind, I’m increasing C10, I think “replace with new log entry” is reasonable [17:38:37] Nice :D [17:39:53] coffee break, will be back soon [17:41:50] \o/ finish line, meet the team. [17:43:37] I think C5 is wrong, but am not familiar with the tools [17:43:52] oh, there's a Resolved comment there [17:44:00] There’s no such thing as “bulk revert” of log entries is what I mean [17:44:05] Amir looked into it; integrating AbuseFilter would require *some* work but it's not tooh ard. [17:44:07] Ah. [17:44:09] I don’t think it’s AbuseFilter integration though [17:46:23] * awight reads about AF [17:53:45] awight: as for C7, the number could be way higher [17:54:14] +1, or like +20 [17:55:30] If we can just use Special:Log and then use the dropdown to zero in on judgment logs the number would be 100 since we wouldn't have to do any special work [17:56:10] The use case I imagine is “What judgments exist for diff=12345” [17:56:30] Oooh. [17:57:36] Well I bumped it up to 75 since creating a view is hopefully not *that* hard in MediaWiki [17:58:18] Agreed! [17:59:00] You said C6 is not too difficult? Why any different than D6? [17:59:01] D6: Interactive deployment shell aka iscap - https://phabricator.wikimedia.org/D6 [17:59:09] awight: I put 50 for C5 (mass revert) [17:59:31] Probably the same for D5? [17:59:31] D5: Ok so I hacked up ssh.py to use mozprocess - https://phabricator.wikimedia.org/D5 [17:59:46] * harej glares at stashbot [18:00:17] Try /msg’ing that fool [18:00:44] I love stashbot but that’s annoying. [18:00:46] stashbot: help [18:00:46] See https://wikitech.wikimedia.org/wiki/Tool:Stashbot for help. [18:00:53] Isn't D11 and C11 inconsistent? [18:00:53] D11: Execute checks after each stage of deployment - https://phabricator.wikimedia.org/D11 [18:01:00] facepalm [18:01:12] stashbot: you're terrible [18:01:12] See https://wikitech.wikimedia.org/wiki/Tool:Stashbot for help. [18:01:38] Amir1: Ah, here’s the problem with both columns, dumps include all history. [18:01:42] We don’t have that for custom tables [18:02:47] actually if we use custom table without logging, it needs to have all cases (otherwise how you're going to revert) but itsn't the case for custom table with logging I guess [18:03:05] s/all cases/all of the history/ [18:05:07] maybe we also should include all of the history in the custom tables (even with logs) but then how we are going to implement suppression there [18:06:14] +1 custom tables w/o a log are a terrible idea [18:06:29] And we lose important data for researchers [18:06:44] hehe “log with custom tables” vs. “custom tables with a log" [18:08:58] https://phabricator.wikimedia.org/diffusion/LTST/browse/master/stashbot/bot.py$144 [18:09:56] average is 87 vs. 80. Just seven more :D [18:10:02] * Amir1 tries harder [18:10:12] (Just kidding, I didn't change much) [18:10:42] I love how phabricator shows the avatar in git blame [18:11:12] I change my avatar to a mug shot [18:11:56] These numbers are doing a decent job showing how we all feel about each implementation, at least. [18:12:30] Also we shouldn't take them too seriously as numbers, since ultimately they're made up numbers. 87 vs. 80 is almost a tie. [18:12:51] yeah, margin of error is huge [18:13:02] I downgraded C16 since the log entries can’t actually be migrated [18:13:04] Also weight of things are different [18:13:09] +1 [18:13:43] I want to be straight up about my lost-investment fallacy, btw: The wiki pages pilot is currently zero effort, and everything else will take significant coding. [18:14:54] So, we should be considering “pilot deployment” as a distinct beast sort of unrelated to “permanent deployment” [18:15:36] It is true that we get the most out of the implementation we've already built, but it's good that we're thinking about these approaches and problems *now* when we have the flexibility to make changes and not worry about change-managing a production system. [18:16:51] True, one big thing I want to see in the codebase is that I think it should be made pretty much storage-agnostic so if even if we change our minds later, we don't lose much [18:17:17] I don't know the codebase well enough though [18:19:26] It’s a nice theory, but usually not possible in the real world. [18:19:37] There should probably be components of JADE that are storage agnostic with middleware that implements the JADE concept at the wiki level. awight how much does JADE resemble that ideal? [18:20:25] Here’s the deal: you can abstract similar storage backends, but it’s a much different game if for example you want to support a RDBMS backend and a key-value store. [18:20:46] I’ll show u... [18:21:38] Here’s the current storage abstraction, https://phabricator.wikimedia.org/diffusion/EJAD/browse/master/includes/EntityJudgmentSetStorage.php [18:22:14] So we can go ahead and swap out the backend for anything that can store sets of judgments grouped by entity. [18:22:59] However, imagine what an implementation of storeJudgmentSet would look like for a log+custom table backend [18:23:23] or what it would look like if we decided to not group judgments together by entity [18:24:11] Another aspect of why this level of modularity is a bad take in our case is that we do *nothing* for recentchanges because it just works. [18:24:29] However, if we implemented using custom tables, there would be a huge amount of code supporting the recent changed view. [18:24:48] With zero benefit in abstracting anything between those two extremes. [18:30:06] (03CR) 10Reedy: "What does CARE mean?" [extensions/JADE] - 10https://gerrit.wikimedia.org/r/453103 (https://phabricator.wikimedia.org/T202039) (owner: 10MarcoAurelio) [18:30:27] awight: i feel like row 11 should be made into two different rows [18:30:44] doit :) [18:30:58] fwiw, I think the “full history” dump is almost the only thing researchers will care about. [18:31:14] ah I see [18:39:29] awight: Amir1, are there any more changes you want to make to the table, if not, where should we proceed from here? [18:40:06] I think we can summarize as: both wikipages and log entries are promising alternatives, and everything else is complete trash for our purposes. [18:40:14] Oh, agreed. [18:40:46] I suppose there’s a wealth of project planning information in here, like where the pain points will be if we try to develop an alternative log-centric implementation. [18:40:59] But donno if we care at this stage. [18:41:14] It's also a good summary we can put in front of TechCom as to why we made the decisions we did [18:41:57] I would accept the challenge of writing the log-centric alternative, but obviously it shouldn’t block any experimentation we can do with the highly functional prtksxna UI or [18:42:02] … or E:JADE. [18:42:13] i.e. let’s do the pilot already [18:42:56] And we know the price we’re paying: a handful of disturbed users who may be allies in the next iteration, plus some deleted pages lying about. [18:43:14] *potential price [18:43:33] It looks amazing to me [18:43:44] agreed with awight [18:44:45] You know what would be fun… reimplement wiki pages entirely as log events and stream processors [18:45:02] * awight drumrolls [18:45:30] Sounds trendy. [18:45:57] MediaWiki as a 12-factor app [18:46:51] It’s somehow reminiscent of wave-particle duality, that wiki pages have two orthogonal yet perfectly coupled important facts about themselves, the history and the current state. [18:47:55] The current state technically being a subset of the history. [18:48:13] A page is just a revision that hasn't been revised yet. [18:48:26] Right now is a subset of all time, etc. [18:49:00] (I hadn’t heard of the 12-branded methodology, good idea, too bad it’s billed as a monolithic package) [18:49:26] harej: current state being equivalent to position in the physical world [18:49:44] so, a bit more of its own value than just a subset of time x position [18:50:33] 12-factor sounds pretty legit but I've been writing code since the early 2000s and changing how I do things sounds like work [18:50:47] Though some things in there are obvious, like "use version control" [18:50:49] 10Scoring-platform-team (Current), 10ORES, 10User-Ladsgroup: Rewrite ORES "reference" UI using React - https://phabricator.wikimedia.org/T195274 (10Ladsgroup) @Jdlrobson That's amazing. It can be either an stab to make all of [[https://github.com/wikimedia/oojs-ui/tree/master/src/styles | oojs ui components]... [18:50:50] 10[1] 04https://meta.wikimedia.org/wiki/https://github.com/wikimedia/oojs%2Dui/tree/master/src/styles [18:51:01] harej: https://office.wikimedia.org/wiki/Bash#August_2018 [18:51:43] :D [18:51:46] harej: yeah that’s what I think too, it’s like Holacracy (tm), just pick and choose from recommended best practices, you don’t need to make a religion out of it. [18:53:49] so, ruling out the latter two options, i'm zeroing in on the differences between page-based and log-based, highlighting the cells where the scores are different for each column. [18:54:04] Hopefully this will help me succinctly summarize the trade-offs with each approach. [18:54:08] *cool [18:54:17] Thanks for taking this on! [18:54:39] Meanwhile, I can fill in the technical implementation. [18:54:39] Where is the most logical place to write down whatever words I come up with? [18:55:26] Heads up, I’m making our sheet public so you might set to world-suggest [18:55:38] harej: Good question! [18:56:15] I hate to say it but https://www.mediawiki.org/wiki/JADE/Implementations ? [18:56:42] Sure! [19:04:24] harej: Could even be a postscript to each section 3.1, 3.2, … [19:04:35] anticipated pain points [19:04:54] This turned out to be a great exercise, and my gut says it yielded the right answer. [19:43:09] mediawiki doesn’t have the Thanks extension? [19:43:26] ah just not in that diff view, strange [19:43:47] When you diff across multiple revisions, https://www.mediawiki.org/w/index.php?title=JADE/Implementations&type=revision&diff=2857246&oldid=2854742&diffmode=source [19:45:07] harej: I would move the central wiki stragegy to second place in that intro paragrah [19:45:50] eh I can do if you’re done editing [19:45:57] Go ahead [19:50:04] let me know when you're done editing [19:50:40] harej: done [20:42:44] Amir1: harej: Has anyone thought about whether “log + custom tables” is going to be x1 tables or normal extension tables? [20:42:57] I’m thinking the latter. [20:43:04] the latter [20:43:21] logs can't be separated [20:43:27] the custom table is not big [20:50:10] 10Scoring-platform-team (Current), 10ORES, 10User-Ladsgroup: Rewrite ORES "reference" UI using React - https://phabricator.wikimedia.org/T195274 (10awight) +1 to porting the select widget to the MediaWiki react components, good idea! [20:51:36] 10Scoring-platform-team (Current), 10ORES, 10User-Ladsgroup: Rewrite ORES "reference" UI using React - https://phabricator.wikimedia.org/T195274 (10dbarratt) FYI: I moved the React bindings for jQuery.i18n into it's own library: https://www.npmjs.com/package/@wikimedia/react.i18n [21:26:52] awight: have you thought about arbitrary wikitext content people might want to add to judgment pages as a whole, like templates and categories? [21:27:24] Someone, somewhere, is going to want to categorize judgment pages, I feel like. [21:27:41] Oh, speaking of the name, what if judgments are the individual acts of judgments and "judgment pages" are the pages, short of a new/better name? [21:29:58] harej: All I’ve thought so far is that judgment.comment is wikitext, but that isn’t a natural place to categorize the page itself. [21:30:28] Actually, categorizing the page begs some questions and makes its granularity very awkward. [21:30:54] Maybe people will be categorizing their own *judgment* rather than the entire page? [21:31:26] Also, I’m fine with “judgment page” for now, but it’s not intuitive that a judgment page holds many judgments. [21:31:35] Oh, just for working terminology. [21:31:42] +1 [21:31:57] More importantly, canonizing that a judgment refers to an individual act and not the page [21:36:35] I imagine the categories and templates would mostly be related to some workflow. [21:36:51] And I think being able to add those things is consistent with Risker's checklist and being able to curate pages. [21:37:16] right, per-judgment categories makes sense in that context, but our granularity is effed. [21:37:39] The category won’t apply nicely to the judgment page [21:37:53] Well, since MediaWiki doesn't allow categorization at that level of scope. Entire pages are categorized. [21:38:32] My idea is for arbitrary wikitext headers so that people can add header tags and categories as they please. [21:38:51] I’d love to see what happens! [21:39:47] Per-judgment categorization can't really be a thing, I don't think. If someone adds a category to a single judgment then the whole page will be categorized and in my opinion that's the correct behavior. [21:40:02] Now, if each individual judgment were its own page... [21:40:32] (Let's please not do that.) [21:46:29] harr [22:05:55] fyi, I’m outlining the log+custom table implementation, https://etherpad.wikimedia.org/p/JADE_design_sync [22:07:53] Excellent [22:08:07] awight: re. C13, how is this the case? Do logs not have API methods? [22:08:25] 10Scoring-platform-team (Current), 10ORES, 10User-Ladsgroup: Rewrite ORES "reference" UI using React - https://phabricator.wikimedia.org/T195274 (10Jdlrobson) @dbarratt nice! will definitely look at that tomorrow :) [22:09:23] harej: I’m not sure either way, for example we need APIs like “get all judgments for revision” [22:09:40] That seems like it takes API glue as well as custom tables where the log events have been indexed. [22:10:15] With per-wiki deployment the two options are to create judgments as pages and to create them as log entries. Both options offer significant re-use of MediaWiki components, which creates a better experience for the users and less engineering work overall. The details of these two proposals are outlined below. [22:10:15] Each solution offers its own advantages and disadvantages relative to the other one. Pages offer much more expressive content (entire JSON blobs vs. log entry summaries), the ability to revise judgments after the fact (including to designate one as a "preferred" judgment), and the ability to quickly roll back many judgments as needed. However, page revisions would be left behind on the wiki (with no ready ability to purge them all) should we choose to [22:10:15] remove the extension, and some UI work would be needed so that wiki users would not need to interact with raw JSON. With judgments as log entries, we gain the ability to purge the logs en masse (if needed) and better support for analytics but would need special API and UI affordances for listing judgments and designating a preferred judgment and deprecating old ones. [22:10:17] how is this summary [22:10:19] Logs can be retrieved by page ID, but that scales poorly for big pages [22:11:51] Seems pretty deep into the weeds, is this the paragraph we’re already tweaking? [22:12:29] I agree with the sentiment though! [22:12:29] I've saved it here: https://www.mediawiki.org/wiki/JADE/Implementations#Per-wiki [22:12:56] It's meant to be pretty detailed? It's supposed to break down what you get with each option. [22:13:14] Hmm, it works like that but I would entirely split the two, so per-wiki shouldn’t need to mention the log implementation at all [22:13:29] +1 for detail, I thought this was the intro to "Implementation strategies" [22:14:48] Darn, seems there’s no EventBus mapping for log actions yet [22:16:02] So much for "better support for analytics"? [22:16:15] (which was my attempt at me summarizing a stack I know next to nothing about) [22:16:36] yeah we’d have to write that mapping, not hard but I worry about the politics [22:17:19] I’m not sure if others would prefer a general stream like “resource-change”, or that we sandbox ourselves in a judgment-specific stream. [22:17:50] Either way, it’s not much code, just the negotiation more than anything. [22:18:41] This is a debate we'd have to have with Analytics? [22:19:23] yeah [22:19:27] and Services [22:19:54] They’d probably have some helpful advice right off the bat [22:21:20] "With judgments as log entries, we avoid the need for a new namespace and content to maintain" [22:21:27] This is probably my favorite thing about judgment as logs [22:21:49] Though with the spreadsheet I now recognize it's probably not as good an option as I thought it was. [22:30:52] (03CR) 10jenkins-bot: Localisation updates from https://translatewiki.net. [extensions/JADE] - 10https://gerrit.wikimedia.org/r/453240 (owner: 10L10n-bot) [22:31:56] There pretty much is content to maintain though, it’s all folded into Special:RecentChanges in a weird way is all. [22:33:03] Hmmm. [22:33:15] "we avoid the need for a new namespace and pages to maintain" ? [22:34:10] How do we not maintain pages? hehe [22:34:23] The content is all there, just split up among many log events [22:39:27] Well, pages can be vandalized or otherwise mucked up; log entries can't be. Feature or bug, you decide. [22:39:41] Log entries can't be vandalized because they can't be edited either! [22:41:21] they have to be edited somehow, so we emulate that layer and then worry about the output [22:42:26] i.e. a new judgment that’s supposed to replace an older one by log ID will be propagated into our custom tables, and then we need to deal with the resulting custom table content [22:42:47] vandalism would have to be rolled back, and we implement how to get to a previous judgment state [22:43:33] * awight adds to the log impl outline [22:43:33] Vandalism wouldn't have to be rolled back because there's no real concept of sequencing. It would be suppressed and ignored. [22:44:01] we do sequence, for better or worse [22:44:28] Here’s what I imagine: we need to support getting all judgments on an entity, which is probably with a custom table that collects content equivalent to what’s in the judgment page today. [22:44:58] Once we have that layer, we have a current state in the table, and suppression would require making edits to that content [22:57:22] hehe I think I scared you away [23:04:56] harej: There’s a new section in https://etherpad.wikimedia.org/p/JADE_design_sync, just compiling our notes so far and will try to turn that into an implementation outline. [23:07:44] Very nice. I’m looking at the JADE pages as a whole and trying to figure out how to organize the growing sprawl of content. I will defer to your implementation outline. [23:17:27] Thanks! It’s nice to have all this material to draw on, whatever comes next. [23:30:03] Cool, I have AbuseFilter running under vagrant so I can poke at it [23:36:53] signing off o/