[23:15:48] bd808: around? I want to run something by you [23:15:59] o/ [23:16:39] So, parsoid has a linter that can detect different types of invalid/improper wikitext [23:17:16] We need a way to output a list of pages with issues to users [23:17:36] (And sorted by type of issue, etc.) [23:17:41] and not magic categories? [23:17:52] Well, parsoid can't add categories [23:18:16] ah. right [23:18:17] (I mean, theoretically we could, but not in the current parsing pipeline) [23:18:42] so you want to use logstash? [23:18:55] Currently the parsoid implementation uses a log message on a specific topic for warnings [23:19:06] heh, well, I was thinking about it :P [23:19:12] something like ApiFeatureUsage [23:19:22] *nod* [23:19:41] the trick would be removing things [23:20:01] deletes from elasticsearch aren't my favorite thing [23:20:32] ApiFeatureUsage are just counts and they roll off day by day [23:20:59] hmm yeah... [23:21:18] But building another pipeline like ApiFeatureUsage generally isn't too hard if you can figure out the count thing [23:21:50] or we could build some different pipeline using the log stream [23:21:55] my other option was to have a local db table, and have parsoid send an API request to MW and maintain the list that way. And we reparse after every edit, so we could clear that way [23:22:32] could you send an api request to add to a category (or remove)? [23:22:55] just to make it slightly more general [23:23:08] * bd808 is still learning api goodness [23:23:42] ehhh...during the PHP parse we could we need to make a request to parsoid, then see if it has any warnings, and then add those categories, and then save the page [23:24:29] yeah that's not a sweet workflow [23:25:19] the special db table might be your best bet then I guess [23:25:56] logstash -> elasticsearch would *almost* work [23:26:19] but the deletes would be some new thing we would have to invent [23:26:47] a special service of some kind would be needed for that [23:26:57] right... [23:29:17] ok, I'll try doing the db table [23:29:25] thanks :) [23:29:45] yw. have fun in Seattle [23:35:50] legoktm: while you are about... should we add emails to the CREDITS file or just stick with names? [23:36:09] and should it be alphabetic or by patch count? [23:37:00] I think alpha [23:37:12] Patch count isn't a metric of quality, or overall benefit etc [23:37:23] I don't think we should output people's emails unless they agree to it...mostly so people don't try to spam them with unrelated stuff (I could see Aaron getting a ton of random emails because he's first on the list) [23:37:27] and yeah, alphabetical [23:37:29] which can be proven emperically [23:37:42] he won't be first anymore [23:37:44] I still get email from when the api help had emails on [23:37:49] but yeah [23:38:10] first is right now "aalekhN" [23:38:20] Anyone want to merge https://gerrit.wikimedia.org/r/314820 for the last CH function deprecation? :) [23:38:22] with an alpha sort [23:38:27] Then just one hook to go [23:38:45] 8bed6734cfe196bfab22cfa7b421e96294ce33e4 [23:39:05] * bd808 logs in as legoktm [23:39:09] Did you sneeze? [23:39:18] hardware key [23:39:28] noooooooooo, that's the sha1 for "Remove API developer email addresses" [23:39:35] heh [23:39:35] heh [23:39:47] I was gonna say, it didn't look yubikey [23:40:23] ok, so no email and alphabetic [23:40:25] can we deprecate ContentHandler::deprecated() now? ;) [23:40:44] legoktm: No, I just killed it [23:40:49] :D [23:40:50] https://gerrit.wikimedia.org/r/#/c/314821/ [23:40:54] @deprecated Since 1.28, use deprecatedDeprecated() [23:41:02] Yeah, it can go [23:41:15] If doing so breaks any extensions [23:41:19] I shall be stabbing people [23:41:39] s/stabbing/gently reminding/ [23:41:47] No [23:41:49] Stabbing [23:41:53] In this case, it's appropriate [23:42:05] (he's just kidding NSA) [23:51:07] legoktm: Just Scribunto's hook usage to go [23:51:09] nudge nudge [23:51:11] wink wnk