[02:10:46] (03PS1) 10Catrope: Treat RC_LOG and RC_EXTERNAL rows as unscorable [extensions/ORES] - 10https://gerrit.wikimedia.org/r/367841 (https://phabricator.wikimedia.org/T168487) [02:26:12] (03PS1) 10Catrope: Use {{int:}} instead of hardcoding "Logged actions" [extensions/ORES] - 10https://gerrit.wikimedia.org/r/367842 [02:26:12] 10[1] 04https://meta.wikimedia.org/wiki/Template:int: [02:27:10] 10Scoring-platform-team, 10Edit-Review-Improvements-RC-Page, 10ORES, 10Wikidata, and 2 others: ORES: Don't highlight changes propagated from Wikidata - https://phabricator.wikimedia.org/T168487#3473463 (10Catrope) a:03Catrope [02:29:56] "Sorry, an error has occurred. Reason: That is an invalid ID, or the post has expired." [02:35:57] 10Scoring-platform-team, 10Edit-Review-Improvements-RC-Page, 10ORES, 10Wikidata, and 2 others: ORES: Don't highlight changes propagated from Wikidata - https://phabricator.wikimedia.org/T168487#3473484 (10Catrope) >>! In T168487#3473450, @gerritbot wrote: > Change 367841 had a related patch set uploaded (b... [02:50:50] (03CR) 10Jforrester: [C: 032] Use {{int:}} instead of hardcoding "Logged actions" [extensions/ORES] - 10https://gerrit.wikimedia.org/r/367842 (owner: 10Catrope) [02:50:50] 10[2] 04https://meta.wikimedia.org/wiki/Template:int: [02:52:35] (03Merged) 10jenkins-bot: Use {{int:}} instead of hardcoding "Logged actions" [extensions/ORES] - 10https://gerrit.wikimedia.org/r/367842 (owner: 10Catrope) [02:52:35] 10[3] 04https://meta.wikimedia.org/wiki/Template:int: [05:23:48] 10Scoring-platform-team-Backlog, 10ORES, 10Release-Engineering-Team, 10Scap: ORES should use git-fat for wheel deployments - https://phabricator.wikimedia.org/T171619#3473690 (10demon) For checking in, yes without issue (that's all client side). However fetch/pull requires rsync access to fatten the blobs... [08:15:03] PROBLEM - puppet on ores-worker-08 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [08:32:42] PROBLEM - puppet on ores-redis-02 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [08:34:20] PROBLEM - puppet on ores-worker-05 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [08:34:56] PROBLEM - puppet on ores-redis-01 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [08:36:57] PROBLEM - puppet on ores-worker-10 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [08:38:05] PROBLEM - puppet on ores-worker-09 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [08:43:42] PROBLEM - puppet on ores-worker-06 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [08:48:37] PROBLEM - puppet on ores-web-03 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [08:51:15] PROBLEM - puppet on ores-worker-07 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [08:54:42] PROBLEM - puppet on ores-lb-02 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [08:55:07] PROBLEM - puppet on ores-worker-08 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [08:55:54] PROBLEM - puppet on ores-web-05 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:12:42] PROBLEM - puppet on ores-redis-02 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:14:22] PROBLEM - puppet on ores-worker-05 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:14:57] PROBLEM - puppet on ores-redis-01 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:21:26] PROBLEM - puppet on ores-worker-10 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:23:42] PROBLEM - puppet on ores-worker-06 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:28:38] PROBLEM - puppet on ores-web-03 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:31:17] PROBLEM - puppet on ores-worker-07 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:34:42] PROBLEM - puppet on ores-lb-02 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:35:07] PROBLEM - puppet on ores-worker-08 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:35:57] PROBLEM - puppet on ores-web-05 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:50:35] RECOVERY - puppet on ores-worker-07 is OK: OK: Puppet is currently enabled, last run 22 seconds ago with 0 failures [09:52:47] PROBLEM - puppet on ores-redis-02 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:54:27] PROBLEM - puppet on ores-worker-05 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:55:02] PROBLEM - puppet on ores-redis-01 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:55:03] RECOVERY - puppet on ores-lb-02 is OK: OK: Puppet is currently enabled, last run 47 seconds ago with 0 failures [09:55:15] RECOVERY - puppet on ores-web-05 is OK: OK: Puppet is currently enabled, last run 47 seconds ago with 0 failures [09:57:02] PROBLEM - puppet on ores-worker-10 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:58:12] PROBLEM - puppet on ores-worker-09 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [09:59:45] I wonder why ^^ those are failing? [10:02:02] RECOVERY - puppet on ores-redis-02 is OK: OK: Puppet is currently enabled, last run 5 seconds ago with 0 failures [10:03:42] RECOVERY - puppet on ores-worker-05 is OK: OK: Puppet is currently enabled, last run 48 seconds ago with 0 failures [10:03:47] PROBLEM - puppet on ores-worker-06 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [10:04:17] RECOVERY - puppet on ores-redis-01 is OK: OK: Puppet is currently enabled, last run 7 seconds ago with 0 failures [10:06:18] RECOVERY - puppet on ores-worker-10 is OK: OK: Puppet is currently enabled, last run 40 seconds ago with 0 failures [10:07:04] RECOVERY - puppet on ores-worker-09 is OK: OK: Puppet is currently enabled, last run 9 seconds ago with 0 failures [10:08:42] PROBLEM - puppet on ores-web-03 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [10:12:36] RECOVERY - puppet on ores-worker-06 is OK: OK: Puppet is currently enabled, last run 27 seconds ago with 0 failures [10:15:03] RECOVERY - puppet on ores-worker-08 is OK: OK: Puppet is currently enabled, last run 20 seconds ago with 0 failures [10:17:58] RECOVERY - puppet on ores-web-03 is OK: OK: Puppet is currently enabled, last run 42 seconds ago with 0 failures [10:34:20] PROBLEM - puppet on ores-worker-05 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [10:34:56] PROBLEM - puppet on ores-redis-01 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [10:34:59] new puppet errors are about to start [10:35:04] with [10:35:04] Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError: Could not find declared class ::puppet_statsd at /etc/puppet/modules/base/manifests/puppet.pp:58 on node jenkins-slave-01.git.eqiad.wmflabs [10:35:04] Warning: Not using cache on failed catalog [10:35:04] Error: Could not retrieve catalog; skipping run [10:36:57] PROBLEM - puppet on ores-worker-10 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [10:38:14] should start recoverying now [11:03:42] RECOVERY - puppet on ores-worker-05 is OK: OK: Puppet is currently enabled, last run 23 seconds ago with 0 failures [11:05:16] RECOVERY - puppet on ores-redis-01 is OK: OK: Puppet is currently enabled, last run 25 seconds ago with 0 failures [11:05:40] RECOVERY - puppet on ores-worker-10 is OK: OK: Puppet is currently enabled, last run 41 seconds ago with 0 failures [14:45:15] (03CR) 10Sbisson: [C: 032] Treat RC_LOG and RC_EXTERNAL rows as unscorable [extensions/ORES] - 10https://gerrit.wikimedia.org/r/367841 (https://phabricator.wikimedia.org/T168487) (owner: 10Catrope) [14:47:00] (03Merged) 10jenkins-bot: Treat RC_LOG and RC_EXTERNAL rows as unscorable [extensions/ORES] - 10https://gerrit.wikimedia.org/r/367841 (https://phabricator.wikimedia.org/T168487) (owner: 10Catrope) [14:49:20] o/ [14:49:52] I'm a bit late today. Not feeling 100% this morning. [14:52:19] 10Scoring-platform-team, 10Edit-Review-Improvements-RC-Page, 10ORES, 10Wikidata, and 2 others: ORES: Don't highlight changes propagated from Wikidata - https://phabricator.wikimedia.org/T168487#3366057 (10SBisson) From the task description: > There should be no highlighting for these rows regardless of whe... [15:04:11] awight turns out i had to add the support in gwtui (lol on the side) [15:04:20] anyways got it working now :) [15:07:14] paladox: argh. Stop my if I’ve already mentioned this, but the one (1) time I tried to add anything to Gerrit, I discovered that the same UI feature had to be added in three (3) separate codebases, each of which used a totally different convention for its data structures. [15:07:17] Madness. [15:07:18] o/ [15:07:24] hola! [15:07:56] oh [15:08:09] awight was that when you were trying to add a db support/ [15:08:16] ie like mysql or postgress? [15:08:43] It's pretty now all in one repo except from the db layers which is in core and also another repo [15:09:01] they have deprecated ReviewDB (database) and are moving to NoteDB [15:09:59] paladox: hehe no, just a UI checkbox, something like a preference to always open unified diffs rather than always side-by-side [15:10:05] ah [15:10:08] that's really easy [15:10:09] now [15:10:21] IIRC it was all in one repo, but totally different libraries and data structs [15:10:36] i've added preference support [15:10:41] Cool! Well, you’ve almost given me the confidence to take another look. [15:10:54] heres one of my changeshttps://gerrit-review.googlesource.com/#/c/114650/ [15:10:54] oh look! some ORES stuff I have to do ;-) [15:11:10] ah neat, looking [15:11:16] yep [15:11:37] awight you could implement things in the backend of gerrit and add it for polygerrit only [15:11:44] it's based in javascript and html [15:11:48] really easy stuff heh [15:12:03] (java is the hard part) [15:12:11] how is “going through the design process” with the other devs? [15:12:24] on gerrit? [15:12:45] fine :) [15:12:49] they have a google-java-format tool now [15:20:56] 10Scoring-platform-team-Backlog, 10ORES, 10Release-Engineering-Team, 10Scap: ORES should use git-fat for wheel deployments - https://phabricator.wikimedia.org/T171619#3475026 (10Halfak) > but it's not undoable. What? We do github based deploys in our Cloud VPS cluster (not beta) using [fabric](http://w... [15:26:41] awight i helped fixed base urls in polygerrit upstream [15:26:50] so polygerrit will work on wmf gerrit when we upgrade [15:27:05] its much faster then gwtui and also mobile optimised [15:29:04] 10Scoring-platform-team-Backlog, 10ORES, 10Release-Engineering-Team, 10Scap: ORES should use git-fat for wheel deployments - https://phabricator.wikimedia.org/T171619#3475056 (10bd808) >>! In T171619#3475026, @Halfak wrote: > AFAICT, there's no good option for doing scap-based deploys in Cloud VPS (outside... [15:29:08] awight i've also helped to implement alot of the admin pages (project list ... etc) [15:32:02] C [15:32:11] Cool—gerrit sure needed the TLC [15:33:05] Not sure I understand what the system would look like, but will you be able to run Polygerrit against WMF Gerrit, or is WMF considering running Polygerrit on the server? [15:34:46] awight polygerrit is gerrit's new ui [15:34:50] it's built in :) [15:35:04] so when we upgrade we doint need to do anything extra [15:35:15] gerrit also allows emailing comments through email [15:35:24] but that will have to be setup seperatly [15:35:48] Ah now I see what you mean by “polygerrit will work on wmf gerrit when we upgrade” [15:37:32] :0 [15:37:33] :) [15:39:27] awight: https://gerrit.git.wmflabs.org/r/?polygerrit=1 [15:41:11] awight, just invited you to a meeting on Friday at 7AM PDT. Please feel free to ignore. Just wanted it on your radar [15:41:54] 10Scoring-platform-team, 10ORES, 10Patch-For-Review: Stress/capacity test new ores* cluster - https://phabricator.wikimedia.org/T169246#3475078 (10Halfak) @akosiaris, I could use a hand making sure I'm hitting the new cluster in a reasonable way. I just invited you to sit down with me at 1400 UTC on Friday.... [15:42:03] loll Looking forward to it [15:44:51] * halfak pours hot coffee on his lap [15:44:58] Oh so it's going to be one of those days, huh? [15:45:37] That wakes you up in all the wrong ways [15:46:08] paladox: <3 that polygerrit interface, at least relative to the baroque direction the UI was headed in for the last few gerrit upgrades [15:46:16] 10Scoring-platform-team-Backlog, 10ORES, 10Release-Engineering-Team, 10Scap: ORES should use git-fat for wheel deployments - https://phabricator.wikimedia.org/T171619#3475091 (10Halfak) Gotcha. Maybe we could stick that in our `ores-staging` project. @demon, if that makes things easier for you, we can... [15:46:25] :) [15:46:33] it's based on polymer [15:46:41] what youtube is being upgraded too [15:46:53] WHo thinks starting up a scap2 deployment server in labs sounds like fun? [15:47:00] * halfak is not being sarcastic [15:47:03] scap3 [15:47:07] scap2 is old [15:47:09] :) [15:47:16] Woops. missed the 3 [15:47:20] halfak i have a scap server [15:47:22] phab-tin [15:47:23] :) [15:47:32] Ahh so you have experience with this? [15:47:49] twentyafterfour did alot of work though i fixed it [15:47:54] but i use my account [15:48:25] Interested in trying this out for ORES? [15:48:46] yes [15:48:47] you can use phab-tin if you want [15:49:47] * awight watches halfak go fishing with fascination [15:51:48] Hmm... It seems that people in releng/cloud do not like the idea of cross VPS project scap deployment servers [15:52:18] But I'm not sure why [15:52:49] Maybe we could make ores-misc-01 be the deployment tin. Is there a good reason why that is a bad idea? [15:58:36] I don’t know much about this stuff, but probably something about privilege separation. If everyone with ores-misc access is a trusted deployer, then it’s fine. [15:58:53] 10Scoring-platform-team-Backlog, 10ORES, 10Release-Engineering-Team, 10Scap: ORES should use git-fat for wheel deployments - https://phabricator.wikimedia.org/T171619#3475148 (10Halfak) I talked to @Paladox -- who offered that we could make use of phab-tin. Would it be better to set up our own deployment... [15:59:08] awight, oh hmm. That's an interesting point. [15:59:45] We should have priv separation between `ores` project and `ores-staging` project [16:00:00] +1 [16:01:30] The deployment server can be an x-small box, fwiw. But afaik it’s best to give machines each a single or at least a small number of responsibilities. [16:04:08] I’m still feeling vague about the issue here—is it just that we don’t want to machines across different projects to have ssh/rsync access to one another? [16:04:24] or is there more going on? [16:05:46] We could have another x-small in the ores project. [16:06:11] awight, see PM [16:14:42] awight, which issue are you referring to? [16:15:06] Why is git-fat tricky so far? [16:17:35] I have no idea [16:17:47] I don't know why we need to fatten or hydrate anything [16:18:00] haha kk glad to know we’re in the same boat [16:18:29] My thought with git-lfs was that we'd have a within-prod mirror like the diffusion mirrors of github. [16:18:37] yes, me too. [16:18:37] So with git-fat, I'm not sure what we want to do. [16:18:42] k I’ll note that on the task [16:21:03] 10Scoring-platform-team-Backlog, 10ORES, 10Release-Engineering-Team, 10Scap: ORES should use git-fat for wheel deployments - https://phabricator.wikimedia.org/T171619#3475205 (10awight) @demon We're fine with deploying from WMF production repos, I'm sure we can figure something out to push mirrored code or... [16:21:13] hopefully I got that right. [16:24:18] hey this is a good topic for scrum of scrums [16:29:20] \o/ [16:30:08] awight|brb, thank you for making that note. I forgot to say that we only have a quirk of history that we deploy from the github repos. We just want to be able to allow volunteers to do their pull requests there. [16:33:36] 10Scoring-platform-team-Backlog, 10ORES, 10Scap, 10Release-Engineering-Team (Watching / External): ORES should use git-fat for wheel deployments - https://phabricator.wikimedia.org/T171619#3475235 (10greg) (Just doing some project management, don't worry about the "watching" bit, we'll just create a (sub)t... [16:49:21] 10Scoring-platform-team-Backlog, 10ORES, 10Scap, 10Release-Engineering-Team (Watching / External): ORES should use git-fat for wheel deployments - https://phabricator.wikimedia.org/T171619#3475303 (10demon) >>! In T171619#3475026, @Halfak wrote: >> but it's not undoable. > > What? > Bad choice of word... [16:52:41] 10Scoring-platform-team-Backlog, 10ORES, 10Scap, 10Release-Engineering-Team (Watching / External): Git-fat should support pulling from production or labs - https://phabricator.wikimedia.org/T171758#3475312 (10awight) [16:55:36] 10Scoring-platform-team-Backlog, 10ORES, 10Scap, 10Release-Engineering-Team (Watching / External): Git-fat should support pulling from production or labs - https://phabricator.wikimedia.org/T171758#3475334 (10demon) Just wanting to clear up a little bit of FUD, since there seems to be this misconception th... [16:56:52] 10Scoring-platform-team-Backlog, 10ORES, 10Scap, 10Release-Engineering-Team (Watching / External): Git-fat should support pulling from production or labs - https://phabricator.wikimedia.org/T171758#3475335 (10Halfak) What does *better* look like? What would you do if you had the time to do it? [16:59:22] 10Scoring-platform-team-Backlog, 10ORES, 10Scap, 10Release-Engineering-Team (Watching / External): Simplify git-fat support for pulling from both production and labs - https://phabricator.wikimedia.org/T171758#3475357 (10awight) [16:59:48] 10Scoring-platform-team-Backlog, 10ORES, 10Scap, 10Release-Engineering-Team (Watching / External): Simplify git-fat support for pulling from both production and labs - https://phabricator.wikimedia.org/T171758#3475312 (10awight) @demon Thanks! I've updated the description. [17:00:19] 10Scoring-platform-team-Backlog, 10ORES, 10Scap, 10Release-Engineering-Team (Watching / External): Simplify git-fat support for pulling from both production and labs - https://phabricator.wikimedia.org/T171758#3475365 (10demon) The idea I was noodling the other day was kind of a generic rsync service that... [17:14:58] * halfak --> lunch [17:22:47] 10Scoring-platform-team, 10Edit-Review-Improvements-RC-Page, 10ORES, 10Wikidata, and 3 others: ORES: Don't highlight changes propagated from Wikidata - https://phabricator.wikimedia.org/T168487#3475452 (10Catrope) >>! In T168487#3474933, @SBisson wrote: > From the task description: >> There should be no hi... [17:29:54] halfak|Lunch: other day I discovered SSDB, which has almost the same exact API and performance as Redis but not everything needs to be in-memory [17:30:08] I'm experimenting with it for storing some particularly large datasets [17:52:04] What on earth does “100x Redis” mean? [17:54:23] Redis but more EXTREME? [17:58:57] Redis on steroids :P [17:59:40] or as I read on a deep learning-related github page today: quantum leap!!!! [18:14:43] harej, redis + swap? [18:15:44] halfak: more like redis + leveldb [18:15:49] With redis, you can use swap and your OS' memory management to store far more than can be kept in RAM [18:16:22] that is no longer the case unfortunately [18:16:31] what? [18:16:34] they've deprecated that feature [18:16:42] That's not a redis feature. [18:16:44] :) [18:16:53] It's a logical consequence of redis. [18:17:04] okay but swap has a lot of overhead and gets you reduced performance [18:17:09] Redis used to manage their own on-disk access, but it turns out it's better to just let the OS do it. [18:17:20] No it doesn't? [18:18:15] has this been benchmarked? [18:18:22] Good Q [18:19:15] True that swap is a whole lot slower than RAM, but AFAIK it’s no slower than regular disk access, so I’m wondering how SSDB does any better [18:20:07] well with SSDB you can cap how much is stored in memory (you can't cap overall RAM usage, so RAM usage will be your cache cap + overhead) and the rest is stored on disk [18:20:20] But I don't know how much different that is from setting a limit in Redis [18:21:07] aww man, my test_model hasn’t done anything since yesterday... [18:21:39] No CPU usage [18:21:56] I see what I did there [18:22:58] don’t read from stdin if you forgot to pipe into the tool [18:23:11] woops [18:25:33] halfak: I guess the main difference is that instead of falling back to swap, it falls back to regular hard drive space [18:25:55] since it is, ultimately, an on-disk store, not an in-memory store [18:27:51] swap is hard drive. [18:32:44] It’s an entertaining value proposition, that Redis is the in-memory outlier among on-disk key-value stores, and SSDB is the on-disk among Redisen [18:33:27] Looking forward to hearing more about experiences using it, though! If it can really deliver in-memory performance with on-disk data, that’s brilliant! [18:37:38] 10Scoring-platform-team, 10editquality-modeling, 10User-Ladsgroup, 10artificial-intelligence: Flagged revs approve model to fiwiki - https://phabricator.wikimedia.org/T166235#3475671 (10awight) Test results ``` make models/fiwiki.damaging_w_flaggedrevs.gradient_boosting.model revscoring test_model \ models... [18:40:45] Why would ROC-AUC have only one significant digit? Could both stats really be 0.900? [18:41:47] awight, I think that's what must be happening here. [18:42:29] Looks like things have gotten worse [18:42:45] that seems like a 1:10,000 chance but OK [18:42:45] I guess the odds are a bit higher, because the distribution will be around there anyway [18:43:52] halfak: How do I get the threshold stats? Just for reference, I won’t bother in this case. [18:44:04] It’s not in model_info yet. [18:44:43] awight, is this built with 1.3 or 2.0? [18:44:51] 1.3 [18:44:58] Oh yeah. I can tell by the output. [18:45:05] So you would use a "statistic" param [18:45:09] But the checked-in models must be built with 1.3 as well? [18:45:11] halfak: for Russian wiki goodfaith model, the AUC is 0.935, so, no difference i assume? [18:45:12] See the editquality makefile [18:45:17] ah okay [18:46:03] fajne, yeah, pretty minor. Probably random. [18:46:21] so what does that may mean? [18:46:33] Labels for ruwiki are better? [18:46:42] Fewer nulls or unimportant nulls for goodfaith [18:47:56] hm.. and the interface for ruwiki looks identically to enwiki, right? [18:48:14] ^i mean wikilabels [18:51:23] 10Scoring-platform-team, 10editquality-modeling, 10User-Ladsgroup, 10artificial-intelligence: Flagged revs approve model to fiwiki - https://phabricator.wikimedia.org/T166235#3475711 (10awight) Comparing to `revscoring model_info models/fiwiki.damaging.gradient_boosting.model`, the model trained on flagged... [18:54:37] aha. ROC is “receiver” because it was invented by wire nuts building radar. [18:54:39] fajne, identical except for translated bits. [18:54:47] awight, right [18:54:57] Receiver operating characteristic [18:55:01] I like “relative” operating character better, now that I know. [18:55:02] *istic [18:55:24] even if it is a backronym at this point [18:58:50] halfak: actually i don't see ruwiki here https://labels.wmflabs.org/ui/ ..am i blind? (tell me the truth, i can handle it:)) [18:59:59] fajne, lol. ruwiki shows up because we already finished the labeling stuff. [19:00:25] and for enwiki it's still on? [19:00:44] oh, it's 2016 campaign, got it [19:02:29] (Is there an API for showing past campaigns?) [19:02:40] Right. We could start up a new one for ruwiki. I think it is due [19:02:57] awight, I think the API hides all of the !active campaigns. [19:03:06] We don't have a param yet to make them visible [19:03:13] But you can still look them up by ID if you have it [19:03:52] Sure—do we care about rounding out this API, enough that I should write a todo? [19:04:16] I remember a task somewhere about cleaning up the Wiki Labels api docs... [19:05:44] halfak, who designed that tool? can i talk to this person? or i will have to just keep asking you about the purpose of certain buttons there. Like, "Unsure?" checkbox. Is it unsure about both categories (damaging and goodfaith) or only about the latter? [19:06:25] * awight wants to give T105518 another token [19:09:20] 10Scoring-platform-team-Backlog: New Wiki Labels API to list all / finished campaigns - https://phabricator.wikimedia.org/T171768#3475772 (10awight) [19:09:28] * awight glares at stashbot [19:12:01] fajne, I mostly designed it. [19:12:12] And built the whole thing. [19:12:19] 10Scoring-platform-team-Backlog: Make Wiki Labels API response format and URL scheme consistent - https://phabricator.wikimedia.org/T171770#3475804 (10awight) [19:12:32] Amir1, does a lot of maintenance and he's responsible for a few UX fixes more recently. [19:13:01] Unsure is something our users ask for. they wanted to be able to signal which judgements were hard to make. [19:13:23] +1 from me personally [19:13:29] “cop out” is my middle name. [19:20:38] yeah, right, "unsure" is a great option, but how does it work? Say, you choose "yes" for damaging, but if it's goodfaith you're unsure. So you also check 'unsure' as if for "goodfaith/badfaith". How does the system see it: unsure/unsure, or damaging/unsure? [19:21:04] fajne, I don't see the problem [19:21:06] Randomly, wondering what to do with a branch like the one I pushed ^? It might be interesting to future us because it shows how to use the new utils in a Makefile, but ultimately I’m abandoning the Makefile changes since the experiment was a failure. [19:21:49] awight, my thought is to document the relevant things and then delete the branch. I like on-wiki reports so we can find them later with elastic search. [19:22:02] fajne: I would say damaging/unsure, right? Why would it be (unsure, unsure)? [19:22:21] awight, https://meta.wikimedia.org/wiki/Research_talk:Automated_classification_of_edit_quality [19:22:34] That's a good place to put any reports that are relevant to the editquality models. [19:23:18] halfak: cool. You even blogged :D. but wait—on that specific talk page? [19:23:29] awight, see the "work log" [19:23:39] awight: https://gerrit-review.googlesource.com/#/c/115710/ https://gerrit-review.googlesource.com/#/c/115311/ :) [19:24:47] halfak: those are archives of this page? WFM [19:25:16] paladox: ooh “cherry-pick”, very nice! [19:25:25] no it's move change [19:25:31] err, wait what’s the difference? [19:25:32] cherry-pick is already implemented [19:25:36] halfak: i see no problem either, i am simply asking. so it should be damaging/unsure? [19:25:40] you can move the change through branches [19:25:45] ie like it's a new change [19:25:48] so the change will stop existing on the old branch [19:25:49] kk [19:25:59] I can see that being useful! [19:26:00] yes (only works on open changes) [19:26:13] Branches upon branches is something GitHub seems to be terrible at. [19:26:38] e.g., merging the head branch also merges its predecessors, IIRC [19:27:21] lol [19:27:33] awight drafts are fianlly being removed [19:27:43] paladox: I lost some part of my soul immediately after reading “ all changes created through web ui will be wips [19:27:47] lol [19:28:10] you were saying! That could be an improvement, I can’t really imagine it well enough yet though [19:31:07] paladox: wow, your “move” change needed a staggering amount of plumbing, just due to the prog design. I still haven’t found the code that actually does the move. [19:31:18] lol [19:31:23] That’s exactly what I remember of fooling around in that code [19:31:27] it's through the rest api [19:31:54] It’s ironic too, that all this abstraction is required and meanwhile the message strings are hardcoded into a monolingual properties file. [19:32:03] yes [19:32:07] Good call to push that forward. [19:32:10] upstream are planning translations [19:32:15] gwtui is deprecated [19:32:17] The gerrit UI really isn’t translatable yet? [19:32:30] nope, though that will change when gwtui is dead [19:32:40] polygerrit is a fresh of life [19:32:46] easy to implement translations [19:33:26] & do you happen to know, is that project still funded by Google or is it all volunteer now? [19:33:54] the king is dead, long live the king! [19:35:26] Yes [19:35:29] halfak: I’m really confused suddenly. The talk page you sent me has discussion from 2015 and 2016, but the archives go through this year. [19:35:34] awight it's still funded by google [19:35:36] as android uses [19:35:38] it [19:35:45] awight actually all google projects use gerrit [19:35:54] halfak: So now I’m thinking, it’s not an archive, I’m supposed to click that “new log entry” thing? [19:36:06] google employees in america and germanly develop and alot of volunteers too [19:36:29] paladox: Are you sure? I was talking to an employee maybe 4 years ago and this person said they use something else for CR [19:36:37] awight, right you got it [19:36:40] Yes sure [19:36:43] chromium [19:36:45] (chrome) [19:36:48] google internal [19:36:55] i think that's google search engine heh [19:37:07] Maybe they run their open source through it but not proprietary code? [19:37:20] awight licensed under apache2 [19:37:23] apache 2.0 [19:37:30] awight i just filled https://bugs.chromium.org/p/gerrit/issues/detail?id=6862 [19:40:22] This is pretty scant evidence, but confirms your allegation! https://news.ycombinator.com/item?id=12620735 [19:40:55] halfak: kthx. Can we archive that 2015 discussion? [19:41:39] Harrr. no VE on talk pages. [19:41:40] awight, porque? [19:41:57] I don’t see how the 2015 convo has anything to do with the “work log” [19:42:32] awight, it doesn't. It's a talk page discussion about the research [19:43:17] yes. Glad that’s out of the way ;-). So perhaps we should have an page dedicated to just the work log? [19:43:34] awight, each research project has its own work log [19:43:46] It seems convenient that the work log list is posted on the talk page. [19:43:53] I'm not sure what the issue is. [19:44:35] all good. I’m just trying to create a mental model of WTF [19:44:42] This is, like, old Research namespace practice. [19:44:44] Gotcha [19:44:46] aha [19:46:06] Hmm, I was about to write a sentence explaining this to fellow acolytes but now I think we need a bigger intervention. Like a help box explaining what the work log is for. [19:46:11] Will not do. [19:46:52] brb [19:48:36] https://meta.wikimedia.org/wiki/Template_talk:Work_log [19:51:02] awight polygerrit has an emojie selector [19:51:18] you can save the emojie only if we are using utf8mb4 [19:51:48] lol, for emojen but not for languages [19:59:13] halfak: are we assuming all our reviewers are closely familiar with wikitext? [20:05:05] b [20:05:12] awight https://groups.google.com/forum/#!topic/repo-discuss/V9IgnEDKQE8 [20:05:17] heh 2.15 disccusions now [20:25:11] 10Scoring-platform-team, 10ORES, 10Operations: rack/setup/install ores2001-2009 - https://phabricator.wikimedia.org/T165170#3476095 (10RobH) [20:46:35] fajne, yes definitely [20:52:12] 10Scoring-platform-team, 10editquality-modeling, 10User-Ladsgroup, 10artificial-intelligence: Investigate small loss in fitness with the new data in fawiki - https://phabricator.wikimedia.org/T171386#3476187 (10Halfak) Looks like there was a substantial improvement to pr-auc [20:52:46] halfak: Would you prefer that I abandon the one-off data processing scripts, leave in some semi-usable scrap bin, or make into full revscoring utilities? [20:53:19] awight, what are you talking about? [20:53:54] halfak: https://github.com/wiki-ai/revscoring/compare/data_utils [20:54:40] I think the deduplicate_revs one is useful if you apply the changes we discussed. [20:54:52] If normalize is useful, it'd be useful in editquality [20:56:41] Why would normalize only be useful in editquality? The column specification is fully dynamic [20:58:39] Doesn't look like it from the code. Also, I'm not sure the column spec *should* be dynamic. [20:58:40] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it [21:02:03] hehe well perhaps not “fully”…. It’s pretty hardcoded at the moment. But passed as a function param at least. [21:02:09] awight here we go .... reviewdb is being removed in 3.0 [21:03:00] polygerrit becomming default ui in 2.15 (supposidly) [21:03:07] mm? Is that something WMF is using and will go crazy migrating off of? [21:04:52] awight no wmf is not using it yet as it's not in 2.13 and not stable just yet [21:04:55] until 2.15 [21:05:06] we will probaly wait until they remove reviewdb [21:05:12] https://gerrit.googlesource.com/homepage/+/md-pages/docs/Notedb.md [21:17:09] halfak: i updated my blogpost on training set revision. the last section is the observations: https://meta.wikimedia.org/wiki/Research_talk:Automated_classification_of_edit_quality/Work_log/2017-07-24 [21:18:31] fajne, I made some bad faith edits in some of my earliest edits. [21:18:54] But by your logic, those edits were actually good faith because I'm obviously good faith now. [21:19:14] i see... [21:20:18] did you do this under your account? [21:20:37] > Those who are real vandals do not remove their edits, and it takes patrol up to several days to find and revert them. [21:20:50] This is not true. Most vandalism is reverted with 5-30 seconds. [21:21:07] i think i explained it [21:21:19] https://grouplens.org/site-content/uploads/2013/09/geiger13levee-preprint.pdf [21:21:46] a lot of quickly reverted vandalism is reverted by the vandals themselves [21:21:55] they sort of testing wiki [21:22:05] Ahh I see. Yeah. [21:22:16] Still was intentionally damaging [21:22:21] i probably should rephrase that paragraph [21:22:27] well [21:22:40] reverted themselves? [21:22:44] it was, but they did not want it to stay [21:22:52] "So whether the user is_anon may be a misleading feature." Not sure I understand this. [21:23:31] yeah, it's like "let's see if i can edit wiki: dbhjsfg; oh, i can! shit, i need to revert it quickly" [21:24:28] halfak, i just found a bunch of registered outrageous vandals. i did not expect they would register, [21:24:46] fajne, I definitely agree that there is a difference between "dhasbdka" and racial slurs. [21:24:53] I put "askbdkab" in the good-faith damage category [21:25:30] oh, you do? some sjfhfgll actually stay until a patrol finds it.. [21:25:55] goodfaith is complicated)) [21:26:37] Yeah. It's not a bold line between goodfaith and badfaith. E.g. I'd say deleting a section is badfaith even though it might have similar motivations. Adding a little bit of obvious nonsense is far less destructive than the removal of information. [21:27:23] both are badfaith for me.. [21:27:36] both are not productive [21:27:59] but the seriousness of the crime is different, for sure) [21:28:49] i wouldn't assign capital punishment foraskhjsfhndfl; )) [21:28:56] *for [21:29:24] ha [21:33:42] I think this is a great report :) [21:33:45] Nice work fajne [21:34:03] when awight gets back, let's talk meta-ORES schema [21:34:05] thanks! [21:34:11] sure [22:09:06] halfak: meanwhile, do i need to test this default-to-goodfaith thing on all other wikis? what if the AUC will get lower for some? 8-\ [22:15:37] 10Scoring-platform-team, 10Wikilabels, 10editquality-modeling, 10artificial-intelligence: Unlabeled goodfaith observations are assumed "false" -- should be "true" - https://phabricator.wikimedia.org/T171491#3476377 (10Natalia) For English wikipedia, the change to assuming goodfaith edit when the actual lab... [22:28:29] fajne, we should use it to rebuild all of the models. Submit a PR with your code change and I'll manage the job for rebuilding all of the models. I'll then give you all of the stats to re-check ;) [22:28:33] It shouldn't be too hard. [22:28:42] I've got to run. Have a good evening folks! [22:28:42] o/ [22:28:57] meta-ORES schema discussions tomorrow :) [22:30:32] ok [22:40:21] Wireless network led to a wire, which I managed to bump into [22:41:01] anyway. halfak did you want to schedule a discussion about meta-ores tomorrow? [22:45:26] awight you missed him by a few mins heh [22:46:08] whew! close call... [22:46:23] lol [22:50:41] awight: yep, the meta ores schema discussion is tomorrow