[01:02:13] 06Revision-Scoring-As-A-Service, 10MediaWiki-extensions-ORES: ORES extension should Assume good faith page creator's revisions - https://phabricator.wikimedia.org/T137846#2570829 (10Iniquity) [01:05:35] 06Revision-Scoring-As-A-Service, 10MediaWiki-extensions-ORES: ORES extension should Assume good faith page creator's revisions - https://phabricator.wikimedia.org/T137846#2570836 (10Iniquity) We have the same problem in Russian Wikipedia. [09:44:08] 06Revision-Scoring-As-A-Service, 10MediaWiki-extensions-ORES: ORES extension should Assume good faith page creator's revisions - https://phabricator.wikimedia.org/T137846#2381134 (10Ladsgroup) @Iniquity. Hey, Can you explain more? [14:10:09] o/ [15:38:05] halfak: o/ [15:38:13] o/ Amir1 [15:39:14] I'm done with some wikidata-related work. I might have some time to work on ORES \o/ [15:39:18] if nothing happens :D [15:41:15] \o/ [15:41:29] Great. I'm just finishing up some emails re. getting us new hardware. [15:43:06] Then I'll start on our agenda [16:34:40] 06Revision-Scoring-As-A-Service, 10Beta-Cluster-Infrastructure, 10MediaWiki-extensions-ORES: Switch beta to use the proper wiki models for scoring (rather than "testwiki") - https://phabricator.wikimedia.org/T143567#2572046 (10Halfak) [16:43:24] 06Revision-Scoring-As-A-Service, 10ChangeProp, 10ORES: Add median, 75% and 95% response time to ORES dashboard - https://phabricator.wikimedia.org/T143568#2572090 (10Halfak) [16:51:56] 10Revision-Scoring-As-A-Service-Backlog, 10MediaWiki-extensions-ORES: Add description when a user reviews an edit - https://phabricator.wikimedia.org/T136903#2572153 (10Halfak) a:05Ladsgroup>03None [16:53:28] 06Revision-Scoring-As-A-Service, 10ChangeProp, 10ORES: Add median, 75% and 95% response time to ORES dashboard - https://phabricator.wikimedia.org/T143568#2572156 (10Halfak) a:03Halfak [16:53:44] 06Revision-Scoring-As-A-Service, 10Beta-Cluster-Infrastructure, 10MediaWiki-extensions-ORES: Switch beta to use the proper wiki models for scoring (rather than "testwiki") - https://phabricator.wikimedia.org/T143567#2572157 (10Halfak) p:05Triage>03Normal [16:53:57] 06Revision-Scoring-As-A-Service, 10ChangeProp, 10ORES: Add median, 75% and 95% response time to ORES dashboard - https://phabricator.wikimedia.org/T143568#2572090 (10Halfak) p:05Triage>03Normal [17:04:56] afk doing the dishes, I'll be back working on deploying ores in en.wp [17:05:40] and https://phabricator.wikimedia.org/T138255 [17:06:26] kk thanks Amir1 [17:29:33] Back! [17:30:03] o/ RoanKattouw. [17:30:04] Around? [17:30:14] Hey halfak [17:30:23] :D! [17:30:25] I'm in a meeting for another hour, sorry [17:30:35] So I wanted to introduce you to Amir1 (the main dev of the ORES extension) [17:30:45] Oh! OK I'll wait :) [17:41:11] 06Revision-Scoring-As-A-Service, 10ChangeProp, 10ORES: Add median, 75% and 95% response time to ORES dashboard - https://phabricator.wikimedia.org/T143568#2572377 (10Halfak) BAM: https://grafana-admin.wikimedia.org/dashboard/db/ores?panelId=15&fullscreen [17:43:32] 06Revision-Scoring-As-A-Service, 10ChangeProp, 10ORES: Add median, 75% and 95% response time to ORES dashboard - https://phabricator.wikimedia.org/T143568#2572090 (10Catrope) >>! In T143568#2572377, @Halfak wrote: > BAM: https://grafana-admin.wikimedia.org/dashboard/db/ores?panelId=15&fullscreen Looks cool,... [17:44:01] 06Revision-Scoring-As-A-Service, 10rsaas-editquality: Update editquality models with new version of revscoring - https://phabricator.wikimedia.org/T143125#2572400 (10Halfak) https://github.com/wiki-ai/editquality/pull/43 [17:47:05] Amir1, I'm working on the weekly update [17:47:18] Do you know if there are any resolved tasks that I should be including? [17:47:52] none [17:47:55] :) [17:48:02] kk [17:48:07] halfak: do you want to wait a little to include enwiki too? [17:48:36] Na [17:48:49] We should write up a big announcement tomorrow when we find that nothing went wrong ;) [17:50:30] halfak: +1 [17:53:59] halfak: Should we do the announcement in VP/T tonight or do it at the same time tomorrow? [17:54:13] Let's aim for tomorrow so we have a work-day to collect feedback [17:54:27] kk [17:54:30] enwiki mostly wakes up at 1400 UTC [18:00:56] Amir1, please review: https://etherpad.wikimedia.org/p/ores_weekly_update [18:02:16] halfak: I made a note there [18:09:12] Thanks Amir1 [18:09:22] Did I get all the notes (1?) addressed? [18:09:38] halfak: yes [18:10:23] 06Revision-Scoring-As-A-Service, 10ChangeProp, 10ORES: Add median, 75% and 95% response time to ORES dashboard - https://phabricator.wikimedia.org/T143568#2572643 (10Halfak) Weird. It looks like the whole number averages only show up in fullscreen mode. Otherwise the data is certainly not whole numbers and... [18:10:27] Amir1, cool [18:10:30] Shall I post then? [18:11:27] Yes, please [18:11:28] Woops. Just clicked send. Too late :S [18:11:31] Oh good [18:12:43] OK Running away for Lunch [18:22:31] 06Revision-Scoring-As-A-Service, 10ChangeProp, 10ORES: Add median, 75% and 95% response time to ORES dashboard - https://phabricator.wikimedia.org/T143568#2572778 (10Ladsgroup) 05Open>03Resolved [18:22:33] 06Revision-Scoring-As-A-Service, 06Research-and-Data: Present on user-feedback stories at Research Showcase - https://phabricator.wikimedia.org/T143275#2572779 (10Ladsgroup) 05Open>03Resolved [18:22:35] 06Revision-Scoring-As-A-Service, 10rsaas-editquality: Update editquality models with new version of revscoring - https://phabricator.wikimedia.org/T143125#2572780 (10Ladsgroup) 05Open>03Resolved [18:22:37] 06Revision-Scoring-As-A-Service, 13Patch-For-Review, 15User-Ladsgroup: Increase celery workers to 40 per scb node - https://phabricator.wikimedia.org/T143105#2572781 (10Ladsgroup) 05Open>03Resolved [18:22:41] 06Revision-Scoring-As-A-Service, 10ORES, 13Patch-For-Review, 15User-Ladsgroup: Add uwsgi-related metrics to grafana - https://phabricator.wikimedia.org/T143081#2572783 (10Ladsgroup) 05Open>03Resolved [18:22:43] 06Revision-Scoring-As-A-Service, 10rsaas-editquality, 15User-Ladsgroup: Include specific user groups in the trwiki edit quality model - https://phabricator.wikimedia.org/T140474#2572787 (10Ladsgroup) 05Open>03Resolved [18:22:45] 06Revision-Scoring-As-A-Service, 10Beta-Cluster-Infrastructure, 10MediaWiki-extensions-ORES, 10ORES, and 2 others: Config beta ORES extension to use the beta ORES service - https://phabricator.wikimedia.org/T141825#2572786 (10Ladsgroup) [18:22:49] 06Revision-Scoring-As-A-Service, 10Beta-Cluster-Infrastructure, 10MediaWiki-extensions-ORES, 10ORES, and 2 others: [Spike] Should we make a model for ores in beta? - https://phabricator.wikimedia.org/T141980#2572784 (10Ladsgroup) 05Open>03Resolved a:03Ladsgroup [18:31:18] halfak|Lunch, Amir1: OK I'm here now [18:31:38] RoanKattouw: hey, Aaron is afk for lunch now [18:31:52] but I guess that's okay [18:32:31] RoanKattouw: I wanted to talk about the ORES extension [18:32:47] Awesome [18:32:55] Yes I wanted to talk to you guys about that too [18:32:57] But you first :) [18:33:37] Okay, the extension works like this: it adds a table which has a foreign key to revision_id [18:33:57] it can be multiple rows to one revision [18:34:14] but how we want to populate that is my biggest problem [18:34:23] we have two of populating [18:34:39] 1- after it's deployed, every edit triggers a job to add the score [18:35:04] 2- we have a maintenance script to populate for the latest 5K edits [18:35:17] (it has some ways of controlling) [18:35:37] like it works only in main ns for wikidata and also only non-bot edits are included [18:36:09] RoanKattouw: one suggestion. We just deployed it in en.wp. Enable it in beta features [18:36:18] and then go to user contribs of someone [18:36:40] OK, looking [18:36:49] https://en.wikipedia.org/wiki/Special:Contributions/179.34.25.227 [18:36:51] e.g. this [18:37:58] Right, that's highlighted red [18:38:09] But I suppose if I look at old contribs, I won't see highlights [18:38:20] exactly [18:38:42] I had two ways to do that [18:38:44] So, do we care about backfilling ORES data for old edits? [18:38:45] We could, but there's hundreds of millions of them on enwiki [18:39:06] I don't think populating all of them would be a good idea [18:39:11] What did you do on other wikis where ORES is already enabled? nlwiki is pretty big too, it's no enwiki but it's not small [18:39:15] but it should be possible on demand [18:39:20] OK, I see [18:39:43] Oh, and re #2 in your list, you backfill only the last 5K edits, that makes sense [18:39:45] wikidata, fawiki, ruwiki, plwiki, trwiki, [18:39:45] ptwiki [18:40:01] we do it once we deployed [18:40:12] but for much older ones [18:40:18] I have two options in mind [18:40:27] So all of those wikis are backfilled to T_enabled - 5000 edits, but not back to the beginning of time? [18:40:28] 1- if someone checks out a user contribs [18:40:44] we trigger a job to check and add [18:40:53] that's correct [18:41:15] 2- we run a js to get the data in real time [18:41:45] when someone checks out a user contribs [18:41:53] Hmm, how about something that's kind of a combination of #1 and #2 [18:42:24] Or, wait, no, sorry, that doesn't make sense [18:42:49] I think #2 would be nice because then you can show the user the result without them having to come back later [18:43:12] exactly [18:43:22] it would be much better if the js also stores data in the db after it showed the results [18:43:29] Alternatively, if you did #1, you could implement it as "every time a piece of code asks for an ORES score and it's missing, return null but also queue a job to compute the score" [18:43:30] maybe someone is being checked a lot [18:43:34] And yes, the JS should store the score [18:44:05] the problem with that is the hook for user contribs [18:44:40] https://github.com/wikimedia/mediawiki-extensions-ORES/blob/master/includes/Hooks.php#L244 [18:44:40] RoanKattouw: this is the hook ^ [18:44:57] we dodge the issue by using left join [18:45:27] maybe we can do it in another hook? [18:45:28] Right, so the score is NULL if it's not available [18:45:40] https://github.com/wikimedia/mediawiki-extensions-ORES/blob/master/includes/Hooks.php#L289 [18:45:47] Like this ^ [18:46:28] Hmm, you can do a lot of this in JS, all you need is for the HTML of a row to contain some sort of flag saying that row doesn't have a score [18:46:47] There's a separate revscoring gadget that shows the exact score on hover, right? [18:46:53] yeah [18:47:00] but that hits the service [18:47:05] Right [18:47:17] I wonder if there would be a way to put the score into the HTML directly [18:47:26] As data-ores-score="0.74" or something [18:47:49] maybe e can put it in resource loader [18:47:50] It looks like onSpecialContributionsFormatRowFlags only lets you do flags, I don't know the ChangesList / SpecialContributions hooks well enough to know if there are other hooks that might help you do something like that [18:47:54] like what wikidata is doin [18:48:01] https://www.wikidata.org/wiki/Q26252561 [18:48:11] (view source) [18:48:11] What does Wikidata put in RL? [18:48:24] values of all items [18:48:34] Oh, mw.config.get( 'wbEntity' ) is all the data [18:48:43] yup [18:48:44] Yeah that's a bit of a backchannel but I suppose that works [18:48:51] exactly [18:49:20] You need to be able to get to the OutputPage object for that, but I guess you have a RequestContext so you can [18:49:38] do you recommend doing it? [18:49:49] Yeah you could export a data blob there that maps an existing attribute of the RC row (rc_id or something) to the ORES information [18:50:06] (re. user contribs hooks, we mangled it a lot recently, added several ones too) [18:50:14] I mean, it would be *nicer* to be able to add data-ores-* attributes directly to the RC rows, but I don't know if that's easily doable with the hooks we have [18:50:15] in the core [18:50:46] If data attributes are doable that would be my preference, but otherwise Wikidata's config blob approach is also reasonable [18:51:51] we already change rc attributes [18:51:56] Oh? Where? [18:52:14] Oh you add class=damaging to the
  • , nice [18:52:44] https://github.com/wikimedia/mediawiki-extensions-ORES/blob/master/includes/Hooks.php#L133 [18:52:59] ? Wrong line? [18:53:13] That hook modifies the DB query [18:53:46] I do see you adding class=damaging from the onContributionsLineEnding hook, but that seems to only let you add classes, not data attrbiutes [18:53:50] we later use it this way: https://github.com/wikimedia/mediawiki-extensions-ORES/blob/master/includes/Hooks.php#L308 [18:53:54] In any case you could add class=noscore there or something [18:54:19] I was wondering rc attributes are being flushed out to RL [18:54:25] (Also I recommend prefixing CSS classes, i.e. something like mw-ores-damaging instead of just damaging) [18:54:30] No, I don't think so [18:54:40] that was my idea [18:54:49] I thought it does that [18:55:03] Okay, I get the idea and I will make phab cards to do it [18:55:08] Thanks [18:55:11] I have two more things: [18:55:23] Please link me to them when you've made them [18:55:30] sure [18:55:34] 1- It does the same for all changes list [18:55:47] like recent changes, watchlist, etc. [18:56:22] for wikis that have RC patrolling enabled, when someone patrols an edit, it doesn't show the "r" flag [18:56:37] but for wikis like enwiki, it stays there forever [18:57:08] The best solution would be to convince communities to enable RC patrolling [18:57:20] legoktm and halfak|Lunch are really want to do that for enwiki [18:57:26] Yes, we want to do taht too [18:57:31] Krinkle asked us to work on that [18:57:41] legoktm actually wants to make it default in all wikimedia projects [18:57:47] Yup, that makes sense [18:58:08] https://www.mediawiki.org/wiki/User:Krinkle/Patrolling#Phase_One [18:58:17] We should talk to quiddity and Trizek about actually making this happen [18:58:44] I was thinking if that solution didn't work out, Should we do other things or tell them "If you want ORES work properly here enable RC patrolling" [18:58:45] yikes scrollback. which/what? [18:58:53] quiddity: I'll TLDR for you [18:59:03] Amir1: I think enabling rc patrol makes a nice carrot. [18:59:12] or rather ORES being the carrot. [18:59:23] Don't try to work around it. Refuse to. [18:59:24] yeah, ORES as the carrot [18:59:36] quiddity: enwiki does not enable RC patrol. ORES extension has just been enabled on enwiki as a beta feature. It has a feature whereby the scary red "this needs to be looked at" thing goes away once the edit is patrolled. Which, on enwiki, is never, because there is no RC patorl [18:59:48] Krinkle: Okay, sounds like a plan [18:59:55] So we should renew our efforts to get enwiki (and possibly ALL wikis) to enable RC patrol, and Krinkle suggests using this as a carrot [19:00:09] [19:00:34] One last thing: the extension doesn't touch api.php [19:00:58] mostly because if someone score for a revision they should hit the service [19:01:04] It was enabled by default originally (and still is in stock). Then a few admins on enwiki in 2006 didn't like the the styling of the red exclamation marks. And eventhough nobody else saw them (since patrol was an admin-only user right by default and no patrol/rollbacker group existed), the community at the time voted to disable it. [19:01:06] API-wise [19:01:10] Which in 2006 meant flipping the wmf config default. [19:01:37] i.e., say that without enabling RC patrol (even if with hidden exclamation marks or whatever tweaks to make the people who didn't like it in 2006 happy), they'll never be able to get rid of the red markers on already-reviewed edits because the software has no concept of "already reviewed" [19:02:49] Are these red background marks behind a user right? [19:02:51] E.g. patrolmarks? [19:02:54] Or visible to all users? [19:03:03] nod. Is this going to cause any immediate problems, for everyone? Or only for users with the ORES beta feature enabled? [19:03:07] It should not be visible to anons/newbies. [19:03:09] quiddity: Beta feature only [19:03:18] Krinkle: Not sure, it's behind a beta feature currently [19:03:44] ok. I'll stop panicking and go back to my other tasks then. ty :) [19:03:55] Also, "problem" is a strong term but it'll probably annoy people eventually [19:04:02] quiddity: Sure, sorry to rope you into this with such immediacy [19:04:22] np! [19:04:40] Also, that scoring gadget is very pretty. So many colors! [19:04:47] Krinkle:why the red mark should not be visible for everyone ? [19:04:47] s/gadget/userscript [19:05:20] :D [19:05:32] 06Revision-Scoring-As-A-Service, 10rsaas-editquality, 15User-Ladsgroup: Include specific user groups in the trwiki edit quality model - https://phabricator.wikimedia.org/T140474#2572931 (10Superyetkin) 05Resolved>03Open We still see some edits made by users with "autoreview" rights being flagged as harmf... [19:06:09] https://phabricator.wikimedia.org/T122689#1939440 [19:07:18] RoanKattouw: I have an API schema for the extension. Do you think we should have that given that it's a beta feature (and only people who enabled the beta feature should see it?) and what do you think of the API schema I wrote there [19:07:52] Amir1: The [mark as patrol] link is only visible to people with the patrol user right. The red exclamataion marks indicating that an edit is not patrolled is likewise only visible to authorised users. They would only be a distraction to other users, potentially with negative effects since they won't be able to do anything about it, it's not a very well [19:07:52] documented/advertised feature, and without further discussion, status quo is that showing them without reason may upset users or trigger a more prompt response from new users (both goodfaith and not). [19:08:21] So whatever the case, ORES should not leak this in the user interface. It's behind an isAllowed() check in the special page. [19:10:30] Krinkle: so as a beta feature they already know what they are dealing with, right? [19:10:58] (a user might be not a patroller but enable the beta feature) [19:12:21] if you still think that it should have the isAllowed() part, I think it's easy to add [19:13:26] 06Revision-Scoring-As-A-Service, 10rsaas-editquality, 15User-Ladsgroup: Include specific user groups in the trwiki edit quality model - https://phabricator.wikimedia.org/T140474#2572959 (10Ladsgroup) It's fixed but it's not deployed yet. We will deploy it possible this week and also bear in mind we are impro... [19:19:43] Okay, I'm afk for now [19:19:46] During the beta feature phase I think it's fine [19:19:57] not afk [19:20:04] But some thought should be given to what's going to happen post-beta [19:20:20] RoanKattouw: the API or the "r" flag? [19:20:24] If this eventually rolls out to all users, do *all* users see the red "r"s, or only users with the patrol right? [19:20:28] The "r" [19:20:31] Sorry, looking at the API now [19:20:39] (I was to step out for a minute, sorry for the delay) [19:21:02] nah, that's fine, just let me know if possible [19:21:15] o/ [19:21:18] Reading scrollback [19:21:29] okay, for "r". If it goes post-beta it'll be for everyone [19:21:48] RoanKattouw, I don't see this ever going post beta without substantial interaction design work [19:21:54] Amir1: Yes I think your API thing looks good. I agree this data should be exposed in the API, and the filter should be too [19:21:54] Not just in the revisions API but also in the recentchanges API [19:22:01] halfak: Makes sense [19:22:25] I guess the question of how/whether this information is presented to users who can't fix it can be part of that [19:22:58] We should go out of beta in three months, it seems there is six months limit for beta features [19:23:21] they should be either disabled or be enabled for everyone [19:23:57] (Or this is not enforced?) [19:23:59] halfak: Once you finish reading scrollback: perhaps you/somebody could make the granularity of the numbers at https://grafana-admin.wikimedia.org/dashboard/db/ores?panelId=15&fullscreen greater than 1 second? Right now it only shows whole seconds, which is not very helpful at this scale. It should probably have ms or at least 1/100 of a second resolution [19:24:25] RoanKattouw, that's grafana bug [19:24:49] Remove the fullscreen and scroll to the bottom [19:24:59] FWIW, these are response timings for when an edit is not cached. [19:25:21] And a worker job has not been started [19:25:21] Still shows whole numbers for me when I do that [19:25:34] So, most actual usage of ORES will be *way faster* [19:25:37] Hmm.. Not for me [19:25:40] Yeah, exactly [19:27:00] RoanKattouw: it's fixed [19:27:00] 1 decimal [19:27:05] how many do you think is useful [19:27:27] 2 decimal [19:27:45] halfak: there is "Decimals" in legends tab [19:27:50] Done [19:27:58] Amir1, funny, but it still worked for me in non-fullscreen [19:28:17] grafana is great but really poor ux for adminship [19:28:48] I need to really go through a lot to learn something about it [19:29:22] halfak: did you delete the uwsgi avg response time? [19:29:35] Amir1, yeah. It's not a useful measure [19:29:57] Arithmetic mean of a log scaled distribution == fragile nonsense [19:30:34] Okay, I really like the concept of "overall average response time" [19:30:57] but scientifically you're right that it's useless [19:34:44] RoanKattouw: one question, Do you think the api for the extension should accessible to people who enabled to beta feature or every one? [19:34:59] Amir1, IMO, everyone [19:35:12] Other extensions will want to make use of it. [19:35:36] Also, bots, 3rd party tools, etc. [19:35:36] The extension can't use it unless we introduce new hooks [19:35:48] but gadgets, etc. yess [19:41:32] Everyone [19:41:39] okay [19:41:54] Thanks. I make the phab cards for them soon [19:41:54] (I'm about to head out to lunch in a few minutes) [19:42:00] and subscribe you too [19:42:04] Thanks [19:42:09] I'm going for dinner [19:42:16] have fun every body [19:42:17] o/ [19:47:23] 06Revision-Scoring-As-A-Service, 10Beta-Cluster-Infrastructure, 10MediaWiki-extensions-ORES: Switch beta to use the proper wiki models for scoring (rather than "testwiki") - https://phabricator.wikimedia.org/T143567#2573058 (10Halfak) So, in order to do this, we'll need to re-write the API locations in the c... [19:51:25] Hey all [19:51:53] o/ bmansurov [19:52:06] i'm trying to get wikilabels server working locally, and when the mediawiki extension tries to open http://127.0.0.1:8080/auth/whoami/ I get a forbidden text. Anyone knows how to fix it? [19:52:48] That's normal if you haven't yet done the oauth handshake [19:52:52] 403 forbidden [19:53:03] halfak: how do I do a handshake? /auth/initiate? [19:53:19] Yup :) [19:54:08] halfak: thanks, this time I'm getting another error message: Unexpect request token key [19:54:22] do I need to add some token to the config file? [19:55:24] bmansurov, should work out of the box. I'm looking now [19:57:27] bmansurov, it's important that you get the 99-oauth.yaml file in the config directory [19:57:34] Do you have that? [19:57:37] halfak: yes [19:57:50] halfak: i think i must use localhost and not 127.0.0.1 right? [19:57:58] Oh! Maybe. [19:58:02] I go to "localhost:8080/auth/initiate" [19:58:06] And the handshake works fine [19:58:20] halfak: ok, i see a blank page now, no errors ;) [19:59:12] halfak: another question. I populated the database with test data, but I dont' see any campaigns in the front end. [19:59:25] halfak: anything I should do? [20:00:29] bmansurov, as for the blank page, just try the "whoami" again and it should work [20:00:36] You should see campaigns, yes./ [20:00:55] You don't see campaigns listed at "http://localhost:8080/gadget/"? [20:01:28] halfak: i do see them at /gadget [20:01:41] halfak: something is wrong with my extension then [20:01:42] thanks [20:03:49] Amir1: halfak: Unless we change this as a general decision, imho it *must* not be shown to all users post-beta. This is currently showing information we consider semi-private. It can be constructed with certain workarounds through APIs and feeds, but is generally not meant for general public viewing. This was a design decision in core, it was hidden on [20:03:49] purpose. ORES should not bypass that. [20:03:57] It's low-prio for the beta, but imho a blocker for post-beta. [20:04:16] It can be decided to leave as-is, but should not be taken for granted and is imho not up to ORES maintainers. [20:05:38] no prob bmansurov [20:06:04] Krinkle, I'm confused what is being shown by ORES that is private [20:06:44] (it=easily querying a list of edits via a feature within the on-wiki default interface that are damaging, and whether they are patrolled or not) [20:06:56] That shuld be of no use to non-patrollers anyway [20:07:55] I'm not saying it should be admin-only, it should be patrol-only. But on wikis that have little no no patrolling activity, those won't have a rollback/patroller/reviewer group yet, so it would be effectively admin-only. [20:08:01] BUt that's a separate issue :) [20:10:24] What should be patrol-only? [20:10:49] Krinkle, ^ [20:11:09] halfak: Seeing the red background for damaging edits and showing only those. [20:11:17] Why is that a problem? [20:11:19] (and hiding hte patrolled ones) [20:11:30] "patrolled" and likely-non-damaging [20:11:44] It's hard for me to defend it as a problem. My main point is that it's status quo. And it's non-trivial to change. There could be good reasons. [20:12:05] We intentionally do not show patrolled-status in the interface for non-patrollers. [20:12:23] https://en.wikipedia.org/w/api.php?action=query&generator=recentchanges&grcshow=!patrolled&prop=info [20:12:27] It's freely available [20:12:29] And we intentionally don't allow the hidepatrolled=1 filter for users without the patrol right. [20:12:51] 'You need patrol or patrolmarks permission to request the patrolled flag', [20:12:51] 'permissiondenied' [20:13:03] No, it's not. [20:13:13] Oh... Interesting [20:13:16] That's... weird [20:13:32] What's the "intentional" reasoning for people to not be able to look up that data? [20:13:45] It can be reconstructed using a differnet API, and also from special-logs or RCFeed. [20:13:55] But that's fairly obscure. [20:14:00] We don't want to make it too easy. [20:14:14] Krinkle, why? [20:14:23] PM [20:28:58] I'm going to delete a bunch of old branches from revscoring. [20:29:01] So, spam is coming [20:29:39] Oh nevermind. there weren't that many. [20:31:05] I'm back [20:31:25] halfak: I merged your config change on gerrit [20:31:51] I was semi-afk during the dinner, happily Amir didn't throw my lap top out of the window :D [20:31:57] Saw that. I think we're ready for that deploy. [20:32:01] Sorry Amir! [20:32:27] No, I was working with the lap top before the gerrit change [20:32:34] don't worry [20:32:36] Amir1, I think I'm convinced that we should hide the patrolled status from people who don't have the right. [20:32:57] hmm [20:33:05] Do you think it'll be complex to have that alternative flow in the extension code -- to check the current user's rights and run a different query? [20:33:13] isn't there precisely a right to view them? [20:33:32] Platonides, yes. [20:33:35] https://github.com/wikimedia/mediawiki/blob/master/includes/api/ApiQueryRecentChanges.php#L201-L209 [20:33:36] That's what we've been discussing [20:33:38] https://github.com/wikimedia/mediawiki/blob/master/includes/specials/SpecialRecentchanges.php#L750-L752 [20:33:39] I was told that it's more like not to frighten people but if there are other reasons please tell me in private chat [20:33:58] Amir1, nothing fancy other than some historic reason and we probably shouldn't step on toes [20:33:59] halfak: nah, it's fairly easy [20:34:05] But this isn't very high importance. [20:34:24] Since we don't plan to deploy the ORES review tool by default to everyone [20:34:25] I can even make the patch right now [20:34:28] Great [20:34:31] Thanks Amir1 :) [20:34:52] * halfak focuses back on Abstract Feature Vectors [20:35:33] halfak: one thing, we should be. There is a rule, Beta features should either be disabled completely or rolled out to everyone after six month (except with special permission like visual editor) [20:35:55] So we have three months to go post-beta or our features would be disabled completely [20:38:19] Amir1, well, I imagine we can appeal given the experimental characteristics of the ORES review tool. [20:38:31] But either way, the Collab team is looking to take over where we left off. [20:38:50] And if the review tool gets disabled completely, then our users will help us with what we need. :) [20:39:27] okay, but we should keep this deadline in mind [20:39:33] let me get the exact date [20:40:48] halfak: https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L12718 [20:40:51] 12-12-2016 [20:41:14] Who enforces this? [20:42:24] IDK [20:42:34] possibly James and/or Greg [20:43:11] Maybe we can switch enabling ORES highlighting to a preference and the turn the extension on by default [20:43:29] I imagine that would be good for any API work we do. [20:43:38] Krinkle, ^ does that make you feel nervous? [20:43:58] I imagine that, we'd disable highlighting by default [20:44:04] If we get to that point. [20:44:15] We can enable it by default for those who have proper rights (patrol/admin) [20:44:41] Amir1, maybe. I'm not sure I'd want highlighting turned on by default for anyone. It seems like this should be opt-in. [20:45:31] * halfak works backwards from his theoretical example: https://gist.github.com/halfak/4b5e856902b5237d88ea49a80c1fb378 [20:45:40] definitely, that will be in preferences [20:45:57] As long as the ORES highlight takes into account $user->useRCPatrol() when evaluating $rcObj->rc_patrolled I'm fine. The rest is a product decision. [20:46:11] lol @ product decision ;) [20:46:22] I agree from a user perspective, I'd probably not want it shown by default, but ::lips-sealed:: [20:46:24] * halfak has a set of hats stacked to the ceiling [20:46:28] but the default should be enabled for those who have rights [20:46:43] and we don't even show the preference for who doesn't [20:46:47] We have preferences for all RC and watchlist filters [20:47:00] So people can change and do "Hide bots" or "Show bots" and that is sticky. [20:47:10] Whatever we do, that should probably apply to ORES as well. [20:47:25] E.g. "Show ORES scores" [20:47:33] We already have a "Hide patrolled changes" [20:47:37] So that's more or less redundant [20:47:49] Krinkle: it's a little bit different I guess, We do add a filter called "Hide good edits" [20:48:02] "Hide/Show probably not damaging changes" as well. [20:48:02] Krinkle, +1. We have a setting in there for ORES' sensitivity [20:48:06] but the matter would be should we have the highlighting or not [20:48:07] Yeah [20:48:20] So there's two filters (show ORES scores, hide probably good edits). [20:48:31] Yeah [20:48:36] "filters" [20:49:20] I guess ORES coudl also consider patrolled-damaging edits as "good edits" from that perspective, if the user has the patrol right. [20:49:34] Though it may be confusing, with the separate 'Hide/Show patrolled edits" filter existing [20:49:38] We already do [20:49:46] Yes, which is what prompted the conversation. [20:49:47] :) [20:49:58] yeah :D [20:52:07] Krinkle: one question. When a wiki does not have RC patrolling, we show the flag to every edit that passes a certain threshold, we are not leaking any data. Can we enabled it for everyone? [20:53:30] As long as there is a sticky way to Hide/Show those scores, sure. And I imagine product/community/UX may not want it shown by default. Per halfak also. [20:53:43] But no blockin problem from my pov. [20:55:44] okay, thanks [21:04:01] 10Revision-Scoring-As-A-Service-Backlog, 10MediaWiki-extensions-ORES: Inject ores scores to rc-data - https://phabricator.wikimedia.org/T143611#2573377 (10Ladsgroup) [21:06:49] 10Revision-Scoring-As-A-Service-Backlog, 10MediaWiki-extensions-ORES: Request scores when someone checks out edits that not stored in ores_classification - https://phabricator.wikimedia.org/T143612#2573392 (10Ladsgroup) [21:07:43] 10Revision-Scoring-As-A-Service-Backlog, 10MediaWiki-extensions-ORES: Inject ores scores to rc-data - https://phabricator.wikimedia.org/T143611#2573377 (10Ladsgroup) [21:07:46] 10Revision-Scoring-As-A-Service-Backlog, 10MediaWiki-extensions-ORES: Request scores when someone checks out edits that not stored in ores_classification - https://phabricator.wikimedia.org/T143612#2573408 (10Ladsgroup) [21:09:29] 10Revision-Scoring-As-A-Service-Backlog, 10MediaWiki-extensions-ORES: Introduce ORES rvprop - https://phabricator.wikimedia.org/T143614#2573432 (10Ladsgroup) [21:10:35] 10Revision-Scoring-As-A-Service-Backlog, 10MediaWiki-extensions-ORES: Introduce rcshow=oresreview and similar ones - https://phabricator.wikimedia.org/T143616#2573460 (10Ladsgroup) [21:11:23] 10Revision-Scoring-As-A-Service-Backlog, 10MediaWiki-extensions-ORES: Expose ores_model data in API using meta=ores - https://phabricator.wikimedia.org/T143617#2573475 (10Ladsgroup) [21:12:09] 06Revision-Scoring-As-A-Service, 10MediaWiki-API, 10MediaWiki-extensions-ORES, 15User-Ladsgroup: api.php integration with ORES - https://phabricator.wikimedia.org/T122689#2573490 (10Ladsgroup) a:03Ladsgroup [21:13:09] 06Revision-Scoring-As-A-Service, 10MediaWiki-API, 10MediaWiki-extensions-ORES, 15User-Ladsgroup: api.php integration with ORES - https://phabricator.wikimedia.org/T122689#2573498 (10Ladsgroup) I made related phab cards to implement such schema, the schema got approved by @Catrope, I will keep iterating on... [21:15:17] Thanks Amir1, I'm in a meeting (again) but I'll read those tasks later [21:15:49] I have more ORES-related stuff to talk about with you and halfak but it may be better to schedule a time for that, because I keep being in meetings (or eating lunch) [21:16:08] RoanKattouw: These are just summary of our discussion. It will keep you informed about the progress :) [21:16:14] Looking forward to it! [21:22:33] 06Revision-Scoring-As-A-Service, 10Beta-Cluster-Infrastructure, 10MediaWiki-extensions-ORES, 15User-Ladsgroup: Switch beta to use the proper wiki models for scoring (rather than "testwiki") - https://phabricator.wikimedia.org/T143567#2573553 (10Ladsgroup) a:03Ladsgroup [21:23:05] 06Revision-Scoring-As-A-Service, 10Beta-Cluster-Infrastructure, 10MediaWiki-extensions-ORES, 15User-Ladsgroup: Switch beta to use the proper wiki models for scoring (rather than "testwiki") - https://phabricator.wikimedia.org/T143567#2573555 (10Ladsgroup) I'm already regretting this but I do it, it needs t... [21:24:03] I need to sleep [21:24:12] o/ [21:26:51] o/ [22:39:35] 10Revision-Scoring-As-A-Service-Backlog, 10MediaWiki-extensions-ORES: Request scores when someone checks out edits that are not stored in ores_classification - https://phabricator.wikimedia.org/T143612#2573899 (10Catrope) [23:04:19] I just pushed some changes. I figured out hashing. Now I'm working on selectors (like Tfidf) [23:04:43] It looks like I might have to bend over backwards for this one or just have it implemented ourselves (which wouldn't be too crazy) [23:15:33] Alright, I'm declaring victory! o/