[08:25:34] <wikibugs>	 06Revision-Scoring-As-A-Service, 10Wikilabels, 10rsaas-editquality: Deploy edit quality campaign for Romanian Wikipedia - https://phabricator.wikimedia.org/T156357#3008418 (10Andrei_Stroe) Done.
[14:32:23] <glorian_wd>	 halfak: I replied your feedback on https://www.wikidata.org/wiki/Wikidata_talk:Item_quality
[14:32:43] <glorian_wd>	 your modification*
[15:36:13] <halfak>	 o/ 
[15:36:17] <halfak>	 Hey glorian_wd 
[15:36:47] <glorian_wd>	 hey o/
[15:36:56] <glorian_wd>	 thought maybe you want to have a look at my reply
[15:36:57] <halfak>	 Looking at the discussion
[15:37:03] <glorian_wd>	 yeah take your time
[15:39:35] <halfak>	 OK.  So in your reply, I see some wording change proposals and some suggestions for further minimizing redundancy.  But then you say "I still think the previous criteria better than this one" but I can't tell what the old criteria makes explicit that this one doesn't
[15:39:52] <halfak>	 Also, I'm just going to apply your proposed changes :D
[15:40:10] <halfak>	 Oh except for the good vs. high quality image. 
[15:40:16] * halfak thinks about that. 
[15:41:40] <wikibugs>	 06Revision-Scoring-As-A-Service, 10MediaWiki-extensions-ORES, 06Research-and-Data: Plot ORES extension adoption over time - https://phabricator.wikimedia.org/T156515#3009542 (10Halfak) I did some queries and this schema is obviously broken.  It's common to see a "prefUpdate" show up multiple times for the ex...
[15:42:36] <Amir1>	 halfak: hey, I need to go to a meeting but one other thing, I saw the deployment in beta was successful, I didn't check the details. Is it okay to go for prod now?
[15:42:44] <glorian_wd>	 halfak, yeah. It seems your revised criteria skip some important points
[15:43:46] <halfak>	 Amir1, can you confirm that the extension is happy in beta?  Otherwise, yes :D
[15:44:17] <Amir1>	 I'll check. halfak: So today is the day (feeling blessed by FSM)
[15:44:40] <halfak>	 \o/  FSM and his noodley goodness
[15:45:12] <Amir1>	 Ramen
[15:45:19] <halfak>	 :D
[15:45:40] <wikibugs>	 06Revision-Scoring-As-A-Service, 10MediaWiki-Recent-changes, 10MediaWiki-Watchlist, 10MediaWiki-extensions-ORES, and 4 others: Add class to diff and history links in changes lists for easier selecting in CSS/javascript - https://phabricator.wikimedia.org/T157178#3009571 (10thiemowmde) p:05Triage>03Low
[15:45:51] <halfak>	 glorian_wd, I don't see that much in your criteria.  But I do disagree on adding "appropriate ranks and qualifiers" for anything except showcase items. 
[15:46:18] <glorian_wd>	 oh why?
[15:46:26] <glorian_wd>	 halfak
[15:46:37] * halfak jumps to #wikidata 
[16:39:20] <wikibugs>	 (03CR) 10Thiemo Mättig (WMDE): [C: 031] "Code looks good, but it seems this is now missing a Depends-On tag?" [extensions/ORES] - 10https://gerrit.wikimedia.org/r/333497 (owner: 10Ladsgroup)
[16:40:50] <wikibugs>	 06Revision-Scoring-As-A-Service, 10Wikilabels: Deploy Romanian translations for Wiki labels - https://phabricator.wikimedia.org/T157580#3009706 (10Halfak)
[16:41:25] <wikibugs>	 06Revision-Scoring-As-A-Service, 10Wikilabels, 10rsaas-editquality: Deploy edit quality campaign for Romanian Wikipedia - https://phabricator.wikimedia.org/T156357#3009720 (10Halfak) Thanks!  Just created {T157580} so we can track the deployment of your translations.
[17:00:20] <wikibugs>	 (03PS5) 10Ladsgroup: Add javascript highlighting to Special:Contributions as well [extensions/ORES] - 10https://gerrit.wikimedia.org/r/333497
[17:01:23] <Amir1>	 halfak glorian_wd I'm back
[17:01:26] <Amir1>	 what's up
[17:01:40] <glorian_wd>	 you can chime in #wikidata
[17:01:41] <glorian_wd>	 :)
[17:02:06] <Amir1>	 It would be nice to have #wikidata-ai :D
[17:02:10] <glorian_wd>	 Amir1: we are talking about multiple properties in statement
[17:02:19] <glorian_wd>	 sorry, unique properties
[17:02:34] <halfak>	 lol
[17:02:41] <halfak>	 @ wikidata-ai
[17:02:56] <glorian_wd>	 Amir1: one day it will exist? :D
[17:03:16] <glorian_wd>	 halfak: *look at your comment on #wikidata*
[17:03:19] <glorian_wd>	 answer*
[17:03:21] <Amir1>	 Hope so
[17:04:26] <halfak>	 If only we could convince the other Wikimedia/WMDE Staffer's working on AI to come here... :/
[17:05:11] <glorian_wd>	 halfak: they may come if your proposal regarding ORES team goes through :)
[17:05:46] <halfak>	 Heh.  will probably just end up with more participation from the regulars. ;) 
[17:09:20] <Amir1>	 I saw the WMCS announcement today, nice :) gave me hope
[17:11:26] <halfak>	 WMCS?
[17:14:11] <Amir1>	 halfak: Wikimedia Cloud (service I think)
[17:14:22] <halfak>	 Oh yeah! :) 
[17:14:27] <halfak>	 Glad to see that's going through. 
[17:17:51] <awight>	 halfak: aww, looks like you're in a meeting.  I had some minor questions about the ores backend
[17:25:53] <awight>	 The biggest question is to understand why we're using HTTP requests in the api.py chunking method.  Can't we make direct calls to the scoring code?
[17:26:21] <halfak>	 awight, can you link to the lines?
[17:26:53] <awight>	 And a fun system-wide question: Mind if I encapsulate the ScoringRequest and ScoringResults, and tamper with the "inherits from dict" paradigm
[17:26:56] <awight>	 sure thing
[17:27:31] <awight>	 fyi https://github.com/wiki-ai/ores/compare/doc_notes
[17:28:24] <awight>	 halfak: This is the http decoupling site, https://github.com/wiki-ai/ores/blob/master/ores/api.py#L96
[17:28:46] <halfak>	 Oh!  That api.py!
[17:28:55] <halfak>	 That's intend to help clients hit our API efficiently. 
[17:28:55] <awight>	 It makes sense to decouple separate services using HTTP/REST, but I don't see the advantage to doing that inside of a single codebase
[17:29:04] <awight>	 oooh
[17:29:12] <awight>	 api.py is run by the client
[17:29:13] <awight>	 ?
[17:29:16] <halfak>	 Right.  
[17:29:42] <awight>	 ty.  I'm sure I'll have a hundred equally inane misunderstandings.
[17:29:58] <awight>	 Will comment in that file to help future paleogrammers
[17:30:47] <halfak>	 :D 
[17:40:54] <halfak>	 I'm not sure what you mean re. ScoringRequest/ScoringResults
[17:40:56] <halfak>	 awight, ^
[18:07:50] <awight>	 sorry, RL-jacking in progress
[18:08:17] <awight>	 re: the encapsulation, I noticed that ScoringSystem and ScoringContext inherict from dict
[18:08:33] <awight>	 Seems like I could twist that into a better structure
[18:09:04] <awight>	 e.g. a static member ScoringSystem.context_map, or better yet a second class responsible for maintaining that store
[18:09:20] <awight>	 and then we wouldn't have to pass context_name down into every subrouting call
[18:09:51] <awight>	 similar with rev_ids and model_names, that could be either ScoringSystem state variables, or better, a ScoringRequest encapsulation that gets passed as a single object.
[18:43:47] <awight>	 halfak|Lunch: ^
[19:05:35] <halfak>	 Hey awight. 
[19:06:12] <halfak>	 So, re. ScoringSystem, I was aiming to have something that took the exact inputs and produces the exact outputs that ORES needs (need to do a v3 version of the interface to show this off)
[19:06:13] <awight>	 o/
[19:06:23] <halfak>	 So that's why it takes a string for the score() method. 
[19:07:00] <halfak>	 That way, I could have the WSGI routes just be responsible for handling web stuff and backwards compatibility re. formats. 
[19:07:10] <halfak>	 I'm not loving this abstraction though. 
[19:07:33] <halfak>	 I wonder if you could make me a gist that mocks a demonstrated use of ScoringRequest. 
[19:07:43] <halfak>	 I'm not quite understanding what that would look like. 
[19:07:44] <awight>	 +1 I would certainly go slowly
[19:08:28] <halfak>	 Regarding the extension of dict -- yeah, I feel OK about that.  It hasn't bit us, but I'm not sure it has added that much beyond the nice convenience functions 
[19:08:42] <halfak>	 E.g. "if context in scoring_system: ..."
[19:08:50] <awight>	 ah, yeah that's cute :)
[19:08:56] <halfak>	 :)  
[19:09:15] <awight>	 But seems misplaced, cos the scoring system has no business containing context IMO
[19:09:16] <halfak>	 Can always just redefine __contains__
[19:09:35] <awight>	 yup or provide an explicit function context_exists
[19:09:49] <halfak>	 Oh interesting.  I'm not sure that I see what you're saying re not containing context
[19:09:53] <halfak>	 Oh wait... I see. 
[19:10:23] <halfak>	 ScoringSystem decides how to score (Celery, ProcessQueue, SingleThreaded, etc) *and* it maintains a set of contexts
[19:10:33] <halfak>	 It should do one or the other. 
[19:10:34] <awight>	 My next step is probably to create a class diagram where I tease apart some of the things that are bothering me
[19:10:43] <awight>	 yep, single responsibility FTW
[19:10:46] <halfak>	 That sounds great
[19:11:05] <awight>	 I think that fixing the internal function interfaces would make _score perfectly readable
[19:11:12] <awight>	 & then clean-up-able
[19:11:14] <halfak>	 :)  I'm really liking this conversation.  It's something I've wanted to talk through for a while. 
[19:11:21] <halfak>	 Oh!  I have some docs that will help. 
[19:11:22] * halfak digs
[19:11:46] <awight>	 :D definitely one of those dialogue things where > 1 person is required
[19:12:30] <halfak>	 https://phabricator.wikimedia.org/T139408
[19:13:04] <halfak>	 awight, +1  I did a lot of work to manage my single-person dialog on the last re-architecting. 
[19:13:44] <halfak>	 https://etherpad.wikimedia.org/p/ores_refactor
[19:13:48] <awight>	 Great, this task has the insights
[19:13:48] <halfak>	 That's a good reference
[19:13:51] <halfak>	 :D
[19:14:09] <halfak>	 You can see why I did things -- to understand and/or more effectively disagree :D
[19:14:21] <awight>	 yes that's a huge help
[19:15:13] <halfak>	 One more note is that I'm way overdue for v3 of the API output structure.  
[19:15:34] <halfak>	 v3 will output exactly what ScoringSystem outputs now without all the transformations. 
[19:15:41] <halfak>	 That makes some of my notes here make a little more sense. 
[19:16:15] <halfak>	 Oh wait..  I have a spec for this.  That's even better. 
[19:16:17] * halfak digs
[19:17:08] <halfak>	 https://etherpad.wikimedia.org/p/ores_response_structure
[19:17:38] <halfak>	 Starting on line 83 is what I want to do for v3. 
[19:18:04] <halfak>	 It switches the order of rev_id and model. 
[19:18:26] <halfak>	 So rev_id has models rather than models having rev_ids.  The output structure makes more sense then. 
[19:20:57] <awight>	 I have lots of ideas here, but there's always the temptation to force code to look like messes I'm familiar with.  So of course, push back...
[19:21:03] <awight>	 Yes that sounds like it makes sense.
[19:21:18] <awight>	 I was wondering, are scoring requests always the cross-product of rev_ids and models?
[19:22:34] <awight>	 (cartesian product), that all revisions are scored for all models in each request?
[19:26:37] <halfak>	 awight, yeah.  I can't imagine another use-case like that. 
[19:27:02] <halfak>	 Where we'd have some rev_ids scored with a subset of models. 
[19:27:17] <awight>	 ok good
[19:29:58] <wikibugs>	 (03CR) 10Gergő Tisza: [C: 04-1] "This still won't work with the first revision of a page. Coloring some affected edits but not all is "incremental" in a way that would bre" [extensions/ORES] - 10https://gerrit.wikimedia.org/r/333497 (owner: 10Ladsgroup)
[21:43:38] <wikibugs>	 06Revision-Scoring-As-A-Service, 10ORES: Investigate failed ORES deployment - https://phabricator.wikimedia.org/T157623#3011121 (10Halfak)
[21:43:45] <wikibugs>	 06Revision-Scoring-As-A-Service, 10ORES: Investigate failed ORES deployment - https://phabricator.wikimedia.org/T157623#3011134 (10Halfak) p:05Triage>03High
[21:50:29] <wikibugs>	 06Revision-Scoring-As-A-Service, 10ORES: Investigate failed ORES deployment - https://phabricator.wikimedia.org/T157623#3011164 (10Halfak) Here's the check that should have been run:   ``` venv="/srv/deployment/ores/venv" deploy_dir="/srv/deployment/ores/deploy" mkdir -p $venv virtualenv --python python3 --sys...
[23:25:34] <wikibugs>	 06Revision-Scoring-As-A-Service, 10Wikilabels: Deploy Romanian translations for Wiki labels - https://phabricator.wikimedia.org/T157580#3011484 (10Halfak) I just checked https://github.com/wiki-ai/wikilabels/tree/master/wikilabels/i18n and https://github.com/wiki-ai/wikilabels-wmflabs-deploy/tree/master/forms/...